Я работаю с Docker на полурегулярной основе уже пару месяцев. Я являюсь техническим лидером для продукта, который не только имеет обычный разработчик и тест, но и несколько развертываний, связанных с пользователем. Эти развертывания могут иметь 5 или 50 пользователей (или более) и могут быть доступны через Интернет внешними пользователями или доступны только для интрасети компании без внешнего подключения. Docker, казалось, был хорошим способом оптимизировать развертывание — где -либо Docker может быть установлен, наш программный стек также может быть установлен.
Некоторые уроки, которые я усвоил на этом пути:
Всегда отображайте объемы
Это был тяжелый урок. Я развернулся вверх и вниз по контейнеру MySQL для локального тестирования, и это произошло последнее, что я встал, я забыл отобразить каталог данных обратно на один на хосте. Я не обращал внимания, сдул контейнер и потерял много местных данных. Очевидно, что потому, что это была моя местная среда, я мог вернуть ее, но я потерял час или две работы, вернувшись туда, где я начал.
Очевидно, что есть преимущество в том, чтобы иметь возможность делиться объемами в разных контейнерах, но хорошо всегда иметь напоминание о том, что контейнеры предназначены для эфемерных.
Скрипт все
Мои первые пару контейнеров были довольно простыми — одна часть приложения развернута на Apache Tomcat, поэтому я начал с этого контейнера в качестве основания и создал простой Dockerfile, чтобы в основном упасть в войну и двигаться дальше. Затем я совершил ошибку, начав заниматься своим контейнером вместо того, чтобы работать над обновлением DockerFile. У меня было в голове то, что нужно было сделать, чтобы получить рабочий контейнер, но когда мы перешли команду на использование Docker для их местных сред, он быстро стал неустойчивым. Урок: всегда сохраняйте ток Dockerfile и обязательно восстановите из этого Dockerfile, а не совершал контейнер. Это создает повторяемый процесс для создания контейнера, и по умолчанию контролируется версией. Так что легко увидеть, как проект развился со временем.
Это касается коммунальных контейнеров, таких как MySQL или Memcached, которые могут иметь изменение или два, но в значительной степени остаются прежними, как и то, что было снято из реестра Docker. Даже поместите эти незначительные обновления в Dockerfile где -то в репозиции GIT, чтобы контролировать изменения.
Недавно мы начали использовать Nexus в качестве внутреннего реестра. Кажется, он работает хорошо и экономит шаг необходимости строить контейнеры на месте; Их функция реестра Docker относительно новая, хотя Так что будет интересно посмотреть, как он развивается в течение следующих нескольких выпусков. До сих пор наибольшее преимущество заключается в том, что в реестре всегда есть текущие сборки DEV и тестирования от Jenkins, чтобы разработчики могли легко сохранить их местные среды, а некоторые сценарии Bash позволяют легко захватить последние контейнеры и выбрать, какая среда развертывается.
На связанной ноте — Docker -Compose является спасением жизни. У нас есть 8 контейнеров для нашего веб -приложения, и требуется использование комплекса. Опять же, файл Docker-Compose контролируется версией, и с обзорами кода по всем запросам привлечения нет сюрпризов с обновлениями развертывания.
Это приводит меня к тому, что я нашел большую головную боль с докером — общие свойства.
Общие свойства
Во многих случаях, когда мы развертываем, система общается с внешней базой данных, и все контейнеры имеют одинаковую конфигурацию; Что ж, по крайней мере, они делятся хостом и портом (вы не делитесь именами пользователей и паролями для различных компонентов даже в одной и той же базе данных, вы ???). Чтобы облегчить нашу жизнь, мы добавили сценарий Ruby, чтобы обернуть Docker-Compose, который фактически создает новый Docker-Compose.yml, который берет общие свойства и копии, затем в каждый из списков свойств контейнеров. У нас есть базовый набор свойств, некоторые контейнерные свойства, которые расширяют/перезаписывают их по мере необходимости, и они в сочетании с базовым файлом с композитом Docker для создания нового файла, который является фактическим файлом составления, в котором мы читаем.
Несмотря на то, что немного странно запускать сценарий обертки вместо того, чтобы напрямую сопоставить Docker, преимущества не повторяют конфигурацию в нескольких местах, что делает дополнительный шаг.
Докер великолепен; Мне было очень весело упростить развертывание путем контейнерирования, и я с нетерпением жду возможности изучить, как мы можем использовать Swarm, чтобы сделать наши развертывания более надежными и устойчивыми к неисправности.
Оригинал: «https://dev.to/ahansondev/lessons-learned-with-docker»