Docker w wydaniu Oracle

Jak wiadomo większość dostawców chmur ma swoje platformy do konteneryzacji, jedne są lepsze, inne gorsze, generalnie jednak większość dąży do wystawiania środowiska w modelu Container As A Sevice. Odrębnym zjawiskiem są oczywiście produkty z gatunku Rancher, które są w stanie również on-premisowo świadczyć nam usługę CaaS. W sumie dodać by należało tu też DCOS i Kubernetes, może i nawet Swarm. Ostatnio przyglądałem się na przykład implementacji Cisco UCS z wbudowanym Docker DataCenter i też spełniało to wszystkie funkcje kompleksowego kombajnu do obróbki kontenerów. Wszystkie platformy powyżej to tzw. COE (Container Orchestration Engine) i faktycznie, dla pewnych klientów, takie platformy są bardzo pomocne. Inna sprawa że są klienci, którzy wolą samodzielnie zbudować rozwiązanie „skrojone pod siebie” i posklejać sobie taki kombajn z ściśle wyselekcjonowanych komponentów (bo np. loadbalancer w swarmie im nie odpowiada, czemu zresztą ciężko się dziwić), czasami uwiera KVS wybrany w backendzie (nie każdy lubi etcd), czasem trzeba popisać nieco inne templejty dla konfigów itd. itp.

W tej rzeczywistości Oracle również musiał jak najszybciej się odnaleźć i w tym celu stosunkowo wcześnie (bo w grudniu 2015) dokonano akwizycji platformy StackEngine, który takim kombajnem niewątpliwie jest. Co więcej mimo że SE mnóstwo rzeczy narzuca nam po swojemu to jednak jest kombajnem zdecydowanie dopracowanym i posiadającym wszystkie elementy jakie mogą okazać się potrzebne. Rzecz jasna dobry admin będzie umiał zastąpić pewne rozwiązania ze środka własnymi komponentami i wspawać np. własne registry czy własny reverse proxy. Z drugiej strony skoro wszystko już jest na pokładzie to może nie warto się męczyć ? 🙂

Produkt dostarczany jest w ramach Oracle Public Cloud i zgrupowany jest pod banderą Oracle Container Cloud Service. Tyle teorii i wstępu, przechodzimy do konkretów.

Po wykreowaniu środowiska (w naszym LABIE to 1 master i 2 workery) i zalogowaniu otrzymujemy całkiem fajny dashboard. Gdyby pojawiło się jeszcze trochę czerwonego koloru byłbym już na starcie całkowicie kupiony przez Orac(L)e 🙂

Pierwszy niezły ficzer – platforma trackuje wszystkie nasze czynności :

W SE powołano zjawisko „Service” które jest  odpowiednikiem service w swarm i application w marathon – zresztą (tu widać tylko początek) dostarczona „out of the box” lista jest całkiem spora:

Sprawdźmy zatem jakiś pierwszy service z brzegu – np. „apache”:

Service jest jak widać stosunkowo nieźle uzbrojony i parametryzowywalny.

A teraz powołajmy do życia nasz własny serwis – będzie to oczywiście nieśmiertelny (występujący chyba we wszystkich odcinkach tego bloga) obraz serwujący swój hostname na porcie 80 – czyli “apacz”:

Warto zwrócić uwagę na zmienne occs (konieczne dla StackEngine) oraz definicje portów

Tak zdefiniowany serwis możemy wystartować:

Przy starcie możemy podać quantity czyli swarmowe replicas tudzież marathonowe scale.

Można też podać scheduling policy:

po wystartowaniu service widać efekt w sekcji Deployments (trochę coś a la marathon?):

po wejściu w nasz deploy widać status usługi:

można też zmienić ilość kontenerów (czyli wykonać scaling):

Co daje nam następujący efekt:

Kontenery rozpędzane przez StackEngine są widoczne na hostach jako:

widać je też dosyć szczegółowo w zakładce Containers:

zakładka Hosts zawiera z kolei info o węzłach w hardware-land i ich utylizacji:

bardzo ciekawa opcja to service discovery (tak, zrobili to, też byłem zdziwiony, duży plus) :

Jak widać wszystkie kontenery ładnie się zameldowały.

Po kliku w Edit dla rekordu z Service Discovery otrzymujemy możliwość wglądu a nawet podmiany zarejestrowanych parametrów:

W discoveringu poza „Services” mamy też rasowy Key Value Store :

Wszystkie powyższe ficzery skłaniają do jednego – czas na auto-load-balancer w oparciu o discovery J

Najpierw jednak trzeba wprowadzić pojęcie „stacka” – jest to już aplikacja czyli zbiór usług, właściwie jest to zbieżne ze stackami w swarm.

Na dzień dobry otrzymujemy kilka predefiniowanych stacków:

po kliknięciu w pierwszy z brzegu otrzymujemy jego definicję w Yaml która jest o dziwo zbieżna z docker-compose (!):

Właściwie gdyby nie parametry OCCS_xxx to byłby to format który miłośnicy docker-compose widzą na co dzień.

Stwórzmy sobie zatem nasz własny stack (o nazwie „my-stack”):

Cóż takiego on robi ? patrząc na YAML można wywnioskować że będziemy tu frontowym rev-nginxem load-balansować do backendowego contentu z obrazu apacz. Co więcej – ten LB będzie zaczytywał konfig backendu z Service Discovery gdzie inne kontenery będą się rejestrowały.

Stack pojawia się na liście jako „my-stack”:

Nie pozostaje nic innego jak go zdeployować – podczas tej czynności w sekcji orchestration for backend wybieramy quantity=2 (czyli będą 2 serwery contentu w backendzie) :

Frontowy Load-balancer będzie występował na razie w liczbie = 1 :

Po uruchomieniu po chwili w zakładce Deploymens pojawi się nasz stack:

po wklikaniu się w niego widać jak wygląda status całości:

Na hostach zaś będziemy mieli następującą sytuację w kontekście rozpędzonych dockerów:

Pozostaje sprawdzić czy autorejestracja w ServiceDiscovery, auto-rekonfiguracja LB i samo load-balansowanie ruchu faktycznie działa. Testujemy zatem całość aplikacji – efekt jest zgodnie z oczekiwaniami taki że curl na port LoadBalancera zwraca raz jeden kontener raz drugi:

Oczywiście w service discovery mamy pełną informację o naszych usługach – jak widać wszystko się ładnie (i automatycznie rzecz jasna) porejestrowało:

po przeskalowaniu backendu faktycznie zmienia się konfig LoadBlancera i zaczyna serwować 2 kontenery :

# cat /etc/nginx/nginx.conf

worker_rlimit_nofile 8192;

 

events {

worker_connections  4096;  ## Default: 1024

}

 

http {

upstream myapp1 {

# `confd` writes backends dynamically

# You will need to manually change the key to the one you want

# Don’t forget to do this in the TOML file as well.

 

server 10.196.91.234:11180;

server 10.196.91.230:11180;

}

 

server {

listen 80;

location / {

proxy_pass http://myapp1;

}

}

}

/

[root@rfdemo-occs-wkr-2 ~]# curl 127.0.0.1:8885a

Container Hash: 1.backend.stack-slawek-nginxLb-apacheBcknd-20170524-145736

[root@rfdemo-occs-wkr-2 ~]# curl 127.0.0.1:8885

Container Hash: 0.backend.stack-slawek-nginxLb-apacheBcknd-20170524-145736

[root@rfdemo-occs-wkr-2 ~]# curl 127.0.0.1:8885

Container Hash: 1.backend.stack-slawek-nginxLb-apacheBcknd-20170524-145736

[root@rfdemo-occs-wkr-2 ~]#

 

Na koniec informacja jak budować obrazy i stacki.  Bazujemy na repo:

https://github.com/oracle/docker-images/tree/master/ContainerCloud

Repo to należy sklonować na local PC (jest dosyć duże), wybrać które IMG lub Stacki chcemy deployować i zrobić stosowne make.

W wyniku make na obrazach powstają obrazy zaś w wyniku make na stackach powstają gotowe pliki YML dla stacków.

To by było na tyle – teraz słowo komentarza na zakończenie. Stack Engine to niezła platforma, posiada co prawda swoje kaprysy i czasami narzuca nam własne podejście ale z drugiej strony bardzo łatwo jest zmodyfikować poszczególne komponenty, usunąć domyślne i zastąpić naszymi. Olbrzymi plus za wbudowanie Service Discovery i za to że działa ono bardzo dobrze i stosunkowo przejrzyście. Druga zaleta to zgodność z YAML docker-compose co po powrocie tego formatu do łask w świecie dockera jest bardzo dobrym krokiem. Również pozytywne jest to, że nie narzuca się użytkownikowi na sztywno działającego load-balancingu ale że istnieje szeroki wybór i pełna dowolność.

Warto zauważyć że repo dostarczonego kodu i konfiguracji jest bardzo duże i można w nim znaleźć olbrzymią ilość wariantów dla bardzo wielu aplikacji, w sumie chyba tylko bardzo wymagający użytkownik będzie musiał budować swoje rozwiązania, w pozostałych przypadkach można ograniczyć się do wykorzystania gotowego lub ewentualnie jego kosmetycznej zmiany.

A teraz wady – w sumie będą dwie. Subiektywnie wg mojej opinii pierwsza wada polega na tym że nie do końca wiadomo dla kogo jest ten produkt (Rancher ma ten sam problem). Zaawansowani użytkownicy mają już od dawna w swoich DataCenters zainstalowane liczne farmy Mesosa czy Swarma z całą uszytą na miarę batalią auto-registry, load-balancingu, monitoringu czy skalowalności. Użytkownicy początkujący lub developerzy nie będą się chcieli tego uczyć bo wyklikają sobie w AWS gotowca w postaci DCOS lub kupią Docker Data Center.

Druga wada jest zdecydowanie poważniejsza – StackEngine jest dobrym produktem, jest stabilny, ma kupę ficzerów, większość koniecznych funkcjonalności itd. Dlaczego zatem jest tak mało popularny? Microsoft robi masę szumu wokół Azure Container Service , AWS czy Google dokoła swoich CaaS również, mnóstwo webinariów czy występów na konferencjach dockerowych wykonuje IBM, DigitalOcean czy Rackspace, nawet Rancher mimo że jego niestabilność jest już owiana miejskimi legendami robi kawał dobrej roboty i ma rosnącą popularność. Odpowiedź jak dla mnie jest prosta – marketing wokół tej platformy jest na bardzo słabym poziomie i backend pre-salesowy i techniczny w Oracle nie ma położonego zbyt dużego nacisku na popularyzację tej technologii. Na moje oko albo Oracle zacznie to popularyzować i sprzedawać na poważnie albo niech po prostu wrzuci to jako open-source, da za darmo i co najwyżej sprzedaje płatne wersje ze wsparciem tak jak to zrobił Mesosphere z DCOS’em. A tak to mamy kawał dobrego softu który jest przed nami użytkownikami skrzętnie ukrywany 🙂