Docker no currículo costuma aparecer ao lado de Kubernetes, como se os dois fossem a mesma experiência com nomes diferentes. Não são. Um Docker Compose que sobe banco e API na sua máquina e um cluster Kubernetes que atende o tráfego de produção descrevem trabalhos diferentes, e a vaga quer saber qual deles você fez. Este guia mostra como descrever o que foi empacotado, em que ambiente ele rodou, quem dependia dele e que resultado operacional a mudança trouxe, sem transformar um ambiente de desenvolvimento em experiência de produção.

Empacotar a aplicação em imagem e decidir onde as cópias rodam são trabalhos diferentes

Escreva Docker quando você criou o Dockerfile, montou a imagem e definiu o ambiente de execução. Escreva Kubernetes quando você configurou o cluster que decide quantas cópias rodam, onde rodam e o que acontece quando uma delas cai. Um currículo que junta as duas palavras sem separar o trabalho deixa o recrutador técnico sem saber qual delas você operou.

Antes: Experiência com Docker e Kubernetes em projetos de software.

Depois: Escrevi os Dockerfiles dos três serviços da aplicação de estoque e o ambiente de desenvolvimento em Docker Compose, o que reduziu a subida do ambiente local de uma tarde para cerca de dez minutos.

Se você é desenvolvedor de back-end, o contêiner costuma aparecer junto da linguagem e do banco, e o guia de currículo de desenvolvedor back-end mostra como escrever esse conjunto. Se o seu uso parou no Compose, a linha correta é Docker Compose, e ela já é útil. Kubernetes exige um cluster de verdade, mesmo que pequeno. Um cluster de estudo na sua máquina não entra como experiência de orquestração. A regra é escrever a ferramenta que você operou, e só essa.

Em qual ambiente a imagem rodou: máquina, homologação ou produção?

O ambiente é a primeira pergunta de qualquer conversa técnica sobre contêiner, e a resposta muda o peso da linha. Coloque o ambiente logo depois da ferramenta, usando uma destas três categorias:

  • Máquina de desenvolvimento.O contêiner roda no notebook da equipe, com banco e fila subindo juntos. Vale citar quando a mudança acabou com o “na minha máquina funciona”, que é um problema real e comum.
  • Homologação. A imagem roda num servidor ou cluster que espelha a produção, e os testes de integração rodam contra ele antes de cada entrega. Cite essa etapa quando ela pegou erros que a máquina de desenvolvimento não pegava.
  • Produção. A imagem atende tráfego real, com monitoramento e alguém de plantão quando algo cai. É o ambiente que mais pesa na linha, e também o que mais exige que você descreva o que aconteceu quando uma falha chegou aos usuários.

Se você só conhece a máquina de desenvolvimento, não escreva produção. Uma conta de teste num provedor de nuvem também não é produção, porque ninguém depende dela. Diga o que ela é: um ambiente de estudo, com a imagem publicada num registro e um deploy feito à mão. A palavra produção fica para quando ela existir, e um currículo de DevOps que quer essa palavra pode seguir o caminho do exemplo de engenheiro DevOps para ver onde ela costuma aparecer.

Quem dependia do contêiner: escreva o efeito sobre o time, não a imagem

Containerizar sozinho é uma tarefa técnica. O que faz a linha ganhar valor é o efeito sobre quem usava o serviço: a equipe que deixou de depender de uma máquina específica, o time de suporte que passou a ter um ambiente de teste idêntico ao de produção, ou o colega que parou de perder a manhã com configuração. Uma boa frase diz o que mudou para essas pessoas.

Antes: Containerização da aplicação de faturamento com Docker.

Depois: Containerizei o serviço de faturamento usado pela equipe financeira, com a mesma imagem em homologação e em produção, o que acabou com as diferenças de configuração que travavam o fechamento mensal.

A segunda versão diz qual problema deixou de existir. Se você não lembra de um problema assim, a pergunta a fazer é mais simples: quem reclamava antes da mudança, e do quê?

Para montar a frase com verbo, ambiente e efeito, o método do guia sobre como descrever experiência com resultados e números serve para qualquer ferramenta, incluindo o Docker.

Orquestração se prova pelo que você configurou no cluster, não pelos nomes dos recursos

Quase todo currículo que cita Kubernetes lista Deployment, Service, Ingress e ConfigMap, e a lista não diz o que foi feito com eles. Escreva as configurações que você definiu e o comportamento que elas garantiram. O recrutador técnico entende escalonamento, reinício automático e atualização sem parada, e confere cada um deles nas perguntas da entrevista.

Antes: Kubernetes, Deployment, Service, ConfigMap e Secrets.

Depois: Configurei o escalonamento automático do serviço de pagamentos entre duas e oito cópias, conforme o uso de CPU, e movi as credenciais de integração para Secrets, tirando-as do repositório.

O mesmo cuidado vale para o que não existe. Escalonamento automático, reinício de contêiner que caiu e atualização gradual são recursos que você conhece se configurou ou diagnosticou um deles. Se só leu a documentação, escreva isso como estudo, em outra linha, e não como experiência.

O resultado operacional mede a operação, e o custo de servidor entra nele

Tempo de subida do ambiente, tempo de deploy, número de falhas em produção e custo mensal de servidor são medidas que a operação já tem, mesmo em empresas pequenas. Se você não tem um número exato, descreva a direção da mudança e o que a sustentou. Quando não há número nenhum, o guia de conquistas no currículo para quem não tem números mostra como descrever o efeito sem inventar cifra.

Antes: Melhoria no processo de deploy com containers.

Depois: Migrei a publicação de quatro serviços para contêineres num cluster, e o tempo médio de deploy caiu de quase uma hora para menos de dez minutos, com volta à versão anterior pelo histórico quando uma entrega falhava.

Se o Docker é de estudo, o caminho para uma linha honesta é publicar um projeto

Curso de Docker concluído mostra matrícula, não operação. Para ter o que escrever, monte uma aplicação pequena com Dockerfile e Compose, publique a imagem num registro e leve a aplicação a um lugar onde alguém consiga acessá-la, mesmo que seja uma máquina virtual barata. Depois descreva essa sequência: onde ela roda, como é atualizada e o que quebrou na primeira tentativa.

Não escreva que operou um cluster Kubernetes se o projeto ficou no Compose. Quem monta esse projeto pode escrever Docker, com o ambiente em que publicou, e estudar Kubernetes num cluster pequeno antes de colocar a palavra no currículo. O guia de currículo de DevOps mostra como transformar esse tipo de projeto em vocabulário de vaga.

O que fazer agora com o seu currículo

Em cada linha que cita Docker ou Kubernetes, procure três coisas: o ambiente, o que você configurou e o que mudou para alguém. Se uma delas falta, reescreva a linha antes de mexer em qualquer outra parte do texto. A regra que resume este guia é escrever a ferramenta junto do ambiente onde ela rodou, e não escrever um ambiente que você não operou.

Quem fica só com a palavra perde a linha na primeira pergunta sobre o ambiente, porque é ela que o entrevistador faz primeiro. Para conferir se os termos da vaga já aparecem no seu texto, cole a descrição da vaga na análise ATS gratuita. Ela não pede cadastro e mostra quais termos da vaga o seu currículo já tem e quais faltam. Se a vaga for de desenvolvimento, confira também os termos listados em palavras-chave para desenvolvedor full stack.

Perguntas frequentes

Docker no currículo é o mesmo que Kubernetes?

Não. Docker empacota uma aplicação numa imagem e a executa como contêiner. Kubernetes orquestra muitos contêineres num cluster, decidindo quantas cópias rodam, reiniciando as que caem e atualizando a versão sem parar o serviço. Escreva as duas palavras quando você usou as duas, cada uma com o trabalho que fez. Se você só empacotou aplicações, Docker basta, e Kubernetes fica de fora.

Usar só Docker Compose no currículo conta como experiência com Docker?

Conta, desde que você tenha escrito os Dockerfiles e o arquivo do Compose, e não só rodado um comando copiado de um tutorial. Descreva o que o ambiente tinha, como banco e fila, e onde ele era usado, como na máquina da equipe ou em homologação. Compose não é orquestração de produção, então não o apresente como Kubernetes.

Como descrever Docker no currículo sem ter trabalhado com produção?

Publique um projeto pequeno: uma aplicação com Dockerfile, banco no Compose, imagem enviada a um registro e uma execução num ambiente que alguém consiga acessar, como uma máquina virtual barata. Descreva essa sequência com o ambiente de destino e o que deu errado na primeira tentativa. Um projeto assim é honesto e mostra que você sabe levar a imagem até um lugar onde ela roda.

Docker vai na seção de habilidades ou na de experiência?

Nas duas, com funções diferentes. A seção de habilidades guarda o nome da ferramenta, para a palavra aparecer no texto. A experiência guarda o uso, com verbo, ambiente e efeito, para o recrutador entender como você trabalhou com ela. Se Docker aparece só na lista de habilidades, a palavra existe, mas nada no texto a sustenta.

Preciso citar a versão do Kubernetes ou do Docker no currículo?

Só quando você souber a versão do ambiente em que trabalhou, porque algumas vagas pedem uma versão mínima. Não escreva um número que você não confirma. Se não lembra a versão, escreva o nome da ferramenta e o tipo de cluster, como um cluster gerenciado na nuvem, e deixe a versão para a entrevista.

Quer otimizar seu currículo para uma vaga específica?

O AjustaCV reescreve seu currículo para passar nos filtros ATS da vaga que você escolher. Pronto em minutos.

AJUSTAR MEU CURRÍCULO — R$9,90