fbpx
Entrypoint vs CMD – v2 – Conteinerizando o Kubectl
Publicado em: quinta-feira, 25 de mar de 2021
Categorias: Docker de A a Z

Se você precisa interagir com um cluster kubernetes, você já deve ter ouvido falar do Kubectl (o Cube Control). Hoje eu vou abordar os conceitos de Entrypoint e CMD, e vou mostrar como eu conteinerizei o Kubectl em uma imagem docker, vou explicar o porquê e vou te mostrar o repositório do github com todo esse rolê.

META

Esse post destina-se a todo e qualquer usuário de docker que queira entender Entrypoint e CMD.

Kubectl entra nessa historia como apenas como um exemplo prático.

Entendendo o Kubectl

O que é?

Kubectl é um utilitário de linha de comando. Ele serve para falar com o Kubernetes. Um dado importante sobre o que vamos ver hoje é que ele precisa de um arquivo de configuração.

O que ele precisa para rodar?

O kubectl espera que essa configuração esteja em ~/.kube/config.

Como instalar?

São poucos comandos, você pode ver o dockerfile pronto aqui.

Exemplo de uso

Aqui estão alguns exemplos de uso dele:

Exemplo 1

kubectl set image deployments/nome-deployment appname=imagem:versao -n namespacecorreto

Exemplo 2

kubectl apply -f ./file.yaml-n namespacecorreto

Temos tudo!

  • Sabemos instalar
  • Sabemos o que precisa para rodar (a configuração)
  • Sabemos como usar (quais parâmetros usar)

Isso é o suficiente para dockernizar qualquer coisa. De uma cafeteira a um disco voador.

Entrypoint e CMD

No post Dockerfiles: Entrypoint vs CMD? vimos a diferença entre os 2. E sinceramente essa coisa é tão, mas tão ridiculamente simples, que só um exemplo real para demonstrar.

Se eu quero executar kubectl set image deployments/nome-deployment appname=imagem:versao -n namespacecorreto então precisamos separar as coisas:

kubectl vai ficar como entrypoint, na minha imagem

e set image deployments/nome-deployment appname=imagem:versao -n namespacecorreto ficaria como CMD, supondo que eu quisesse executar somente esse comando, ou que esse seja o comando default.

Para o docker, não faz diferença o que é entrypoint ou command, ele sempre vai usar a soma dos 2 para inicializar o container.

Quem que deve se importar com essa escolha somos nós que estamos fazendo o design da imagem, pensando em como usá-la.

Ou seja, tecnicamente

Entrypoint [ "echo"]
CMD ["teste"]
e
Entrypoint [ "echo", "teste"]
CMD [ ]

produzem o mesmo efeito prático. A diferença é que no primeiro, durante um docker run, eu facilmente troco o valor “teste” por qualquer outra coisa de meu interesse. Já o entrypoint sequer originalmente foi projetado para ser alterado, mas hoje em dia é possível alterar sim.

A sentença do docker run é mais ou menos assim: docker run [options] imagem [cmd], ou seja tudo que está à direita do nome/versão da imagem sobrescreve o CMD que está explícito no dockerfile.

Dessa forma com a imagem produzida com o Dockerfile, conseguimos rodar comandos assim, em ambientes que não tem a instalação do kubectl.

docker run \
-v /root/.kube/config:/root/.kube/config:ro \
luizcarlosfaria/kubectl \
get pods

docker run -v /root/.kube/config:/root/.kube/config:ro luizcarlosfaria/kubectl get pods

E se você não entendeu o poder disso, agora de qualquer lugar que eu tenha o arquivo de configuração do kubectl, eu consigo produzir um comando para o rollout para uma nova versão de imagem em um deployment. Ou seja, eu consigo interagir com o kubernetes sem precisar instalar nada nos meus runners de CI/CD, isso deixa o setup mais enxuto e resiliente ao tempo. Na hora que eu precisar de uma versão diferente do kubectl, mais atual, eu vou produzir uma imagem mais recente e não preciso me preocupar com retrocompatibilidade.

O poder de executar isso aqui:

docker run \
-v $K8S_CONFIG_FILE:/root/.kube/config:ro \
 registry.oragon.io/services/kubectl:v1.0.0 \
set image deployments/hub-deployment hub=registry.oragon.io/services/hub-edge:${BRANCH_NAME:-master} -n hub

no pipeline, salva vidas!!!!

Para que containerizar o Kubectl?

Esse é um assunto que não diz respeito ao post em si. O post tem o propósito de abordar, de forma prática o CMD e o Entrypoint de uma imagem docker. Ou melhor, de uma imagem OCI.

Meu servidor de CI/CD não faz parte do cluster kubernetes, portanto não tem kubectl nele.

Para garantir a sanidade dos meus servers eu tenho algumas regrinhas básicas a seguir:

  • A primeira opção de uso de qualquer ferramenta, deve ser no mínimo containerizada.
  • Use imagens docker oficiais
  • Não sendo possível, busque por fornecedores confiáveis (linuxserver, bitnami).
  • Não sendo possível, cogite não usar a ferramenta. Busque um bom substituto.
  • Não sendo possível, crie a sua própria imagem.
  • Não sendo possível, instale direto no host.

Esse pipeline de decisão facilita muito a minha vida.

Depois que eu fiz eu pensei em chamar o projeto de Kubectl-Aleluia em homenagem ao Fabricio Veronez, mas já era tarde.

Luiz Carlos Faria

Mensagem do Autor

Espero que goste desse post. Não deixe de comentar e falar o que achou. 

Se acha que esse post pode ajudar alguém que você conheça, compartilhe!

 

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.