🦅 Это птица! Это самолет! Это docker compose! 🛩

Товарищ compose, как мы все с вами знаем, удивительно полезный инструмент для управления множеством контейнеров. Но помимо запуска, он ещё умеет и в сборку образов.

services:
  bird:
    image: birds/parrot
    build: ./parrot

  plane:
    image: planes/airbus
    build:
      context: airbus
      dockerfile: ../bus.Dockerfile

  superman:
    build: ~/hero

Как видно из листинга, определить в compose файле сборку не так уж и сложно. Для каждого сервиса добавляем секцию build, которая может быть как строкой, так и объектом. Она должна указывать на build context, то есть на директорию где искать Dockerfile (context или просто build) и в какой файл смотреть (dockerfile).

Если уж вы совсем ленивый и не хотите пушить собранный образ на удалённый репозиторий руками, то добавив секцию image вы запушите свой собранный образ в docker registry по умолчанию.

Чтобы собрать и запустить это добро понадобится любимый compose up:

docker compose up

Все сервисы из compose файла единожды соберутся и запустятся.

Конечно, в базовом использовании не совсем понятно зачем нужна данная фича - в большинстве случаев будет удобнее отделить процесс сборки образа от процесса деплоя контейнера. Но вот если у вас монорепозитрий с сотней другой сервисов, то будет очень удобно создать единый compose file (даже, пусть только для тестовых нужд) со всеми переменными, портами, нюансами деплоев и тд и тп, а сборку раскидать по папкам с сервисами.


🥷 Docker Ninja 🥷

🤔 А если я хочу использовать compose только для сборки?! 🤔

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

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

🐺 Самый важный hard skill 🐺

Уж если есть вход, значит должен быть и выход! Так и в докере - про логин поговорили, теперь пришло время обсудить обратную команду.

Чтобы, выйти из ситуации сухим, пишем в терминале команду по шаблону:

docker logout registry_url

Очень полезно, если вы вступили в волчистое сообщество инфоцыг "Осознанная меркантильность" и предпринимаете все меры, чтобы не спалиться, что вы трудитесь на 3-х валютных удаленках параллельно. А то ведь можно ненароком запушить образы не в тот registry.

Ну а если серьезно, то в абсолютно любой конторе, в которой разработка идет в ногу со временем, будет развернут свой registry. Так что тут, как и с vim-ом, будет полезно знать не только как войти, но и как выйти.

Кстати, важно иметь в виду, что если в аргументах команды не будет указан репозиторий, то docker daemon выберет сам в каком репо разлогиниться:

docker logout 

Так что будьте внимательны! Ситуация обратимая, но в пылу рабочих задач может знатно прогреть область между стулом и рудиментарным органом чуть ниже поясницы🍑


🥷 Docker Ninja 🥷

💩 Палки закончились, дальше строим из г**** Pt.1 💩

Когда вы работаете с Docker, особенно при создании образов с помощью Dockerfile, важно понимать, что такое build context и как он влияет на процесс сборки.

Build Context — это набор файлов и папок, которые вы передаете через Docker CLI в dockerd во время сборки образа. Он используется Docker для доступа ко всем необходимым файлам, указанным в Dockerfile.

Концепция понятна - контекст = папка, в которую dockerd получает доступ при сборке, чтобы оперировать какими-то файлами (например копируя их через COPY или ADD). Так то оно так, но и тут есть двойное дно. В Docker различают некоторые типы Build Context:

1. Локальный путь: Наиболее распространенный вариант, когда файлы передаются из локальной файловой системы.

docker build -t myapp .

Здесь . обозначает текущую директорию как build context.

2. Архив: Вы можете передать контекст в виде архива.

tar -czf - . | docker build -t myapp -

В этом примере текущая директория архивируется и передается в Docker через стандартный ввод.

3. Git-репозиторий: Используйте URL на Git-репозиторий.

docker build -t myapp https://github.com/user/repo.git

Docker клонирует репозиторий и использует его содержимое в качестве контекста.

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


🥷 Docker Ninja 🥷

🎮 Никакой личной жизни... 🎮

Порою, для понимания того, из-за чего твой контейнер ведет себя неадекватно, недостаточно увидеть логи. В некоторых ситуациях важно понимать, что происходит с файловой системой сразу же после запуска контейнера. И тут на помощь приходит команда docker diff. С ее помощью мы всегда можем выяснить, какие файлы были добавлены, изменены или удалены во время работы контейнера. Идеально, когда тебе нужно понять, что же всё-таки натворил тот гениальный скрипт, который ты писал перед корпоративом уже знатно приняв на грудь.

Работает это так:

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

# И сразу же смотрим, куда nginx запустил свои грязные руки
docker diff test

# И получаем список изменений: 
A /path/to/file/or/dir  # добавлен файл или папка.
C /path/to/file/or/dir  # изменен файл или папка.
D /path/to/file/or/dir  # удалён файл или папка.

Если копать глубже, то мы поймем, что виноват в наличии данной команды наш любимый LFS. А если точнее, то те самые image layer и writable layer, разницу между которыми мы и смотрим.
Таким вот не хитрым, но вместе с тем гениальным решением получаем дополнительный инструмент для дебага контейнеров.🤗

Если было полезно, то обязательно реагируем пальчиками - 👍🏻


🥷 Docker Ninja 🥷

🐲 Великий китайский фаервол 🐲

По умолчанию, после установки Docker Engine, в хостовой системе создаётся сетевой интерфес docker0. Тип такого интерфейса bridge (подробнее о типах сетей в docker поговорим в следующих постах). Это значит, что контейнеры внутри такой сети будут изолированны от трафика внутри хостовой сети, а для доступа внутрь контейнера придется прокидывать порты.

Для тестовых нужд вполне достаточно и docker0, но вот на проде нам может понадобится большая изоляция контейнеров друг от друга или какие-то специфические настройки. Значит, нам важно иметь возможность создавать новые интерфейсы и такой функционал, конечно же, предусмотрен:

docker network create network_name

Вжух, и лёгким движением пальцев предотвращаем любые сливы🥭 в сети. А что там происходит внутри, можно подсмотреть вот тут.


🥷 Docker Ninja 🥷

❓ А что там с compose? ❓

С единичными контейнерами понятно. Если сеть не создана, то весь трафик идёт через интерфейс docker0.

Но неужели контейнеры компоуза так же по умолчанию общаются через этот интерфейс?

😷 Регулярная диспансеризация 🤒

Работа в ИТ хороша тем, что большую часть рутинных задач можно автоматизировать. Эта участь не обошла и периодическую проверку контейнеров на жизнеспособность.

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

Разработчики docker так же предусмотрели возможность держать руку на пульсе своего контейнера с помощью директивы HEALTHCHECK.

Она имеет две формы:

# проверяет состояние контейнера выполняя внутри него команду
HEALTHCHECK [OPTIONS] CMD command 

#отключает любые проверки состояния из базового образа
HEALTHCHECK NONE

Настроить его мы можем вот так:

FROM nginx:latest

# Добавляем директиву
HEALTHCHECK  \
  CMD curl -f http://localhost/ || exit 1

# Остальная магия
...

После сборки мы получаем контейнер, который с определённой периодичностью (по умолчанию 30 секунд) запускает скрипт из CMD. Если несколько (по умолчанию 3) таких проверок вернут код ошибки 1, то контейнер получит статус unhealthy.

Мы же получим дополнительный геморрой в виде дебага, настроенного нами хелсчека, помимо всего прочего. Но как говорил классик от медицины, "это норма". Да и хорошо отлаженный хелсчек впоследствии окупится вдвойне!

Ставь 🔥, если было полезно!

🥷 Docker Ninja 🥷

🐢 А что если сервис не успеет? 🐢

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

Чтобы этого избежать, мы конечно можем увеличить тайминги проверок, но это не совсем правильное решение, потому что они могут быть основаны на каких-нибудь бизнес требованиях (наподобие SLI/SLO/SLA).

🤡 Пятничный troubleshoot-очный 🤡

Юзаю на работе docker stats,
Решаю все проблемы как Борецкий Стас!

Ты только что развернул новый сервис, а сервер уже кричит от боли. Логи молчат, у контейнера статус healthy? Кто виноват, а главное, что с этим делать?
Пора устраивать ревизию! Команда docker stats поможет быстро выяснить, кто из контейнеров потребляет больше ресурсов на хосте.

Пора действовать! Набирай:

docker stats

# Получим постоянно обновляющийся вывод, наподобие этого
CONTAINER ID  NAME  CPU %  MEM USAGE / LIMIT     MEM %  NET I/O       BLOCK I/O         PIDS
b415e06e97ee  one   0.00%  15.86MiB / 31.31GiB   0.05%  53MB / 242MB  27.6MB / 41kB     9

В мгновение получаем активную сводку по ресурсам, не прибегая ко всяким заббиксам или прометею с его экспортерами. И, что самое интересное, сводка будет по контейнерам со всего хоста в одном месте!

Забирайте команду к себе в копилку и пользуйтесь на здоровье!🤗


🥷 Docker Ninja 🥷

😈 Not today, Satan! 😈

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

Поскольку, в Docker изоляция чисто номинальная, то по факту root доступ в контейнере имеет все шансы стать root-ом на хостовой системе. Малейшая уязвимость или баг — и вся ваша безопасность идет коту под хвост. Но если ты используешь директиву USER, твое приложение работает от имени непривилегированного пользователя, и нежелательные гости остаются за воротами.

Пример использования:

# Берем базовый образ
FROM ubuntu:20.04

# Создаем пользователя и группу
RUN groupadd -r appgroup && useradd -r -g appgroup appuser

# Назначаем пользователя для выполнения команд внутри контейнера
USER appuser

# Запускаем приложение
CMD ["my_app"]

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

1:0 в пользу воинов света!
Ставь 😇, если пост был полезным.


🥷 Docker Ninja 🥷

1️⃣ Но есть один нюанс 1️⃣

Как вы наверняка знаете, у пользователей и групп в линуксе есть не только их названия, но и id ( uid и gid).

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

🙅‍♂ Oh, don't touch my tralala 🙅‍♂

Все мы знаем, что если просто так запустить контейнер не передвая никаких дополнительных флагов, то stdout о его работе мы будем видеть прямо у себя в терминале. При этом, всплывать он будет по мере поступления событий в самом контейнере.

И, наверняка, ни для кого не является секретом, что есть такой волшебный флаг -d или --detach.

Используем мы его так:

docker run -d -p 80:80 my_image

Интересно тут то, как это дело работает изнутри.

Как мы уже говорили, когда контейнер запускается без флага -d, терминал остается привязанным к стандартному вводу/выводу контейнера. Это значит, что весь вывод контейнера (stdout и stderr) будет отображаться в терминале.

Detach же работает по аналогии с линуксовым оператором &, который переводит процесс в фоновый режим.

Конечно, системные вызовы это не тема нашего поста и в них мы погрузимся в будущих постах, но, если копать detach ещё глубже, то выйдем на системный вызов setsid(), который отделяет наш контейнер (процесс) от управляющего терминала, делая его независимым.

А на этом я с вами прощаюсь и конечно же ставьте 👍, если пост был полезен!


🥷 Docker Ninja 🥷

🧤Война без конечностей 🧤

Ранним утром в четверг коллеги из разработки отдали свою новую поделку со словами: "Сразу в прод под нашу ответственность".

Мы люди простые, сказано - сделано. Запускаем контейнер с апликухой - работает. Но разработка вдруг сказала, что срочно нужно обновить, потому что влили хотфикс. Не проблема.

И вдруг, первоначальный контейнер повис. Дело пахнет керосином, потому что мы словили зомби процесс.

Пора применять более радикальные меры! Здесь на сцену выходит наш герой — docker kill. Эта команда без лишних вопросов отправляет контейнер в вечный отпуск не ждя никаких gracefull shutdown.

docker container kill [OPTIONS] CONTAINER [CONTAINER...]

А теперь поиграем в Таноса:

docker kill dr_strange
docker kill star-lord
docker kill spidy

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

🥷 Docker Ninja 🥷

😱 К нам едет ревизор! 😱

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

Возможности эти не такие большие и по большей части они позволяют нам менять какое-то поле конфига dockerd. Но есть довольно полезные экземпляры, например флаг —validate.

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

$ dockerd --validate
configuration OK

# Для верности посмотрим код последней команды
$ echo $?
0

И вот теперь вопрос, зачем, а главное когда оно нам понадобится?

Тут все просто!
Когда вам необходимо с помощью какого-то IaC инструмента поднять докер на множестве хостов и при этом заменить дефолтный конфиг на свой. Еще интереснее, когда этот самый конфиг уникальный для некоторых групп хостов.

Просто ставите докер, закидываете свой конфиг и запускаете dockerd --validate с последующей обработкой кода ответа команды. И теперь вы всегда знаете, зашел ли ваш конфиг демону докера!

Ставь 👍🏻, если было полезно!


🥷 Docker Ninja 🥷

🐈 На словах ты tar простой, а на деле img Толстой 🦁

Помнишь, как мы с тобой создавали свой первый образ из архива с помощью команды docker import? Но что, если нам понадобится наоборот из существующего контейнера сделать архив?! Сегодняшняя тема — команда docker export, которая позволяет это сделать.

Сама команда выглядит следующим образом:

docker container export [OPTIONS] CONTAINER

В живую это будет выглядеть примерно так:

docker export mycontainer > mycontainer_backup.tar

Хоба! И теперь у нас в руках есть копия файловой системы контейнера в виде архива, который можно позже развернуть с помощью docker import, как мы делали это раньше.

Используй docker export, чтобы сохранить свои шедевры и всегда быть на шаг впереди! 🧙🏼


🥷 Docker Ninja 🥷

⁉️ Да на кой это нам черт ⁉️

Команда docker export довольно специфичная и, с первого взгляда, применения ей можно и не найти. Тогда на кой черт она сдалась нам?!

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

Вперед!👇🏻