Use um Dockerfile para compilar o código-fonte em uma imagem de container e, em seguida, distribua e implante essa imagem. Projetos Java são mais complexos de containerizar do que projetos Golang ou Python e geralmente apresentam builds mais lentos. Empresas normalmente dependem de repositórios de dependências autogerenciados, como o Maven, e os desenvolvedores muitas vezes desconhecem o mecanismo de cache do Dockerfile. Este tópico aborda um cenário típico: um repositório de código GitLab autogerenciado e um repositório Maven autogerenciado na cloud. Ele demonstra como compilar um projeto Java com um Dockerfile e acelerar cada build. Também mostra como automatizar a criação de imagens com o service de build do Container Registry Enterprise Edition (ACR EE).
Pré-requisitos
Crie um repositório de código GitLab.
Crie um repositório Maven.
Crie uma instância do Container Registry Enterprise Edition. Para mais informações, consulte Create an Enterprise Edition instance.
Visão geral do projeto
Este tópico demonstra um processo de build com dois projetos Java interdependentes. Os projetos são:
-
Provider: fornece um service chamável.
Módulo Core: disponibiliza interfaces públicas.
Módulo Service: implementa o service.
-
Consumer: chama o service Provider.
-
Módulo Service: depende do módulo Core no projeto Provider. Exemplo de código:
. ├── consumer │ ├── Dockerfile │ ├── consumer.iml │ ├── pom.xml │ └── service │ ├── pom.xml │ ├── src │ └── target └── provider ├── Dockerfile ├── core │ ├── pom.xml │ ├── src │ └── target ├── pom.xml ├── provider.iml └── service ├── pom.xml ├── src └── target
-
Artefatos de build:
Imagem da aplicação produtora criada a partir do projeto Provider.
Imagem da aplicação consumidora criada a partir do projeto Consumer.
Etapa 1: Fazer upload das dependências públicas
Antes de criar qualquer imagem, faça upload dos pacotes de dependências públicas referenciados pelo projeto para o repositório Maven autogerenciado. No projeto Provider, execute o seguinte comando de upload no diretório do Provider:
mvn clean install org.apache.maven.plugins:maven-deploy-plugin:2.8:deploy -DskipTestsEtapa 2: Criar uma imagem base Maven personalizada
Para acessar o repositório Maven autogerenciado no ambiente de build containerizado, adicione a configuração do repositório Maven à imagem base. Crie uma imagem base Maven pública personalizada para sua empresa com base na imagem oficial do Maven. Assim, os projetos poderão referenciar essa imagem base para acessar o repositório Maven.
-
Salve o conteúdo abaixo como um Dockerfile no mesmo diretório do arquivo settings.xml do repositório Maven.
FROM maven:3.8-openjdk-8 # Use a Maven image that matches the project. This example uses Maven 3.8. ADD settings.xml /root/.m2/ # Add the self-managed Maven repository configuration to the specified path. -
Execute os comandos a seguir para criar a imagem e enviá-la ao repositório de imagens remoto.
ls Dockerfile settings.xml docker build -t demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8 -f Dockerfile . Sending build context to Docker daemon 7.68kB Step 1/2 : FROM maven:3.8-openjdk-8 ---> a3f42bfde036 Step 2/2 : ADD settings.xml /root/.m2/ ---> db0d5a5192e3 Successfully built db0d5a5192e3 Successfully tagged demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8 docker push demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8
Etapa 3: Criar a imagem da aplicação Consumer (ignorar para o projeto Provider)
Execute o comando a seguir. Envie todas as imagens base necessárias durante o processo de build para um repositório de imagens da Alibaba Cloud.
FROM demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8 AS builder
# add pom.xml and source code
ADD ./pom.xml pom.xml
ADD ./service service/
# package jar
RUN mvn clean package
# Second stage: minimal runtime environment
From demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/openjdk:8-jre-alpine
# copy jar from the first stage
COPY --from=builder service/target/service-1.0-SNAPSHOT.jar service-1.0-SNAPSHOT.jar
EXPOSE 8080
CMD ["java", "-jar", "service-1.0-SNAPSHOT.jar"]Etapa 4: Otimizar a velocidade do build
Na Etapa 3: Criar a imagem da aplicação Consumer (ignorar para o projeto Provider), você criou uma imagem. No entanto, ao modificar o código e recompilar, o processo de build fica lento porque baixe os pacotes JAR novamente em vez de usar o cache. O docker invalida o cache de uma camada quando seu conteúdo muda. Após a modificação do código-fonte, o hash dos arquivos na instrução ADD é alterado. Essa mudança força a reexecução da instrução RUN, ignorando o cache do build anterior. Para mais informações, consulte Melhores práticas de Dockerfile.
Para otimizar a velocidade do build, armazene em cache e reutilize as dependências do Maven:
Copie o arquivo pom.xml do projeto para o container para baixar as dependências. Se o arquivo pom.xml não sofrer alterações, os builds subsequentes usarão o cache.
Copie o código-fonte do projeto e compile-o.
O Dockerfile a seguir é uma versão aprimorada. O primeiro build leva 43 segundos. Se você alterar apenas o código-fonte, os builds subsequentes levarão 7 segundos.
FROM demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/maven-base:3.8-openjdk-8 AS builder
# To resolve dependencies in a safe way (no re-download when the source code changes)
ADD ./pom.xml pom.xml
ADD ./service/pom.xml service/pom.xml
RUN mvn install
ADD ./service service/
# package jar
RUN mvn clean package
# Second stage: minimal runtime environment
From demo-registry-vpc.cn-beijing.cr.aliyuncs.com/demo/openjdk:8-jre-alpine
# copy jar from the first stage
COPY --from=builder service/target/service-1.0-SNAPSHOT.jar service-1.0-SNAPSHOT.jar
EXPOSE 8080
CMD ["java", "-jar", "service-1.0-SNAPSHOT.jar"]Etapa 5: Automatizar o processo de build com o Container Registry Enterprise Edition
O ACR EE oferece services de build de nível empresarial e é recomendado para clientes corporativos. Para mais informações, consulte Build images using an Enterprise Edition instanceBuild images using an Enterprise Edition instance.
As seções a seguir descrevem algumas melhores práticas.
-
Use o modo de build VPC
Para instâncias GitLab autogerenciadas na cloud, use o modo de build VPC seguro para criar imagens. Isso evita a exposição de services à internet pública. Para mais informações, consulte Build container images in secure VPC modeBuild container images in secure VPC mode.
-
Use o recurso de versão de imagem imutável
Ative o recurso de versão de imagem imutável no repositório para evitar que versões em produção sejam sobrescritas. Na página Create Image Repository, na etapa Repository Information, defina Image Version como Immutable marcando a caixa de seleção. Após marcar essa opção, nenhuma versão de imagem no repositório, exceto
latest, poderá ser sobrescrita. Isso mantém as versões das imagens de container consistentes. -
Crie uma regra de build baseada em IDs de commit
Cada build gera duas versões de imagem. Uma versão usa o ID do commit de código, permitindo mapear uma versão de imagem para uma versão de código. A outra versão usa
latestpara indicar a versão mais recente. Na caixa de diálogo Modify Building Rule, na etapa Image Version, configure as versões de imagem Commit ID e latest.Faça o commit do código para acionar um build. O exemplo a seguir mostra dois builds acionados automaticamente por dois commits de código. Cada build gera duas imagens; o segundo build é mais rápido por aproveitar o cache. Na página de configurações de build, a opção Automatically Build Images upon Code Change está ativada. Nas configurações da regra de build, Branch está definido como
branches:master, o diretório de contexto de build é/e o nome do Dockerfile éDockerfile. A versão da imagem inclui duas tags, Configuration 1 e Configuration 2, correspondentes à versão do ID do commit e à versão mais recente. O log de build indica que ambos os builds foram concluídos com sucesso, levando 85 segundos e 106 segundos, respectivamente.