Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix wordpress tutorial pvcs #6418

Merged
merged 1 commit into from
Jan 4, 2018
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -7,7 +7,7 @@ approvers:
{% capture overview %}
This tutorial shows you how to deploy a WordPress site and a MySQL database using Minikube. Both applications use PersistentVolumes and PersistentVolumeClaims to store data.

A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been provisioned by an administrator, and a [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a set amount of storage in a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods.
A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes). A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods.

**Warning:** This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) to deploy WordPress in production.
{: .warning}
Expand All @@ -18,7 +18,7 @@ A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece
{% endcapture %}

{% capture objectives %}
* Create a PersistentVolume
* Create PersistentVolumeClaims and PersistentVolumes
* Create a Secret
* Deploy MySQL
* Deploy WordPress
Expand All @@ -32,8 +32,6 @@ A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece

Download the following configuration files:

1. [local-volumes.yaml](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/local-volumes.yaml)

1. [mysql-deployment.yaml](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/mysql-deployment.yaml)

1. [wordpress-deployment.yaml](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/wordpress-deployment.yaml)
Expand All @@ -42,38 +40,22 @@ Download the following configuration files:

{% capture lessoncontent %}

## Create a PersistentVolume

MySQL and Wordpress each use a PersistentVolume to store data. While Kubernetes supports many different [types of PersistentVolumes](/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes), this tutorial covers [hostPath](/docs/concepts/storage/volumes/#hostpath).
## Create PersistentVolumeClaims and PersistentVolumes

**Note:** If you have a Kubernetes cluster running on Google Kubernetes Engine, please follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk).
{: .note}
MySQL and Wordpress each require a PersistentVolume to store data. Their PersistentVolumeClaims will be created at the deployment step.

### Setting up a hostPath Volume
Many cluster environments have a default StorageClass installed. When a StorageClass is not specified in the PersistentVolumeClaim, the cluster's default StorageClass is used instead.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

quick link or note on "how to not use default storage class"? It's not always clear that in order to stop dynamic provisioning sometimes you have to make the SC=""

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is explained in detail in the PVC page.


A `hostPath` mounts a file or directory from the host node’s filesystem into your Pod.
When a PersistentVolumeClaim is created, a PersistentVolume is dynamically provisioned based on the StorageClass configuration.

**Warning:** Only use `hostPath` for developing and testing. With hostPath, your data lives on the node the Pod is scheduled onto and does not move between nodes. If a Pod dies and gets scheduled to another node in the cluster, the data is lost.
**Warning:** In local clusters, the default StorageClass uses the `hostPath` provisioner. `hostPath` volumes are only suitable for development and testing. With `hostPath` volumes, your data lives in `/tmp` on the node the Pod is scheduled onto and does not move between nodes. If a Pod dies and gets scheduled to another node in the cluster, or the node is rebooted, the data is lost.
{: .warning}

1. Launch a terminal window in the directory you downloaded the manifest files.

2. Create two PersistentVolumes from the `local-volumes.yaml` file:

kubectl create -f local-volumes.yaml

{% include code.html language="yaml" file="mysql-wordpress-persistent-volume/local-volumes.yaml" ghlink="/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/local-volumes.yaml" %}

{:start="3"}
3. Run the following command to verify that two 20GiB PersistentVolumes are available:

kubectl get pv

The response should be like this:
**Note:** If you are bringing up a cluster that needs to use the `hostPath` provisioner, the `--enable-hostpath-provisioner` flag must be set in the `controller-manager` component.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not trivial to set controller-manager flags. Is this set by default?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not set by default because hostpath provisioners are only meant for development/local clusters and should not be used in production.

If you use local-up.sh, there is a parameter that you can pass that will set the flag for you. But I'm not sure if we should be prescribing any specific cluster deployment methods in this tutorial.

{: .note}

NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM STORAGECLASS REASON AGE
local-pv-1 20Gi RWO Retain Available 1m
local-pv-2 20Gi RWO Retain Available 1m
**Note:** If you have a Kubernetes cluster running on Google Kubernetes Engine, please follow [this guide](https://cloud.google.com/kubernetes-engine/docs/tutorials/persistent-disk).
{: .note}

## Create a Secret for MySQL Password

Expand Down Expand Up @@ -108,7 +90,19 @@ The following manifest describes a single-instance MySQL Deployment. The MySQL c

kubectl create -f mysql-deployment.yaml

2. Verify that the Pod is running by running the following command:
2. Verify that a PersistentVolume got dynamically provisioned:

kubectl get pvc

**Note:** It can take up to a few minutes for the PVs to be provisioned and bound.
{: .note}

The response should be like this:

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
mysql-pv-claim Bound pvc-91e44fbf-d477-11e7-ac6a-42010a800002 20Gi RWO standard 29s

3. Verify that the Pod is running by running the following command:

kubectl get pods

Expand All @@ -130,7 +124,19 @@ The following manifest describes a single-instance WordPress Deployment and Serv

kubectl create -f wordpress-deployment.yaml

2. Verify that the Service is running by running the following command:
2. Verify that a PersistentVolume got dynamically provisioned:

kubectl get pvc

**Note:** It can take up to a few minutes for the PVs to be provisioned and bound.
{: .note}

The response should be like this:

NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
wp-pv-claim Bound pvc-e69d834d-d477-11e7-ac6a-42010a800002 20Gi RWO standard 7s

3. Verify that the Service is running by running the following command:

kubectl get services wordpress

Expand All @@ -142,15 +148,15 @@ The following manifest describes a single-instance WordPress Deployment and Serv
**Note:** Minikube can only expose Services through `NodePort`. <br/><br/>The `EXTERNAL-IP` is always `<pending>`.
{: .note}

3. Run the following command to get the IP Address for the WordPress Service:
4. Run the following command to get the IP Address for the WordPress Service:

minikube service wordpress --url

The response should be like this:

http://1.2.3.4:32406

4. Copy the IP address, and load the page in your browser to view your site.
5. Copy the IP address, and load the page in your browser to view your site.

You should see the WordPress set up page similar to the following screenshot.

Expand All @@ -172,13 +178,9 @@ The following manifest describes a single-instance WordPress Deployment and Serv
kubectl delete deployment -l app=wordpress
kubectl delete service -l app=wordpress

3. Run the following commands to delete the PersistentVolumeClaims and the PersistentVolumes:
3. Run the following commands to delete the PersistentVolumeClaims. The dynamically provisioned PersistentVolumes will be automatically deleted.

kubectl delete pvc -l app=wordpress
kubectl delete pv local-pv-1 local-pv-2

**Note:** Any other Type of PersistentVolume would allow you to recreate the Deployments and Services at this point without losing data, but `hostPath` loses the data as soon as the Pod stops running.
{: .note}

{% endcapture %}

Expand Down

This file was deleted.