Альтернативная версия упаковки Java приложения в Docker

[@darken99]

Не пробовали на openjdk:8-jre-alpine запускать то же самое?

[@osigida]

Руки пока, к сожалению, не дошли… по отзывам должно работать.

[@12sd]

Никогда так не делайте, пожалуйста.
Смысл Dockerfile'a в том, что я могу взять и сделать такой же билд. В том, что система оркестрации (начиная от обычного docker-compose заканчивая Rancher) может взять и сбилдить контейнер. В том, что Jenkins + Docker plugin может билдить проект, в котором есть Dockerfile, пушить его в ваш/общедоступный Registry.

А здесь Вы зачем-то делаете тоже самое, но в maven-конфигурации. Смысла в этом крайне мало, а может добавить гемора при деплое этого сервиса куда-то.

[@osigida]

Эм, Вы и так можете взять проект и сделать такой же билд… ну и плюсы решения перечисленны в конце статьи.

[@sainnr]

Пример для Spring Boot в этом плане выглядит удачнее?

[@hamsterksu]

в свое время юзал вот этот очень удобный плагин от sptofy — https://github.com/spotify/docker-maven-plugin

[@axmetishe]

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

Мавен не руководствуется порядком написания, у него есть lifecycle в котором определены фазы сборки, для плагинов дефолтные задаются через аннотации, например:

io.fabric8.maven.docker.PushMojo
....
@Mojo(name = "push", defaultPhase = LifecyclePhase.DEPLOY)
@Execute(phase = LifecyclePhase.INITIALIZE)
public class PushMojo extends AbstractDockerMojo {
...

подробнее описано на https://maven.apache.org/developers/mojo-api-specification.html
Так что здесь необходимо посмотреть на какие фазы прибит гоал плагина, ну и переопределить при необходимости разбросав на разные фазы.

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

[@osigida]

Проблема не совсем в этом. Проблемы начинаются когда два плагина должны исполняться в одной фазе, например: сборка контейнера и сборка jar-ников проекта. Можно столкнуться с ситуацией когда контейнер будет собираться до того как собраны jar-ники и все упадет с ошибкой. Железно работает перенос сборки контейнера в более позднюю фазу (install, deploy), но это как-то не аккуратненько.

[@axmetishe]

Если плагины запускаются в одной фазе, то они исполняются в порядке описания в pom.xml, если смотреть на твой пример, у тебя там сборка jar в принципе не задана, потому как она используется по дефолту, однако, в этом случае порядок исполнения плагинов стоит проверить через генерацию эффективного пома.

[@axmetishe]

конкретно на примере указанного репозитория github-е:

    <plugin>
        <groupId>io.fabric8</groupId>
        <artifactId>docker-maven-plugin</artifactId>
        <version>0.16.4</version>
        <executions>
          <execution>
            <id>Build docker container</id>
            <phase>package</phase>
            <goals>
              <goal>build</goal>
            </goals>
....
      <plugin>
        <artifactId>maven-jar-plugin</artifactId>
        <version>2.3.2</version>
        <executions>
          <execution>
            <id>default-jar</id>
            <phase>package</phase>
            <goals>
              <goal>jar</goal>
            </goals>
          </execution>
        </executions>
....

build из докер плагина будет исполнен раньше запуска jar плагина

[@Borz]

если быть точнее, то даже не в порядке объявления в pom.xml, а в порядке объявления всех Execution блоков в effective-pom. Просто допускается опускать блок execution если он один

[@osigida]

оу, точно! спасибо!

[@axmetishe]

я это и имел ввиду=)

[@osigida]

спасибо вам обоим :-)

[@axmetishe]

Мне кажется отличный способ расширить типы поставки приложения.

[@osigida]

Версионированние может быть источником частых ошибок, на выяснение которых будет тратится много времени.
К примеру у нас в команде, сборка контейнера определена одни раз в родительском pom-e, куда заглядываешь не часто, а вот dokerfile прийдется хранить в каждом приложении. Так что файл проекта выходит не такой уж и большой.
Бонусом идет обновление сборки для всех проектов одновременно! А их много…

Более того возможность использовать maven большой плюс.
Например:
— Мы теггируем контейнер еще и ревизией гита, которая опять же легко поставляется мавеном.
— Каждый разработчик имеет свой собственный спейс в докер репозитории, так что мы не мешаем друг другу собирая и отлаживая рабочие версии, в том числе и на тест окружениях. Имя пользователя поставляется мавеном.
— Ну и может вам и ненужен контейнер локально, но очень часто для того чтоб запустить нечто, нужно поставить много разных пакетов, что не всегда хочется делать на локальной машине (мавеном ведь можно собирать не только ява приложения). И вот тогда локальный контейнер становится поистине спасением, не надо ничего качать и зависеть от подключения к сети/впн.

[@ludenus]

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

Из преимуществ — пересборка и запуск грозди контейнеров в нужном порядке до запуска интеграционных тестов, остановке и удаление всей этой кухни — после. Всё это — по одной команде mvn verify без внешних инструментов оркестрации и шелловских скриптов.

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