🧅 Сидит дед, в сто шуб одет 🧅

Мы уже не раз касались такой темы как Layered File System в Docker (6, 19, 41, 64). И уже хорошо знаем, что благодаря этому механизму обеспечивается приличное количество фич, упрощающих процесс разработки. Особенно в условиях новомодного микросервисного ада!🤯

Но как же это реализовано изнутри?? Давайте глянем.

Как мы уже говорили, есть image layer и writable layer. Если быть честным, то и того и другого слоев будет несколько. Просто то, что было сделано в базовом образе, называется image layer и по своей сути является неизменным (read-only). Writable layer же - это чистое поле для экспериментов и каждое изменение фиксируется в нем как отдельный слой со своим хэш-ом - названием (наподобие commit hash в git-е).

Как хранится?
Docker хранит эти слои как отдельные директории в /var/lib/docker/driver_name/

/var/lib/docker/overlay2/
├── abc123.../diff     # Слой с изменениями
├── def456.../diff     # Еще один слой
├── ......
└── merged/            # Итоговая FS

За всем этим колдунством стоит так называемый UnionFS. Storage driver-ы склеивают слои через механизм union mount. Верхние слои "перекрывают" нижние. Если файл меняется в нескольких слоях - побеждает верхний. Таким образом обеспечивается актуальность изменений.

CoW:
Операции I/O реализованны через стратегию Copy-on-Write
🔹Read: файл читается из read-only слоев
🔹Write: когда мы пытаемся изменить файл в базовом образе, он копируется в верхний writable слой, и изменяется именно копия исходного файла
🔹Delete: создается "whiteout" файл, скрывающий нижний слой


Хеширование и дедупликация:
Каждый слой идентифицируется SHA256 (об этом чутка упоминал выше). Одинаковые слои физически хранятся один раз, независимо от количества образов!

Зачем эта сложность?
🔹Пересобираются только измененные слои
🔹Скачиваются только новые слои
🔹Один слой на много образов = оптимизация хранения


Теперь ты знаешь, почему docker pull иногда показывает "Already exists" - Docker просто переиспользует существующие слои!

Ставь 🤯, если ничего не понятно, но очень интересно и ты просто требуешь пояснительной бригады в виде длино-поста с красивыми картинками!🤓


🥷 Docker Ninja 🥷

🕳 Если долго смотреть в cgroup, cgroup начинает смотреть в тебя 🕳

По вашим заявкам в посте про cgroups продолжаем углубляться в кроличью нору дальше. Что ж, мои дорогие любители покопаться в кишочках, давайте приступим. 🙏🏻

🔍 Находим нужную cgroup
Ищем ID контейнера, чтобы знать в какую папку стучать

ddocker inspect test-container | grep Id

🤿 Теперь ныряем в его метрики:
💾 Метрики памяти

# Текущее использование памяти
cat /sys/fs/cgroup/memory/docker/CONTAINER_ID/memory.usage_in_bytes

# Лимит памяти контейнера
cat /sys/fs/cgroup/memory/docker/CONTAINER_ID/memory.limit_in_bytes

# Детальная статистика памяти
cat /sys/fs/cgroup/memory/docker/CONTAINER_ID/memory.stat

# Пиковое потребление памяти
cat /sys/fs/cgroup/memory/docker/CONTAINER_ID/memory.max_usage_in_bytes

# Swap использование
cat /sys/fs/cgroup/memory/docker/CONTAINER_ID/memory.memsw.usage_in_bytes

🖥 CPU метрики

# Общее время CPU в наносекундах
cat /sys/fs/cgroup/cpuacct/docker/CONTAINER_ID/cpuacct.usage

# CPU usage по ядрам
cat /sys/fs/cgroup/cpuacct/docker/CONTAINER_ID/cpuacct.usage_percpu

# Детальная статистика CPU
cat /sys/fs/cgroup/cpu/docker/CONTAINER_ID/cpu.stat

# Время в user/system mode
cat /sys/fs/cgroup/cpuacct/docker/CONTAINER_ID/cpuacct.stat

# CPU throttling статистика
cat /sys/fs/cgroup/cpu/docker/CONTAINER_ID/cpu.throttling_data

💿 Block I/O метрики

# Статистика по чтению/записи
cat /sys/fs/cgroup/blkio/docker/CONTAINER_ID/blkio.throttle.io_service_bytes

# IOPS счетчики
cat /sys/fs/cgroup/blkio/docker/CONTAINER_ID/blkio.throttle.io_serviced

# Время обслуживания I/O
cat /sys/fs/cgroup/blkio/docker/CONTAINER_ID/blkio.time

🥶Наш любимый freezer

# Текущее состояние контейнера
cat /sys/fs/cgroup/freezer/docker/CONTAINER_ID/freezer.state

# PID родительского процесса контейнера
cat /sys/fs/cgroup/freezer/docker/CONTAINER_ID/cgroup.procs

# Список всех потоков (threads), принадлежащих контейнеру (в старых версиях ядра).
cat /sys/fs/cgroup/freezer/docker/CONTAINER_ID/tasks

Как мы уже разобрали в первом посте про cgroups, docker stats и флаг --memory работают именно с этими файлами.
Но, линукс не линукс, если бы все было так просто... Данная файловая структура актуальна для cgroups v1. Поэтому, ставь 🔥 если хочешь узнать про то, как работать с файлами cgroups v2.


🥷 Docker Ninja 🥷

🧼 Моя оборона! 🧼

Я где-то слышал, что практически каждый второй Docker-образ, будь то Docker Hub или же приватные registry содержит критические уязвимости, но мы же продолжаем пулить их как ни в чем не бывало!

Проверять это утверждение я конечно же не буду, но не удивлюсь, если это окажется правдой... Да и как предлог заколлабиться с безопасниками и реализовать что-то новенькое для своего портфолио хороший!😏
Так шо сегодня разберем с вами Docker Scout - встроенный сканер безопасности докер образов aka "нет пробития"! Ага, прикиньте, есть такой. Я сам однажды офигел!!!

🔐 Запускаем сканирование

# Сканируем локальный образ
docker scout cves nginx:latest

# Получим что-то типа такого
✔️ Image stored for indexing
┌───────────────┬────────┬──────────┬───────────────┐
│ CVE           │ Score  │ Severity │ Package       │
├───────────────┼────────┼──────────┼───────────────┤
│ CVE-2023-1234 │ 8.2    │ HIGH     │ libc6         │
│ CVE-2023-5678 │ 6.5    │ MEDIUM   │ openssl       │
│ CVE-2023-9012 │ 4.3    │ LOW      │ zlib          │
└───────────────┴────────┴──────────┴───────────────┘
Summary: 15 vulnerabilities found (3 critical, 5 high, 4 medium, 3 low)

# Или прямо при сборке
docker scout cves local://my-app:v1.0

После docker login можем сканировать приватные образы:

docker scout cves registry.company.com/my-private-app:latest

📊 Детальный анализ

# Сканирование с рекомендациями по исправлению
docker scout recommendations nginx:latest

# Анализ по критичности (только HIGH и CRITICAL)
docker scout cves --severity high,critical node:18-alpine

# Сравнение двух версий образа
docker scout compare nginx:1.20 --to nginx:1.21

# Анализ конкретного слоя
docker scout cves --layer-details postgres:15

## Вывод довольно читабельный
Layer 1: base image (debian:bullseye)
├── CVE-2023-1234 (HIGH) in libc6
└── CVE-2023-5678 (MEDIUM) in openssl

Layer 3: application dependencies
├── CVE-2023-9012 (CRITICAL) in python3.9
└── CVE-2023-3456 (HIGH) in postgresql-15

💡Что еще умеет?
🔹 Scout анализирует не только OS-пакеты, но и зависимости языков (Node.js, Python, Java, а это уже вполне себе такой Software Composition Analisys)
Кстати, тул умеет выгружать эту аналитику в sbom файл, который потом можно грузануть в какую-нибудь систему аналитики уязвимостей (типа Dependency Track или DefectDojo)
🔹 Интегрируется с Docker Desktop для GUI-анализа
🔹 Поддерживает webhook-и для автоматических уведомлений


Теперь об обороне стало думать легче, тылы прикрыты, так что можно спокойно ронять мыло в общественных местах💪🏻


Ставь 😎 если уже представляешь, как твой security-отдел будет тебя благодарить!


🥷 Docker Ninja 🥷

🐧Некоторым птицам не место в контейнере. У них слишком яркие перья🐧

Ну и заключительный пост про файлы cgroups (первый, второй).

Начиная с версии ядра Linux 4.5 мы взаимодействуем с cgroups v2, который стал более структурированный, чем первая версия.

Выглядит это дело так:
🎯Определяем директорию нашего контейнера:

# Запускаем контейнер
docker run -d --name test-app nginx

# Путь к cgroup контейнера
CGROUP_PATH="/sys/fs/cgroup/system.slice/docker-$(docker inspect -f '{{.Id}}' test-app).scope"

🧠Memory

# Текущее потребление памяти
cat $CGROUP_PATH/memory.current
# 52428800 (50MB в байтах)

# Максимальное потребление с момента старта
cat $CGROUP_PATH/memory.max
# max (без лимитов)

# Детальная статистика памяти
cat $CGROUP_PATH/memory.stat
# anon 12582912
# file 8388608
# kernel_stack 32768

⚡️CPU

# Статистика использования CPU
cat $CGROUP_PATH/cpu.stat
# usage_usec 1542340
# user_usec 890123
# system_usec 652217

# Помечен ли процесс контейнера как "с минимальным приоритетом"
cat $CGROUP_PATH/cpu.idle

# Текущий вес процесса
cat $CGROUP_PATH/cpu.weight
# 100

💾I/O

# Статистика ввода-вывода
cat $CGROUP_PATH/io.stat
# 8:0 rbytes=1048576 wbytes=4096 rios=64 wios=8

# Текущий I/O pressure
cat $CGROUP_PATH/io.pressure
# some avg10=0.00 avg60=0.00 avg300=0.00 total=0

🧊Freezer

# Проверяем текущее состояние
cat $CGROUP_PATH/cgroup.freeze
# 0 (разморожен)

# Замораживаем контейнер без docker cli
echo 1 > $CGROUP_PATH/cgroup.freeze
# После выполнения попробуй зайти в терминал контейнера

# Проверяем состояние
cat $CGROUP_PATH/cgroup.freeze
# 1 (заморожен)

# Размораживаем обратно
echo 0 > $CGROUP_PATH/cgroup.freeze

🚨Контроль процессов

# Список PID-ов в контейнере  
cat $CGROUP_PATH/cgroup.procs
# 1234
# 1235

# События cgroup (убийства OOM, миграции и проч.)
cat $CGROUP_PATH/cgroup.events
# populated 1
# frozen 0

В большинстве случаев, вы столкнетесь именно с cgroups v2. Поэтому полезно углубиться именно в этот вариант каталогов.

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

Но, если есть желание закопаться еще глубже, то ставьте ваши 👍🏻 на пост. 25+ 👍🏻 станут для меня знаком, что стоит копнуть еще и в линукс.

🥷 Docker Ninja 🥷

🧙🏾‍♂️Раньше был я Гендальф Серый. А теперь я Саша Белый 🧙‍♂️

Пятница. 18:00. Ты уже одной ногой в уличном ботинке. Но тут в телегу предательски прилетает алерт - одному из сервисов в контейнере не хватает памяти...

Заходишь на хост. Видишь, что свободной памяти еще выше крыши. Но метрики показывают другое.

Смотришь в inspect контейнера и видишь, что при запуске дали ограничение в половину всей памяти хоста. Ребутать(пык, мык) или стопать контейнер не вариант - инстанс сервиса только один, так что прод сразу встанет, а ты ляжешь под обильными плевками коллег, решивших расслабиться в вечер пятницы.

Что же делать? Как расширить память запущенного контейнера?

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

🎯 Базовое использование:
Ограничиваем прожорливый контейнер:

# Урезаем память до 512MB
docker update --memory=512m my-app

Можно обновлять сразу несколько контейнеров:

# Апдейтим все контейнеры с префиксом web
docker update --memory=256m web-app-1 web-app-2 web-app-3

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

Помнишь лимиты памяти и политики рестарта? Их, к слову, тоже можно менять налету с помощью данной команды!

Как обычно, ставь свои реакты. Так я буду знать, что пост зашел, а мне стоит продолжать делиться знаниями в подобном формате!

🥷 Docker Ninja 🥷

©️Хорошие копируют, великие воруют🦝

Мы с вами уже довольно хорошо погрузились в различные аспекты написания Dockerfile. Все может казаться просто и лаконично: захотел закинуть сорсы в контейнер - используй COPY; надо закинуть что-то из архива - втыкай ADD; слишком тяжелая сборка - пробуй multistage build.

Но порою, меняешь одну строчку в коде, а сборка после этого идет 15 минут. Как будто Docker внезапно забыл про все свои слои и решил: "А давайте-ка пересоберем все с нуля!"

А ведь проблема часто кроется в бездумных COPY в твоем Dockerfile.

Так шо сегодня рассмотрим best practices для COPY, которые превратят твою сборку в пушку ракету!🚀

Правило №1: Зависимости копируем отдельно
Частный случай для следующего правила, но стоит рассмотреть его отдельно

# ❌ Плохо - весь контекст копируется сразу  
COPY . /app
RUN npm install

Делаем так:

# ✅ Хорошо - сначала только package.json
COPY package*.json /app/
RUN npm install
COPY . /app/

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

COPY requirements.txt /app/    # Меняется редко
RUN pip install -r requirements.txt
COPY some_noscript.sh /noscripts/ # Меняется средне
COPY src/ /app/src/           # Меняется средне  
COPY main.py /app/            # Меняется часто

Правило №3: Дружи с .dockerignore
Смотрим пост про .dockerignore и проникаемся

# ❌ Опасно - копируем весь мусор, а в довесок и секреты 
COPY . /app

# ✅ Безопасно - фильтруем через .dockerignore
## Создай .dockerignore рядом с Dockerfile:
node_modules
.git
*.log
.env
.idea
.vscode
dist
Dockerfile
.dockerignore

Правило №4: Multi-stage для чистых артефактов
Собираем в одном образе, забираем результат в другом

FROM golang:1.23 AS sdk
...
RUN go build -o /bin/hello ./main.go

FROM scratch
COPY /app/some_file.txt /app/file.txt
COPY --from=sdk /bin/hello /bin/hello
CMD ["/bin/hello"]

Зачем это нужно?

Представь: у тебя Node.js приложение, ты фиксишь баг в main.js. При правильном COPY пересоберется только один последний слой. При неправильном - весь npm install заново, а это могут быть гигабайты зависимостей!

В реальности это означает разницу между сборкой за 10 секунд и за 10 минут. Особенно критично для CI/CD пайплайнов, где каждая секунда на счету. Да и в момент разработки дико бесит, что нужно долго ждать пересборку...

Так что, воруйте все что здесь написано и ставьте ваши реакции!!!

🥷 Docker Ninja 🥷

😱 Игра началась 😱

Помнится, в самом начале моего девопсерского пути меня долго мучал вопрос, нафига нужен ENTRYPOINT если уже есть CMD? Преимущества второго ведь на лицо - его можно изменить при запуске контейнера.

Но как и в случае с "необязательным EXPOSE-ом", тут оказалось не так все просто...

Так что сегодня мы с вами слепим грузина с чемоданом и раз и навсегда разберемся в том, зачем нам ENTRYPOINT. Но для начала мини обзорчик как это дело функционирует.

Exec vs Shell форма
Как и с нашим старым знакомцем CMD, у ENTRYPOINT есть две формы записи:

# Exec форма (рекомендуемая)
ENTRYPOINT ["nginx", "-g", "daemon off;"]

# Shell форма
ENTRYPOINT nginx -g "daemon off;"

# Exec форма работает напрямую с ядром, без лишних оберток — быстрее и надежнее!

Комбинирование с CMD
А вот тут и начинается вся свистопляска...

ENTRYPOINT ["python", "app.py"]
CMD ["--help"]

# docker run myapp → выполнит python app.py --help
# docker run myapp --version → выполнит python app.py --version
# docker run myapp --config prod.conf → выполнит python app.py --config prod.conf
# ENTRYPOINT остается неизменным, а `CMD` становится аргументами по умолчанию!

Зачем это нужно?
ENTRYPOINT директива далеко не обязательная, но очень полезная. Из самых базовых кейсов можно привести следующие:

1️⃣ Нужно сделать из контейнера самостоятельную софтину.

docker run уже запускает нужный нам бинарник, а мы лишь назначаем аргументы в cmd (смотри пример выше)

2️⃣ Когда нужно гарантированно выполнить какой-либо скрипт.

Например делаем контейнер для запуска ансибла (такое практикуют если рабочи комп на винде). В `ENTRYPOINT` ставим скрипт, который грузит зависимые ansible модули из requirements, а в CMD указываем команды ансибла

3️⃣ Для правильной обработки сигналов ОС.

Для этого ставим в `ENTRYPOINT` то что мы собираемся запускать в контейнере (nginx, python, node). В `CMD` ставим его аргументы (my_app.py, server.js). В таком случае, если мы прервем работу контейнера штатными средствами (pause, stop), то сигнал получит не shell, а непосредственно то, что мы указали в `ENTRYPOINT`. А значит, мы получаем более корректное завершение работы нашего приложения.

Как обычно, ставьте ваши реакты, если хочется побольше таких постов! Всем peace✌🏻 и хороших выходных.

🥷 Docker Ninja 🥷

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

Сидишь ты значит, деплоишь в продакшен очередной микросервис, потирая красные от недосыпа глаза, как вдруг, ИБ-ешник присылает отчет Docker Scout с полным набором критических уязвимостей. Половина из них - в пакетах Ubuntu, которые твое приложение вообще никогда не юзает! Curl, wget, package manager - зачем это все в контейнере, если твой бинарник статически слинкован?

Первое что приходит на ум это аппнуть базовый образ - авось все уязвимые пакеты там пропатчены.

Но что, если образ уже последней версии? Будешь создавать свой образ Ubuntu в котором вырежешь все дырявые пакеты? Ну да, вариант, но до очередной уязвимости. А как будешь следить за патчами пакетов и самой ОС?

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

Distroless - это образы без дистрибутива. Звучит как сапожник без сапог, но тем не менее. Внутри только runtime-зависимости и все. Никаких shell-ов(да мы с вами об этом уже говорили - тык, брык), package manager-ов, лишних библиотек. Только то, что нужно твоему приложению для работы.

Сравни сам через docker images:

docker pull ubuntu:20.04
docker pull gcr.io/distroless/static-debian11

docker images
# Было (Ubuntu base)
ubuntu    20.04    b7bab04fd9aa   7 months ago    72.8MB
# Стало (Distroless)
gcr.io/distroless/static-debian12  latest  e021002e4213   N/A  2.08MB

Результат: образ сжался с 72MB до 2MB! 🎯

Зачем юзать:
💊 Меньше уязвимостей - меньше головной боли с security
💊 Микроскопический размер - быстрее пуллится и стартует
💊 Невозможно зайти в контейнер через shell - дополнительная защита
💊 Отлично сочетается с multi-stage builds

Google предоставляет варианты на любой вкус:
🔹 /static (без какого-либо рантайма, хорошо подходит для go)
🔹 /java,
🔹 /python,
🔹 /nodejs

Подобрать вариант под себя можно вот тут.

Минус только один: дебажить сложнее, так что обрадуйте своих любителей дебажить на проде - лафа закончилась😏

Попробовал Distroless? Ставь 🔥!

Этот пост лишь маленькая часть серии из 3-х постов про distroless и scratch образы. Ссылки на все части ты можешь найти в этом посте.

🥷 Docker Ninja 🥷