🫨 I wanna see you cry... 🫨

А все потому, что тема этого поста - "Отличие виртуализации от контейнеризации".

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

Но теперь ближе к телу.

Контейнер, это не полноценная операционная система. Это процесс, который имеет свои изолированные от других процессов ресурсы. Нигде, кроме как на существующей ОС, запустить контейнер не возможно, потому что для работы ему нужно ядро операционной системы. Сам он ее не имеет поэтому использует хостовую. Но это позволяет быстро запускать и останавливать контейнеры, экономя ресурсы.

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

🪆Reset на reset-е, reset-ом погоняет🪆

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

Бацаем в терминале вот такое:

docker compose restart

На выходе получаем полный рестарт всех сервисов, запущенных в данном контексте компоуза.

Довольно похоже на docker restart, не правда ли? В дальнейшем мы встретим её ещё не раз и вы в этом убедитесь!

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

Для этого придётся полностью рестартовать контейнеры. Но это уже будет темой для одного из следующих постов.

🥴 И так сойдет... 🥴

Есть в Dockerfile такая интересная инструкция - EXPOSE. Используется для указания портов, которые контейнер будет прослушивать во время выполнения. И самое интересное в ней то, что никаким поднятием портов она не занимается. Единственная ее функция - это документирование какой порт будет слушаться приложением внутри контейнера.

Например, чтобы указать, что контейнер будет прослушивать tcp порт 80, добавим в Dockerfile строку:

EXPOSE 80

То же самое, но для udp:

EXPOSE 80/udp

Но не кажется ли вам, будто бы разработчики Docker сами не до конца разобрались, что же они сделали?

Я думаю, что у многих именно такие мысли. Поэтому так часто можно встретить докер образы, где не указаны никакие ExposedPorts. И очень даже зря!

👌🏻 Все что ни делается, к лучшему 👌🏻

И было бы опрометчиво считать разработчиков такого большого продукта дураками. Даже такая необязательная фича как EXPOSE портов продумана и сделана для упрощения деплоя!

💂 Убежать по-английски 💂

Docker значительно упростил процесс использования какого-либо софта. И речь даже не о контейнеризации своего приложения, а об использовании сторонних программулин. Частенько приходится запускать какой-то инструмент локально или, например, на агенте для CI/CD. И в случае с последним, особенно важно следить, чтобы отработавшие контейнеры не засоряли нам систему.

На случай как раз таких ситуаций существует флаг --rm в команде docker run.

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

Вот как это выглядит в терминале:

docker run --rm <image_name> <command>

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

♦️ Пояснялово ♣️

Кстати, помните расшифровку docker-версии загадки про два стула? Частенько на какие-то разовые ситуации приходится запускать контейнер с томом. Но если контейнер мы удалим с помощью --rm , то что будет с томом этого контейнера?

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

📰 Догоняй, журналюга! 📰

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

Для этого существует команда docker logs.

Эта команда позволяет просматривать вывод стандартного вывода (stdout) и ошибок (stderr) контейнера. Вот как ей пользоваться:

docker logs <container_id_or_name>

А теперь просто представьте, как бы было больно постоянно держать контейнер в foreground режиме? Или лезть в сам контейнер, чтобы почитать системные логи?🤢

⚠️ Один нюанс ⚠️

docker logs команда несомненно полезная, но стоит понимать, что, как и во всем, тут не все так просто! Могут возникнуть ситуации, когда вы, запустив эту команду, не увидите ничего путного в выводе.

Причин может быть несколько. Стоит ознакомиться и не паниковать в случае чего😉

🪬 Чёрная метка 🪬

Уже несколько раз мы касались работы с тэгами (тык, жмык). И в общем-то вполне себе понятная концепция, использовать какую-то уникальную строку для обозначения образов, но и в ней есть некоторые нюансы, которые стоит понимать.

Тэг состоит из двух частей:
- image_namе - непосредственно имя контейнера
- tag - дополнительная строка в которую пихают все, кто во что горазд, чтобы выделить между собой образы с одинаковым image_namе

Из описания второго, можно уловить мысль, что нет четкой и единой структуры для самого тэга. Там мы можем указать практически все что угодно, главное, чтобы это была строка. Соответственно, даже если у образа стоит тэг latest, далеко не факт, что внутри не обнаружится latest трех-летней давности.

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

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

Так что, будьте внимательны при работе с тэгами!!!

🥷 Docker Ninja 🥷

🤦 Attention Deficit Disorder 🤦

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

Конечно же в Dockerfile сделать это можно, и, вдобавок, не одним способом. Но конкретно сегодня хотелось бы обсудить инструкцию ADD.

ADD это один из способов копирования файлов внутрь контейнера. И способ этот специфичный, потому что он может копировать файлы:

1. Из build context

ADD ./config.yml /

2. Из локального архива

ADD ./my_files.tar.gz /

В случае такого копирования docker разархивирует указанный локальный конфиг в место назначения внутри конфига.

3. По http/https адресу

ADD https://example.com/my_files.tar.gz

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

4. Из git репозитория

ADD git@user/repo.git /

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

🥷 Docker Ninja 🥷

🔑 Ключ от всех дверей 🗝

Для работы с приватными репозиториями на Docker Hub или других Docker Registry необходимо сначала авторизоваться. Это можно сделать с помощью команды docker login.
Эта команда запрашивает ваши учетные данные и сохраняет их, чтобы вы могли безопасно скачивать и загружать образы.

docker login [OPTIONS] [SERVER]

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

docker login

Так мы вызовем интерактивный запрос логина и пароля.
А так, передаем эти данные через ключи:

docker login -u papa_justify -p hudu_magic

🥷 Docker Ninja 🥷

🤩 Amazing Customer Service 🤩

Давайте разберёмся с директивой services в Docker Compose — основой, на которой строится вся конфигурация вашего многоконтейнерного приложения.

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

Пример:

services:
  web:
    image: nginx
    ports:
      - "80:80"
    environment:
      - NGINX_PORT=80
    depends_on:
      - app

  app:
    image: my-app
    volumes:
      - .:/code
    environment:
      - APP_ENV=production

Но возникает вопрос, зачем, а главное - нафига?! На кой черт сдался нам этот ваш сервис? Почему бы нам не взять и просто описать контейнер с параметрами запуска?

Все дело в назначении инструмента docker compose. Его основная фишка, это управление многоконтейнерными приложениями. И речь тут даже не столько о возможности деплойнуть сам сервис с контейнером базы - такое практикуют скорее на тесте. А, скорее, о необходимости разом поднимать несколько инстансов одного и того контейнера для отказоустойчивости. И в довесок, об управлении жизненным циклом этих инстансов.

Для этих целей и придумали структуру services, в которой будет удобно пояснить за то "какой details, какой fabrique..." А знатоки, наверное уже поняли что для данной директивы есть аналогия в k8s.


🥷 Docker Ninja 🥷

👽 А царь то ненастоящий! 👽

Когда дело доходит до создания собственных контейнеров, команда docker build — ваш лучший друг. Она позволяет собрать образ на основе инструкций, указанных в Dockerfile.

docker build -t <your_image_name>:<your_tag> .

А что, если я вам скажу, что docker build, это на самом деле команда docker buildx build?

Спокойно✋🏻
Чтобы ваше войско не бунтовало, могу сказать, что вас не обманули! Точнее обманули, но в вашу пользу!
docker buildx — это расширенная версия, которая поддерживает мультиплатформенные сборки и другие полезные функции. А появилась она в версии docker engine 19.0.0

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

docker buildx build -t <your_image_name>:<your_tag> .

Здесь -t задаёт имя и тег для вашего образа, а . указывает на текущую директорию, где находится Dockerfile. С buildx вы получаете больше гибкости и возможностей для создания контейнеров! Ну а подробнее о различиях старого build и buildx build мы поговорим в следующий постах👌🏻


🥷 Docker Ninja 🥷

😎 Устроился драйвером в Яндекс GO. Теперь я в ИТ? 😎

Однажды, в студеную зимнюю пору
Болтали мы с вами про докер тома.
Но как-то давно прочитал я на хабре,
Что в докере драйвер есть - overlay номер 2...

Сегодня расскажу вам про такую интересную штуку как docker storage drivers. Но, прежде чем понять а на*уй он нам нужон, этот ваш docker storage drivers, стоит углубиться в механизм работы со слоями в докере.

Как помним, есть модная-сковородная технология LFS, которая помогает нам быстренько и бюджетненько крутить различными контейнерами и не бояться пересечения данных. А работает это потому, что в контейнерах есть image layer и writable layer. У образа есть только первый. У контейнера есть и первый и второй. Соответственно, первый неизменный, второй постоянно меняется и удаляется при удалении контейнера.

За обслуживание всех этих танцев со слоями и берется docker storage drivers.

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


🥷 Docker Ninja 🥷

🧑🏼‍💻 У композитора проекты за проектами 🧑🏼‍💻


Если вы хоть раз наблюдали как в Docker Desktop отображаются контейнеры, запущенные с помощью docker compose, то наверняка задавались вопросом: "А че это за прикол такой?"

А дело тут в том, что компоуз при запуске приложений из compose.yml оперирует абстракцией компоуз проекта. В него он включает все сервисы, их настроки, сети и тд. Зачем это нужно поговорим чуть позже, а вот удобства ради приведу вам одну интересную команду.

docker compose ls

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


🥷 Docker Ninja 🥷

🤔 Аргументный Аргумент 🤔

Когда работаем с Dockerfile, иногда требуется передавать переменные, которые могут изменяться в зависимости от окружения. С этой задачей нам поможет директива ARG.

ARG позволяет задавать значения, которые могут быть использованы на этапе сборки образа. Это особенно полезно, когда необходимо передать различные параметры, такие как версии ПО или пути.

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

FROM alpine

ARG VERSION=latest
RUN apk add --no-cache mypackage=$VERSION

Теперь, при сборке образа, можно указать нужную версию:

docker build --build-arg VERSION='1.2.3' .

Это делает ваш Dockerfile более универсальным и адаптивным к изменениям.


🥷 Docker Ninja 🥷

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

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

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

docker exec far_far_galaxy_container /order_66

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

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

🥷 Docker Ninja 🥷