📚 Ну это база! 📚

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

Например, чтобы начать с базового образа Ubuntu, пишем следующее:

FROM ubuntu:latest

Вот так вот берем базовый образ и добавляем свои уникальные слои (про Layered file system помним, ага?).

FROM, к слову можно встретить в Dockerfile не один раз, но это уже совсем другая история.

🏞 Из-за леса, из-за гор... 🏞

Хоть используя docker, хоть Dockerfile, хоть compose, нам всегда приходится работать с образами контейнеров. Но эти самые образы перед использованием приходится скачивать из какого-то Docker Registry. Поможет нам в этом команда docker pull.

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

Програмироваем в терминале вот такое:

docker pull <image_name>:<image_tag>

И далее, просто ждем.

🖖 Спокойно, коллега 🖖

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

Именно она, помимо прочих преимуществ, облегчает и процесс скачивания образа.

🚫 Экспонаты руками не трогать! 🚫

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

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

Один из таких механизмов - read-only режим запуска:

docker run --read-only alpine

Запуск контейнера в режиме read-only предотвращает изменения файловой системы, что особенно полезно для повышения безопасности и обеспечения неизменности контейнера.

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

⚠️ Disclamer ⚠️

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

Поэтому, настоятельно рекомендую поизучать этот вопрос самостоятельно!

🫨 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 🥷