Облачная экосистема

Так как образ состоит из слоёв, совместно используемых в разных образах, то в разных нештатных ситуациях эти слои остаются. Поскольку отдельно мы их использовать не можем, то безопасно их удалить командой docker image prune.

Для сохранения результатов работы контейнера можно примонтировать папку хостовой машины к папке контейнера. Мы можем явно указать папку на хостовой манине, например, docker run -v /page_host:/page_container nama_image, или дать возможность сгенерировать её docker run -v /page_container nama_image. Для удаления сгенерированных папок (томов), которые уже не используются контейнерами введите команду docker valume prune. Для сборки неиспользуемых сетей, также есть свой сборщик мусора.

Также есть единый сборщик мусора, по факту, просто объединяющий специализированные в один с логически совместимыми параметрами docker system prune. Имеется тенденция его ставить в крон. Можно также посмотреть на занимаемое место всеми контейнерами, всеми образами и всеми томами с помощью команды docker system df, а также без группировки – docker system df -v.

Многие проблемы, описанные здесь созданием мусора решаются программой docker-compose. К тому же она существенно упрощает жизнь, если только вы не запустили контейнера разово для экспериментов. Так команда docker-compose up запускает контейнера, а docker-compose down -v их удаляет, так-же удаляются все зависимости между ними. Все параметры запуска контейнера описываются в docker-compose.yml, а также связи между ними. Благодаря этому, при изменении параметров запуска контейнеров не нужно заботиться, чтобы удалить старые и создать новые, не нужно прописывать все параметры контейнеров – просто запасть с параметром up и она либо пересоздаст, либо обновит конфигурацию контейнера.

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

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

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

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

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

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

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

* С появление интернета массово ПО устанавливается с помощью пакетных менеджеров, при выхове которых, из удалённого репозитория ОС оно скачивается и устанавливается. Он старается следить и поддерживать совместимость совместимость программ. Дальнейшее изучение и использование программы: как запустить, как настроить, как понять что она работает ложится на пользователя или системного администратора.