Como implantar automaticamente novas imagens do Docker do Dockerhub para o Kubernetes?

Como implantar automaticamente novas imagens do Docker do Dockerhub para o Kubernetes?

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: Deploymentmanifesto é 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: Deploymentmanifesto é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: Deploymentmanifesto 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: Deploymentmanifesto, 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: Deploymentmanifesto com o novo nome da tag
  • Mantenha o kind: Deploymentmanifesto (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:

  1. Git push de mudança de código para um repositório de código
  2. AGatilho Tektonrecebe um evento do sistema Git e inicia um novo arquivo PipelineRun.
  3. 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: Deploymentmanifesto com o novo resumo de imagem e git-push para um repositório com os manifestos.
  4. 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

informação relacionada