Использование Docker в разработке приложений Java EE

Question

Я добавит 300 очков, как Баунти

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

У меня есть некоторые вопросы относительно того, как и на какой стадии я должен добавить приложение Java EE в контейнер. Как я вижу, это несколько способов сделать это.

Это был типичный рабочий процесс (в моей команде) до Docker:

1. Разработчик пишет код
2. Разработчик создает код с Maven производя WAR
3. Разработчик загружает WAR в консоли администратора JBoss/или с плагином Maven

Теперь, когда появился Docker, я немного смущен, если мне нужно создать нужные мне изображения и настроить их так, чтобы все это было ft, когда вы запускаете контейнер JBoss Wildfly, нужно развернуть приложение через консоль администратора в Интернете. Или я должен создать новый контейнер для каждого раза, когда я создам приложение в Maven и добавлю его командой ADD в файл Docker, а затем просто запустите контейнер, не развертывая его после его запуска?

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

Answer 1

Я долгое время использовал Докер с Glassfish и давно написал блог на эту тему here.

Его отличный инструмент для разработки JavaEE.

Для вашего образа производства я предпочитаю объединять все вместе, создавая статичное изображение базы и слои в новой WAR. Мне нравится использовать CI-сервер для выполнения работы и иметь конфигурацию CI для производственных ветвей, которая будет захватывать базовый слой в сборке релиза, а затем публиковать артефакт. Обычно мы вручную развертываем в производство, но если вы действительно хотите получить фантазию, вы можете даже автоматизировать это с развертыванием сервера CI в производственной среде и с использованием прокси-серверов для обеспечения новых сеансов, которые приходят, чтобы получить обновленную версию.

В разработке мне нравится придерживаться того же подхода, когда приходит время локально запускать все, что полагается на контейнер (например, тесты по интеграции в Аркиллиан) до проверки кода. Это позволяет окружающей среде как можно ближе к производству, что, на мой взгляд, важно, когда дело доходит до тестирования. Это одна из главных причин, по которой я против таких подходов, как тестирование со встроенными контейнерами, но развертывание для не внедренных. Я видел множество случаев, когда тест проходит во встроенной среде и не работает в производственном/не встроенном.

Во время цикла разработки/развертывания/ручной проверки, прежде чем совершать код, я считаю, что подход к развертыванию в контейнер (который является частью базового изображения) более экономичен с точки зрения скорости этого dev. цикл против здания в вашей WAR каждый раз. Это также лучший подход, если ваша среда для разработчиков использует инструмент JRebel или XRebel, где вы можете быстро развернуть свой код и просто обновить браузер, чтобы увидеть изменения.

Answer 2

Как обычно вы устанавливаете что-либо с Docker, создавая новое изображение поверх базового изображения платформы. Таким образом, вы следуете философии связывания зависимостей Docker.

С точки зрения Maven, вы можете создать сборку tarball (предположим, что это называется jars.tar), а затем позвоните ADD jars.tar /app/lib в Dockerfile. Вы также можете реализовать плагин Maven, который также создает файл Docker.

Это самый разумный подход с Докером сегодня, другие подходы, такие как изображение здания FROM scratch не совсем применимы для приложений Java.

См. Также Java JVM on Docker/CoreOS.

Answer 3

Возможно, вы захотите взглянуть на rhuss/docker-maven-plugin. Это позволяет бесшовную интеграцию для использования докера в качестве единицы развертывания:

• Используйте стандартный Maven дескриптор сборки для создания изображений с docker:build, поэтому вы создали файл WAR или ваш Microservice может быть легко добавлен в Докер изображение.
• Вы можете нажать созданное изображение с docker:push
• С docker:start и docker:stop вы можете использовать образ во время модульных тестов.

Этот плагин содержит исчерпывающую документацию, если есть какие-либо открытые вопросы, пожалуйста, откройте проблему.

И, как вы могли заметить, я являюсь автором этого плагина ;-). И, честно говоря, есть другие докеры-maven-плагины, которые все имеют немного другой фокус. Для простой проверки вы можете взглянуть на shootout-docker-maven, который предоставляет примеры конфигураций для четырех наиболее активных плагинов maven-docker.

Рабочий процесс затем просто сдвигает границу артефакта из WAR/EAR файлов на изображения Docker. mvn docker:push перемещает их в реестр Docker, откуда он вытаскивается на разных этапах тестирования, используемых в конвейере непрерывной доставки.

Answer 4

В блоге пост о настройке JRebel с Докер по Arun Gupta, вероятно, будет удобно здесь: http://blog.arungupta.me/configure-jrebel-docker-containers/

Answer 5

Я попробовал Двойники сценарий использовать докер для запуска моего приложения. В моей ситуации я хотел начать докер с помощью tomcat, который вел войну. Затем на этапе интеграции-теста maven запускает тест интеграции огурца/фантома на докере. Пример реализации документирован в https://github.com/abroer/cucumber-integration-test. Вы можете расширить этот пример, чтобы нажать изображение докера на свое личное репо, когда тест будет успешным. Толкаемое изображение может использоваться в любой среде от разработки до производства.

Answer 6

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

Вернуться к описанию вашего рабочего процесса: для любого типичного приложения Java EE необходимы сервер приложений и сервер базы данных. Поскольку вы не упоминаете в своем сообщении о том, как настроена база данных, я бы предположил, что ваша среда разработки будет иметь отдельный сервер базы данных для каждого разработчика.

Принимая все это в предположение, я мог бы предложить следующий рабочий процесс:

• Построить базу Wildfly сервер приложений с официальным образом. Вы можете достичь этого путем: "Docker блату" команды
• Запустите сервер приложений базы с:

докер запустить -d -p 8080 -это: 8080 -p 9990: 9990 --name baseWildfly JBoss/wildfly

сервер приложений работает в настоящее время, необходимо настроить его для подключения к серверу базы данных, а также настроить параметры DataSource и другую конфигурацию, если для того, необходимые для запуска приложения Java EE. Для этого вам необходимо войти в Баш терминал контейнера JBoss:

докер ехес -i -t baseWildfly/бен/Баш/

Вы теперь в терминале контейнера. Вы можете настроить сервер приложений так же, как и для любой среды Linux.

Вы можете проверить конфигурацию, вручную развернув файл WAR в Wildfly. Это можно легко сделать с помощью консоли администратора или плагина maven или команды ADD, как вы сказали. Обычно я делаю это с помощью консоли администратора, просто для тестирования быстро. Когда вы убедитесь, что конфигурация работает, вы можете удалить файл WAR и создать снимок вашего контейнера:

докер фиксации --change «добавить параметры базы и конфигурации» baseWildfly yourRepository: тег

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

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

Предполагая, что вы настроили Maven для создания файла WAR в «../your_project/deployments/», вы можете связать, что в каталог развертывания JBoss контейнера следующим образом:

Docker запуска -d - р 8080: 8080 -v ../your_project/deployments:/opt/jboss/wildfly/standalone/deployments

Теперь, каждый раз, когда вы пересобрать приложение с Maven, сервер приложений будет проверять изменения и перераспределить ваш файл WAR.

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

Предполагая, что вы используете Postgres в качестве вашего сервера db, вы можете вытащить его из официального хранилища postgres.Если у вас есть изображение готово, вы можете запустить сервер БД:

Docker пробег -d -p 5432: 5432 -t --name postgresDB Postgres

или запустить сервер базы данных со связанной "данные" каталога:

докер запустить -d -p 5432: 5432 -v ../your_postgres/data:/var/lib/postgresql -t --name postgresDB Postgres

Первая команда сохранит ваши данные в контейнере, а последняя сохранит ваши данные в env.

Теперь вы можете связать свой контейнер базы данных с Wildfly:

Docker запустить -d -p 8080: 8080 --link postgresDB: база данных -t baseWildfly

Ниже приводится выход ссылка:

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

Эти же базовые изображения могут использоваться для производственной среды, так что всякий раз, когда вы хотите опубликовать новую версию, вам просто нужно скопировать файл WAR в папку «your_deployment» хоста.

Хорошо, что сервер приложений и сервер db-приложений - это то, что вы можете легко сгруппировать его в будущем, чтобы масштабировать его или применить высокую доступность.

Answer 7

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

<plugin> 
      <groupId>org.codehaus.mojo</groupId> 
      <artifactId>exec-maven-plugin</artifactId> 
      <version>${plugin.exec.version}</version> 
      <executions> 
       <execution> 
        <id>docker</id> 
        <phase>package</phase> 
        <goals> 
         <goal>exec</goal> 
        </goals> 
       </execution> 
      </executions> 
      <configuration> 
       <executable>docker</executable> 
       <arguments> 
        <argument>cp</argument> 
        <argument>${project.build.directory}/${project.build.finalName}</argument> 
        <argument>glassfish:/glassfish4/glassfish/domains/domain1/autodeploy</argument> 
       </arguments> 
      </configuration> 
     </plugin> 

Как только вы запустите: mvn clean package, контейнеры начнут развертывание и начнет развертывание последней войны.