Construções de contêineres podem ser um grande desperdício. Cada atualização do sistema operacional, nova versão de dependência e atualização do conjunto de ferramentas resulta em grandes quantidades de energia usadas para construir e reconstruir nossas imagens de contêiner; muitas vezes desnecessariamente. Pode ser caro em escala, e é por isso que os Buildpacks Cloud Native foram projetados para executar compilações completas apenas quando uma reconstrução é realmente necessária.
Buildpacks transformam o código-fonte do aplicativo em imagens de contêiner. Eles podem ser usados com ou sem Docker para encapsular padrões comuns entre compilações, o que torna a conteinerização mais fácil e mais consistente para desenvolvedores de aplicativos. Buildpacks também fornecem mecanismos avançados de cache e patch que os tornam uma escolha ecologicamente correta para construção de contêineres. Em certos casos, os Buildpacks impedem que muitas imagens sejam reconstruídas. Essa é uma grande mudança em relação a outras tecnologias nativas da nuvem, que podem assumir que recursos de nuvem ilimitados estão disponíveis.
Sobre o impacto ambiental da nuvem nativa
Antes do surgimento do ecossistema nativo da nuvem e do uso generalizado de imagens de contêiner, implantávamos nossos aplicativos em servidores criados a partir de imagens de máquinas que eram atualizadas com pouca frequência e em uma cadência diferente da própria aplicação.
Hoje, muitas aplicações estão acopladas ao sistema operacional e seus pacotes porque utilizam um Dockerfile para definir suas imagens de contêiner. Como resultado, essas imagens frequentemente precisam de reconstruções para aplicar patches a componentes no nível do sistema operacional ou simplesmente para atualizar ferramentas que nem são usadas pelo aplicativo. Pior ainda, o mecanismo de cache de camadas imposto por Dockerfile nos obriga a reconstruir frequentemente camadas que nem precisam ser reconstruídas.
O ecossistema nativo da nuvem trouxe grande produtividade e melhorias operacionais para o desenvolvimento de software. Mas perdemos de vista o quanto algumas dessas tecnologias podem ser um desperdício. Os Buildpacks, por outro lado, foram projetados para funcionar em uma escala (ou seja, dezenas de milhões de imagens) onde o desperdício tem custos reais. É por isso que o mecanismo de rebase do Buildpacks requer recursos mínimos.
Reduzir, reutilizar, rebase
As imagens de contêiner criadas a partir de um Dockerfile exigem uma compilação completa quando uma nova atualização do sistema operacional está disponível, mesmo que seu aplicativo não precise ser recompilado ou reinstalado para funcionar com a atualização (ou seja, a atualização é compatível com ABI ). Este não é o caso ao usar Buildpacks.
Quando uma nova imagem base do sistema operacional fica disponível para uma imagem gerada por um buildpack, as camadas existentes acima do sistema operacional podem ser reutilizadas. Este processo, ilustrado abaixo, é chamado de rebase. As camadas de aplicação, com exatamente o mesmo SHA, podem ser transferidas para as novas camadas de imagem do sistema operacional.
O processo de rebase do Buildpacks, em última análise, constrói uma nova imagem de contêiner usando as camadas existentes e as novas camadas do sistema operacional, sem a necessidade de construção. Basicamente, o rebase de imagens é um processo simples. Ao inspecionar uma imagem de aplicativo, o rebase pode determinar se existe ou não uma versão mais recente da imagem base do aplicativo (localmente ou em um registro). Se existir uma versão mais recente, o rebase atualiza os metadados da camada da imagem do aplicativo para fazer referência à versão mais recente da imagem base. Esta é essencialmente uma operação que edita um arquivo JSON. Leva milissegundos e usa muito poucos recursos de computação.
O Rebase permite que desenvolvedores ou operadores de aplicativos atualizem rapidamente a imagem de um aplicativo quando sua imagem de execução for alterada. Ao usar o rebase da camada de imagem, este comando evita a necessidade de reconstruir totalmente o aplicativo.
Mas rebase não é o único mecanismo Buildpacks que é mais sustentável que Dockerfile builds. Buildpacks também podem armazenar artefatos de construção em cache para permitir compilação incremental e outras técnicas de economia de recursos. Essas camadas de cache nem sempre serão descartadas quando você precisar de uma reconstrução, como aconteceria com as compilações `Dockerfile“.
Seja tão ecológico quanto seus testes de unidade
As construções de contêineres não são os maiores infratores quando se trata do impacto ambiental do software. A eletricidade necessária para extrair bitcoin é mais do que utilizada por países inteiros , mas o crescimento do software que utiliza técnicas criptográficas trouxe uma nova consciência de como o nosso código afeta o mundo que nos rodeia. Isso é uma coisa boa.
Temos a responsabilidade de pensar em minimizar os recursos necessários ao software que produzimos. O código que escrevemos tem impacto no mundo e nossas escolhas são importantes.
Para saber mais sobre a relação entre o desenvolvimento de software de código aberto e o meio ambiente, visite o Grupo Consultivo Técnico de Sustentabilidade Ambiental (TAG).
Artigo originalmente publicado em Blog CNCF
