Блог

Я новичок в docker, и я проделал некоторую основную работу над docker, например, как создать образ, как создать контейнер, что такое dockerfile.yml, файл docker-compose.yml выполняет и т.д. Я практиковался на своем локальном компьютере. У меня возникают следующие вопросы, когда дело доходит до разработки в реальном времени с использованием docker.

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

2) Для каждого выпуска мы сохраняем контейнер или образ для этого выпуска?

3) что является наилучшей практикой для поддержания базы данных, означает ли это, что мы включаем базу данных в образ и создаем контейнер или мы включаем только связанные с приложением вещи и создаем образ и контейнер, и этот контейнер будет взаимодействовать с базой данных, которая находится во внешнем контейнере или на физическом сервере базы данных?

Заранее спасибо.

Подобные вопросы, как правило, не имеют окончательного ответа. Это сильно зависит от вашей компании, вашей команды, используемого инструментария, программного стека и т.д. Лучшее, что можно было бы сделать, — это обратиться к старшим специалистам по разработке и высшему техническому руководству вашей организации, чтобы помочь сформулировать ответы на подобные вопросы.

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

1) Зависит от того, что наиболее удобно для разработчиков и какой язык вы используете. Некоторые разработчики считают, что рабочий процесс со всеми контейнерами удобен, некоторые разработчики считают, что они могут быстрее выполнять итерации с их существующим рабочим процессом IDE / CLI и тестировать с использованием изображений контейнеров в последнюю очередь.

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

2) Да. Для этой цели вы можете использовать тегирование контейнера.

3) Запуск баз данных в контейнерах возможен, но если ваша команда не имеет опыта работы с контейнерами и их оркестровкой, я бы оставил базы данных на традиционном «голом металле» или виртуальных машинах.

Контейнеры — это причудливая оболочка вокруг одного процесса Linux. Как правило, эмпирическое правило заключается в одном контейнере для одного процесса. Вы не должны объединять несколько объектов в одном контейнере. (Эта история становится немного сложнее, когда вы переходите к чему-то вроде Red Hat OpenShift или Kubernetes, поскольку обсуждение вращается вокруг количества контейнеров в pod).

1. Настройка, к которой я привык, заключается в том, что разработчики в основном игнорируют Docker, пока он не понадобится им для развертывания. Такие инструменты, как node_modules каталог узла или виртуальные среды Python, могут помочь изолировать подпроект друг от друга. Любой отдельный разработчик должен иметь возможность запускать docker build для создания образа, но обычно это не требуется до финальных этапов тестирования конкретного изменения. Вам следует развернуть систему непрерывной интеграции, которая возьмет на себя ответственность за тестирование и создание окончательного образа Docker для каждого коммита.

2. Вы никогда не «поддерживаете контейнеры». Если контейнер выходит из строя, удалите его и запустите новый. Ваша система CI должна создавать образ для каждой версии, и вам следует развернуть реестр для их хранения.

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

Нет технической причины, по которой вы не можете использовать Docker Compose для производства, но если вам в конечном итоге потребуется развернуть ваше приложение более чем на одном физическом сервере, вы можете обнаружить, что это ограничивает. Kubernetes сложнее, но, похоже, является текущим победителем в этой области; Docker Swarm набирает обороты; Hashicorp Nomad уже существует; или вы можете создать систему ручного развертывания вручную. (Обратите внимание, что, по крайней мере, Kubernetes и Nomad оба очень сильны в концепции «что-то изменилось, поэтому я собираюсь удалить и воссоздать контейнер», и оба чрезвычайно усложняют разработку в режиме реального времени в квазипроизводственной установке.)

Также обратите внимание, что там, где я говорю «развернуть», есть версии всех этих вещей в общедоступном облаке (Docker Hub, CircleCI, комплексные решения, включая реестр и Kubernetes, построенные поверх AWS, Azure или GCP), и если вас устраивает соотношение затрат и усилий и последствия использования внешнего сервиса в вашей цепочке сборки / развертывания, то это может помочь вам быстрее приступить к работе