[Trilha CI/CD]: Provisionando o GitLab em uma instância EC2 da AWS com Terraform e Ansible
Opa pessoal, colando aqui de novo e hoje para falar sobre CI/CD, pipelines, runners e MUITO sobre GitLab. Estou iniciando essa trilha para justamente compartilhar TUDO o que eu sei sobre GitLab e ajudar mais pessoas que estão começando nessa jornada, pega seu café e venha curtir essa leitura TOP! 😄Hoje é sobre como você pode provisionar de forma simples e rápida o GitLab usando Terraform & Ansible no serviço de EC2 da AWS.
É hora de você parar de vez de criar serviços manuais na AWS e partir logo para o mindset de automação, bora!?
Claro, estava me esquecendo… eu vou criar um repositório no GitHub sobre essa trilha de CI/CD com todos os arquivos que estaremos usando ao longo do tempo, e convido vocês a contribuírem para que possamos melhorar esse projeto, a ideia é que mais pessoas possam aprender MUITO sobre GitLab e CI/CD, seguindo as boas práticas e com casos reais de mercado. 👊
O que vem pela frente?
Direto e reto!? IaC, Terraform, Ansible e GitLab. Hoje você vai terminar essa leitura sabendo do zero, como provisionar de forma automatizada a instalação de uma instância do GitLab (self-managed), no serviço EC2 da AWS usando Terraform & Ansible playbook. Você terá a chance de ter um GitLab somente seu para estudar e usar em seus projetos de CI/CD e DevOps.
Antes da gente dar sequência no código em si, preciso passar alguns conceitos das ferramentas que vamos usar aqui no artigo hoje, que são, Terraform, Ansible, GiLab e a abordagem de IaC, isso se faz necessário para situar as pessoas que estão começando agora, então a leitura fica mais prazerosa. Para os profissionais já atuantes com alguma das ferramentas que citei, sinta-se à vontade para pular essa etapa e ir logo para a parte mais prática do provisionamento do GiLab na AWS. 🚀
GitLab
Primeiramente, temos que discutir sobre o que é a ferramenta GitLab. De uma forma bem simples, e seguindo a própria documentação oficial, GitLab é um gerenciador de repositório de software baseado em Git com diversos serviços que fornecem suporte ao ciclo de desenvolvimento de software. Umas das partes mais bacanas do GitLab é que você pode instalar uma instância dele dentro da infraestrutura da sua empresa, mantendo seus repositórios privados. É justamente isso que vamos fazer aqui hoje com Terraform e Ansible.
Vale destacar que, o ponto legal que difere o GitHub do GitLab, é o foco que o GitLab vem dando à integração com ferramentas de DevOps, como o próprio Kubernetes, Slack, Nomad entre outros e sem contar que ele possibilita você a criar pipelines de CI/CD. O GitLab proporciona nativamente, ferramentas de integração e entrega contínua (CI/CD), resumindo isso… ele fornece software mais rapidamente com melhor segurança e colaboração em uma única plataforma, essa é uma vantagem que eu considero sob o GitHub.
IaC (Infrastructure as Code)
A abordagem de Infraestrutura como Código é o que vamos usar aqui hoje para provisionar o GitLab na AWS com Terraform. Basicamente, Infraestrutura como Código (IaC) é uma abordagem que consiste em você gerenciar e provisionar os recursos e/ou serviços da sua infraestrutura via código, ao invés de processos manuais. Na IaC, você cria arquivos de configuração (.yml/.tf) que incluem as especificações da sua infraestrutura.
Falando nisso, um colega MUITO atuante na comunidade conhecido como Rafael Gomes a.k.a Gomex, fundou um projeto bacana demais, que ajuda muitas pessoas na comunidade à aprender mais sobre IaC, chamado de Mentoria de IaC. Vale MUITO você conhecer caso pretenda aprender mais sobre como funciona IaC na pegada de mercado mesmo, e já adianto para você, é TUDO sem custos, é de trabalhador para trabalhador.
Ansible
“O Ansible é um mecanismo open source de automação de TI que automatiza o provisionamento, gerenciamento de configurações, implantação de aplicações, orquestração e muitos outros processos de TI por. Utilize a automação do Ansible para instalar softwares, automatizar tarefas rotineiras, provisionar infraestrutura, melhorar segurança e conformidade, aplicar patch em sistemas e compartilhar automação na sua empresa.” (Red Hat).
Recentemente, publiquei um artigo bacana sobre as boas práticas do Ansible, vale demais você ler, e se você já usa alguma boa prática, posta lá nos comentários, vai ajudar muitas outras pessoas que estão se aperfeiçoando. 👇
Terraform
Também usaremos aqui o Terraform, acredito que é uma das ferramentas mais fortes hoje no mercado de DevOps, justamente por elevar o nível de você codar e manter toda uma infraestrutura de TI organizada, versionada e com gerenciamento total de estado dos serviços. Para quem está estudando Terraform, eu super indico você ler as boas práticas da ferramenta que foram escritas pelo Anton Babenko, responsável por criar diversos módulos hoje usados por toda a comunidade e uma pessoa maravilhosa, super dedicada em melhorar e criar boas práticas do Terraform com AWS. ☁️
Aproveita e segue os projetos dele no GitHub porque são muito usados e lá você fica sempre de olho no que ele está trabalhando em torno de Terraform.
Stack
Para nosso hands-on de hoje, você precisa seguir com a seguinte stack:
- Ter o Ansible instalado na sua maquineta/instância/VirtualBOX.
- Ter o Terraform instalado na sua maquineta/instância/VirtualBOX.
- Ter o Git instalado na sua maquineta/instância/VirtualBOX.
- Ter uma conta free tier na AWS.
- Não precisa ter conhecimento prévio de IaC (vamos aprender…)
Vou dar sequência agora primeiramente com o Terraform para justamente fazermos todo o provisionamento da instância no serviço de EC2 da AWS. Logo depois vamos ver como ficou o Ansible Playbook e na parte final vamos executar isso e ver como ele se comportará no provisionamento.
A estrutura do Terraform
Para esse projeto de hoje, vou manter a seguinte arquitetura de exemplo, vamos usar um módulo local para referenciar os arquivos (.tf) da nossa infraestrutura na AWS.
A ideia aqui é termos a opção de provisionar o GitLab em duas regiões diferentes da AWS usando os arquivos bases que estão setados dentro de modules. Basicamente, você trocando a região e o AMI da instância fica OK, eu evito duplicação de código e dessa forma eu posso fazer a reusabilidade.
Definindo nossos arquivos “.tf”
Por boas práticas do Terraform, sempre é bom criar vários arquivos (.tf) para que fique mais organizado o diretório de trabalho e os serviços que você está provisionando e sempre que possível, use módulos no Terraform (locais ou de produtos como AWS, Azure, GCP), para que você evite código duplicado, configuração complexa de arquivos (.tf) e limites de reusabilidade, os módulos existem justamente para sanar esse tipo de problema.
Abaixo vou declarar nossos arquivos (.tf) que usaremos nesse projeto, alguns arquivos eu tenho adicionado variáveis, uma boa prática também e outros não, justamente para mostrar como ficam alguns arquivos com variáveis, vale mencionar que eu vou postar isso no GitHub em breve, então fica ligado que tudo será bem documentado e você poderá melhorar e contribuir com esse código. Se você tiver dúvidas na criação das credenciais do Terraform, veja esse outro artigo que eu escrevi no passado, lá está bem exemplificado.
O arquivo é o que vamos usar para declarar as variáveis que usaremos por enquanto na estrutura do projeto de Terraform:
No arquivo de ec2.tf, vamos declarar um recurso chamado de locals.tf, usado para declarar algumas variáveis importantes da estrutura.
Sobre o arquivo de versions.tf, esse é utilizado para que a gente tenha o controle das versões que estaremos trabalhando com o Terraform.
Sobre o arquivo de security_group.tf, este será usado para configurar as regras de firewall da nossa instância EC2, que no caso usaremos o protocolo SSH e o HTTP para que tenhamos acesso via web browser do GitLab.
Por fim, este arquivo output.tf, será usado para que possamos ter na saída padrão do Terraform, o valor do IP público da instância EC2.
Definindo o Ansible Playbook
Já temos todos os arquivos criados e definidos do Terraform, que vai fazer a parte de provisionamento do EC2, agora temos que trabalhar na parte do Ansible para que tudo ocorra da melhor forma. Eu desenvolvi esse playbook abaixo de forma bem simples, pode notar que ele não está documentado ainda (vou documentar no GitHub).
Esse playbook, possui algumas tasks bem simples, de instalação de pacotes, outras de configuração do Postfix e uma outra para adicionar o repositório do GitLab. Todas essas etapas eu busquei diretamente na documentação do GitLab, como estaremos instalando no sistema Ubuntu, basta você buscar pelo sistema dentro do site do GitLab, que ele oferece suporte e também para outros sistemas operacionais, como CentOS 7, Raspberry PI OS, OpenSUSE e outros.
Aqui abaixo o modelo de playbook que estaremos usando para nosso exemplo:
Partindo para o provisionamento
Acredito que estamos bem encaminhados por aqui, vamos fazer um checklist dos itens que já temos e o que está faltando!?
- Criamos nossa estrutura do Terraform conforme mostrado anteriormente.
- Definimos nossos arquivos (.tf) que serão utilizados.
- Definimos que vamos usar a Cloud da AWS e o serviço de EC2.
- A ferramenta de CI/CD que vamos usar é o GitLab.
- Definimos também o arquivo do Ansible Playbook.
Bom, hora de partir para o provisionamento da instância EC2 da AWS, para isso vamos trabalhar primeiramente com o Terraform, é ele que faz essa parte de Infraestrutura como Código no nosso projeto, com ele teremos a vantagem de termos nossa infraestrutura (EC2 e Security Group) provisionada e com gerenciamento de estado do que estamos criando na AWS, porque quando tudo estiver legal e rodando, vamos ter que deletar toda essa infraestrutura e o Terraform é capaz disso também.
Principais comandos do Terraform
Deixo abaixo alguns dos principais comandos mais utilizados do Terraform. Basicamente, vamos usar todos eles aqui no decorrer do nosso lab na AWS.
Main commands:
init Prepare your working directory for other commands
validate Check whether the configuration is valid
plan Show changes required by the current configuration
apply Create or update infrastructure
destroy Destroy previously-created infrastructureHora de pôr o Terraform em ação
Criado os arquivos, podemos partir para executar nosso projeto. O primeiro comando que devemos executar é o comando $ terraform fmt Esse comando deve formatar corretamente nossos arquivos criados para que esteja dentro do estilo de marcação do HCL.
$ terraform fmt
main.tf
provider.tf
variables.tfFeito vamos executar o $ terraform init Aqui você pode observar ele vai inicializar o nosso módulo:
$ terraform init
Initializing modules...Initializing the backend...Initializing provider plugins...
- Reusing previous version of hashicorp/aws from the dependency lock file
- Using previously-installed hashicorp/aws v3.74.3Terraform has been successfully initialized!You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
Agora vamos gerar o plano da nossa infraestrutura que será provisionada, não pretendo portar a saída aqui porque ficaria imenso…
$ terraform planTerraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
+ createTerraform will perform the following actions:# module.gitLab_deploy.aws_instance.server will be created
# module.gitLab_deploy.aws_security_group.server will be createdPlan: 2 to add, 0 to change, 0 to destroy.
Nesse momento que conhecemos o plano da nossa infraestrutura, vamos executar o comando $ terraform apply
$ terraform apply --auto-approvePlan: 2 to add, 0 to change, 0 to destroy...
Veja que nesse momento ele está buscando se conectar com o Ansible…
Aqui ele já obteve conectividade e executou o comando $ ansible-playbook Veja que o próprio Terraform se encarrega de cuidar da saída padrão:
Feito, veja que o provisionamento do GitLab levou mais de 9m:
Usuário e senha de acesso
Para testar o acesso, basta seguir a documentação do GitLab, onde diz que o usuário é root e a senha está no arquivo /etc/gitlab/initial_root_password Na AWS, você deve usar o Public IPv4 DNS para que tenha acesso direto no browser.
Finalizando…
Isso seria o que eu tinha em mente para hoje sobre GitLab pessoal, como essa é a primeira sessão da nossa trilha, pode esperar que vem mais, vamos ficar ninja em CI/CD com GitLab, brincar com algumas pepilines e quem sabe até usar Terraform integrado, massa demais!
Fiquem a vontade para enviar suas ideias, se achou bacana o artigo ou/e se precisa melhorar alguma coisa do que foi escrito aqui no post, eu sempre corrijo o que existe de errado baseado na observação de vocês, e se você notou que algum trecho não está legal, deixe-me saber, vamos contribuir e aprender ainda mais, fico agradecido pela sua leitura e tempo. TMJ! 🚀
