🥇Galinha ou ovo: desvendando o IaC

O que veio primeiro — o ovo ou a galinha? Um começo bastante estranho para um artigo sobre Infrastructure-as-Code, não é mesmo?

O que é um ovo?

Na maioria das vezes, Infrastructure-as-Code (IaC) é uma forma declarativa de representar a infraestrutura. Nele, descrevemos o estado que queremos alcançar, desde a parte física até a configuração do software. Portanto, IaC é usado para:

Provisionamento de Recursos. Isso inclui VMs, S3, VPC, etc. As principais ferramentas utilizadas são: Terraform e CloudFormation.
Configuração de Software. Principais ferramentas: Ansible, Chef, etc.

Todo código reside em repositórios git. E cedo ou tarde, o líder de equipe decidirá que é hora de organizar tudo. Ele fará refatoração. Criará uma estrutura. E verá que isso é bom.

Também é bom que já exista GitLab e GitHub- um provedor para Terraform (e isso é Configuração de Software). Com eles, é possível gerenciar todo o projeto: membros da equipe, CI/CD, git-flow, etc.

De onde veio o ovo?

Aqui estamos, aos poucos, chegando à pergunta principal.

Antes de mais nada, é preciso começar com um repositório que descreva a estrutura dos outros repositórios, inclusive o próprio. E, claro, no contexto do GitOps, é necessário adicionar CI para que as alterações sejam executadas automaticamente.

E se o Git ainda não foi criado?

Como armazená-lo no Git?
Como integrar o CI?
E se o Gitlab também for implementado usando IaC e em Kubernetes?
E o GitLab Runner também em Kubernetes?
E o Kubernetes em um provedor de nuvem?

O que surgiu primeiro: o GitLab, onde carregarei meu código, ou o código que descreve qual GitLab eu preciso?

A galinha com os ovos

«Oyakodon3 com dinossauro» [src]

Vamos tentar preparar o prato, usando como provedor de nuvem Managed Kubernetes Selectel.

TL;DR

E é possível fazer isso tudo em um único comando?

$ export MY_SELECTEL_TOKEN=
$ curl https://gitlab.com/chicken-or-egg/mks/make/-/snippets/2002106/raw | bash

Ingredientes:

Conta do my.selectel.ru;
Token da conta;
Habilidades em Kubernetes;
Habilidades em Helm;
Habilidades em Terraform;
Chart Helm GitLab;
Chart Helm GitLab Runner.

Receita:

Obtenha MY_SELECTEL_TOKEN do painel my.selectel.ru.
Crie um cluster Kubernetes, passando o token da conta.
Obtenha KUBECONFIG do cluster criado.
Instale o GitLab no Kubernetes.
Obtenha o GitLab-token do GitLab criado para o usuário root.
Crie a estrutura de projetos no GitLab, utilizando o GitLab-token.
Envie o código existente para o GitLab.
???
Lucro!

Passo 1. O token pode ser obtido na seção Chaves API.

Passo 2. Preparamos nosso Terraform para "cozinhar" um cluster de 2 nós. Se você tem certeza de que possui recursos suficientes para tudo, pode habilitar a auto-quota:

provider "selectel" {
 token = var.my_selectel_token
}

variable "my_selectel_token" {}
variable "username" {}
variable "region" {}


resource "selectel_vpc_project_v2" "my-k8s" {
 name = "my-k8s-cluster"
 theme = {
   color = "269926"
 }
 quotas {
   resource_name = "compute_cores"
   resource_quotas {
     region = var.region
     zone = "${var.region}a"
     value = 16
   }
 }
 quotas {
   resource_name = "network_floatingips"
   resource_quotas {
     region = var.region
     value = 1
   }
 }
 quotas {
   resource_name = "load_balancers"
   resource_quotas {
     region = var.region
     value = 1
   }
 }
 quotas {
   resource_name = "compute_ram"
   resource_quotas {
     region = var.region
     zone = "${var.region}a"
     value = 32768
   }
 }
 quotas {
   resource_name = "volume_gigabytes_fast"
   resource_quotas {
     region = var.region
     zone = "${var.region}a"
     # (20 * 2) + 50 + (8 * 3 + 10)
     value = 130
   }
 }
}

resource "selectel_mks_cluster_v1" "k8s-cluster" {
 name         = "k8s-cluster"
 project_id   = selectel_vpc_project_v2.my-k8s.id
 region       = var.region
 kube_version = "1.17.9"
}

resource "selectel_mks_nodegroup_v1" "nodegroup_1" {
 cluster_id        = selectel_mks_cluster_v1.k8s-cluster.id
 project_id        = selectel_mks_cluster_v1.k8s-cluster.project_id
 region            = selectel_mks_cluster_v1.k8s-cluster.region
 availability_zone = "${var.region}a"
 nodes_count       = 2
 cpus              = 8
 ram_mb            = 16384
 volume_gb         = 15
 volume_type       = "fast.${var.region}a"
 labels            = {
   "project": "my",
 }
}

Adicionando usuário ao projeto:

resource "random_password" "my-k8s-user-pass" {
 length = 16
 special = true
 override_special = "_%@"
}

resource "selectel_vpc_user_v2" "my-k8s-user" {
 password = random_password.my-k8s-user-pass.result
 name = var.username
 enabled  = true
}

resource "selectel_vpc_keypair_v2" "my-k8s-user-ssh" {
 public_key = file("~/.ssh/id_rsa.pub")
 user_id    = selectel_vpc_user_v2.my-k8s-user.id
 name = var.username
}

resource "selectel_vpc_role_v2" "my-k8s-role" {
 project_id = selectel_vpc_project_v2.my-k8s.id
 user_id    = selectel_vpc_user_v2.my-k8s-user.id
}

Saída:

output "project_id" {
 value = selectel_vpc_project_v2.my-k8s.id
}

output "k8s_id" {
 value = selectel_mks_cluster_v1.k8s-cluster.id
}

output "user_name" {
 value = selectel_vpc_user_v2.my-k8s-user.name
}

output "user_pass" {
 value = selectel_vpc_user_v2.my-k8s-user.password
}

Iniciando:

$ env 
TF_VAR_region=ru-3 
TF_VAR_username=diamon 
TF_VAR_my_selectel_token= 
terraform plan -out planfile

$ terraform apply -input=false -auto-approve planfile

Passo 3. Obtendo kubeconfig.

Para baixar KUBECONFIG programaticamente, é necessário obter um token do OpenStack:

openstack token issue -c id -f value > token

E com esse token, fazer a solicitação na API do Kubernetes Gerenciado da Selectel. k8s_id fornece terraform:

curl -XGET -H "x-auth-token: $(cat token)" "https://ru-3.mks.selcloud.ru/v1/clusters/$(cat k8s_id)/kubeconfig" -o kubeConfig.yaml

O kubeconfig também pode ser obtido através do painel.

Passo 4. Depois que o cluster foi configurado e temos acesso, podemos adicionar um yaml de nossa escolha.

Eu prefiro adicionar:

namespace,
classe de armazenamento,
política de segurança do pod e outros.

Classe de Armazenamento para Selectel pode-se pegar de repositório oficial.

Como inicialmente escolhi o cluster na zona ru-3a, então a classe de armazenamento que preciso é dessa zona.

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
 name: fast.ru-3a
 annotations:
   storageclass.kubernetes.io/is-default-class: "true"
provisioner: cinder.csi.openstack.org
parameters:
 type: fast.ru-3a
 availability: ru-3a
allowVolumeExpansion: true

Passo 5. Vamos configurar o balanceador de carga.

Vamos utilizar o padrão, que é muito comum nginx-ingress. Já existem muitas instruções para sua instalação, então não vamos nos demorar nisso.

$ helm repo add nginx-stable https://helm.nginx.com/stable
$ helm upgrade nginx-ingress nginx-stable/nginx-ingress -n ingress --install -f ../internal/K8S-cluster/ingress/values.yml

Vamos aguardar aproximadamente 3-4 minutos até que ele obtenha um IP externo:

Obtivemos o IP externo:

Passo 6. Vamos instalar o GitLab.

$ helm repo add gitlab https://charts.gitlab.io
$ helm upgrade gitlab gitlab/gitlab -n gitlab --install -f gitlab/values.yml --set "global.hosts.domain=gitlab.$EXTERNAL_IP.nip.io"

Novamente, aguardamos até que todos os pods sejam iniciados.

kubectl get po -n gitlab
NAME                                      	READY   STATUS  	RESTARTS   AGE
gitlab-gitaly-0                           	0/1 	Pending 	0      	0s
gitlab-gitlab-exporter-88f6cc8c4-fl52d    	0/1 	Pending 	0      	0s
gitlab-gitlab-runner-6b6867c5cf-hd9dp     	0/1 	Pending 	0      	0s
gitlab-gitlab-shell-55cb6ccdb-h5g8x       	0/1 	Init:0/2	0      	0s
gitlab-migrations.1-2cg6n                 	0/1 	Pending 	0      	0s
gitlab-minio-6dd7d96ddb-zd9j6             	0/1 	Pending 	0      	0s
gitlab-minio-create-buckets.1-bncdp       	0/1 	Pending 	0      	0s
gitlab-postgresql-0                       	0/2 	Pending 	0      	0s
gitlab-prometheus-server-6cfb57f575-v8k6j 	0/2 	Pending 	0      	0s
gitlab-redis-master-0                     	0/2 	Pending 	0      	0s
gitlab-registry-6bd77b4b8c-pb9v9          	0/1 	Pending 	0      	0s
gitlab-registry-6bd77b4b8c-zgb6r          	0/1 	Init:0/2	0      	0s
gitlab-shared-secrets.1-pc7-5jgq4         	0/1 	Completed   0      	20s
gitlab-sidekiq-all-in-1-v1-54dbcf7f5f-qbq67   0/1 	Pending 	0      	0s
gitlab-task-runner-6fd6857db7-9x567       	0/1 	Pending 	0      	0s
gitlab-webservice-d9d4fcff8-hp8wl         	0/2 	Pending 	0      	0s
Aguardando gitlab
./wait_gitlab.sh ../internal/gitlab/gitlab/.pods
aguardando pelo pod...
aguardando pelo pod...
aguardando pelo pod...

Os pods foram iniciados:

Passo 7. Obtendo o token do GitLab.

Primeiro, vamos descobrir a senha de acesso:

kubectl get secret -n gitlab gitlab-gitlab-initial-root-password -o jsonpath='{.data.password}' | base64 --decode

Agora vamos nos autenticar e obter o token:

python3 get_gitlab_token.py root $GITLAB_PASSWORD http://gitlab.gitlab.$EXTERNAL_IP.nip.io

Passo 8. Organizamos os repositórios Git na hierarquia correta com o Provedor GitLab.

cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfile

Infelizmente, existe um problema no provedor GitLab do terraform. bug. Então, será necessário remover os projetos conflitantes manualmente para corrigir o tf.state. Em seguida, reinicie o comando `$ make all`

Passo 9. Transferimos os repositórios locais para o servidor.

$ make push

[master (root-commit) b61d977]  Commit inicial
 3 arquivos alterados, 46 inserções(+)
 criar modo 100644 .gitignore
 criar modo 100644 values.yml
Enumerando objetos: 5, feito.
Contando objetos: 100% (5/5), feito.
Compressão delta usando até 8 threads
Compactando objetos: 100% (5/5), feito.
Escrevendo objetos: 100% (5/5), 770 bytes | 770.00 KiB/s, feito.
Total 5 (delta 0), reutilizado 0 (delta 0)

Pronto:

Conclusão

Conseguimos gerenciar tudo de forma declarativa a partir da nossa máquina local. Agora, queremos transferir todas essas tarefas para o CI e apenas pressionar botões. Para isso, precisamos transferir nossos estados locais (Terraform state) para o CI. Sobre como fazer isso, falaremos na próxima parte.