Google Cloud Deployment Manager Kubernetes, PostgresSQL e IP Estático
Criando a infra básica para um projeto pessoal

Convido você a ler Minha estrutura de projetos pessoais. Pipeline, projetos privados, badges e cloud, para entender de onde saiu esse post.
A primeira coisa que eu fiz ao montar todo o projeto foi definir o que eu iria querer de infra, obviamente teria que ser o que tem de mais novo, afinal, não vou gastar meu pouco tempo livre para menos.
De cara eu queria a última versão do Kubernetes, apenas no Google Cloud eu consegui achar, no Azure não é atualizado e a AWS cobra pelo node master e também não tem a última versão. No Google eu consegui achar a última versão e pagaria apenas as máquinas que vou usar. Sim, eu sei que não preciso da última versão e tal, mas como falei, ou é para pegar o que existe de mais novo ou eu não me sentiria motivado para continuar.
Você vai precisar de todo um aparato de ferramentas que vem junto, não é só um K8S que vai resolver e esse foi um dos motivos de eu ter estudado o Deployment Manager, outro é que eu queria aprender sobre isso e também eu não queria ficar criando um banco de dados, criando usuário, criando cluster tudo na mão. Isso iria matar o meu pouco tempo livre além de acabar com meu bom humor. Falei um pouco mais sobre a arquitetura em Visão geral de toda a solução para meus projetos pessoais.
Será necessário criar uma conta Google, criar um projeto, configurar o CLI etc. Isso é bem básico e não acho que vale a pena perder tempo nisso, vamos direto ao que importa.
Identifiquei três coisas que eu iria querer sempre criar, um cluster Kubernetes, um banco de dados Postgres e um IP Estático para apontar um domínio de teste. Funciona assim… Criamos uma receita para cada um:
Muitas coisas nessa receita são os valores padrões, você pode simplesmente remover que vai funcionar. E o porque eu não fiz isso? Porque eu queria saber como é a receita da maneira mais completa possível, afinal, estava estudando, amanhã se eu precisar mudar a rede do cluster eu sei que só precisa mudar a linha 32 e que é uma chave valor com string simples.
Também iria precisar de um banco de dados. Como tudo que eu uso é Django e eu gosto da ideia de ter o JsonField, optei por usar o Postgres. Para criar um desses é simples também.
Aqui você já consegue ver a criação do banco de dados, de uma base de dados e de um usuário. Isso ja vai adiantar a sua vida na hora de fazer testes e tal.
Um detalhe que para o nome do banco de dados eu uso o sql_name = str(uuid.uuid4().hex), isso porque se você criar um serviço com o nome name_1, deletar o serviço e tentar criar novamente ele vai dar erro dizendo que o nome já existe, pelo que eu entendo ele guarda o database durante alguns dias.
A primeira vez que eu fiz isso eu achei que já era o suficiente, mas eu depois percebi que precisava de um ip estático para vincular ao meu Ingress porque eu queria apontar um domínio de testes nele. E resolvi já criar de uma vez:
Esse cara vai funcionar perfeitamente para o Ingress GCE. Para o Ingress NGINX, que eu não uso eu sei que tem que ser um IP público não global ou alguma coisa assim, se você for usar um NGINX fique atento com isso.
Agora você vai criar um yml que vai rodar isso tudo:
Aqui você começa importando os arquivos que você quer e aí já dá para começar a explodir a mente com a quantidade de possibilidades que temos para começar a gerenciar tudo com isso.
Depois você faz o setup de cada recurso passando os valores nas variáveis.
Para criar todo o deployment basta executar:
gcloud deplyment-manager deployments create dp_name —-config=setup.yml —-project=my-project-dev
Ele vai criar toda a infra para você enquanto você está livre para fazer outras coisas.
Tips
Quando você executa o comando você pode passar variáveis ali, eu optei por passar o nome do projeto que será usado.
Caso em alguma receita você precise desse valor, você pode pegá-lo com context.env["project"], isso serve para qualquer outra variável, perceba que o valor entra como variável de ambiente.
A parte das properties você pega com context.properties["variavel"], sem mistério aqui.
Existe uma opção legal de usar o valor de saída de alguma receita como entrada para outra, vamos supor que você precisa do IP do seu cluster para expor alguma API dele para outro serviço.
Você pode expor o ip no output, veja acima na receita do K8S, ao final, existe o output. Agora basta referenciá-la no yaml:
properties:
endpoint: $(ref.cluster.endpoint)O próprio deployment vai entender que só pode criar o recurso em questão quando o cluster tiver funcionando e com o ip dele alocado. Isso já cria um sistema de dependências entre as receitas que possibilita a criação em sequencia de recursos dependentes.
Removendo tudo
Agora, antes de dormir, vamos deletar tudo para economizar. Para deletar basta executar:
gcloud deployment-manager deployments delete db_name
Conclusão
Agora você consegue chegar em casa, mandar subir sua infra, ir tomar um banho, jantar e voltar já com tudo pronto para começar a estudar.

