🐈 На словах ты 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 довольно специфичная и, с первого взгляда, применения ей можно и не найти. Тогда на кой черт она сдалась нам?!

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

Вперед!👇🏻

🌐 Дурной devops - дурные сети. Сломал релиз - голодны дети 🦑

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

1. Bridge 🛠
- По умолчанию используется для контейнеров на одном хосте.
- Создает частную сеть, изолированную от внешнего мира, но позволяет контейнерам на одном хосте "общаться" между собой.
- Отлично подходит для локальных разработок и тестирования.
- Вариант по умолчанию при создании сети

2. Host 🌍
- Контейнер использует сетевой стек хоста напрямую
- Полезен для приложений, которым требуется высокая производительность, но получаем дебафф в виде полного остутсвия сетевой изоляции.

3. Overlay 🕸
- Позволяет контейнерам на разных хостах общаться друг с другом. По факту соединяет в сеть несколько докер демонов.
- Используется для создания распределенных систем и кластеризации, например, в Docker Swarm.

4. Macvlan 🔌
- Позволяет контейнеру иметь собственный MAC-адрес, как полноценное сетевое устройство.
- Полезен для интеграции с сетевыми устройствами или когда требуется точная настройка сетевого интерфейса.

5. IPvlan 📡
- Позволяет контейнеру иметь собственный IP-адрес в сети, используя один физический интерфейс.
- Работает в режимах L2 и L3, обеспечивая гибкость в управлении трафиком.
- Отлично подходит для высокой плотности контейнеров и минимальной конфигурации сети.

6. None 🚫
- Отключает сеть для контейнера.
- Полностью изолирует контейнер от сетей. Полезно, когда контейнер творит такую дичь, что лучше его никому не видеть и не слышать.

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


🥷 Docker Ninja 🥷

🐺 И волки целы и овцы сыты 🐑

Зачастую, чтобы собрать простейший образ с вашим приложением, приходится использовать массивные базовые образы со всем сопутствующим обвязом (sdk, сертификаты и прочие прелести из мира CI). В конечном итоге, мы можем получить монструозный многослойный образ, при запуске которого сразу и не скажешь, что деплоишь легкий контейнер.

Эту проблему отлично решает multi-stage build. Stage тут, это все, что идет после диррективы FROM до следующей такой диррективы.
Концептуально, это работает так:
1. Берем за основу образ с необходимым CI софтом
2. Собираем проект внутри него
3. Берем минимально необходимый образ, в котором наша аппликуха будет работать полноценно
4. Копируем в него собранный проект из второго шага

Фича может быть реализована разными способами, но сегодня рассмотрим один из самых распространенных.

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

FROM scratch
COPY --from=0 /bin/hello /bin/hello
CMD ["/bin/hello"]

Как видим, здесь мы собираем бинарник в образе с golang sdk от версии 1.23, а далее берем минимальный образ scratch и копируем в него тот самый бинарь. Таким образом, получаем легкий образ без лишних файлов.


🥷 Docker Ninja 🥷

💃🏻 Хороший тамада и конкурсы интерактивные!🕺🏼

Мы с вами уже знаем, что логи приложения внутри контейнера можно смотреть через команду docker logs. Все благодаря тому, что данная команда считывает stdout внутри контейнера. Но что делать, если мы хотим иметь возможность что-то передать внутрь контейнера? Как открыть stdin контейнера?

На такой случай предусмотрен флаг --interactive (или -i), который оставляет поток ввода контейнера открытым, позволяя отправлять данные в контейнер через стандартный ввод.

echo hello | docker run --rm -i busybox cat

# Ответ команды
hello

Скорее всего, многие из вас уже пользовались им в связке с другим флагом (-t), о котором мы поговорим в других постах. Но это не единственный кейс использования интерактивного режима на практике.

Использование флага -i позволяет создавать линуксовые пайпы через несколько вызовов различных контейнеров:

docker run --rm -i busybox echo "foo bar baz" \
  | docker run --rm -i busybox awk '{ print $2 }' \
  | docker run --rm -i busybox rev

# Ответ команды
rab

Эта фишка особенно помогает, когда нам нужно выполнить пайплайн на хосте, где нету какого-либо пакета, а установлен только docker. Например, мы имеем один мощный билд агент и не хотим морочить себе голову установкой чего-либо.

И, кстати, прошу заметить, что данный флаг присутствует не только в команде docker run, но и для docker exec!

🥷 Docker Ninja 🥷

💊 Принимай волумпрунин 💊

Уж сколько раз твердили миру, что за контейнером нужно подчищать, особенно это касается диска! И сегодня разберем очередную команду docker volume prune, которая поможет очистить неиспользуемые тома Docker.

Не буду сильно напоминать о том, что со временем docker тома накапливаются, занимая место на диске, даже если они больше не используются. Чтобы освободить место и поддерживать чистоту в системе, мы можем прибегнуть к docker system prune, но что если удалить нужно только тома. Вот тут то и понадобится команда docker volume prune.

Чтобы удалить все неиспользуемые тома и освободить пространство, просто выполняем команду:

docker volume prune

# Сразу же ловим АХТНУГ и запрос на подтверждение операции
WARNING! This will remove anonymous local volumes not used by at least one container.
Are you sure you want to continue? [y/N] y
Deleted Volumes:
07c7bdf3e34ab76d921894c2b834f073721fccfbbcba792aa7648e3a7a664c2e
my-named-vol

Total reclaimed space: 36 B

Получив подтверждение, docker удалит все тома, которые никак не задействованы в каких либо контейнерах.


🥷 Docker Ninja 🥷

⁉️ А как же два стула ⁉️

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

🦫 Залетаем в топ с левой пятки 🦫

Сидим с бобром за компом, к релизу готовим контейнер с nginx-ом.

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

В случае с Nginx, например, это означает, что внутри контейнера будет основной (master) процесс и один или несколько дочерних (worker) процессов. И тут очень важно убедиться, что все worker-ы веб-сервера работают корректно, а иначе плакаль ваш хайлоуд крипто-стартап крокодьими слезками😭

docker top позволяет вам следить за всей этой процессной кухней: убедиться, что они запущены и функционируют без сбоев.

Начнем с базового использования.

# Пускаем контейнер
docker run -d --name my_container nginx

# Смотрим, какие процессы запущены внутри контейнера
docker top my_container

Пример вывода команды:

UID                 PID                 PPID                C                   STIME               TTY                 TIME                CMD
root                12345               12344               0                   00:00               ?                   00:00:00            nginx: master process nginx -g daemon off;
101                 12346               12345               0                   00:00               ?                   00:00:00            nginx: worker process

Видим тут PID и PPID, шо значит process id и parent process id. Проверяем: root, в виде nginx-master, у нас родитель для nginx-worker.

Прочитал? Тогда поставь 🔥 за тех, кто не знал про команду и остался курвой после факапа в пятничный релиз!

🥷 Docker Ninja 🥷

⚠️ Коллеги, ATTENTION PLEASE ⚠️

Вчера ловил жуткие отходняки от магнитных дурей🤯

Так что ловите сердечную сорямбу за пропущенный пост🫶🏻

И викторину для трениров-очки🕶

👇🏻👇👇🏿

😈 Понедельник - день суровый 😈

Как говорил, классик, "Опять работа...". Увы и ах, а, может быть, для кого-то и ура, но впереди у нас еще 5 рабочих дней! И поэтому, чтобы жизнь совсем перестала казаться медом, сегодня погутарим опять за сети. А точнее, подумаем над вопросом, почему же, если контейнер это процесс, то его порты не конфликтуют с портами хоста?

Повторюсь в очередной раз, контейнеры в Docker, хотя и являются процессами на хостовой системе, изолированы с помощью пространства имён (namespaces) и cgroups. Это изоляция позволяет контейнерам иметь свои собственные сетевые стеки, включая независимый пул портов.

В результате имеем:

1. Сетевые namespaces:
Каждый контейнер работает в своём собственном сетевом пространстве имён. Это означает, что он имеет свой собственный сетевой интерфейс и стек, который изолирован от хостовой сети и других контейнеров. Благодаря этому порты, используемые в контейнере, не конфликтуют с портами хоста.

2. Проброс портов (Port Binding):
Чтобы контейнер был доступен извне, нужно явно настроить проброс портов с хоста в контейнер. В docker это делается с помощью флага -p, но мы то с вами знаем, что изнутри там ковыряются в политиках iptables. Именно через iptables, в том числе, настраиваются и пробросы портов сквозь разные сетевые неймспейсы.

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

Как-то так. А мы дружно ставим 🍾 за тех, кто сегодня не на удаленке!

🥷 Docker Ninja 🥷

🎮 Первому игроку приготовиться 🎮

Четверг, иной раз, выдаётся даже похуже понедельника. Поэтому любая автоматизация рутины для нас в такие деньки, как глоток воздуха!

Один из таких способов не делать лишних движений - команда docker init.


docker init инициализирует docker проект со всеми необходимыми для запуска контейнера файлами, да ещё может делать это из специальных шаблонов под конкретный язык 😝

Находясь в папке с нашим проектом запускаем:

docker init

Welcome to the Docker Init CLI!

This utility will walk you through creating the following files with sensible defaults for your project:
  - .dockerignore
  - Dockerfile
  - compose.yaml
  - README.Docker.md

Let's get started!

? What application platform does your project use?  [Use arrows to move, type to filter]
PHP with Apache - (detected) suitable for a PHP web application
  Go - suitable for a Go server application
  Java - suitable for a Java application that uses Maven and packages as an uber jar
  Python - suitable for a Python server application
  Node - suitable for a Node server application
  Rust - suitable for a Rust server application
  ASP.NET Core - suitable for an ASP.NET Core application
  Other - general purpose starting point for containerizing your application
  Don't see something you need? Let us know!
  Quit

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

После её запуска в папке с проектом обнаружим следующие файлы:
- .dockerignore
- Dockerfile
- compose.yaml
- README.Docker.md

Если какой-то из указанных файлов уже имеется в папке (или в случае с compose, там будет docker-compose.yml) то команда спросит надо ли перезаписать существующий файл.

Лёгким движением руки экономим себе драгоценные минуты на более полезные задачи 🪄


🥷 Docker Ninja 🥷

📌 Раздаём ярлыки 📌


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

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

Пример использования директивы LABEL:

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

# Добавляем метаданные
LABEL maintainer="Senpai <senpai@devops.com>"
LABEL version="1.0"
LABEL denoscription="Это образ для веб-приложения на базе Ubuntu 20.04"

# Установка необходимых пакетов
RUN apt-get update && apt-get install -y nginx

# Копируем файл конфигурации
COPY nginx.conf /etc/nginx/nginx.conf

# Запускаем Nginx
CMD ["nginx", "-g", "daemon off;"]

Теперь ваш образ содержит метаданные, которые помогут быстро понять его назначение и версию/ А так же, вы теперь знаете кому дать в лоб за косяки в образе😈


🥷 Docker Ninja 🥷

🔮Видишь терминал? А его нет 🔮

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

Сегодня же у нас на повестке флаг --tty (-t) . И польза его в том, что он прокидывает так называемый pseudo-tty в контейнер (о том, что это такое мы поговорим попозже), что дает нам возможность лицезреть терминал в контейнере.

docker run -it nginx /bin/bash

Этот самый режим есть как для команды run, так и для exec:

docker exec -it my_container /bin/bash

Как видим, флаг -t используется у нас в связке с -i. И, если последний и возможно хоть как-то применить в одиночку, то вот -t без интерактивного режима ничем нам не поможет. А все потому, что для работы с терминалом нам, как ни крути, нужен доступный stdin. Без него мы просто не сможем ничего написать в терминале.

Так что запоминаем как "Отче наш": нужен терминал, смело ставь -it!

🥷 Docker Ninja 🥷