Você já se cansa de brincar com um Dockerfile? As imagens DockerFiles e Docker são uma ótima maneira de empacotar seu aplicativo para implantações reutilizáveis e de contêiner. No entanto, escrever e manter um Dockerfile nem sempre é intuitivo, e leva um tempo que, de outra forma, poderia ser usado para adicionar recursos ao seu aplicativo. Digite o Cloud Native BuildPacks. O BuildPacks existe para reunir tudo o que seu aplicativo precisa para executar e colocá -lo em uma imagem de iniciativa de contêiner aberta (OCI) – não é necessário o DockerFile.
Para todos os desenvolvedores por aí que precisam de um processo de construção de contêineres fáceis de usar e economizará tempo e dores de cabeça, o Cloud Native BuildPacks pode ser a solução que está procurando. Interessado? Eu vou te contar mais.
O que são o Cloud Native Buildpacks?
Em termos gerais, a Buildpack pega o código do aplicativo e o torna executável por meio de um processo de construção. Então, o Cloud Native BuildPacks pega seu código -fonte de aplicativo e o transforma em imagens OCI reprodutíveis e executáveis, implementando seus requisitos para segurança de imagem, otimização de desempenho e ordem de construção de contêineres. É como ter o Dockerfile exato de que você precisa – só você não precisa escrever um.
Enquanto a maioria dos desenvolvedores pode escrever um Dockerfile, poucos são especialistas em Docker ou infraestrutura. Muitos aplicativos possuemfiles de dockerfiles que são pareados a partir de trechos de código encontrados na web-geralmente um mash-up de copilot, transbordamento de pilha e chatgpt. Os erros do Dockerfile podem levar a aplicativos inseguros e com desempenho ruim.
Buildpacks nativos em nuvem Assuma esse ônus, aplicando automaticamente as melhores práticas para cada idioma ou estrutura. UM construtor pode então utilizar qualquer número de Buildpacksdetectando automaticamente quais BuildPacks são necessários e aplicando -os para criar um aplicativo. Aqui estão os Buildpacks que o Builder da Heroku atualmente suporta:
$ pack builder inspect heroku/builder:24
Inspecting builder: heroku/builder:24
REMOTE:
Description: Ubuntu 24.04 AMD64+ARM64 base image with buildpacks for .NET, Go, Java, Node.js, PHP, Python, Ruby & Scala.
...
Buildpacks:
ID NAME VERSION
heroku/deb-packages Heroku .deb Packages 0.0.3
heroku/dotnet Heroku .NET 0.1.10
heroku/go Heroku Go 0.5.2
heroku/gradle Heroku Gradle 6.0.4
heroku/java Heroku Java 6.0.4
heroku/jvm Heroku OpenJDK 6.0.4
heroku/maven Heroku Maven 6.0.4
heroku/nodejs Heroku Node.js 3.4.5
heroku/nodejs-corepack Heroku Node.js Corepack 3.4.5
heroku/nodejs-engine Heroku Node.js Engine 3.4.5
heroku/nodejs-npm-engine Heroku Node.js npm Engine 3.4.5
heroku/nodejs-npm-install Heroku Node.js npm Install 3.4.5
heroku/nodejs-pnpm-engine Heroku Node.js pnpm Engine 3.4.5
heroku/nodejs-pnpm-install Heroku Node.js pnpm install 3.4.5
heroku/nodejs-yarn Heroku Node.js Yarn 3.4.5
heroku/php Heroku PHP 0.2.0
heroku/procfile Heroku Procfile 4.0.0
heroku/python Heroku Python 0.23.0
heroku/ruby Heroku Ruby 5.0.1
heroku/sbt Heroku sbt 6.0.4
heroku/scala Heroku Scala 6.0.4
Outros construtores, como os do Paketo ou do Google Cloud, também trazem uma variedade de BuildPacks. Em suma, o ecossistema de BuildPacks nativo da nuvem está crescendo e amadurecendo, o que é emocionante para os desenvolvedores!
Para aqueles que estão familiarizados com Heroku, você já está gostando do Buildpack experiência. Com git push heroku mainvocê conseguiu implantar diretamente para a Heroku, sem o DockerFile necessário. O BuildPacks nativo da nuvem se baseia na experiência do Heroku Buildpack, pegando o que antes era uma implementação específica do fornecedor e transformando-o em um padrão CNCF que é utilizável em qualquer plataforma em nuvem.
Resumidamente, Buildpacks nativos em nuvem Permitir que os desenvolvedores:
- Implantar aplicativos mais facilmente do que nunca
- … De maneira baseada em padrão sem bloqueio
- … Enquanto aplica as melhores práticas de contêiner
- … E sem tornar os desenvolvedores mexer com o Dockerfiles.
Casos de uso
Parece ótimo, certo? Com todos esses benefícios, vejamos alguns casos específicos em que você pode se beneficiar do uso de BuildPacks nativos em nuvem.
Qualquer lugar onde você normalmente precisaria de um DockerFile é uma oportunidade de usar um BuildPack. Exemplos incluem:
- Um aplicativo da web node.js
- Um microsserviço python
- Um aplicativo heterogêneo que usa vários idiomas ou estruturas
- Construindo aplicativos para implantação em plataformas em nuvem como AWS, Azure e Heroku
Uma coisa a observar é a seguinte: Enquanto Buildpacks são declarativoDockerfiles são processual. Com um BuildPack, você simplesmente declara que deseja um determinado aplicativo construído com um determinado construtor ou BuildPack. Por outro lado, um Dockerfile exige que você defina os comandos e a ordem em que esses comandos são executados para criar seu aplicativo. Como tal, o BuildPacks atualmente não oferece o nível de configuração disponível dentro de um Dockerfile, para que possa não atender às necessidades de alguns casos de uso mais avançados.
Dito isto, não há bloqueio de fornecedores com o Cloud Native Buildpacks. Eles simplesmente constroem uma imagem OCI. Precisa de mais personalização e opções do que o disponível no BuildPack? Basta substituir o construtor em seu pipeline de construção pelo seu Dockerfile e uma construção de imagem OCI padrão, e você está pronto.
Um simples passo a passo
Vamos fazer um passo rápido de como usar o Cloud Native BuildPacks.
Para começar com o BuildPacks como desenvolvedor de aplicativos, seu primeiro passo deve ser instalar a ferramenta Pack CLI. Esta ferramenta permite criar um aplicativo com o BuildPacks. Siga as instruções de instalação para o seu sistema operacional.
Além disso, se você ainda não o possui, precisará de um daemon do Docker para o construtor criar seu aplicativo e para executar sua imagem. Com essas duas ferramentas instaladas, você está pronto para começar.
Construa um aplicativo de amostra
Com acesso ao pack Ferramenta, você está pronto para experimentá -lo construindo um aplicativo de amostra. Estarei executando isso dentro de um aplicativo Next.js. Precisa de um aplicativo de amostra para testar o BuildPack? Aqui está um diretório completo de aplicativos de amostra Next.js. Você também pode experimentar qualquer aplicativo que tiver em mãos.
Depois de ter seu aplicativo pronto, comece vendo o que o construtor a ferramenta de pacote sugere. No seu shell, navegue até o diretório do aplicativo e execute este comando:
$ pack builder suggest
Na minha instalação do Ubuntu, para o meu próximo.js aplicativo, o pack A ferramenta sugere os seguintes construtores:
Vamos tentar o Heroku Buildpack sugerido (heroku/builder:24). Para usar este, execute o seguinte comando:
$ pack build my-app --builder heroku/builder:24
O tempo de construção varia de acordo com o tamanho do seu aplicativo; Para mim, a construção do aplicativo levou 30 segundos. Com isso, minha imagem estava pronta para ir. Podemos executar a imagem com o seguinte:
$ docker run -p 3000:3000 my-app
O resultado é assim:
E é isso! Construímos com sucesso uma imagem OCI do nosso Aplicativo Next.js –sem usando um Dockerfile.
Configurações adicionais
E se você precisar configurar algo dentro do Buildpack? Para isso, você referenciaria os BuildPack (s) que foram selecionados pelo seu construtor. Por exemplo, para o meu aplicativo Next.js, posso ver nos logs que o construtor selecionou dois BuildPacks: Nodejs-Engine e Nodejs-Yarn.
Digamos que eu queira especificar a versão de fios usada pelo BuildPack. Primeiro, eu iria ao Nodejs-Yarn Buildpack Readme, onde vejo que posso especificar a versão do fio no meu package.json Arquivo com um packageManager chave. Eu modificaria meu arquivo para ficar assim:
{
"packageManager": "[email protected]"
}
A partir daí, tudo que eu precisaria fazer é correr pack build my-app --builder heroku/builder:24 de novo.
Conclusão
O Cloud Native BuildPacks é uma nova maneira emocionante de criar imagens de contêineres para nossos aplicativos. Ao remover a necessidade de um Dockerfile, eles o tornam mais rápido do que nunca para obter nosso aplicativo embalado e implantado. Além disso, à medida que eles criam imagens padrão de contêineres, não há bloqueio de fornecedor.
O Cloud Native BuildPacks está em visualização em muitas plataformas, o que significa que o conjunto de recursos é leve, mas rápido. A Heroku, que de origem aberta de seus nativos de nuvem, também os está trazendo para sua plataforma de próxima geração. Estou ansioso para ver como o Cloud Native BuildPacks permite a implantação de aplicativos rápida e segura em toda a comunidade da plataforma em nuvem.
