Темы которые будут затронуты в данной статье:
Docker vs. Podman
Установка Podman
Компоненты Podman
Как Podman запускает контейнеры
Docker Compose
Podman REST API
Перемещение образов между машинами
Demo-приложение
Генерируем исходный код проекта Spring Boot
Добавляем логику
Dockerfile
Конвейер:
Build
Push
Test
Scan
Archive
Шифрование
Инструкции по установке тестового стенда Jenkins
Docker vs. Podman
В этой статье мы не будем подробно разбирать базовые функции Podman и отличия этого проекта от Docker.
Такой информации хватает в интернете.
Вместо этого, мы на конкретном примере (простое Java приложение) разберем как можно заменить Docker на Podman в конвейере CI/CD,
и какие это может принести дивиденды.
Podman – это инструмент с открытым исходным кодом для работы с образами контейнеров.
Является утилитой командной строки с аналогичными docker командами, однако не требует дополнительный сервис для работы и может работать без привилегий root.
В этой статье речь пойдет об использовании Podman в контексте CI/CD, но перед этим стоит перечислить несколько отличий Podman о Docker:
Podman позволяет конфигурировать короткие имена для реестров. В Docker используется docker.io когда вы выбираете короткое имя.
Podman может запускать контейнеры и поды и использованием YAML Кубернетес. А также он может генерировать YAML Кубернетес для запущенных контейнеров.
Podman поддерживает поды как в Кубернтес и может запускать несколько контейнеров в одном поде.
Podman работает как обычная CLI утилита, а Docker необходимо несколько демонов Linux с привилегиями root.
Podman может запускать контейнеры в разных пользовательских пространствах имен в отличии от Docker.
Podman поддерживает запуск systemd в контейнерах а также многие другие возможности systemd.
Podman не нужен для работы контейнеров, а Doсker использует демон Linux, который должен быть запущен всегда.
Все настройки по-умолчанию в Podman можно кастомизировать в отличии от Docker.
В то время как Docker использует монолитное приложение для создания, запуска и загрузки образов контейнеров,
разработчики Podman решили разделить функционал между тремя проектами: Podman, Buildah, и Skopeo.
Podman на Windows и macOS уже доступен, а Buildah пока доступна только на Linux, с возможностью установки в WSL2 на Windows.
Отношение между компонентами Podman:
![](https://habrastorage.org/getpro/habr/post_images/895/dbe/07d/895dbe07db15ffb5ea5d7cdb37ed92e6.png)
Как Docker запускает контейнеры:
![](https://habrastorage.org/getpro/habr/post_images/c60/287/989/c6028798918bbf8f23be212e334ef81e.png)
Архитектура Containerd:
![](https://habrastorage.org/getpro/habr/post_images/110/af9/a95/110af9a959f6332e7c70edefbc54fee4.png)
Как Podman запускает контейнеры:
![](https://habrastorage.org/getpro/habr/post_images/6f8/550/d7b/6f8550d7b82b53378e4030b41968cfd8.png)
Команды Docker и Podman:
![](https://habrastorage.org/getpro/habr/post_images/674/792/e26/674792e26ff0eefb62aceb51f54049f6.jpg)
Команды которых нет в Podman:
docker container update
Podman не поддерживает изменение запущенных контейнеров, рекомендуется пересоздавать их заново.docker plugin
Podman не поддерживает плагины.docker swarm
Podman не поддерживает Docker Swarm, вместо этого Podman, для оркестрации интегрируется с Кубернетес и использует CRI-O.docker trust
Эта команда имплементрована как Podman image trust
.
Команды которых нет в Docker:
podman container
podman generate
podman healthcheck
podman image
podman init
podman machine
podman mount
podman network exists/prune/reload
podman play
podman pod
podman system
podman unmount
podman unshare
podman untag
podman volume exists
Установка Podman
Пакеты Podman доступны для большинства дистрибутивов Linux и не требуют настройки дополнительных репозиториев:
yum install podman buildah skopeo
Сборка Podman из исходного кода гораздо проще, чем компиляция бинарных файлов Docker.
Компоненты Podman
Компонент |
Описание |
---|---|
Управление жизненным циклом контейнеров |
|
Среда выполнения контейнеров |
|
Управление образами контейнеров |
|
Управление томами, файловой системой и хранилищем данных для контейнеров и образов |
|
Сборка контейнеров |
|
Мониторинг среды выполнения контейнеров |
|
Управление сетями реализовано на основе спецификаций Кубернетес CNI |
Реестры контейнеров
Для того, чтобы получить список с реестрами контейнеров которые используются Podman:
podman info | grep registries -A 4
registries:
search:
- registry.access.redhat.com
- registry.redhat.io
- docker.io
Docker Compose
Compose нужен для оркестрации мультиконтейнерных приложений.
Podman полностью совместим с Docker Compose, однако для это необходимо активировать сервис сокета в системе:
systemctl enable --now podman.socket
docker-compose нужен docker.sock
, поэтому Podman при установке создает символическую ссылку на этот файл:
ls -al /run/docker.sock
API
После активации сервиса сокета можно проверить REST API Podman с помощью curl:
curl --unix-socket /run/podman/podman.sock http://d/v3.0.0/libpod/images/json
В данном случае вы должны получить список со всеми образами контейнеров в системе. Большинство функции Podman CLI доступны через REST API.
Перемещение образов между машинами
Podman позволяет перемещать образы контейнеров между хостами, без использования реестров контейнеров. Сначала нужно добавить новое SSH соединение:
podman system connection add <CONNECTION> -i ~/.ssh/id_ed25519 REMOTE_USER_NAME@<IP_ADDRESS>/run/user/1000/podman/podman.sock
Затем копируем образ с помощью команды podman image scp
:
podman image scp my_image <CONNECTION>
Demo-приложение
В качестве примера будет использоваться тестовый проект на Java Spring Boot. Для сборки Java будет использоваться Gradle.
Для оркестрации Jenkins.
Генерируем исходный код проекта Spring Boot
Spring Boot дает возможность с помощью встроенных средств создавать скелет проекта: директории и исходный код для сборных инструментов экосистемы Java – Maven и Gradle.
Для этого можно использовать интерфейс командной строки, веб-форму, в данном случае вы будете использовать утилиту curl:
curl https://start.spring.io/starter.tgz \
-d applicationName=HelloApplication \
-d artifactId=demo \
-d baseDir=hello \
-d bootVersion=2.7.0 \
-d dependencies=web,actuator \
-d description='Demo project for Spring Boot' \
-d groupId=com.example \
-d javaVersion=17 \
-d language=java \
-d name=demo \
-d packageName=com.example.demo \
-d packaging=jar \
-d type=gradle-project \
-d version=0.0.1-SNAPSHOT \
| tar -xzvf -
После выполнения этой команды, в текущей директории должен появится каталог приложения под названием hello:
Для того, чтобы вывести список с файлами в директории выполните команду ls hello
.
Планируемый результат:
HELP.md build.gradle gradle gradlew gradlew.bat settings.gradle src
Нужно будет добавить код в директорию сгенерированного приложения, для того, чтобы скомпилировать проект.
Добавляем логику
Ниже приведен пример кода, который нужно добавить в скелет проекта.
HelloApplication.java:
Код
package com.example.demo;
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;
@SpringBootApplication
@RestController
public class HelloApplication {
@RequestMapping("/")
public String home() {
return "Hello world\n";
}
public static void main(String[] args) {
SpringApplication.run(HelloApplication.class, args);
}
}
Добавите этот код в проект:
cp -f HelloApplication.java hello/src/main/java/com/example/demo/
Выполнить команду: ls hello/src/main/java/com/example/demo/
Планируемый результат:
HelloApplication.java
Dockerfile
Для работы вы будете использовать следующий Dockerfile:
Dockerfile
## Stage 1 : Gradle компилирует исходный код в исполняемый jar
FROM openjdk:17-oraclelinux8 as builder
RUN microdnf install findutils
WORKDIR /home/gradle/src
COPY . .
RUN ./gradlew build
## Stage 2 : Финальный образ который содержит JRE и jar
FROM openjdk:17-oraclelinux8
# Копируем jar в образ контейнера
COPY --from=builder /home/gradle/src/build/libs/demo-0.0.1-SNAPSHOT.jar demo.jar
EXPOSE 8080
# Запускаем приложение используя исполняемый jar файл
CMD ["java", "-jar", "demo.jar"]
Следующая стадия определяет контейнер который содержит только среду выполнения Java (Java runtime).
Jar-файл из предыдущей стадии копируется в новый контейнер, а остальные инструкции нужны, чтобы запустить с нужными параметрами приложение Spring Boot, которое мы создали.
Скопируйте Dockerfile в проект:
cp -f Dockerfile hello
Выполнить команду: ls hello/Dockerfile
Планируемый результат:
hello/Dockerfile
Конвейер непрерывной интеграции
Jenkins с помощью вебхуков (webhook) можно интегрировать с GitLab или Gitea,
таким образом можно организовать автоматический запуск CI конвейера после коммита в репозиторий Git.
![](https://habrastorage.org/getpro/habr/post_images/745/1c5/1de/7451c51de20c5ffcf6ea0ebd05e1ab56.jpg)
Build
Для сборки образа будем использовать Buildah.
Buildah это инструмент который работает в связке с Podman. Кодовая база Podman включает в себя пакеты Buildah.
Buildah поддерживает формат Dockerfile, но его цель это низкоуровневый интерфейс для сборки образов контейнеров без Dockerfile.
Buildah не нужен демон Linux, с помощью этого инструмента можно создавать образ контейнера внутри другого контейнера.
Buildah не нужны привилегии root для сборки образов, что является несомненным плюсом с точки зрения безопасности.
Код
stage('Build image') {
steps {
dir('k8s-course/podman/helloPodman') {
sh 'buildah build -f Dockerfile -t antonvkrylov/k8s-course:helloPodman'
}
}
}
После запуска сборки в логах можно увидеть вывод Gradle:
![](https://habrastorage.org/getpro/habr/post_images/400/d55/1c8/400d551c8130bea24e89c8139677dd90.jpg)
Основные конфигурационные файлы, которые используются Buildah:
/etc/containers/registries.conf - Реестры контейнеров.
/usr/share/containers/policy.json - Верификация сигнатур.
/usr/share/containers/mounts.conf - Директории и файлы которые автоматически монтируются в контейнерах.
/usr/share/containers/seccomp.json - Системные вызовы которые разрешены для выполнения в контейнерах.
Push
Загрузка собранного образа в реестр ничем не отличается от Docker:
Код
stage('Push image') {
steps {
dir('k8s-course/podman/helloPodman') {
sh 'buildah push antonvkrylov/k8s-course:helloPodman'
}
}
}
Так же как и с Docker для аутентификации используется команда podman/buildah login
Buildah так же как и Podman умеет работать c аутентификационными файлами:buildah push --authfile /auth.json registry.example.com
Test
Podman позволяет проверять состояние контейнера и приложения с помощью специальных проверок (healthchecks).
Механизм проверок похож на то, что было реализовано в последних версиях Docker Compose.
С помощью этой функции, можно встраивать в конвейер CI простые функциональные и интеграционные тесты.
Код
stage('Test') {
/////////
/// Jenkins позволяет выполнять стадии или шаги внутри одной стадии параллельно
/////////
parallel {
stage('Test ports') {
steps {
/////////
/// Мы создаем проверку (healthcheck) с определенными параметрами, которая выполняет запрос с помощью curl внутри контейнера.
/////////
sh"""
podman run --rm -dt --name test_ports \
--healthcheck-start-period 10s \
--healthcheck-retries 1 \
--healthcheck-command "CMD-SHELL curl -f http://127.0.0.1:8080 || exit 1" docker.io/antonvkrylov/k8s-course:helloPodman
"""
/////////
/// Если таймаут в 2 минуты будет превышен то конвейер прервется с ошибкой и статусом «Aborted»
/////////
timeout(time: 2, unit: 'MINUTES') {
/////////
/// В этом скрипте мы проверяем статус проверки через каждые 3 секунды – если статус «healthy» то цикл завершается.
/////////
sh"""
#!/bin/bash
while [ "`podman healthcheck run test_ports`" = "unhealthy" ]; do
sleep 3
done
"""
}
}
}
stage('Test Java') {
steps {
/////////
/// С помощью grep проверяем версию Java в контейнере
/////////
sh"""
podman run --rm -dt --name test_java \
--healthcheck-start-period 10s \
--healthcheck-retries 1 \
--healthcheck-command "CMD-SHELL java --version | grep 'openjdk 17.0.2' || exit 1" docker.io/antonvkrylov/k8s-course:helloPodman
"""
timeout(time: 2, unit: 'MINUTES') {
sh"""
#!/bin/bash
while [ "`podman healthcheck run test_java`" = "unhealthy" ]; do
sleep 3
done
"""
}
}
}
}
}
Scan
Для сканирования собранного образа на уязвимости можно использовать один из популярных инструментов для статического анализа уязвимостей (SAST):
Код
stage('Scan image') {
steps {
dir('k8s-course/podman/helloPodman') {
sh 'trivy image --security-checks vuln --severity CRITICAL antonvkrylov/k8s-course:helloPodman'
}
}
}
Результаты сканирования для каждой сборки будут сохранятся в Jenkins:
![](https://habrastorage.org/getpro/habr/post_images/01d/6ba/3da/01d6ba3daf931539fdc92be7979dcb96.jpg)
Archive
Skopeo используется для копирования и перемещения образов между реестрами контейнеров. В данном случае образ контейнера из публичного реестра с помощью skopeo сохраняется для архивации на диске:
Код
stage('Archive') {
steps {
sh"""
skopeo copy docker://antonvkrylov/k8s-course:helloPodman --dest-compress --dest-compress-format gzip docker-archive:./helloPodman.tar.gz
"""
}
}
}
Skopeo можно использовать для реверс-инжиниринга образов, в случаях, когда не доступа к Dockerfile:
# С помощью команды inspect получаем манифест camunda-bpm-platform
skopeo inspect docker://camunda/camunda-bpm-platform:wildfly-SNAPSHOT
# Далее копируем этот образ из Dockerhub в директорию /tmp/camunda
skopeo copy docker://camunda/camunda-bpm-platform:wildfly-SNAPSHOT dir://tmp/camunda
tree /tmp/camunda/
/tmp/camunda/
├── 0cdfa0c98ed79707cd91c5dd7ebd282aa2b976d86a9e699d7fc188cdb6be390e
├── 16e3566755e5dc026d1a6bcc28c8edc7a7aa6d068af8a5b9e10478c1dd900682
├── 410f32425c8a73d3e62330ab499ae85a1ce97fec74e572c2b50af4d654d44649
├── 4f4fb700ef54461cfa02571ae0db9a0dc1e0cdb5577484a6d75e68dc38e8acc1
├── c2005d18c6a3b605fc54bf733127284e0e46adbcd1180532d8d0f06b684525ae
├── dd2f5668f681c59da620c20459eca51d05ac3412e3e37ab24420329452e5fec9
├── manifest.json
└── version
0 directories, 8 files
# Манифест Docker будет содержать директивы которые необходимо выполнять для сборки образа:
cat /tmp/camunda/16e3566755e5dc026d1a6bcc28c8edc7a7aa6d068af8a5b9e10478c1dd900682 | jq .
Шифрование
В ситуациях когда необходимо использовать публичный реестр контейнеров для работы с закрытой кодовой базой, skopeo позволяет использовать шифрование:
# Генерируем приватный ключ
openssl genrsa -out private_key.pem
openssl rsa -inform pem -outform pem -pubout -in private_key.pem -out public_key.pem
Загружаем образ с помощью skopeo:
# Используем приватный ключ для шифрования образа
skopeo copy --encryption-key jwe:public_key.pem docker://antonvkrylov/k8s-course:helloPodman docker://antonvkrylov/k8s-course:helloPodman_encrypted
Artifacts
Инструктируем Jenkins сохранять сборочные артефакты и останавливать все запущенные контейнеры после прогона конвейера:
Код
post {
// Clean after build
always {
cleanWs()
}
success {
echo "Build success"
//archiveArtifacts artifacts: '**/*.tar.gz', fingerprint: true
}
failure {
echo "Build failed"
sh "podman stop --all"
}
aborted {
echo "Build aborted"
sh "podman stop --all"
}
}
Инструкции по установке тестового стенда Jenkins
Инструкции
Скачать docker-compose:
curl -L "https://github.com/docker/compose/releases/download/1.29.2/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
Сделать файл исполняемым:
chmod +x /usr/local/bin/docker-compose
Удостовериться, что docker-compose работает:
docker-compose --version
docker-compose version 1.29.2, build 5becea4c
Сохранить файл со следующим содержимым docker-compose.yaml
:
version: '2'
services:
jenkins:
image: jenkins/jenkins:2.401.2-lts-jdk11
user: root
privileged: true
container_name: jenkins
user: jenkins
volumes:
- ${PWD}/data:/var/jenkins_home
environment:
JENKINS_HOST_HOME: "/data/jenkins"
ports:
- "8088:8080"
- "5000:5000"
- "50000:50000"
mkdir data
chown -R 1000:1000 data
Запустите docker-compose:
docker-compose up
Планируемый результат:
Pulling jenkins (jenkins:2.60.3)...
2.60.3: Pulling from library/jenkins
55cbf04beb70: Pull complete
1607093a898c: Pull complete
9a8ea045c926: Pull complete
d4eee24d4dac: Pull complete
c58988e753d7: Pull complete
794a04897db9: Pull complete
70fcfa476f73: Pull complete
0539c80a02be: Extracting [=========> ] 26.74MB/133.9MB
54fefc6dcf80: Download complete
911bc90e47a8: Download complete
http://<< IP ADDRESS >>:8088
Сгенерированный автоматический пароль можно найти в логе:
![](https://habrastorage.org/getpro/habr/post_images/b5c/901/c0f/b5c901c0f10135e9eb17d0338bbbf670.jpg)
Введите пароль:
![](https://habrastorage.org/getpro/habr/post_images/ca6/6f1/c6a/ca66f1c6a7a78aa1c1adacc09669f340.jpg)
Дождитесь завершения загрузки плагинов:
![](https://habrastorage.org/getpro/habr/post_images/19f/161/907/19f16190778047515484d92ecc71d1cc.jpg)
Выберите «new item» => pipeline:
![](https://habrastorage.org/getpro/habr/post_images/ff7/fc5/306/ff7fc53068a56e378bbe6f5fea6c4897.jpg)
В секции «pipeline» нужно будет добавить скрипт для тестового приложения:
![](https://habrastorage.org/getpro/habr/post_images/1c6/a2e/b9f/1c6a2eb9fcfa98a7fb82ea9a48941f36.jpg)
Конвейер для тестового приложения:
Код
pipeline {
agent any
stages {
stage('Cleanup') {
steps {
sh 'rm -rf k8s-course'
}
}
stage('Clone sources') {
steps {
sh 'git clone https://github.com/randomfx/k8s-course.git'
}
}
stage('Build image') {
steps {
dir('k8s-course/podman/helloPodman') {
sh 'buildah build -f Dockerfile -t antonvkrylov/k8s-course:helloPodman'
}
}
}
stage('Push image') {
steps {
dir('k8s-course/podman/helloPodman') {
sh 'buildah push antonvkrylov/k8s-course:helloPodman'
}
}
}
stage('Scan image') {
steps {
dir('k8s-course/podman/helloPodman') {
sh 'trivy image --security-checks vuln --severity CRITICAL antonvkrylov/k8s-course:helloPodman'
}
}
}
stage('Test') {
/////////
/// Jenkins позволяет выполнять стадии или шаги внутри одной стадии параллельно
/////////
parallel {
stage('Test ports') {
steps {
/////////
/// Мы создаем проверку (healthcheck) с определенными параметрами, которая выполняет запрос с помощью curl внутри контейнера.
/////////
sh"""
podman run --rm -dt --name test_ports \
--healthcheck-start-period 10s \
--healthcheck-retries 1 \
--healthcheck-command "CMD-SHELL curl -f http://127.0.0.1:8080 || exit 1" docker.io/antonvkrylov/k8s-course:helloPodman
"""
/////////
/// Если таймаут в 2 минуты будет привешен то конвейер прервется с ошибкой и статусом «Aborted»
/////////
timeout(time: 2, unit: 'MINUTES') {
/////////
/// В этом скрипте мы проверяем статус проверки через каждые 3 секунды – если статус «healthy» то цикл завершается.
/////////
sh"""
#!/bin/bash
while [ "`podman healthcheck run test_ports`" = "unhealthy" ]; do
sleep 3
done
"""
}
}
}
stage('Test Java') {
steps {
/////////
/// С помощью grep проверяем версию Java в контейнере
/////////
sh"""
podman run --rm -dt --name test_java \
--healthcheck-start-period 10s \
--healthcheck-retries 1 \
--healthcheck-command "CMD-SHELL java --version | grep 'openjdk 17.0.2' || exit 1" docker.io/antonvkrylov/k8s-course:helloPodman
"""
timeout(time: 2, unit: 'MINUTES') {
sh"""
#!/bin/bash
while [ "`podman healthcheck run test_java`" = "unhealthy" ]; do
sleep 3
done
"""
}
}
}
}
}
stage('Archive') {
steps {
sh"""
skopeo copy docker://antonvkrylov/k8s-course:helloPodman --dest-compress --dest-compress-format gzip docker-archive:./helloPodman.tar.gz
"""
}
}
}
post {
// Clean after build
always {
cleanWs()
}
success {
echo "Build success"
//archiveArtifacts artifacts: '**/*.tar.gz', fingerprint: true
}
failure {
echo "Build failed"
sh "podman stop --all"
}
aborted {
echo "Build aborted"
sh "podman stop --all"
}
}
}
Комментарии (51)
impwx
16.07.2023 13:57+11Кроме возможности работы без root-привелегий больше различий в статье не увидел. Это одно уже позволяет похоронить Docker, или все-таки есть что-то еще?
iig
16.07.2023 13:57+8Для работы с docker не нужны root-привилегии. Достаточно добавить себя в группу docker.
Hidden text
dockerd внутри системы крутится от root, да.
mayorovp
16.07.2023 13:57+11Находясь в группе docker можно запускать любые процессы из-под рута, так что группу docker по-хорошему надо бы рассматривать как скрытых рутов.
randomsimplenumber
16.07.2023 13:57+1Думал возразить, что процесс, работающий под root изолирован внутри контейнера. Но вспомнил, что можно же смонтировать любой каталог внутрь контейнера, и с правами root туда что-то записать..
Llorephie
16.07.2023 13:57+1Изолированные пространства имён всё-таки не стали панацеей для Podman: https://bdu.fstec.ru/vul/2023-03685 (https://cwe.mitre.org/data/definitions/269.html; https://cwe.mitre.org/data/definitions/281.html) - даже без операции монтирования общего с хостом каталога :)
Rikimaru22 Автор
16.07.2023 13:57-3В контексте CI/CD модульная структура Podman (Buildah, Skopeo, Podman) является серьезным преимуществом. Podman поддерживает интеграцию с Systemd и Kubernetes – но об этом я может быть расскажу в другой статье.
impwx
16.07.2023 13:57+14Просто слово "модульность" ни о чем не говорит. Мне так сотовый оператор периодически пытается впарить новый тариф, говоря что он "комплексный". На деле выходит, что в него просто включены ненужные мне функции, за которые я буду переплачивать.
В чем именно заключается преимущество модульности в данном случае?
Rikimaru22 Автор
16.07.2023 13:57-10Честно говоря я бы сказал, что «впаривать» пытается как раз Docker Inc. когда они интегрируют движок Кубернетес в Docker Desktop. :)
Может быть вы просто не работали в больших компаниях. Дело в том, что Docker хочет денег если вы используете их продукты в корпоративном окружении.
Кроме того, для ИБ возможность установки отдельной утилиты для работы с образами (Skopeo) без необходимости на каждом сервере разворачивать Docker daemon является плюсом. Просто может быть вы не знаете, что Docker при установке на Linux вносит изменения в правила Iptables, что с точки зрения безопасности является серьезным вопросом.
PuerteMuerte
16.07.2023 13:57+7Дело в том, что Docker хочет денег если вы используете их продукты в корпоративном окружении
Хм. Вы так пишете, как будто в этом есть хоть капля чего-то плохого. Это бизнес, в бизнесе платить за приносящий деньги софт нормально. Я вам более того скажу, сколь-нибудь крупные бесплатные проекты и существуют как раз благодаря тому, что бизнес платит их разработчикам.
Rikimaru22 Автор
16.07.2023 13:57-11Все правильно. У меня нет никаких претензий к лицензированию Docker. Разработчики Docker создали потрясающий проект. Просто судя по тому как, коллега выше в комментариях написал про «впаривать» у меня есть серьезные сомнения, в том, что он как и большинство пользователей покупал лицензию Docker или учетную запись на Dockerhub.
И разработчики Podman тоже хотят денег, но не за Podman, а за доступ к экосистеме RedHat, что для российских компаний является больше предпочтительным вариантом, особенно в текущих условиях.
impwx
16.07.2023 13:57Слово "впаривать" я использовал в контексте того, как ваша статья очень категорично предлагает использовать новый инструмент вместо старого и не предоставляет достаточно веских аргументов. Это не про деньги, это про манеру подачи.
Касательно лицензии на докер, ваше допущение неверно: у нас в организации он лицензионный. Но я работаю не на российскую фирму, тут с этим строже и в то же время проще: риска быть "отключенным" от услуг и обновлений нет, поэтому лицензии на софт, который используется и окупается, приобретаются без вопросов.
MikalaiR
16.07.2023 13:57+1Похоронить вряд ли, но насколько помню, обычный Docker имеет некоторые проблемы с SELinux, которых нет в podman.
s207883
16.07.2023 13:57+1Второй плюс, видимо, в том, что докер для старперов, а подман это стильно и модно.
AllexIn
16.07.2023 13:57+8Ну вот. Я надеялся, что статья расскажет почему контейнерам пора умереть и есть решения лучше, а по факту предлагают заменить шило на мыло.
Rikimaru22 Автор
16.07.2023 13:57-11У «шила» есть лицензионное соглашение:
*Docker Desktop is free to use as part of the Docker Personal subscription for individuals, non-commercial open source developers, students and educators, and small businesses of fewer than than 250 employees AND less than $10 million in revenue. Commercial use of Docker Desktop at a company of more than 250 employees OR more than $10 million in annual revenue requires a paid subscription (Pro, Team, or Business).
Большинство российских компаний не возможности лицензировать Docker даже если бы было такое желание.
И это только один из моментов которые стоит учитывать.
siziyman
16.07.2023 13:57+5Большинство российских компаний не возможности лицензировать Docker даже если бы было такое желание.
Вот только в заголовке нет ни слова про российские компании. :)
Eltypo
16.07.2023 13:57+2The Docker Engine is licensed under the Apache License, Version 2.0.
https://docs.docker.com/engine/Rikimaru22 Автор
16.07.2023 13:57Docker Engine да лицензия Apache но у него есть другие недостатки по сравнению с Podman:
Podman позволяет конфигурировать короткие имена для реестров. В Docker «захрадкожен» docker.io когда вы выбираете короткое имя.
Podman может запускать контейнетры и поды и использованием YAML Кубернетес. А также он может генерировать YAML Кубернетес для запущенных контейнеров.
Podman поддерживает поды как в Кубернтес и может запускать несколько контейнеров в одном поде.
Podman работает как обычная CLI утилита, а Docker необходимо несколько демонов Linux с привилегиями root.
Podman может запускать контейнреы в разных пользовательских пространствах имен в отличии от Docker.
Podman поддерживает запуск systemd в конейнерах а также многие возможности systemd.
Podman не нужен для работы контейнеров, а Doсker использует демон Linux, который должен быть запущенн всегда.
Все настройки по-умолчанию в Podman можно кастомизировать в отличии от Docker.
izogfif
16.07.2023 13:57+1А почему бы просто не использовать Kubernetes вместо Podman? minikube, k8s и вот это вот все?
saboteur_kiev
16.07.2023 13:57+1А мне кажется вы тупо путаете само создание контейнеров и их оркестрацию. И подман следует сравнивать не с докер, а с его прямыми конкурентами - докерсварм, кубер, опенщифт и др.
PuerteMuerte
16.07.2023 13:57+1И это только один из моментов которые стоит учитывать.
Если у вас контора с прибылью более 10 млн баксов в год, вы этот момент уж точно в состоянии учесть. Или скорее не вы, а профессиональный учитыватель моментов в отделе учёта софта учётного управления вашей корпорации, вам даже ничего делать не надо - просто отправить на согласование служебку "Хочу Докер".
Rikimaru22 Автор
16.07.2023 13:57Для компании Docker все оказалось немного сложнее :) они испытывали, определенные трудности с поиском клиентов готовых платить деньги, даже среди крупных корпораций. Однажды они могут решить отказатся от Docker Engine и Docker Desktop и передать эту часть бизнеса другому вендору как это уже было сделано с Docker Enterprise.
По-этому на десктопах и рабочих машинах под управлением macOS и Windows, Docker все еще номер 1, если говорить о user expirence, а вот на стороне CI/CD – он больше не нужен. Есть более перспективные варианты, например Podman.
BugM
16.07.2023 13:57Не надо так делать. Это черевато разными тонкостями реализаций. Когда софт ведет себя не так как ожидалось. И все тратят дни и недели чтобы понять что сломалось.
Есть стандарты - пользуйтесь ими. И купите уже Докер. Он для компании совсем недорогой.
Rikimaru22 Автор
16.07.2023 13:57-2Стандарты определяет Open Container Initiative. У большинства пользователей не должно возникнуть проблем с миграцией на Podman. Можно, даже использовать простой алиас «alias docker=podman» – большая часть функционала у Docker Engine CLI совподает с Podman.
Можете покупать Docker, но для российских компаний я все же рекомендовал бы научится собирать Podman из исходников, делать пакеты RPM и DEB, и пользоваться Linux.
Это для того, чтобы, однажды у них не отозвали оплаченные лицензии и не заблокировал учетки на GitHub, как это уже происходило не раз. :)
BugM
16.07.2023 13:57Большая часть это очень мало на самом деле. Проблемы они в последних 2 процентах всегда. И эти проблемы могут стоить много миллионов.
Купить это лучший выбор обычно. При чем тут российские компании непонятно. Лицензия едина для всех. Ну если Докер их продавать не хочет, то другое дело. Тогда стоит подумать. И вероятно купить через прокладку. Их навалом у всех уже. А если продает купить и забыть о проблеме надолго.
Отозвать оплаченные лицензии нельзя. Они ну просто есть.
Rikimaru22 Автор
16.07.2023 13:57-3Мне кажется ты совсем понимаешь суть вопроса. Компания может купить лицензии GitHub, Dockerhub и Docker, а потом в один день, по независящем от нее причинам, у этой компании отзовут лицензии и удалят репозитории с исходным кодом, который стоил миллионы.. Это вполне реальная ситуация.
Кстати о стандартах в IT можно сказать, что они постоянно меняются. Когда-то WebSphere и Drowizard были стандартами, а Docker непонятной новой игрушкой. Стандарты будут меняться, а вместе с ними и инструменты.
BugM
16.07.2023 13:57+1Вы точно знаете как тот же Гитхаб Энтерпрайз работает? Мне кажется что нет.
Большие ребята договорились и разошлись по хорошему. Никто никому ничего никогда не удаляет в корпоративной сфере. Тем более внезапно. Там большие деньги. И все в курсе что потом все снова вместе работать будут. Отношения портить не стоит. Конкуренты про все узнают и будут этим пользоваться годами. Это сильный козырь.
Вот как стандарт сменится тогда и приходите. Ничего не имею против новых отраслевых стандартов. Буду переходить и внедрять без всяких проблем или сопротивления. Подман сейчас заметно не тянет на отраслевой стандарт. Через годик стоит еще раз на него посмотреть. Может что и изменится.
slonopotamus
16.07.2023 13:57+3И купите уже Докер
Не надо смешивать Docker и Docker Desktop. Если вам нужно первое, его можно получить миллионом способов, например через Podman Desktop.
slonopotamus
16.07.2023 13:57+14Что-нибудь кроме докера уже научилось билдить виндовые контейнеры? Спойлер: нет. Заголовок осуждаю.
mayorovp
16.07.2023 13:57+7Что-то тут мне интересно стало, а как в непривелигированном podman работают виртуальные сети?
Как без общего реестра будет выделен новый адрес для созданного контейнера? А как создаётся сеть в подмане? Как там вообще работает DNS, резолвящий имена контейнеров? Как без прав рута пробрасывается порт?
ivankudryavtsev
Заголовок кликбейтный, потому что он подразумевает, что статья ответит на вопрос "Почему".
Давайте продолжим: Podman больше не нужен (firecracker, server webassembly, ... подставьте). Ну и Java тоже не нужна.
Rikimaru22 Автор
Не очень удачная аналогия с firecracker и webassembly. Эти проекты не могут быть полноценной заменой для Docker, и более того никто не ставит перед ними такой задачи. Podman, с другой стороны был создан как альтернатива для Docker и на данном этапе, я считаю уже готов для того, чтобы служить полноценной заменой для Docker в контексте CI/CD. Это не значит, что в Docker больше нет необходимости, просто больше он не является безальтернативным инструментом как это было раньше.
aol-nnov
Но это оправдание, кхм, совсем не оправдывает кликбейтный заголовок. Более того, хочется уже спросить "что ж ты, фраер, сдал назад?" Особенно, после "Это не значит, что в Docker больше нет необходимости" ????
Rikimaru22 Автор
Вам показалась. Docker действительно больше не нужен. :)
aol-nnov
С появлением Open Container Initiative. Случилось ли это до появления подмана или после, сказать не могу, но автор статьи в каментах делает отчаянные попытки скользить - это факт )
ivankudryavtsev
Да я просто первое что в голову пришло написал...
Rikimaru22 Автор
Да, я понял. Есть еще много моментов о которых в гайде не напишешь, например Docker Inc. является коммерческой структурой, которая в один прекрасный момент может решить свернуть проект Docker или продать часть бизнеса другому вендору, как это уже произошло с Docker Swarm. IBM\RedHat в этом контексте гораздо надежней для больших компаний, потому-что они могут гарантировать развитие проектов с открытым исходным кодом на десятилетия вперед. Хотя как уже успели убедится на примере Centos 100% никто дать не может.
Учитывая немалый вклад RedHat в экосистему Кубернетес, можно спрогнозировать, что Podman будет развиваться в плане добавления новых возможностей гораздо быстрее Docker.
ugenk
Резюмируя: у Docker есть один фатальный недостаток (с)
RadeG
История с CentOS показывает, что RedHat также ничего особо не гарантирует
isden
Нет уж позвольте!
AlexSteelax
Ну есть же c#, который и приятнее, и с сахаром, и развивается в быстром темпе.
isden
Kotlin тогда уж. Но Java и так не так уж и плоха, особенно в последние несколько лет.
eyudkin
Таки c# и по фичам и сахару богаче котлина, и внедряет их быстрее.
isden
По моим наблюдениям, котлин достаточно резво развивается. По поводу сахара - это субъективно :) Лично мне больше нравится котлин.
Gotcha7770
Конечно же, Вы имели в виду F#))
Source
Вы прям в корень зрите. Зачем нужна Java c JVM, если можно взять Elixir с BEAM, и вот вам уже и Java не нужна и Docker тоже не нужен (там своих фич хватает для горизонтального масштабирования и отказоустойчивости)
mayorovp
Но Docker же не для масштабирования используется, и не для отказоустойчивости...