Сценарии развертывания Java EE для контейнеров Docker

Некоторое время я публиковал некоторый контент вокруг Docker, и мне вообще нравится играть с контейнерами. Вы можете найти дополнительную информацию о том, как запустить Docker-Machine в Windows, а также о том, как использовать клиент Docker 1.6 . Одной из первых публикаций в блоге была сборка всех видов ресурсов о Java EE, Docker и Maven для разработчиков Java EE . Работа более подробно и часто с контейнерами поднимает вопрос о том, как должны распространяться приложения Java EE и как разработчики должны использовать контейнеры. Это пытается уточнить немного и дать вам хороший обзор о различных вариантах.

Базовое изображение против пользовательского изображения и некоторые основы

Скорее всего, ваш сервер приложений доступен в публичном реестре, известном как Docker Hub . Это верно для WildFly. Первое решение, которое вы должны сделать, это то, хотите ли вы использовать одно из базовых изображений или собираетесь испечь свое собственное изображение. Бег с базой в значительной степени:

и ваш экземпляр будет запущен через секунду после загрузки базового образа. Но что это значит? И как это работает? В основе каждого контейнера лежит Linux. Подросток один. В обычном Linux ядро ​​сначала монтирует корневую файловую систему только для чтения, проверяет ее целостность, а затем переключает весь том rootfs в режим чтения-записи. Подростковый Linux в контейнере Docker делает это по-другому. Вместо того, чтобы переключать файловую систему в режим чтения-записи, она использует преимущество монтирования для добавления файловой системы чтения-записи поверх файловой системы только для чтения. На самом деле может быть несколько файловых систем, доступных только для чтения, расположенных друг над другом. Если вы посмотрите на изображение jboss / wildfly, это то, что вы видите на первый взгляд:

Вы видите четыре разных уровня на этой картинке. Давайте не будем называть их слоем, потому что они еще не. Это иерархия изображений, которые являются основой для нашего изображения jboss / wildfly. Каждое из этих изображений состоит из Dockerfile . Это пустой текстовый файл с кучей инструкций. Вы можете думать об этом как о некоем pom-файле, который нужно обрабатывать с помощью инструмента « Builder ». Он может содержать различные команды и параметры для добавления пользователей, томов, добавления программного обеспечения, загрузок и многого другого. Если вы посмотрите на файл Docker jboss / wildfly, вы увидите команды, которые составляют изображение:

Первая строка определяет базу, из которой получено изображение. Глядя на jboss / base-jdk: 7 Dockerfile показывает корень, который является jboss / base .

Теперь представьте, что каждая из этих строк что-то делает с файловой системой. Самый очевидный пример — загрузка. Это добавляет что-то к этому. Но вместо записи в уже смонтированный раздел, он складывается как новый слой. Глядя на все слои jboss / wildfly, мы суммируем до 19 уникальных слоев общим размером 951mb .

Используя базовый образ, вы можете ожидать, что под рукой будет конфигурация по умолчанию. И это отличное место для начала. Мы в JBoss стараемся сделать наши проекты (и продукты тоже!) Готовыми к использованию для максимально возможного количества вариантов использования, но не существует способа, чтобы одна конфигурация могла удовлетворить потребности каждого. Например, мы поставляем 4 варианта конфигурационного файла standalone.xml вместе с WildFly, поскольку существует очень много различных сценариев развертывания. Но этого все еще недостаточно. Мы должны быть в состоянии настроить его в любой момент. Изображение jboss / wildfly здесь не исключение.

Создание собственного изображения с

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

Приложения Java EE — в Docker

Один из основных принципов Docker — «Воссоздать — не изменять». Поскольку контейнер является неизменяемой частью инфраструктуры, доступной только для чтения, с очень ограниченными возможностями, которые можно изменять во время выполнения, вас могут заинтересовать различные варианты развертывания приложения.

Dockerize It

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

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

Недостатки:

• Нет повторных развертываний. каждый
• Без изменений
• Новая версия, новая версия изображения
• Не типичная модель операций на данный момент.
• Возможно, понадобятся дополнительные инструменты (плагины для Maven / Jenkins)

Преимущества:

• Докер Путь
• Легко интегрировать в ваш проект .
• Простота развертывания и настройки

Контейнеры как инфраструктура

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

Недостатки:

• Более сложное наслоение для сохранения состояния в контейнерах
• Не путь докера
• Не модно.
• Централизованное управление и администрация

Преимущества:

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

Рекомендация

Это трудно. Я бы посоветовал вам посмотреть, что лучше всего подходит для вашей ситуации. Большинство корпоративных компаний склонны придерживаться решения «Контейнеры как инфраструктура». У этого есть много недостатков, чтобы смотреть на это с точки зрения разработчиков. Приличным промежуточным решением может быть OpenShift v3, которое оптимизирует операции для контейнеров и принесет много удобства и простоты в мир Java EE PaaS.

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