🐳 Docker выпустила Sandboxes - изолированные среды специально для AI coding agents.
Идея простая: дать агентам вроде Claude Code, Codex, Gemini CLI, Copilot CLI, OpenCode и Kiro больше свободы, но не давать им свободно ломать хост-систему.
Каждый агент запускается в отдельной microVM и получает только рабочую директорию проекта. Внутри он может:
- устанавливать пакеты;
- менять конфиги;
- запускать сервисы;
- поднимать собственные Docker-контейнеры;
- выполнять долгие задачи без постоянного подтверждения действий.
При этом Docker позволяет отдельно контролировать filesystem, network и credentials, а сам sandbox после работы можно просто удалить.
Это инфраструктурный слой для эпохи автономных coding agents: агенту дают почти полный контроль внутри песочницы, но хост остаётся изолированным.
https://www.docker.com/products/docker-sandboxes/
#Docker #AI #AIAgents #DevOps #Programming
Идея простая: дать агентам вроде Claude Code, Codex, Gemini CLI, Copilot CLI, OpenCode и Kiro больше свободы, но не давать им свободно ломать хост-систему.
Каждый агент запускается в отдельной microVM и получает только рабочую директорию проекта. Внутри он может:
- устанавливать пакеты;
- менять конфиги;
- запускать сервисы;
- поднимать собственные Docker-контейнеры;
- выполнять долгие задачи без постоянного подтверждения действий.
При этом Docker позволяет отдельно контролировать filesystem, network и credentials, а сам sandbox после работы можно просто удалить.
Это инфраструктурный слой для эпохи автономных coding agents: агенту дают почти полный контроль внутри песочницы, но хост остаётся изолированным.
https://www.docker.com/products/docker-sandboxes/
#Docker #AI #AIAgents #DevOps #Programming
👍11🤡2
🤯 Ошибка уже произошла. В логах — сотни строк, причин может быть несколько, а исправление ещё нужно проверить. Расследование инцидента легко превращается в часы ручной работы.
8 сентября в 20:00 МСК на открытом уроке «ИИ против бага: как разобрать инцидент в Python-проекте от логов до исправления» покажем, где в этом процессе действительно может помочь искусственный интеллект.
На практическом примере пройдём весь путь: проанализируем логи, сформулируем и проверим гипотезы, найдём проблемный участок кода, подготовим исправление и тесты. Вы увидите, как ускорять расследование с помощью ИИ, сохраняя контроль над результатом.
Урок будет полезен Python-разработчикам, знакомым с отладкой и анализом логов, и проходит в преддверии старта курса «ИИ для Python-разработчиков».
🤖Зарегистрируйтесь и разберите рабочий сценарий применения ИИ: https://vk.cc/d0TUT1
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
8 сентября в 20:00 МСК на открытом уроке «ИИ против бага: как разобрать инцидент в Python-проекте от логов до исправления» покажем, где в этом процессе действительно может помочь искусственный интеллект.
На практическом примере пройдём весь путь: проанализируем логи, сформулируем и проверим гипотезы, найдём проблемный участок кода, подготовим исправление и тесты. Вы увидите, как ускорять расследование с помощью ИИ, сохраняя контроль над результатом.
Урок будет полезен Python-разработчикам, знакомым с отладкой и анализом логов, и проходит в преддверии старта курса «ИИ для Python-разработчиков».
🤖Зарегистрируйтесь и разберите рабочий сценарий применения ИИ: https://vk.cc/d0TUT1
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru
❤1💩1
Что на самом деле делает `docker run -it` 🐳
Когда контейнеру нужен интерактивный shell, REPL или текстовый редактор, обычно запускают:
Но
-
-
Вместе они дают полноценную интерактивную сессию:
Без
Без
Под капотом схема примерно такая:
То есть
Если вы годами пишете
https://labs.iximiuz.com/challenges/docker-101-container-run-tty
Когда контейнеру нужен интерактивный shell, REPL или текстовый редактор, обычно запускают:
docker run -it ...
Но
-i и -t делают разные вещи.-
-i (--interactive) — оставляет STDIN открытым, чтобы процесс внутри контейнера мог получать ввод с клавиатуры.-
-t (--tty) — создаёт pseudo-TTY, поэтому приложение ведёт себя как в обычном терминале.Вместе они дают полноценную интерактивную сессию:
docker run -it ubuntu bash
Без
-i не будет нормального интерактивного ввода.Без
-t приложение может работать, но без привычного терминального поведения: prompt, цветов, управления курсором и нормальной работы vim, top, less и других TTY-программ.Под капотом схема примерно такая:
Terminal
↓
Docker CLI
↓
pseudo-TTY
↓
bash внутри контейнера
То есть
-i отвечает за ввод, а -t — за сам терминал.Если вы годами пишете
docker run -it, но никогда не разбирались, зачем нужны оба флага, у iximiuz есть отличный практический challenge:https://labs.iximiuz.com/challenges/docker-101-container-run-tty
👍13
Чат с вашими резюме.
Присылайте резюме, чтобы HR вас увидела и ей(ему) было удобно с вами связаться.
IT Резюме
P.S сейчас там можно бесплатно «прожарить» свое резюме на предмет ошибок и обхода ATS
Присылайте резюме, чтобы HR вас увидела и ей(ему) было удобно с вами связаться.
IT Резюме
P.S сейчас там можно бесплатно «прожарить» свое резюме на предмет ошибок и обхода ATS
Telegram
IT Резюме
Ваши IT резюме. Присылайте сюда, чтобы их заметили HRы
Можно постить, обсуждать и помогать.
Без флуда, провокаций, агрессии и мата.
@antonzvonar
Можно постить, обсуждать и помогать.
Без флуда, провокаций, агрессии и мата.
@antonzvonar
🤡4🔥3
eBPF: рентгеновское зрение для production
Сервис замедлился, соединения обрываются, а привычные показатели указывают только на симптом. Чтобы найти настоящую причину, иногда нужно увидеть, что происходит глубже — на уровне ядра Linux.
23 сентября в 20:00 на открытом уроке курса «DevOps практики и инструменты» познакомитесь с eBPF — технологией, которая помогает исследовать сетевые события, производительность и безопасность работающей системы.
На демонстрации вы увидите, как Cilium Hubble показывает сетевые взаимодействия и помогает находить проблемы с трафиком. С помощью Tetragon разберёте обнаружение подозрительной активности на уровне ядра. Также рассмотрите диагностику узких мест без остановки сервисов.
Преподаватель объяснит архитектуру eBPF простыми словами — как программы безопасно запускаются в ядре, какие данные можно получать и почему этот подход расширяет возможности традиционного мониторинга.
Вы поймёте, для каких задач eBPF действительно полезен, где он дополняет существующие средства наблюдаемости и когда его внедрение будет избыточным.
👉 Зарегистрируйтесь: https://vk.cc/d1LA8H
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Сервис замедлился, соединения обрываются, а привычные показатели указывают только на симптом. Чтобы найти настоящую причину, иногда нужно увидеть, что происходит глубже — на уровне ядра Linux.
23 сентября в 20:00 на открытом уроке курса «DevOps практики и инструменты» познакомитесь с eBPF — технологией, которая помогает исследовать сетевые события, производительность и безопасность работающей системы.
На демонстрации вы увидите, как Cilium Hubble показывает сетевые взаимодействия и помогает находить проблемы с трафиком. С помощью Tetragon разберёте обнаружение подозрительной активности на уровне ядра. Также рассмотрите диагностику узких мест без остановки сервисов.
Преподаватель объяснит архитектуру eBPF простыми словами — как программы безопасно запускаются в ядре, какие данные можно получать и почему этот подход расширяет возможности традиционного мониторинга.
Вы поймёте, для каких задач eBPF действительно полезен, где он дополняет существующие средства наблюдаемости и когда его внедрение будет избыточным.
👉 Зарегистрируйтесь: https://vk.cc/d1LA8H
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
❤2🔥2💩2
🐳 Docker-образ с 3,17 ГБ до 354 МБ - почти в 9 раз меньше
Такая оптимизация обычно достигается не одной магией, а несколькими простыми приёмами:
- multi-stage build
-
- удаление build-зависимостей после сборки
- очистка
-
- установка только production-зависимостей
- объединение команд
Пример:
Что это даёт:
- быстрее pull/push
- быстрее CI/CD
- меньше места в registry
- быстрее запуск новых pod
- меньше потенциальная attack surface
Перед оптимизацией полезно посмотреть, что реально раздувает образ:
и отдельно проверить слои через
Большой Docker image почти всегда стоит сначала разобрать по слоям — часто там лежат гигабайты build-tools, cache и файлов, которые в runtime вообще не нужны.
Такая оптимизация обычно достигается не одной магией, а несколькими простыми приёмами:
- multi-stage build
-
python:slim / distroless вместо тяжёлого base image- удаление build-зависимостей после сборки
- очистка
apt / pip cache-
.dockerignore для лишних файлов- установка только production-зависимостей
- объединение команд
RUN, чтобы не тащить мусор в слоиПример:
3.17 GB → 354 MBЧто это даёт:
- быстрее pull/push
- быстрее CI/CD
- меньше места в registry
- быстрее запуск новых pod
- меньше потенциальная attack surface
Перед оптимизацией полезно посмотреть, что реально раздувает образ:
docker history <image>и отдельно проверить слои через
dive.Большой Docker image почти всегда стоит сначала разобрать по слоям — часто там лежат гигабайты build-tools, cache и файлов, которые в runtime вообще не нужны.
😁5🤔2👍1
Из вашего резюме вообще понятно, что вы умеете как DevOps-инженер?
Мы разбили работу DevOps-инженера на основные категории и сделали чекер, который показывает, какие из них в вашем резюме раскрыты хорошо, частично или почти не видны.
Опыт может быть - но по резюме этого не видно.
Проверь бесплатно и без регистрации:
https://updatecv.me/devops-resume-checker
А полный анализ резюме с правками доступен на: https://updatecv.me
Мы разбили работу DevOps-инженера на основные категории и сделали чекер, который показывает, какие из них в вашем резюме раскрыты хорошо, частично или почти не видны.
Опыт может быть - но по резюме этого не видно.
Проверь бесплатно и без регистрации:
https://updatecv.me/devops-resume-checker
А полный анализ резюме с правками доступен на: https://updatecv.me
💩6❤1
Kagent + Ollama: ИИ-агент для работы с Kubernetes
Как использовать локальную языковую модель для работы с Kubernetes? На вебинаре разберём связку Kagent + Ollama и посмотрим, как ИИ-агент помогает анализировать состояние кластера и взаимодействовать с его ресурсами.
1 октября в 20:00 МСК на открытом вебинаре OTUS покажем, как запустить ИИ-агента с локальной LLM и применить его в DevOps-задачах.
На практике рассмотрим:
— какую роль выполняют Kagent и Ollama;
— как подключить локальную LLM к агенту;
— как агент анализирует состояние кластера и работает с Kubernetes-ресурсами;
— в каких повседневных задачах DevOps-инженера он может помочь;
— какие возможности и ограничения есть у агентного подхода.
После вебинара вы поймёте, как устроена связка Kagent + Ollama, увидите её применение в Kubernetes и сможете оценить, для каких задач в вашей инфраструктуре подходит ИИ-агент.
Урок проходит в преддверии старта курса «ИИ в работе DevOps-инженера».
👉 Регистрируйтесь: https://vk.cc/d23O7U
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Как использовать локальную языковую модель для работы с Kubernetes? На вебинаре разберём связку Kagent + Ollama и посмотрим, как ИИ-агент помогает анализировать состояние кластера и взаимодействовать с его ресурсами.
1 октября в 20:00 МСК на открытом вебинаре OTUS покажем, как запустить ИИ-агента с локальной LLM и применить его в DevOps-задачах.
На практике рассмотрим:
— какую роль выполняют Kagent и Ollama;
— как подключить локальную LLM к агенту;
— как агент анализирует состояние кластера и работает с Kubernetes-ресурсами;
— в каких повседневных задачах DevOps-инженера он может помочь;
— какие возможности и ограничения есть у агентного подхода.
После вебинара вы поймёте, как устроена связка Kagent + Ollama, увидите её применение в Kubernetes и сможете оценить, для каких задач в вашей инфраструктуре подходит ИИ-агент.
Урок проходит в преддверии старта курса «ИИ в работе DevOps-инженера».
👉 Регистрируйтесь: https://vk.cc/d23O7U
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
💩2
🐳 Как устроен Docker: что происходит «под капотом»
Поговорим немного про базу.
Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри.
1) Что такое контейнер?
Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.
2) Основные компоненты
• Docker Engine
– Docker Daemon (
– Docker CLI (
– REST API — взаимодействие CLI и Daemon
👉 Пример:
3) Namespaces
Механизм изоляции в Linux, создающий для контейнера:
• свой процессный ID (pid namespace)
• файловую систему (mnt namespace)
• сеть (net namespace)
• hostname (uts namespace)
• IPC (ipc namespace)
👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы.
4) Cgroups
Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть).
Пример: можно задать лимит 512 МБ RAM и 0.5 CPU.
Если приложение превышает лимит — Docker его ограничит или остановит.
5) Union File Systems (OverlayFS)
Docker использует многослойную файловую систему. Каждый шаг
При запуске контейнера создаётся верхний writable-слой, остальные read-only.
👉 10 контейнеров на одном образе разделяют слои → экономия места.
6) Container Runtime
Docker использует
Daemon вызывает
7) Docker Images
Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (
8) Docker Networking
Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.
👉 Можно пробросить порты через
В Swarm используется Overlay network (сеть между хостами).
9) Безопасность
Docker использует:
• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)
⚠️ По умолчанию контейнеры имеют широкий доступ (например,
10) Что происходит при `docker run nginx`?
1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается
7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command
Контейнер живёт, пока жив его процесс.
11) Почему Docker — не магия?
Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.
Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.
12) Заключение
Под капотом Docker:
• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие
Docker скрывает сложность, давая простой инструмент для запуска, сборки, развёртывания приложений.
Теперь, зная внутреннее устройство, можно глубже понять контейнеры, лучше их настраивать и оптимизировать.
➡️ Подробнее
Поговорим немного про базу.
Docker — одно из самых популярных средств контейнеризации. Его простота снаружи скрывает сложную архитектуру. Разберём, как он устроен внутри.
1) Что такое контейнер?
Контейнер — изолированная среда, где запускается приложение со всеми зависимостями.
⚠️ Это не виртуальная машина: контейнер делит ядро ОС с хостом, но видит только свою «песочницу» через изоляцию.
2) Основные компоненты
• Docker Engine
– Docker Daemon (
dockerd) управляет контейнерами, образами, сетями – Docker CLI (
docker) — интерфейс пользователя – REST API — взаимодействие CLI и Daemon
👉 Пример:
docker run nginx → CLI отправляет запрос, Daemon находит образ, создаёт контейнер, запускает процесс.3) Namespaces
Механизм изоляции в Linux, создающий для контейнера:
• свой процессный ID (pid namespace)
• файловую систему (mnt namespace)
• сеть (net namespace)
• hostname (uts namespace)
• IPC (ipc namespace)
👉 Благодаря namespace контейнер видит «свою» мини-ОС, хотя на деле — это лишь виртуальные границы.
4) Cgroups
Ограничивают и учитывают ресурсы (CPU, RAM, I/O, сеть).
Пример: можно задать лимит 512 МБ RAM и 0.5 CPU.
Если приложение превышает лимит — Docker его ограничит или остановит.
5) Union File Systems (OverlayFS)
Docker использует многослойную файловую систему. Каждый шаг
Dockerfile создаёт новый слой. При запуске контейнера создаётся верхний writable-слой, остальные read-only.
👉 10 контейнеров на одном образе разделяют слои → экономия места.
6) Container Runtime
Docker использует
runc для запуска контейнера (соответствует OCI Runtime Spec). Daemon вызывает
runc, который через clone(), setns(), chroot() изолирует процесс.7) Docker Images
Образ — read-only слои, собранные в Union FS.
Каждый слой — изменения относительно предыдущего (например, установка пакета → новый слой).
Хранение: локально (
/var/lib/docker) или в реестре (Docker Hub, GitLab Container Registry).8) Docker Networking
Docker создаёт виртуальные сети (bridge, overlay, host).
По умолчанию контейнеры подключаются к bridge и получают IP из внутреннего пула.
👉 Можно пробросить порты через
-p, создать собственные сети, объединять контейнеры через docker network connect.В Swarm используется Overlay network (сеть между хостами).
9) Безопасность
Docker использует:
• seccomp (ограничение системных вызовов)
• AppArmor / SELinux (контроль привилегий)
• user namespaces (отображение UID контейнера в другой UID хоста)
⚠️ По умолчанию контейнеры имеют широкий доступ (например,
/proc виден). Для production стоит ограничивать права (например, --cap-drop).10) Что происходит при `docker run nginx`?
1. CLI отправляет запрос через API
2. Daemon ищет образ (локально или в registry)
3. Создаётся read-write слой контейнера
4. Создаются namespace (pid, net, mnt…)
5. Применяются cgroups
6. Вызывается
runc для изоляции процесса7. Контейнер подключается к сети
8. Запускается ENTRYPOINT/command
Контейнер живёт, пока жив его процесс.
11) Почему Docker — не магия?
Docker использует стандартные возможности ядра Linux (namespaces, cgroups, chroot, seccomp, overlayfs), оборачивая их в удобный интерфейс.
Контейнер — просто изолированный процесс, а не полноценная VM.
Поэтому Docker лёгкий, быстрый, удобный.
12) Заключение
Под капотом Docker:
• namespaces — изоляция
• cgroups — контроль ресурсов
• runc — запуск
• overlayfs — многослойная ФС
• REST API + Daemon + CLI — взаимодействие
Docker скрывает сложность, давая простой инструмент для запуска, сборки, развёртывания приложений.
Теперь, зная внутреннее устройство, можно глубже понять контейнеры, лучше их настраивать и оптимизировать.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤11👍4
GitOps-практики: развёртываем сервис через ArgoCD
Классический CI/CD запускает деплой. Но как сделать так, чтобы состояние Kubernetes после него соответствовало конфигурации в Git? На вебинаре разберём принципы GitOps и посмотрим, как ArgoCD помогает управлять изменениями в кластере.
7 октября в 20:00 МСК на открытом вебинаре OTUS развернём сервис в Kubernetes с помощью ArgoCD и покажет работу подхода на практике.
На практике рассмотрим:
— чем GitOps отличается от классического CI/CD и когда его применять;
— как устроен ArgoCD и какие есть варианты реализации GitOps;
— как развернуть сервис в Kubernetes через ArgoCD;
— что произойдёт при изменении конфигурации напрямую в кластере;
— какие подходы к работе с ArgoCD полезны в проектах.
После вебинара вы поймёте принципы GitOps, познакомитесь с возможностями ArgoCD и увидите полный процесс развёртывания сервиса. Полученные подходы сможете применить при работе со своими Kubernetes-кластерами.
Урок проходит в преддверии старта курса «DevOps. Экспертный уровень».
👉 Регистрируйтесь: https://vk.cc/d2t4v4
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
Классический CI/CD запускает деплой. Но как сделать так, чтобы состояние Kubernetes после него соответствовало конфигурации в Git? На вебинаре разберём принципы GitOps и посмотрим, как ArgoCD помогает управлять изменениями в кластере.
7 октября в 20:00 МСК на открытом вебинаре OTUS развернём сервис в Kubernetes с помощью ArgoCD и покажет работу подхода на практике.
На практике рассмотрим:
— чем GitOps отличается от классического CI/CD и когда его применять;
— как устроен ArgoCD и какие есть варианты реализации GitOps;
— как развернуть сервис в Kubernetes через ArgoCD;
— что произойдёт при изменении конфигурации напрямую в кластере;
— какие подходы к работе с ArgoCD полезны в проектах.
После вебинара вы поймёте принципы GitOps, познакомитесь с возможностями ArgoCD и увидите полный процесс развёртывания сервиса. Полученные подходы сможете применить при работе со своими Kubernetes-кластерами.
Урок проходит в преддверии старта курса «DevOps. Экспертный уровень».
👉 Регистрируйтесь: https://vk.cc/d2t4v4
Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576
❤1💩1
Настраиваем простой healthcheck для Docker-контейнера!
Контейнер может быть запущен, но приложение внутри него уже не отвечает. Поэтому одного docker ps часто недостаточно: нужен healthcheck, который будет регулярно проверять состояние сервиса.
Представим простой HTTP-сервис, который отвечает на /health:
curl -f http://localhost:8080/health
Если команда возвращает код 0, контейнер считается здоровым. Если команда падает несколько раз подряд, Docker помечает контейнер как unhealthy.
В Dockerfile можно добавить HEALTHCHECK:
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
CMD curl -f http://localhost:8080/health || exit 1
Параметры задают частоту проверки, максимальное время ожидания и число неудачных попыток.
Соберём образ:
docker build -t app-with-health .
Запустим контейнер:
docker run -d --name app app-with-health
Теперь статус будет виден прямо в списке контейнеров:
docker ps
В выводе можно увидеть состояние:
Up 2 minutes (healthy)
Если нужно посмотреть healthcheck подробнее, используем inspect:
docker inspect --format '{{json .State.Health}}' app
А чтобы вывести только текущий статус:
docker inspect --format '{{.State.Health.Status}}' app
Ожидаемый результат:
healthy
Healthcheck особенно полезен в связке с оркестраторами и deploy-скриптами, можно отличать “процесс запущен” от “приложение реально готово принимать запросы”.
Контейнер может быть запущен, но приложение внутри него уже не отвечает. Поэтому одного docker ps часто недостаточно: нужен healthcheck, который будет регулярно проверять состояние сервиса.
Представим простой HTTP-сервис, который отвечает на /health:
curl -f http://localhost:8080/health
Если команда возвращает код 0, контейнер считается здоровым. Если команда падает несколько раз подряд, Docker помечает контейнер как unhealthy.
В Dockerfile можно добавить HEALTHCHECK:
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
CMD curl -f http://localhost:8080/health || exit 1
Параметры задают частоту проверки, максимальное время ожидания и число неудачных попыток.
Соберём образ:
docker build -t app-with-health .
Запустим контейнер:
docker run -d --name app app-with-health
Теперь статус будет виден прямо в списке контейнеров:
docker ps
В выводе можно увидеть состояние:
Up 2 minutes (healthy)
Если нужно посмотреть healthcheck подробнее, используем inspect:
docker inspect --format '{{json .State.Health}}' app
А чтобы вывести только текущий статус:
docker inspect --format '{{.State.Health.Status}}' app
Ожидаемый результат:
healthy
Healthcheck особенно полезен в связке с оркестраторами и deploy-скриптами, можно отличать “процесс запущен” от “приложение реально готово принимать запросы”.
👍6❤3