Como usar os discos permanentes com WordPress e MySQL

Neste tutorial, você aprenderá a configurar uma implantação do WordPress e de um banco de dados MySQL de réplica única no seu cluster. Discos persistentes são usados por ambos os aplicativos para armazenamento. Os dados são preservados pelos discos permanentes quando as instâncias dos aplicativos são reiniciadas ou quando os contêineres do aplicativo são reprogramados em um nó diferente no cluster de contêineres.

Contexto

O WordPress é uma ferramenta de blog que usa MySQL como banco de dados para armazenar artigos de blog e o sistema de arquivos local para armazenar itens, como imagens em uma postagem do blog ou extensões. Neste tutorial, são usadas as imagens de contêiner oficiais do MySQL e do WordPress a partir do Docker Hub.

Em geral, um sistema de arquivos de raiz do contêiner não é adequado para armazenar dados permanentes. Os contêineres executados no Kubernetes Engine normalmente são entidades descartáveis. O gerenciador do cluster poderá excluir, eliminar ou reprogramar quaisquer contêineres que se tornarem indisponíveis devido a uma falha de node ou outras causas. Caso isso ocorra, todos os dados salvos no sistema de arquivos de raiz de um contêiner são perdidos.

Usar discos permanentes permite o armazenamento de dados em aplicativos WordPress e MySQL fora dos próprios contêineres. Dessa forma, mesmo se o contêiner for excluído, os dados permanecem.

Neste tutorial, crie duas Implantações: uma para o MySQL e uma para o WordPress. Ambas executam apenas uma réplica única de cada pod.

Em seguida, crie dois serviços: um para estabelecer a comunicação do contêiner do WordPress com o do MySQL e outro para expor a implantação do WordPress na Internet em um endereço IP externo com um balanceador de carga.

Antes de começar

Siga estas etapas para ativar a Google Kubernetes Engine API:
  1. Acesse a página do Kubernetes Engine no Console do Google Cloud Platform.
  2. Crie ou selecione um projeto.
  3. Aguarde a ativação da API e dos serviços relacionados. Isso pode demorar alguns minutos.
  4. Verifique se o faturamento foi ativado no projeto do Google Cloud Platform.

    Saiba como ativar o faturamento

Instale as seguintes ferramentas de linha de comando usadas neste tutorial:

  • O gcloud é usado para criar e excluir clusters do Kubernetes Engine. O gcloud está incluído no Google Cloud SDK.
  • O kubectl é utilizado para gerenciar o Kubernetes, o sistema de orquestração de clusters utilizado pelo Kubernetes Engine. É possível instalar o kubectl usando o gcloud:
    gcloud components install kubectl

Definir padrões para a ferramenta de linha de comando gcloud

Para economizar tempo ao digitar o código do projeto e as opções de zona do Compute Engine na ferramenta de linha de comando gcloud, defina valores de configuração padrão executando os seguintes comandos:
gcloud config set project [PROJECT_ID]
gcloud config set compute/zone us-central1-b

Fazer o download de manifestos do aplicativo

Para este tutorial, crie os objetos do Kubernetes necessários usando arquivos do manifesto no formato YAML.

Essa abordagem é chamada de gerenciamento de objetos declarativo. Esses arquivos são fornecidos a você. Para fazer o download dos arquivos do manifesto no repositório do GitHub, execute os seguintes comandos em um terminal:

git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
cd kubernetes-engine-samples/wordpress-persistent-disks

Se o git não está instalado no sistema, faça o download dele nestes links:

Etapa 1: criar um cluster do Kubernetes Engine

A primeira etapa é criar um cluster do Kubernetes Engine para hospedar os contêineres de aplicativos do WordPress e do MySQL. O comando a seguir cria um cluster chamado persistent-disk-tutorial com três nodes:

gcloud container clusters create persistent-disk-tutorial --num-nodes=3

Etapa 2: criar discos permanentes

Neste tutorial, são usados discos permanentes, permitindo a preservação do armazenamento do aplicativo quando os pods são reiniciados ou reprogramados em outros nodes devido a falhas no aplicativo ou reinicializações de nodes.

Nesse exemplo, você precisa de dois discos, um para que os dados sejam armazenados pelo banco de dados do MySQL e outro para que os itens do WordPress sejam armazenados no sistema de arquivos. Para criar discos permanentes, execute:

gcloud compute disks create --size 200GB mysql-disk
gcloud compute disks create --size 200GB wordpress-disk

Etapa 3: configurar o MySQL

Implantar o MySQL

A primeira etapa para implantar o MySQL é criar um Segredo Kubernetes para armazenar a senha do banco de dados. Para criar uma Chave secreta chamada mysql, execute o seguinte comando, substituindo YOUR_PASSWORD por uma senha longa de sua escolha:

kubectl create secret generic mysql --from-literal=password=YOUR_PASSWORD

Em seguida, use o arquivo do manifesto mysql.yaml para implantar o aplicativo do MySQL de instância única em execução na porta 3306. O arquivo mysql.yaml tem a seguinte aparência:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  replicas: 1
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
        - image: mysql:5.6
          name: mysql
          env:
            - name: MYSQL_ROOT_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: mysql
                  key: password
          ports:
            - containerPort: 3306
              name: mysql
          volumeMounts:
            - name: mysql-persistent-storage
              mountPath: /var/lib/mysql
      volumes:
        - name: mysql-persistent-storage
          gcePersistentDisk:
            pdName: mysql-disk
            fsType: ext4

Nesse manifesto, é descrita uma Implantação com um pod do MySQL de instância única, que terá a variável de ambiente MYSQL_ROOT_PASSWORD, cujos valores são definidos a partir do segredo criado. O disco permanente montado em /var/lib/mysql é usado pelo contêiner do MySQL.

Para implantar esse arquivo do manifesto, execute:

kubectl create -f mysql.yaml

Confirme se o pod está em execução. Pode demorar alguns minutos para que o pod passe para o status Running, uma vez que a conexão do disco permanente ao node de cálculo demora um pouco:

$ kubectl get pod -l app=mysql
NAME                 READY     STATUS    RESTARTS   AGE
mysql-259040-flmqh   1/1       Running   0          3m

Criar o serviço MySQL

A próxima etapa é criar um Serviço para publicar o contêiner do MySQL e torná-lo acessível a partir do contêiner wordpress que você criará.

Use o manifesto do Serviço definido em mysql-service.yaml, que tem a seguinte aparência:

apiVersion: v1
kind: Service
metadata:
  name: mysql
  labels:
    app: mysql
spec:
  type: ClusterIP
  ports:
    - port: 3306
  selector:
    app: mysql

Nesse manifesto, é descrito um serviço que cria um IP de cluster na porta 3306 para os pods correspondentes ao marcador app: mysql. O contêiner mysql implantado na etapa anterior tem esse marcador. Nesse caso, use type:ClusterIP para o Serviço, já que esse valor faz com que ele possa ser acessado apenas de dentro do cluster.

O IP do cluster criado direciona o tráfego para o contêiner do MySQL de todos os nodes de cálculo no cluster e não pode ser acessado por clientes fora do cluster. Depois que o Serviço é criado, o mesmo nome DNS do contêiner mysql é usado pelo contêiner wordpress para comunicação, mesmo que eles não estejam no mesmo node de cálculo.

Para implantar esse arquivo do manifesto, execute:

kubectl create -f mysql-service.yaml

Confirme se o Serviço foi criado:

$ kubectl get service mysql
NAME      CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
mysql     10.51.240.175   <none>        3306/TCP   4m

Você concluiu a configuração do banco de dados do seu novo blog do WordPress!

Etapa 4: configurar o WordPress

Implantar o WordPress

A próxima etapa é implantar o contêiner do WordPress no cluster de contêineres. Use o arquivo do manifesto wordpress.yaml para implantar um contêiner do WordPress de instância única.

O wordpress.yaml tem a seguinte aparência:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: wordpress
  labels:
    app: wordpress
spec:
  replicas: 1
  selector:
    matchLabels:
      app: wordpress
  template:
    metadata:
      labels:
        app: wordpress
    spec:
      containers:
        - image: wordpress
          name: wordpress
          env:
          - name: WORDPRESS_DB_HOST
            value: mysql:3306
          - name: WORDPRESS_DB_PASSWORD
            valueFrom:
              secretKeyRef:
                name: mysql
                key: password
          ports:
            - containerPort: 80
              name: wordpress
          volumeMounts:
            - name: wordpress-persistent-storage
              mountPath: /var/www/html
      volumes:
        - name: wordpress-persistent-storage
          gcePersistentDisk:
            pdName: wordpress-disk
            fsType: ext4

Nesse manifesto, é descrita uma Implantação com um pod do WordPress de instância única. A variável de ambiente WORDPRESS_DB_PASSWORD é lida por esse contêiner a partir do Segredo de senha do banco de dados criado anteriormente.

O contêiner do WordPress também é configurado por esse manifesto para estabelecer a comunicação entre o MySQL e o endereço de host mysql:3306. Esse valor é definido na variável de ambiente WORDPRESS_DB_HOST. Podemos nos referir ao banco de dados como mysql, porque o DNS do Kubernetes permite que um Serviço seja comunicado pelo nome dele pelos pods.

Para implantar esse arquivo do manifesto, execute:

kubectl create -f wordpress.yaml

Confirme se o pod está em execução. Pode demorar alguns minutos para que o pod passe para o status Running, uma vez que a conexão do disco permanente ao node de cálculo demora um pouco:

$ kubectl get pod -l app=wordpress
NAME                     READY     STATUS    RESTARTS   AGE
wordpress-387015-02xxb   1/1       Running   0          9h

Publicar o Serviço do WordPress

Na etapa anterior, você implantou um contêiner do WordPress que não pode ser acessado de fora do cluster porque ele não tem um endereço IP externo.

Para publicar o aplicativo do WordPress na Internet usando um balanceador de carga, que está sujeito a faturamento, você precisa de um Serviço com type:LoadBalancer.

O arquivo wordpress-service.yaml que contém o manifesto para esse Serviço tem a seguinte aparência:

apiVersion: v1
kind: Service
metadata:
  labels:
    app: wordpress
  name: wordpress
spec:
  type: LoadBalancer
  ports:
    - port: 80
      targetPort: 80
      protocol: TCP
  selector:
    app: wordpress

Para implantar esse arquivo do manifesto, execute:

kubectl create -f wordpress-service.yaml

A implantação do manifesto cria um balanceador de carga, o que pode demorar alguns minutos. Execute o seguinte comando para saber qual é o endereço IP externo do blog:

$ kubectl get svc -l app=wordpress
NAME        CLUSTER-IP      EXTERNAL-IP    PORT(S)        AGE
wordpress   10.51.243.233   203.0.113.3    80:32418/TCP   1m

Na saída acima, o endereço IP público criado para o blog é mostrado na coluna EXTERNAL-IP. Salve o endereço IP para a próxima etapa.

Você concluiu a implantação e a publicação do seu blog do WordPress!

Etapa 5: visitar o novo blog do WordPress

Depois de saber qual é o endereço IP do blog, direcione o navegador para ele e veja a tela de instalação do WordPress:

Captura da tela de instalação do WordPress

Depois de concluir a configuração do WordPress, direcione o navegador para o endereço IP do aplicativo do WordPress novamente para visitar o blog. Tudo funciona como esperado.

Etapa 6: testar a permanência de dados em caso de falha (Opcional)

Com discos permanentes, os dados ficam fora do contêiner do aplicativo. Quando o contêiner fica indisponível e é reprogramado em outra instância de cálculo pelo Kubernetes, o disco permanente é disponibilizado pelo Kubernetes Engine na instância que iniciou a execução do pod.

$ kubectl get pods -o=wide
NAME                   ...  IP          NODE
mysql-259040-flmqh     ...  10.48.2.8   gke-persistent-disk-tutorial-default-pool-fe4fe9af-wcb4
wordpress-387483-02xxb ...  10.48.2.7   gke-persistent-disk-tutorial-default-pool-fe4fe9af-wcb4

Agora, exclua o pod mysql. Basta executar:

kubectl delete pod -l app=mysql

Depois que o Pod mysql é excluído, o controlador da Implantação nota essa ausência do Pod e o recria. Provavelmente o novo Pod mysql será iniciado em um nó diferente daquele em que era executado.

Execute o seguinte comando para ver se o Pod mysql está programado em uma instância de cálculo diferente da anterior. Caso contrário, exclua o Pod novamente até que ele seja executado em outro local.

$ kubectl get pods -o=wide
NAME                   ...  IP          NODE
mysql-259040-flmqh     ...  10.48.2.8   gke-persistent-disk-tutorial-default-pool-fe4fe9af-vg56
wordpress-387483-02xxb ...  10.48.2.7   gke-persistent-disk-tutorial-default-pool-fe4fe9af-wcb4

Visite o blog novamente para ver se o website está funcionando adequadamente, se os dados permanecem mesmo depois de você ter excluído o Pod e se o Pod está programado para outra instância no cluster.

Etapa 7: como atualizar as imagens do aplicativo

É importante manter atualizado o software implantado. Por exemplo, vulnerabilidades podem ser informadas no WordPress, exigindo uma atualização. Para atualizar o contêiner de imagens do WordPress, procure a nova versão da imagem no Docker Hub e atualize o valor da imagem no arquivo wordpress.yaml. Para aplicar a atualização, execute:

kubectl apply -f wordpress.yaml

Limpeza

Para evitar cobranças dos recursos usados neste tutorial na conta do Google Cloud Platform, siga esta recomendação.

Após concluir o tutorial, siga estas etapas para remover os seguintes recursos e evitar cobranças indesejadas na sua conta:

  1. Exclua o serviço: nessa etapa, o balanceador de carga da nuvem criado para o Serviço wordpress é desalocado:

    kubectl delete service wordpress
    
  2. Aguarde até que o balanceador de carga fornecido para o serviço wordpress seja excluído: o balanceador de carga é excluído de maneira assíncrona em segundo plano quando você executa o kubectl delete. Aguarde até que o balanceador de carga seja excluído observando a saída do seguinte comando:

    gcloud compute forwarding-rules list
    
  3. Exclua o cluster de contêineres: nessa etapa, os recursos que compõem o cluster de contêineres, como instâncias de cálculo, discos e recursos de rede, são excluídos.

    gcloud container clusters delete persistent-disk-tutorial
    
  4. Exclua os discos permanentes: nessa etapa, os discos criados pelos aplicativos WordPress e MySQL são excluídos.

    gcloud compute disks delete mysql-disk wordpress-disk
    

Próximas etapas

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…

Documentação do Kubernetes Engine