Как лучше использовать Docker в непрерывной доставке?

Ответ 1

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

• Отделите код развертывания (банки/войны и т.д.) от контейнеров докеров в отдельных VCS-репозиториях (мы использовали два разных Git -repos в моем последнем проекте). Это означает, что изображения докеров, которые вы используете для развертывания вашего кода, встроены в отдельный шаг. Докер-построить так сказать. Здесь вы можете, например, создайте изображения докеров для вашей базы данных, сервера приложений, кеша redis или аналогичного. Когда в вашем VCS "Dockerfile" или аналогичный был изменен, Jenkins или все, что вы используете, может инициировать сборку изображений докеров. Эти изображения должны быть помечены и помещены в какой-либо реестр (может быть Docker Hub или какой-либо локальный реестр).
• Развертываемый код (банки/войны и т.д.) должен быть построен, как обычно, с помощью Jenkins и commit-hooks. В одном из моих проектов мы фактически запускали Jenkins в контейнере Docker как описанном здесь.
• Все контейнеры докеров, которые используют динамические данные (например, хранилище для базы данных, военные файлы для Tomcat/Jetty или файлы конфигурации, которые являются частью базы кода) должны монтировать эти файлы как тома данных или в контейнерах объема данных.
• Серверы тестирования или любые шаги, которые являются частью вашего конвейера, должны быть настроены в соответствии со спецификацией, которая известна вашему серверу сборки. Мы использовали дескриптор, который связал ваш недавно созданный тег с базой кода с тегом на контейнерах докеров. Затем плагин конвейера Jenkins мог запустить script, который сначала перенесли артефакты сборки на хост-сервер, вытащил правильные изображения докеров из локального реестра, а затем начал все процессы с использованием контейнеров объема данных (мы использовали Fig для управления жизненным циклом докера.

При таком подходе мы также могли запускать наши локальные процессы (базы данных и т.д.) в качестве контейнеров Docker. Эти контейнеры, конечно, были основаны на тех же изображениях, что и на производстве, и также могут быть разработаны на машинах dev. Единственной реальной разницей между локальной средой разработчиков и производственной средой была операционная система. В машинах dev обычно работала Mac OS X/Boot2Docker, а prod - в Linux.

Ответ 2

Да, вы должны перейти от файлов jar/war к изображениям в качестве артефактов сборки. Процесс, описанный в @wassgren, должен хорошо работать, однако я нашел следующее, чтобы лучше соответствовать нашему варианту использования, особенно для разработки:

1- Сделать базовое изображение. Похоже, что вы являетесь магазином java, например, давайте сделаем вид, что ваше базовое изображение FROM ubuntu:14.04 и устанавливает jdk и некоторые из наиболее распространенных библиотек. Позвольте называть его myjava.

2- Во время разработки, используйте fig, чтобы открыть свой контейнер локально и смонтировать ваш код dev в нужное место. Рис использует базовое изображение myjava и не заботится о файле Docker.

3- Когда вы строите проект для развертывания, он использует файл Docker, а где-то он делает COPY артефактов кода/сборки в нужном месте. Затем изображение будет помечено соответствующим образом и развернуто.

Ответ 3

простых шагов для выполнения.

1) Установите jenkins в контейнер

2) Установите инструмент рамки в том же контейнере (я использовал SBT).

3) Создайте проект в jenkins с необходимыми плагинами, чтобы интегрировать данные из gitlab и собрать все jar в сжатый формат (скажем build.tgz).

4) Этот файл build.tgz можно перемещать в любом месте и запускать, но он должен удовлетворять всем его зависимостям среды (например, например, он требует mysql).

5) Теперь мы создаем образ базовой среды (в нашем случае mysql установлен).

6) При каждом запуске сборки мы должны вызвать файл докеров на сервере, который будет комбинировать файл build.tgz и среды.

7) Теперь у нас есть наш build.tgz вместе с удовлетворенной средой. Это изображение должно быть перенесено в реестр. Это наше окончательное изображение. Оно переносимо и может быть развернуто в любом месте.

8) Это окончательное изображение можно сохранить в контейнере с необходимыми точками монтирования для получения выходов, а script (script.sh) можно запустить, указав команду entrypoint в файле docker.

9) Этот script.sh будет внутри изображения (базовое изображение) и будет настроен на выполнение действий в соответствии с нашей целью.

10) Перед тем, как сделать этот контейнер, вам нужно остановить ранее запущенный контейнер.

Важные замечания:

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

Ответ 4

Вы также можете создать стабильный конвейер CD с Bamboo и Docker. Интеграция Bamboo Docker происходит как в форме агента сборки, так и в виде связанной задачи внутри приложения. Вы можете найти эту статью полезной: http://blogs.atlassian.com/2015/06/docker-containers-bamboo-winning-continuous-delivery/

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

Удачи!