In a prior blog post we detailed the steps required to migrate an existing WordPress instance from OpenShift V2 to V3. The instructions consisted of a series of manual steps to first set up a new instance of WordPress and then migrate the data across from an existing instance of WordPress.
In this blog post, we are going to show you a much easier way of getting a new instance of WordPress up and running in OpenShift 3.6 or later using a quick start template and custom WordPress image.
This instance can be used for a new site, or you can perform the data migration steps we already detailed in the prior blog to migrate your data from an existing instance of WordPress.
Loading the Templates
A template is a record of the set of resource definitions which need to be constructed to create an application in OpenShift. This can consist of a build configuration for defining how to build an application image from source code, a deployment configuration defining how to deploy the application image, as well as the definitions needed to make the service available and accessible to users.
All this could have been described using a raw set of resource definitions from which you created the application, but a template allows us to input parameters which customize the name of the application and other configuration such as the amount of resources required.
A template can also be pre-loaded into OpenShift, with it then becoming selectable from the service catalog in the OpenShift web console, or used from the command line when creating a new application.
Using a template allows us to easily go on to create multiple instances of the application, each running independently.
To load our quick start templates for WordPress, from the command line run:
oc create -f https://raw.githubusercontent.com/openshift-evangelists/wordpress-quickstart/master/templates/classic-standalone.json oc create -f https://raw.githubusercontent.com/openshift-evangelists/wordpress-quickstart/master/templates/classic-repository.json
To deploy a fresh WordPress instance, from the web console select Add to Project. Under Browse Catalog, select PHP. You should be able to see options for deploying WordPress. In this post we are going to use the template WordPress (Classic / Standalone).
This template will create a standalone installation of WordPress. The configuration requires two persistent volumes be available. One is used for a MySQL database and the other for plugins, themes and other assets you may install through WordPress.
If you are using OpenShift Online Pro, you will first need to ensure you have two persistent volumes in the resource quota attached to your account. The template will not work with OpenShift Online Starter as it only provides a single persistent volume as part of the plan.
Select WordPress (Classic / Standalone) and you will be presented with a form to fill out details for the WordPress instance to be created.
Set the name the WordPress instance will be known by in OpenShift. You can optionally set the database username and password. If you do not, these will be automatically filled in with generated values. You can look up the auto-generated values later using the web console if needed.
Click on Create to deploy the WordPress instance and return to the Overview in the OpenShift web console to monitor progress as the application image is built and deployed.
Once WordPress has finished deploying, go to the WordPress site by clicking on the URL displayed on the Overview page of the OpenShift web console. The configuration created will ensure that a secure HTTP connection is used when performing any administration on the WordPress instance, or when logging into the WordPress site.
When the WordPress instance is created, it will be automatically configured with the database credentials to match the MySQL database which is also deployed by the template. Other settings necessary for running under OpenShift will also be automatically set up.
Upon visiting the WordPress site you should, therefore, bypass the initial setup usually required for WordPress. The first page you should arrive at will be that to select the language to use.
Select the language and click on Continue. You will be asked to provide the name for the WordPress instance and details of an initial user.
Fill in your details and click on Install WordPress. You will receive confirmation that setup of WordPress has been successful.
You can now log in to your WordPress instance and start using it.
If you implement your own plugins or themes for WordPress and have them in a hosted Git repository, you can have them automatically deployed with the WordPress site by using the WordPress (Classic / Repository) template. You will be asked to provide a URL for a source repository containing your source code for the plugins and themes. Each time you make changes to your plugins or themes, you can trigger a new build of the WordPress site and they will copied into the site from the source code repository.
Running a Permanent Site
The above steps provide an easy way of starting up a WordPress site. If you are going to use this to create your own permanent site, we do recommend that you first fork the repository containing the template and use your copy.
The reason for this is that the WordPress image will on each re-build, pull down from the repository custom variants of the Source-to-Image (S2I) scripts which will be run within the PHP S2I builder. These custom scripts will run additional steps on top of those run by the standard scripts provided with the PHP S2I builder, in part replacing the manual steps that were described in the prior blog we posted on running WordPress on OpenShift V3.
By creating your own fork of the repository and using it, you ensure you will not be affected by any changes made to the original repository. You can still pull down any changes and merge them into your copy later if necessary.
To fork the repository, use the Fork button on the home page of the repository on GitHub.
This will create a copy of the repository in your own GitHub account.
When you use the templates, use your copy and also ensure you change the URL in the
QUICKSTART_REPOSITORY_URL field of the template to be the URL for your fork of the repository.
Deployments and Scaling
The template used above creates a configuration which deploys WordPress and a MySQL database instance. They are deployed as separate applications in OpenShift and can be independently restarted. If the OpenShift instance you are using has persistent volumes of type ReadWriteMany available, you can use those instead of the default of ReadWriteOnce. Using this persistent volume type will then allow you to scale up the number of instances of WordPress to more than 1 replica. If you use persistent volumes of type ReadWriteMany, you will also be able to use the Rolling deployment strategy. This deployment strategy enables you to have zero downtime deploys when rolling out an update to WordPress.
If you are using OpenShift Online Pro, do be aware that at this time only persistent volumes of type ReadWriteOnce are available and you will need to stick with a single instance of WordPress.
Creating a Site for Testing
The way in which the template deploys WordPress is intended to provide a starting point for running a permanent instance of WordPress. If you have a need to run an instance of WordPress to test out deployments, upgrades or features of WordPress, separate templates are provided suitable for a testing environment.
These templates can be loaded by running:
oc create -f https://raw.githubusercontent.com/openshift-evangelists/wordpress-quickstart/master/templates/testing-standalone.json oc create -f https://raw.githubusercontent.com/openshift-evangelists/wordpress-quickstart/master/templates/testing-repository.json
When these templates are used, they will deploy WordPress and MySQL together in a single Kubernetes pod. This configuration only requires a single persistent volume. Because MySQL is run together with WordPress, you will not be able to scale up to more than one instance of WordPress, nor enable rolling deployments.
Due to these limitations, this configuration is only recommended for a testing environment. Although you can deploy WordPress to OpenShift Online Starter with this configuration, the Starter environment should only be used for testing, it is not suitable for running a permanent instance of WordPress that needs to always be available. This is due to the fact that the application will be idled when not in use and also forced to hibernate if it runs for more than a certain amount of time in a specified period.
Hopefully, you will find these templates provide an easier way of getting a WordPress instance running. If you want further information about how to use these templates, check out documentation provided in the repository.
These quick start templates are provided by the OpenShift Evangelists team as an example for how to use templates. It is not officially supported and we aren’t WordPress experts, but if you have any feedback you can create an issue on GitHub.
And now that you have your WordPress instance setup and running< if you want to migrate an existing WordPress site, jump back to our prior blog post and start out with step 8.Openshift is available and integrated with Cloud Infrastructure Server Cluster