Большинство людей знают о преимуществах запуска своих производственных приложений в контейнерах докеров. Однако многие люди, похоже, упускают из виду положительные стороны использования докер-контейнеров для повседневной разработки.

Зачем разрабатывать в контейнерах Docker?

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

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

Давайте подробнее остановимся на этих четырех преимуществах.

Разные версии голанга

Разработка в docker-контейнере означает, что вы можете использовать любую версию go, какую захотите. Это удобно, если вы работаете с несколькими приложениями go, каждое из которых использует свою собственную версию go.

Например, есть приложение, с которым я работаю, которое использует версию go версии 1.11.3. Это приложение еще не настроено для разработки докеров, поэтому на моем локальном компьютере установлена ​​версия 1.11.3. Таким образом, когда я разрабатываю это приложение, я могу использовать конкретную версию go, с которой оно будет работать в производственной среде.

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

Хотя есть фантастические варианты, такие как gvm, для установки на вашем компьютере нескольких версий go. Я считаю, что проще и менее утомительно просто использовать образ Docker с конкретной версией go, которая мне нужна.

Переход от разработки к производству

Это кое-что связано с вышеизложенным: наличие среды разработки, максимально приближенной к производственной, всегда хорошо (всегда это сильное слово, но я не могу придумать причину, по которой было бы лучше иметь среда разработки отличается от продакшена больше, чем нужно).

Такое сходство между разработкой и производством действительно может помочь сократить количество ошибок типа «Это работает на моей машине» и упростить процесс CI / CD.

Разработка внутри контейнера также познакомит вас с командами и особенностями докеров, которые могут помочь вам при отладке контейнеров докеров в производственной среде.

Легкая адаптация

Выполнение вашей разработки в контейнере докеров может означать, что адаптация нового разработчика так же проста, как установка Docker, отправка им вашего файла .env, а затем выполнение простой команды, такой как docker-compose up.

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

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

Тестирование кода базы данных

Тестирование кода базы данных может разочаровывать. Смехаться сложно и, похоже, не придает нужной уверенности. Для развертывания локальной базы данных необходимо установить множество зависимостей и решить ряд собственных проблем, таких как поддержание правильных версий, не забывая о том, что база данных запущена и занимает ценное место на жестком диске.

При разработке с помощью Docker эти проблемы исчезают. Запуск вашего приложения с помощью docker-compose легко вызывает тестовую базу данных, которая автоматически добавляется в вашу сеть приложений. Это упрощает обмен версиями базы данных, устраняет необходимость помнить о запуске базы данных и позволяет легко удалять изображения, когда они больше не нужны.

При сотрудничестве с другими разработчиками это также упрощает работу с одной и той же версией базы данных.

Минусы разработки в контейнерах Docker

После рассмотрения этих положительных сторон разработки внутри контейнеров Docker будет справедливо упомянуть о некоторых недостатках.

* Больше работы над начальной настройкой проекта
* Отладка может быть более сложной
* Добавляет еще один уровень сложности

Больше работы по настройке проекта

Выполнение разработки в докере обычно означает, что вам нужен еще один файл Dockerfile специально для разработки. Это означает, что вам нужно выполнить настройку. Вы также, вероятно, захотите использовать docker-compose, что означает, что вам понадобится файл docker-compose.yml. Это добавляет небольшой объем дополнительной работы, когда вы впервые настраиваете свой проект, но в долгосрочной перспективе я считаю, что это экономит ваше время и облегчает вашу жизнь разработки.

Отладка сложнее

Вы больше не можете просто запустить локальный отладчик. Это может быть проблемой, если вы привыкли регулярно использовать отладчик. Однако с такими инструментами, как VsCode Remote Development, теперь это не намного сложнее, чем локальная отладка.

Добавляет еще один уровень сложности

Разработка в Docker добавляет еще один уровень сложности, о котором вы должны подумать, но если ваше приложение работает в Docker во время производства, это хорошая привычка регулярно думать об этой сложности. Не только это, но и сложность дает столько преимуществ, что я думаю, что в конечном итоге это того стоит.

Вывод

Спасибо, что прочитали о том, почему мне нравится использовать контейнеры Docker во время разработки. Надеюсь, вы кое-что узнали и подумываете об использовании Docker как в разработке, так и в производстве.