How to run WordPress on Google Kubernetes Engine (GKE) Standard
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.
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.
Before you begin
- In the Google Cloud console, on the project selector page, select or create a Google Cloud project.
Note: If you don’t plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.Go to project selector - Make sure that billing is enabled for your Cloud project. Learn how to check if billing is enabled on a project.
- In the console, activate Cloud Shell.Activate Cloud ShellAt the bottom of the console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.
- In Cloud Shell, enable the GKE and Cloud SQL Admin APIs:gcloud services enable container.googleapis.com sqladmin.googleapis.com
Setting up your environment
- In Cloud Shell, set the default zone for the Google Cloud CLI:gcloud config set compute/zone zone Replace the following:
zone
: Choose a zone that’s closest to you. For more information, see Regions and Zones.
- Set the
PROJECT_ID
environment variable to your Google Cloud project ID
(project-id).export PROJECT_ID=project-id - Download the app manifest files from the GitHub repository:
git clone https://github.com/GoogleCloudPlatform/kubernetes-engine-samples
- Change to the directory with the
wordpress-persistent-disks
file:cd kubernetes-engine-samples/wordpress-persistent-disks
- 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
Note: Ensure that you have properly set the zone as explained in this earlier step. If the zone is not set,
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=truegcloud
will create a regional cluster. A regional cluster will create a node-pool of 3 nodes per zone within the default region for your project. This will result in a cluster with more nodes than a single zonal cluster, and possible quota issues.Creating a PV and a PVC backed by Persistent Disk
Create a PVC as the storage required for WordPress. 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.
- 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. You can check the status with the following command:kubectl get persistentvolumeclaim
When the process is complete, an output similar to the following displays:
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
- In Cloud Shell, create an instance named
mysql-wordpress-instance
:INSTANCE_NAME=mysql-wordpress-instance
gcloud sql instances create $INSTANCE_NAME - Add the instance connection name as an environment variable:
export INSTANCE_CONNECTION_NAME=$(gcloud sql instances describe $INSTANCE_NAME \
--format='value(connectionName)') - Create a database for WordPress to store its data:
gcloud sql databases create wordpress --instance $INSTANCE_NAME
- Create a database user called
wordpress
and a password for WordPress to authenticate to the instance:CLOUD_SQL_PASSWORD=$(openssl rand -base64 18)
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.
gcloud sql users create wordpress --host=% --instance $INSTANCE_NAME \
--password $CLOUD_SQL_PASSWORD
You have completed setting up the database for your new WordPress blog.
Deploying WordPress
Before you can deploy WordPress, you must 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
- To let your WordPress app 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 - Add the service account email address as an environment variable:
SA_EMAIL=$(gcloud iam service-accounts list \
--filter=displayName:$SA_NAME \
--format='value(email)') - Add the
cloudsql.client
role to your service account:gcloud projects add-iam-policy-binding $PROJECT_ID \
--role roles/cloudsql.client \
--member serviceAccount:$SA_EMAIL - Create a key for the service account:
gcloud iam service-accounts keys create $WORKING_DIR/key.json \
This command downloads a copy of the
--iam-account $SA_EMAILkey.json
file. - 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 - 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.
- Prepare the file by replacing the
INSTANCE_CONNECTION_NAME
environment variable:cat $WORKING_DIR/wordpress_cloudsql.yaml.template | envsubst > \
$WORKING_DIR/wordpress_cloudsql.yaml - 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 a Persistent Disk is attached to the compute node. - 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 Kubernetes Service with an attached external load balancer. To learn more about exposing apps using Services in GKE, see the how-to guide.
- Create a Service of
type:LoadBalancer
:kubectl create -f $WORKING_DIR/wordpress-service.yaml
It takes a few minutes to create a load balancer. - 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. Note that your external IP is different from the following example.
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
EXTERNAL_IP
address field to use later.
Warning: Don’t leave your WordPress installation with a load balancer that exposes the cluster. Other visitors can set up a website on your cluster and use it to serve potentially malicious content. Either continue with the installation steps or clean up this deployment.
Setting up your WordPress blog
In this section, you set up your WordPress blog.
- In your browser, go to the following URL, replacing external-ip-address with the
EXTERNAL_IP
address of the service that exposes your WordPress instance:
http://external-ip-address - On the WordPress installation page, select a language, and then click Continue.
- Complete the Information needed page, and then click Install WordPress.
- Click Log In.
- Enter the username and password that you previously created.
- You now have a blog site. To visit your blog, in your browser, go to the following URL:
http://external-ip-address
Reference: https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk
Hey people!!!!! Good mood and good luck to everyone!!!!!
Hi , do you have similar aws architecture decison flowchart or guide me where I can get in similar manner…
A cloud architecture is the most advanced and cutting-edge technology. The technique you described in this post, which includes reviewing…
Hi Tama, thanks for reading this article. Definitely the answer will be back to your decision, but here are some…
Hello Mr.Doddi! I've been read for your article since 2 years ago before i get into a collage. Then now…