📖Смотришь в книгу, видишь фигу👎

Бывает сидишь такой, никого не трогаешь, спокойно доживаешь последнюю недельку на работе и тут бац - прилетает алерт, что супер важный микросервис на проде упал. Лезешь в docker logs, но ничего не можешь увидеть, потому что контейнер лежит. Лезешь за ними в заведомо настроенный ELK/Opensearch и ничего не понимаешь. Никакой ошибки или баги не было. Сервис как будто просто вырубили руками.

И тут до тебя доходит, а вдруг кто-то еще не успел оклематься после новогоднего корпоратива и случайно удалил тот самый супер важный сервис? А что если это диверсия!??!?!?! Ужас!😱

В такие моменты хорошо бы узнать какие именно операции проводили с dockerd за последнее время. Какой контейнер падает, какой образ пуллится, какая сеть создается?

И тут на помощь приходит docker events! Эта команда подключается напрямую к потоку событий и показывает в реальном времени каждый чих происходящий на хосте с dockerd.

По сути, эта штука как логгер всех операций Docker daemon-а. Создал контейнер - событие. Остановил - событие. Скачал образ - тоже событие. Весь lifecycle твоих контейнеров как на ладони!

Базовый синтаксис такой:

# Мониторинг всех событий в реальном времени
docker events

2025-12-21T21:48:54.964163622+03:00 container kill f0770ec141f769b7330e1ff5fd206096c5ccc50a215803e75920a2cdc62bd080 (image=nginx, maintainer=NGINX Docker Maintainers <docker-maint@nginx.com>, name=elated_jepsen, signal=9)
2025-12-21T21:48:55.465756543+03:00 network disconnect 0a0d7305d434379c8336fc51f51e2a1bacd1065b0a24c18ec65eb53c1e061c63 (container=f0770ec141f769b7330e1ff5fd206096c5ccc50a215803e75920a2cdc62bd080, name=bridge, type=bridge)
2025-12-21T21:48:55.499566110+03:00 container die f0770ec141f769b7330e1ff5fd206096c5ccc50a215803e75920a2cdc62bd080 (execDuration=12, exitCode=137, image=nginx, maintainer=NGINX Docker Maintainers <docker-maint@nginx.com>, name=elated_jepsen)

Хоба! Кто-то из любимых коллекг кильнул этот контейнер!

А вот как это выглядит в деле:

# События за последний час = perfect для дебага
docker events --since "1h"

# События конкретного контейнера
docker events --filter container=webapp --filter type=container

Что умеет фильтровать:
Событий у докера может быть много и в них легко закопаться до следующего года. Так что полезно знать, что конкретно можно там увидеть.
⚙️ Типы объектов: container, image, network, volume - каждый тип живет своей жизнью
⚙️ События контейнеров: create, start, restart, stop, die, destroy, pause, unpause, kill, oom
⚙️ События образов: pull, push, delete, import, load, save, tag, untag
⚙️ По времени: устанавливаем интересующий нас диапазон


Зачем это надо?
➡️ Дебаг падающих сервисов - отслеживаешь последовательность start/die и понимаешь, где все пошло по причинному месту
➡️ Аудит в shared-окружении - видишь кто что делает через события create/destroy/pull, полезно для соблюдения политик ИБ
➡️ Автоматизация реакций - запускаешь скрипты или уведомления при определенных событиях
➡️ Отладка Docker Compose - смотришь порядок создания сетей и томов при сложных multi-service развертываниях
➡️ Мониторинг ресурсных проблем - ловишь OOM events раньше чем они убьют продакшен

Теперь ты можешь читать Docker daemon как открытую книгу без всяких фиг! Больше никаких тыканий пальцем в небо при дебаге. Попробовал docker events в деле? Ставь реакт!

🥷 Docker Ninja 🥷

🤫Secret Room🤭

Сидишь ты такой, делаешь ревью нового сервиса, а там в Dockerfile видишь шедевр: ENV POSTGRES_PASSWORD=supersecret123 прямо в переменных окружения! Ладно бы это был dev, так нет - продакшен! И еще этот Dockerfile валяется в гите, доступном всей команде из 30 человек, а образ запушен в публичный registry. А потом воздыхают, почему ИБ-шники постоянно закручивают гайки...

Или вот классика жанра: пароли зашиты прямо в Dockerfile, логи CI пестрят API-токенами, а в docker inspect можно прочитать всю подноготную приложения включая секретные ключи. И все это "потому что так быстрее", "потом переделаем", "да кто на наш тест полезет"...

Знакомо? Тогда давай разберем как делать правильно, чтобы ИБ-ешники не материли хотя бы твою родословную до седьмого колена!

Пароли, ключи и прочие чувствительные данные штука зависящая от конкретного контура где развертывается приложение (test, stage, prod). Не будем же мы юзать одни и те же секреты для прода и для теста (хотя я встречал и такое...). Поэтому, хорошо бы иметь возможность поместить их подстановку на этап деплоя. То есть в Docker Compose.

На такой случай придумали директиву secrets - встроенный сейф для всех твоих паролей, токенов и прочих деликатесов!

По сути, эта штука создает изолированное хранилище чувствительных данных, которые монтируются в контейнеры как файлы в памяти. Не в переменных окружения (которые светятся везде), не в обычных файлах на диске, а в защищенной tmpfs - файловой системе прямо в оперативке!

Вот как это выглядит в деле:

# docker-compose.yml
version: '3.8'

secrets:
  db_password:
    file: ./secrets/db_password.txt  # секрет из файла
  api_key:
    external: true  # секрет берется из внешнего источника

services:
  web:
    image: nginx
    secrets:
      - db_password  # подключение секрета к сервису
      - source: api_key
        target: /run/secrets/api_token  # монтирование с другим именем

Видишь? Секреты объявляются в отдельной секции, а потом подключаются к нужным сервисам. Никаких паролей в открытом тексте!

Как создаем?
Самые базовые способы - создать секрет из файла или переменной среды.

secrets:
  mysql_root_password:
    file: ./mysql_root_password.txt  # содержимое файла становится секретом

  database_url:
    environment: DATABASE_CONNECTION_STRING  # секрет создается из переменной окружения хоста

External секреты в самом первом примере - это когда секрет уже создан внешними инструментами или через некоторые механизмы Swarm, о которых поговорим в будущих постах.

Зачем это нужно?
➡️ ИБ-шники не кусаются - секреты не попадают в логи CI/CD, Docker registry и остаются изолированными от кода
➡️ Соответствие стандартам - корпоративные политики безопасности запрещают пароли в переменных окружения
➡️ Разные окружения - можешь использовать разные секреты для dev/staging/prod без изменения compose-файлов
➡️ Минимальная attack surface - секреты живут только в памяти контейнера, недоступны через файловую систему хоста
➡️ Ротация через override - можешь менять секреты через docker-compose.override.yml без правки основного файла

Но у встроенного механизма есть ограничения:
⚠️ нет автоматической ротации - привет протухшим сертам
⚠️ нет централизованного аудита - не видим где и что уже утекло, значит не знаем где дыры
⚠️ нет интеграции с enterprise-системами типа HashiCorp Vault или AWS Secrets Manager

Для сложных production-окружений все же лучше переходить на специализированные решения. Зато для большинства задач Docker Compose secrets - это идеальный баланс простоты и безопасности!

Теперь ты знаешь как хранить секреты по-человечески, а не светить ими на всю вселенную!

Полезно - ставь реакт! А теперь предлагаю удалиться на выходнульки, чтобы сделать последний рывок перед 2к26!

🥷 Docker Ninja 🥷

🙃Post-Monday brain loading🙃

30.12.2025 Вторник 09:30 🥱. Ты опрокидываешь 4-ю стопку эспрессо и удобно располагаешься в своем рабочем кресле, чтобы сделать 2-минутную передышку перед очередной задачей. Но опухшие веки медленно, но верно смыкаются. Тело рязмякает и ты проваливаешься в объятья Морфея...

Где то на фоне ты слышишь постоянно повторяющиеся ритмичные звуки: ты ты ты - тыыы тыыы тыыы - ты тыыы тыыы ты. Ты открываешь глаза, а вокруг все черное белое. Ты едешь в трамвае. На старинных часах марки "Заря" стоит дата 6 октября 2025 года. В правой руке ты держишь дискету с надписью nginx.tar.

И тут ты понимаешь, такое уже было - ты в прошлом. И, чтобы выбраться из этой временной ловушки, необходимо доехать до офиса и сделать полноценный образ, который ты сохранил когда-то давно с помощью docker save. Но как это сделать ты не знаешь...

И тут на помощь приходит команда docker load!

Эта команда умеет воскрешать Docker-образы из tar-архивов, созданных через docker save.

Вот как это выглядит в деле:

# На исходном сервере: пакуем образ в архив
docker save -o myapp.tar myapp:latest

# На целевом сервере: распаковываем обратно
docker load -i myapp.tar

# Или через pipe без промежуточного файла
docker save myapp:latest | docker load

Видишь? Ты этими командами говоришь Docker достать из архива не только файлы, но и всю структуру слоев, историю команд, теги - все что было в оригинальном образе. А далее восстановить все как было: слои, метаданные, теги, всю родословную образа.

А чем же docker load отличается от docker import?
Тут как разница между полным бекапом системы и копированием домашней папки. docker load восстанавливает весь образ со всеми потрохами, а docker import создает новый образ из файловой системы, теряя всю историю. Если тебе нужно именно перенести готовый образ, то подходит только load!

Зачем это нужно?
➡️ Air-gapped развертывания: когда интернет - роскошь
➡️ Миграция между дата-центрами через флешки (да, бывает и такое!)
➡️ Disaster recovery: храним критические образы локально, чтобы никто не уволок
➡️ Медленный интернет: лучше один раз скачать и развезти

А вот что мы можем найти внутри tar-архива
📀 blobs/sha256/ - файлы слоев образа
📀 index.json - указатель на манифесты (в папке blobs/sha256/) для разных архитектур образа
📀 manifest.json - это легаси вариант того самого манифеста, который указывает как и в каком порядке соединять слои образа
📀 oci-layout - содержит версию формата oci и помогает инструментам определить, что это OCI-совместимый образ
📀 repositories - содержит соответствие тегов образа хешам манифестов

Docker читает manifest.json, восстанавливает граф зависимостей слоев, проверяет SHA256 хэши и регистрирует все это богатство в локальном хранилище.

Так что теперь ты знаешь как загрузить образы из архива и спасти себя от повторного проживания 3 месяцев до Нового Года! Фухх, сон отпускает. Ты возвращаешься к работе и ставишь реакт на новый пост в канале...

🥷 Docker Ninja 🥷

🔫Pullp fiction🔫

31 декабря. Воздух пронизан заливной рыбой и мандаринками. Ты шагаешь в местный магазин за горошком для оливьехи. Но тут тебе на плечо садится почтовый голубь с письмом от коллеги-дежурного на НГ (вот ведь бедолага...):
- Привет! Решил развернуть все наше инфраструктурное окружение (Nginx, PostgreSQL, Redis, RabbitMQ, ELK, Consul, Vault и еще пару штуковин...) у себя на рабочем компе, чтобы потестить кое-какую штуку. Запустил docker compose up -d и положил всю сеть в офисе... Что делать??

- Однако, - думаешь ты. - Ну что же, надо выручать коллегу!

Можно конечно через docker pull каждый образ по отдельности тащить, но когда у тебя полтора десятка сервисов, это превращается в пытку. А docker compose up с таким количеством сервисов, как видим, сразу отъедает большую часть сетевого канала.

Уверен, что команду docker compose pull придумали специально для тех, кто трудится не покладая рук даже по праздникам!

По сути, эта штука парсит твой docker-compose.yml, вытаскивает все образы из секций image и тихо-мирно скачивает их с registry. Никаких остановок сервисов, никаких пересозданий контейнеров, никаких тебе указаний названия и тэга образа - просто обновляет локальный кеш нужных тебе образов и все!

Базовый синтаксис элементарен:

# Загружает образы для всех сервисов из docker-compose.yml
docker compose pull

А если вдруг нужно спуллить что-то конкретное, то делаем так

# Обновляешь образы только для указанных сервисов
docker compose pull web database redis

Представь у тебя такой compose-файл:

version: '3.8'
services:
  web:
    image: nginx:1.21
  api:
    image: myapp:latest
  database:
    image: postgres:14

Команда проверяет доступность новых версий для nginx:1.21, myapp:latest и postgres:14 в registry и загружает их в локальное хранилище Docker daemon. Существующие контейнеры продолжают жить на предыдущих версиях до явного пересоздания.

Зачем это нужно?
➡️ Минимизируем downtime при обновлениях - предварительная загрузка образов позволяет быстро перезапускать сервисы без ожидания скачивания
➡️ Валидируем образы перед деплоем - проверяешь существование указанных образов в registry до начала обновления продакшна
➡️ Оптимизируем CI/CD pipeline - разделяешь этапы загрузки образов и их применения для лучшего контроля процесса
➡️ Готовимся к rolling updates - обеспечиваешь наличие новых образов на всех хостах кластера перед началом поэтапного обновления
➡️ Blue-green deployments - подготавливаешь образы для обеих сред заранее

И не забывай про layer sharing - Docker Compose pull эффективно использует общие слои между образами. При обновлении образов с одинаковыми базовыми слоями загружаются только измененные layers!

Ты отправил дежурному его голубя обратно, указав в ответном письме, что можно спуллить необходимые компоненты через docker compose pull по одному ссылку на этот пост, совсем забыв, что сеть в офисе лежит намеренно, ведь в такой день важно замедлиться, отложить рабочие дела и расслабиться за вычиткой постов из любимого канала имя которому...

🥷 Docker Ninja 🥷

🛻 Синий трактор едет к нам. Pt. 2🛻

Коллеги, вот уже второй год мы с вами встречаем новогодние праздники вместе! И в этом году, как и говорил, я подготовил для вас небольшой подарочек. Его вы найдете завтра под елкой в нашем канале!

Ну и конечно же, мои вам пожелания на новый год:
В новом году хочу пожелать вам энергии, крепкого здоровья, хорошего достатка, ну и конечно же по-больше приятных встреч с родными и близкими! Ведь именно этого не хватает нам ИТ-шникам в загруженные рабочие будни! С праздником вас, друзья!🥳

И не забывайте в новогоднюю ночь слова известного китайского мудреца:

Самогон вина полезней -
Пей без мин трагических!

Он спасет от всех болезней,
Кроме венерических!

Лао-Цзы

🥷 Docker Ninja 🥷

🎄Елочка гори!🎄

Коллеги, вот и пришла пора распаковывать наши подарочки!

Примерно в начале ноября передо мной встал вопрос, куда двигаться дальше. Помимо докера, есть еще множество интереснейших тем, о которых очень хочется вам поведать, поэтому на новогодних выходных я со всей силы работаю над новыми каналами по тематике Kubernetes и Linux. Тематика была выбрана не случайно - обе эти темы связаны с тематикой Docker и это дает большой простор для написания перекрестных постов за счет чего можно будет погрузиться в тему более детально.

Но сам подарок состоит не в том.
Новый год это не только обещания похудеть, бросить курить или начать читать по 40 книг в год, но и возможность пересмотреть свой прошлый опыт, чтобы определить вектор для будущего развития. Для меня таким вектором (близким мне по духу) стала идея построения этакого хаба знаний/сообщества для devops/sre - инженеров любого уровня. Поэтому, я принял решение развивать не только этот и озвученные выше каналы, но и Бусти. Это никак не скажется на качестве контента в телеграм каналах, но даст мне большую мотивацию и ресурсы для дальнейшего развития.

Сейчас я уже подготовил для вас на каждый день выходных расширенные версии постов с канала Docker Ninja. Ближе к 15 января вы сможете найти там и расширенные версии постов с каналов по Linux и Kubernetes еще до выхода в свет самих вышеозвученных каналов. Сам доступ к расширенным постам возможен за небольшую плату. Подробнее вы можете ознакомиться на самой странице Boosty. Но, с сегодняшнего дня и по 16 января все читатели канала смогут читать расширенные версии постов бесплатно перейдя по этой ссылке! Поэтому, предлагаю вам ознакомиться на праздниках, пока доступ не закрылся.

Постов на канале Docker Ninja не будет до 12 января включительно.

А на этом у меня все. Спасибо за внимание! И хорошо вам отдохнуть и набраться сил перед новыми карьерными достижениями!💪

Посты за ноябрь 2025

➡️ Работа с файлами cgroups v2 для мониторинга Docker контейнеров
➡️ Команда `docker update` для изменения ограничений ресурсов работающих контейнеров
➡️ Файл .dockerignore: исключение файлов из Build Context при сборке образов
➡️ Best practices при использовании инструкции COPY в Dockerfile: оптимизация кэширования слоев
➡️ Директива ENTRYPOINT в Dockerfile: разница с CMD и практическое применение
➡️ Distroless образы в Docker: минимализм для продакшена
➡️ Конфигурационный файл daemon.json: где лежит и зачем нужен
➡️ Флаг `--cpus` в Docker: точное ограничение процессорного времени
➡️ FROM scratch образы в Docker: как запускать приложения в пустых контейнерах
➡️ Флаг `--cap-add` в Docker: предоставление дополнительных Linux capabilities контейнеру
➡️ Секция `volumes` в Docker Compose: маппинг томов и bind mounts

Посты за декабрь 2025

➡️ Shell и Exec формы инструкций в Distroless и FROM scratch образах: как работают команды без shell
➡️ Docker Compose override файлы: как перезаписывать конфигурации для разных окружений
➡️ Директива MAINTAINER в Dockerfile: deprecated инструкция и альтернативы через LABEL
➡️ Docker Image Manifest и Registry V2 API: как устроено хранение метаданных образов
➡️ Docker Engine plugins: расширение функциональности через внешние модули
➡️ Команды `docker stop и start` для перезапуска контейнеров
➡️ Команда `docker network ls` для просмотра созданных сетей
➡️ Директива VOLUME в Dockerfile: автоматическое создание точек монтирования
➡️ Docker Container Runtime и containerd: архитектура исполнения контейнеров
➡️ Флаг `--privileged` в Docker: когда контейнер получает полный доступ к хосту
➡️ Команда docker events для мониторинга событий Docker в реальном времени
➡️ Секция secrets в Docker Compose: безопасное управление паролями и токенами
➡️ Команда docker load для импорта образов из tar-архивов
➡️ Команда docker compose pull для обновления образов сервисов

Направо пойдешь -... Налево пойдешь - ...

Коллеги, здравствуйте.

Мне очень неловко. Я надолго пропал, хотя обещал регулярно радовать вас контентом и новыми материалами. Это было связано с личными и рабочими обстоятельствами, но факт остаётся фактом: я не сдержал слово, и за это я искренне прошу прощения. Спасибо, кто остался🫶🏼

Планировал исправиться и вернуться с новыми силами, но теперь вмешался ещё и внешний фактор. Как вы знаете, в нашей стране появились серьёзные проблемы с доступом к Telegram. Канал перестал быть надёжной площадкой, где я могу гарантированно достучаться до каждого из вас.

Но бросать вас и обещанные темы я не хочу. Поэтому сейчас у меня к вам очень важный опрос.

Где вам было бы комфортно читать меня дальше? (выберите один или несколько вариантов, или предложите свой в директ канала)
➡️ ВКонтакте
➡️ Дзен
➡️ Max
➡️ Бесплатный доступ в boosty

Я очень дорожу вами и тем, что мы начали. Поэтому не хочу принимать решение за вас. Выберем платформы вместе, и там я уже буду отдавать все долги сполна — выпущу всё, что обещал, и даже больше.

P.S.
Переход в новые площадки не означает, что я перестану вести телегу. Этот канал все так же остается актуальным, просто мы с вам вместе придумаем удобные альтернативы.

P.S. 2
Я долго не хотел мириться с этой мыслью, но реальность оказалась сильнее. Изначально я планировал сделать несколько каналов по различным узким тематикам, чтобы каждый читал только то, что ему интересно.
Увы, придумывать такое количество тем для контента по узкой теме в одиночку оказалось не так то просто. Поэтому, отныне и навсегда данный канал будет называть Devops Senpai и будет покрывать все аспекты нашего непростого ремесла, а не только docker.

Спасибо, что вы есть! Жду ваших голосов и идей в директ 👇