podman_container_systemd
podman-container-systemd
ПРИМЕЧАНИЕ: Хотя это, надеюсь, все еще работает, обратите внимание, что дальнейшая разработка проходит в новом проекте podman для системных ролей Linux. Попробуйте его, он находится в активной разработке. Спасибо всем участникам на протяжении многих лет!
Роль настраивает контейнер(ы) для запуска на хосте с помощью systemd. Podman реализует события контейнеров, но не контролирует их жизненный цикл. Это задача внешнего инструмента, такого как Kubernetes в кластерах и systemd в локальных установках.
Я написал эту роль, чтобы помочь управлять жизненным циклом контейнеров podman на моем личном сервере, который не является кластером. Поэтому я хочу использовать systemd, чтобы они оставались включенными и работали после перезагрузки.
Что делает роль:
- устанавливает Podman
- загружает необходимые образы
- при последовательных запусках снова загружает образ и перезапускает контейнер, если образ изменился (пока не для пода)
- создает файл systemd для контейнера или пода
- создает файл yaml для kubernetes для пода
- создает каталоги для томов контейнеров, если они не существуют. (для пода используйте DirectoryOrCreate)
- устанавливает контейнер или под для автоматического перезапуска, если контейнер остановился.
- заставляет контейнер или под запускаться при загрузке системы
- добавляет или удаляет открытые порты контейнеров в фаерволе.
- Принимает параметр для запуска контейнеров без прав суперпользователя от заданного пользователя
Для справки смотрите эти два блога о роли:
Блоги описывают, как можно использовать один контейнер или несколько контейнеров как один под, используя этот модуль.
Примечание для запуска контейнеров без прав суперпользователя:
- Вы должны создать пользователя перед запуском этой роли.
- У пользователя должны быть записи в файлах /etc/sub[gu]id для диапазона пространств имен. Если нет, эта роль добавит некоторые переменные для начала работы, но лучше всего, если вы их проверите.
- Некоторые контрольные параметры, такие как память или другие лимиты ресурсов, не будут работать для пользователя.
- Вам нужно сильно увеличить
systemd_TimeoutStartSec
, так как мы не можем предварительно загрузить образы перед запуском юнита systemd. Поэтому systemd нужно подождать, пока podman загрузит образы перед тем, как запустить контейнер. Это может занять минуты в зависимости от вашего интернет-соединения и размера образа контейнера.
Требования
Требуется система, способная запускать podman, и чтобы podman находился в репозиториях пакетов. Роль устанавливает podman. Роль также устанавливает firewalld, если пользователь определил переменную container_firewall_ports
. Устанавливает kubeval для пода, если container_pod_yaml_template_validation: true
.
Переменные роли
Роль использует переменные, которые необходимо передать при ее подключении. Поскольку есть возможность запускать один контейнер отдельно или несколько контейнеров в поде, обратите внимание, что некоторые параметры применимы только для другого метода.
container_image_list
- список образов контейнеров для запуска. Если определено более одного образа, контейнеры будут запущены в поде. Можно определить как словарь для включения информации об аутентификации на образ, например:
container_image_list:
- image: docker.io/imagename
user: exampleuser
password: examplepw
- image: docker.io/imagename2
container_image_user
- необязательное имя пользователя по умолчанию для использования при аутентификации на удаленных регистрахcontainer_image_password
- необязательный пароль по умолчанию для использования при аутентификации на удаленных регистрахcontainer_name
- идентифицирует контейнер в командах systemd и podman. Файл службы systemd будет называться container_name--container-pod.service. Это можно перезаписать с помощью service_name.container_run_args
- все, что вы передаете podman, кроме имени и образа при запуске одного контейнера. Не используется для пода. Может быть строкой или списком строк.container_cmd_args
- любые команды и аргументы, переданные podman-run после указания имени образа. Не используется для пода.container_run_as_user
- под каким пользователем systemd должен запускать контейнер. По умолчанию root.container_run_as_group
- в какой группе systemd должен запускать контейнер. По умолчанию root.container_dir_owner
- какой владелец должен быть у директорий томов. По умолчанию container_run_as_user. Если вы используете :U в качестве опции тома, podman автоматически установит права для пользователя внутри контейнера. Цитата: Суффикс :U указывает Podman использовать правильный UID и GID хоста на основе UID и GID внутри контейнера для рекурсивного изменения владельца и группы исходного тома. Предупреждение: используйте с осторожностью, так как это изменит файловую систему хоста.container_dir_group
- какая группа должна быть у директорий томов. По умолчанию container_run_as_group.container_dir_mode
- какие разрешения должны быть у директорий томов. По умолчанию '0755'.container_state
- контейнер установлен и работает, если состояниеrunning
, и остановлен, а файл systemd удален, еслиabsent
container_firewall_ports
- список портов, которые вы открыли из контейнера и хотите открыть в фаерволе. Когда состояние контейнера отсутствует, порты фаервола закрываются. Если вы не хотите устанавливать firewalld, не определяйте это.systemd_TimeoutStartSec
- как долго systemd ждет запуска контейнера?systemd_tempdir
- где хранить conmon-pidfile и cidfile для отдельных контейнеров. По умолчанию%T
на системах, поддерживающих этот спецификатор (см. man 5 systemd.unit) или/tmp
в противном случае.service_name
- как называются файлы службы systemd. По умолчанию"{{ container_name }}-container-pod-{{ container_run_as_user }}.service"
.service_files_dir
- где хранить файлы службы systemd. По умолчанию/usr/local/lib/systemd/system
для root и"{{ user_info.home }}/.config/systemd/user
для пользователя без прав суперпользователя.service_files_owner
- какой пользователь должен владеть файлами службы systemd. По умолчанию root.service_files_group
- какая группа должна владеть файлами службы systemd. По умолчанию root.service_files_mode
- какие разрешения должны иметь файлы службы systemd. По умолчанию 0644.container_pod_yaml
- путь к yaml-файлу пода. Обязателен для пода.container_pod_yaml_deploy
- нужно ли развертывать yaml-файл пода. По умолчаниюfalse
.container_pod_yaml_template
- шаблон для развертывания yaml-файла пода. Поскольку шаблон не включает все возможные параметры конфигурации, вы можете перезаписать его своим шаблоном. По умолчаниюtemplates/container-pod-yaml.j2
.container_pod_yaml_template_validation
- нужно ли проверять развернутый yaml-файл пода. По умолчаниюfalse
.container_pod_labels
- определяет метки дляcontainer_pod_yaml_deploy
.container_pod_volumes
- определяет тома дляcontainer_pod_yaml_deploy
.container_pod_containers
- определяет контейнеры дляcontainer_pod_yaml_deploy
.
Этот плейбук не имеет модуля Python для разбора параметров для команды podman. До этого момента вам просто нужно передать все параметры так, как вы бы использовали podman из командной строки. Смотрите man podman
или уроки podman для получения информации.
Если вы хотите, чтобы ваши образы автоматически обновлялись, добавьте эту метку к container_cmd_args: --label "io.containers.autoupdate=image"
Никогда не используйте ansible.builtin.import_role
, чтобы выполнить эту роль, если вы намерены использовать ее более одного раза за плейбук, иначе вы попадете в этот антипаттерн.
Зависимости
- containers.podman (коллекция)
- ansible.posix (коллекция)
Пример плейбука
Смотрите tests/main.yml для примера. Короче говоря, подключите роль с переменными.
Контейнер root:
- name: тестовый контейнер
vars:
container_image_list:
- sebp/lighttpd:latest
container_name: lighttpd
container_run_args: >-
--rm
-v /tmp/podman-container-systemd:/var/www/localhost/htdocs:Z,U
--label "io.containers.autoupdate=image"
-p 8080:80
#container_state: absent
container_state: running
container_firewall_ports:
- 8080/tcp
- 8443/tcp
ansible.builtin.include_role:
name: podman-container-systemd
Контейнер без прав суперпользователя:
- name: убедиться в существовании пользователя
user:
name: rootless_user
comment: Я запускаю пример контейнера
- name: тестовый контейнер
vars:
container_run_as_user: rootless_user
container_run_as_group: rootless_user
container_image_list:
- sebp/lighttpd:latest
container_name: lighttpd
container_run_args: >-
--rm
-v /tmp/podman-container-systemd:/var/www/localhost/htdocs:Z,U
-p 8080:80
#container_state: absent
container_state: running
container_firewall_ports:
- 8080/tcp
- 8443/tcp
ansible.builtin.include_role:
name: podman-container-systemd
Под без прав суперпользователя:
- name: убедиться в существовании пользователя
user:
name: rootless_user
comment: Я запускаю пример контейнера
- name: тестовый под
vars:
container_run_as_user: rootless_user
container_run_as_group: rootless_user
container_image_list:
- sebp/lighttpd:latest
container_name: lighttpd-pod
container_pod_yaml: /home/rootless_user/lighttpd-pod.yml
container_pod_yaml_deploy: true
container_pod_yaml_template_validation: true
container_pod_labels:
app: "{{ container_name }}"
io.containers.autoupdate: 'image(1)'
container_pod_volumes:
- name: htdocs
hostPath:
path: /tmp/podman-container-systemd
type: DirectoryOrCreate
container_pod_containers:
- name: lighttpd
image: sebp/lighttpd:latest
volumeMounts:
- name: htdocs
mountPath: /var/www/localhost/htdocs:Z
ports:
- containerPort: 80
hostPort: 8080
container_state: running
container_firewall_ports:
- 8080/tcp
- 8443/tcp
ansible.builtin.include_role:
name: podman-container-systemd
Лицензия
GPLv3
Авторская информация
Илкка Тенгвалл ilkka.tengvall@iki.fi
Role sets up container(s) to run on host with help of systemd.
ansible-galaxy install ikke-t/podman-container-systemd