ikke_t.podman_container_systemd

podman-container-systemd

UWAGA: Choć to mam nadzieję nadal działa, należy zauważyć, że dalszy rozwój odbywa się w nowym projekcie linux system roles podman. Spróbuj tego, jest w aktywnym rozwoju. Dziękuję wszystkim wkładom tutaj przez lata!

Rola ustawia kontenery do uruchomienia na hoście z pomocą systemd. Podman implementuje zdarzenia kontenerów, ale nie kontroluje ani nie śledzi cyklu życia. To zadanie narzędzi zewnętrznych, takich jak Kubernetes w klastrach oraz systemd w lokalnych instalacjach.

Napisałem tę rolę, aby pomóc w zarządzaniu cyklem życia kontenerów podman na moim osobistym serwerze, który nie jest klastrem. Dlatego chcę używać systemd, aby utrzymać je włączone i działające po restarcie.

Co robi rola:

instaluje Podman
pobiera wymagane obrazy
przy kolejnych uruchomieniach ponownie pobiera obraz i restartuje kontener, jeśli obraz się zmienił (jeszcze nie dla podów)
tworzy plik systemd dla kontenera lub poda
tworzy plik yaml kubernetes dla poda
tworzy katalogi wolumenów dla kontenerów, jeśli nie istnieją. (dla podu użyj DirectoryOrCreate)
ustawia kontener lub pod, aby zawsze automatycznie restartował się, jeśli kontener umiera.
sprawia, że kontener lub pod wchodzi w stan uruchomienia przy starcie systemu
dodaje lub usuwa otwarte porty kontenerów do zapory.
Przyjmuje parametr do uruchamiania kontenerów bezrootowych pod danym użytkownikiem

Dla odniesienia, zobacz te dwa blogi dotyczące roli:

Blogi opisują, jak można uruchomić pojedynczy kontener lub kilka kontenerów jako jeden pod z użyciem tego modułu.

Uwaga dotycząca uruchamiania kontenerów bezrootowych:

Musisz utworzyć użytkownika przed uruchomieniem tej roli.
Użytkownik powinien mieć wpisy w plikach /etc/sub[gu]id dla zakresu przestrzeni nazw. Jeśli nie, ta rola dodaje pewne zmienne, aby coś ruszyć, ale preferencyjnie powinieneś je sprawdzić.
Niektóre kontrolne rzeczy, jak limit pamięci czy inne limity zasobów, nie będą działać jako użytkownik.
Chcę znacznie zwiększyć systemd_TimeoutStartSec, ponieważ nie możemy pobierać obrazów przed uruchomieniem jednostki systemd. Tak więc systemd musi poczekać na podman, aby pobrać obrazy przed uruchomieniem kontenera. Może to zająć minuty w zależności od połączenia sieciowego i rozmiaru obrazu kontenera.

Wymagania

Wymaga systemu, który potrafi uruchomić podman, i aby podman był dostępny w repozytoriach pakietów. Rola instaluje podman. Rola także instaluje firewalld jeśli użytkownik zdefiniował zmienną container_firewall_ports. Instaluje kubeval dla poda, jeśli container_pod_yaml_template_validation: true.

Zmienne roli

Rola używa zmiennych, które należy przekazać podczas jej włączenia. Tak jest możliwość uruchomienia jednego kontenera osobno lub wielu kontenerów w podzie, zauważ, że niektóre opcje dotyczą tylko innej metody.

container_image_list - lista obrazów kontenerów do uruchomienia. Jeśli zdefiniowano więcej niż jeden obraz, kontenery będą uruchamiane w podzie. Możliwe jest zdefiniowanie go jako słownik, aby uwzględnić informacje o uwierzytelnieniu dla każdego obrazu, jak poniżej:

container_image_list:
  - image: docker.io/imagename
    user: exampleuser
    password: examplepw
  - image: docker.io/imagename2

container_image_user - opcjonalna domyślna nazwa użytkownika do używania przy uwierzytelnianiu w zdalnych rejestrach
container_image_password - opcjonalne domyślne hasło do używania przy uwierzytelnianiu w zdalnych rejestrach
container_name - identyfikacja kontenera w systemd i poleceniach podman. Plik usługi systemd będzie nazwany container_name--container-pod.service. Można to nadpisać zmienną service_name.
container_run_args - wszystko, co przekazujesz do podman, z wyjątkiem nazwy i obrazu podczas uruchamiania pojedynczego kontenera. Nie jest używane dla podu. Może to być ciąg lub lista ciągów.
container_cmd_args - dowolne polecenie i argumenty przekazane do podman-run po określeniu nazwy obrazu. Nie jest używane dla podu.
container_run_as_user - Który użytkownik powinien uruchomić kontener systemd. Domyślnie to root.
container_run_as_group - Która grupa powinna uruchomić kontener systemd. Domyślnie to root.
container_dir_owner - Kto powinien być właścicielem katalogów wolumenów. Domyślnie to container_run_as_user. Jeśli użyjesz opcji :U jako opcji wolumenu, podman automatycznie ustawi uprawnienia dla użytkownika wewnątrz kontenera. Cytat: Sufiks :U mówi Podmanowi, aby używał odpowiedniego UID i GID hosta na podstawie UID i GID w kontenerze, aby rekurencyjnie zmienić właściciela i grupę źródłowego wolumenu. Ostrzeżenie – używaj z ostrożnością, ponieważ to zmodyfikuje system plików hosta.
container_dir_group - Która grupa powinna mieć katalogi wolumenów. Domyślnie to container_run_as_group.
container_dir_mode - Jakie uprawnienia powinny mieć katalogi wolumenów. Domyślnie '0755'.
container_state - kontener jest zainstalowany i uruchomiony, jeśli stan to running, a zatrzymany i plik systemd usunięty, jeśli absent
container_firewall_ports - lista portów, które otworzyłeś z kontenera i chcesz otworzyć zaporę dla. Kiedy stan kontenera jest absent, porty zapory zostaną zamknięte. Jeśli nie chcesz, aby firewalld był zainstalowany, nie definiuj tego.
systemd_TimeoutStartSec - jak długo systemd czeka na uruchomienie kontenera?
systemd_tempdir - Gdzie przechowywać plik conmon-pidfile i cidfile dla pojedynczych kontenerów. Domyślnie %T na systemach obsługujących ten specyfikator (patrz man 5 systemd.unit) /tmp w przeciwnym razie.
service_name - Jak nazywane są pliki usług systemd. Domyślnie "{{ container_name }}-container-pod-{{ container_run_as_user }}.service".
service_files_dir - Gdzie przechowywane są pliki usług systemd. Domyślnie /usr/local/lib/systemd/system dla roota i "{{ user_info.home }}/.config/systemd/user dla użytkownika bezrootowego.
service_files_owner - Który użytkownik powinien być właścicielem plików usług systemd. Domyślnie root.
service_files_group - Która grupa powinna być właścicielem plików usług systemd. Domyślnie root.
service_files_mode - Jakie uprawnienia powinny mieć pliki usług systemd. Domyślnie 0644.
container_pod_yaml - ścieżka do pliku yaml poda. Wymagana dla poda.
container_pod_yaml_deploy - czy wdrożyć plik yaml poda. Domyślnie false
container_pod_yaml_template - Szablon do użycia dla wdrożenia yaml poda. Ponieważ szablon nie zawiera każdej możliwej opcji konfiguracyjnej, można go nadpisać własnym szablonem. Domyślnie templates/container-pod-yaml.j2.
container_pod_yaml_template_validation - czy walidować wdrożony plik yaml poda. Domyślnie false.
container_pod_labels - Definiuje etykiety dla container_pod_yaml_deploy.
container_pod_volumes - Definiuje wolumeny dla container_pod_yaml_deploy.
container_pod_containers - Definiuje kontenery dla ```container_pod_yaml_deploy``.

Ten playbook nie ma modułu pythona do parsowania parametrów dla polecenia podman. Do tego czasu musisz przekazać wszystkie parametry tak, jakbyś używał podman z wiersza poleceń. Zobacz man podman lub tutoriale podman po więcej informacji.

Jeśli chcesz, aby Twoje obrazy były automatycznie aktualizowane, dodaj tę etykietę do container_cmd_args: --label "io.containers.autoupdate=image"

Nigdy nie używaj ansible.builtin.import_role, aby wykonać tę rolę, jeśli zamierzasz używać jej więcej niż raz na playbook, ponieważ wpadniesz w ten antywzorzec.

Zależności

containers.podman (kolekcja)
ansible.posix (kolekcja)

Przykładowy playbook

Zobacz tests/main.yml dla przykładu. Krótko mówiąc, włącz rolę z zmiennymi.

Kontener root:

- nazwa: test kontenera
  zmienne:
    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

Kontener bezrootowy:

- nazwa: upewnij się, że użytkownik istnieje
  użytkownik:
    nazwa: rootless_user
    komentarz: Uruchamiam przykładowy kontener

- nazwa: test kontenera
  zmienne:
    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

Pod bezrootowy:

- nazwa: upewnij się, że użytkownik istnieje
  użytkownik:
    nazwa: rootless_user
    komentarz: Uruchamiam przykładowy kontener

- nazwa: test poda
  zmienne:
    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