♻️ 7 бед - один reset ♻️

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

docker restart  <container_name>

Команда останавит и сразу же запустит контейнер заново. Легкий способ обновления конфигурации для ваших контейнеров без лишних усилий и первая команда при траблшутинге приложений!

🏴‍☠️ Портовый Жан-Батист 🏴‍☠️

Утилита docker-compose, а с некоторого времени плагин для docker docker compose значительно упрощает запуск и управление многоконтейнерными приложениями.

Заюзать его просто, как дважды два:
1. Описываем что за контейнеры мы хотим развернуть в файле docker-compose.yml
2. Для быстрого старта используем команду:

docker-compose up

3. Наблюдаем бегущие строки запуска в терминале
4. А далее ловим логи в stdout

👨🏼‍🦳 Старикам тут не место 👨🏼‍🦳

Не prune-ом единым жив devops-инженер! Порою возникает необходимость удалить какой-то конкретный контейнер и на этот случай, конечно же есть команда.

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

docker rm <container_id>

Быстро и эффективно ликвидирует контейнер и, в отличие от Чигура, делает свою работу не прибегая к случайности. Если вы, конечно, понимаете о чем я.😈

🗡 Кто ты, воин? 🗡

Наверное, мало кто задумывается, но то, что мы называем докером, на самом деле зовется Docker Engine.

Docker Engine по своей сути это технология контейнеризации и действует она как клиент-серверное приложение со следующей архитектурой:
- Сервер в виде демон-процесса dockerd.
- API, через которое с dockerd взаимодействуют клиентские приложения.
- Клиент в виде интерфейса командной строки (CLI) docker.

CLI болтает с dockerd через предоставленный API, но так же есть и другие клиенты, которые могу использовать либо API либо CLI.
dockerd же управляет объектами Docker (images, containers и тд).

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

Директива 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 команда несомненно полезная, но стоит понимать, что, как и во всем, тут не все так просто! Могут возникнуть ситуации, когда вы, запустив эту команду, не увидите ничего путного в выводе.

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