O que veio primeiro – a galinha ou o ovo? É um começo bastante estranho para um artigo sobre infraestrutura como código, não é?
O que é um ovo?
Na maioria das vezes, Infraestrutura como Código (IaC) é uma forma declarativa de representar a infraestrutura. Nele descrevemos o estado que queremos alcançar, começando pela parte de hardware e terminando com a configuração de software. Portanto IaC é usado para:
Provisão de recursos. São VMs, S3, VPC, etc. Ferramentas básicas para trabalho: Terraform и CloudFormação.
Qualquer código está nos repositórios git. E mais cedo ou mais tarde o líder da equipe decidirá que eles precisam ser colocados em ordem. E ele irá refatorar. E isso criará alguma estrutura. E ele verá que isso é bom.
Também é bom que já exista GitLab и GitHub-provider para Terraform (e esta é a configuração de software). Com a ajuda deles, você pode gerenciar todo o projeto: membros da equipe, CI/CD, git-flow, etc.
De onde veio o ovo?
Então estamos gradualmente nos aproximando da questão principal.
Primeiro de tudo, você precisa começar com um repositório que descreva a estrutura de outros repositórios, inclusive o seu. E, claro, como parte do GitOps, você precisa adicionar CI para que as alterações sejam executadas automaticamente.
Se o Git ainda não foi criado?
Como armazená-lo no Git?
Como instalar o CI?
Se também implantarmos o Gitlab usando IaC, e até mesmo em Kubernetes?
E o GitLab Runner também no Kubernetes?
E quanto ao Kubernetes no provedor de nuvem?
O que veio primeiro: o GitLab onde carregarei meu código ou o código que descreve que tipo de GitLab eu preciso?
Obtenha MY_SELECTEL_TOKEN do painel meu.selectel.ru.
Crie um cluster Kubernetes transferindo um token de conta para ele.
Obtenha KUBECONFIG do cluster criado.
Instale o GitLab no Kubernetes.
Obtenha o token GitLab do GitLab criado para o usuário raiz.
Crie uma estrutura de projeto no GitLab usando o token GitLab.
Envie o código existente para o GitLab.
???
Lucro!
Passo 1. O token pode ser obtido na seção Chaves de API.
Passo 2. Preparamos nosso Terraform para “preparar” um cluster de 2 nós. Se tiver certeza de que possui recursos suficientes para tudo, você pode ativar as cotas automáticas:
Passo 8. Trazendo repositórios Git para a hierarquia correta usando o provedor Gitlab.
cd ../internal/gitlab/hierarchy && terraform apply -input=false -auto-approve planfile
Infelizmente, o provedor terraform GitLab tem um flutuante bug. Então você terá que excluir os projetos conflitantes manualmente para que tf.state seja corrigido. Em seguida, execute novamente o comando `$make all`
Passo 9. Transferimos repositórios locais para o servidor.
Conseguimos gerenciar tudo de forma declarativa em nossa máquina local. Agora quero transferir todas essas tarefas para o CI e apenas pressionar os botões. Para fazer isso, precisamos transferir nossos estados locais (estado Terraform) para CI. Como fazer isso está na próxima parte.
Assine o nosso Blogpara não perder o lançamento de novos artigos!