Docker — одна из самых используемых контейнерных платформ. Этот инструмент управляет всеми процессами контейнеризации: сборкой, запуском и проверкой образов контейнеров.
В августе 2021 года Docker Desktop анонсировал изменения в лицензии. Он больше не будет бесплатным для компаний, имеющих больше 250 сотрудников и больше 10 млн. долларов дохода.
Но контейнеризация возможна не только при помощи Docker. Есть альтернативные варианты, часто в форме отдельных инструментов. Порой они обеспечивают даже лучший результат, чем Docker.
В этой статье мы рассмотрим несколько альтернатив Docker, которые могут послужить заменой разных аспектов его экосистемы. Каждый из этих инструментов соответствует спецификации Open Containers Initiative (OCI).
1. Podman
Podman — движок контейнеров, разработанный RedHat. Это одна из самых ярких альтернатив Docker для сборки, запуска и хранения образов контейнеров. Podman, как и Docker, придерживается OCI-спецификации для образа контейнера. Это означает, что Podman может запускать образы, созданные Docker, и наоборот.
Интерфейс командной строки Podman аналогичен Docker CLI, включая аргументы. Вы даже можете создать псевдоним docker=podman, и вообще не заметите разницы в работе. Это очень облегчит переход на Podman тем разработчикам, которые уже привыкли работать с Docker.
# .bashrc alias docker=podman
В отличие от Docker, который использует демон dockerd для управления всеми контейнерами, Podman демоны не использует. Таким образом, в нем нет постоянного соединения с некоторыми долгоживущими процессами. Это устраняет проблему единой точки отказа в Docker, где внезапное нарушение процесса демона может убить запущенные контейнеры или оставить их процессы сиротами.
Podman взаимодействует с реестром и хранилищем образов, а также ядром Linux, поскольку его контейнеры не зависят от какого-либо центрального процесса. Вместо этого контейнеры запускаются как потомки процесса Podman, для чего интенсивно используется пространство имен пользователя и сети.
Podman также отличается от Docker тем, что по умолчанию использует rootless контейнеры. Для запуска и работы контейнера доступ с правами root не требуется, но он помогает уменьшить потенциальные уязвимости в среде выполнения контейнера.
Обратите внимание, что Docker теперь тоже поддерживает rootless-режим. Эта экспериментальная фича появилась в Docker Engine v19.03, а затем закрепилась в v20.10. Тем не менее, в экосистеме ею пока не часто пользуются.
Дополнительная фича Podman, которой пока нет в Docker, — возможность создавать и запускать поды. Под (pod) — это коллекция из одного или нескольких контейнеров, использующих общий пул ресурсов и работающих в тесной связке для достижения определенной функции. Поды также являются самыми маленькими юнитами выполнения в Kubernetes, что упрощает переход на Kubernetes в случае необходимости.
2. Buildah
Buildah — альтернатива Docker по части создания образов. Тоже разработка RedHat.
Этот инструмент часто используется в связке с Podman. Фактически, Podman использует поднабор функционала Buildah для реализации своей подкоманды build.
Если вам нужен тонкий контроль над образами, вам стоит использовать Buildah CLI целиком. На время написания этой статьи он работает в нескольких дистрибутивах Linux, но не поддерживается в Windows или macOS.
Образы, создаваемые Buildah, полностью соответствуют OCI-спецификации. Они работают так же, как образы, созданные Docker. Buildah также может создавать образы, используя существующий Dockerfile или Containerfile, что облегчает миграцию. Еще Buildah позволяет применять Bash-скрипты для обхода ограничений Dockerfiles и более простой автоматизации этого процесса.
Как и Podman, Buildah придерживается fork-exec модели, для работы которой не требуется центральный демон или root-доступ.
Одно из преимуществ Buildah перед Docker — возможность коммитить много изменений на один слой. Эта фича очень затребована у пользователей контейнеров. Buildah также позволяет создавать пустой образ контейнера, хранящий только метаданные. Благодаря этому можно легко добавлять только необходимые для образа пакеты. Соответственно, итоговый результат меньше, чем его эквивалент в Docker.
Что еще отличает Buildah — его образы специфичны для пользователей. Каждый отдельный пользователь видит только образы, которые сам создал.
3. Buildkit
Buildkit — новый движок создания образов для Docker, разработанный как часть проекта Moby. Начиная с Docker ≥v18.09, Buildkit интегрирован в docker build, но он также поставляется и как отдельный инструмент.
Одна из главных особенностей Buildkit — улучшенная производительность. Она связана с параллельной обработкой слоев образа, не зависящих друг от друга. Еще одна особенность — лучшее кеширование. Благодаря ему уменьшается необходимость пересоздавать каждый слой образа. Наконец, Buildkit предлагает расширяемость: его архитектура позволяет использовать плагины. Buildkit также допускает rootless-сборки и возможность пропускать неиспользуемые стейджи.
Чтобы включить Buildkit перед созданием образа, нужно использовать переменную среды DOCKER_BUILDKIT в вашей оболочке:
$ DOCKER_BUILDKIT=1 docker build .
Вы также можете настроить Docker, чтобы использовать Buildkit по умолчанию. Просто отредактируйте или создайте файл /etc/docker/daemon.json. В нем должно быть следующее:
{
"features": {
"buildkit": true
}
}
После сохранения файла перезапустите демон, чтобы применить изменения:
$ systemctl reload docker
Понять, что Buildkit используется, легко по его выводу, который отличается от дефолтного:
$ DOCKER_BUILDKIT=1 docker build . [+] Building 30.8s (7/7) FINISHED => [internal] load build definition from Dockerfile 0.1s => => transferring dockerfile: 142B 0.1s => [internal] load .dockerignore 0.0s => => transferring context: 2B 0.0s => [internal] load metadata for docker.io/library/centos:latest 0.6s => [auth] library/centos:pull token for registry-1.docker.io 0.0s => [1/2] FROM docker.io/library/centos:latest@sha256:a27fd8080b517143cbbbab9dfb7c8571c40d67d534bbdee55bd6 14.3s => => resolve docker.io/library/centos:latest@sha256:a27fd8080b517143cbbbab9dfb7c8571c40d67d534bbdee55bd6c 0.0s => => sha256:a27fd8080b517143cbbbab9dfb7c8571c40d67d534bbdee55bd6c473f432b177 762B / 762B 0.0s => => sha256:a1801b843b1bfaf77c501e7a6d3f709401a1e0c83863037fa3aab063a7fdb9dc 529B / 529B 0.0s => => sha256:5d0da3dc976460b72c77d94c8a1ad043720b0416bfc16c52c45d4847e53fadb6 2.14kB / 2.14kB 0.0s => => sha256:a1d0c75327776413fa0db9ed3adcdbadedc95a662eb1d360dad82bb913f8a1d1 83.52MB / 83.52MB 2.0s => => extracting sha256:a1d0c75327776413fa0db9ed3adcdbadedc95a662eb1d360dad82bb913f8a1d1 10.8s => [2/2] RUN yum -y install httpd 14.7s => exporting to image 1.0s => => exporting layers 1.0s => => writing image sha256:c18170a407ca85218ee83526075a3f2a2e74f27d7bd5908ad68ba2328b4f4783 0.0s
4. Kaniko
Kaniko — разработка Google. Этот инструмент используется для создания образов внутри контейнера или кластера Kubernetes. Аналогично Buildah, Kaniko не нужен демон. Он может создавать образы из Dockerfiles и при этом не зависит от Docker.
Основное различие между Docker и Kaniko состоит в том, что Kaniko больше фокусируется на Kubernetes workflows. Он запускается как образ, в связи с чем неудобен для локальной разработки.
5. Skopeo
Еще один инструмент, созданный RedHat для различных операций с образами и репозиториями образов. Skopeo может использоваться вместе с Podman и Buildah.
В Skopeo есть подкоманда inspect (аналог docker inspect), предоставляющая низкоуровневую информацию об образе контейнера.
В отличие от Docker, Skopeo может помочь вам собрать полезные сведения о репозитории или теге без первоначальной их загрузки:
$ skopeo inspect docker://docker.io/fedora # inspect remote image
{
"Name": "docker.io/library/fedora",
"Digest": "sha256:72c6c48a902baff1ab9948558556ef59e3429c65697287791be3c709738955b3",
"RepoTags": [
"20",
"21",
"22",
"23",
"24",
"25",
"26",
"26-modular",
"27",
"28",
"29",
"30",
"31",
"32",
"33",
"34",
"35",
"36",
"branched",
"heisenbug",
"latest",
"modular",
"rawhide"
],
"Created": "2021-11-02T21:29:22.547065293Z",
"DockerVersion": "20.10.7",
"Labels": {
"maintainer": "Clement Verna \u003ccverna@fedoraproject.org\u003e"
},
"Architecture": "amd64",
"Os": "linux",
"Layers": [
"sha256:fc811dadee2400b171b0e1eed1d973c4aa9459c6f81c77ce11c014a6104ae005"
],
"Env": [
"PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin",
"DISTTAG=f35container",
"FGC=f35",
"FBR=f35"
]
}
При помощи команды skopeo copy можно скопировать образ из одного удаленного реестра в другой или в локальную директорию. Есть еще одна связанная с этой функция: Skopeo может синхронизировать образы между реестрами контейнеров и локальными директориями при помощи команды skopeo sync.
6. Dive
Dive — инструмент для просмотра, анализа и оптимизации образов контейнеров. Он может показывать содержимое контейнера послойно, подсвечивая отличия каждого.
Dive также может проанализировать ваш образ, предоставив вам сведения об эффективности (в процентах). Это пригодится, если вы захотите уменьшить размер образа.
Еще одна полезная фича Dive — CI-интеграция. Она дает результат pass или fail в зависимости от эффективности образа и количества занятого пространства. Для доступа к функции CI-интеграции установите значение true для переменной окружения CI при вызове любой валидной команды dive:
$ CI=true dive node:alpine
7. runc и crun
runc — CLI-инструмент, который порождает и запускает контейнеры в Linux (в соответствии с OCI-спецификацией). Раньше этот инструмент был встроен в Docker в качестве модуля, но позже, в 2015 году, выделен в отдельный инструмент.
runc остается средой выполнения контейнера по умолчанию в Docker, Podman и большинстве других движков контейнеров. Альтернатива runc — crun, разработанный RedHat и написанный не на GO, а на C, как большинство инструментов контейнеризации в Linux.
crun обеспечивает лучшую производительность и меньшее использование памяти по сравнению с runc. Также он дает возможность установить более строгие лимиты на разрешенную память в контейнере.
crun тоже придерживается спецификации OCI, и его функционал совместим с runc. Поэтому вы можете использовать его в качестве замены runc в Docker, Podman, containerd и прочих движках контейнеров, где используются OCI-совместимые среды запуска контейнеров. Более детальное сравнение с runc можно почитать во вводной статье по crun.
Итоги
В этой статье мы рассмотрели альтернативы Docker для создания, запуска и распространения образов контейнеров. Хотя Docker остается доминирующей платформой для контейнеризации и управления контейнерами, не будет лишним знать и о других аналогичных инструментах. Тем более, что в некоторых случаях использования они могут работать даже лучше.
Все упомянутые в этой статье инструменты соответствуют OCI-спецификации, так что переход на них должен пройти без заминок.
Перевод статьи «Top Docker alternatives for 2022».
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
