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.