Infraestrutura em CloudFormation para hospedagem de um blog Wordpress na AWS com ECS e Fargate
Esta publicação é resultado de um estudo de ferramentas para criação de blogs e hospedagem de websites, o qual foi motivado pela necessidade da criação de um endereço eletrônico para o time de Pesquisa Aplicada da Senior, o Senior Labs. Tal necessidade advém de algumas das demandas do Senior Labs, as quais requerem um website ou blog para a apresentação dos protótipos construídos pelo time, os quais precisam estar centralizados em um local virtual. Neste artigo serão abordadas as ferramentas e estratégias escolhidas para implementar esta solução por meio do WordPress e da Amazon Web Services.
O WordPress (WP) é um software do tipo Content Management System (CMS), o qual tem como propósito a criação e gerenciamento de conteúdos digitais, sendo utilizado por quase 40% de todos os sites da web (SOUTHERN, 2021). Tamanha popularidade deve-se ao fato de o WordPress ser um software open source, que recebe contribuições continuamente de diversos desenvolvedores, e por ter como missão a facilidade de uso, a segurança, a acessibilidade e a performance, visando a ideia de que seus usuários possam priorizar o conteúdo dos websites, minimizando a carga de trabalho com suas configurações. (WORDPRESS, 2021)
De maneira similar, a Amazon Web Services (AWS), provedora de serviços em nuvem, também suporta a ideia de minimizar a carga de trabalho de seus usuários com a configuração de ambientes, redes e alocação de memória, facilitando a implementação e desenvolvimento de aplicações. A AWS, assim como o WP, também é líder de uso em seu segmento. (AWS, 2021a)
Neste sentido, a criação do website do Senior Labs, e também o site de outros projetos de pesquisa, foi realizada utilizando o WordPress e foram hospedados na AWS, fazendo uso dos seguintes serviços:
- Elastic Container Service (ECS)
- Fargate
- Relational Database Service (RDS)
- Elastic File System (EFS)
- Elastic Load Balancer (ELB)
- Virtual Private Cloud (VPC)
- Route 53
- CloudFront
- CloudWatch
- CloudFormation
Arquitetura
Existem diferentes maneiras e serviços da AWS a serem utilizados para realizar a hospedagem do WordPress, conforme explorados por Aws (2021b) e Lightsail (2018), por exemplo, os quais fazem uso do Elastic Compute Cloud (EC2) e do Amazon Lightsail, respectivamente.
A Figura 1 apresenta a arquitetura utilizada para a hospedagem dos websites WordPress na AWS utilizando o ECS e o Fargate. Esta solução é implementada e descrita por Alvarez-Parmar e Hayes (2021) como uma arquitetura serverless, uma vez que o Fargate se responsabiliza pelas configurações e gerenciamento de containers, que são criados a partir do ECS. Assim, é possível utilizar uma imagem Docker (serviço de empacotamento de aplicações) do WordPress, com as configurações de Banco de Dados, Sistema de Arquivos e Load Balancer apontando para outros serviços da Amazon.
Fonte: Elaborado pela autora (2021)
Dessa forma, a aplicação do WordPress é empacotada em um container Docker e disponibilizada no bitnami como uma imagem (BITNAMI, 2021). Essa imagem é então utilizada como uma definição do container, na criação do ECS, bem como a configuração de regras do Load Balancer, do EFS e também do Banco de Dados Aurora MySQL Serverless, o qual foi construído como uma instância de um RDS. Todos esses serviços devem estar dentro da mesma região e rede, VPC, da AWS, para que a conexão entre eles seja possível. Por fim, a Figura 1 ilustra a conexão de um web browser ao WordPress, que foi viabilizada a partir do Amazon CloudFront, um serviço utilizado em conjunto com o Route 53 para redirecionar as requisições dos domínios para o endereço do Load Balancer.
A infraestrutura foi projetada utilizando arquivos yaml e o serviço CloudFormation, os quais facilitam a criação e manutenção de serviços, configurações e recursos na AWS. A página de
Referência de tipos de recurso e propriedade da AWS é muito útil para entender melhor o CloudFormation, como funciona, sua estrutura e organização.
Templates da infraestrutura
A seguir serão apresentados os templates de CloudFormation utilizados para a criação da arquitetura ilustrada na Figura 1. Para a realização das definições é necessário observar alguns requisitos:
- As credencicais de usuário e autenticação da AWS CLI devem estar configuradas no arquivo ~/.aws/credentials, conforme o tutorial de configuração do AWS CLI;
- Deve existir um cluster ECS Fargate (ambiente), uma VPC, e duas subnets já criados na AWS;
- É necessário que o VpcId seja exportado, bem como os dados das subnets, pois serão utilizados nos outros serviços;
- O nome da stack do ECS Fargate utilizado foi ecs-cluster-stack-name e das subnets foram PublicSubnetOne e PublicSubnetTwo, as quais foram exportadas com o prefixo do nome da stack do ECS Fargate.
Permissões
O primeiro arquivo é o wordpress-roles.yml, apresentado no Bloco 1, que define as permissões de acesso dos serviços na arquitetura. Neste arquivo foram criadas uma Role, denominada FargateAccessRole, que é uma identidade IAM com políticas de permissão que determinam o que a identidade pode e não pode fazer na AWS (AWS, 2021c) e uma Policy, que atua como uma configuração customizada e específica de acessos que permite, ou não, acesso de usuários e serviços à outros serviços.
Neste arquivo a Policy foi denominada FargateAccessPolice, realizando uma associação à Role, que foi criada anteriormente.
Load Balancer e Security Groups
O segundo arquivo criado, apresentado no Bloco 2, é o wordpress-loadbalancer.yml, o qual cria um Load Balancer para a aplicação. Neste arquivo é necessário especificar o nome da stack do ambiente, a qual teve seu parâmetro identificado como EnvironmentStackName e que seria o cluster ECS (já existente, conforme mencionado previamente nos requisitos do projeto).
É necessário criar um Security Group (SG) para o Load Balancer (LB), o qual atua como um firewall para a VPC, com configurações de permissão para a entrada e saída da rede. No caso do PublicLoadBalancerSG, o SG do Load Balancer, a configuração foi realizada de modo a permitir que qualquer endereço possa acessá-lo, isto porque o endereço do LB servirá como o endereço público da nossa aplicação (blog do WordPress). Isso significa que para acessar o blog será necessário inserir a URL do LB no navegador. Posteriormente será possível criar uma configuração de redirecionamento e roteirização de um outro domínio para o endereço do Load Balancer, utilizando os serviços Route 53 e CloudFront.
Neste arquivo do LB também é criado o SG para o container que será utilizado no ECS, permitindo a entrada (SecurityGroupIngress) do PublicLoadBalancerSG, a fim de garantir a conexão entre o LB e o container. Também é criado, no arquivo de Load Balancer, um Listener identificado como PublicLoadBalancerListener, o qual é responsável por verificar as solicitações de conexão ao LB, usando o protocolo e a porta configurados. As regras definidas para um listener determinam como o LB roteará as solicitações para seus destinos registrados. (AWS, 2021d)
No final deste arquivo são exportadas as referências do PublicLoadBalancerListener e do ContainerSecurityGroup, para que possam ser importados e utilizados em outros arquivos. A razão de o SG do container ser criado neste momento é que ele será utilizado na maioria dos próximos arquivos.
Sistema de arquivos
Após as definições da Role e da Policy, para determinar as permissões de acesso entre os serviços, e da criação do Load Balancer e Security Groups, para realizar o balanceamento de carga das requisições, é possível gerar o arquivo wordpress-efs.yml, cujo conteúdo está presente no Bloco 3. Este arquivo é responsável pela criação do Elastic File System (EFS), que é um serviço de arquivos, necessário na aplicação para persistir os arquivos criados e utilizados pelo WP. O EFS é um serviço serverless, o que permite o compartilhamento dos dados de arquivos sem provisionar ou gerenciar armazenamento (AWS, 2021e)
Os parâmetros do arquivo são o nome da stack do cluster ECS, EnvironmentStackName, e o nome da stack do LB, LoadBalancerStackName. Esses nomes de stack são criados no momento do deploy dos arquivos para a AWS, pela AWS CLI, como será explicado no final desta publicação.
O EFS foi criado e identificado como FileSystem. Também foi criado um SG para o EFS, identificado como EFSSecurityGroup, na VPC do ambiente (cluster ECS), permitindo a entrada/conexão do SG do container, que conterá o WP. Assim, o WP poderá persistir seus arquivos no EFS, de acordo com um path específico.
A referência do EFS criado é exportada na seção de outputs do arquivo, para ser utilizado no arquivo de criação do container, a fim de realizar as configurações do WP no EFS.
Banco de dados
O WordPress requer uma conexão com um Banco de Dados (BD) para que os dados criados no blog, como os posts e configurações de usuários, por exemplo, sejam salvos. A criação de um BD externo ao ECS em que o WP será hospedado é uma boa opção, pois caso seja necessário alterar as configurações definidas no container os dados do blog não serão perdidos. Dessa forma, foi realizada a criação do arquivo wordpress-rds.yml, conforme o Bloco 4, que gera um Banco de Dados a partir do serviço Relational Data Base (RDS) da AWS.
Neste arquivo são utilizados os parâmetros do nome da stack do ambiente e do LB, para permitir a conexão entre estes serviços, além do nome de usuário, senha e nome do banco de dados que serão criados: DBUsername, DBPassword e DBName, respectivamente.
É necessária a criação de um cluster RDS, o qual hospedará a instância do BD. Para isto é criado, em primeiro lugar, o SG do cluster RDS, identificado como DataBaseClusterSG e que terá permissão de acesso de entrada e saída do LB do container. O cluster RDS é criado e identificado como RDSCluster, nele são definidos os valores de nome de usuário, senha e nome do banco de dados (caso o DatabaseName não seja informado, não é criado nenhum DB, sendo necessária a criação de uma instância RDS).
O WP pode ser utilizado tanto com o MySQL quanto com o MariaDB. Como estamos optando por uma arquitetura serverless, o Banco de Dados utilizado para a aplicação foi o Aurora Serverless. Além da vantagem de possibilitar a utilização do MySQL, este Banco de Dados dispõe de uma configuração com escalabilidade automática sob demanda, permitindo que o serviço inicie, encerre e expanda a capacidade automaticamente, de acordo com a necessidade da aplicação, além de não necessitar de nenhum gerenciamento de capacidade (AWS, 2021f)
Como output, é exportado o endereço do banco de dados (host), para que seja possíver realizar a conexão nas configurações do ECS.
Container e serviço
Por último, e mais importante, é criado o arquivo wordpress-ecs-infrastructure.yml, presente nos Blocos de 5 a 8, nele estarão as configurações do blog WP. Para isto, é preciso especificar alguns parâmetros, como o nome da stack do ambiente (cluster ECS), o nome do serviço (que estará sendo executado dentro do ambiente ECS), o número da porta que o WP está vinculado dentro do container Docker, os valores de Cpu e Memória utilizados pelo serviço, um path para as requisições, a prioridade do serviço dentro do cluster (relacionado ao path), e os demais parâmetros utilizados já em outros arquivos.
É necessário criar um Access Point no EFS, que terá o diretório /wordpress como o root para a aplicação salvar seus arquivos.
O LogGroup é criado como um recurso que será utilizado para visualizar os logs do container no Amazon CloudWatch. Além disso é criada também uma TaskDefinition que conterá configurações do container, tais como as informações da imagem bitnami do WP utilizada e as configurações para conexão com o RDS Aurora Serverless, criado anteriormente. Também é realizada a associação do container com o Access Point do EFS, na seção de volumes.
Também é criado um Service, o qual é responsável por executar e manter um número específico de instâncias de uma TaskDefinition simultaneamente em um cluster ECS. Assim, se alguma das tarefas falhar, o service inicia outra instância da TaskDefinition para substituí-la, mantendo o número desejado de tarefas no serviço (AWS, 2021g)
É necessário também criar uma regra entre o ECS e o Load Balancer, que foi definida e identificada como LoadBalancerRule. Por fim, são exportados o arn e o nome do service.
Deploy e acesso ao blog
Após a criação dos 5 arquivos que geram todos os serviços e configurações necessárias para seu funcionamento, é preciso realizar o deploy para a AWS, de acordo com os comandos listados no Bloco 9, sendo que os nomes das stacks, arquivos e parâmetros podem ser alterados e customizados.
É possível acompanhar o deploy dos arquivos na AWS pela tela do CloudFormation. Após realizar o deploy de todos os arquivos com sucesso, o blog poderá ser acessado pelo endereço eletrônico do Load Balancer, que está disponível na Tela do LB, no serviço EC2. Caso tenha sido realizada a configuração do CloudFront e Route 53, o blog é acessado pela URL e domínio escolhidos.
Para acessar o painel do WordPress é necessário realizar o login, conforme a Figura 2, a partir da URL do Load Balancer (ou da URL customizada) seguida do path /wp-admin. As credenciais padrões da imagem do WP no bitnami são Username: user e Password: bitnami, os quais podem, e devem, ser alterados após o primeiro login.
Fonte: WORDPRESS (2021)
Referências:
ALVAREZ-PARMAR, Re; HAYES, Jimmy. Running WordPress on Amazon ECS on AWS Fargate with Amazon EFS. 2021. Disponível em: https://aws.amazon.com/blogs/containers/running-wordpress-amazon-ecs-fargate-ecs/. Acesso em: 25 jun. 2021.
AWS. Cloud computing with AWS. 2021a. Disponível em: https://aws.amazon.com/what-is-aws/. Acesso em: 25 jun. 2021.
AWS. Implante o WordPress com o Amazon RDS. 2021b. Disponível em: https://aws.amazon.com/pt/getting-started/hands-on/deploy-wordpress-with-amazon-rds/5/. Acesso em: 25 jun. 2021.
AWS. IAM roles. 2021c. Disponível em: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html. Acesso em: 25 jun. 2021.
AWS. Listeners for your Application Load Balancers. 2021d. Disponível em:https://docs.aws.amazon.com/elasticloadbalancing/latest/application/load-balancer-listeners.html. Acesso em: 25 jun. 2021.
AWS. Amazon Elastic File System. 2021e. Disponível em: https://aws.amazon.com/efs/. Acesso em: 25 jun. 2021.
AWS. Amazon Aurora Serverless. 2021f. Disponível em: https://aws.amazon.com/pt/rds/aurora/serverless/. Acesso em: 25 jun. 2021.
AWS. Amazon ECS services. 2021g. Disponível em: https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ecs_services.html. Acesso em: 25 jun. 2021.
BITNAMI. WordPress: stack. 2021. Disponível em: https://bitnami.com/stack/wordpress. Acesso em: 25 jun. 2021.
LIGHTSAIL, Amazon. Tutorial: Iniciar e configurar uma WordPress instância do no Amazon Lightsail. 2018. Disponível em: https://lightsail.aws.amazon.com/ls/docs/pt_br/articles/amazon-lightsail-tutorial-launching-and-configuring-wordpress. Acesso em: 25 jun. 2021.
SOUTHERN, Matt. WordPress Powers 39.5% of All Websites. 2021. Disponível em: https://www.searchenginejournal.com/wordpress-powers-39-5-of-all-websites/391647/. Acesso em: 25 jun. 2021.
WORDPRESS. WordPress: Democratize Publishing. 2021. Disponível em: https://wordpress.org/about/. Acesso em: 25 jun. 2021.
