😈 Республика должна умереть! 😈

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

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

docker exec far_far_galaxy_container /order_66

Киллер фича данной команды в том, что Вы можете выполнять ее столько раз, сколько нужно, без влияния на основную задачу контейнера. То есть команда никак не затрагивает корневой процесс контейнера (PID 1), как это происходит при docker attach, а порождает дочерний. То есть, даже ошибочное исполнение процесса в docker exec не сломает контейнер.

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

🥷 Docker Ninja 🥷

📡 Networking здорового человека 📡

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

Создание сети
1. Выбор драйвера сети:
- Docker поддерживает несколько типов сетевых драйверов, но по умолчанию используется bridge, обеспечивающий изоляцию и взаимодействие на уровне одного хоста.
2. Создание сети:
- Когда вы создаёте сеть, Docker инициирует создание сетевого пространства.
- Для bridge-сети создаётся программный сетевой мост, к которому будут подключаться контейнеры.
3. Настройка сетевых параметров:
- Docker автоматически назначает подсеть и шлюз сети. Вы также можете задать эти параметры вручную для большей гибкости.
- Создаются правила iptables для управления доступом и маршрутизацией трафика.

Запуск контейнера
1. Подключение контейнера к сети:
- При запуске контейнера с указанием сети, Docker создаёт виртуальный сетевой интерфейс (veth), который связывает сетевое пространство контейнера с bridge-сетью.
2. Настройка сетевых интерфейсов:
- В контейнере создаётся сетевой интерфейс, получающий IP-адрес из диапазона сети.
- Docker настраивает DNS для контейнера, чтобы он мог разрешать имена хостов других контейнеров в той же сети.
3. Маршрутизация и правила доступа:
- Docker обновляет iptables для разрешения или блокировки трафика в зависимости от политик сети.
- Контейнер получает доступ к другим контейнерам в той же сети через DNS-имена, что упрощает их взаимодействие.

🥷 Docker Ninja 🥷

🌿 Дискомфортная окружающая сре пятница 🌿

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

Давайте посмотрим как с ним работать.
Для начала необходимо указать директиву ENV в Dockerfile.Значение переменной по умолчанию задается напрямую:

FROM week_before_new_year:latest
ENV  PLAN_100_RELEASES_BEFORE_HOLIDAYS=false

Теперь остается только собрать образ из полученного Dockerfile

docker build -t goodbye_production:2024 .

Попав в образ эта переменная уже никуда не денется и ее можно использовать внутри контейнера как мы бы использовали переменные среды в Linux.

Сильное заявление! Проверять я его конечно же буду:

# Заходим в контейнер
docker run -e PLAN_100_RELEASES_BEFORE_HOLIDAYS=true goodbye_production:2024 /bin/bash

# Чекаем переменные
env

А вы, конечно же, подпишитесь и оставьте реакт, если пост понравился😉

🥷 Docker Ninja 🥷

⚓️ Курс на Тортугу! ⚓️

Порты контейнера - это самый главный способ достучаться до приложения в нем снаружи. Поэтому, в 90 процентах случаев, мы будем открывать какие порты при его запуске. Самый простой способ сделать это, запустить команду docker run с флагом -p.

Запускаем контейнер

docker run -p <host_port>:<container_port> <image_name>

Как видим, значение флага состоит из двух частей, разделенных символом :.
1. <host_port> - порт на машии с docker engine, где запущен контейнер с нашим приложением. После запуска контейнера приложение будет доступно по адресу <host_address>:<host_port>.
2. <container_port> - порт, на котором работает наше приложение внутри контейнера. Его можно подсмотреть в EXPOSE образа. Трафик, приходящий по <host_address>:<host_port> будет перенаправлен на этот порт внутри контейнера.

Но и это еще не все. За раз мы можем указать сразу не сколько портов, повторно указывая флаг -p.

docker run -p 80:80 -p 123:321 my_container:latest

Ну и теперь, вишенка на торте! В обоих портах, мы можем указать протокол (udp, tcp, sctp) или даже принудительно хост:

docker run -p 127.0.0.1:80:80/udp my_container:latest

Вот такие вот пироги с огурцами может вылепить, казалось бы, простейшая команда!

🥷 Docker Ninja 🥷

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

Коллеги, вот и настало время новогодних праздников. Большинство из нас в эти дни полноценно отдыхает, расслабляется и набирается сил перед новым рывком длинной в один год. Админ канала Docker Ninja (то есть я) не исключение, поэтому до 5 числа включительно будет небольшое затишье. Но не стоит расстраиваться, потому что следующий год будет ещё интереснее и насыщеннее!🥳🥳🥳

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

Много слов и мало по делу, поэтому, обобщу словами классика:

Пожелаю я братве
Фартовой воли на Земле!
Здоровья, счастья, пацаны
И чтоб не трогали менты!


Дж. Стетхем (Стэйтем)

🥷 Docker Ninja 🥷

🐴 Андрюха, у нас сигнал. Возможен graceful shutdown. По коням! 🐴

В разработке есть такое понятие - graceful shutdown. Нужен он для корректного завершения работы приложения, чтобы все соединения, файлики и прочия и подобныя были закрыты перед завершением самого приложения. Подобная фича предусмотрена и в работе Docker Engine.
Поскольку контейнер это процесс, docker daemon может управлять этим процессом, посредством механизма сигналов (Unix signals).

Вот что он использует:
🔹 SIGQUIT (Signal Quit): Этот сигнал часто используется для завершения процесса и создания дампа памяти. В Docker его можно отправить, чтобы приложение завершалось с созданием отладочной информации, если оно поддерживает обработку SIGQUIT.

🔹 SIGTERM (Signal Terminate): Это стандартный сигнал для завершения процесса контейнера docker container stop. Docker сначала отправляет SIGTERM, чтобы дать процессу возможность завершиться корректно. Если процесс не завершится в течение тайм-аута (по умолчанию 10 секунд), отправляется SIGKILL.

🔹 SIGKILL (Signal Kill): Принудительное завершение процесса, если он не реагирует на другие сигналы.

🔹 SIGINT (Signal Interrupt): Используется для прерывания процесса, как при нажатии Ctrl+C. Срабатывает, когда мы, например, мы запускаем терминальную сессию как родительский процесс контейнера в интерактивном режиме, а после завершаем его через Ctrl+C.

🔹 SIGHUP (Signal Hang Up): Этот сигнал обычно используется для уведомления процесса о том, что терминал был отключен. В контексте Docker он может использоваться для перезагрузки конфигурации приложения без полного перезапуска контейнера, если приложение поддерживает обработку SIGHUP.

🔹 SIGUSR1 и SIGUSR2: Эти сигналы могут использоваться для пользовательских задач. Docker Daemon, например, использует SIGUSR1 для сброса стека и SIGUSR2 для перезагрузки конфигурации.

А ты ставь 🔥 если сделал graceful shutdown, завершив 2024 год без факапов на работе!

🥷 Docker Ninja 🥷

🤤 И пусть весь мир подождет 🤤

Представь себе: выходишь ты такой с новогодних с 3-мя лишними киллограммами, а тут еще и продовый хост с множеством важных контейнеров кричит о нехватке CPU. И все начинает тормозить, как в пятничный вечер в пробке.

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

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

Для этого просто скажи терминалу:

docker compose pause <service_name>

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

docker compose unpause <service_name>

🥷 Docker Ninja 🥷

💩 Чуешь?! Сигналами пахнет? 💩

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

Так что, коллеги, знайте, docker compose pause абсолютный singnal free! За его работу отвечает другой механизм.

🏋️ Сколько вешать в граммах? 🏋️

А вот и очередная команда из серии БАЗА.
Мы уже много раз говорили про вероятный отжор диска за счет не удаленных после использования образов и контейнеров. И вот, в очередной раз возвращаемся к этой теме в контексте первых.

Очень вряд ли в вашей жизни сложится ситуация, когда вы поднимите какой либо контейнер единожды и не будете к нему притрагиваться. Скорее всего, образ контейнера будет активно обновляться, ну и вы, чтобы идти в ногу со временем, будете обновлять образы локально. Ну и конечно же откатываться в случае проблем. Поэтому всегда полезно знать, какие версии образов у вас стоят локально. И на этот вопрос, конечно же, нашлась команда - docker image ls.

Заюзать ее проще простого:

docker image ls

Или еще проще, через алиас:

docker images

А если нужна информация про образы из конкретного репозитория, то делаем так:

docker images [REPOSITORY]

Ну и конечно же, можно добавить TAG через : после REPOSITORY. Что репо, что тэг должны быть максимально точными, иначе рискуете не получить ничего, либо инфу о совсем другом образе.

🥷 Docker Ninja 🥷

🇨🇳©️ Made in China ©️🇨🇳

А сегодня у нас опять нетленочка! Помните, мы говорили о двоюродном младшем брате aka сыне маминой подруги для команды ADD. Встречайте, COPY!!!

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

Начнем с базового использования.
Всё просто:

# Берем базовый образ
FROM node:14

# Копируем файл в контейнер
COPY my_app.js /usr/src/app/

Теперь твой my_app.js уютно устроился в директории /usr/src/app/ внутри контейнера.

Но это, скорее, сферический осел🐴 в вакууме, чем пример. Что делать, если файлов много (а в большинстве случае так и будет)? Например, ты хочешь перенести сразу несколько конфигурационных файлов или скриптов.
Делов на 5 секунд:

# Копируем сразу несколько файлов
COPY config1.conf config2.conf /etc/my_app/

Ну или вайлдкард:

# wildcard
COPY noscripts/*.sh /usr/local/bin/

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


🥷 Docker Ninja 🥷

💔 I saw your search history 💔

Настоящий IT ниндзя презирает эти ваши новомодные ультра удобные GUI и откровенно шлет наgui все, что не называется vim-ом или в окончании чего нет sh! Настоящий IT ниндзя держит под рукой только лишь один инструмент - терминал. И, конечно же, настоящий IT ниндзя не ищет нужный ему докер образ в docker hub через окно браузера! Настоящий IT ниндзя юзает команду docker search.

Без лишних слов, ныряем в дебри терминала, чтобы найти самый нужный образ - busybox:

docker search busybox

NAME                 DESCRIPTION                                     STARS     OFFICIAL
busybox              Busybox base image.                             3367      [OK]
rancher/busybox                                                      0
chainguard/busybox   Build, ship and run secure software with Cha…   0
stagex/busybox       Size optimized toolbox of many common UNIX u…   0
okteto/busybox                                                       0

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

Но если ты вдруг никакой не настоящий ниндзя, а всего лишь ниндзя с 9 до 18 часов (как, собсна, и я - work-life balance, мать его за ногу!), то вот тебе козырь на случай холиваров с терминальными нердами:

Внимание!!!!
docker search не умеет работать с self-hosted docker registry. Для это придется использовать сторонние cli инструменты...

Раунд🎤

🥷 Docker Ninja 🥷

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

Глядя на лошадиных размеров образы и лица людей, собравших их, на безбрежный живой поток задач, поднятый волей тимлида и pm-а, мчащийся в никуда по багровой закатной kanban доске, я часто думал: кто собрал самый первый докер образ?

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

И, вопрос сегодняшнего дня откуда взялся самый первый образ и как сделать нулевой образ самому?!

Покопавшись в дебрях интернетов можем найти интересную команду docker import, которая создает из tar архива файловую систему контейнера и образ. Фишка тут в том, что в архиве должен быть именно слепок файловой системы.

docker  import file.tar REPOSITORY:TAG

Данная информация наводит на интересные мысли. А что если сделать архив корня нашей файловой системы и запедалить ее через импорт в образ?

Сказано, сделано:

sudo tar -cvf rootfs.tar 
docker import ./rootfs.tar testimg

Получаем образ testimg:latest, который готов к запуску, +100 к скиллу devops-а и преисполнение в своем познании!🧙🏼

Теперь ты знаешь, что докер контейнер, это не только обычный процесс, но еще и обычный архив.


🥷 Docker Ninja 🥷

🦅 Это птица! Это самолет! Это 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 🥷