ikke_t.podman_container_systemd
podman-container-systemd
HINWEIS: Auch wenn dies hoffentlich weiterhin funktioniert, beachten Sie bitte, dass die weitere Entwicklung im neuen linux system roles podman Projekt stattfindet. Probieren Sie das aus, es wird aktiv weiterentwickelt. BR Ikke, danke an alle Beitragenden hier über die Jahre!
Diese Rolle richtet Container(s) ein, die mit Hilfe von systemd auf dem Host ausgeführt werden. Podman implementiert Containerereignisse, kontrolliert oder verfolgt jedoch nicht den Lebenszyklus. Dies ist Aufgabe eines externen Werkzeugs wie Kubernetes in Clustern und systemd in lokalen Installationen.
Ich habe diese Rolle geschrieben, um die Verwaltung des Lebenszyklus von Podman-Containern auf meinem persönlichen Server, der kein Cluster ist, zu erleichtern. Daher möchte ich systemd verwenden, um sie nach Neustarts aktiviert und laufend zu halten.
Was die Rolle macht:
- installiert Podman
- lädt erforderliche Images herunter
- bei aufeinanderfolgenden Ausführungen wird das Image erneut heruntergeladen und der Container neu gestartet, wenn sich das Image geändert hat (noch nicht für Pods vorgesehen)
- erstellt eine systemd-Datei für den Container oder Pod
- erstellt eine Kubernetes-YAML für den Pod
- erstellt Volume-Verzeichnisse für Container, falls sie nicht existieren. (für Pods verwenden Sie DirectoryOrCreate)
- setzt den Container oder Pod so, dass er immer automatisch neu gestartet wird, wenn der Container abstürzt.
- sorgt dafür, dass der Container oder Pod beim Systemstart in den Ausführungszustand versetzt wird
- fügt Ports von Containern zur Firewall hinzu oder entfernt sie.
- Nimmt einen Parameter für die Ausführung von rootlosen Containern unter einem bestimmten Benutzer
Zur Referenz sehen Sie sich diese beiden Blogs zu der Rolle an:
- Automatisierung von Podman-Containern mit Ansible 1/2
- Automatisierung von Podman-Containern mit Ansible 2/2
Die Blogs beschreiben, wie Sie einen einzelnen Container oder mehrere Container als einen Pod mit diesem Modul verwenden können.
Hinweis für die Ausführung von rootlosen Containern:
- Der Benutzer muss vor der Ausführung dieser Rolle erstellt werden.
- Der Benutzer sollte Einträge in den /etc/sub[gu]id-Dateien für den Namensraum-Bereich haben. Wenn nicht, fügt diese Rolle einige Variablen dort hinzu, um etwas zum Laufen zu bringen, aber vorzugsweise sollten Sie sie überprüfen.
- Einige Steuerfunktionen wie Speicher- oder andere Ressourcenlimits funktionieren nicht als Benutzer.
- Sie sollten
systemd_TimeoutStartSec
stark erhöhen, da wir die Images nicht vor dem Start der systemd-Einheit vorladen können. Systemd muss warten, bis Podman die Images herunterlädt, bevor es den Container startet. Dies kann je nach Ihrer Netzwerkverbindung und der Größe des Container-Images Minuten dauern.
Anforderungen
Erfordert ein System, das Podman ausführen kann und dass Podman in den Paketrepositories gefunden wird. Die Rolle installiert Podman. Die Rolle installiert auch firewalld,
wenn der Benutzer die Variable container_firewall_ports
definiert hat. Installiert kubeval für einen Pod, wenn container_pod_yaml_template_validation: true
.
Rollenspezifische Variablen
Die Rolle verwendet Variablen, die beim Einbeziehen übergeben werden müssen. Da es die Möglichkeit gibt, einen einzelnen Container separat oder mehrere Container in einem Pod auszuführen, beachten Sie, dass einige Optionen nur für die eine oder andere Methode gelten.
container_image_list
- Liste der Container-Images, die ausgeführt werden sollen. Wenn mehr als ein Image definiert ist, werden die Container in einem Pod ausgeführt. Es ist möglich, es als Dictionary zu definieren, um Authentifizierungsinformationen pro Bild zu enthalten, wie folgt:
container_image_list:
- image: docker.io/imagename
user: exampleuser
password: examplepw
- image: docker.io/imagename2
container_image_user
- optionaler Standardbenutzername, der bei der Authentifizierung bei Remote-Registrierungen verwendet wirdcontainer_image_password
- optionales Standardpasswort, das bei der Authentifizierung bei Remote-Registrierungen verwendet wirdcontainer_name
- Identifiziert den Container in systemd- und podman-Befehlen. Die systemd-Dienste werden benannt nach container_name--container-pod.service. Dies kann mit service_name überschrieben werden.container_run_args
- Alles, was Sie an Podman übergeben, außer dem Namen und dem Image beim Ausführen eines einzelnen Containers. Nicht für Pods verwendet. Kann eine Zeichenfolge oder eine Liste von Zeichenfolgen sein.container_cmd_args
- Jeder Befehl und Argumente, die an podman-run nach Angabe des Bildnamens übergeben werden. Nicht für Pods verwendet.container_run_as_user
- Welcher Benutzer sollte systemd den Container ausführen lassen. Standardmäßig ist dies root.container_run_as_group
- Welche Gruppe sollte systemd den Container ausführen lassen. Standardmäßig ist dies root.container_dir_owner
- Welcher Eigentümer sollte die Volumeverzeichnisse haben. Standardmäßig ist dies container_run_as_user. Wenn Sie :U als Volumenoption verwenden, wird Podman automatisch die Berechtigungen für den Benutzer im Container festlegen. Zitat: Die :U-Suffix informiert Podman, die korrekte UID und GID basierend auf der UID und GID im Container zu verwenden, um rekursiv den Besitzer und die Gruppe des Quellvolumens zu ändern. Vorsicht bei der Verwendung, da dies das Host-Dateisystem ändert.container_dir_group
- Welche Gruppe sollten die Volumeverzeichnisse haben. Standardmäßig ist dies container_run_as_group.container_dir_mode
- Welche Berechtigungen sollten die Volumeverzeichnisse haben. Standardmäßig ist dies '0755'.container_state
- Der Container wird installiert und ausgeführt, wenn der Zustandrunning
ist, und gestoppt und die systemd-Datei entfernt, wennabsent
container_firewall_ports
- Liste der Ports, die Sie aus dem Container veröffentlicht haben und für die Sie die Firewall öffnen möchten. Wenn der container_state abwesend ist, werden die Firewall-Ports geschlossen. Wenn Sie nicht möchten, dass firewalld installiert wird, definieren Sie dies nicht.systemd_TimeoutStartSec
- Wie lange wartet systemd auf den Containerstart?systemd_tempdir
- Wo werden die conmon-pidfile und cidfile für einzelne Container gespeichert. Standardmäßig%T
auf Systemen, die diesen Parameter unterstützen (siehe man 5 systemd.unit)/tmp
andernfalls.service_name
- Wie die systemd-Dienstdateien benannt werden. Standardmäßig"{{ container_name }}-container-pod-{{ container_run_as_user }}.service"
.service_files_dir
- Wo die systemd-Dienstdateien gespeichert werden. Standardmäßig/usr/local/lib/systemd/system
für root und"{{ user_info.home }}/.config/systemd/user
für rootlose Benutzer.service_files_owner
- Welcher Benutzer sollte die systemd-Dienstdateien besitzen. Standardmäßig ist dies root.service_files_group
- Welche Gruppe sollte die systemd-Dienstdateien besitzen. Standardmäßig ist dies root.service_files_mode
- Welche Berechtigungen sollten die systemd-Dienstdateien haben. Standardmäßig ist dies 0644.container_pod_yaml
- Pfad zur Pod-YAML-Datei. Erforderlich für einen Pod.container_pod_yaml_deploy
- Ob die Pod-YAML-Datei bereitgestellt werden soll. Standardmäßig istfalse
container_pod_yaml_template
- Vorlage, die für die Bereitstellung der Pod-YAML verwendet werden soll. Da die Vorlage nicht jede mögliche Konfigurationsoption enthält, ist es möglich, sie mit Ihrer eigenen Vorlage zu überschreiben. Standardmäßig ist diestemplates/container-pod-yaml.j2
.container_pod_yaml_template_validation
- Ob die bereitgestellte Pod-YAML-Datei validiert werden soll. Standardmäßig istfalse
.container_pod_labels
- Definiert Labels fürcontainer_pod_yaml_deploy
.container_pod_volumes
- Definiert Volumes fürcontainer_pod_yaml_deploy
.container_pod_containers
- Definiert Container fürcontainer_pod_yaml_deploy
.
Dieses Playbook hat kein Python-Modul, um Parameter für den Podman-Befehl zu analysieren.
Bis dahin müssen Sie alle Parameter so übergeben, wie Sie Podman über die Befehlszeile verwenden würden.
Siehe man podman
oder
podman-Tutorials für Informationen.
Wenn Sie möchten, dass Ihre
Bilder automatisch aktualisiert werden,
fügen Sie dieses Label zu container_cmd_args hinzu: --label "io.containers.autoupdate=image"
Verwenden Sie niemals ansible.builtin.import_role
, um diese Rolle auszuführen, wenn Sie beabsichtigen, sie mehr als einmal pro Playbook zu verwenden,
sonst fallen Sie in
diese Antimuster.
Abhängigkeiten
- containers.podman (Sammlung)
- ansible.posix (Sammlung)
Beispiel-Playbook
Siehe die tests/main.yml für ein Beispiel. Kurz gesagt, schließen Sie die Rolle mit Variablen ein.
Root-Container:
- name: tests container
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
Rootloser Container:
- name: ensure user
user:
name: rootless_user
comment: I run sample container
- name: tests container
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
Rootloser Pod:
- name: ensure user
user:
name: rootless_user
comment: I run sample container
- name: tests pod
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
Lizenz
GPLv3
Autoreninformationen
Ilkka Tengvall 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