Евгений Штольц - Из разработчика в архитекторы. Практический путь

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

Экономия времени на создание контейнера

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

Для стандартных программы: не нужно устанавливать, не нужно поддерживать

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

* В те времена, когда все программы писались на ассемблере, программы распространялись по почте, у уже

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

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

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

* Во время распространения на дисках уже компании писали свои программные продукты на более высокоуровневых

языках, проверяли под разные версии ОС. Здесь и далее будем рассматривать свободное ПО. Программа уже содержала

MakeFile, который сам компилировал программу и её устанавливал.

* С появление интернета массово ПО устанавливается с помощью пакетных менеджеров, при выходе которых, из

удалённого репозитория ОС оно скачивается и устанавливается. Он старается следить и поддерживать совместимость

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

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

* С появлением Docker Hub и Web приложения скачиваются и запускаются контейнером. Его, обычно, для начальной

работы не нужно настраивать.

Безопасность и надёжность

но и для контейнеров и образов в целом у сервера: объёма свободно места и занимаемого пространства. По умолчания для всех контейнеров и образов отводится 10G, при этом из этого объёма должно оставаться как dm.min_free_space=5 %, но лучше поместить в конфиг, который возможно прийдётся создать как /etc/docker/daemon.json:

{

"storage-opts": [

"dm.basesize=50G",

"dm.min_free_space=5 %",

]

}

Можно ограничить ресурсы потребляемые контейнером в его настройках:

* – m 256m – максимальный размер потребления оперативной памяти (здесь 256Mb);

* – c 512 – вес приоритета на использование процессора (по умолчанию 1024);

* —cpuset="0,1" – номера разрешённых к использованию ядер процессора.

Управление контейнерами

Мы управляем контейнерами с помощью команды Docker. Теперь, допустим, появилась необходимость управлять удалённо. Использовать VNC, SSH или другое для управления командой Docker наверное, будет слишком трудоёмким если задача усложнится. Правильно, сперва будет разобраться, что из себя представляет Docker, ведь команда Docker и программа Docker не одно и тоже, а точнее команда Docker является консольным клиентом для управления клиент серверным приложение Docker Engine. Команда взаимодействует с сервером Docker Mashine через Docker REST API, который и предназначен для удалённого взаимодействия с сервером.