Вы наконец-то поддались контейнерам и обнаружили, что они решают множество проблем и имеют массу преимуществ:
- Контейнеры незыблемы: ОС, библиотеки, папки и приложения — поскольку все это хранится непосредственно в контейнере, вы на 100% уверены, что образ, проверенный в QA, всегда пойдет в производство.
И это будет работать точно так же.
- Контейнеры легкие: контейнер не тратит зря память.
Вместо сотен мегабайт и гигабайт контейнеру нужна память только для основного процесса.
- Контейнеры работают быстро: контейнер запускается так же быстро, как обычный процесс Linux. Не минуты, а буквально считанные секунды.
Однако многие до сих пор считают, что контейнеры — это виртуальные машины, и забывают об их самом важном свойстве…
Контейнеры эфемерны
Одноразовость — вот почему вам нужно изменить свой подход к обращению с контейнерами.И вот чего никогда не следует делать, чтобы не потерять преимущества контейнеров: 1. Нет необходимости хранить данные внутри контейнера.
В течение своего жизненного цикла контейнеры могут быть приостановлены, уничтожены или заменены.
Если приложение работает в контейнере, то версию 1.0 этого приложения можно будет легко изменить на версию 1.1 без потери данных или других проблем.
Поэтому, если вам нужно сохранить данные, вам нужно записать их на том.
Однако тогда нужно позаботиться о том, чтобы два контейнера не записывали в одно и то же место, чтобы не повредить данные.
Итак, убедитесь, что приложения корректно записывают данные в общее хранилище.
2. Нет необходимости разделять доставку приложений.
Некоторые думают, что контейнер — это то же самое, что виртуальная машина.
И большинство из них считают, что приложения следует разворачивать в уже существующие работающие контейнеры.
На самом деле это тоже возможно, особенно на этапе разработки, когда идет постоянная отладка и развертывание.
Но приложения должны поступать на конвейер компакт-дисков непрерывной доставки для передачи в отдел контроля качества или в производство только как часть собственного образа.
Помните: контейнеры неизменяемы.
3. Не нужно создавать большие изображения.
Большой имидж труднее распространять.
Поэтому в образ следует включать только те файлы и библиотеки, которые действительно необходимы для запуска процесса приложения.
Нет необходимости устанавливать лишние пакеты или запускать обновления (yum update), которые создают новый слой в образе и записывают в него множество файлов.
4. Нет необходимости использовать однослойную тару.
Чтобы эффективно использовать многоуровневые файловые системы, всегда создавайте отдельные уровни для ОС, для определения имени пользователя, для конфигурации и, наконец, для самого приложения.
Это облегчит воссоздание, поддержку и распространение изображений.
5. Не нужно создавать образы из запущенных контейнеров.
Другими словами, не используйте команду docker commit для создания образа, поскольку такие образы не будут воспроизводиться.
Вместо этого всегда используйте Dockerfile или другие инструменты S2I (источник-образ), обеспечивающие воспроизводимость.
Вы также можете легко отслеживать изменения в Dockerfile, если сохраните его в исходном репозитории (git).
6. Не используйте только последний тег.
Этот тег похож на SNAPSHOT для пользователей Maven. Из-за многоуровневой природы файловой системы контейнера теги очень полезны.
Однако вас может ожидать неприятный сюрприз, когда, например, после многомесячного перерыва вы решите собрать образ и вдруг обнаружите, что приложение больше не запускается, поскольку родительский уровень (FROM на языке Dockerfile) был заменен.
новой версией, которая не имеет обратной совместимости.
Или потому, что последняя версия, полученная из кэша сборок, оказалась не той, которую вы ожидали.
Кроме того, следует избегать тега последней версии при развертывании контейнеров в рабочей среде, поскольку вы не сможете отслеживать, какая версия образа запущена.
7. Нет необходимости запускать более одного процесса в контейнере.
Контейнеры идеально подходят для запуска одного процесса (http-демона, сервера приложений, СУБД).
В противном случае вы можете столкнуться со всякими неприятностями, например, с копанием журналов или обновлением процессов по отдельности.
8. Нет необходимости хранить учетные данные в образе — используйте для этого переменные среды.
Не пишите на изображении никаких логинов и паролей.
Вместо этого используйте переменные среды для извлечения соответствующих данных из источников, внешних по отношению к контейнеру.
Изображение Postgres — отличный пример того, как это сделать правильно.
9. Нет необходимости запускать процессы от имени root. «По умолчанию контейнеры Docker запускаются от имени пользователя root. (.
) Однако по мере развития технологий могут появиться другие, более безопасные варианты запуска по умолчанию.
В сегодняшних условиях требование привилегий root может рассматриваться как угроза и не может быть предоставлено во всех средах.
Директива USER используется для указания пользователя без полномочий root, под именем которого будет запускаться контейнер».
(Отрывок из руководства для авторов образов Docker) 10. Не полагайтесь на IP-адреса.
Каждый контейнер имеет свой внутренний IP-адрес, который может измениться после перезапуска контейнера.
Если приложению или микросервису необходимо взаимодействовать с другим контейнером, используйте переменные среды, чтобы передать желаемое имя хоста и номер порта из одного контейнера в другой.
Ты помнишь? Теперь вы можете смело использовать его.
Практические советы по использованию контейнеров можно найти в нашем блоге.
Теги: #разработка Linux #виртуализация #открытый исходный код #Red Hat #контейнеры
-
Мтс Решила Запретить Skype
19 Oct, 24 -
Что Для Вас Микроблог?
19 Oct, 24 -
Карьерные Стероиды. Путь Самурая
19 Oct, 24 -
Посвящается Java-Кодерам.
19 Oct, 24 -
Дж. Тригг. Правила Правописания
19 Oct, 24
