Deploying WordPress on GKE with Persistent Disks and Cloud SQL

This tutorial shows you how to set up a single-replica WordPress deployment on Google Kubernetes Engine (GKE) using a MySQL database. Instead of installing MySQL, you use Cloud SQL, which provides a managed version of MySQL. WordPress uses PersistentVolumes (PV) and PersistentVolumeClaims (PVC) to store data.

A PV is a representation of storage volume in the cluster that is provisioned by an admin, or dynamically provisioned by Kubernetes, to fulfill a request made in a PVC. A PVC is a request for storage of a certain storage class by a user that can be fulfilled by a PV. PVs and PVCs are independent from pod lifecycles and preserve data through restarting, rescheduling, and even deleting pods. WordPress uses Google Persistent Disk as storage to back the PVs.

Background

WordPress is a blogging tool that uses a relational database to store the blog articles and their related objects and metadata, and the local file system to store assets, such as pictures in a blog post. This tutorial uses the official WordPress Docker image from Docker Hub.

In general, a container's root file system isn't suitable to store persistent data. The containers you run on GKE are typically disposable entities, and the cluster manager can delete, evict, or reschedule any containers that become unavailable due to node failures or other causes. When nodes fail, all data saved to a container's root file system is lost.

Using PVs backed by Persistent Disk let you store your WordPress platform data outside the containers. This way, even if the containers are deleted, their data persists. With the default storage class, your Persistent Disk (and hence your data) doesn't move with your pod if it's rescheduled to another node. There are different ways to handle moving the data, but that's outside the scope of this tutorial. For more information, see Persistent volumes with Persistent Disk.

WordPress requires a PV to store data. For this tutorial, you use the default storage class to dynamically create Google Persistent Disk and create a PVC for the deployment.

Objectives

  • Create a GKE cluster.
  • Create a PV and a PVC backed by Persistent Disk.
  • Create a Cloud SQL for MySQL instance.
  • Deploy WordPress.
  • Set up your WordPress blog.

Costs

This tutorial uses the following billable components of Google Cloud Platform:

To generate a cost estimate based on your projected usage, use the pricing calculator. New GCP users might be eligible for a free trial.

When you finish this tutorial, you can avoid continued billing by deleting the resources you created. For more information, see Cleaning up.

Before you begin

  1. Sign in to your Google Account.

    If you don't already have one, sign up for a new account.

  2. Select or create a GCP project.

    Go to the project selector page

  3. Verifica che la fatturazione sia attivata per il tuo progetto.

    scopri come attivare la fatturazione

  4. In the Google Cloud Platform Console, go to Cloud Shell.

    Go to Cloud Shell

    At the bottom of the GCP Console, a Cloud Shell session opens and displays a command-line prompt. Cloud Shell is a shell environment with the Cloud SDK already installed, including the gcloud command-line tool, and with values already set for your current project. It can take a few seconds for the session to initialize.

  5. In Cloud Shell, enable the GKE and Cloud SQL Admin APIs:
    gcloud services enable container.googleapis.com sqladmin.googleapis.com
    

Setting up your environment

  1. In Cloud Shell, set the default zone for the gcloud command-line tool:

    gcloud config set compute/zone zone
    

    Replace the following:

  2. Download the app manifest files from the GitHub repository:

    git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
    
  3. Change to the directory with the wordpress-persistent-disks file:

    cd kubernetes-engine-samples/wordpress-persistent-disks
    
  4. Set the WORKING_DIR environment variable:

    WORKING_DIR=$(pwd)
    

    For this tutorial, you create Kubernetes objects using manifest files in YAML format.

Creating a GKE cluster

You create a GKE cluster to host your WordPress app container.

  • In Cloud Shell, create a cluster named persistent-disk-tutorial that has three nodes:

    CLUSTER_NAME=persistent-disk-tutorial
    gcloud container clusters create $CLUSTER_NAME \
        --num-nodes=3 --enable-autoupgrade --no-enable-basic-auth \
        --no-issue-client-certificate --enable-ip-alias --metadata \
        disable-legacy-endpoints=true
    

Creating a PV and a PVC backed by Persistent Disk

To create the storage required for WordPress, you need to create a PVC. GKE has a default StorageClass resource installed that lets you dynamically provision PVs backed by Persistent Disk. You use the wordpress-volumeclaim.yaml file to create the PVCs required for the deployment.

This manifest file describes a PVC that requests 200 GB of storage. A StorageClass resource hasn't been defined in the file, so this PVC uses the default StorageClass resource to provision a PV backed by Persistent Disk.

  1. In Cloud Shell, deploy the manifest file:

    kubectl apply -f $WORKING_DIR/wordpress-volumeclaim.yaml
    

    It can take up to ten seconds to provision the PV backed by Persistent Disk and to bind it to your PVC.

    When that process is complete, the output is similar to the following:

    NAME                    STATUS    VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
    wordpress-volumeclaim   Bound     pvc-89d49350-3c44-11e8-80a6-42010a800002   200G       RWO            standard       5s
    

Creating a Cloud SQL for MySQL instance

  1. In Cloud Shell, create an instance named mysql-wordpress-instance:

    INSTANCE_NAME=mysql-wordpress-instance
    gcloud sql instances create $INSTANCE_NAME
    
  2. Add the instance connection name as an environment variable:

    export INSTANCE_CONNECTION_NAME=$(gcloud sql instances describe $INSTANCE_NAME \
        --format='value(connectionName)')
    
  3. Create a database user called wordpress and a password for WordPress to authenticate to the instance:

    CLOUD_SQL_PASSWORD=$(openssl rand -base64 18)
    gcloud sql users create wordpress --host=% --instance $INSTANCE_NAME \
        --password $CLOUD_SQL_PASSWORD
    

    If you close your Cloud Shell session, you lose the password. Make a note of the password because you need it later in the tutorial.

You have completed setting up the database for your new WordPress blog.

Deploying WordPress

Before you can deploy WordPress, you need to create a service account. You create a Kubernetes secret to hold the service account credentials and another secret to hold the database credentials.

Configure a service account and create secrets

  1. To allow your WordPress app to access the MySQL instance through a Cloud SQL proxy, create a service account:

    SA_NAME=cloudsql-proxy
    gcloud iam service-accounts create $SA_NAME --display-name $SA_NAME
    
  2. Add the service account email address as an environment variable:

    SA_EMAIL=$(gcloud iam service-accounts list \
        --filter=displayName:$SA_NAME \
        --format='value(email)')
    
  3. Add the cloudsql.client role to your service account:

    gcloud projects add-iam-policy-binding $DEVSHELL_PROJECT_ID \
        --role roles/cloudsql.client \
        --member serviceAccount:$SA_EMAIL
    
  4. Create a key for the service account:

    gcloud iam service-accounts keys create $WORKING_DIR/key.json \
        --iam-account $SA_EMAIL
    

    This command downloads a copy of the key.json file.

  5. Create a Kubernetes secret for the MySQL credentials:

    kubectl create secret generic cloudsql-db-credentials \
        --from-literal username=wordpress \
        --from-literal password=$CLOUD_SQL_PASSWORD
    
  6. Create a Kubernetes secret for the service account credentials:

    kubectl create secret generic cloudsql-instance-credentials \
        --from-file $WORKING_DIR/key.json
    

Deploy WordPress

The next step is to deploy your WordPress container in the GKE cluster.

The wordpress_cloudsql.yaml manifest file describes a deployment that creates a single pod running a container with a WordPress instance. This container reads the WORDPRESS_DB_PASSWORD environment variable that contains the cloudsql-db-credentials secret you created.

This manifest file also configures the WordPress container to communicate with MySQL through the Cloud SQL proxy running in the sidecar container. The host address value is set on the WORDPRESS_DB_HOST environment variable.

  1. Prepare the deployment file by replacing environment variables:

    cat $WORKING_DIR/wordpress_cloudsql.yaml.template | envsubst > \
        $WORKING_DIR/wordpress_cloudsql.yaml
    
  2. Deploy the wordpress_cloudsql.yaml manifest file:

    kubectl create -f $WORKING_DIR/wordpress_cloudsql.yaml
    

    It takes a few minutes to deploy this manifest file while Persistent Disk are attached to the compute node.

  3. Watch the deployment to see the status change to running:

    kubectl get pod -l app=wordpress --watch
    

    When the output shows the following status, you can move on to the next step.

    NAME                     READY     STATUS    RESTARTS   AGE
    wordpress-387015-02xxb   2/2       Running   0          9h
    

Expose the WordPress service

In the previous step, you deployed a WordPress container, but it's currently not accessible from outside your cluster because it doesn't have an external IP address. You can expose your WordPress app to traffic from the internet by creating and configuring a load balancer.

  • Create a service of type:LoadBalancer: kubectl create -f $WORKING_DIR/wordpress-service.yaml It takes a few minutes to create a load balancer.
  1. Watch the deployment and wait for the service to have an external IP address assigned:

    kubectl get svc -l app=wordpress --watch
    

    When the output shows an external IP address, you can proceed to the next step:

    NAME        CLUSTER-IP      EXTERNAL-IP    PORT(S)        AGE
    wordpress   10.51.243.233   203.0.113.3    80:32418/TCP   1m
    

    Make a note of the IP address because you need it later.

Setting up your WordPress blog

In this section, you set up your WordPress blog.

  1. In your browser, go to the following URL:

    http://external-ip-address
    

    Replace the following:

    • external-ip-address: the external IP address of the service that exposes your WordPress instance.
  2. On the WordPress installation page, select a language, and then click Continue.

  3. Complete the Information needed page, and then click Install WordPress.

  4. Click Log In.

  5. Enter the username and password that you previously created.

  6. You now have a blog site. To visit your blog, in your browser, go to the following URL:

    http://external-ip-address
    

Cleaning up

To avoid incurring charges to your Google Cloud Platform account for the resources used in this tutorial:

Delete the project

  1. In the GCP Console, go to the Manage resources page.

    Go to the Manage resources page

  2. In the project list, select the project you want to delete and click Delete .
  3. In the dialog, type the project ID, and then click Shut down to delete the project.

Delete the individual resources

If you used an existing project and you don't want to delete it, delete the individual resources.

  1. Delete the service:

    kubectl delete service wordpress
    

    Wait for the load balancer provisioned for the wordpress service to be deleted. The load balancer is deleted asynchronously in the background

    Watch the deletion process:

    watch gcloud compute forwarding-rules list
    

    The load balancer is deleted when you see the following output:

    Listed 0 items.
    
  2. Delete the deployment:

    kubectl delete deployment wordpress
    
  3. Delete the PVC for WordPress:

    kubectl delete pvc wordpress-volumeclaim
    

    This command also automatically deletes the PV and Persistent Disk.

  4. Delete the GKE cluster:

    gcloud container clusters delete $CLUSTER_NAME
    
  5. Delete the Cloud SQL instance:

    gcloud sql instances delete $INSTANCE_NAME
    
  6. Remove the role from the service account:

    gcloud projects remove-iam-policy-binding $DEVSHELL_PROJECT_ID \
        --role roles/cloudsql.client \
        --member serviceAccount:$SA_EMAIL
    
  7. Delete the service account:

    gcloud iam service-accounts delete $SA_EMAIL
    

What's next

Hai trovato utile questa pagina? Facci sapere cosa ne pensi:

Invia feedback per...

Kubernetes Engine Tutorials