- Praktický úvod do Docker a kontejnerů (1) – od instalace po první kontejnery
- Praktický úvod do Docker a kontejnerů (2) – propojování
- Praktický úvod do Docker a kontejnerů (3) – víc najednou aneb něco užitečného s Docker Compose
- Praktický úvod do Docker a kontejnerů (4) – jak z nich získat maximum
- Praktický úvod do Docker a kontejnerů (5) – Docker Machine
- Praktický úvod do Docker a kontejnerů (6) – cluster hostitelů s Docker Swarm
- Praktický úvod do Docker a kontejnerů (7) – scheduler v Docker Swarm
- Praktický úvod do Docker a kontejnerů (8) – váš vlastní registr obrazů
- Praktický úvod do Docker a kontejnerů (9) – multi-host networking
- Praktický úvod do Docker a kontejnerů (10) – Windows kontejnery s Docker API
- Praktický úvod do Docker a kontejnerů (11) – Windows kontejnery s PowerShell
- Praktický úvod do Docker a kontejnerů (12) – Windows Hyper-V kontejner
- Praktický úvod do Docker a kontejnerů (13) – Swarm mode, service, balancing, scaling (v1.12)
V první díle jsme se naučili základy Dockeru a v druhém jejich propojování. Dnes budeme pokračovat, ale sestavíme si něco, co bude už opravdu užitečné a výsledkem bude hotová aplikace. A protože jde o čtyři kontejnery, tak je nebudeme všechny konfigurovat ručně – správně namířená lenost je přece hnací motor pokroku, proto se seznámíme s Docker Compose.
WordPress na lusknutí
Tyto stránky jsou postaveny na open source redakčním systému WordPress – mám ho rád, dobře se s ním pracuje. Máme ho k dispozici už nainstalovaný v rámci hosting služby – zkoušel jsem si to i sám a uspěl, ale dalo to nějaké čtení, zkoušení a sem tam nějaký zásek. Pokud ale použijeme Docker, bude nám nejdelší dobu trvat stažení image (ale v porovnání s VM je to ale samozřejmě mnohem méně). Samotné nastartování nové databáze, web serveru a WordPress je pak záležitostí doslova (!) jedné vteřiny.
První co uděláme je, že vytvoříme volume kontejner, který bude publikovat prostor ve /var/lib/mysql, což je adresář, ve kterém si ve výchozí konfiguraci ukládá databáze MySQL datové soubory.
docker create -v /var/lib/mysql --name data_mysql busybox
Teď, když máme volume kontejner, můžeme vytvořit kontejner s MySQL. Použijeme oficiální image z Docker hub a namapujeme dovnitř volume z prvního kontejneru. Vyplníme dvě environmentální proměnné, na základě kterých se MySQL dokonfiguruje – heslo a jméno databáze.
docker run --name mojedb -e MYSQL_ROOT_PASSWORD=heslo -e MYSQL_DATABASE=mojedb --volumes-from data_mysql -d mysql:5.7
Připravme si další volume kontejner pro cestu /var/www/html, což je výchozí umístění pro soubory webového serveru.
docker create -v /var/www/html/ --name data_wp busybox
Teď zbývá web server s WordPress – i na ten existuje oficiální image z Docker hub (připomínám – v tomto případě nejde o nějaký binární obraz, ale Dockerfile, ve kterém je popis toho, jak se z obrazu php-apache dostat k běžícímu WordPress a php-apache je zase předpis na to, jak se z image Debian dostat na web server; něco takového si klidně můžete vytvořit sami pro vaší vlastní aplikaci … ale to už jsme rozebrali). Jak na to? Namapujeme ho na příslušný volume kontejner a uvnitř běžící službu na portu 80 přemapujeme na port 8080 na hostiteli. Dále ho prolinkujte s MySQL kontejnerem – dostanete dovnitř všechny potřebné komunikační parametry jako environmentální proměnné a obraz WordPress s tím počítá. Poslední věc je kontejneru přes environmentální proměnné prozradit jméno a heslo databáze.
docker run -e WORDPRESS_DB_PASSWORD=heslo -d -p 8080:80 --name wordpress --volumes-from data_wp --link mojedb:mysql wordpress
Otevřete prohlížeč třeba ve svém notebooku a namiřte ho na IP VM, ve které Docker zkoušíte na portu 8080, třeba http://1.2.3.4:8080 … máte hotovo, WordPress jede !
Pojďte teď příkazem docker rm -f jméno odmazat předchozí kontejnery a zkusíme to celé jinak.
Docker Compose
Rychlost, jednoduchost a opakovatelnost s jakou jsme získali WordPress se mi líbí, ale raději bych popsal celou aplikaci v jednom dobře čitelném strukturovaném souboru, kde definuji kontejnery, jejich návaznosti a linky, proměnné, porty. Ideální je pro mě formát YAML – je výborně lidsky pochopitelný (s JSON nebo XML je to horší nemluvě o binárních formátech, kde to bez čtečky dělají jen skuteční pravověrní Assembleráři) a přitom strojově zpracovatelný. Tak počkat – přesně tohle nabízí Docker Compose!
Nejprve si Docker Compose nainstalujte
sudo apt-get install python-pip sudo pip install -U docker-compose
Vytvořte nová adresář a vejděte
cloudsvet@ubuntu:~$ mkdir MojeWP cloudsvet@ubuntu:~$ cd MojeWP/
Vytvořte soubor docker-compose.yml s tímto obsahem:
cloudsvet@ubuntu:~/MojeWP$ nano docker-compose.yml data_mysql: image: busybox volumes: - /var/lib/mysql data_wp: image: busybox volumes: - /var/www/html/ wordpress: image: wordpress volumes_from: - data_wp links: - mysql environment: - WORDPRESS_DB_PASSWORD=heslo ports: - "8080:80" mysql: image: mysql:5.7 volumes_from: - data_mysql environment: - MYSQL_ROOT_PASSWORD=heslo - MYSQL_DATABASE=wordpress
Asi není potřeba moc vysvětlovat, jen si jdete pozor na správná odsazení (YAML vypadá jako takový článeček, ale ve skutečnosti má pevnou strukturu, kterou je nutné dodržet). V zásadě to co děláte v příkazové řádce tady popisujete jinak a najednou.
Pojďme to celé jedním příkazem nahodit:
cloudsvet@ubuntu:~/MojeWP$ docker-compose up -d Creating mojewp_data_wp_1... Creating mojewp_data_mysql_1... Creating mojewp_mysql_1... Creating mojewp_wordpress_1...
Přesně tak – pokud to zkoušíte tak ano, už je to všechno hotové, přesvědčte se
cloudsvet@ubuntu:~/MojeWP$ docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 54bcd8f4150d wordpress "/entrypoint.sh apach" 22 seconds ago Up 20 seconds 0.0.0.0:8080->80/tcp mojewp_wordpress_1 f56de4a61f18 mysql:5.7 "/entrypoint.sh mysql" 22 seconds ago Up 21 seconds 3306/tcp mojewp_mysql_1 fe315217c2da busybox "/bin/sh" 23 seconds ago Exited (0) 21 seconds ago mojewp_data_mysql_1 c1c9e0304abc busybox "/bin/sh" 23 seconds ago Exited (0) 22 seconds ago mojewp_data_wp_1
Představte si, že na serveru máte vždy bare metal nebo VM se vším potřebným pro Docker. Stačí tam poslat Docker Compose soubor a nahodit – třeba WordPress nebo jakoukoli jinou aplikaci, kterou dokážete kontejnerizovat. Představujte si dál – tento soubor můžete dát do versioning systému stejně tak jako Dockerfile vašich vlastních image. Změny typu novější verze některé z komponent máte zdokumentované a víte kdy a kdo je provedl a můžete kdykoli vyvolat setup jakékoli verze.
V minulém díle jsem naznačil, že se dá tohle všechno orchestrovat, automatizovat, vytvářet clustery a síťovou virtualizaci s nástroji jako je CloudFoundry (kompletní PaaS), Kubernetes, Mesos, Fleet, etcd, Swarm a další. K některým z nich se na cloudsvet rozhodně dostaneme, ale to už nebude součást úvodu do Docker, spíše pokročilejší povídání. Čeká nás další díl, který je dočasným uzavřením seriálu – pár praktických tipů jak efektivně kontejnery využít – čtěte cloudsvet. Pak se vrátíme s další várkou článků na téma Docker.
Zdravim, preco v docker kontajneroch mapujete porty z vseobecne znameho portu 80 na 8080? Nebolo by lepsie to mapovat opacne? T.j. aby som sa pripajal na sluzbu na znamom porte a nie nejakom obskurnom?
Dobrá otázka, ale odpověď na ní je vlastně na celý nový článek 🙂
V kostce: u kontejnerů se obvykle neočekává, že budou jako VM existovat měsíce či roky (spíše vteřiny, minuty, hodiny). Typicky se nasazují v nějakém cloud-native pojetí, tedy jako microservices, stateless a balancované ať už klasickým in-line způsobem pro real-time operace (např. HAproxy nebo OpenStack LBaaS) nebo dávkově asynchronně (např. RabbitMQ). Typicky se počet těchto stateless entit bude v čase velmi měnit, budou vznikat a zanikat (autoscaling). Z toho důvodu se spíše očekává, že kombinace IP:port nebude “obecně známa”, ale půjde o nějaký automatizovaný proces.
Například pro backend služby se použije nějaké service discovery jako je Consul (můj nejoblíbenější), Zookeeper, Doozerd či Etcd, případně je součastí nějakého frameworku pro orchestraci typu Kubernetes nebo dokonce součást kompletní vývojové a provozní platformy (PaaS), kde výrazně preferuji Cloud Foundry (součást např. Helion Stackato nebo Helion Development Platform). Front end bude zase reprezentován něčím jako HAproxy s tím, že jednotlivé privátní nody přidává automat (a jak moc je vnitřní port obskurní nebo není nehraje roli). Zase – tohle bude součást PaaS, Cloud Foundry má balancer a URL router v sobě.
Tedy souhlasím, že pro klasičtější nasazení ala “malá VM” může být lepší používat známé porty. Nicméně pro moderní nasazení bychom neměli mít k IP a port jakýkoli vztah na stupnici od hezkého po obskurní – abych použil známou analogii: IP, port i kontejner je dobytek, ne domácí mazlíček.
Jo – ale důvod proč v mém návodu není použit port 80 byl fakt, že mi na něm běžela jiná služba 🙂 Ale to na věci moc nemění. Navíc – takových “webových kontejnerů” budu chtít mít na jednom serveru klidně stovky. Mimochodem pro malá neprodukční prostředí jsou popsány metody jak mít HAproxy přímo na nodu (ale pokud je prostředí víc jak jeden server, jděte do vyšší orchestrace a ideálně PaaS).
Dávám vám to smysl?