Мониторинг контейнеров#

Используйте команды Podman для управления средой. С их помощью можно определить состояние контейнера, благодаря информации о системе и pod, а также отслеживать события Podman.

Проверка состояния контейнера#

Можно использовать проверку состояния, чтобы определить готовность процесса, запущенного внутри контейнера.

Если проверка прошла успешно, контейнер помечается как healthy. В противном случае присваивается статус unhealthy. Можно сравнить проверку состояния с выполнением команды podman exec и проверкой кода завершения. Нулевое значение отражает, что контейнер healthy.

Проверки состояния можно установить при создании образа с помощью инструкции HEALTHCHECK в файле Containerfile или при создании контейнера в командной строке. Для отображения состояние проверки состояния (health-check status) используйте команды podman inspect или podman ps.

Проверка состояния состоит из шести основных компонентов:

  • Command (опция --health-cmd) - выполняет команду внутри целевого контейнера и ждет кода завершения;

  • Retries (опция --health-retries) - определяет количество последовательных неудачных проверок, которые должны произойти до того, как контейнер будет помечен как unhealthy. Успешная проверка состояния сбрасывает счетчик повторений;

  • Interval (опция --health-interval) - описывает время между выполнением команды проверки. Обратите внимание, небольшие интервалы заставляют систему тратить много времени на проверку. Большие интервалы вызывают трудности с тайм-аутами;

  • Start-period (опция --health-start-period) - устанавливает время между запуском контейнера и моментом, когда нужно пропускать сбои проверки состояния;

  • Timeout (опция --health-timeout) - описывает период времени, в течение которого проверка должна быть завершена, прежде чем попытка будет считаться неудачной;

  • Container recovery (опция --health-on-failure) - определяет, какие действия выполнять при состоянии unhealthy. Когда приложение выходит из строя, Podman автоматически перезапускает его.

Компоненты, связанные с планированием проверки, необязательны.

Опция --health-on-failure поддерживает четыре действия:

  • none - не предпринимает никаких действий (значение по умолчанию);

  • kill - останавливает контейнер;

  • restart - перезапускает контейнер;

  • stop - приостанавливает контейнер.

Примечание

Опция --health-on-failure доступна в Podman 4.2 и более поздних версиях.

Важно

Не объединяйте команду restart с опцией --restart. При работе внутри systemd unit рассмотрите возможность использования действия kill или stop, чтобы использовать политику перезапуска systemd.

Проверки состояния проходят внутри контейнера. Они имеют смысл только в том случае, если известно какие существуют состояния службы и можно провести различие между успешной и неудачной проверкой.

Выполнение проверки работоспособности через командную строку#

Можно установить проверку работоспособности из командной строки при создании контейнера.

  1. Запустите проверку работоспособности:

    podman run -dt --name=hc-container -p 8080:8080 --health-cmd='curl http://localhost:8080 || exit 1' --health-interval=0 registry.example.ru/ubi8/httpd-24

    В данной команде опции выполняют следующие действия:

    • --health-cmd - устанавливает команду проверки работоспособности для контейнера;

    • --health-interval=0 со значением 0 - указывает, что проверка работоспособности запускается вручную.

  2. Проверьте состояние контейнера hc-container:

    • С помощью команды podman inspect:

      podman inspect --format='{{json .State.Health.Status}}' hc-container

      Пример вывода команды:

      healthy

    • С помощью команды podman ps:

      podman ps

      Пример вывода команды:

      CONTAINER ID  IMAGE                 COMMAND               CREATED      STATUS          PORTS       NAMES
a680c6919fe  localhost/hc-container:latest  /usr/bin/run-http...  2 minutes ago  Up 2 minutes (healthy) hc-container

    • С помощью команды podman healthcheck run:

      podman healthcheck run hc-container

      Пример вывода команды:

      healthy

Выполнение проверки работоспособности с помощью Containerfile#

Можно выполнять проверку работоспособности, используя инструкцию HEALTHCHECK в файле Containerfile.

  1. Создайте Containerfile:

    cat Containerfile

    Пример вывода команды:

    FROM registry.example.ru/ubi8/httpd-24
EXPOSE 8080
HEALTHCHECK CMD curl http://localhost:8080 || exit 1

    Примечание

    Инструкция HEALTHCHECK поддерживается только для формата образа docker. Для формата образа oci инструкция не учитывается.

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

    podman build --format=docker -t hc-container .

    Пример вывода команды:

    STEP 1/3: FROM registry.example.ru/ubi8/httpd-24
STEP 2/3: EXPOSE 8080
--> 5aea97430fd
STEP 3/3: HEALTHCHECK CMD curl http://localhost:8080 || exit 1
COMMIT health-check
Successfully tagged localhost/health-check:latest
a680c6919fe6bf1a79219a1b3d6216550d5a8f83570c36d0dadfee1bb74b924e

  3. Запустите контейнер:

    podman run -dt --name=hc-container localhost/hc-container

  4. Проверьте статус работоспособности контейнера hc-container:

    • С помощью команды podman inspect:

      podman inspect --format='{{json .State.Health.Status}}' hc-container

      Пример вывода команды:

      healthy

    • С помощью команды podman ps:

      podman ps

      Пример вывода команды:

      CONTAINER ID  IMAGE                 COMMAND               CREATED      STATUS          PORTS       NAMES
a680c6919fe  localhost/hc-container:latest  /usr/bin/run-http...  2 minutes ago  Up 2 minutes (healthy) hc-container

    • С помощью команды podman healthcheck run:

      podman healthcheck run hc-container

      Пример вывода команды:

      healthy

Отображение системной информации о Podman#

Команда podman system позволяет управлять системами Podman, отображая системную информацию:

  • Для отображения использования дисков введите:

    podman system df

    Пример вывода команды:

    TYPE           TOTAL       ACTIVE      SIZE        RECLAIMABLE
Images         3           2           1.085GB     233.4MB (0%)
Containers     2           0           28.17kB     28.17kB (100%)
Local Volumes  3           0           0B          0B (0%)

  • Для раскрытия детальной информации об использовании пространства введите:

    podman system df -v

    Пример вывода команды:

    Images space usage:

REPOSITORY                                TAG         IMAGE ID      CREATED     SIZE        SHARED SIZE  UNIQUE SIZE  CONTAINERS
registry.example.ru/ubi9           latest      b1e63aaae5cf  13 days     233.4MB     233.4MB      0B           0
registry.example.ru/ubi9/httpd-24  latest      0d04740850e8  13 days     461.5MB     0B           461.5MB      1
registry.example.io/rhel8/podman           latest      dce10f591a2d  13 days     390.6MB     233.4MB      157.2MB      1

Containers space usage:

CONTAINER ID  IMAGE         COMMAND                     LOCAL VOLUMES  SIZE        CREATED     STATUS      NAMES
311180ab99fb  0d04740850e8  /usr/bin/run-httpd          0              28.17kB     16 hours    exited      hc1
bedb6c287ed6  dce10f591a2d  podman run ubi9 echo hello  0              0B          11 hours    configured  dazzling_tu

Local Volumes space usage:

VOLUME NAME                                                       LINKS       SIZE
76de0efa83a3dae1a388b9e9e67161d28187e093955df185ea228ad0b3e435d0  0           0B
8a1b4658aecc9ff38711a2c7f2da6de192c5b1e753bb7e3b25e9bf3bb7da8b13  0           0B
d9cab4f6ccbcf2ac3cd750d2efff9d2b0f29411d430a119210dd242e8be20e26  0           0B

  • Для раскрытия информации о хосте, текущей статистике хранилища и сборке Podman используйте:

    podman system info

    Пример вывода команды:

    host:
  arch: amd64
  buildahVersion: 1.22.3
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: conmon-2.0.29-1.module+el8.5.0+12381+e822eb26.x86_64
    path: /usr/bin/conmon
    version: 'conmon version 2.0.29, commit: 7d0fa63455025991c2fc641da85922fde889c91b'
  cpus: 2
  distribution:
    distribution: '"rhel"'
    version: "8.5"
  eventLogger: file
  hostname: localhost.localdomain
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 4.18.0-323.el8.x86_64
  linkmode: dynamic
  memFree: 352288768
  memTotal: 2819129344
  ociRuntime:
    name: runc
    package: runc-1.0.2-1.module+el8.5.0+12381+e822eb26.x86_64
    path: /usr/bin/runc
    version: |-
      runc version 1.0.2
      spec: 1.0.2-dev
      go: go1.16.7
      libseccomp: 2.5.1
  os: linux
  remoteSocket:
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_NET_RAW,CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: true
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: slirp4netns-1.1.8-1.module+el8.5.0+12381+e822eb26.x86_64
    version: |-
      slirp4netns version 1.1.8
      commit: d361001f495417b880f20329121e3aa431a8f90f
      libslirp: 4.4.0
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.5.1
  swapFree: 3113668608
  swapTotal: 3124752384
  uptime: 11h 24m 12.52s (Approximately 0.46 days)
registries:
  search:
  - registry.fedoraproject.org
  - registry.example.ru
  - registry.centos.org
  - docker.io
store:
  configFile: /home/user/.config/containers/storage.conf
  containerStore:
    number: 2
    paused: 0
    running: 0
    stopped: 2
  graphDriverName: overlay
  graphOptions:
    overlay.mount_program:
      Executable: /usr/bin/fuse-overlayfs
      Package: fuse-overlayfs-1.7.1-1.module+el8.5.0+12381+e822eb26.x86_64
      Version: |-
        fusermount3 version: 3.2.1
        fuse-overlayfs: version 1.7.1
        FUSE library version 3.2.1
        using FUSE kernel interface version 7.26
  graphRoot: /home/user/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: xfs
    Native Overlay Diff: "false"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 3
  runRoot: /run/user/1000/containers
  volumePath: /home/user/.local/share/containers/storage/volumes
version:
  APIVersion: 3.3.1
  Built: 1630360721
  BuiltTime: Mon Aug 30 23:58:41 2021
  GitCommit: ""
  GoVersion: go1.16.7
  OsArch: linux/amd64
  Version: 3.3.1

  • Для удаления всех неиспользуемых контейнеров, образов и данных тома используйте команду:

    podman system prune

    Пример вывода команды:

    WARNING! This will remove:
        - all stopped containers
        - all stopped pods
        - all dangling images
        - all build cache
Are you sure you want to continue? [y/N] y

    В данном примере:

    • Команда podman system prune удаляет все неиспользуемые контейнеры (зависшие и без ссылок), pods и, опционально, тома из локального хранилища;

    • Опция --all удаляет все неиспользуемые образы. Неиспользуемые образы — это зависшие образы и образы, на основе которых нет никаких контейнеров;

    • Опция --volume удаляет тома. По умолчанию тома не удаляются, чтобы предотвратить потерю важных данных при отсутствии контейнера.

Типы событий Podman#

Можно отслеживать события, происходящие в Podman. Существует несколько типов событий, и каждый сообщает о разных статусах.

Тип события container сообщает о следующих статусах:

  • attach;

  • checkpoint;

  • cleanup;

  • commit;

  • create;

  • exec;

  • export;

  • import;

  • init;

  • kill;

  • mount;

  • pause;

  • prune;

  • remove;

  • restart;

  • restore;

  • start;

  • stop;

  • sync;

  • unmount;

  • unpaus.

Тип события pod сообщает о следующих статусах:

  • create;

  • kill;

  • pause;

  • remove;

  • start;

  • stop;

  • unpause.

Тип события image сообщает о следующих статусах:

  • prune;

  • push;

  • pull;

  • save;

  • remove;

  • tag;

  • untag.

Тип события system сообщает о следующих статусах:

  • refresh;

  • renumber.

Тип события volume сообщает о следующих статусах:

  • create;

  • prune;

  • remove.

Мониторинг событий Podman#

Можно отслеживать и отображать события, которые происходят в Podman, с помощью команды podman events. Каждое событие будет включать в себя метку времени, тип, статус, имя, если это применимо, и образ, если это возможно.

  1. Запустите контейнер myubi:

    podman run -q --rm --name=myubi registry.example.ru/ubi8/ubi:latest

  2. Раскройте события Podman:

    • Для отображения всех событий введите:

      now=$(date --iso-8601=seconds)
podman events --since=now --stream=false

      Пример вывода команды:

      2023-03-08 14:27:20.696167362 +0100 CET container create d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72fe09 (image=registry.example.ru/ubi8/ubi:latest, name=myubi,...)
2023-03-08 14:27:20.652325082 +0100 CET image pull  registry.example.com/ubi8/ubi:latest
2023-03-08 14:27:20.795695396 +0100 CET container init d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72fe09 (image=registry.example.ru/ubi8/ubi:latest, name=myubi...)
2023-03-08 14:27:20.809205161 +0100 CET container start d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72fe09 (image=registry.example.ru/ubi8/ubi:latest, name=myubi...)
2023-03-08 14:27:20.809903022 +0100 CET container attach d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72fe09 (image=registry.example.ru/ubi8/ubi:latest, name=myubi...)
2023-03-08 14:27:20.831710446 +0100 CET container died d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72fe09 (image=registry.example.ru/ubi8/ubi:latest, name=myubi...)
2023-03-08 14:27:20.913786892 +0100 CET container remove d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72fe09 (image=registry.example.ru/ubi8/ubi:latest, name=myubi...)

      Опция --stream=false гарантирует, что выполнение команды podman events завершится при чтении последнего известного события.

      Список событий, происходящих в podman run, может включать:

      • container create - создание нового контейнера;

      • image pull - получении образа, если образ контейнера отсутствует в локальном хранилище;

      • container init - инициализация контейнера во время выполнения и настройки сети;

      • container start - запуск контейнера;

      • container attach - присоединение к терминалу контейнера. Такое событие происходит, если контейнер работает в приоритетном режиме;

      • container died - выход из контейнера;

      • container remove - удаление контейнера после выхода из него (если указан флаг --rm).

    • Для отображения событий Podman используйте команду journalctl:

      journalctl --user -r SYSLOG_IDENTIFIER=podman

      Пример вывода команды:

      Mar 08 14:27:20 fedora podman[129324]: 2023-03-08 14:27:20.913786892 +0100 CET m=+0.066920979 container remove
...
Mar 08 14:27:20 fedora podman[129289]: 2023-03-08 14:27:20.696167362 +0100 CET m=+0.079089208 container create d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72f>

    • Чтобы отобразить события Podman, связанные с созданием контейнеров, введите:

      podman events --filter event=create

      2023-03-08 14:27:20.696167362 +0100 CET container create d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72fe09 (image=registry.example.com/ubi8/ubi:latest, name=myubi,...)

    • Можно также использовать команду journalctl:

      journalctl --user -r PODMAN_EVENT=create

      Пример вывода команды:

      Mar 08 14:27:20 fedora podman[129289]: 2023-03-08 14:27:20.696167362 +0100 CET m=+0.079089208 container create d4748226a2bcd271b1bc4b9f88b54e8271c13ffea9b30529968291c62d72f>

Использование событий Podman для аудита#

В предыдущих версиях события (в выводе команд) должны были связываться с событием для правильной интерпретации. Например, событие container-create должно было связываться с событием image-pull для понимания, какой образ использовался. Событие container-create не включало все данные, например, настройки безопасности, тома, точки монтирования и так далее.

Начиная с Podman v4.4, можно получить всю соответствующую информацию о контейнере непосредственно из одного события и записи в journald. Данные представлены в формате JSON, соответствующем команде podman container inspect, и включают в себя все настройки конфигурации и безопасности контейнера. Можно настроить Podman, присоединив данные проверки контейнера для целей аудита.

  1. Измените файл ~/.config/containers/containers.conf и добавьте опцию events_container_create_inspect_data=true в раздел [engine]:

    cat ~/.config/containers/containers.conf

    Пример вывода команды:

    [engine]
events_container_create_inspect_data=true

    Для общесистемной конфигурации измените файл /etc/containers/containers.conf или /usr/share/container/containers.conf.

  2. Создайте контейнер:

    podman create registry.example.ru/ubi8/ubi:latest

    Пример вфвода команды:

    19524fe3c145df32d4f0c9af83e7964e4fb79fc4c397c514192d9d7620a36cd3

  3. Отобразите события Podman:

  • С помощью команды podman events:

    now=$(date --iso-8601=seconds)
podman events --since $now --stream=false --format "{{.ContainerInspectData}}" | jq “.Config.CreateCommand"

    Пример вывода команды:

    [
  "/usr/bin/podman",
  "create",
  "registry.example.com/ubi8"
]

    В данном примере:

    • Опция --format "{{.ContainerInspectData}}" отображает данные проверки;

    • jq ". Config.CreateCommand" преобразует данные JSON в более читаемый формат и отображает параметры для команды podman create.

  • Используя команду journalctl:

    journalctl --user -r PODMAN_EVENT=create --all -o json | jq ".PODMAN_CONTAINER_INSPECT_DATA | fromjson" | jq ".Config.CreateCommand"

    Пример вывода команды:

    [
  "/usr/bin/podman",
  "create",
  "registry.example.ru/ubi8"
]

    Выводы события podman и команды journalctl совпадают.