Infraestrutura para hospedar um servidor wordpress em uma instância EC2 e armazenar os dados produzidos em um RDS.

Componentes:

Rede privada envolvendo os recursos

Sub-rede com recursos publicos ou que possibilitam o acesso externo:

• ALB: Application Load Balancer para redirecionar as requisições recebidas em seu DNS público para o servidor web existente na subnet privada.
• Internet Gateway: Habilita acesso a internet aos recursos da VPC.
• Nat Gateway: Permite que componentes em subnets privadas tenham acesso a internet, estes componentes não são acessíveis na internet, apenas possuem acesso a ela.
• Security group: SSH liberado publicamente para acesso ao bastion.
• EC2: Instância t2.micro, esta instância é utilizada apenas para acessar outras instâncias privadas de modo seguro, por isso é chamada de bastion.

Sub-rede para o servidor web (EC2):

• Security group:
  • HTTP liberado publicamente;
  • SSH liberado na VPC (10.0.0.0/22).
• EC2: Servidor web com acesso ao banco de dados RDS, a única forma de acesso ao bash é via bastion, não é possível acessá-lo diretamente via internet, apenas via HTTP (redirecionado pelo ALB). Para baixar pacotes como o client do MySQL e PHP é utilizado o Nat Gateway mencionado anteriormente, a instância EC2 é direcionada para o Nat Gateway que por sua vez encaminha a requisição para o Internet Gateway possibilitando o acesso a internet pela instância.

Sub-rede para o banco de dados MySQL (RDS)

• Security Group: Acesso liberado a subnet privada (servidor web).
• RDS: MySQL para salvar dados gerados pelo servidor wordpress.

A infraestrutura criada precisa das seguintes variáveis para funcionar corretamente:

Importante: A documentação do terraform orienta que a criação da Key Pair seja feita fora dos arquivos ".tf" para não serem armazenados nos arquivos de estado do terraform. O direcionamento é que apenas o nome da Key Pair seja utilizado nos arquivos ".tf".

Caso a chave wordpress-lab não exista região em que o ambiente será publicado - us-east-1 por padrão, essa configuração pode ser alterada no arquivo main.tf - a infra não será criada. As Keys Pairs podem ser substituidas atribuido as variáveis bastion_key_name e web_server_key_name novos valores, este processo será detalhado nas próximas seções.

Para criar variáveis que serão identificadas pelo terraform o prefixo TF_VAR_ precisa ser utilizado.

$env:TF_VAR_master_rds_user = 'usuario root'
$env:TF_VAR_master_rds_user_password = 'senha super secreta'
$env:TF_VAR_wordpress_user = 'usuario wordpress'
$env:TF_VAR_wordpress_user_password = 'outra senha super secreta'
$env:TF_VAR_wordpress_database = 'exemplo'
$env:TF_VAR_bastion_key_name = 'bastion-key-pair'
$env:TF_VAR_web_server_key_name = 'web-server-key-pair'

export TF_VAR_master_rds_user = 'usuario root'
export TF_VAR_master_rds_user_password = 'senha super secreta'
export TF_VAR_wordpress_user = 'usuario wordpress'
export TF_VAR_wordpress_user_password= 'outra senha super secreta'
export TF_VAR_wordpress_database = 'exemplo'
export TF_VAR_bastion_key_name = 'bastion-key-pair'
export TF_VAR_web_server_key_name = 'web-server-key-pair'

Observação: Criando as as variáveis TF_VAR_bastion_key_name e TF_VAR_web_server_key_name com os valores acima o padrão "wordpress-lab" definido nas variáveis bastion_key_name e web_server_key_name serão substituidas com os valores bastion-key-pair e web-server-key-pair, respectivamente.

Se as variáveis citadas nas seções anterioes não forem criadas ao implantar a infra elas serão solicitadas conforme imagem abaixo:

A infraestrutura é provisionada a partir dos comandos a seguir:

• terraform init: Baixa os modulos e providers necessários para execução;
• terraform plan: Exibe plano de execução para criação, atualização e/ou remoção de recursos;
• terraform apply: Executa plano e altera os recursos conforme exibido no plan.

Os comandos terraform init e terraform appy são obrigatórios para criação da infraestrutura via terraform cli.

Executando o comando terraform apply -auto-approve a solicitação de aprovação não é exibida.

Importante: Executar este lab tem custo devido ao Nat Gateway.

Os valores entre colchetes utilizados nesta seção deverão ser substituidos em testes locais.

Quando a execução finalizar 4 outputs serão exibidos conforme imagem e tabela abaixo:

Observação: Não é interessante a exposição desses valores em ambientes produtivos, a variável sensitive = true pode ser adicionada ao output para ocultá-los.

O primeiro passo a ser executado após o provisionamento da infra é o acesso ao ALB, ele redirecionará a requisição para a url https://[alb_public_dns]/wp-admin/setup-config.php onde o wordpress pode ser configurado clicando em Let's go! conforme imagens abaixo.

Com a configuração feita corretamente a seguinte tela será exibida, solicitando que o conteúdo seja adicionado ao arquivo wp-config.php.

Para adicionar este conteúdo no arquivo wp-config.php o web server precisa ser acessado, porém, conforme mencionado anteriormente, a instância web não pode ser acessada publicamente, apenas por recursos em sua VPC, então o acesso será feito a partir do bastion.

Sem a chave privada de acesso o bastion também não conseguirá conectar ao servidor web, para que isso seja possível, a chave privada (.pem) do servidor deve ser copiada com o comando SCP.

scp -i [bastion_key_name].pem [web_server_key_name].pem ec2-user@[DNS bastion]:/home/ec2-user

Em casos de erro ao executar o SCP ou SSH as permissões da chave .pem devem ser revisadas e alteradas preferencialmente, a AWS exige a permissão 400, ela pode ser alterada com o comando chmod.

chmod 400 [bastion_key_name].pem
chmod 400 [web_server_key_name].pem

A instância bastion pode ser acessada utilizando SSH com a chave [bastion_key_name].pem criada no inicio do processo.

ssh -i [bastion_key_name].pem ec2-user@[bastion_ec2_public_address]

Conectado ao bastion o web server precisa ser acessado para que o arquivo wp-config.php seja criado.

ssh -i [bastion_key_name].pem ec2-user@[web_server_ec2_ip_address]

Importante: A permissão da key pair precisa ser alterada para 400 conforme mencionado anteriormente, caso contrário o bastion não conseguirá acessar o web server.

O arquivo wp-config.php pode ser criado com o comando vim.

sudo vim /var/www/html/wp-config.php

Com o arquivo criado, seu conteúdo deve ser adicionado, porém aperte i antes de colar para que o editor vim entre em modo de inserção. Para salvar o conteúdo adicionado a opção :x pode ser utilizada.

Após salvar o arquivo wp-config.php e acessar o endereço do ALB novamente a página de configuração do administrador do site será exibida.

Com os campos preenchidos a configuração o wordpress pode ser finalizada, este processo cria as tabelas no RDS para que as alterações feitas sejam armazenadas.

Feita a configuração e as tabelas criadas o site já pode ser acessado com o administrador conforme imagens abaixo.

Para validar a criação das tabelas o banco de dados pode ser acessado - do web server o bastion não possui acesso ao RDS - com o comando mysql.

mysql -u [master_rds_user] -h [db_endpoint] -p[master_rds_user_password]

A imagem abaixo exibe as tabelas do banco de dados wordpress a partir dos comandos show databases;, use wordpress; e show tables;.

É possível visualizar que o web server (10.0.0.177) foi acessado na saída do comando ip a.

O acesso ao bastion também é evidenciado devido a mensagem "Connection to ec2-34-229-116-196.compute-1.amazonaws.com closed.".

O comando terraform destroy -auto-approve deve ser executado para remover todos os recursos criados via terraform. A opção -auto-approve não é obrigatória, se ela não for adicionada ao comando destroy será solicitada aprovação, quando o comando finalizar a mensagem: "Destroy complete! Resources: X destroyed." será exibida, onde X é o número de recursos criados pelo terraform apply.

O ambiente web é provisionado via shell script, no arquivo wordpress.sh todos os passos para instalação do wordpress e suas dependências como: apache web server, php7, mysql client estão declarados.

A propriedade user_data do web-server.tf foi utilizada para executar o script na inicialização da instância, então sempre que uma nova instância for criada as configurações iniciais do wordpress estarão preparadas.

Analisando o arquivo cloud-init-output.log é possível listar os logs da execução de scripts adicionados ao user_data para troubleshooting.

sudo cat /var/log/cloud-init-output.log

É importante frisar que este é um estudo de caso, em um ambiente produtivo onde o provisionamento de outras máquinas é feito com auto scaling o ideal seria criar uma AMI com o ambiente configurado lendo as configurações do wordpress de variáveis de ambiente.