Чем можно заменить docker
8 бесплатных альтернатив Docker на 2022 год
Редактор новостей Highload
Примечание: каждый инструмент, рассматриваемый ниже, придерживается спецификации Open Containers Initiative (OCI).
1. Podman
Контейнерный движок с открытым исходным кодом, разработанный компанией Red Hat. Одна из наиболее известных альтернатив Docker для создания, запуска и хранения образов контейнеров. Podman, как и Docker, поддерживает совместимость со спецификацией образа контейнера OCI, то есть может запускать образы контейнеров, созданные Docker, и наоборот.
В отличие от Docker, который использует докер-демон для управления всеми контейнерами, находящимися под его контролем, Podman не имеет демона. Поэтому нет постоянного соединения с каким-то долгоживущим процессом, что устраняет проблему единой точки отказа в Docker, когда внезапный сбой в процессе демона может «убить» запущенные контейнеры.
Podman взаимодействует с реестром образов, хранилищем и ядром Linux, а его контейнеры не зависят от какого-либо центрального процесса. Вместо этого контейнеры запускаются как дочерние процессы процесса Podman, в значительной степени используя пространства имен пользователей и сетевые пространства имен.
Podman также отличается от Docker тем, что по умолчанию использует контейнеры без рута. Root-доступ не требуется для запуска и работы контейнера, но он помогает смягчить потенциальные уязвимости в среде выполнения контейнера, которые могут привести к повышению привилегий.
Еще одна функция Podman, которой еще нет в Docker, — это возможность создавать и запускать так называемые поды (pods) — группы контейнеров, развернутые совместно. Поды также — наименьшая единица выполнения в Kubernetes, что, при необходимости, облегчает переход на Kubernetes.
2. Buildah
Если нужен точечный контроль над образами, можно использовать инструмент Buildah CLI. На момент написания статьи Buildah работает на нескольких дистрибутивах Linux, но не поддерживается на Windows или macOS.
Образы, которые создает Buildah, полностью соответствуют спецификации OCI и работают так же, как образы, созданные с помощью Docker. Buildah также может создавать образы с помощью существующий Dockerfile или Containerfil e, что значительно упрощает миграцию. Buildah позволяет использовать Bash-скрипты, которые обходят ограничения Dockerfiles, упрощая автоматизацию процесса.
Одно из преимуществ использования Buildah перед Docker — возможность фиксировать множество изменений на одном уровне. Это востребованная функция среди пользователей контейнеров. С помощью Buildah также можно создать пустой образ контейнера, хранящего только метаданные. Это позволяет добавлять в образ только необходимые пакеты. Конечный результат получается меньше, чем его эквивалент в Docker.
Еще одно отличие заключается в том, что изображения Buildah зависят от пользователя, поэтому ему будут видны только те изображения, которые построены им самим.
3. Buildkit
Чтобы включить Buildkit перед сборкой образа, нужно использовать переменную окружения DOCKER_BUILDKIT :
При желании можно настроить Docker для использования Buildkit по умолчанию. Для этого нужно отредактировать файл /etc/docker/daemon.json следующим образом:
После сохранения файла перезагрузите демон, чтобы изменения вступили в силу:
4. Kaniko
Инструмент для разработки образов контейнеров внутри контейнера или кластера Kubernetes от Google. Как и Buildah, Kaniko не требует демона и может создавать образы из Docker-файлов, не зависят от Docker.
Основное различие между Docker и Kaniko в том, что Kaniko больше ориентирован на рабочие процессы Kubernetes, и предназначен для запуска в виде образа, что делает его неудобным для локальной разработки.
5. Skopeo
Еще один инструмент от Red Hat для выполнения операций с образами контейнеров и репозиториями образов. Может использоваться как вспомогательный инструмент для Podman и Buildah, которые предназначены для проверки образов, переноса их из одного реестра в другой и массового удаления.
В отличие от Docker, Skopeo может собирать полезную информацию о хранилище или теге без предварительной загрузки:
6. Dive
Инструмент для проверки, анализа и оптимизации образов контейнеров. Может показать содержимое образа по слоям, выделяя различия между каждым из них. Инструмент способен анализировать изображение, предоставляя процентную оценку эффективности, оценивая потерянное пространство, что полезно при попытке уменьшить размер изображения.
Еще одна полезная функция — CI-интеграция, которая выдает результат pass или fail, основываясь на эффективности изображения и количестве потраченного впустую пространства. Чтобы получить доступ к CI-интеграции, при вызове любой dive-команды установите значение переменной окружения CI в true :
7. runc
runc — это CLI-инструмент, который создает и запускает контейнеры на Linux в соответствии со OCI-спецификацией. runc ранее был встроен в Docker в качестве модуля, но в 2015 году стал отдельным инструментом.
runc остается контейнерной средой выполнения по умолчанию в Docker, Podman и большинстве других контейнерных движков.
8. crun
Альтернатива runc, которая разработана компанией RedHat и написана на языке C, а не на Go, как большинство контейнерных инструментов Linux.
Инструмент может похвастаться более высокой производительностью и меньшим использованием памяти по сравнению с runc, а также возможностью устанавливать более строгие ограничения на память, допустимую в контейнере. crun также совместим с OCI и функционально совместим с runc, поэтому можно использовать его в качестве замены runc в Docker, Podman, containerd и любом другом контейнерном движке, который использует OCI-совместимые контейнерные среды выполнения.
9 лучших альтернатив Docker для управления контейнерами
9 лучших альтернатив Docker для управления контейнерами. Podman, ZeroVM, OpenVZ, Rancher, Containerd, VirtualBox, RunC, Buildah, Kubernetes
9 лучших альтернатив Docker для управления контейнерами. Podman, ZeroVM, OpenVZ, Rancher, Containerd, VirtualBox, RunC, Buildah, Kubernetes
Что такое Docker Volume? Примеры, свойства
Docker — не единственное программное обеспечение для управления контейнерами на рынке. Ознакомьтесь с этими альтернативами Docker для использования в своем следующем проекте.
Контейнеры очень полезны для разработки, развертывания и управления программным обеспечением в виртуальной среде. Docker полезен в процессе контейнеризации, но это не единственная платформа. Если вы ищете альтернативу Docker, не ищите дальше. В этом списке представлены некоторые многофункциональные и эффективные альтернативы Docker для использования в вашем следующем проекте.
1. Podman
Podman — это контейнерный движок с открытым исходным кодом. Этот родной для Linux движок лучше всего подходит для разработки, запуска и управления контейнерами и образами контейнеров Linux OCI. Вы можете использовать это для управления и использования контейнеров из простого интерфейса.
Несмотря на наличие интерфейса командной строки, такого как Docker, он не имеет демона, что означает, что его функциональность не зависит от демона. Вместо этого он использует процесс времени выполнения для непосредственного взаимодействия с ядром Linux и реестром.
Подману не нужен root-доступ. Следовательно, он ограничивает потенциально опасные процессы дополнительным буфером безопасности. Без демонов движок стал более гибким, поскольку использование одного процесса может привести к сбою дочерних процессов.
2. ZeroVM
ZeroVM — это виртуальная среда с открытым исходным кодом, основанная на собственном клиенте Chromium от Google. Эта изолированная платформа для встраивания приложений очень безопасна. Поскольку он не виртуализирует полную ОС, запуск занимает меньше времени, а также экономит вычислительную мощность.
Вы также можете развернуть его в различных средах для процессов приложений. Эта система не моделирует всю среду, как обычная виртуальная машина. Вместо этого он способствует более быстрому развертыванию, виртуализируя только пространство для запуска приложения. Кроме того, он предлагает защиту для непроверенного кода. Он также обладает уникальной способностью изолировать каждый процесс без ядра или ОС.
3. OpenVZ
OpenVZ — это технология контейнеризации, основанная на Linux. Хотя он имеет функции и функции, аналогичные Docker, его набор инструментов позволяет ему выполнять задачи, выходящие за рамки развертывания приложений.
Это гипервизор, на котором размещены виртуальные серверы с такими функциями, как распределенное облачное хранилище, инструменты управления и выделенная поддержка. Вы можете независимо получать доступ и разрабатывать приложения в сети с помощью OpenVZ.
На одном сервере вы можете создать несколько изолированных контейнеров Linux. Поскольку каждый контейнер имеет независимый корневой доступ, нет риска возникновения конфликта приложений при одновременном запуске нескольких приложений на платформе.
Сетевая файловая система OpenVZ (NFS) позволяет получить доступ к файлам сетевого диска виртуальных серверов, размещенных в OpenVZ. Если вы системный администратор, вы можете совместно использовать виртуальные серверы между несколькими физическими серверами с помощью NFS.
4. Rancher
Rancher — это программное обеспечение для оркестровки, которое помогает администрировать кластеры контейнеров с минимальными усилиями. Это особенно полезно для крупномасштабной разработки приложений в широкой сети или в нескольких командах.
В зависимости от настроек и конфигураций администратора он может автоматизировать весь процесс управления кластером. Таким образом, администраторы могут легко управлять сложной средой, состоящей из нескольких кластеров. Они также могут сделать процесс безошибочным, удалив пользователя сразу из всех групп кластера.
После организации кластера вы можете предлагать разрешения и привилегии каждому пользователю, чтобы они могли без проблем использовать указанную среду.
5. Containerd
Containerd — это автономное приложение среды выполнения контейнера, ориентированное на простоту и переносимость. Эта популярная и независимая альтернатива Docker также является удобным инструментом оркестратора, который не управляет построением образов или созданием томов.
Будучи контейнером низкого уровня, он предлагает отличную производительность в качестве платформы начального уровня для разработки. Он оснащен интерфейсом между движками контейнеров и операционными системами.
Платформа предлагает абстракцию, позволяющую избежать сложностей, с которыми вы могли столкнуться при создании различных низкоуровневых системных вызовов. Он также имеет такие функции, как управление созданием контейнеров, управление снимками, функции push и pull и т. Д.
6. VirtualBox
Он также имеет возможность переносить данные из одной ОС в другую с помощью облачного хранилища. При этом виртуальные машины используют ядро ОС, отличное от ядра хоста, для обеспечения безопасности пользователя.
Это приложение также может запускать приложения на основе графики, обмениваться файлами и папками и предлагать кроссплатформенную поддержку — и все это без какой-либо аппаратной виртуализации. Вы также можете использовать его для хранения и резервного копирования файлов в облачное хранилище.
7. RunC
RunC — это стандартизированная, совместимая среда выполнения контейнеров, которая раньше была компонентом Docker. Этот автономный модульный инструмент может в значительной степени улучшить переносимость контейнеров. Это также помогает плавно перемещать процессы разработки во время обновления оборудования.
Вы можете использовать этот компонент нижнего уровня контейнерного движка с Docker или без него. Это надежный инструмент для быстрого тестирования и разработки в изолированных средах.
8. Buildah
Buildah — это конструктор образов OCI, который можно использовать в качестве системы контейнеризации. Он создает образы, совместимые с OCI, из файла Dockerfile или файла-контейнера.
Более того, он предлагает вам детальный контроль над изображениями и создаваемыми слоями. Следовательно, вы можете внести несколько изменений, которые будут преобразованы в один слой одновременно. Используя эту платформу, вы можете пользоваться аналогичными преимуществами работы с образом в Docker. Он также может создавать пустые изображения, которые вы можете настроить с нуля.
9. Kubernetes (K8)
Kubernetes, также известный как K8, — популярная система автоматизации контейнеров с открытым исходным кодом. Google разработал эту платформу для управления приложениями в физических, виртуальных или облачных средах. Независимо от хостинговых платформ, он позволяет вам контролировать тысячи контейнерных приложений и рабочих нагрузок.
Эта экосистема также работает как API, который может выполнять такие задачи, как координация, управление и автоматизация нескольких контейнеров из одной системы. Его встроенный механизм изоляции позволяет группировать контейнеры в соответствии с привилегиями root.
С его помощью вы также можете управлять несколькими узлами или кластерами и автоматически перепланировать неактивные узлы. Это также позволяет повысить уровень безопасности, сети и балансировки нагрузки на всех узлах. Эта альтернатива Docker упрощает совместную работу над проектами, поскольку позволяет избежать сложности обработки нескольких ресурсов контейнера.
Выберите подходящий контейнер
Хотя Docker — широко используемая платформа для контейнеризации и управления контейнерами, его конкуренты не отстают. Просматривая исчерпывающий список альтернатив Docker, вы наверняка найдете платформу, которая соответствует вашим требованиям. При выборе подходящего контейнера вы также можете узнать, какая среда разработки веб-приложений лучше всего подходит для вас.
Red Hat заменяет Docker на Podman
Понятно, что в настоящий момент страсти вокруг Red Hat имеют совсем другой и весьма глобальный фокус, но мы всё же о своём — локальном и прикладном из мира контейнеров. С начала этого года в Red Hat активно трудятся над заменой для Docker под названием Podman (или libpod). Об этом проекте ещё почему-то не писали на хабре, а ведь сейчас весьма подходящее время для того, чтобы познакомиться с ним, узнать о его истоках и подумать о перспективах. Поехали!
CRI-O как предыстория
Если окинуть взглядом современный мир Linux-контейнеров, то легко увидеть, что тема сегодняшней статьи является лишь одним из этапов долгосрочной стратегии Red Hat. Ярким тому подтверждением является проект CRI-O, о котором мы писали год назад. Если вкратце, то CRI-O — реализация интерфейса Kubernetes CRI (Container Runtime Interface) для запуска исполняемых сред контейнеров, совместимых со стандартом OCI (Open Container Initiative). Если ещё короче, то это замена Docker’у в качестве runtime для Kubernetes. (Схожая в техническом смысле инициатива для K8s со стороны компании Docker Inc — cri-containerd, о которой мы тоже писали; в той же статье есть сравнение производительности этих двух решений.)
История появления CRI-O такова, что, пока в OCI готовили стандарты для контейнеров (Runtime Specification и Image Specification) [что, впрочем, тоже происходило при участии Red Hat], в RH создали и поместили в инкубатор Kubernetes новый проект под названием OCID (Open Container Initiative Daemon), который позже [по требованию OCI] переименовали в CRI-O. Его предназначение звучало как «реализация стандартного интерфейса для исполняемой среды для контейнеров в Kubernetes», а продвижением в «технические массы» занимались в рамках более масштабного проекта Red Hat по созданию операционной системы для контейнеров — Project Atomic.
Шапки с логотипом CRI-O на KubeCon + CloudNativeCon North America 2017
За минувшее время CRI-O дозрел до версии 1.0, получил поддержку в Minikube, а его последним достижением можно считать принятие в качестве интерфейса для исполняемой среды контейнеров по умолчанию в проекте Kubic, который, что особенно примечательно, развивается сообществом конкурентного (для Red Hat) Linux-дистрибутива — openSUSE.
Возвращаясь к теме статьи: Podman изначально был частью CRI-O.
Появление и суть Podman
Официальный анонс проекта Podman (название является сокращением от «pod manager») состоялся в феврале этого года:
«Podman (ранее известный как kpod) существовал с прошлого лета. Изначально он являлся частью проекта CRI-O. Мы выделили podman в отдельный проект — libpod. Мы хотели, чтобы и Podman, и CRI-O развивались со своей скоростью. Оба отлично работают и по отдельности (как независимые утилиты), и вместе».
По этой причине сам анонс был озаглавлен как «повторное представление» (reintroduction). А первый публичный релиз Podman — v0.2 — состоялся за 2 недели до этого анонса. Итак, в чём же суть Podman?
Цель Podman — предоставить консольный интерфейс для запуска контейнеров вне системы оркестровки. Примечательно, что запускаемые контейнеры могут быть объединены в специальные группы с общими пространствами имён, т.е. поды (pods) — эта концепция уже стала хорошо известной благодаря Kubernetes. Проект следует идеологии UNIX-команд, где каждая утилита делает лишь одну вещь, но хорошо. Другая важная деталь, которую неустанно подчёркивают разработчики, уже была процитирована выше в анонсе: Podman может использоваться как вместе с CRI-O, так и независимо от него.
В целом же основная задумка Podman заключается в том, чтобы предоставить пользователям Kubernetes, выбравшим CRI-O в качестве исполняемой среды для контейнеров, аналог консольного интерфейса Docker CLI (для взаимодействия с контейнерами и образами, запущенными в кластерах):
«Podman реализует 38 из 40 команд Docker CLI, определённых в Docker 1.13 (на момент анонса в феврале — прим. перев.), но некоторые из них мы специально не повторяли. Например, связанные с Docker Swarm — вместо этого для подов/контейнеров, нуждающихся в оркестровке, мы предлагаем использовать Kubernetes. Также не были реализованы некоторые команды для Docker Plugins вроде плагинов томов и для сети. Полный список команд Podman и их эквивалентов в Docker можно найти на странице Podman Usage Transfer».
Фрагмент таблицы сравнения команд Docker и Podman: большинство из них совпадают, но встречаются и отличия
Однако за этой видимой идентичностью в интерфейсе кроется принципиальная разница в архитектуре: если Docker CLI для выполнения команд общается с демоном Docker, то Podman — самостоятельная утилита, не требующая никаких демонов для своей работы.
Как минимум из-за этого архитектурного отличия будет более корректным сравнивать Podman не с Docker как таковым, а с crictl — консольной утилитой из состава cri-tools (он используется, в частности, для интеграции containerd с Kubernetes). И здесь есть функциональные отличия: Podman может перезапускать остановленные контейнеры, а также обеспечивает управление образами контейнеров. (Более подробное сравнение см. в блоге OpenShift. )
С релизом Fedora 28 Atomic Host (май этого года) Podman стал инструментом этого Linux-дистрибутива по умолчанию для управления контейнерами. И только совсем недавно, в сентябре, на Linux-конференции All Systems Go! в Берлине Dan Walsh, руководитель команды Red Hat Container Engineering, представил Podman ещё более широкой публике — запись выступления можно увидеть здесь (а только презентацию — здесь).
Презентация Podman на All Systems Go! 2018
Технические примечания
Последний релиз Podman — v0.10.1.3 (от 18 октября), а последний с новыми фичами — v0.10.1 (от 12 октября), что вобрал в себя несколько новых команд и дополнительных флагов.
Код Podman написан на языке Go и распространяется на условиях свободной лицензии Apache License 2.0. Готовые для установки пакеты доступны для Fedora версии 27 и выше (есть и инструкция по установке в Ubuntu). Среди зависимых компонентов для работы Podman — такие утилиты для Linux-контейнеров, как runc и conmon, а также сетевые плагины CNI.
И запуск контейнера с Podman, и последующая работа с ним похожи на привычный сценарий использования docker :
Для практического знакомства с Podman можно также воспользоваться соответствующим онлайн-сценарием на Katacoda: «Containers without Docker — Launching Containers using Podman and Libpod».
Наконец, отдельного упоминания достоин проект pypodman, который находится в стадии активной разработки и предлагает написанный на Python интерфейс для удалённого исполнения команд Podman.
Не только Podman: libpod и экосистема
В статье уже не раз наряду с Podman встречалось упоминание проекта libpod. В чём разница?
Если говорить о «полном» проекте Red Hat, то он в действительности называется libpod и размещён на GitHub именно под таким названием. На сегодняшний день libpod позиционируется как «библиотека для приложений, нуждающихся в работе с концепцией подов из контейнеров, популяризированной Kubernetes». А сам Podman — это утилита, входящая в состав библиотеки libpod.
Если же вернуться к более широкому взгляду на контейнеры, то у Red Hat есть своё видение, которое воплощается в жизнь целым набором утилит на все случаи жизни. Большая их часть сосредоточена в репозиториях с говорящим названием github.com/containers, и одно только это уже показывает очевидные амбиции компании (к слову, раньше некоторые из этих проектов располагались на github.com/projectatomic).
Взгляды Red Hat на стандартизацию и развитие экосистемы контейнеров сформулированы прямо в README проекта libpod:
Мы уже писали практически обо всех этих проектах (runc, containers/image, containers/storage, CNI, conmon) в обзоре CRI-O, однако немаловажным пополнением с тех пор стала утилита для сборки образов контейнеров под названием buildah. Кроме того, у Red Hat уже есть готовые ответы и на некоторые другие потребности современного мира контейнеров, такие как udica для генерации профилей безопасности SELinux и skopeo для работы с удалёнными реестрами образов.
Резюмируя
Подобно тому, как Red Hat стоит не только за своей enterprise-платформой для контейнеров OpenShift, но и принимает активнейшее участие в жизни «нижележащего» Open Source-проекта Kubernetes, американская компания реализует свой взгляд на современную IT-инфраструктуру и на более фундаментальном уровне — самих контейнеров, оркестровкой которых так озабочены DevOps- и SRE-инженеры. Podman и libpod — важные компоненты целой экосистемы, формируемой Red Hat в мире контейнеров на базе открытых стандартов. Если так смотреть на происходящее, то упомянутая в самом начале статьи сделка с IBM, которую преподносят как инициативу по формированию ведущего поставщика решений в области гибридных облаков, выглядит ещё интереснее в масштабах всей индустрии…
Напоследок, предлагаю небольшой опрос об информированности читателей хабры о проекте Podman до появления этой статьи. Спасибо за участие!