Validating the NFS provisioner using WordPress and MySQL
A sample playbook has been provided to show how to use the NFS provioner for perstent storage for a WordPress and MySQL deployment.
Prerequisites
- Install the
kubectl
binary on your Ansible box - Install the UCP Client bundle for the
admin
user - Confirm that you can connect to the cluster by running a test command, for example,
kubectl get nodes
- Deploy the NFS provisioner as outlined in the preceeding section. The article assumes that the NFS configuration is the same as used in that section, namely:
Variable | Value |
---|---|
nfs_provisioner_namespace | nfsstorage |
nfs_provisioner_role | nfs-provisioner-runner |
nfs_provisioner_serviceaccount | nfs-provisioner |
nfs_provisioner_name | hpe.com/nfs |
nfs_provisioner_storage_class_name | nfs |
nfs_provisioner_server_ip | hpe2-nfs.am2.cloudra.local |
nfs_provisioner_server_share | /k8s |
Running the playbook
The playbook test/playbooks/wordpress-mysql-nfs.yml
creates Persistent Volume Claims for both Wordpress
and MySQL
, deploys both applications and makes the WordPress
UI available via a NodePort.
# cd ~/Docker-SimpliVity
# ansible-playbook -i vm_hosts ./test/playbooks/wordpress-mysql-nfs.yml --vault-password-file .vault_pass
The output shows the components created along with the NodePort for the wordpress
service.
ok: [localhost] => {
"ps.stdout_lines": [
"Cluster \"ucp_hpe2-ucp01.am2.cloudra.local:6443_admin\" set.",
"User \"ucp_hpe2-ucp01.am2.cloudra.local:6443_admin\" set.",
"Context \"ucp_hpe2-ucp01.am2.cloudra.local:6443_admin\" modified.",
"namespace/wordpress-mysql created",
"secret/mysql-pass created",
"persistentvolumeclaim/mysql-pv-claim created",
"persistentvolumeclaim/wp-pv-claim created",
"deployment.apps/wordpress-mysql created",
"deployment.apps/wordpress created",
"service/wordpress-mysql created",
"service/wordpress created",
"NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE",
"wordpress NodePort 10.96.216.103 <none> 80:33790/TCP 0s",
"wordpress-mysql ClusterIP None <none> 3306/TCP 0s"
]
Browse to the specified port on any node in your cluster.
http://hpe2-ucp01.am2.cloudra.local:33790
Configuring WordPress
You need to configure the language and password before WordPress is ready to use.
Figure. Configure WordPress language
Add a username, password and other configuration details.
Figure. Configure WordPress password
Log in to WordPress, with the user name and password you have just set up.
Figure. WordPress login
The welcome page is presented.
Figure. WordPress welcome
Create your first post
Click on Write your first blog post
and start creating some content. Add a blog title and then click Add Media
to upload an image to the Media Library and then Insert into post
. In this example, the image is a file named
380 with OmniStack.jpg
.
Figure. Create your first WordPress blog post
Click Publish
and then View post
to see your new blog post.
Figure. View your first post
Test persistence for WordPress
Find your WordPress Persistent Volume Claim (PVC)
# kubectl -n wordpress-mysql get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-pv-claim Bound pvc-d48880e3-2d58-11e9-adb2-0242ac110003 1Gi RWO nfs 1h
wp-pv-claim Bound pvc-d4bc101f-2d58-11e9-adb2-0242ac110003 20Gi RWO nfs 1h
Connect to the NFS VM and browse the /k8s
folder to find the volume for the WordPress claim wp-pv-claim
.
# ssh hpe2-nfs ls /k8s
wordpress-mysql-mysql-pv-claim-pvc-d48880e3-2d58-11e9-adb2-0242ac110003
wordpress-mysql-wp-pv-claim-pvc-d4bc101f-2d58-11e9-adb2-0242ac110003
Locate the wp-content
folder.
# ssh hpe2-nfs ls /k8s/wordpress-mysql-wp-pv-claim-pvc-d4bc101f-2d58-11e9-adb2-0242ac110003
index.php
license.txt
readme.html
wp-activate.php
wp-admin
wp-blog-header.php
wp-comments-post.php
wp-config.php
wp-config-sample.php
wp-content
wp-cron.php
wp-includes
wp-links-opml.php
wp-load.php
wp-login.php
wp-mail.php
wp-settings.php
wp-signup.php
wp-trackback.php
xmlrpc.php
Now find the image used in the blog post.
# ssh hpe2-nfs ls /k8s/wordpress-mysql-wp-pv-claim-pvc-d4bc101f-2d58-11e9-adb2-0242ac110003/wp-content/uploads/2019/02
380-with-OmniStack-100x100.jpg
380-with-OmniStack-150x150.jpg
380-with-OmniStack-300x150.jpg
380-with-OmniStack-768x384.jpg
380-with-OmniStack.jpg
Note that WordPress has created a number of variations of the original image, for different screen sizes.
Shutdown wordpress (leave MySQL running for now)
# kubectl -n wordpress-mysql delete -f /tmp/wordpress-mysql-nfs/wordpress-deployment.yml
deployment.apps "wordpress" deleted
Refresh the page in the browser to confirm that WordPress is indeed inaccessible.
Figure. Cannot connect to WordPress
Redeploy Wordpress
# kubectl -n wordpress-mysql apply -f /tmp/wordpress-mysql-nfs/wordpress-deployment.yml
deployment.apps/wordpress created
Refresh the page in the browser to confirm that WordPress is now accessible and that the image in the blog post has survived the shutdown.
Figure. View restored post
Test persistence in MySQL
A similar procedure can be performed for MySQL. While assets such as images, CSS files, etc are stored in the WordPress volume, information about users, posts, comments, tags, etc are stored in the MySQL database. It is possible to browse the tables in the database and identify the rows related to the blog post you created.
Shut down MySQL as follows:
# kubectl -n wordpress-mysql delete -f /tmp/wordpress-mysql-nfs/mysql-deployment.yml
deployment.apps "wordpress-mysql" deleted
Refresh the page for your blog post, and you will see that WordPress can no longer connect to the database:
Figure. Cannot connect to MySQL
Restore the MySQL deployment:
# ubectl -n wordpress-mysql apply -f /tmp/wordpress-mysql-nfs/mysql-deployment.yml
deployment.apps/wordpress-mysql created
Refresh the page in the browser to confirm that WordPress can now access the database and that the blog post has survived the database shutdown.
Figure. Check after MySQL restored