Какво са контейнерите

Модул 9: Docker и docker compose · Време за четене: 10 минути

Цел на урока: След този урок ще можете да обясните какво е контейнер, с какво се различава от виртуална машина, къде остават данните на един контейнер и кога Docker има смисъл на Вашия сървър.

Основни понятия: image, контейнер, слой, registry (Docker Hub), tag, digest, namespaces, cgroups, споделено ядро, нетрайна файлова система, volume, bind mount, публикуване на порт, официален image

Защо контейнери?

Да предположим, че искате на Вашия VPS да работи страница за състоянието, която показва дали сайтът Ви работи. Програмата е написана на Node.js, изисква определена негова версия и около двеста библиотеки. Без контейнери инсталирате всичко това на сървъра си, редом с уеб сървъра и базата данни. Година по-късно искате втора програма, която изисква друга версия на Node.js. Тогава започва главоблъсканицата.

Контейнерът решава този проблем. Създателят на програмата я предоставя заедно с всичко, от което тя се нуждае, в един пакет: image. На сървъра си стартирате този image като контейнер. Програмата вижда своите собствени файлове, своя собствен Node.js, своите собствени библиотеки и не влиза в конфликт с останалата част от сървъра Ви. Искате да я премахнете? Изтривате контейнера и image и в /usr или /etc не остава нищо.

Docker е най-известният инструмент за изтегляне на images и стартиране на контейнери. Има и алтернативи (Podman, самият containerd), но понятията навсякъде са едни и същи.

Image, контейнер и registry

Три думи, които ще срещате постоянно:

• Image: шаблон само за четене с файлова система (програма, библиотеки, настройки) и командата, която трябва да се стартира. Един image е изграден от слоеве: базов слой (например минимален Debian), върху него слой с Node.js, а върху него програмата. Два images с един и същ базов слой споделят този слой на диска Ви.
• Контейнер: работещ (или спрян) екземпляр на image. Върху слоевете само за четене контейнерът получава собствен тънък слой за запис. От един image можете да стартирате десет контейнера.
• Registry: мястото, където се съхраняват images, например Docker Hub (docker.io) или registry на GitHub (ghcr.io). Docker изтегля image с docker pull.

Името на един image изглежда така:

louislam/uptime-kuma:2
caddy:2
vaultwarden/server:latest

Частта след двоеточието е tag: етикет за версия. Един tag може да се променя: caddy:2 днес сочи към друг build, отколкото след три месеца, щом излезе нова 2.x. Ако искате да фиксирате точно кой image използвате, използвайте digest: пръстов отпечатък на съдържанието, например caddy@sha256:.... Той никога не се променя. Tag latest е просто име, което създателят избира; той не означава автоматично "най-новата стабилна версия" и затова е лош избор, ако искате да знаете какво точно работи.

Не е виртуална машина

Контейнерът прилича на малка виртуална машина, но не е такава. Тази разлика е важна за сигурността.

Всъщност контейнерът е обикновен процес на Вашия сървър, който ядрото поставя в изолирана среда:

• namespaces осигуряват на процеса собствен изглед към файловете, процесите, мрежата и потребителите. В контейнера програмата изглежда като процес номер 1 и не вижда останалата част от сървъра Ви;
• cgroups ограничават колко процесорно време и памет може да използва.

Тъй като всички контейнери споделят едно и също ядро, изолацията е по-слаба, отколкото между два VPS. Уязвимост в ядрото или контейнер с твърде много права може да засегне хоста. Затова важат правилата от този модул: стартирайте само images, на които имате доверие, не давайте на контейнерите повече права от необходимото и никога не монтирайте /var/run/docker.sock или / в контейнер (урок 9.3 и 10.2).

Къде остават Вашите данни?

Това е класическият капан за начинаещи. Слоят за запис на контейнера е нетраен: ако изтриете контейнера (например при актуализация, урок 9.4), всичко, което програмата е записала в него, изчезва. Затова данните, които трябва да се запазят, трябва да са извън контейнера:

• Volume: място за съхранение, което Docker управлява сам (в /var/lib/docker/volumes/). Давате му име, например uptime-kuma, и го свързвате с папка в контейнера: -v uptime-kuma:/app/data.
• Bind mount: обикновена папка на Вашия сървър, която закачате в контейнера: -v /srv/vaultwarden:/data. Удобно е, защото виждате файловете директно и лесно ги включвате в резервното си копие (модул 8).

Контейнер с добре настроени volumes можете да изтриете и да създадете отново, без да загубите нищо. Точно така работи актуализирането: изтегляте нов image, премахвате стария контейнер и създавате нов контейнер върху същите volumes. Затова включете volumes в плана си за резервни копия (урок 8.1).

Публикуване на портове

Контейнерът има собствена мрежа. Уеб програма, която в контейнера слуша на порт 3001, не е достъпна извън сървъра, докато не публикувате този порт: -p 3001:3001 (порт на хоста:порт на контейнера). Внимание: без адрес Docker публикува порта на всички адреси на сървъра Ви, т.е. 0.0.0.0 и [::]. Това означава: достъпен от целия интернет, като Docker урежда това в обход на ufw (урок 9.3). Безопасният навик е да публикувате на loopback, -p 127.0.0.1:3001:3001, и да поставите пред него reverse proxy с https (урок 9.4).

Кой създава image?

Един image е софтуер от някой друг, който може да работи като root на Вашия сървър. Затова проверете кой е създателят:

• Docker Official Images (например caddy, nginx, postgres) се поддържат от Docker съвместно със създателите;
• images от самия създател (например louislam/uptime-kuma и vaultwarden/server), разпознаваеми по името, посочено на уебсайта на проекта;
• images от непознати с имена, които приличат на оригиналните: не ги използвайте.

Винаги използвайте името, посочено на официалния уебсайт на проекта, а не първото, което излезе при търсене.

Кога да, кога не?

Docker е удобен за програми, които създателят предоставя като image, за услуги, които искате бързо да можете да премахнете или преместите, и за паралелно стартиране на няколко програми с различни изисквания. За основата на сървъра си (SSH, защитна стена, актуализации) не използвате контейнери. А един отделен уебсайт с nginx и PHP от хранилището с пакети (урок 7.2) работи отлично и без Docker. Контейнерът добавя слой, който трябва да разбирате и да поддържате актуален; използвайте го, когато Ви носи полза.

Обобщение

• Image е шаблон само за четене, изграден от слоеве; контейнерът е работещ екземпляр със собствен слой за запис.
• Контейнерите споделят ядрото на хоста и са изолирани с namespaces и cgroups: по-леки от VM, но с по-слаба изолация.
• Слоят за запис е нетраен: трайните данни трябва да са във volume или bind mount, а те трябва да са в резервното Ви копие.
• Един tag може да се промени, а digest не; latest казва малко.
• Публикувайте портове на 127.0.0.1 и използвайте само images от създателя или официални images.

Тест (quiz)

Задача

Задача O9.1: Контейнер или не? Изберете две програми, които искате да стартирате на сървъра си (или използвайте за пример Uptime Kuma и сайт с WordPress). За всяка програма проверете дали създателят предоставя официален image и под какво име, кой tag бихте избрали, коя папка съдържа трайните данни и на кой порт слуша програмата. След това обяснете дали бихте я стартирали в контейнер или от хранилището с пакети и защо.

Още за четене

• Документация на Docker, What is a container?: https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/
• Документация на Docker, Volumes: https://docs.docker.com/engine/storage/volumes/
• Документация на Docker, Port publishing and mapping: https://docs.docker.com/engine/network/port-publishing/
• Docker Official Images: https://docs.docker.com/docker-hub/repos/manage/trusted-content/official-images/