Eu estava tentando adicionar suporte para invocar docker build como docker buildx build mas temo que possa ser um pouco mais complicado do que isso
Minha intenção é adicionar esses tipos de parâmetros:
Em seguida, podemos armazenar em cache as camadas de construção do Docker de uma maneira mais eficiente. De qualquer forma, as opções --cache-to e --cache-from estão disponíveis apenas no Docker Buildx, como muitas outras opções que eu gostaria de usar
No passado, habilitei com sucesso volumes de cache para o bundler dentro de um Dockerfile, para que as alterações no Gemfile e Gemfile.lock não resultassem em um recálculo completo das dependências de tempo de compilação da imagem, mas sim compilassem a partir do cache para que apenas novas dependências foram recalculadas.
Embora isso seja obviamente uma otimização de nicho, existem outros casos de uso mais comuns que só podem ser bem tratados com buildx. O conjunto de ferramentas do buildkit está se tornando bastante padrão agora IMHO. Eu adoraria se fosse possível invocar a compilação Kuby de uma maneira que usa buildx!
Eu poderia tentar implementar isso novamente mais tarde, pode ser mais fácil agora que o 0.15.0 foi lançado solidamente. Enquanto isso, há um exemplo de funcionamento do GitHub Actions que é WIP, mas atualmente parece muito bom em: https://github.com/kingdonb/kuby_test
Com o cache configurado corretamente neste último local e algumas outras alterações, acho que isso está quase pronto para marcar e criar um exemplo para contribuição de volta ao kuby-core ou para morar em algum lugar no projeto getkuby 👍
kingdonb
Todos 6 comentários
Ei!
É possível usar buildx agora, se você definir como um construtor padrão .
Aqui está um exemplo de ação do Github que usa buildx e seus recursos de cache: https://github.com/anycable/anycable_rails_demo/pull/25/files#diff -28802fbf11c83a2eee09623fb192785e7ca92a3f40602a517c011b947a1822d3R28-R44
Veja também https://evilmartians.com/chronicles/kubing-rails-stressless-kubernetes-deployments-with-kuby#deploying -continuously-with-kuby-and-github-actions
palkan
em 14 dez. 2021
Eu estava apenas procurando por algo como o sinalizador --only , pois estava tendo problemas para configurar o cache! Tive a ideia de que precisava separar os escopos para cada tipo de compilação, como vejo que você fez aqui.
Muito obrigado pelas referências úteis 👍 Estou acompanhando agora para ver se eles me fazem cruzar a linha!
Definitivamente, também estava faltando o recurso construtor padrão de setup-buildx-action ( install: true )
Parece estar funcionando agora! Acabei de ver a criação de uma imagem de aplicativo concluída em menos de 10 segundos. Existem outros problemas que estou tendo agora, possivelmente uma regressão que encontrei onde o RAILS_MASTER_KEY não está sendo exportado corretamente, mas vou ler a fonte para descobrir agora.
Se eu usar o install: true como neste commit, então o método build de lib/kuby/docker/cli.rb invoca buildx , e eu posso passar construções buildx como --cache-to após o -- para colocá-los no array *docker-args 👍 para que isso possa ser fechado, exceto que pode ser bom para o kuby-core documentar como ele pode ser usado com buildx, não é estritamente problema do kuby
kingdonb
em 14 dez. 2021
Com o exemplo em:
https://github.com/kingdonb/kuby_test/commit/d74bf51e04253359b0d54aae7ddd6723ea6fd41d#diff -e2ad06bfd6b3aefc2d5f4fe8f60e0015b16947abc16764adef02e4339ac07a42R17-R20
Eu posso usar buildx, então este problema pode ser fechado.
kingdonb
em 14 dez. 2021
Isso é muito legal, obrigado por descobrir as coisas do buildx! Fiquei com a impressão de que você poderia definir uma variável de ambiente e seria Just Work™, é isso que a ação docker/setup-buildx-action@v1 está fazendo? Parece que o buildx vem com o Docker Desktop e versões mais recentes instaladas por meio de pacotes deb/rpm, então eu me pergunto se o Kuby poderia simplesmente usá-lo como padrão. Se for configurável via env var, talvez invocar docker buildx build não seja necessário? Talvez Kuby possa detectá-lo e voltar ao normal docker build ?
camertron
em 14 dez. 2021
Sim, é possível (e é isso que install: true no GitHub Action faz): https://docs.docker.com/buildx/working-with-buildx/#set -buildx-as-the-default- construtor
palkan
em 14 dez. 2021
Tudo bem, se docker build for apenas um alias para docker buildx , não vejo necessidade de Kuby fazer nada de especial. Deve caber ao usuário configurar o construtor que deseja.
camertron
em 15 dez. 2021
Questões relacionadas
hovancik
·
5Comentários
traels
·
13Comentários
gcerquant
·
3Comentários
indirect
·
3Comentários
kalkin
·
3Comentários
Comentários muito úteis
Tudo bem, se
docker buildfor apenas um alias paradocker buildx, não vejo necessidade de Kuby fazer nada de especial. Deve caber ao usuário configurar o construtor que deseja.