WordPress no Serviço Kubernetes do Azure

Este artigo descreve uma arquitetura baseada em contentores para alojar uma grande instalação WordPress intensiva em armazenamento no Azure. Os componentes-chave incluem Azure Front Door, Azure Kubernetes Service (AKS) e Azure NetApp Files.

Arquitetura

Descarregue um ficheiro Visio desta arquitetura.

Fluxo de dados

O seguinte fluxo de dados corresponde ao diagrama anterior:

1. Os utilizadores acedem ao site front-end através do Azure Front Door com o Firewall de Aplicações Web do Azure ativado.

2. Azure Front Door Premium liga-se à origem do balanceador de carga interno do AKS através de um serviço Azure Private Link que expõe o balanceador de carga interno. O balanceador de carga interno é um componente do AKS. O Azure Front Door recupera dados que não guardou em cache.

3. O balanceador de carga interno distribui o tráfego de entrada para um controlador de entrada dentro do AKS. Pode usar o controlador de entrada gerido NGINX com o complemento de encaminhamento de aplicações ou o Application Gateway for Containers como controlador de entrada.

4. O Azure Key Vault armazena segredos como palavras-passe de base de dados e certificados de Segurança da Camada de Transporte (TLS), incluindo as suas chaves privadas.

5. A aplicação WordPress utiliza um endpoint privado para aceder a uma instância de servidor flexível do Base de Dados do Azure para MySQL. O aplicativo WordPress recupera informações dinâmicas deste serviço de banco de dados gerenciado.

6. Todo o conteúdo estático está alojado no Azure NetApp Files. A solução utiliza o driver Trident Container Storage Interface (CSI) com o protocolo Network File System (NFS).

Componentes

• O AKS é um serviço Kubernetes gerido para implementar, gerir e escalar aplicações containerizadas. Nesta arquitetura, o AKS aloja os contentores do WordPress e fornece a plataforma de orquestração para alta disponibilidade e escalabilidade.

• Azure Managed Redis é um serviço gerido de armazenamento e cache de dados em memória. Nesta arquitetura, todos os pods partilham uma cache Azure Managed Redis. Os plugins de otimização de desempenho do WordPress usam esta cache para reduzir os tempos de resposta.

• Base de Dados do Azure para MySQL servidor flexível é um serviço de base de dados relacional gerido baseado no motor de base de dados MySQL de código aberto. Nesta arquitetura, esta base de dados armazena dados WordPress.

• Azure DDoS Protection é um serviço de segurança de rede que oferece funcionalidades de mitigação DDoS distribuídas melhoradas. A Proteção DDoS tem dois níveis: Proteção de Rede DDoS e Proteção IP DDoS. Nesta arquitetura, a Proteção DDoS defende contra ataques DDoS quando a combina com as melhores práticas de design de aplicações e a ativa na rede perimetral.

• Azure Front Door é uma rede de distribuição de conteúdos na cloud e um balanceador global de carga. Esta arquitetura requer o Azure Front Door Premium tier porque utiliza Azure Private Link para se ligar à origem através de um serviço Private Link que expõe o balanceador de carga interno. Nesta arquitetura, o Azure Front Door é o ponto de entrada público para a implementação do WordPress.

• Azure NetApp Files é uma solução de armazenamento gerida, intensiva em desempenho e sensível à latência. Nesta arquitetura, o Azure NetApp Files aloja o conteúdo do WordPress para que todos os pods possam aceder aos dados partilhados através de armazenamento de ficheiros de alto desempenho.

• Rede Virtual do Azure é um serviço de rede que liga recursos implementados entre si, à internet e a redes locais. Nessa arquitetura, as redes virtuais fornecem isolamento e segmentação.

• Key Vault é um serviço em nuvem que armazena e controla o acesso a segredos, certificados, chaves e palavras-passe. Nesta arquitetura, o Key Vault armazena segredos como credenciais de base de dados e certificados TLS que os pods recuperam em tempo de execução.

• Balanceador de Carga do Azure é um balanceador de carga de camada 4 que distribui o tráfego de entrada com base nas regras e nos resultados das sondas de saúde. Nesta arquitetura, um balanceador de carga interno situa-se atrás de um serviço Private Link, o que permite ao Azure Front Door Premium alcançar a origem de forma privada. O balanceador de carga interno então distribui o tráfego para os pods do controlador 'Ingress'.

• Azure Container Registry é um serviço gerido de registo de imagens de contentores. Nesta arquitetura, o Container Registry armazena as imagens dos contentores do WordPress e torna-as disponíveis para o cluster AKS através de um endpoint privado.

• Os NSGs (grupos de segurança de rede) são recursos de segurança que usam regras de segurança para permitir ou negar o tráfego de rede de entrada ou saída com base no endereço IP de origem ou destino, porta e protocolo. Nessa arquitetura, as regras NSG restringem o fluxo de tráfego entre os componentes do aplicativo nas sub-redes.

Alternativas

• Use um pod Redis auto-hospedado dentro do cluster AKS como cache em vez do serviço gerido Azure Managed Redis.

• Use uma solução autoalojada como Rook-Ceph storage em vez de uma solução de armazenamento gerido como a Azure NetApp Files. Uma solução de armazenamento auto-alojada aumenta a complexidade operacional e exige que a sua equipa gere diretamente a camada de armazenamento. Avalie se os custos operacionais são aceitáveis para a sua organização antes de optar por esta abordagem.

• Usa Azure Container Apps para alojar cargas de trabalho WordPress containerizadas em vez de AKS. Container Apps é um serviço de contêiner gerenciado sem servidor que se adapta a cenários mais simples ou de menor escala. Para implantações grandes, com uso intensivo de armazenamento e altamente personalizáveis, use o AKS.

Detalhes do cenário

Este cenário de exemplo funciona melhor para instalações grandes e com uso intensivo de armazenamento do WordPress. Este modelo de implementação escala para responder a picos de tráfego para o site.

Potenciais casos de utilização

• Blogs de alto tráfego que usam o WordPress como seu sistema de gerenciamento de conteúdo
• Sites de negócios ou e-commerce que usam WordPress

Considerações

Estas considerações implementam os pilares do Azure Well-Architected Framework, que é um conjunto de princípios orientadores que pode usar para melhorar a qualidade de uma carga de trabalho. Para obter mais informações, consulte Well-Architected Framework.

Fiabilidade

A confiabilidade ajuda a garantir que seu aplicativo possa cumprir os compromissos que você assume com seus clientes. Para obter mais informações, consulte Lista de verificação de revisão de design para confiabilidade.

Considere as seguintes recomendações ao implantar esta solução:

• Utilize pods no AKS (Kubernetes Service do Azure) e um balanceador de carga para distribuir o tráfego de entrada. Essa abordagem fornece alta disponibilidade mesmo se ocorrer uma falha no pod.

• Coloque todos os componentes de rede atrás do Azure Front Door. Esta abordagem proporciona resiliência contra problemas que podem perturbar o tráfego e afetar o acesso dos utilizadores.

• Ativar a cache no Azure Front Door. Quando a origem não está disponível, o Azure Front Door pode continuar a servir conteúdo em cache. O cache por si só não oferece uma solução completa de disponibilidade.

• Replicar o armazenamento Azure NetApp Files entre regiões emparelhadas para aumentar a disponibilidade. Para mais informações, veja replicação do Azure NetApp Files.

• Implemente opções de alta disponibilidade que respondam às suas necessidades para aumentar a disponibilidade do Base de Dados do Azure para MySQL.

• A arquitetura suporta implantação multirregional, replicação de dados e autoescalonamento. As sondas de saúde garantem que apenas cápsulas saudáveis recebam tráfego.

• Azure Front Door é um serviço global que pode encaminhar tráfego para origens em várias regiões.

Segurança

A segurança fornece garantias contra ataques deliberados e o uso indevido de seus valiosos dados e sistemas. Para obter mais informações, consulte Lista de verificação de revisão de design para segurança.

Considere as seguintes práticas recomendadas ao implantar esta solução:

• Use o Firewall de Aplicações Web do Azure no Azure Front Door para ajudar a proteger o tráfego de rede virtual que flui para a camada de aplicações front-end. Para mais informações, consulte Firewall de Aplicações Web do Azure em Azure Front Door.

• Bloqueia o tráfego de saída da internet do nível da base de dados.

• Bloqueie o acesso público ao armazenamento privado e desligue o acesso público aos recursos. Utilize endpoints privados para a Base de Dados do Azure para MySQL, o Azure Managed Redis, o Cofre de Chaves e o Registo de Contêineres. Para mais informações, consulte Private Link.

Para mais informações, consulte dicas gerais de segurança e desempenho do WordPress e documentação de segurança do Azure.

Otimização de Custos

A Otimização de Custos concentra-se em formas de reduzir despesas desnecessárias e melhorar a eficiência operacional. Para obter mais informações, consulte Lista de verificação de revisão de projeto para Otimização de custos.

Analise as seguintes considerações de custo ao implantar esta solução:

• Expectativas de tráfego em GB por mês: O volume de tráfego tem o maior impacto no seu custo. O tráfego que recebes determina o número de nós AKS necessários e o preço da transferência de dados de saída. O volume de tráfego também está diretamente correlacionado com os dados que a sua rede de distribuição de conteúdos fornece, onde os custos de transferência de dados de saída são mais baixos.

• Dados alojados: Considere os dados que hospeda, porque os preços do Azure NetApp Files dependem da capacidade reservada. Para otimizar custos, reserve a capacidade mínima necessária para os seus dados.

• Percentagem de escrita: Considere a quantidade de novos dados que você escreve em seu site e o custo para armazená-los. Para implementações multirregionais, os novos dados que introduz no seu site correlacionam-se com os dados espelhados nas suas regiões.

• Conteúdo estático versus dinâmico: Monitorize o desempenho e a capacidade de armazenamento da sua base de dados para determinar se um SKU de menor custo suporta o seu site. O banco de dados armazena conteúdo dinâmico e a rede de entrega de conteúdo armazena em cache conteúdo estático.

• Otimização do cluster AKS: Siga orientações gerais para o AKS, como orientações sobre o tamanho da máquina virtual e reservas Azure, para otimizar os custos do seu cluster AKS. Para obter mais informações, consulte Otimização de custos do AKS.

Excelência Operacional

A Excelência Operacional abrange os processos operacionais que implantam um aplicativo e o mantêm em execução na produção. Para obter mais informações, consulte Lista de verificação de revisão de design para excelência operacional.

Considere as seguintes recomendações ao implantar esta solução:

• Ative a monitorização Kubernetes em Azure Monitor para o cluster AKS, incluindo métricas Managed Prometheus e registo de contentores. Configure alertas para a utilização de recursos de nós e pods para que possa responder a problemas antes que afetem os utilizadores.

• Armazene os seus manifestos Kubernetes, gráficos de Helm e infraestrutura como modelos de código (IaC) num sistema de controlo de versões. Utilize um pipeline de integração contínua e entrega contínua (CI/CD) para implementar alterações no seu cluster AKS, reduzindo erros manuais e garantindo implementações repetíveis.

• Utilize atualizações de imagem de nós do AKS e atualizações regulares de versões do Kubernetes para se manter atualizado com patches de segurança e correções de erros.

• Use Azure Policy para AKS para impor normas organizacionais em todos os seus clusters, como exigir registos privados ou restringir containers privilegiados.

Eficiência de desempenho

A Eficiência de Desempenho refere-se à capacidade da sua carga de trabalho de escalar para atender às demandas dos usuários de forma eficiente. Para obter mais informações, consulte Lista de verificação de revisão de projeto para eficiência de desempenho.

Este cenário usa pods no AKS para hospedar o front-end. A funcionalidade de autoescala permite que o número de pods que executam a camada de aplicação front-end escale automaticamente com base na procura do cliente. Os pods também podem escalar com base num horário. Para obter mais informações, consulte Opções de dimensionamento para aplicativos no AKS.

kind: PersistentVolume
...
    accessModes:
    - ReadWriteMany
    mountOptions:
    - vers=4.1
    nfs:
      server: xx.xx.xx.xx

Contribuidores

A Microsoft mantém este artigo. Os seguintes colaboradores escreveram este artigo.

Autor principal:

• Vaclav Jirovsky | Arquiteto de Soluções em Nuvem

Outros contribuidores:

• Adrian Calinescu - Brasil | Arquiteto de Soluções Cloud Sênior
• Andrew Cardy | Engenheiro de Software Sénior

Para ver perfis de LinkedIn não públicos, inicie sessão no LinkedIn.

Próximos passos

Documentação do produto:

• Visão Geral do Azure Front Door
• Visão geral do Firewall de Aplicações Web do Azure
• Azure NetApp Files visão geral
• Crie um volume NFS para Azure NetApp Files
• Configure Azure NetApp Files para AKS
• Banco de Dados do Azure para servidor flexível MySQL
• Visão geral da Rede Virtual
• Visão geral do Key Vault
• Visão geral do Balanceador de Carga
• Visão geral da Proteção contra DDoS

Módulos de formação da Microsoft:

• Desenvolver e implantar aplicativos no Kubernetes
• Introdução à Azure NetApp Files
• Implementar Key Vault
• Introdução ao Rede Virtual

Recursos relacionados

• princípios de design para aplicações Azure
• Aplicativos de nuvem escaláveis e engenharia de confiabilidade do local