
Estou procurando uma solução de CD para meu cluster k8s. Agora, depois de enviar um commit com dev-*
tag, o dockerhub cria uma nova imagem marcada como dev-latest
. Aqui está minha configuração de implantação:
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-image-backend-local-deployment
labels:
app: my-image
type: web
spec:
replicas: 2
minReadySeconds: 15
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 25%
maxSurge: 1
selector:
matchLabels:
app: my-image
template:
metadata:
labels:
app: my-image
spec:
imagePullSecrets:
- name: regcred
containers:
- name: backend
image: cosmicfruit/my-image:dev-latest
imagePullPolicy: IfNotPresent
envFrom:
- secretRef:
name: my-image-backend-local-secret
ports:
- containerPort: 8000
readinessProbe:
httpGet:
path: /flvby
port: 8000
initialDelaySeconds: 10
periodSeconds: 5
- name: celery
image: cosmicfruit/my-image:dev-latest
imagePullPolicy: IfNotPresent
workingDir: /code
command: ["/code/run/celery.sh"]
envFrom:
- secretRef:
name: my-image-backend-local-secret
- name: redis
image: redis:latest
imagePullPolicy: IfNotPresent
Quero que novas imagens sejam implantadas automaticamente nos pods, mas não consigo encontrar uma solução relevante.
Atualização
Gostaria que minhas imagens fossem implantadas automaticamente após a nova imagem com dev-0.1.*
a tag (onde * é um número) ser enviada para o registro. Não quero fazer nada depois que o código for enviado e incorporado à imagem. Eu descobri alguns projetos da CD Foundation: Jenkins X, Spinnaker e Tekton e acho que alguns deles podem me ajudar a implementar minha ideia, mas seria ótimo implementá-la sem mais um animal de estimação no meu zoológico.
Responder1
Referência de imagem e manifestos
Kubernetes gerencia implantações, por exemplo, usando uma estratégia de implantação contínua sempre que seu kind: Deployment
manifesto é alterado.
Agora, depois de enviar um commit com a tag dev-*, o dockerhub cria uma nova imagem marcada como dev-latest
O principal problema com isso é que você usa omesmonome da tag para cada imagem. Isso significa que seu kind: Deployment
manifesto énãoatualizado quando sua imagem é atualizada, para que o Kubernetes não inicie uma nova implantação contínua, pois não há alterações no manifesto.
Uma boa prática é usar uma tag de imagem exclusiva sempre que você enviar uma imagem e, em seguida, atualizar o kind: Deployment
manifesto com esse novo nome de tag de imagem, para que o Kubernetes acione automaticamente uma nova implantação contínua.
Alguns registros de imagens podem ser configurados para usar "nomes de tags imutáveis", isso significa que você estáaplicadopara sempre usar um nome de tag exclusivo para cada imagem construída. Alternativamente, você pode usar oresumo completo da imagemno kind: Deployment
manifesto, para que você possa ter uma referência de imagem exclusiva, mesmo que o nome da tag seja o mesmo (Image Digest é um hash do conteúdo).
Resumindo:
- Use nomes exclusivos de tags de imagem para cada compilação
- Atualize o
kind: Deployment
manifesto com o novo nome da tag - Mantenha o
kind: Deployment
manifesto (e outro manifesto yaml) no controle de versão, por exemplo, Git - Considere usar o Image Digest completo no manifesto ao se referir à imagem
Processo e automação
Atualizar o manifesto e aplicá-lo ao cluster pode ser feito de diversas maneiras diferentes, mas é recomendado sempre armazenar o manifesto atualizado em um repositório Git após cada alteração, antes de ser aplicado ao cluster. Dessa forma, você obtém uma boa rastreabilidade sobre o que mudou e é mais fácil voltar para uma versão funcional se algo falhar.
Com as etapas necessárias descritas acima, outra prática importante é usarautomaçãopor esta. Após cada alteração no repositório Git, acione um processo automatizado para fazer o trabalho, de preferência sem nenhuma etapa manual. Historicamente, Jenkins tem sido uma ferramenta popular para isso, mas tem sua idade e não foi projetado para funcionar bem em um ambiente de contêiner. Agora recomendo usar uma ferramenta comoAções do GitHub,Google Cloud Buildou um sistema moderno dentro do cluster Kubernetes, comoOleodutos Tekton
Construir e implantar pipeline usando Tekton
Se você optar por usar o Tekton em seu cluster Kubernetes, poderá estruturar o projeto assim:
- Git push de mudança de código para um repositório de código
- AGatilho Tektonrecebe um evento do sistema Git e inicia um novo arquivo
PipelineRun
. - OOleoduto Tektoncontém etapas para git-clone, construir o código, executar testes e construir e enviar uma imagem. O resultado é um resumo ou rótulo de imagem. Então você tem uma última tarefa no pipeline que, se todas as tarefas anteriores foram bem-sucedidas, atualiza o
kind: Deployment
manifesto com o novo resumo de imagem e git-push para um repositório com os manifestos. - Um pipeline de implantação é acionado para aplicar os manifestos ao cluster (talvez usando uma estratégia de implantação de sua escolha, implantação contínua ou implantação gradual ou implantação canário)
Recomendações de livros
Kubernetes instalado e funcionando2ª edição (de 2019) - contém um novo capítulo:18. Organizando seu aplicativoque descreve como gerenciar implantações com manifestos e controle de versão.
Entrega Contínua- um livro clássico sobre como usarconstruir e implantar pipelinese automação.
Alternativas
Eu descobri alguns projetos da CD Foundation: Jenkins X, Spinnaker e Tekton e acho que alguns deles podem me ajudar a implementar minha ideia, mas seria ótimo implementá-la sem mais um animal de estimação no meu zoológico.
Implantações no Kubernetespodeser feito sem usar manifestos declarativos e, em vez disso, ser feito comcomandos imperativossem nenhuma alteração controlada por versão, mas isso érealmente desanimadopara um ambiente profissional. É importante fazer isso de forma declarativa e reproduzível, embora pipelines automatizados levem algum tempo para serem configurados.
Responder2
Finalmente descobri a ferramenta incrível “keel.sh” que faz exatamente o que espero do CD para kubernetes