16.07.2023 11:18
Rikimaru22 51 22000 Источник

Темы которые будут затронуты в данной статье:

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:

Как Docker запускает контейнеры:

Архитектура Containerd:

Как Podman запускает контейнеры:

Команды Docker и Podman:

Команды которых нет в 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

Компонент

Описание

libpod

Управление жизненным циклом контейнеров

crun/runc

Среда выполнения контейнеров

containers/image

Управление образами контейнеров

containers/storage

Управление томами, файловой системой и хранилищем данных для контейнеров и образов

Buildah

Сборка контейнеров

Conmon

Мониторинг среды выполнения контейнеров

Container Network Interface (CNI)

Управление сетями реализовано на основе спецификаций Кубернетес 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.

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:

Основные конфигурационные файлы, которые используются 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:

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

Сгенерированный автоматический пароль можно найти в логе:

Введите пароль:

Дождитесь завершения загрузки плагинов:

Выберите «new item» => pipeline:

В секции «pipeline» нужно будет добавить скрипт для тестового приложения:

Конвейер для тестового приложения:

Код
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)


  1. ivankudryavtsev
    16.07.2023 13:57
    #25757478
    +54

    Заголовок кликбейтный, потому что он подразумевает, что статья ответит на вопрос "Почему".

    Давайте продолжим: Podman больше не нужен (firecracker, server webassembly, ... подставьте). Ну и Java тоже не нужна.


    1. Rikimaru22 Автор
      16.07.2023 13:57
      #25757512
      -18

      Не очень удачная аналогия с firecracker и webassembly. Эти проекты не могут быть полноценной заменой для Docker, и более того никто не ставит перед ними такой задачи. Podman, с другой стороны был создан как альтернатива для Docker и на данном этапе, я считаю уже готов для того, чтобы служить полноценной заменой для Docker в контексте CI/CD. Это не значит, что в Docker больше нет необходимости, просто больше он не является безальтернативным инструментом как это было раньше.


      1. aol-nnov
        16.07.2023 13:57
        #25757524
        +28

        Но это оправдание, кхм, совсем не оправдывает кликбейтный заголовок. Более того, хочется уже спросить "что ж ты, фраер, сдал назад?" Особенно, после "Это не значит, что в Docker больше нет необходимости" ????


        1. Rikimaru22 Автор
          16.07.2023 13:57
          #25757534
          -10

          Вам показалась. Docker действительно больше не нужен. :)


          1. aol-nnov
            16.07.2023 13:57
            #25757546
            +2

            С появлением Open Container Initiative. Случилось ли это до появления подмана или после, сказать не могу, но автор статьи в каментах делает отчаянные попытки скользить - это факт )


      1. ivankudryavtsev
        16.07.2023 13:57
        #25757530

        Да я просто первое что в голову пришло написал...


        1. Rikimaru22 Автор
          16.07.2023 13:57
          #25757564
          -3

          Да, я понял. Есть еще много моментов о которых в гайде не напишешь, например Docker Inc. является коммерческой структурой, которая в один прекрасный момент может решить свернуть проект Docker или продать часть бизнеса другому вендору, как это уже произошло с Docker Swarm. IBM\RedHat в этом контексте гораздо надежней для больших компаний, потому-что они могут гарантировать развитие проектов с открытым исходным кодом на десятилетия вперед. Хотя как уже успели убедится на примере Centos 100% никто дать не может.

          Учитывая немалый вклад RedHat в экосистему Кубернетес, можно спрогнозировать, что Podman будет развиваться в плане добавления новых возможностей гораздо быстрее Docker.


          1. ugenk
            16.07.2023 13:57
            #25757622
            +17

            Резюмируя: у Docker есть один фатальный недостаток (с)


          1. RadeG
            16.07.2023 13:57
            #25757968
            +13

            История с CentOS показывает, что RedHat также ничего особо не гарантирует


    1. isden
      16.07.2023 13:57
      #25757612

      Ну и Java тоже не нужна.

      Нет уж позвольте!


      1. AlexSteelax
        16.07.2023 13:57
        #25757910

        Ну есть же c#, который и приятнее, и с сахаром, и развивается в быстром темпе.


        1. isden
          16.07.2023 13:57
          #25757950
          +1

          Kotlin тогда уж. Но Java и так не так уж и плоха, особенно в последние несколько лет.


          1. eyudkin
            16.07.2023 13:57
            #25761148

            Таки c# и по фичам и сахару богаче котлина, и внедряет их быстрее.


            1. isden
              16.07.2023 13:57
              #25761178

              По моим наблюдениям, котлин достаточно резво развивается. По поводу сахара - это субъективно :) Лично мне больше нравится котлин.


        1. Gotcha7770
          16.07.2023 13:57
          #25758784

          Конечно же, Вы имели в виду F#))


    1. Source
      16.07.2023 13:57
      #25760150

      Ну и Java тоже не нужна.

      Вы прям в корень зрите. Зачем нужна Java c JVM, если можно взять Elixir с BEAM, и вот вам уже и Java не нужна и Docker тоже не нужен (там своих фич хватает для горизонтального масштабирования и отказоустойчивости)


      1. mayorovp
        16.07.2023 13:57
        #25761450
        -1

        Но Docker же не для масштабирования используется, и не для отказоустойчивости...


  1. impwx
    16.07.2023 13:57
    #25757490
    +11

    Кроме возможности работы без root-привелегий больше различий в статье не увидел. Это одно уже позволяет похоронить Docker, или все-таки есть что-то еще?


    1. iig
      16.07.2023 13:57
      #25757518
      +8

      Для работы с docker не нужны root-привилегии. Достаточно добавить себя в группу docker.

      Hidden text

      dockerd внутри системы крутится от root, да.


      1. mayorovp
        16.07.2023 13:57
        #25757698
        +11

        Находясь в группе docker можно запускать любые процессы из-под рута, так что группу docker по-хорошему надо бы рассматривать как скрытых рутов.


        1. randomsimplenumber
          16.07.2023 13:57
          #25757760
          +1

          Думал возразить, что процесс, работающий под root изолирован внутри контейнера. Но вспомнил, что можно же смонтировать любой каталог внутрь контейнера, и с правами root туда что-то записать..


          1. Llorephie
            16.07.2023 13:57
            #25762466
            +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) - даже без операции монтирования общего с хостом каталога :)


      1. kova7ev
        16.07.2023 13:57
        #25757864
        +4

        https://docs.docker.com/engine/security/rootless/


    1. Rikimaru22 Автор
      16.07.2023 13:57
      #25757528
      -3

      В контексте CI/CD модульная структура Podman (Buildah, Skopeo, Podman) является серьезным преимуществом. Podman поддерживает интеграцию с Systemd и Kubernetes – но об этом я может быть расскажу в другой статье.


      1. impwx
        16.07.2023 13:57
        #25757544
        +14

        Просто слово "модульность" ни о чем не говорит. Мне так сотовый оператор периодически пытается впарить новый тариф, говоря что он "комплексный". На деле выходит, что в него просто включены ненужные мне функции, за которые я буду переплачивать.


        В чем именно заключается преимущество модульности в данном случае?


        1. Rikimaru22 Автор
          16.07.2023 13:57
          #25757572
          -10

          Честно говоря я бы сказал, что «впаривать» пытается как раз Docker Inc. когда они интегрируют движок Кубернетес в Docker Desktop. :)

          Может быть вы просто не работали в больших компаниях. Дело в том, что Docker хочет денег если вы используете их продукты в корпоративном окружении.

          Кроме того, для ИБ возможность установки отдельной утилиты для работы с образами (Skopeo) без необходимости на каждом сервере разворачивать Docker daemon является плюсом. Просто может быть вы не знаете, что Docker при установке на Linux вносит изменения в правила Iptables, что с точки зрения безопасности является серьезным вопросом.


          1. PuerteMuerte
            16.07.2023 13:57
            #25757714
            +7

            Дело в том, что Docker хочет денег если вы используете их продукты в корпоративном окружении

            Хм. Вы так пишете, как будто в этом есть хоть капля чего-то плохого. Это бизнес, в бизнесе платить за приносящий деньги софт нормально. Я вам более того скажу, сколь-нибудь крупные бесплатные проекты и существуют как раз благодаря тому, что бизнес платит их разработчикам.


            1. Rikimaru22 Автор
              16.07.2023 13:57
              #25757746
              -11

              Все правильно. У меня нет никаких претензий к лицензированию Docker. Разработчики Docker создали потрясающий проект. Просто судя по тому как, коллега выше в комментариях написал про «впаривать» у меня есть серьезные сомнения, в том, что он как и большинство пользователей покупал лицензию Docker или учетную запись на Dockerhub.

              И разработчики Podman тоже хотят денег, но не за Podman, а за доступ к экосистеме RedHat, что для российских компаний является больше предпочтительным вариантом, особенно в текущих условиях.


              1. impwx
                16.07.2023 13:57
                #25759458

                Слово "впаривать" я использовал в контексте того, как ваша статья очень категорично предлагает использовать новый инструмент вместо старого и не предоставляет достаточно веских аргументов. Это не про деньги, это про манеру подачи.

                Касательно лицензии на докер, ваше допущение неверно: у нас в организации он лицензионный. Но я работаю не на российскую фирму, тут с этим строже и в то же время проще: риска быть "отключенным" от услуг и обновлений нет, поэтому лицензии на софт, который используется и окупается, приобретаются без вопросов.


    1. MikalaiR
      16.07.2023 13:57
      #25758362
      +1

      Похоронить вряд ли, но насколько помню, обычный Docker имеет некоторые проблемы с SELinux, которых нет в podman.


    1. s207883
      16.07.2023 13:57
      #25760094
      +1

      Второй плюс, видимо, в том, что докер для старперов, а подман это стильно и модно.


    1. Self_Perfection
      16.07.2023 13:57
      #25760546

      По моим бенчмаркам podman гораздо меньше тормозит.


  1. AllexIn
    16.07.2023 13:57
    #25758152
    +8

    Ну вот. Я надеялся, что статья расскажет почему контейнерам пора умереть и есть решения лучше, а по факту предлагают заменить шило на мыло.


    1. Rikimaru22 Автор
      16.07.2023 13:57
      #25758164
      -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 даже если бы было такое желание.

      И это только один из моментов которые стоит учитывать.


      1. siziyman
        16.07.2023 13:57
        #25758170
        +5

        Большинство российских компаний не возможности лицензировать Docker даже если бы было такое желание.

        Вот только в заголовке нет ни слова про российские компании. :)


      1. ColdPhoenix
        16.07.2023 13:57
        #25758228
        +19

        Docker desktop != docker


      1. Eltypo
        16.07.2023 13:57
        #25758236
        +2

        The Docker Engine is licensed under the Apache License, Version 2.0.
        https://docs.docker.com/engine/


        1. Rikimaru22 Автор
          16.07.2023 13:57
          #25758242

          Docker 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. 


          1. izogfif
            16.07.2023 13:57
            #25760096
            +1

            А почему бы просто не использовать Kubernetes вместо Podman? minikube, k8s и вот это вот все?


          1. saboteur_kiev
            16.07.2023 13:57
            #25760120
            +1

            А мне кажется вы тупо путаете само создание контейнеров и их оркестрацию. И подман следует сравнивать не с докер, а с его прямыми конкурентами - докерсварм, кубер, опенщифт и др.


      1. PuerteMuerte
        16.07.2023 13:57
        #25758414
        +1

        И это только один из моментов которые стоит учитывать.

        Если у вас контора с прибылью более 10 млн баксов в год, вы этот момент уж точно в состоянии учесть. Или скорее не вы, а профессиональный учитыватель моментов в отделе учёта софта учётного управления вашей корпорации, вам даже ничего делать не надо - просто отправить на согласование служебку "Хочу Докер".


        1. Rikimaru22 Автор
          16.07.2023 13:57
          #25758440

          Для компании Docker все оказалось немного сложнее :) они испытывали, определенные трудности с поиском клиентов готовых платить деньги, даже среди крупных корпораций. Однажды они могут решить отказатся от Docker Engine и Docker Desktop и передать эту часть бизнеса другому вендору как это уже было сделано с Docker Enterprise.

          По-этому на десктопах и рабочих машинах под управлением macOS и Windows, Docker все еще номер 1, если говорить о user expirence, а вот на стороне CI/CD – он больше не нужен. Есть более перспективные варианты, например Podman.


          1. BugM
            16.07.2023 13:57
            #25758462

            Не надо так делать. Это черевато разными тонкостями реализаций. Когда софт ведет себя не так как ожидалось. И все тратят дни и недели чтобы понять что сломалось.

            Есть стандарты - пользуйтесь ими. И купите уже Докер. Он для компании совсем недорогой.


            1. Rikimaru22 Автор
              16.07.2023 13:57
              #25758480
              -2

              Стандарты определяет Open Container Initiative. У большинства пользователей не должно возникнуть проблем с миграцией на Podman. Можно, даже использовать простой алиас «alias docker=podman» – большая часть функционала у Docker Engine CLI совподает с Podman.

              Можете покупать Docker, но для российских компаний я все же рекомендовал бы научится собирать Podman из исходников, делать пакеты RPM и DEB, и пользоваться Linux.

              Это для того, чтобы, однажды у них не отозвали оплаченные лицензии и не заблокировал учетки на GitHub, как это уже происходило не раз. :)


              1. BugM
                16.07.2023 13:57
                #25758516

                Большая часть это очень мало на самом деле. Проблемы они в последних 2 процентах всегда. И эти проблемы могут стоить много миллионов.

                Купить это лучший выбор обычно. При чем тут российские компании непонятно. Лицензия едина для всех. Ну если Докер их продавать не хочет, то другое дело. Тогда стоит подумать. И вероятно купить через прокладку. Их навалом у всех уже. А если продает купить и забыть о проблеме надолго.

                Отозвать оплаченные лицензии нельзя. Они ну просто есть.


                1. Rikimaru22 Автор
                  16.07.2023 13:57
                  #25758540
                  -3

                  Мне кажется ты совсем понимаешь суть вопроса. Компания может купить лицензии GitHub, Dockerhub и Docker, а потом в один день, по независящем от нее причинам, у этой компании отзовут лицензии и удалят репозитории с исходным кодом, который стоил миллионы.. Это вполне реальная ситуация.

                  Кстати о стандартах в IT можно сказать, что они постоянно меняются. Когда-то WebSphere и Drowizard были стандартами, а Docker непонятной новой игрушкой. Стандарты будут меняться, а вместе с ними и инструменты.  


                  1. BugM
                    16.07.2023 13:57
                    #25758546
                    +1

                    Вы точно знаете как тот же Гитхаб Энтерпрайз работает? Мне кажется что нет.

                    Большие ребята договорились и разошлись по хорошему. Никто никому ничего никогда не удаляет в корпоративной сфере. Тем более внезапно. Там большие деньги. И все в курсе что потом все снова вместе работать будут. Отношения портить не стоит. Конкуренты про все узнают и будут этим пользоваться годами. Это сильный козырь.

                    Вот как стандарт сменится тогда и приходите. Ничего не имею против новых отраслевых стандартов. Буду переходить и внедрять без всяких проблем или сопротивления. Подман сейчас заметно не тянет на отраслевой стандарт. Через годик стоит еще раз на него посмотреть. Может что и изменится.


            1. slonopotamus
              16.07.2023 13:57
              #25759250
              +3

              И купите уже Докер

              Не надо смешивать Docker и Docker Desktop. Если вам нужно первое, его можно получить миллионом способов, например через Podman Desktop.


  1. slonopotamus
    16.07.2023 13:57
    #25758348
    +14

    Что-нибудь кроме докера уже научилось билдить виндовые контейнеры? Спойлер: нет. Заголовок осуждаю.


  1. mayorovp
    16.07.2023 13:57
    #25758638
    +7

    Что-то тут мне интересно стало, а как в непривелигированном podman работают виртуальные сети?


    Как без общего реестра будет выделен новый адрес для созданного контейнера? А как создаётся сеть в подмане? Как там вообще работает DNS, резолвящий имена контейнеров? Как без прав рута пробрасывается порт?


  1. Nextusius
    16.07.2023 13:57
    #25760200

    "тут был неправильный комментарий" ))