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:

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 wird
  • container_image_password - optionales Standardpasswort, das bei der Authentifizierung bei Remote-Registrierungen verwendet wird
  • container_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 Zustand running ist, und gestoppt und die systemd-Datei entfernt, wenn absent
  • 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 ist false
  • 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 dies templates/container-pod-yaml.j2.
  • container_pod_yaml_template_validation - Ob die bereitgestellte Pod-YAML-Datei validiert werden soll. Standardmäßig ist false.
  • container_pod_labels - Definiert Labels für container_pod_yaml_deploy.
  • container_pod_volumes - Definiert Volumes für container_pod_yaml_deploy.
  • container_pod_containers - Definiert Container für container_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

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

Über das Projekt

Role sets up container(s) to run on host with help of systemd.

Installieren
ansible-galaxy install ikke_t.podman_container_systemd
Lizenz
Unknown
Downloads
13.1k
Besitzer
I nerd around the clock. At day time for Red Hat, at evenings for my hobby projects. Except when family duties interrupt :) All for open source.