как использовать докер в разработке

Question

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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