Questão de Engenharia de Software — Outros tópicos de Engenharia de Software — CESPE / CEBRASPE 2023

Spring Boot e camadas de imagem Docker

Gabarito: Certo (C). O Spring Boot, a partir da versão 2.3, suporta a criação de imagens Docker otimizadas por meio de camadas, tanto para arquivos JAR quanto WAR, e a afirmação descreve corretamente o princípio: o código do aplicativo, que muda com mais frequência entre compilações, é isolado em uma camada separada das dependências, que mudam com menos frequência. Isso permite que o Docker reutilize camadas em cache, acelerando builds e reduzindo o tamanho das imagens.

O que a questão aborda é um recurso específico do ecossistema Spring Boot, não um conceito genérico de engenharia de software. Para entender, precisamos primeiro compreender como o Docker constrói imagens. Uma imagem Docker é composta por uma série de camadas (layers) empilhadas, cada uma representando uma instrução do Dockerfile (como COPY, RUN, etc.). Quando uma camada é alterada, todas as camadas subsequentes precisam ser reconstruídas, mas as camadas anteriores, se inalteradas, podem ser reaproveitadas do cache. Portanto, a ordem e a granularidade das camadas têm um impacto direto na eficiência do processo de build e no tamanho final da imagem.

Tradicionalmente, ao empacotar uma aplicação Spring Boot em um único arquivo JAR executável (o famoso "fat jar"), todo o conteúdo — classes da aplicação, bibliotecas de terceiros, recursos estáticos — era colocado em uma única camada. Isso significava que qualquer alteração no código, por menor que fosse, invalidava o cache de toda a camada, forçando o Docker a reenviar e reconstruir tudo, mesmo que as dependências externas não tivessem mudado. Para resolver esse problema, o Spring Boot introduziu o suporte a "layers" (camadas) no empacotamento. A ideia central é separar o conteúdo do JAR em camadas lógicas, com base na probabilidade de alteração. As dependências (bibliotecas externas) raramente mudam entre builds, enquanto o código da aplicação muda com frequência. Ao isolar o código em uma camada própria, o Docker pode reutilizar as camadas de dependências do cache, tornando o processo de build muito mais rápido e eficiente.

Essa funcionalidade é habilitada por padrão no Spring Boot 2.3 e versões posteriores. O plugin Maven (spring-boot-maven-plugin) e o plugin Gradle (spring-boot-gradle-plugin) geram, por padrão, um arquivo layers.idx dentro do JAR, que é o "índice de camada" mencionado na questão. Esse arquivo define a ordem e o conteúdo de cada camada. As camadas padrão são: dependencies (dependências de terceiros), spring-boot-loader (classes do carregador do Spring Boot), snapshot-dependencies (dependências SNAPSHOT), application (classes e recursos da aplicação). O suporte a camadas também foi estendido para arquivos WAR, permitindo que aplicações web empacotadas dessa forma também se beneficiem da otimização. A questão, portanto, descreve com precisão o mecanismo: a adição de um arquivo de índice de camada ao JAR e o suporte a camadas para WAR, com o objetivo de separar o código com base na probabilidade de alteração, isolando o código da aplicação em uma camada separada.

A pegadinha aqui é sutil: o candidato pode achar que a afirmação é falsa porque o suporte a camadas é uma funcionalidade relativamente nova e específica, ou pode confundir com outras técnicas de otimização de imagens, como multi-stage builds. No entanto, a descrição é tecnicamente precisa e corresponde exatamente ao comportamento do Spring Boot. A banca não está testando um conceito abstrato, mas sim o conhecimento de uma funcionalidade concreta e documentada de uma tecnologia popular. O candidato que conhece o recurso de "layers" do Spring Boot reconhecerá a afirmação como correta.

Guarde o critério decisivo: a questão testa o conhecimento do recurso de camadas (layers) do Spring Boot para otimização de imagens Docker, que se baseia na separação do código por probabilidade de alteração. É isso que separa o certo do errado.

Item — ✅ CERTO ⟵ GABARITO

A afirmação está correta. O Spring Boot, desde a versão 2.3, suporta a criação de imagens Docker otimizadas por camadas. O mecanismo funciona da seguinte forma:

1. Arquivo de índice de camada (layers.idx): O plugin de build (Maven ou Gradle) gera um arquivo layers.idx dentro do JAR (ou WAR) que descreve a ordem e o conteúdo de cada camada. Esse é o "arquivo de índice de camada" mencionado na questão.

2. Separação por probabilidade de alteração: O conteúdo é dividido em camadas como dependencies, spring-boot-loader, snapshot-dependencies e application. As dependências mudam raramente, enquanto o código da aplicação muda com frequência.

3. Suporte a WAR: O recurso de camadas também é suportado para arquivos WAR, não apenas para JARs.

4. Isolamento do código: O código da aplicação é isolado em uma camada separada, permitindo que o Docker reutilize as camadas de dependências do cache quando apenas o código é alterado.

A lógica por trás disso é exatamente a descrita: como é mais provável que o código do aplicativo mude entre as compilações, isolá-lo em uma camada separada maximiza o reaproveitamento do cache do Docker, acelerando o build e reduzindo o tráfego de rede ao enviar a imagem para um registro.

Gabarito: Certo (C).