Tomáš Záluský: března 2016

Začínám s Dockerem a dal jsem si za cíl zprovoznit docker-machine. Bohužel Windows není pro Docker systém jaksi úplně nativní, i když za poslední měsíce došlo ke značnému pokroku. Samotný postup instalace je jednoduchý, tutoriál na docker.com vodí za ručičku. Stačí začít zde a postupovat po wizardu až do konce. Nicméně troubleshooting mi dal některé zkušenosti, které chci zachytit:

Virtualizace

na mém ntb nebyla zapnutá, ale po rebootu do BIOSu se checkbox snadno najde a zapnutí se projeví ve Windows přesně dle tutoriálu.

VPN

Při buildování vlastního image se nedařilo připojení na archive.ubuntu.com. Odpověď nalezená na SO mi pak pomohla si uvědomit, že jsem na VPN, neboť problém s DNS jsem před časem kvůli VPN taky řešil. Stačilo se tedy jen odpojit. Jinak nefungující apt-get v Dockerfile je možné zkoušet v dockerovém linux terminálu napřímo, není nutné volat docker run.

403 při docker login

V kroku přihlášení se k Docker hubu akce selhávala po nezvykle dlouhém timeoutu na chybu 403 Request forbidden by administrative rules. Návody, které radily volat docker login s URL registry nebo editovat soubor .docker/config.json, se nakonec ukázaly jako zavádějící, řešení bylo prozaičtější: upgradnout Docker Toolboxu z 1.9 na 1.10. Jsou to všechno relativně mladé issues a udržovat si nejnovější verzi se vyplatí. Po upgradu už to bylo ok.

Upgrade Docker Toolboxu

Docker Toolbox aktuálně nemá mechanismus automatických aktualizací, i když issue na zlepšení v tomto směru existuje. Podle oficiálního návodu se upgrade provede prostým nainstalováním nové verze. To však v mém případě vedlo na chybu startu docker machine An error occurred trying to connect ConnectEx - No connection could be made because the target machine actively refused it. a Machine state changed to 'PoweredOff'. Protože na ni jsem vesměs nic nenašel, odinstaloval jsem nový Docker Toolbox a pro jistotu i VirtualBox a rebootnul počítač. Pak už instalace nové verze i spuštění proběhlo bez problému.

DNS

Chyby apt-getu jako např. Err http://archive.ubuntu.com ... InRelease nebo W: Failed to fetch http://archive.ubuntu.com/ smrdí problémem připojení k internetu. Obzvlášť když na jedné síti (doma) to jde a na jiné (na firmě) už ne. Zabývá se tím toto issue a mně pomohlo otevřít síťová propojení, najít virtuální síťovku nainstalovanou s VirtualBoxem a ve známém okně Vlastnosti vyplnit Internet Protocol Version 4 -> Preferred DNS server 8.8.8.8 (případně Alternate 8.8.4.4). Restart VirtualBoxu. Zřejmě by šly i ostatní tipy (přepínač -dns - ten je ale jen u docker run, ne už u docker build, DOCKER_OPTS nebo nastavení etc/resolv.conf).

Asociace názvu s docker machine

Pro přístup k docker machine přes jméno a ne přes IP je třeba přidat do souboru c:\windows\system32\drivers\etc\hosts záznam pro příslušnou IP. Tu zjistíme buď při startu Docker Toolbox klienta z hlášky docker is configured to use the default machine with IP 192.168.99.100, nebo v shellu boot2dockeru (spuštěném pro danou docker machine z GUI VirtualBoxu přes Start -> Normal Start) příkazem ifconfig nebo příkazem docker-machine ls. Ověřit přes ping docker nebo ssh docker@docker, default heslo tcuser.

Přístup k adresářům na fyzickém stroji

Přepínač -v ve volání docker run -v $PWD:/somedirectory vezme adresář v docker virtuálce zadaný před dvojtečkou (zde aktuální) a zviditelní ho v kontejneru pod cestou zadanou za dvojtečkou. V prostředí Windows ale docker virtuálka běží pod VirtualBoxem, a proto se musí nastavit ještě sdílení ve VirtualBoxu a mount adresáře z docker virtuálky. Celý návod včetně příslušných příkazů a screenshotů je v tomto výborném článku.

Automatický mount v souboru profile

VirtualBox defaultně zpřístupňuje pouze domovský adresář uživatele. Tento setup byl ale pro účely našeho projektu nevhodný, protože docker potřeboval vidět na adresář s projektem, který leží mimo můj domovský adresář v /c/java/workspace/myproject. Jak plyne z předchozího oddílu, pro ustanovení propojení Windows-virtuálka musí být adresář namountován, To lze udělat přepnutím se do konzole shellu virtuálky (nebo z Docker toolbox klienta přes ssh) a spuštěním příkazu sudo mount -t vboxsf -o uid=1000,gid=50 somedirectory /c/java/workspace/myproject/ (sudo, protože jsme pod uživatelem docker, ne pod rootem). Následně lze zkontrolovat přes mount df -h. To je ale nutné dělat při každém startu klienta znovu. Alternativní možnost je proto spouštět mountování v souboru /mnt/sda1/var/lib/boot2docker/profile (bližší popis viz předchozí odkaz).

Výhodou tohoto setupu je, že přežije restart docker-machine. Musí se opakovat pouze po restartu celého VirtualBoxu. Vzhledem k jiným pozdějším zásahům do VirtualBoxu, které vyžadovaly restart, jsem proto variantu přes profile soubor považoval nejdříve za nezajímavou (nastavení se ztrácelo), ale teď už to vypadá stabilně.

Jak ověřit, zda už je na obsah adresáře vidět? Pokud trvá docker run dlouho a na nesprávné namountování adresáře přijde až pozdě, pak je takové zkoušení zdlouhavé. Není však nutné se zdržovat opakovaným voláním původního docker run, místo toho lze buď spustit kontejner v interaktivním režimu (docker run -i -t -v $PWD:/somedirectory myproject /bin/bash) anebo zkusit jiný kontejner, jehož spuštění tak dlouho netrvá (typicky připravené ubuntu - docker run -v $PWD:/somedirectory -it ubuntu bash). V obou případech pak vypsat ls somedirectory.

Perlička: při rozběhávání jsem udělal zkušenost s union file systémem, který tvoří stavební kámen Dockeru. Po jednom nezdařeném pokusu, kdy se ještě adresář nenamountoval, jsem chtěl smazat prázdný adresář /c/java/workspace/myproject v shellu virtuálky. Věděl jsem sice, že nemám explicitně namountovaný jiný adresář, ale zapomněl jsem na automatický mount domovského adresáře. Proto se rm -rf /c/ pokusil smazat celý domovský adresář. Naštěstí na věci mimo Docker neměl práva, proto se celkem nic nestalo - schytal to však právě adresář .docker, kde příkaz smazal systémové soubory a po podivných chybách jako např. Could not read CA certificate ... ca.pem: The system cannot find the file specified. jsem usoudil, že nejlepší bude celý Docker Toolbox přeinstalovat.

Problém s chybějícím dvojitým lomítkem jsem však neměl.
Více o volumes.

Symlinky

Máme konečně přístup do adresáře, ale ještě není vyhráno, Docker chce vytvářet symbolické linky, ale nedaří se, symptomem jsou chyby jako run EROFS: read-only file system, symlink a samozřejmě failující docker run. Řešení má 2 kroky: (1) nastavit příslušný parametr VirtualBoxu, který povoluje symlinky pro daný adresář: VBoxManage setextradata default VBoxInternal2/SharedFoldersEnableSymlinksCreate/somedirectory 1 a (2) spustit VirtualBox jako administrator.

Kroky jsem aplikoval v uvedeném pořadí, takže už jsem neověřoval, zda by problém nebyl vyřešen pouze tím druhým. Pro příkaz setextradata existuje i ekvivalent getextradata (bez hodnoty na konci) pro ověření efektu. Protože ke spouštění VirtualBoxu dojde automaticky z Docker Toolboxu, musí se i Docker Toolbox spouštět jako administrator, ideálně to nastavit přímo ve vlastnostech zástupce. Docker machine default, která běží ve VirtualBoxu spuštěném jako administrator, se ve VirtualBoxu spuštěném normálně jeví jako vypnutá!

Pro ověření funkčnosti opět není potřeba opakovat případnou dlouhotrvající operaci, stačí nastartovat kontejner jako v předchozím odstavci a zkusit vytvořit link pomocí ln -s existingfile.txt linkname.txt.

Ostatní tipy

Smazání kontejneru

Smazat image příkazem docker rmi imagename není dobré, pokud nad imagem běží kontejner. Ve výpisu docker images zůstane image viset s <null> jménem. Použití rmi -f přes hash sice image smaže, ale kontejnery to samo o sobě nesestřelí! Je proto lépe nejdřív vypsat si kontejnery pomocí docker ps, stopnout příslušný kontejner pomocí docker stop a až pak teprve mazat image. Pokud už jsme smazali image, kontejnery stopnout dodatečně, užitečný je hromadný příkaz docker rm $(docker ps -a -q).