Cvičení: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14.
Hlavním tématem tohoto cvičení je používání kontejnerů: lehkých virtuálních strojů, které jsou velmi užitečné pro testování a vývoj. Na to navážeme v posledním cvičení kde si pomocí nich nastavíme tzv. continuous integration.
Zvláštní téma o tisku a skenování můžete s klidem přeskočit pokud nemáte moc času.
Předstartovní kontrola
- Víte, že software se na Linuxu instaluje pomocí správce balíčků.
Kontejnery
Kontejnery jsou dalším způsobem izolace. Zatím jsme viděli izolování projektu sandboxingem a mnoho z vás si vyzkoušelo virtualizovanou instalaci Linuxu.
Kontejnery jsou někde na pomezí.
Nabízejí izolované prostředí, které se v podstatě chová jako virtualizovaný
stroj.
Z implementačního hlediska jsou blíže virtuálním prostředím, protože procesy
uvnitř
kontejneru jsou viditelné z hostitele.
Můžeme si to představit tak, že kontejner dostane jeden adresář (který
obsahuje obvyklé podadresáře
jako /dev
, /proc
nebo /home
) a z něj nemůže uniknout.
Kvůli tomu mohou kontejnery spouštět jen aplikace napsané pro tentýž operační systém (na rozdíl od plnohodnotného virtuálního stroje).
Protože jsou kontejnery od hostitelského systému odděleny, jsou v mnoha situacích velmi užitečné. Pochopitelně je tu i možnost použít plně virtualizovaný stroj (např. VirtualBox nebo QEMU), ale kontejnery jsou lehčí a mají menší režii (např. rychlejší start).
Oddělení od hostitelského systému je poměrně velké: bez dodatečné konfigurace se kontejner nemůže dostat na hostitelův systém souborů a nemůže poslouchat na žádných portech (pro příchozí spojení). Může ale začít odchozí komunikaci (např. stahovat balíčky, které je potřeba nainstalovat). Kontejner může být též omezen množstvím paměti RAM, kterou může použít. Ve výchozím nastavení jsou procesy uvnitř kontejneru plánovány jako běžné procesy (tj. mají stejnou prioritu), je ale možné omezit i jejich přístup k CPU (čili je zpomalit jako úlohy s nízkou prioritou).
Typickým příkladem je potřeba spustit izolovaný server, který potřebujete pro vývoj. Zde si můžete představit třeba databázový nebo webový server. Určitě můžete takový server nainstalovat do systému (vzpomeňte si na cvičení 09). Tam ale není od systému nijak oddělený a odinstalace také není úplně přímočará. Vzpomeňte si, jak fungují virtuální prostředí: odstraněním jednoho adresáře odstraníme kompletně celé prostředí.
Podobně, odstranění kontejneru je jednoduchá a rychlá operace a nový můžete nastartovat během pár vteřin.
Používání kontejneru vám také umožní přesně určit, jak bude vše vypadat:
které procesy se spustí, na kterém portu bude poslouchat atd.
Tuto konfiguraci pak můžeme lehce kodifikovat (podobně jako
requirements.txt
) a díky tomu snadno zopakovat na jiném stroji.
Obrazy kontejnerů jsou také často používány, když potřebujete distribuovat složitou aplikaci, která vyžaduje běh několika služeb. Namísto poskytnutí detailního manuálu nebo obrazu disku pro VirtualBox můžete dodat kontejner, který již bude připraven ke spuštění. Uživatel pak spustí celý kontejner a ten si už sám uvnitř vyřeší zbytek a navenek zpřístupní cílovou službu. Například celý GitLab lze stáhnout a používat v kontejneru.
Docker a Podman
V tomto cvičení se podíváme na základy Linuxových kontejnerů postavených nad
Dockerem a Podmanem.
Obě implementace jsou v podstatě stejné.
Jejich hlavní příkazy (docker
a podman
) podporují úplně stejné argumenty
a mají skoro vždy úplně stejnou sémantiku.
Hlavním rozdílem je, že Docker je trochu starší (ale je stále ještě vyvíjen) a byl zamýšlen pro systémové kontejnery (např. pokud byste si chtěli pustit vlastní GitLab). Podman je o něco mladší a využívá nové vlastnosti Linuxového jádra, které mu dovolují spouštět kontejnery bez práv superuživatele (což je pořád ještě poměrně nová funkce Linuxu). Navíc, Podman se lépe integruje do zbytku systému.
Z tohoto pohledu je Podman perfektní volbou pro vývojáře. Potřebujete databázový server? Použijte Podman s tím správným kontejnerem a spusťte ho. Vaše databáze je připravená k použití. To vše bez potřeby práv superuživatele (často se setkáte s označením rootless mode).
Na druhou stranu, pokud máte o něco starší verzi Linuxu nebo kontejner vyžaduje specifické vlastnosti Dockeru, Docker může být lepší volbou.
Terminologie …
V tomto cvičení jsou důležité dva koncepty. Obraz (image) a kontejner (container). Jsou trochu podobné třídě a objektu (instanci) nebo programu a běžícímu procesu.
Obraz je něco jako pevný disk pro izolované prostředí. Obsahuje všechny potřebné soubory: spustitelné i datové soubory.
Abychom ho spustili, vytvoříme kontejner. Kontejner je spuštěn se stejným stavem jako obraz, ale má i běžící procesy, které mohou měnit jeho stav. Pokud o to explicitně nepožádáme, změny provedené kontejnerem nejsou uloženy zpátky na obraz: místo toho je kontejner spuštěn s kopií obrazu a mění tuto kopii.
Procesy v kontejneru jsou izolovány od okolí (hostitele) a kontejner nevidí procesy hostitele.
Na druhou stranu, procesy v kontejneru jsou viditelné na hostiteli. Kořenovému adresáři kontejneru odpovídá nějaký podadresář na hostiteli. ID uživatelů v kontejneru jsou přeložena na uživatelská ID hostitele. To samé platí o skupinách.
Docker/Podman obvykle spouští své procesy s privilegii kontejnerového
uživatele root
, který se navenek – v hostiteli – tváří jako obyčejný
uživatel (obvykle s velmi vysokým UID).
Skládání obrazů
Nové obrazy jsou obvykle odvozeny od jiných, již existujících. Například existují základní obrazy systému a z nich jsou vytvářeny další specializované obrazy. To zjednodušuje konfiguraci, protože můžeme začít s předpřipraveným stavem a nemusíme začínat od nuly.
Pro ušetření místa jsou odvozené obrazy ukládány jen jako rozdíl oproti základnímu (rodičovskému) obrazu. Rozdíly jsou pak sloučeny (overlay) se základním obrazem v okamžiku, kdy se vytváří kontejner.
To zlepšuje výkon a šetří místo na disku i v paměti (pokud vám běží více kontejnerů se stejným základním obrazem, tak stačí jedna sdílená instance základního obrazu). Také když stahujete nový obraz, můžete stahovat jen rozdíly, pokud jste už dříve stáhli základní obraz.
Tento mechanismus je trochu podobný tomu, co dělá Git. Tváří se, že každý commit je vlastně kompletní kopie celého stromu souborů v projektu. Interně si ale zaznamenává jen rozdíly mezi soubory.
Distribuce a Alpine
Obrazy můžou být vytvořeny nad různými distribucemi. Díky tomu jsou kontejnery snadnou cestou, jak vyzkoušet váš program v různých distribucích bez nutnosti instalovat triple- (nebo více-) boot nebo se starat o několik virtuálních strojů.
Brzy uvidíte, že mnoho kontejnerů je postaveno nad distribucí Alpine Linux. To je minimalisticky navržená distribuce (velikostí i složitostí) – má okolo 6 MB a nemá žádnou složitou konfiguraci.
Alpine používá Apk (Alpine package manager) pro správu balíčků. Například následující příkaz nainstaluje curl (který není nainstalován ve výchozím stavu):
apk add curl
Nastavení Dockeru/Podmanu
Nainstalujte Docker nebo Podman.
Následující příkaz by vám měl pomoci rozhodnout, který z nich vlastně potřebujete.
grep cgroup /proc/filesystems
Pokud uvidíte jen následující řádku, váš kernel nezná cgroups v2, které potřebuje Podman.
nodev cgroup
Pokud ale uvidíte následující, máte cgroups v2 povolené a měli byste používat Podman.
nodev cgroup
nodev cgroup2
Pak pokračujte s instalací.
Nejnovější verze Fedory už přešly na cgroup v2 a instalace Podmanu je
jedinou možností.
Takže ho instalujte pomocí sudo dnf install podman
.
Všechny následující příklady budou používat příkaz podman
.
Pokud vaše distribuce Podman nepodporuje, nahraďte jej příkazem sudo docker
.
Podman: nastavení /etc/subuid
a /etc/subgid
Jak jsme vysvětlovali výše, Podman potřebuje určitý rozsah volných ID uživatelů a skupin, aby do nich mohl namapovat UID a GID z kontejneru.
Superuživatel může bloky UIDů/GIDů přidělovat obyčejným uživatelům, kteří je
pak mohou takto využívat.
Říká se tomu sub-UID/sub-GID a jejich nastavení je zaznamenáno v souborech
/etc/subuid
a /etc/subgid
.
Nejdříve si, prosím, zkontrolujte, zda-li váš /etc/subuid
neobsahuje něco
jako intro:100000:65536
. Pokud ano, máte už vše připravené a můžete zbytek
této sekce přeskočit.
Jinak se ujistěte, že tento soubor existuje, a vytvořte nové přiřazení
pomocí usermod
:
sudo touch /etc/subuid /etc/subgid
sudo usermod --add-subuids 100000-165536 --add-subgids 100000-165536 YOUR_LOGIN
Systémová (balíčková) aktualizace může občas Podman z různých důvodů rozbít.
Pokud se vám to stane, zkuste vždy nejdříve spustit podman system migrate
,
který obvykle vyřeší většinu
chyb spojených s přechodem na novější verzi.
Docker: spuštění služby
U Dockeru je potřeba se ujistit, že běží dockerd
. Obvykle by měl stačit
následující příkaz:
sudo package-manager-of-your-distribution install docker
sudo systemctl enable docker
sudo systemctl start docker
Základní test funkčnosti
Spusťte podman info
, čímž získáte základní informace o
systému. Pravděpodobně uvidíte něco jako:
host:
arch: amd64
...
cgroupManager: systemd
cgroupVersion: v2
conmon:
...
...
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 100000
size: 65536
...
os: linux
...
store:
graphRoot: $HOME/.local/share/containers/storage
...
runRoot: /run/user/1000/containers
volumePath: $HOME/.local/share/containers/storage/volumes
version:
APIVersion: 3.0.0
...
Až budete ladit problémy s Podmanem, vždy vložte tuto informaci (bez dalších úprav)
do popisu Issue (pochopitelně, vkládejte text do ```
, nikoliv jako screenshot!).
Abyste ověřili, že můžete kontejnery spouštět, zkuste následující příkaz:
podman run --rm docker.io/library/alpine:latest cat /etc/os-release
Pokud uvidíte něco jako následující výpis, vše je připraveno. Jinak klidně otevřte Issue na Fóru a pokusíme se to nějak vyřešit (nezapomeňte říct, kterou distribuci používáte).
Trying to pull docker.io/library/alpine:latest...
Getting image source signatures
Copying blob 4abcf2066143 done |
Copying config 05455a0888 done |
Writing manifest to image destination
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.19.1
PRETTY_NAME="Alpine Linux v3.19"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
První polovina výstupu se týká stažení obrazu. Teprve druhá polovina odpovídá výstupu příkazu. Neváhejte a spusťte výše uvedený příkaz ještě jednou (protože obraz je již stažen), abyste získali následující výstup:
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.19.1
PRETTY_NAME="Alpine Linux v3.19"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
Podman je částečně k dispozici i na počítačích v IMPAKTu a jeho instalace (i když s určitými omezeními) by měla být pro naše účely dostatečná.
Je však mnohem pohodlnější používat vlastní počítač.
podman
na linux.ms.mff.cuni.cz
, vždy odstraňte
nepoužívané obrazy. Zatímco systém má dostatek místa pro experimentování,
obrazy mohou snadno zaplnit celý disk. Až je nebudete potřebovat, použijte k
jejich odstranění příkazy podman images
a podman rmi IMAGE_ID
(další
podrobnosti viz níže).
Příprava na cvičení
Před zahájením dalších pokusů s Podmanem se ujistěte, že máte aktuální kopii repozitáře examples.
Budeme používat podadresář 13/
.
/tmp
, protože -v
by nefungovalo se soubory na svazku
souborového systému AFS.
Spuštění prvního kontejneru
První spuštění bude trochu komplexnější, abyste si mohli udělat představu o tom, co je možné. Podrobnosti si vysvětlíme v následujících kapitolách.
Předpokládejme, že se nacházíte v adresáři 13
v repozitáři
examples.
Následující příkaz spustí webový server Nginx.
podman run --rm --publish 8080:80/tcp -v ./web:/usr/share/nginx/html:ro docker.io/library/nginx:1.26
Zobrazí se podobný výstup jako v následujícím případě.
Trying to pull docker.io/library/nginx:1.26...
Getting image source signatures
Copying blob 97573c8fbb99 done |
Copying blob 13808c22b207 done |
Copying blob 1201812f08b3 done |
Copying blob 60f70a034a14 done |
Copying blob 86824adef66e done |
Copying blob 7f96f3100df0 done |
Copying blob 4749f4ee1e34 done |
Copying config e8d7a2a5de done |
Writing manifest to image destination
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: Getting the checksum of /etc/nginx/conf.d/default.conf
10-listen-on-ipv6-by-default.sh: info: Enabled listen on IPv6 in /etc/nginx/conf.d/default.conf
/docker-entrypoint.sh: Sourcing /docker-entrypoint.d/15-local-resolvers.envsh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up
2024/04/24 12:23:15 [notice] 1#1: using the "epoll" event method
2024/04/24 12:23:15 [notice] 1#1: nginx/1.26.0
2024/04/24 12:23:15 [notice] 1#1: built by gcc 12.2.0 (Debian 12.2.0-14)
2024/04/24 12:23:15 [notice] 1#1: OS: Linux 6.6.7-arch1-1
2024/04/24 12:23:15 [notice] 1#1: getrlimit(RLIMIT_NOFILE): 524288:524288
2024/04/24 12:23:15 [notice] 1#1: start worker processes
2024/04/24 12:23:15 [notice] 1#1: start worker process 24
2024/04/24 12:23:15 [notice] 1#1: start worker process 25
2024/04/24 12:23:15 [notice] 1#1: start worker process 26
2024/04/24 12:23:15 [notice] 1#1: start worker process 27
2024/04/24 12:23:15 [notice] 1#1: start worker process 28
2024/04/24 12:23:15 [notice] 1#1: start worker process 29
2024/04/24 12:23:15 [notice] 1#1: start worker process 30
2024/04/24 12:23:15 [notice] 1#1: start worker process 31
Otevřete ve vašem prohlížeči http://localhost:8080/. Měla by se vám v něm zobrazit stránka NSWI177 Test Page.
Pokud se místo toho zobrazí 403 Forbidden, přidejte na konec argumentu
volby -v
znaky ,Z
. Příkaz by tedy obsahoval -v ./web:/usr/share/nginx/html:ro,Z
. To je potřeba (a obecně je to dobrý
postup), pokud pracujete na počítači s povoleným SELinuxem v režimu
vynucování (výchozí instalace Fedory, ale ne na USB discích od nás).
Při spouštění na linux.ms.mff.cuni.cz
je třeba zadat jedinečné
číslo portu (na daném portu může naslouchat pouze jedna aplikace).
Prakticky libovolné číslo je v pořádku, pokud je větší než 1024 a nekoliduje s ničím jiným.
Pokud si pamatujete forwardování portů pomocí SSH (bavili jsme se o něm na minulém cvičení), můžete ho nastavit tak, abyste výsledek viděli ve svém (grafickém) prohlížeči. Pro základní vyzkoušení ale stačí použít pouhý curl
.
Podman ukončete stiskem Ctrl-C
.
Všimněte si, že běžící webový server Nginx vypisoval svůj log – tj. seznam zobrazených stránek – na stdout.
Nyní otevřete v prohlížeči stránku web/index.html
. Opět se zobrazí
NSWI177 Test Page, ale adresa URL bude ukazovat na váš místní souborový
systém (tj. file:///home/.../examples/13/web/index.html
).
Výše uvedený příklad ilustruje tři důležité funkce, které jsou u kontejnerů k dispozici:
- Webový server v kontejneru není třeba konfigurovat ani instalovat v rámci celého systému.
- Kontejner může naslouchat na portech hostitelského systému a předávat síťovou komunikaci dovnitř kontejneru.
- Kontejner může přistupovat k souborům hostitele a používat je.
Všechny tyto funkce jsou velmi dobré pro vývoj, testování i distribuci softwaru.
Stahování a kontrola obrazů
Při spuštění kontejneru je nejprve třeba získat jeho obraz. Ačkoli Podman
umí stáhnout obraz jako součást podpříkazu run
, někdy je užitečné získat
jej v samostatném kroku.
Příkaz podman images
vypíše seznam obrazů, které se nacházejí ve vašem
systému. Výstup může vypadat takto.
REPOSITORY TAG IMAGE ID CREATED SIZE
docker.io/library/alpine latest 9ed4aefc74f6 2 weeks ago 7.34 MB
docker.io/library/nginx 1.20.0 7ab27dbbfbdf 6 days ago 137 MB
docker.io/library/fedora 34 8d788d646766 2 weeks ago 187 MB
...
Sloupec repository odkazuje na on-line repozitář, ze kterého jsme obraz získali. Sloupec tag je v podstatě verze. Sloupec image id je jedinečná identifikace obrazu, obvykle se odvozuje z kryptografického hashe jeho obsahu. Zbývající sloupce jsou samovysvětlující.
Když spustíte podman pull IMAGE:TAG
, Podman stáhne obraz, aniž by spustil
kontejner. Pokud jako značku (TAG) použijete latest
, bude stažena
nejnovější dostupná verze.
Stáhněte docker.io/library/python:3-alpine
a zkontrolujte, zda se poté
objevil v podman images
.
Kratší názvy obrazů
Pokud do souboru /etc/containers/registries.conf.d/unqualified.conf
vložíte následující obsah, nebudete muset před každý název obrazu zadávat
docker.io/
. Říká se tomu unqualified search (nekvalifikované vyhledávání)
a pro každý název obrazu se vyzkouší jako první.
unqualified-search-registries = ["docker.io"]
Různé společnosti mohou mít svá vlastní úložiště. Pokud si přejete v případech, když není uveden plně kvalifikovaný název obrazu, vyzkoušet více různých úložišť , můžete jich zde nastavit několik.
Repozitář obrazů
Pokud vás zajímá, odkud obrazy pocházejí, podívejte se na https://hub.docker.com/. Každý tam může nahrát své obrazy, které pak mohou ostatní používat.
Podobně jako v případě Python package index, i zde
můžete narazit na škodlivé obrazy. Kontejnery alespoň běží izolovaně, takže
šance na špatné chování jsou trochu omezené (ve srovnání s pip install
,
který spouštíte v kontextu běžného uživatele).
Obrazy ze skupiny library
jsou oficiální obrazy schválené samotným
nástrojem Docker, a proto jsou relativně důvěryhodné.
Průběžný příklad
Po stažení obrazu z něj můžeme vytvořit kontejner.
Začneme obrazem Alpine, protože je velmi malý, a tudíž velmi rychlý.
podman run --interactive --tty alpine:latest /bin/sh
Pokud vše proběhlo v pořádku, měli byste vidět interaktivní prompt / #
a
při kontrole /etc/os-release
byste měli vidět následující text (čísla
verzí se mohou lišit):
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.19.1
PRETTY_NAME="Alpine Linux v3.19"
HOME_URL="https://alpinelinux.org/"
BUG_REPORT_URL="https://gitlab.alpinelinux.org/alpine/aports/-/issues"
Podpříkaz run
spustí kontejner ze zadaného obrazu. Pomocí --interactive
a --tty
(které se často spojují do jediného -it
) určíme, že chceme ke
kontejneru připojit terminál, abychom jej mohli používat interaktivně.
Poslední částí příkazu je program, který se má spustit.
Uvnitř kontejneru můžeme provádět libovolné příkazy. Jsme bezpečně uzavřeni a změny neovlivní hostitelský systém.
Nainstalujte curl
a zkontrolujte, zda máte funkční
přístup k síti.
Řešení.
Otevřete druhý terminál, abychom mohli zkontrolovat, jak kontejner vypadá zvenčí.
Uvnitř kontejneru spusťte sleep 111
a v druhém terminálu (který je spuštěn
v hostiteli) spusťte ps -ef --forest
. Zobrazí se následující řádky:
student 1477313 1 0 16:29 ? 00:00:00 /usr/bin/conmon ...
student 1477316 1477313 0 16:29 pts/0 00:00:00 \_ /bin/sh
student 1477370 1477316 0 16:33 pts/0 00:00:00 \_ sleep 111
To potvrzuje, že procesy běžící uvnitř kontejneru jsou viditelné zvenčí.
Spusťte ps -ef
uvnitř kontejneru (nebo se podívejte do /proc
).
Co uvidíte? Je tam něco překvapivého?
Řešení.
Spusťte také podman ps
. Ten vypíše seznam spuštěných kontejnerů.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
643b5e7cea06 docker.io/library/alpine:latest /bin/sh 4 minutes ago Up 4 minutes ago practical_bohr
ID kontejneru je opět jedinečná identifikace, ostatní sloupce jsou samovysvětlující. Všimněte si, že vzhledem k tomu, že jsme nezadali název, Podman kontejneru přiřadil náhodný název.
Pokud relaci ukončíte uvnitř kontejneru (exit
nebo Ctrl-D
), vrátíte se
do hostitelského terminálu.
Znovu spusťte podman ps
. Výstup je prázdný: kontejner neběží. Pokud
přidáte --all
, uvidíte, že se STATUS
změnil.
Exited (130) 1 second ago
Všimněte si, že kdybychom znovu spustili podman run ...
, spustili bychom
nový kontejner. Vyzkoušejte si to nyní.
Životní cyklus kontejneru popíšeme později, pokud chcete kontejner odstranit
nyní, spusťte podman rm NAME
. Jako NAME
použijte náhodně přidělený
název nebo CONTAINER ID
.
Jednorázová spuštění
Příkazu podman run
můžete předat libovolný příkaz, který se má provést.
Pokud víte, že kontejner ihned poté odstraníte, můžete přidat --rm
, abyste
Podmanu řekli, že má kontejner po dokončení příkazu automaticky odstranit.
podman run --rm alpine:latest cat /etc/os-release
Pokud chcete předat složitější příkaz, je lepší použít sh -c
.
Změňte výše uvedený příkaz tak, že nejprve provedeme cd
do etc
a poté zavoláme cat os-release
.
Proč by nefungoval příkaz podman run --rm alpine:latest cd /etc && cat os-release
?
Řešení.
Správa životního cyklu kontejneru
Kontejnery jsou vlastně dost podobné službám, o kterých jsme hovořili ve Cvičení 09.
Spuštění kontejneru
Po ukončení interaktivní relace byl kontejner ukončen. Pro jeho opětovné
spuštění můžeme zavolat podman start CONTAINER
.
Každý kontejner má tzv. vstupní bod, který se spustí při jeho spuštění. U kontejneru typu služba (např. s webovým serverem) by se služba spouštěla znovu.
V našem příkladu s Alpine je vstupním bodem /bin/sh
(shell), takže se nic
zajímavého nestane.
Zkontrolujte, že je kontejner spuštěn, pomocí podman ps
.
Připojení ke spuštěnému kontejneru
Když je kontejner spuštěn, můžeme se k němu připojit. podman attach
v
podstatě připojí stdout vstupního bodu k vašemu terminálu. S naším
kontejnerem Alpine můžeme opět spustit příkaz uvnitř kontejneru.
Můžeme také zavolat podman exec -it CONTAINER CMD
, který se připojí ke
spuštěnému kontejneru v novém terminálu (jako nová karta). V našem případě
bude fungovat spuštění následujícího příkazu (použijte název vašeho
kontejneru).
podman exec -it practical_bohr /bin/sh
Spusťte znovu ps -ef
uvnitř kontejneru.
Které procesy vidíte?
Řešení.
Ukončení exec
nutého shellu nás vrátí zpět k hostiteli. Ukončení
attach
nutého shellu ukončí celý kontejner.
Kontejnery na pozadí (s názvy)
U kontejnerů typu služba (např. nginx
, který poskytuje webový server) je
často chceme spouštět v režimu démona – na pozadí.
To je možné pomocí volby --detach
příkazu run
.
Do příkazu přidáme také jméno webserver
, abychom na kontejner mohli snadno
odkazovat.
podman run --detach --name webserver --publish 8080:80/tcp -v ./web:/usr/share/nginx/html:ro nginx:1.20.0
Volby -v
a --publish
si vysvětlíme později.
Tento příkaz spustí kontejner a skončí. Webový server běží na pozadí. Zkontrolujte, zda máte opět přístup k http://localhost:8080/ v prohlížeči.
Takový kontejner můžete zastavit příkazem podman stop webserver
. Je to
něco podobného jako systemctl stop ...
. Není to náhoda.
Zkontrolujte, že po zastavení webového serveru http://localhost:8080/ již nefunguje.
Opětovné spuštění kontejneru je možné pomocí příkazu podman start webserver
.
start
, stop
a standardní výstup
Všimněte si, že jak start
, tak stop
vypisují na standardní výstup jméno
kontejneru, který byl spuštěn (zastaven). To je užitečné při provádění ve
skriptech; při interaktivním použití můžeme tento výstup jednoduše
ignorovat.
Úklidové akce
Jakmile s kontejnerem skončíme, můžeme jej odstranit (nejprve jej však
musíme zastavit
).
Spuštěním následujícího příkazu by byl kontejner webserver
zcela
odstraněn.
podman rm webserver
Pomocí podpříkazu rmi
můžete také odstranit stažené obrazy.
Například pro odstranění nginx:1.20.0
můžete spustit následující příkaz.
podman rmi nginx:1.20.0
Všimněte si, že Podman odmítne obraz odstranit, pokud jej používá existující kontejner. Připomeňme, že obrazy jsou naskládané na sebe, a proto Podman nemůže odstranit spodní vrstvy.
Omezení izolace
Kontejner je ve výchozím nastavení izolovaný svět. Pokud k němu chcete
přistupovat zvenčí, musíte se do něj exec
nout (pro práci v terminálu) nebo
zveřejnit jeho služby navenek.
Přesměrování portů (tzv. publikování portů)
U kontejnerů serverového typu (např. Nginx, který jsme použili výše) to
znamená vystavení některých portů hostitelskému počítači. To se provádí
pomocí argumentu --publish
, ve kterém určíte, který port na hostiteli
(např. 8080
) má být přesměrován do kontejneru: na který port a který
protokol (např. 80
a tcp
).
Argument --publish 8080:80/tcp
tedy znamená, že očekáváme, že kontejner
sám nabízí službu na svém portu 80
a chceme tento port (kontejneru)
zpřístupnit jako 8080
.
To je velmi podobné jako SSH port forwarding, který jsme si ukazovali na minulém cvičení.
Kontejner nginx
můžeme spustit i bez --publish
, ale to neznamená, že to
má velký smysl. Proč?
Řešení.
Připojování svazků
Další možností, jak narušit izolaci kontejneru, je připojit do kontejneru
určitý adresář. Existuje několik možností, jak to provést. My si ukážeme
parametr --volume
(nebo -v
).
/tmp
.
Parametr -v
přijímá tři argumenty (opět oddělené dvojtečkou): zdrojový
adresář na hostiteli, mapování uvnitř kontejneru a volby (options).
Náš příklad ./web:/usr/share/nginx/html:ro
tedy určuje, že místní
(hostitelský) adresář web
bude viditelný pod /usr/share/nginx/html
uvnitř kontejneru v režimu pouze pro čtení. Je to velmi podobné běžnému
připojování (mountování), které již znáte.
Pokud zadáte rw
místo ro
, můžete uvnitř kontejneru upravovat hostitelské
soubory.
Připojení svazku je užitečné pro jakýkoli kontejner typu služba. Typickým příkladem je databázový server. Spustíte kontejner a přidělíte mu připojený svazek. Do tohoto svazku (adresáře) bude ukládat vlastní databázi (datové soubory). Po ukončení kontejneru jsou tedy vaše data ve skutečnosti trvalá, protože byla uložena mimo kontejner.
To má obrovskou výhodu při testování aktualizací služeb. Zastavíte kontejner, vytvoříte zálohu datového adresáře a spustíte nový kontejner (s novější verzí) nad stejným datovým adresářem. Pokud vše funguje správně, můžete pokračovat. V opačném případě můžete nový kontejner zastavit, obnovit data ze zálohy a vrátit se ke staré verzi.
Velmi jednoduché a účinné.
Zkontrolujte si vaše porozumění
Cvičení
Proč máme všechny ty systemctl
, dnf
, podman
, pip
, …
V tuto chvíli by mohlo dojít k určitým nejasnostem, proč existuje tolik konceptů, které se v podstatě zabývají stejnou problematikou.
- K instalaci softwaru máme správce balíčků (
dnf install
). Některý software však můžeme instalovat také prostřednictvím správců specifických pro daný jazyk (pip install
). - Webový server lze spustit pomocí
systemctl start
nebo vytvořením kontejneru. - Máme virtuální prostředí pro vývoj softwaru, ale také kontejnery a plnohodnotné virtuální stroje.
- …
Pravdou je, že některé koncepty a nástroje jsou důsledkem historického vývoje, zatímco jiné řeší některé problémy z různých úhlů.
Klidně se k tomuto textu vraťte později, např. až trochu vstřebáte téma kontejnerů.
Pokusíme se stručně vysvětlit, proč má smysl je všechny znát. Pokud se vám zdá, že je naše zobecnění příliš široké, připojte prosím ke každé větě přívlastek většinou, obvykle nebo jiné podobné příslovce :-).
Především je důležité rozlišovat potřeby koncového uživatele (což může být i správce webového serveru) od potřeb vývojáře.
-
Koncový uživatel obvykle požaduje snadnou instalaci a spokojí se s jednou verzí. Očekává, že aktualizace bude bezproblémový proces.
-
Vývojáři mohou mít nainstalováno více verzí stejného softwaru a mohou dokonce používat dvě různé verze současně. Aktualizace (např. ve smyslu aktualizace potřebných knihoven) je křehký proces, při kterém je třeba otestovat spoustu věcí.
-
A můžeme k tomu přidat i testery, kteří musí zajistit, aby software fungoval na široké škále hardwarových a softwarových platforem.
Všechny tyto skupiny ve skutečnosti používají stejný software (stejný kus kódu), ale jejich požadavky se liší.
Správci balíčků tak dodávají do uživatelova počítače dobře otestovanou verzi programu, která je připravena ke spuštění. Použití správce balíčků znamená, že existuje centrální autorita, která zabraňuje instalaci konfliktních souborů a zjednodušuje hromadné aktualizace.
Vývojáři nechtějí svůj program instalovat pro celý systém, ale přesto jej chtějí spouštět, jako by byl pro celý systém nainstalován (protože tak bude program nakonec používán). Virtuální prostředí poskytuje čisté prostředí, které je dostatečně dobré pro emulaci čisté instalace do stejného systému, jaký používá vývojář. Je také velmi nenáročné, protože soubory zůstávají ve stejném souborovém systému, a proto je konfigurace ostatních nástrojů – například IDE – jednoduchá.
Tato izolace (na úrovni virtuálního prostředí) je však poměrně slabá,
protože neizoluje od ostatních nainstalovaných aplikací (připomeňme, že
$PATH
se ve virtuálním prostředí rozšiřuje, nikoli nahrazuje), ani od
síťové konfigurace. Kontejnery poskytují vyšší úroveň izolace, ale za vyšší
cenu. Přístup k souborům je možný, ale vyžaduje další nastavení, kontejner
obvykle neobsahuje žádný další software, který by zjednodušil rutinní úlohy,
atd.
Na druhou stranu kontejner poskytuje čistší prostředí pro testování, protože uživatel může mít plnou kontrolu nad tím, co se instaluje.
Kontejnery i virtuální prostředí mohou spokojeně koexistovat, a to i ve více kopiích, což opět zjednodušuje testování a vývoj.
Uvedené nástroje plní ve vývojovém cyklu softwaru různé role. Teoreticky můžeme kontejnery použít prakticky na všechno, protože jejich izolace (alespoň částečně) ruší potřebu správců balíčků i virtuálních prostředí, ale hlavní roli zde hraje snadnost použití.
Vždy zvolte pro danou práci správný nástroj. Potřeby správců, uživatelů, vývojářů a testerů se liší. A právě proto existuje tolik nástrojů, které zdánlivě řeší stejnou úlohu. Všechny mají své využití.
Tisk a skenování v Linuxu
Níže je stručný přehled o tisku a skenování na Linuxu. Dnes je většina zařízení připojena po síti a po připojení budou rovnou fungovat (nebo alespoň jejich základní funkce).
Zvláštní balíčky (ty budete možná muset stáhnout přímo od výrobce) jsou potřeba jenom pro extra vychytávky.
Tisk pomocí CUPSu
Tisk v Linuxu zajišťuje subsystém CUPS, který standardně spolupracuje prakticky s každou tiskárnou podporující IPP (internetový tiskový protokol) a podporuje také mnoho starších tiskáren.
Jednoduché sudo dnf install cups
nainstaluje základní subsystém, pro
konkrétní modely mohou být potřeba další ovladače.
OpenPrinting.org obsahuje databázi,
ve které lze vyhledávat, které ovladače jsou potřeba (pokud vůbec nějaké
jsou). Například pro většinu tiskáren HP je třeba nainstalovat balíček
hplip
.
Obvykle chcete mít CUPS v systému neustále spuštěný, a proto jej musíte povolit:
sudo systemctl enable --now cups
CUPS má pěkné webové rozhraní, které můžete použít ke konfiguraci tiskáren. U mnoha moderních tiskáren připojených k síti je to často zbytečné, protože budou správně automaticky objeveny.
Pokud jste již CUPS spustili, zkuste navštívit http://localhost:631/. Na kartě Administration můžete přidat nové tiskárny. Výběr správného modelu pomůže systému CUPS rozhodnout, které možnosti zobrazit v dialogovém okně tisku, a umožní správnou funkci tisku ve stupních šedi a podobné funkce.
Skenování obrázků a dokumentů pomocí Sane
Podpora skenerů v systému Linux je řešena pomocí SANE (Scanner Access Now Easy). Stejně jako u tisku bude většina skenerů automaticky detekována. GIMP, který možná již znáte, má podporu SANE.
Přidejte jej pomocí sudo dnf install xsane-gimp
.
Vlastní skenování obrázku lze provést v dialogovém okně File -> Create -> XSane, kde vyberete zařízení, vlastnosti skenování (např. rozlišení nebo barvy) a poté můžete spustit skenování.
Úlohy k ověření vašich znalostí
Očekáváme, že následující úlohy vyřešíte ještě před příchodem na cvičení, takže se budeme moci o vašich řešeních na cvičení pobavit.
Učební výstupy
Učební výstupy podávají zhuštěný souhrn základních konceptů a dovedností, které byste měli umět vysvětlit a/nebo použít po každém cvičení. Také obsahují absolutní minimum, které je potřebné pro pochopení navazujících cvičení (a dalších předmětů).
Znalosti konceptů
Znalost konceptů znamená, že rozumíte významu a kontextu daného tématu a jste schopni témata zasadit do většího rámce. Takže, jste schopni …
-
vysvětlit, co je to kontejner
-
porovnat kontejner s virtuálním strojem a procesem
-
vysvětlit, kde se hodí izolace, kterou nabízí kontejnery
-
vysvětlit životní cyklus kontejneru
-
vysvětlit, proč použití virtuálních prostředí (nebo jiných typů sandboxů) není uvnitř kontejneru obvykle potřeba
-
vysvětlit rozdíl mezi běžícím kontejnerem a obrazem kontejneru
Praktické dovednosti
Praktické dovednosti se obvykle týkají použití daných programů pro vyřešení různých úloh. Takže, dokážete …
-
spustit v Podmanu interaktivní kontejner
-
spustit kontejner Podmanu se službou
-
zpřístupnit (expose) porty kontejneru
-
připojit svazek dovnitř kontejneru
-
vymazat nepoužívané kontejnery a obrazy
-
volitelné: tisknout a skenovat v Linuxu