dockerfile maven

Dockerfile Maven

Estado: maduro

Neste momento, não estamos desenvolvendo ou aceitando novos recursos ou mesmo corrigindo bugs não críticos.

Este plugin Maven integra Maven com Docker.

Os objetivos do projeto são:

• Não faça nada sofisticado. Dockerfile s são como você cria projetos Docker; é isso que este plugin usa. Eles são obrigatórios.
• Faça com que o processo de construção do Docker se integre ao processo de construção do Maven. Se você vincular as fases padrão, ao digitar mvn package , obterá uma imagem Docker. Quando você digita mvn deploy , sua imagem é enviada.
• Faça com que os objetivos se lembrem do que você está fazendo. Você pode digitar mvn dockerfile:build e posterior mvn dockerfile:tag e posterior mvn dockerfile:push sem problemas. Isso também elimina a necessidade de algo como mvn dockerfile:build -DalsoPush ; em vez disso, você pode apenas dizer mvn dockerfile:build dockerfile:push .
• Integre-se ao reator de construção Maven. Você pode depender da imagem Docker de um projeto em outro projeto, e o Maven construirá os projetos na ordem correta. Isto é útil quando você deseja executar testes de integração envolvendo vários serviços.

Este projeto segue o Código de Conduta Aberto. Ao participar, espera-se que você honre este código.

Veja o changelog para uma lista de lançamentos

Configurar

Este plugin requer Java 7 ou posterior e Apache Maven 3 ou posterior (dockerfile-maven-plugin <=1.4.6 precisa de Maven >= 3, e para outros casos, Maven >= 3.5.2). Para executar os testes de integração ou usar o plugin na prática, é necessária uma configuração do Docker funcional.

Exemplo

Para obter mais exemplos, consulte o diretório de teste de integração.

Em particular, o teste avançado apresenta um serviço completo que consiste em dois microsserviços cuja integração é testada usando helios-testing .

Isso configura o plugin real para construir sua imagem com mvn package e enviá-la com mvn deploy . Claro que você também pode dizer mvn dockerfile:build explicitamente.

< plugin >
  < groupId >com.spotify</ groupId >
  < artifactId >dockerfile-maven-plugin</ artifactId >
  < version >${dockerfile-maven-version}</ version >
  < executions >
    < execution >
      < id >default</ id >
      < goals >
        < goal >build</ goal >
        < goal >push</ goal >
      </ goals >
    </ execution >
  </ executions >
  < configuration >
    < repository >spotify/foobar</ repository >
    < tag >${project.version}</ tag >
    < buildArgs >
      < JAR_FILE >${project.build.finalName}.jar</ JAR_FILE >
    </ buildArgs >
  </ configuration >
</ plugin >

Um Dockerfile correspondente poderia ter a seguinte aparência:

 FROM openjdk:8-jre
MAINTAINER David Flemström <[email protected]>

ENTRYPOINT ["/usr/bin/java", "-jar", "/usr/share/myservice/myservice.jar"]

# Add Maven dependencies (not shaded into the artifact; Docker-cached)
ADD target/lib           /usr/share/myservice/lib
# Add the service itself
ARG JAR_FILE
ADD target/${JAR_FILE} /usr/share/myservice/myservice.jar

Nota importante

A maneira mais Maven de fazer referência ao artefato de construção provavelmente seria usar a variável project.build.directory para fazer referência ao diretório 'target'. No entanto, isso resulta em um caminho absoluto, que não é suportado pelo comando ADD no Dockerfile. Qualquer fonte desse tipo deve estar dentro do contexto da construção do Docker e, portanto, deve ser referenciada por um path relativo . Veja #101

Não use ${project.build.directory} como forma de referenciar seu diretório de construção.

O que isso me dá?

Há muitas vantagens em usar este plugin para suas compilações.

Tempos de construção mais rápidos

Este plug-in permite que você aproveite o cache do Docker de forma mais consistente, acelerando enormemente suas compilações, permitindo armazenar em cache as dependências do Maven em sua imagem. Também incentiva a evitar o maven-shade-plugin , que também acelera bastante as compilações.

Ciclo de vida de construção consistente

Você não precisa mais dizer algo como:

 mvn package
mvn dockerfile:build
mvn verify
mvn dockerfile:push
mvn deploy

Em vez disso, basta dizer:

 mvn deploy

Com a configuração básica, isso garantirá que a imagem seja construída e enviada nos momentos corretos.

Depender de imagens Docker de outros serviços

Você pode depender das informações do Docker de outro projeto, porque este plugin anexa metadados do projeto ao construir imagens do Docker. Basta adicionar esta informação a qualquer projeto:

< dependency >
  < groupId >com.spotify</ groupId >
  < artifactId >foobar</ artifactId >
  < version >1.0-SNAPSHOT</ version >
  < type >docker-info</ type >
</ dependency >

Agora, você pode ler informações sobre a imagem Docker do projeto da qual você dependia:

 String imageName = getResource ( "META-INF/docker/com.spotify/foobar/image-name" );

Isso é ótimo para um teste de integração onde você deseja a versão mais recente da imagem Docker de outro projeto.

Observe que você precisa registrar uma extensão Maven em seu POM (ou um POM pai) para que o tipo docker-info seja suportado:

< build >
  < extensions >
    < extension >
      < groupId >com.spotify</ groupId >
      < artifactId >dockerfile-maven-extension</ artifactId >
      < version >${version}</ version >
    </ extension >
  </ extensions >
</ build >

Use outras ferramentas Docker que dependem de Dockerfiles

Seu(s) projeto(s) ficam assim:

 a/
  Dockerfile
  pom.xml
b/
  Dockerfile
  pom.xml

Agora você pode usar esses projetos com Fig ou docker-compose ou algum outro sistema que funcione com Dockerfiles. Por exemplo, um docker-compose.yml pode ser parecido com:

 service-a :
  build : a/
  ports :
  - ' 80 '

service-b :
  build : b/
  links :
  - service-a

Agora, docker-compose up e docker-compose build funcionarão conforme o esperado.

Uso

Consulte a documentação de uso.

Autenticação

Consulte os documentos de autenticação.

Liberando

Para cortar a versão do Maven:

 mvn clean [-B -Dinvoker.skip -DskipTests -Darguments='-Dinvoker.skip -DskipTests'] 
  -Dgpg.keyname=<key ID used for signing artifacts> 
  release:clean release:prepare release:perform

Usamos gren para criar Releases no Github:

 gren release