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. Существующие контейнеры продолжают жить на предыдущих версиях до явного пересоздания.
Зачем это нужно?
И не забывай про layer sharing - Docker Compose pull эффективно использует общие слои между образами. При обновлении образов с одинаковыми базовыми слоями загружаются только измененные layers!
Ты отправил дежурному его голубя обратно, указав в ответном письме
🥷 Docker Ninja 🥷
Please open Telegram to view this post
VIEW IN TELEGRAM
❤6🔥2😁2
🛻 Синий трактор едет к нам. Pt. 2🛻
Коллеги, вот уже второй год мы с вами встречаем новогодние праздники вместе! И в этом году, как и говорил, я подготовил для вас небольшой подарочек. Его вы найдете завтра под елкой в нашем канале!
Ну и конечно же, мои вам пожелания на новый год:
В новом году хочу пожелать вам энергии, крепкого здоровья, хорошего достатка, ну и конечно же по-больше приятных встреч с родными и близкими! Ведь именно этого не хватает нам ИТ-шникам в загруженные рабочие будни! С праздником вас, друзья!🥳
И не забывайте в новогоднюю ночь слова известного китайского мудреца:
🥷 Docker Ninja 🥷
Коллеги, вот уже второй год мы с вами встречаем новогодние праздники вместе! И в этом году, как и говорил, я подготовил для вас небольшой подарочек. Его вы найдете завтра под елкой в нашем канале!
Ну и конечно же, мои вам пожелания на новый год:
В новом году хочу пожелать вам энергии, крепкого здоровья, хорошего достатка, ну и конечно же по-больше приятных встреч с родными и близкими! Ведь именно этого не хватает нам ИТ-шникам в загруженные рабочие будни! С праздником вас, друзья!
И не забывайте в новогоднюю ночь слова известного китайского мудреца:
Самогон вина полезней -
Пей без мин трагических!
Он спасет от всех болезней,
Кроме венерических!
Лао-Цзы
🥷 Docker Ninja 🥷
Please open Telegram to view this post
VIEW IN TELEGRAM
🍾6🎄1
🎄Елочка гори!🎄
Коллеги, вот и пришла пора распаковывать наши подарочки!
Примерно в начале ноября передо мной встал вопрос, куда двигаться дальше. Помимо докера, есть еще множество интереснейших тем, о которых очень хочется вам поведать, поэтому на новогодних выходных я со всей силы работаю над новыми каналами по тематике Kubernetes и Linux. Тематика была выбрана не случайно - обе эти темы связаны с тематикой Docker и это дает большой простор для написания перекрестных постов за счет чего можно будет погрузиться в тему более детально.
Но сам подарок состоит не в том.
Новый год это не только обещания похудеть, бросить курить или начать читать по 40 книг в год, но и возможность пересмотреть свой прошлый опыт, чтобы определить вектор для будущего развития. Для меня таким вектором (близким мне по духу) стала идея построения этакого хаба знаний/сообщества для devops/sre - инженеров любого уровня. Поэтому, я принял решение развивать не только этот и озвученные выше каналы, но и Бусти. Это никак не скажется на качестве контента в телеграм каналах, но даст мне большую мотивацию и ресурсы для дальнейшего развития.
Сейчас я уже подготовил для вас на каждый день выходных расширенные версии постов с канала Docker Ninja. Ближе к 15 января вы сможете найти там и расширенные версии постов с каналов по Linux и Kubernetes еще до выхода в свет самих вышеозвученных каналов. Сам доступ к расширенным постам возможен за небольшую плату. Подробнее вы можете ознакомиться на самой странице Boosty . Но, с сегодняшнего дня и по 16 января все читатели канала смогут читать расширенные версии постов бесплатно перейдя по этой ссылке ! Поэтому, предлагаю вам ознакомиться на праздниках, пока доступ не закрылся.
Постов на канале Docker Ninja не будет до 12 января включительно.
А на этом у меня все. Спасибо за внимание! И хорошо вам отдохнуть и набраться сил перед новыми карьерными достижениями!💪
Коллеги, вот и пришла пора распаковывать наши подарочки!
Примерно в начале ноября передо мной встал вопрос, куда двигаться дальше. Помимо докера, есть еще множество интереснейших тем, о которых очень хочется вам поведать, поэтому на новогодних выходных я со всей силы работаю над новыми каналами по тематике Kubernetes и Linux. Тематика была выбрана не случайно - обе эти темы связаны с тематикой Docker и это дает большой простор для написания перекрестных постов за счет чего можно будет погрузиться в тему более детально.
Но сам подарок состоит не в том.
Новый год это не только обещания похудеть, бросить курить или начать читать по 40 книг в год, но и возможность пересмотреть свой прошлый опыт, чтобы определить вектор для будущего развития. Для меня таким вектором (близким мне по духу) стала идея построения этакого хаба знаний/сообщества для devops/sre - инженеров любого уровня. Поэтому, я принял решение развивать не только этот и озвученные выше каналы, но и Бусти. Это никак не скажется на качестве контента в телеграм каналах, но даст мне большую мотивацию и ресурсы для дальнейшего развития.
Постов на канале Docker Ninja не будет до 12 января включительно.
А на этом у меня все. Спасибо за внимание! И хорошо вам отдохнуть и набраться сил перед новыми карьерными достижениями!
Please open Telegram to view this post
VIEW IN TELEGRAM
1👍7❤4🔥3😍2🎅1
Посты за ноябрь 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
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥7❤2👍1
Посты за декабрь 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 для обновления образов сервисов
Please open Telegram to view this post
VIEW IN TELEGRAM
1🔥10❤3👍3
Тебе необходимо настроить веб-приложение с docker-compose.yml для запуска на проде. Для этого нужно изменить порты и добавить volume для hot-reload. Как лучше это сделать?
Anonymous Quiz
14%
Создать отдельный docker-compose-dev.yml файл
32%
Создать docker-compose.override.yml файл с изменениями
18%
Изменить основной docker-compose.yml файл
35%
Использовать переменные окружения в docker-compose.yml
😁2
🐟 И рыбку сьесть, и на стул присесть 🪑
Но не спеши паковать вещички! Встречай, единственный и неповторимый флаг --platform и его старший брат buildx (которого мы немножко касались вот тут) для multi-platform сборки!
По сути, multi-platform образы - это запакованные в единый образ несколько вариаций одного и того же контейнерного приложения. И конечно же, прежде чем запускать такой вот мултитул, необходимо собрать образ.
Вот как это выглядит в деле для одной платформы
А как же сборка через Dockerfile?
Не беспокойся, и тут все уже придумали! Вот тебе Dockerfile, который все знает
BuildKit автоматически проставит BUILDPLATFORM как платформу хоста, на котором идет сборка. TARGETPLATFORM ты укажешь через флаг --platform, а TARGETOS и TARGETARCH получатся из парсинга TARGETPLATFORM BuildKit-ом.
Проверка архитектуры образа
Кстати, самое главное, проверить архитектуру спулленного образа можно через уже знакомый docker inspect
Зачем это все нужно?
🎯 Нативная работа на Apple M1/M2 без тормозной эмуляции x86_64
🎯 Оптимальная производительность на ARM-серверах (AWS Graviton, Azure Ampere)
🎯 Поддержка IoT и edge-устройств на ARM
🎯 Единый образ для всей инфраструктуры - не нужно париться с версионированием отдельных build-ов
Так что теперь, когда твоя команда работает на зоопарке из Intel MacBook-ов, Apple Silicon и Linux-серверов, ты можешь собрать один образ и быть уверенным - он заработает везде!
Попробовал multi-platform сборку? Ставь 🔥, чтобы я знал, что не зря потратил время на объяснение всех этих архитектурных заморочек!
Кстати, для серьезных пацанов и девчонков советую углубиться в buildx, который может собрать сразу несколько архитектур одной командой. Подробности работы с ним, а так же особенности строения манифестов под multiplatform образы, нюансы эмуляции при кросс-компиляции вы можете увидеть в бусти Devops сенпая!
🥷 Docker Ninja 🥷
Сидишь ты такой в пятницу. Лениво пушишь в продакшен репо контейнер, собранный с новенького MacBook M2, подаренного на нг. А в голове ни капли беспойства, ведь все работает красиво на твоей ARM-машинке. А во вторник во время релиза прилетает алерт - приложение на x86_64-серверах AWS падает с загадочными ошибками архитектуры.
Релиз менеджер уже разминает свои голосовые связки и неголосовые сухожилия, перед тем, как начать тыкать тебя как котенка в обгаженный уголок...
Ты виновато заходишь в логи, а там "cannot execute binary file: Exec format error". И тут до тебя доходит - ты собрал образ под ARM, а продакшн крутится на Intel!
Первая мысль - ребутать все серверы и надеяться, что проблема рассосется сама. Вторая - начать собирать отдельные образы для каждой архитектуры и как-то их синхронизировать. Третья - тихо всплакнуть в салфеточку и искать новую работу.
Но не спеши паковать вещички! Встречай, единственный и неповторимый флаг --platform и его старший брат buildx (которого мы немножко касались вот тут) для multi-platform сборки!
По сути, multi-platform образы - это запакованные в единый образ несколько вариаций одного и того же контейнерного приложения. И конечно же, прежде чем запускать такой вот мултитул, необходимо собрать образ.
Вот как это выглядит в деле для одной платформы
# Собираем для AMD64 (классические серверы)
docker build --platform linux/amd64 -t myapp:amd64 .
# Собираем для ARM64 (Apple M1/M2, AWS Graviton)
docker build --platform linux/arm64 -t myapp:arm64 .
А как же сборка через Dockerfile?
Не беспокойся, и тут все уже придумали! Вот тебе Dockerfile, который все знает
# Этап 1: Сборщик. Используем платформу ХОСТА для скорости.
FROM --platform=$BUILDPLATFORM golang:1.21-alpine AS builder
# TARGETOS и TARGETARCH автоматически установлены BuildKit
ARG TARGETOS TARGETARCH
WORKDIR /app
COPY . .
# Компиляция под ЦЕЛЕВУЮ ОС и архитектуру
RUN CGO_ENABLED=0 GOOS=$TARGETOS GOARCH=$TARGETARCH go build -o /app/myapp .
# Этап 2: Финальный образ. Используем ЦЕЛЕВУЮ платформу.
FROM --platform=$TARGETPLATFORM alpine:3.18
RUN apk --no-cache add ca-certificates
COPY --from=builder /app/myapp /usr/local/bin/myapp
USER nobody
CMD ["myapp"]
BuildKit автоматически проставит BUILDPLATFORM как платформу хоста, на котором идет сборка. TARGETPLATFORM ты укажешь через флаг --platform, а TARGETOS и TARGETARCH получатся из парсинга TARGETPLATFORM BuildKit-ом.
Проверка архитектуры образа
Кстати, самое главное, проверить архитектуру спулленного образа можно через уже знакомый docker inspect
docker inspect myapp:amd64 | grep Architecture # Выводит архитектуру собранного образа
Зачем это все нужно?
🎯 Нативная работа на Apple M1/M2 без тормозной эмуляции x86_64
🎯 Оптимальная производительность на ARM-серверах (AWS Graviton, Azure Ampere)
🎯 Поддержка IoT и edge-устройств на ARM
🎯 Единый образ для всей инфраструктуры - не нужно париться с версионированием отдельных build-ов
Так что теперь, когда твоя команда работает на зоопарке из Intel MacBook-ов, Apple Silicon и Linux-серверов, ты можешь собрать один образ и быть уверенным - он заработает везде!
Попробовал multi-platform сборку? Ставь 🔥, чтобы я знал, что не зря потратил время на объяснение всех этих архитектурных заморочек!
Кстати, для серьезных пацанов и девчонков советую углубиться в buildx, который может собрать сразу несколько архитектур одной командой. Подробности работы с ним, а так же особенности строения манифестов под multiplatform образы, нюансы эмуляции при кросс-компиляции вы можете увидеть в бусти Devops сенпая!
🥷 Docker Ninja 🥷
🔥11👍6✍4❤1
Ты создаешь production-ready образ для Node.js приложения. В Dockerfile используете FROM node:18-alpine. Какую директиву стоит добавить для улучшения безопасности?
Anonymous Quiz
19%
RUN npm install -g npm@latest
6%
EXPOSE 3000
21%
WORKDIR /app
54%
USER node
❤1🔥1
В твоей компании возникла проблема: контейнеры запускаются, но процессы внутри них не отвечают на SIGTERM. В какой компонент Docker архитектуры ты полезешь, чтобы прочекать все за создание и управление жизненным циклом процессов контейнера?
Anonymous Quiz
16%
dockerd
37%
containerd
16%
runc
30%
Docker CLI
👌6
Направо пойдешь -... Налево пойдешь - ...
Коллеги, здравствуйте.
Мне очень неловко. Я надолго пропал, хотя обещал регулярно радовать вас контентом и новыми материалами. Это было связано с личными и рабочими обстоятельствами, но факт остаётся фактом: я не сдержал слово, и за это я искренне прошу прощения. Спасибо, кто остался🫶🏼
Планировал исправиться и вернуться с новыми силами, но теперь вмешался ещё и внешний фактор. Как вы знаете, в нашей стране появились серьёзные проблемы с доступом к Telegram. Канал перестал быть надёжной площадкой, где я могу гарантированно достучаться до каждого из вас.
Но бросать вас и обещанные темы я не хочу. Поэтому сейчас у меня к вам очень важный опрос.
Где вам было бы комфортно читать меня дальше? (выберите один или несколько вариантов, или предложите свой в директ канала)
➡️ ВКонтакте
➡️ Дзен
➡️ Max
➡️ Бесплатный доступ в boosty
Я очень дорожу вами и тем, что мы начали. Поэтому не хочу принимать решение за вас. Выберем платформы вместе, и там я уже буду отдавать все долги сполна — выпущу всё, что обещал, и даже больше.
Спасибо, что вы есть! Жду ваших голосов и идей в директ 👇
Коллеги, здравствуйте.
Мне очень неловко. Я надолго пропал, хотя обещал регулярно радовать вас контентом и новыми материалами. Это было связано с личными и рабочими обстоятельствами, но факт остаётся фактом: я не сдержал слово, и за это я искренне прошу прощения. Спасибо, кто остался🫶🏼
Планировал исправиться и вернуться с новыми силами, но теперь вмешался ещё и внешний фактор. Как вы знаете, в нашей стране появились серьёзные проблемы с доступом к Telegram. Канал перестал быть надёжной площадкой, где я могу гарантированно достучаться до каждого из вас.
Но бросать вас и обещанные темы я не хочу. Поэтому сейчас у меня к вам очень важный опрос.
Где вам было бы комфортно читать меня дальше? (выберите один или несколько вариантов, или предложите свой в директ канала)
Я очень дорожу вами и тем, что мы начали. Поэтому не хочу принимать решение за вас. Выберем платформы вместе, и там я уже буду отдавать все долги сполна — выпущу всё, что обещал, и даже больше.
P.S.
Переход в новые площадки не означает, что я перестану вести телегу. Этот канал все так же остается актуальным, просто мы с вам вместе придумаем удобные альтернативы.
P.S. 2
Я долго не хотел мириться с этой мыслью, но реальность оказалась сильнее. Изначально я планировал сделать несколько каналов по различным узким тематикам, чтобы каждый читал только то, что ему интересно.
Увы, придумывать такое количество тем для контента по узкой теме в одиночку оказалось не так то просто. Поэтому, отныне и навсегда данный канал будет называть Devops Senpai и будет покрывать все аспекты нашего непростого ремесла, а не только docker.
Спасибо, что вы есть! Жду ваших голосов и идей в директ 👇
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥8👌2👎1
👎32👍2👏2🤡1