podman

Эта роль управляет конфигурацией podman, контейнерами и системными службами systemd, которые запускают контейнеры podman.

Требования

Роль требует podman версии 4.2 или более поздней. Роль требует podman версии 4.4 или более поздней для поддержки quadlet и секретов. Роль требует podman версии 4.5 или более поздней для поддержки проверки состояния (поддерживается только при использовании типов контейнеров quadlet).

Требования к коллекциям

Роль требует следующие коллекции:

• containers.podman
• fedora.linux_system_roles

Используйте это для установки коллекций:

ansible-galaxy collection install -vv -r meta/collection-requirements.yml

Пользователи, группы, subuid, subgid

Пользователи и группы, указанные в podman_run_as_user, podman_run_as_group, и указанные в спецификации kube как run_as_user и run_as_group, имеют следующие ограничения:

• Они должны уже существовать в системе — роль не создаст пользователей или группы, роль завершит работу с ошибкой, если указан несуществующий пользователь или группа.
• Они должны уже существовать в /etc/subuid и /etc/subgid, или иначе предоставляться вашей системой управления идентификацией — роль завершит работу с ошибкой, если указанный пользователь не присутствует в /etc/subuid, или если указанная группа отсутствует в /etc/subgid. Роль использует getsubids, чтобы проверить пользователя и группу, если это возможно, или проверяет файлы напрямую, если getsubids недоступен.

Переменные роли

podman_kube_specs

Это список. Каждый элемент списка — это словарь, описывающий podman pod и соответствующий системный юнит для управления. Формат словаря в основном похож на podman_play модуль, за исключением следующего:

• state — по умолчанию created. Это принимает 3 значения:
  • started — Создайте поды и системные службы и запустите их.
  • created — Создайте поды и системные службы, но не запускайте их.
  • absent — Удалите поды и системные службы.
• run_as_user — Используйте это, чтобы указать пользователя для каждого пода. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_run_as_user. В противном случае будет использоваться root. ПРИМЕЧАНИЕ: Пользователь должен уже существовать — роль не создаст его. Пользователь должен присутствовать в /etc/subuid.
• run_as_group — Используйте это, чтобы указать группу для каждого пода. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_run_as_group. В противном случае будет использоваться root. ПРИМЕЧАНИЕ: Группа должна уже существовать — роль не создаст ее. Группа должна быть в /etc/subgid.
• systemd_unit_scope — Область, которую следует использовать для системного юнита. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_systemd_unit_scope. В противном случае область будет system для контейнеров root и user для пользовательских контейнеров.
• activate_systemd_unit — Необходимо ли активировать системный юнит, когда он создан. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_activate_systemd_unit, которое по умолчанию равно true.
• pull_image — Убедитесь, что образ загружен перед использованием. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_pull_image, которое по умолчанию равно true.
• continue_if_pull_fails — Если загрузка изображения не удалась, не считайте это фатальной ошибкой и продолжайте выполнение роли. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_continue_if_pull_fails, которое по умолчанию равно false.
• kube_file_src — Это имя файла на контроллере, который будет скопирован в kube_file на управляемом узле. Это файл в формате YAML Kubernetes. Не указывайте это, если указываете kube_file_content. kube_file_content имеет приоритет над kube_file_src.
• kube_file_content — Это либо строка в формате YAML Kubernetes, либо словарь в формате YAML Kubernetes. Он будет использоваться как содержимое kube_file на управляемом узле. Не указывайте это, если указываете kube_file_src. kube_file_content имеет приоритет над kube_file_src.
• kube_file — Это имя файла на управляемом узле, который содержит спецификацию Kubernetes контейнера/pod. Обычно вам не нужно указывать это, если вам не нужно каким-либо образом копировать этот файл на управляемый узел вне роли. Если вы указываете kube_file_src или kube_file_content, указывать это не нужно. Рекомендуется опустить kube_file и вместо этого указать либо kube_file_src, либо kube_file_content и позволить роли управлять путем и именем файла.
• Проверка базового имени файла будет равняться значению metadata.name из K8s yaml, к которому будет добавлен суффикс .yml.
• Директория будет /etc/containers/ansible-kubernetes.d для системных служб.
• Директория будет $HOME/.config/containers/ansible-kubernetes.d для пользовательских служб.

Например, если у вас есть

podman_kube_specs:
  - state: started
    kube_file_content:
      apiVersion: v1
      kind: Pod
      metadata:
        name: myappname

Это будет скопировано в файл /etc/containers/ansible-kubernetes.d/myappname.yml на управляемом узле.

podman_quadlet_specs

Список [спецификаций Quadlet] (https://docs.podman.io/en/latest/markdown/podman-systemd.unit.5.html) Спецификация quadlet уникально определяется именем и типом, где тип — это один из типов юнитов, таких как контейнер, kube, сеть, том и т.д. Вы можете либо передать name и type явно, либо name и type будут производиться из имени файла, данного в file, file_src или template_src.

По умолчанию файлы будут скопированы в или созданы в /etc/containers/systemd/$name.$type для корневых контейнеров и $HOME/.config/containers/systemd/$name.$type для контейнеров без корня на управляемом узле. Вы можете предоставить другое расположение, используя file, но тогда вам, вероятно, придется изменить конфигурацию systemd, чтобы найти файл, что не поддерживается этой ролью.

Когда спецификация quadlet зависит от какого-либо другого файла, например, quadlet.kube, который зависит от файла Yaml или ConfigMap, тогда этот файл должен быть указан в списке podman_quadlet_specs до файла, который его использует. Например, если у вас есть файл my-app.kube:

[Kube]
ConfigMap=my-app-config.yml
Yaml=my-app.yml
...

То вы должны сначала указать my-app-config.yml и my-app.yml перед my-app.kube:

podman_quadlet_specs:
  - file_src: my-app-config.yml
  - file_src: my-app.yml
  - file_src: my-app.kube

Большинство параметров для каждой спецификации quadlet аналогичны параметрам podman_kube_spec выше, за исключением того, что параметры *kube* не поддерживаются, и следующие поддерживаются:

• name — Имя единицы. Если не указано, оно будет производиться из file, file_src или template_src. Например, если вы укажете file_src: /path/to/my-container.container, то name будет my-container.
• type — Тип единицы (контейнер, kube, том и т.д.). Если не указано, оно будет производиться из file, file_src или template_src. Например, если вы укажете file_src: /path/to/my-container.container, то type будет container. Если производимый тип не распознается как допустимый тип quadlet, например, если вы укажете file_src: my-kube.yml, то он просто будет скопирован и не обработан как спецификация quadlet.
• file_src — Имя файла на узле управления, который будет скопирован на управляемый узел для использования в качестве источника юнита quadlet. Если этот файл находится в формате юнита quadlet и имеет допустимый суффикс юнита quadlet, он будет использоваться как юнит quadlet, в противном случае он просто будет скопирован.
• file — Имя файла на управляемом узле, который будет использоваться в качестве источника юнита quadlet. Если этот файл находится в формате юнита quadlet и имеет допустимый суффикс юнита quadlet, он будет использоваться как юнит quadlet, в противном случае он будет трактоваться как обычный файл.
• file_content — Содержимое файла, который будет скопирован на управляемый узел в строковом формате. Это полезно для передачи коротких файлов, которые можно легко указать в строковом формате. Вы также должны указать name и type.
• template_src — Имя файла на узле управления, который будет обработан как шаблон Jinja, а затем скопирован на управляемый узел для использования в качестве источника юнита quadlet. Если этот файл находится в формате юнита quadlet и имеет допустимый суффикс юнита quadlet, он будет использоваться как юнит quadlet, в противном случае он просто будет скопирован. Если файл имеет суффикс .j2, этот суффикс будет удален для определения типа файла quadlet.

Например, если вы укажете:

podman_quadlet_specs:
  - template_src: my-app.container.j2

Тогда локальный файл templates/my-app.container.j2 будет обработан как файл шаблона Jinja, затем скопирован в /etc/containers/systemd/my-app.container как спецификация юнита контейнера quadlet на управляемом узле.

ПРИМЕЧАНИЕ: При удалении quadlet необходимо удалять сети последними. Вы не можете удалить сеть, которая используется контейнером.

podman_secrets

Это список спецификаций секретов в почти том же формате, который используется в podman_secret. Есть дополнительное поле:

• run_as_user — Используйте это, чтобы указать секрет для определенного пользователя. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_run_as_user. В противном случае будет использоваться root. ПРИМЕЧАНИЕ: Пользователь должен уже существовать — роль не создаст его.

Рекомендуется использовать Ansible Vault для шифрования значения поля data.

podman_create_host_directories

Это логическое значение, значение по умолчанию — false. Если true, роль обеспечит создание директорий хоста, указанных в монтировании хоста в спецификациях volumes.hostPath в YAML Kubernetes, и из конфигурации тома в спецификации контейнера quadlet, где указан путь хоста. ПРИМЕЧАНИЕ: Директории должны указываться как абсолютные пути (для корневых контейнеров) или пути относительно домашней директории (для контейнеров без корня), чтобы роль могла ими управлять. Все остальное будет считаться каким-либо другим типом тома и будет проигнорировано. Роль применит свои значения по умолчанию для прав собственности/доступа к директориям. Если вам нужно установить права собственности/доступ, смотрите podman_host_directories.

podman_host_directories

Это словарь. При использовании podman_create_host_directories это указывает роли, какие права доступа/собственность применить к автоматически созданным директориям хоста. Каждый ключ — это абсолютный путь директории хоста для управления. Значение находится в формате параметров для file модуля. Если вы не укажете значение, роль будет использовать свои встроенные значения по умолчанию. Если вы хотите указать значение, которое будет использоваться для всех директорий хоста, используйте специальный ключ DEFAULT.

podman_host_directories:
  "/var/lib/data":
    owner: dbuser
    group: dbgroup
    mode: "0600"
  DEFAULT:
    owner: root
    group: root
    mode: "0644"

Роль будет использовать dbuser:dbgroup 0600 для /var/lib/data, и root:root 0644 для всех других директорий хоста, созданных ролью.

podman_firewall

Это список словарей в том же формате, что используется ролью fedora.linux_system_roles.firewall. Используйте это, чтобы указать порты, которые вы хотите, чтобы роль управляла в брандмауэре.

podman_firewall:
  - port: 8080/tcp

podman_selinux_ports

Это список словарей в том же формате, что используется ролью fedora.linux_system_roles.selinux. Используйте это, если вы хотите, чтобы роль управляла политикой SELinux для портов, используемых этой ролью.

podman_selinux_ports:
  - ports: 8080
    protocol: tcp
    setype: http_port_t

podman_run_as_user

Это имя пользователя, которое будет использоваться для всех контейнеров без корня. Вы также можете указать имя пользователя для каждого контейнера с помощью run_as_user в podman_kube_specs. ПРИМЕЧАНИЕ: Пользователь должен уже существовать — роль не создаст его. Пользователь должен быть в /etc/subuid.

podman_run_as_group

Это имя группы, которое будет использоваться для всех контейнеров без корня. Вы также можете указать имя группы для каждого контейнера с помощью run_as_group в podman_kube_specs. ПРИМЕЧАНИЕ: Группа должна уже существовать — роль не создаст ее. Группа должна быть в /etc/subgid.

podman_systemd_unit_scope

Это область systemd, которая используется по умолчанию для всех системных юнитов. Вы также можете указать область для каждого контейнера с помощью systemd_unit_scope в podman_kube_specs. По умолчанию контейнеры без корня будут использовать user, а корневые контейнеры будут использовать system.

podman_activate_systemd_units

Активирует каждый системный юнит сразу после его создания. Значение по умолчанию — true. Вы также можете сделать это для каждого юнита, используя activate_systemd_units в спецификации для каждого юнита. Например, если вы развертываете несколько спецификаций и хотите, чтобы только последняя в списке активировалась, что приведет к активации других за счет зависимостей, тогда установите activate_systemd_unit: false для каждой, кроме последней, которая использует activate_systemd_unit: true. ПРИМЕЧАНИЕ: юниты quadlet по умолчанию активируются при создании — вы не можете в настоящее время использовать activate_systemd_unit, чтобы отключить эти юниты — вы можете использовать activate_systemd_unit, чтобы создать юниты остановленными или запущенными.

podman_pull_image

Убедитесь, что каждый образ, упомянутый в спецификации kube или quadlet, присутствует, загружая образ перед его использованием. Значение по умолчанию — true. Используйте false, если управляемый узел уже имеет правильную версию или не может загрузить изображения. Вы также можете указать это для каждого юнита с помощью pull_image.

podman_continue_if_pull_fails

Если попытка загрузки изображения завершается неудачей, не считайте это фатальной ошибкой и продолжайте выполнение роли. Значение по умолчанию — false — неудача попытки загрузки является фатальной ошибкой. Вы можете установить это для каждого юнита с помощью continue_if_pull_fails.

podman_containers_conf

Это настройки containers.conf(5), предоставленные в словаре. Эти настройки будут предоставлены в файле drop-in в директории containers.conf.d. Если запускается от имени root (см. podman_run_as_user), будут управляться системные настройки, в противном случае будут управляться пользовательские настройки. Смотрите man-страницу для местоположений директории.

podman_containers_conf:
  containers:
    default_sysctls:
      - net.ipv4.ping_group_range=0 1000
      - user.max_ipc_namespaces=125052

podman_registries_conf

Это настройки containers-registries.conf(5), предоставленные в словаре. Эти настройки будут предоставлены в файле drop-in в директории registries.conf.d. Если запускается от имени root (см. podman_run_as_user), будут управляться системные настройки, в противном случае будут управляться пользовательские настройки. Смотрите man-страницу для местоположений файлов.

podman_registries_conf:
  aliases:
    myregistry: registry.example.com

podman_storage_conf

Это настройки containers-storage.conf(5), предоставленные в словаре. Если запускается от имени root (см. podman_run_as_user), будут управляться системные настройки, в противном случае будут управляться пользовательские настройки. Смотрите man-страницу для местоположений файлов.

podman_storage_conf:
  storage:
    runroot: /var/big/partition/container/storage

podman_policy_json

Это настройки containers-policy.json(5), предоставленные в словаре. Если запускается от имени root (см. podman_run_as_user), будут управляться системные настройки, в противном случае будут управляться пользовательские настройки. Смотрите man-страницу для местоположений файлов.

podman_policy_json:
  default:
    type: insecureAcceptAnything

podman_use_copr (ЭКСПЕРИМЕНТАЛЬНО)

Логическое значение - по умолчанию не установлено - если вы хотите включить репозиторий copr для использования последней версии разработки podman, используйте podman_use_copr: true.

podman_fail_if_too_old (ЭКСПЕРИМЕНТАЛЬНО)

Логическое значение - по умолчанию не установлено - по умолчанию роль завершит работу с ошибкой, если вы используете более старую версию podman и пытаетесь использовать функцию, поддерживаемую только более новой версией. Например, если вы попытаетесь управлять quadlet или секретами с podman 4.3 или более ранней версии, роль завершится с ошибкой. Если вы хотите, чтобы роль была пропущена вместо этого, используйте podman_fail_if_too_old: false.

podman_registry_username

Строка - по умолчанию не установлена - имя пользователя, которое будет использоваться для аутентификации в реестре. Вам также нужно установить podman_registry_password. Вы можете переопределить это для каждого спецификации с помощью registry_username. Использование container_image_user было неподдерживаемым и устарело.

podman_registry_password

Строка - по умолчанию не установлена - пароль, который будет использоваться для аутентификации в реестре. Вам также нужно установить podman_registry_username. Вы можете переопределить это для каждого спецификации с помощью registry_password. Использование container_image_password было неподдерживаемым и устарело.

podman_credential_files

Это список. Каждый элемент списка — это словарь, описывающий файл учетных данных podman, используемый для аутентификации в реестрах. См. man containers-auth.json и man containers-registries.conf: credential-helpers для получения дополнительной информации о формате этих файлов и пути поиска по умолчанию.
ПРИМЕЧАНИЕ: Эти файлы содержат учетные данные аутентификации. Пожалуйста, будьте осторожны с ними. Рекомендуется использовать Ansible Vault для их шифрования.
Ключи каждого словаря следующие:

• state — по умолчанию present. Используйте absent, чтобы удалить файлы.
• file_src — Это имя файла на узле управления, который будет скопирован в file на управляемом узле. Не указывайте это, если указываете file_content или template_src, которые имеют приоритет над file_src.
• template_src — Это имя файла на узле управления, который будет отформатирован с помощью модуля шаблон и скопирован в file на управляемом узле. Не указывайте это, если указываете file_content или file_src.
• file_content — Это строка в формате containers-auth.json. Она будет использована как содержимое file на управляемом узле. Не указывайте это, если указываете file_src или template_src.
• file — Это имя файла на управляемом узле, который будет содержать данные auth.json. Значение по умолчанию будет $HOME/.config/containers/auth.json. Если вы укажете относительный путь, он будет относиться к $HOME/.config/containers. Если вы укажете что-то другое, кроме значений по умолчанию, упомянутых в man containers-auth.json, вам также нужно будет настроить credential-helpers в containers-registries.conf, используя podman_registries_conf. Все недостающие родительские директории будут созданы.
• run_as_user — Используйте это, чтобы указать владельца файла для конкретного файла учетных данных. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_run_as_user. В противном случае будет использоваться root. ПРИМЕЧАНИЕ: Пользователь должен уже существовать — роль не создаст его. Пользователь должен быть в /etc/subuid. ПРИМЕЧАНИЕ: Это используется как пользователь для директории $HOME, если file не указано, и как владелец файла. Если вы хотите, чтобы владелец файла отличался от пользователя для $HOME, укажите file как абсолютный путь.
• run_as_group — Используйте это, чтобы указать группу владельца файла для конкретного файла учетных данных. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_run_as_group. В противном случае будет использоваться root. ПРИМЕЧАНИЕ: Группа должна уже существовать — роль не создаст ее. Группа должна быть в /etc/subgid.
• mode — Режим файла — значение по умолчанию "0600".

Например, если у вас есть

podman_credential_files:
  - file_src: auth.json
    run_as_user: my_user

Локальный файл auth.json будет найден в обычных путях поиска файлов Ansible и будет скопирован в файл /home/my_user/.config/containers/auth.json на управляемом узле. Владелец файла будет my_user, а режим будет "0600". Директории /home/my_user/.config и /home/my_user/.config/containers будут созданы, если они не существуют.

podman_registry_certificates

Эта переменная является списком словарей, который позволяет управлять TLS сертификатами и ключами, используемыми для подключения к реестрам. Директории, форматы и файлы описаны в man containers-certs.d. Имена ключей, используемых для TLS сертификатов и ключей, следуют конвенциям именования TLS системных ролей. ПРИМЕЧАНИЕ: префикс client_ был убран здесь для cert и private_key, потому что в этом контексте только клиенты.

ПРИМЕЧАНИЕ: Настоятельно рекомендуется использовать Ansible Vault для шифрования частных ключей и любых других конфиденциальных значений.

Ключи каждого словаря следующие:

• state — по умолчанию present. Используйте absent, чтобы удалить файлы.
• run_as_user — Это пользователь, который будет владельцем файлов и используется для поиска директории $HOME для файлов. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_run_as_user. В противном случае будет использоваться root.
• run_as_group — Это группа, которая будет владельцем файлов. Если вы не укажете это, будет использовано глобальное значение по умолчанию podman_run_as_group. В противном случае будет использоваться root.
• registry_host — Обязательное поле — имя хоста или hostname:port реестра. Это будет использоваться как имя директории в $HOME/.config/containers/certs.d (для контейнеров без корня) или /etc/containers/certs.d (для системных контейнеров), где будут храниться сертификаты и ключи. Если использовать state: absent и все файлы будут удалены, директория будет удалена.
• cert — имя файла в директории certs.d, содержащего TLS клиентский сертификат. Если не указано, используется базовое имя cert_src. Если это не указано, используется client.cert.
• private_key — имя файла в директории certs.d, содержащего частный TLS ключ клиента. Если не указано, используется базовое имя private_key_src. Если это не указано, используется client.key.
• ca_cert — имя файла в директории certs.d, содержащего CA сертификат TLS. Если не указано, используется базовое имя ca_cert_src. Если это не указано, используется ca.crt.
• cert_src — имя файла на узле управления, который будет скопирован в cert.
• private_key_src — имя файла на узле управления, который будет скопирован в private_key.
• ca_cert_src — имя файла на узле управления, который будет скопирован в ca_cert.
• cert_content — содержимое сертификата, которое будет скопировано в cert.
• private_key_content — содержимое частного ключа, которое будет скопировано в private_key.

podman_run_as_user: root
podman_registry_certificates:
  - registry_host: quay.io:5000
    cert_src: client.cert
    private_key_content: !vault |
      $ANSIBLE_VAULT.....
    ca_cert_src: ca.crt

Это создаст директорию /etc/containers/certs.d/quay.io:5000/, скопирует локальный файл client.cert, найденный по обычным путям поиска файлов Ansible, в /etc/containers/certs.d/quay.io:5000/client.cert, скопирует содержимое зашифрованного Ansible Vault private_key_content в /etc/containers/certs.d/quay.io:5000/client.key, и скопирует локальный файл ca.crt, найденный по обычным путям поиска файлов Ansible, в /etc/containers/certs.d/quay.io:5000/ca.crt.

podman_validate_certs

Логическое значение — по умолчанию null — используйте это, чтобы контролировать, будет ли проверка TLS сертификатов при загрузке изображений из реестров. Значение по умолчанию null означает использование того, что является стандартным для модуля containers.podman.podman_image. Вы можете переопределить это для каждой спецификации, используя validate_certs.

podman_prune_images

Логическое значение - по умолчанию false - по умолчанию роль не будет очищать неиспользуемые образы при удалении quadlet и других ресурсов. Установите это значение в true, чтобы сказать роли удалить неиспользуемые образы при очистке.

podman_transactional_update_reboot_ok

Эта переменная применима только для систем обновлений с транзакционной обработкой. Если транзакционное обновление требует перезагрузки, роль продолжит выполнение перезагрузки, если podman_transactional_update_reboot_ok установлено на true. Если установлено на false, роль уведомит пользователя о том, что требуется перезагрузка, что позволяет выполнить индивидуальную обработку требования о перезагрузке. Если эта переменная не установлена, роль завершится с ошибкой, чтобы гарантировать, что требование о перезагрузке не будет упущено. Для систем обновлений без транзакционной обработки эта переменная игнорируется.

Переменные, экспортированные ролью

podman_version

Это строка версии используемой версии podman. Вы можете использовать это в своих шаблонах. Например, если вы хотите указать template_src quadlet для контейнера и использовать проверки состояния и секреты, если используется podman 4.5 или более поздней версии:

podman_quadlet_specs:
  - template_src: my-app.container.j2
podman_secrets:
  - name: my-app-pwd
    data: .....

my-app.container.j2:

[Container]
{% if podman_version is version("4.5", ">=") %}
Secret=my-app-pwd,type=env,target=MYAPP_PASSWORD
HealthCmd=/usr/bin/test -f /path/to/my-app.file
HealthOnFailure=kill
{% else %}
PodmanArgs=--secret=my-app-pwd,type=env,target=MYAPP_PASSWORD
{% endif %}

podman_subuid_info, podman_subgid_info

Роль должна обеспечить наличие любых пользователей и групп в информации subuid и subgid. После извлечения этих данных они будут доступны в podman_subuid_info и podman_subgid_info. Это словари. Ключ — это имя пользователя или группы, а значение — это словарь с двумя полями:

• start — начало диапазона идентификаторов для этого пользователя или группы, как int
• range — диапазон идентификаторов для этого пользователя или группы, как int

podman_host_directories:
  "/var/lib/db":
    mode: "0777"
    owner: "{{ 1001 + podman_subuid_info['dbuser']['start'] - 1 }}"
    group: "{{ 1001 + podman_subgid_info['dbgroup']['start'] - 1 }}"

Где 1001 — это uid для пользователя dbuser, а 1001 — это gid для группы dbgroup.

ПРИМЕЧАНИЕ: в зависимости от пространства имен, используемого вашими контейнерами, вы можете не иметь возможности использовать информацию subuid и subgid, которая извлекается с помощью getsubids, если это возможно, или напрямую из файлов /etc/subuid и /etc/subgid на хосте. Смотрите режимы пространств имен пользователя podman для получения дополнительной информации.

Примеры плейбуков

Создание контейнера без корня с монтированием тома:

- name: Управление контейнерами podman и службами
  hosts: все
  vars:
    podman_create_host_directories: true
    podman_firewall:
      - port: 8080-8081/tcp
        state: enabled
      - port: 12340/tcp
        state: enabled
    podman_selinux_ports:
      - ports: 8080-8081
        setype: http_port_t
    podman_kube_specs:
      - state: started
        run_as_user: dbuser
        run_as_group: dbgroup
        kube_file_content:
          apiVersion: v1
          kind: Pod
          metadata:
            name: db
          spec:
            containers:
              - name: db
                image: quay.io/db/db:stable
                ports:
                  - containerPort: 1234
                    hostPort: 12340
                volumeMounts:
                  - mountPath: /var/lib/db:Z
                    name: db
            volumes:
              - name: db
                hostPath:
                  path: /var/lib/db
      - state: started
        run_as_user: webapp
        run_as_group: webapp
        kube_file_src: /path/to/webapp.yml
  roles:
    - linux-system-roles.podman

Создание контейнера, работающего от имени root, с томом Podman:

- name: Управление корневыми контейнерами podman и службами
  hosts: все
  vars:
    podman_firewall:
      - port: 8080/tcp
        state: enabled
    podman_kube_specs:
      - state: started
        kube_file_content:
          apiVersion: v1
          kind: Pod
          metadata:
            name: ubi8-httpd
          spec:
            containers:
              - name: ubi8-httpd
                image: registry.access.redhat.com/ubi8/httpd-24
                ports:
                  - containerPort: 8080
                    hostPort: 8080
                volumeMounts:
                  - mountPath: /var/www/html:Z
                    name: ubi8-html
            volumes:
              - name: ubi8-html
                persistentVolumeClaim:
                  claimName: ubi8-html-volume
  roles:
    - linux-system-roles.podman

Создание приложения quadlet с секретами. Ожидайте начала приложения до тех пор, пока все юниты не будут созданы. Обратите внимание, что порядок файлов в podman_quadlet_specs соответствует порядку зависимостей. Использование podman_create_host_directories: true создаст любые директории хоста, смонтированные в спецификации контейнера, указанные в директиве Volume=.

podman_create_host_directories: true
podman_activate_systemd_unit: false
podman_quadlet_specs:
  - name: quadlet-demo
    type: network
    file_content: |
      [Network]
      Subnet=192.168.30.0/24
      Gateway=192.168.30.1
      Label=app=wordpress
  - file_src: quadlet-demo-mysql.volume
  - template_src: quadlet-demo-mysql.container.j2
  - file_src: envoy-proxy-configmap.yml
  - file_src: quadlet-demo.yml
  - file_src: quadlet-demo.kube
    activate_systemd_unit: true
podman_firewall:
  - port: 8000/tcp
    state: enabled
  - port: 9000/tcp
    state: enabled
podman_secrets:
  - name: mysql-root-password-container
    state: present
    skip_existing: true
    data: "{{ root_password_from_vault }}"
  - name: mysql-root-password-kube
    state: present
    skip_existing: true
    data: |
      apiVersion: v1
      data:
        password: "{{ root_password_from_vault | b64encode }}"
      kind: Secret
      metadata:
        name: mysql-root-password-kube
  - name: envoy-certificates
    state: present
    skip_existing: true
    data: |
      apiVersion: v1
      data:
        certificate.key: {{ key_from_vault | b64encode }}
        certificate.pem: {{ cert_from_vault | b64encode }}
      kind: Secret
      metadata:
        name: envoy-certificates

Лицензия

MIT.

Информация об авторе

На основе podman-container-systemd Илькки Тенгвалла ilkka.tengvall@iki.fi.

Авторы: Том Карлин, Рич Меггинсон, Адам Миллер, Валентин Ротберг