Rancher.io

Dzisiejszy wpis będzie przypadkowy i zupełnie niezaplanowany…  Miało być o HA a będzie o rancher.io. Cała historia rozpoczęła się gdy w gąszczu poszukiwań orkiestratora idealnego do instytucji w jakiej pracuję natknąłem się na istnego rodzynka i postanowiłem szybko o nim napisać. Na moje oko rancher nie jest ot takim zwykłym orkiestratorem jak np. Shipyard czy ś.p. Tutum (który odrodził się jako płatny DockerCloud). Rancher proponuje poza standardową orkiestracją (dodaj host, uruchom 7 kontenerów alpine, zmień parametry postgresa) trochę dodatkowych funkcji a co za tym idzie nieco inne podejście.

Czytając dokumentację do ranchera odnoszę wrażenie że chłopaki zaplanowali sobie stworzenie kompletnego Platform As a Service (a może nawet Container as a Service)
Oto LAB jaki na szybko skleciłem aby pokazać co i jak.

3 serwery:

1. rancher01 / 10.3.0.4 – tu będzie serwer ranchera
2. rancher02 / 10.3.0.5 – węzeł #1
3. rancher03 / 10.3.0.7 – węzeł #1

Instalacja jest trywialna i w dokumentacji jesteśmy prowadzeni za rączkę z kolejnymi krokami :

Instalacja serwera rancher:

 docker run -d --restart=always -p 8080:8080 rancher/server

Instalacja 2 węzłów którymi zarządzać ma rancher:

sudo docker run -e CATTLE_AGENT_IP='10.3.0.5'  -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.0.1http://10.3.0.4:8080/v1/scripts/678CB4C7F99B4BB78736:1461909600000:IUyyQcqCVtSoz61JntddHZhp6Y

sudo docker run -e CATTLE_AGENT_IP='10.3.0.7'  -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.0.1http://10.3.0.4:8080/v1/scripts/678CB4C7F99B4BB78736:1461909600000:IUyyQcqCVtSoz61JntddHZhp6Y

po wykonaniu tych 3 poleceń oto co ukazuje się naszym oczom na naszych 3 hostach :

zaś na GUI ranchera (web gui odpala się na serwerze ranchera na porcie 8080) mamy naszą infrastrukturę:

Wstępnie w GUI nie ma usera ani hasła, dlatego admin pali się na czerwono. Oczywiście możemy dodawać sobie kontenery , zarządzać węzłami i obserwować jak performuje harware-land:

Oczywiście to nie robi na nas wrażenia (może poza ładnym CSS coś ala twitter bootstrap) gdyż to potrafi każdy orkiestrator czy byle GUI do wizualizacji farm dockerowych (np. spartański Shipyard)

Rancher jak wspominałem wcześniej idzie krok dalej. Po pierwsze chłopaki wymyślili i stosują własną sieć typu multihost – niestety nie jest ona typu docker-overlay-network. Sieć ta to na sztywno 10.42.0.0/16 , zrobiona na IPsec (a nie jak overlay na VXLAN). Dodatkowo Rancher sam przyznaje że sieć ta nie jest zgodna ze standardami dockera, a zatem nie będzie widoczna w network inspect , cytuję:

Rancher supports cross-host container communication by implementing a simple and secure overlay network using IPsec tunneling. To leverage this capability, a container launched through Rancher must select “Managed” for its network mode or if launched through Docker, provide an extra label “–label io.rancher.container.network=true”. Most of Rancher’s network features, such as load balancer or DNS service, require the container to be in the managed network. Under Rancher’s network, a container will be assigned both a Docker bridge IP (172.17.0.0/16) and a Rancher managed IP (10.42.0.0/16) on the default docker0 bridge. Containers within the same environment are then routable and reachable via the managed network.
 Note: The Rancher managed IP address will not be present in Docker meta-data and as such will not appear in the result of a Docker “inspect.” This sometimes causes incompatibilities with certain tools that require a Docker bridge IP. We are already working with the Docker community to make sure a future version of Docker can handle overlay networks more cleanly.

Po drugie – rancher (jako w założeniu PaaS) definiuje Stacki, Service i potrafi budować stosy usługowe a nawet ma Library (coś a ala katalog-sklep z obrazami). Oto definicje usługowe ze świata ranchera:

• Service to zbiór od 1 do N kontenerów opartych o ten sam obraz,
• Stack to stos usług typu Service,
• Warstwa Load Balancerów , Linków i aliasów.

Postaram się pokazać to na prostym przykładzie, najpierw jednak zróbmy na obydwu węzłach obraz pod nasze testy (apache który serwuje swój hostname):

root@rancher02:/tmp# cat Dockerfile
 FROM ubuntu:14.04
 EXPOSE 80
 RUN apt-get -y update && apt-get -y install apache2
 CMD apachectl start && hostname >  /var/www/html/index.html && /bin/bash

root@rancher02:/tmp# docker build -t apacz .

root@rancher02:/tmp# docker images
 REPOSITORY               TAG                 IMAGE ID            CREATED             SIZE
 apacz                    latest              85f42193bdc4        17 hours ago        224.1 MB

Następnie wykonajmy to samo na drugim węźle (rancher03). Kolejny krok to budowa usługi (nazwiemy ją apaczService) opartej o 4 instancje obrazu “apacz” :

Po wykonaniu tego kroku w sekcji Infrastructure w WEB-GUI otrzymujemy:

…jak widać rancher z defaultu wszystko dodaje do swojej multi-host sieci 10.42.0.0/16. W modelu ranchera otrzymaliśmy sytuację gdzie apaczService wchodzi w budowę Stacka o nazwie Default. Teraz w stacku “Default” dodajemy kolejną warstwę – LoadBalancer (tak! rancher proponuje takie usługi). W GUI wchodzimy w Applications -> Stack i wybieramy Add Load Balancer:

Następnie dodajemy LoadBalancer o nazwie “NaszLoadBalancer” , wstawiamy mapowanie portów 80 na 80 oraz wskazujemy aby LoadBalancer balansował nasz serwis (target jako = apaczService) i klikamy Save:

Nasz LB pojawił się w infrastrukturze:

Sprawdzamy jak wygląda sytuacja na hostach:

Sprawdzamy hostnames kontenerów z apacze:

 root@rancher02:/tmp# docker exec -ti 94a8d455b7ef hostname
 94a8d455b7ef
 root@rancher02:/tmp# docker exec -ti b331a7bd19f6 hostname
 b331a7bd19f6

Jak również i to samo na drugim węźle:

root@rancher03:/tmp# docker exec -ti 8b47e6179f4e hostname
 8b47e6179f4e
 root@rancher03:/tmp# docker exec -ti c4dda78e8037 hostname
 c4dda78e8037

Teraz zupełnie gdzieś z boku (np z hosta rancher01) sprawdzamy czy nasz LoadBalancer działa i płynnie rozdziela ruch między nasze 4 apacze:

root@rancher01:~# curl 10.3.0.5
 94a8d455b7ef
 root@rancher01:~# curl 10.3.0.5
 c4dda78e8037
 root@rancher01:~# curl 10.3.0.5
 b331a7bd19f6
 root@rancher01:~# curl 10.3.0.5
 8b47e6179f4e
 root@rancher01:~# curl 10.3.0.5
 94a8d455b7ef
 root@rancher01:~# curl 10.3.0.5
 c4dda78e8037
 root@rancher01:~# curl 10.3.0.5
 b331a7bd19f6
 root@rancher01:~# curl 10.3.0.5
 8b47e6179f4e
 root@rancher01:~#

Z tego co widać działa dobrze i chyba robi to nawet wyszukaną wysublimowaną metodą round-robin 🙂

Myślę, że to jest dobry moment aby pokazać pewien super patent – przeskalowanie usługi apaczService na więcej węzłów – z GUI – klikamy w nasz Stack a następnie w usługę apaczService:

Klikamy na “+” przy Scale – np do 8:

Po chwili na Infrastructure mamy jeszcze więcej węzłów (8):

zaś LoadBalancer zwraca jeszcze więcej hostname’ów 🙂

root@rancher01:~# for i in `echo 1 2 3 4 5 6 7 8`; do curl 10.3.0.5  ; done
 f9aa56d7a042
 81bf517261ed
 f92eea2cb0a1
 165c09e30e0f
 c4dda78e8037
 b331a7bd19f6
 8b47e6179f4e
 94a8d455b7ef

Wyobraźmy sobie teraz usługę kilkuwarstwową do której dla każdej warstwy możemy w zależności od potrzeb dodawać lub usuwać w ten prosty sposób moc obliczeniową. Fajne? No raczej. Kolejny fajny patent w rancher to Library:

Dodajmy sobie z tego katalogu np Jenkinsa:

Po kliknięciu “Launch” i krótkiej chwili otrzymujemy zdeployowany gotowy stack Jenkinsa (powstał nowy stack o nazwie jenkins-ci):

Jenkins był 1 kontenerowy więc poszło łatwo, dajmy rancherowi nieco ambitniejsze zadanie – kolej na 17 kontenerowego Hadoopa:

Oto co mamy w stacku Hadoopa (po długiej kawie):

Na koniec chyba wisienka na torcie… aczkolwiek jak później się okaże wisienka nieco spleśniała i nieświeża. Otóż rancher jako jeden z nielicznych na świecie (obok rackspace karina) realizuje Swarm as a Service. Po dodaniu kolejnego Environements – tym razem typu Swarm (z typów jest jeszcze kubernetes i defaultowy typ Cattle) GUI przenosi nas od razu do sekcji Adding your first Host (nie różni się ona zupełnie od klasycznego dodawania hostów, ponownie otrzymujemy curla instalacyjnego przykładowo:

sudo docker run -e CATTLE_AGENT_IP='10.3.0.8'  -d --privileged -v /var/run/docker.sock:/var/run/docker.sock -v /var/lib/rancher:/var/lib/rancher rancher/agent:v1.0.1 http://10.3.0.4:8080/v1/scripts/DB20B9DC347DE293CED1:1461924000000:qqgHtI0y5Jc463kEylO2aRdFuG8

Różnica zaczyna się po jego uruchomieniu – na maszynie rancher04 bowiem poza standardowym dwuskładnikowym agentem ranchera pojawiają się dodatkowe 2 maszyny swarmowe:

Następnie w GUI dodajemy drugi węzeł hardware-land (rancher05 – 10.3.0.9) – tym razem znowu klasycznie curlem instalacyjnym. Przy drugim node obrazy swarmowe się na już nie pojawiają – zgodnie z notką z dokumentacji:

"The swarm agent does not need to be deployed on all hosts."

po podłączeniu się do swarm-agenta otrzymujemy znajomo wyglądające listingi swarma:

root@rancher04:~# docker ps | grep swarm | grep agent
2eabb934f09a        rancher/swarm-agent:v0.1.2      "swarm-agent"            46 minutes ago      Up 46 minutes                                                      r-Swarm_swarm-agent_1
e65255cadbeb        rancher/swarm-agent:v0.1.2      "swarm-agent server -"   46 minutes ago      Up 46 minutes                                                      r-Swarm_swarm_1

root@rancher04:~# docker exec -ti r-Swarm_swarm-agent_1 bash

root@2eabb934f09a:/# docker info
Containers: 17
Running: 9
Paused: 0
Stopped: 8
Images: 7
Server Version: swarm/1.1.3
Role: primary
Strategy: spread
Filters: health, port, dependency, affinity, constraint
Nodes: 2
rancher04: localhost:3000
└ Status: Healthy
└ Containers: 9
└ Reserved CPUs: 0 / 1
└ Reserved Memory: 0 B / 1.718 GiB
└ Labels: executiondriver=, kernelversion=4.2.0-23-generic, operatingsystem=Ubuntu 15.10, storagedriver=aufs
└ Error: (none)
└ UpdatedAt: 2016-04-29T10:17:15Z
rancher05: localhost:3001
└ Status: Healthy
└ Containers: 8
└ Reserved CPUs: 0 / 1
└ Reserved Memory: 0 B / 1.718 GiB
└ Labels: executiondriver=, kernelversion=4.2.0-23-generic, operatingsystem=Ubuntu 15.10, storagedriver=aufs
└ Error: (none)
└ UpdatedAt: 2016-04-29T10:17:18Z
Plugins:
Volume:
Network:
Kernel Version: 4.2.0-23-generic
Operating System: linux
Architecture: amd64
CPUs: 2
Total Memory: 3.437 GiB
Name: e65255cadbeb

To samo CLI jest zresztą wystawione na WEB-GUI w sekcji Swarm->CLI. Swarm w wydaniu ranchera jednak posiada (to wyłącznie moja prywatna opinia) kilka wad:

• brak wsparcia dla docker overlay networks (jak wspominałem wcześniej rancher proponuje własne podejście do sieci multi-host w oparciu o swoją sieć)
• swarm-master połączony z węzłem obliczeniowym swarma (imho tak się nie powinno robić)
• niejasny kanał komunikacji między węzłami swarma – skoro wszystko leci przez unux-sockety to kanał prawdopodobnie jest zestawiony w środku sesji rancher-agentów
• nie chcę myśleć jak bardzo trzeba by rozgrzebać obrazy ranchera aby wdrożyć pełne TLS’y
• nie da się nadinstalować ranchera na istniejący produkcyjny klaster swarma

Ogólnie to dobrze że rancher oferuje swarm as a service, ale moim zdaniem daleko mu do ideału. Idąc jeszcze dalej – osobiście nie widzę szansy na użycie tak spreparowanego swarma u siebie na produkcji.

Czas na podsumowanie.

Rancher to świetny produkt, w dodatku za darmo. Z założenia jest on – premisowy więc mamy wybór czy instalujemy go u nas czy w AWS/Azure (w przypadku Tutuma wyboru nie mamy). Patrząc na rozwój platformy widać że chłopaki bardzo się starają, widać ciągły postęp i dbałość o detale, ale…

W świecie dockera jakoś tak już jest że produkty które załapią się na elitarną listę “made by docker team” stają się po pewnym czasie standardem a produkty konkurencyjne systematycznie słabną (nawet jeśli są lepsze). Czy widzę przyszłość Ranchera ? Mam pewne obawy , dosyć popularny Tutum (główny konkurent) przeszedł w ręce dockera i przez to stał się platformą referencyjną , docker dodał do tego jeszcze UCP.

Na moje oko nad rancherem zawisły nieco czarniejsze chmury ale trzymam za nich kciuki bo produkt mimo kilku wad mnie urzekł. To tyle polityki, teraz dwie główne imho merytoryczne wady ranchera:

1. niemoc współpracy z socketem innym niż unix (to co ja mam zrobić jak mam produkcyjny deploy swarma na SSL tcp:2376?)  Prostacki byle shipyard potrafi to ogarnąć… https://github.com/rancher/rancher/issues/1670

2. rancher nie umie zainstalować się na środowisku już pracującym:

“As Rancher adds support for multiple cluster management frameworks, Rancher currently does not support the ability to switch between environments that already have services running in it.”

A poza tym jest to naprawdę świetna platforma, każdy kto szuka dobrego orkiestratora powinien kilka dni sobie w niego poklikać, na pewno się spodoba