Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/64j0/bootcamp-sre-elvenworks

Trabalho final do Bootcamp SRE ElvenWorks.
https://github.com/64j0/bootcamp-sre-elvenworks

Last synced: 2 days ago
JSON representation

Trabalho final do Bootcamp SRE ElvenWorks.

Awesome Lists containing this project

README 

        
#+TITLE: Desafio final bootcamp ElvenWorks

#+AUTHOR: Vinícius Gajo Marques Oliveira



* Introdução



Este repositório guarda o projeto relacionado ao desafio final do bootcamp da

ElvenWorks, terceira turma, 2022. Ao longo deste README irei apresentar tanto os

requisitos e critérios, quanto minhas ideias de como implementar o projeto.



O título do desafio foi: *Wordpress Turbinado na AWS*.



* Instruções



Para reproduzir o mesmo ambiente utilizado no desenvolvimento deste projeto,

certifique-se ter as seguintes ferramentas disponíveis no seu ambiente local:



+ ~Terraform v1.3.5~

+ ~AWS CLI 2.8.12~

+ ~Docker version 20.10.21~



** IaC - Terraform



Para provisionar os serviços na AWS, use os comandos:



#+BEGIN_SRC shell :tangle no

  # Pré-requisitos para executar o script:

  #

  # * Necessário:

  #

  # export TF_VAR_rds_db_username="databaseadmin"

  # export TF_VAR_rds_db_password="veryStrongPassphrase12377GotIt"

  #

  # * Não necessário:

  #

  # export TF_VAR_wordpress_db_name="wordpress"

  # export TF_VAR_wordpress_db_username="wpadmin"

  # export TF_VAR_wordpress_db_password="Wp@12345"



  cd sh/

  ./terraform-run.sh # y

  cd ../terraform

  ssh -i "curso_terraform.pem" -o IdentitiesOnly=yes ubuntu@



  # Para destruir o serviço:

  #

  # cd terraform/

  # terraform destroy

#+END_SRC



*** Módulos Terraform



- [X] EC2 Wordpress.

- [X] EC2 monitoramento (Prometheus, Grafana e 1P).

- [X] RDS para o DB do Wordpress.

- [ ] CDN/WAF na instância do Wordpress.



** Ansible



Para organizar os manifestos do Ansible, decidi separar as configurações

específicas de cada ambiente numa pasta diferente. No momento temos apenas a

configuração do wordpress para o ambiente local (~ansible/wordpress-local/~) e

outra configuração para o ambiente da AWS (~ansible/wordpress-aws/~).



Este segundo (~wordpress-aws~) é o que deve ser usado em conjunto com a

configuração dos serviços do Terraform.



*** wordpress-aws/



Neste diretório estão os arquivos necessários para configurar e iniciar o

serviço do Wordpress no ambiente provisionado com Terraform na AWS.



*** wordpress-local/



+ Atenção: A configuração para ser executada no container Docker não está

  funcional por enquanto, devido à algumas limitações relacionadas ao próprio

  Docker.



Para facilitar o desenvolvimento da configuração do Ansible, decidi fazer o

provisionamento num container local primeiramente. O manifesto com as

configurações desse container pode ser visto no arquivo ~./Dockerfile.Ansible~.



#+BEGIN_SRC shell :tangle no

  # criação do container

  docker build -t "ansible-wordpress" -f "Dockerfile.Ansible" "."



  # executando localmente

  docker run -d -p 80:80 ansible-wordpress:latest

  # para debugar

  # docker run -p 80:80 -it --entrypoint="bash" ansible-wordpress:latest

#+END_SRC



* Requisitos & Critérios



Nesta seção estou mencionando a lista de requisitos e critérios adotados para o

trabalho final do bootcamp. Alguns destes pontos são apenas opcionais.



** Requisitos



+ Automação de ambientes com Infras as Code: Criar recursos com o Terraform e

  configurações das dependências/pacotes dentro do Linux com Ansible;

+ Provisionar 2 servidores Linux na AWS;

+ Instalar e configurar o Wordpress com Ansible na EC2;

+ Configurar banco de dados em outro servidor (RDS);

+ Arquitetura elástica com VMs e autoscaling: configurar load balancer;

+ Arquitetura com CDN/WAF na frente do wordpress;

+ Criar um ambiente mínimo de Monitoramento ou Observabilidade, usando

  Prometheus, Grafana e 1P;

+ Criar indicadores para CPU, Memória, Disco e Request HTTP ou para The Four

  Golden Signals (Latências, Tráfego, Erros e Saturação).



** Critérios



- [X] Conhecer os principais serviços da AWS (EC2, VPC, RDS Memcached, Load

  Balancer, Autoscaling, WAF, CloudFront);

- [X] Entender a função dos principais serviços da AWS (EC2, VPC, RDS Memcached,

  Load Balance, Autoscaling, WAF, CloudFront) e a sua correlação quando existir;

- [X] Aplicar boas práticas de mercado no provisionamento dos principais

  serviços AWS. Exemplo: Launch Template, Tags, Gerenciamento de Conta e

  Usuário, Controle de Data transfer (In/Out), Well Architected, FinOps;

- [X] Analisar a necessidade ou não do provisionamento de serviço na

  infraestrutura;

- [X] Criar conta válida na AWS;

- [X] Conhecer Ansible, suas estruturas, módulos e comandos, usados para se

  configurar o blog Wordpress;

- [X] Entender a função dos principais módulos usados para se configurar o blog

  Wordpress;

- [X] Aplicar boas práticas de mecado na configurção do blog Wordpress. Exemplo:

  variáveis, roles e coesão de código;

- [X] Analisar a necessidade ou não do uso de um módulo na configuração do blog

  Wordpress;

- [X] Criar um projeto Ansible para configurar Wordpress no EC2;

- [X] Conhecer recurso ou módulos Terraform obrigatório (EC2, VPC, RDS) e não

  obrigatórios (Mecached, Load Balancer, Autoscaling, WAF, CloudFront) da AWS;

- [X] Entender as principais estruturas do Terraform e a sua função (resources,

  variaveis, outputs e módulos);

- [X] Aplicar as melhores práticas de mecado no provisionamento dos recursos na

  AWC com Terraform. Exemplo: variáveis, condicionais, loops, modularização e

  coesão de código;

- [X] Analisar a necessidade de refatoração para melhor manutenibilidade e

  legibilidade de código;

- [X] Criar um projeto Terraform com os recurso obrigatório (EC2, VPC, RDS) e

  não obrigatórios (Mecached, Load Balancer, Autoscaling, WAF, CloudFront);

- [X] Conhecer The Four Golden Signals (Latência, Tráfego, Erros e Saturação);

- [X] Entender a diferença entre Monitoramento e Observabilidade;

- [X] Aplicar conceitos SLAs, SLOs, SLIs e Error Budgets;

- [X] Analisar Indicadores(CPU, Memória, Disco e Request HTTP) ou The Four

  Golden Signals(Latência, Tráfego, Erros e Saturação);

- [X] Criar um ambiente mínimo de Monitoramento ou Observabilidade, usando

  Prometheus, Grafana e 1P;



* Conceitos



** Serviços da AWS



*** EC2 - Elastic Cloud Computing



*EC2* é um acrônimo que significa "Elastic Cloud Computing". É o serviço de IaaS

da AWS que fornece uma VM ligada à um datacenter gerenciado pela Amazon.



A configuração inicial da VM é baseada numa imagem, que usando a terminologia

específica da AWS é conhecida como *AMI*: "Amazon Machine Image".



*AMI* é a imagem de uma máquina específica, um backup com várias configurações

já feitas, incluindo o sistema operacional, e em alguns casos serviços já

instalados e capazes de executar desde o boot.



Além da imagem inicial da VM, outros aspectos que devem ser considerados num

primeiro momento são: *Volume*, que está relacionado ao storage/armazenamento da

VM, e *Network*, que está relacionado à rede em que a VM irá operar.



Por fim, após definir os requisitos do processo que será executado na VM,

devemos levar em consideração o *preço* associado ao recurso.



Mais informações em: [[https://docs.aws.amazon.com/ec2/index.html][Amazon Elastic Compute Cloud Documentation]].



*** VPC - Virtual Private Cloud



VPC é um acrônimo para "Virtual Private Cloud". É um serviço usado para criação

e gerenciamento de redes virtuais (privadas ou não) para conectar componentes

dentro da cloud.



Mais informações em: [[https://docs.aws.amazon.com/vpc/][Amazon Virtual Private Cloud Documentation]].



*** RDS - Relational Database Service



RDS é um acrônimo para "Amazon Relational Database Service". Este serviço é

usado para facilitar o provisionammento, configuração e operação de bancos

relacionais na nuvem.



Mais informações em: [[https://docs.aws.amazon.com/rds/index.html][Amazon Relational Database Service Documentation]].



*** ElastiCache



O serviço Amazon ElastiCache foi pensado para facilitar a configuração,

gerenciamento, e operação de ambientes distribuídos de cache em memória dentro

da nuvem da AWS.



Atualmente suporta os motores tanto do Redis quanto do Memcached, que são bancos

de dados não-relacionais utilizados para armazenamento de cache em memória.



Mais informações em: [[https://docs.aws.amazon.com/elasticache/index.html][Amazon ElastiCache Documentation]].



*** Elastic Load Balancing



O serviço Elastic Load Balancing distribui automaticamente o tráfego de entrada

entre vários servidores, como instâncias de EC2, containers, e endereços de IP,

em uma ou mais zonas de disponibilidade (Availability Zones).



Este serviço monitora a saúde dos servidores registrados, e roteia o tráfego

apenas para os processos sadios.



Mais informações em: [[https://docs.aws.amazon.com/elasticloadbalancing/index.html][Elastic Load Balancing Documentation]].



*** Auto Scaling



A nuvem da Amazon provê múltiplos serviços que podem ser usados para escalar sua

aplicação manualmente/automaticamente.



Tratando especificamente de instâncias de EC2, o serviço Amazon EC2 Auto Scaling

ajuda a garantir que o número correto de instâncias estejam disponíveis para

lidar com a carga da sua aplicação. Para isso, é necessário criar coleções de

instâncias EC2, chamadas "Auto Scaling groups", definindo o número mínimo e

máximo de instâncias que devem estar disponíveis para a aplicação.



Mais informações em: [[https://docs.aws.amazon.com/autoscaling/index.html][Auto Scaling Documentation]], [[https://docs.aws.amazon.com/autoscaling/ec2/userguide/what-is-amazon-ec2-auto-scaling.html][What is Amazon EC2 Auto

Scaling?]].



*** WAF - Web Application Firewall



WAF é um acrônimo para "Web Application Firewall". É um serviço que permite

monitorar requisições WEB que são enviadas para distribuições do Amazon

CloudFront, ou para um Application Load Balancer.



É possível usar o AWS WAF para bloquear ou permitir as requisições com base em

condições especificadas, como por exemplo, validação de endereços IP de origem

da requisição, ou com base em valores contidos na própria requisição.



Mais informações em: [[https://docs.aws.amazon.com/waf/index.html][AWS WAF Documentation]].



*** CloudFront



O serviço Amazon CloudFront acelera a distribuição de conteúdo web estático e

dinâmico, por exemplo, arquivos .html, .css, .php, imagens, e arquivos de

mídia. Quando os usuários requisitam seu conteúdo, o serviço CloudFront o

entrega através de uma rede global de múltiplas localizações limite, garantindo

baixa latência e alta performance.



Pode ser entendido como um CDN, "Content Delivery Network".



Mais informações em: [[https://docs.aws.amazon.com/cloudfront/index.html][Amazon CloudFront Documentation]].



** The "Four Golden Signals" do Monitoramento



Os "quatro sinais dourados" são relacionados a conceitos abordados no livro

"Site Reliability Engineering", escrito por engenheiros do Google, e que foi

crucial na definição da posição de SRE em diversas empresas mundialmente.



Em resumo, os quatro sinais são: latência, tráfego, erros e saturação. Estas são

as métricas que o time de SRE deve focar primariamente para conseguir

desempenhar seu papel de maneira efetiva, no monitoramento de sistemas

distribuídos.



Com base nessas métricas já é possível trazer vários insights para melhoria do

sistema e detectar problemas de maneira mais direta.



*** Latência



O tempo gasto para servir uma requisição. É importante manter a distinção entre

a latência de requisições bem-sucedidas e malsucedidas. Por exemplo, um erro

HTTP 500 disparado devido à perda de conexão com um banco de dados ou outro

serviço crítico do backend pode ser servido muito rapidamente; porém, em outros

cenários isso pode levar a uma grande perda de performance da aplicação.



Por isso é importante fazer a distinção principalmente entre a latência de

requisições bem-sucedidas e falhas.



*** Tráfego



Uma medida da demanda que é aplicada ao sistema monitorado, medida em uma

métrica específica para o sistema que seja de alto nível.



Por exemplo, em um serviço web, essa medida é normalmente a quantidade de

requisições HTTP por segundo. Em alguns casos ainda é feita a distinção entre

cada tipo de requisição (e. g., conteúdo estático versus dinâmico).



Em um sistema de transmissão de áudio, essa medida pode focar na razão de

entrada/saída da rede, ou sessões concorrentes.



Em um sistema de armazenamento chave-valor, essa medida pode ser escritas e

leituras por segundo.



*** Erros



A porcentagem de requisições que falham, seja explicitamente (e.g., HTTP 500s),

implicitamente (por exemplo, uma resposta HTTP 200, mas com conteúdo relacionado

a falha), ou por política (por exemplo, "consideramos qualquer resposta que leve

mais que um segundo para finalizar um erro").



*** Saturação



Quão "cheio" o seu serviço está. Uma medida fracionária do seu sistema,

enfatizando os recursos que estão mais limitados (por exemplo, em um sistema

limitado em memória, mostrar a memória; em um sistema limitado em entrada/saída,

mostrar o valor de entrada/saída).



Note que muitos sistemas degradam de performance mesmo antes de atingir 100% de

utilização, então, ter um limite de utilização é essencial para manter os mesmos

níveis de performance.



*** Referência



A versão digital do livro é disponibilizada gratuitamente pela própria Google

junto a outros títulos do tema, e pode ser lida no seguinte link:

https://sre.google/books/.



Por fim, para uma explicação mais detalhada, vale a pena conferir o capítulo

onde esse tópico é abordado no livro de Site Reliability Engineering. Link:

[[https://sre.google/sre-book/monitoring-distributed-systems/][Chapter 6 - Monitoring Distributed Systems]].



** Monitoramento x Observabilidade



De acordo com o livro [[https://www.oreilly.com/library/view/observability-engineering/9781492076438/][Observability Engineering]], ferramentas tradicionais de

*monitoramento* funcionam verificando as condições do sistema em relação a

valores conhecidos que indicam que algum erro ocorrido anteriormente está

presente. É uma abordagem fundamentalmente reativa que funciona bem para

identificar modos de falha identificados anteriormente.



Em contraste, ferramentas de *observabilidade* funcionam permitindo a

investigação exploratória iterativa para determinar sistematicamente onde e

porque problemas de performance podem estar acontecendo. Observabilidade permite

uma abordagem proativa para identificar qualquer modo de falha, tendo este

ocorrido anteriormente ou não.



Para informações mais detalhadas, vale a pena consultar a referência mencionada

nessa seção.



** SLAs, SLOs, SLIs e Error Budgets



*** Service Level Indicators - SLI



Uma quantidade definida cuidadosamente para medir algum aspecto do nível de

serviço que está sendo disponibilizado.



A maioria dos serviços considera a *latência das requisições* como um SLI

chave. Outro SLI comum inclui a *taxa de erros*, normalmente expressa como uma

fração de todas as requisições recebidas, e a *transferência do sistema*

(throughput), normalmente medido em requisições por segundo.



Essas medidas são normalmente agregadas para facilitar a análise posterior, além

de reduzir a quantidade de dados a serem mantidos ao longo do tempo.



Idealmente, o SLI mede diretamente o nível do serviço sendo avaliado, porém em

algumas situações é necessário usar um proxy, pois a medição desejada pode ser

complicada de se obter ou interpretar corretamente. Por exemplo, a latência no

lado do cliente é geralmente uma ótima métrica relevante do ponto de vista do

usuário, mas na maior parte dos casos só é possível medir a latência no

servidor.



Outro SLI importante no ponto de vista do SRE é a *disponibilidade*

(availability), ou a fração de tempo em que um serviço é usável.



*** Service Level Objectives - SLO



Um valor alvo, ou espaço de valores, para o nível de serviço que é medido pelo

SLI. Uma estrutura natural para o SLO é, portanto, ~SLI <= alvo~, ou ~limite

inferior <= SLI <= limite superior~.



*** Service Level Agreements - SLA



Um contrato explícito ou implícito com os usuários do serviço que inclui

consequências em casos onde a meta definida pelos SLOs é atingida (ou não). As

consequências são mais facilmente reconhecíveis quando tem um caráter

financeiro, mas pode assumir outras formas.



Uma maneira simples de saber a diferença entre um SLO e um SLA é se perguntar "o

que acontece se os SLOs não são atingidos?": se não existir uma consequência

explícita, então você está certamente olhando para um SLO.



*** Error Budgets



Uma taxa que define quanto um SLO pode ser perdido, que geralmente é monitorado

numa base diária ou semanal. Os níveis mais altos da hierarquia corporativa vão

querer geralmente um relatório mensal ou trimestral geralmente.



*** Referências



A principal referência considerada nesta seção foi o livro "Site Reliability

Engineering". Link: [[https://sre.google/sre-book/service-level-objectives/][Chapter 4 - Service Level Objectives]].



* Ideias



- [X] Usar a infraestrutura na AWS;

- [X] Provisionar os componentes com Terraform;

- [X] Gerenciar a configuração com Ansible;

+- [ ] Usar como exemplo de Literate DevOps;+

- [X] GitHub Action para verificar o formato e validar o código Terraform;

- [ ] Criar GitHub Actions para automatizar o processo de provisionamento e

  destruição dos serviços;

- [ ] Salvar o estado do Terraform num bucket S3;

  

* AWS CLI



** Comandos Úteis



+ Listar os profiles: ~aws configure list-profiles~

+ Listar os buckets s3: ~aws s3 ls~



* Links Úteis



+ [[https://medium.com/dnx-labs/terraform-remote-states-in-s3-d74edd24a2c4][Terraform Remote States in S3]]

+ [[https://devops4solutions.com/monitoring-using-prometheus-and-grafana-on-aws-ec2/][Monitoring using Prometheus and Grafana on AWS EC2]]

+ [[https://duffney.io/containers-for-ansible-development/][Containers for Ansible Development]]

+ [[https://markontech.com/wordpress/deploy-wordpress-on-docker-using-ansible/][Deploy WordPress On Docker Using Ansible]]

+ [[https://blog.opstree.com/2020/03/24/ansible-directory-structure-default-vs-vars/][Ansible directory structure (Default vs Vars)]]

+ [[https://github.com/wellingtonvidaleal/ansible-desafio-final-formacao-sre][wellingtonvidaleal/ansible-desafio-final-formacao-sre]]

+ [[https://github.com/diogolimaelven/ansible][diogolimaelven/ansible]]