App Wordpress - Large Files Edition

This is a Crossplane Application that you can use to deploy Wordpress into a KubernetesCluster using a MySQLInstance database in the cloud.

Installation

Install with the following command after replacing <version> with the correct one, like 0.1.0:

kubectl crossplane stack install -n default 'crossplane/app-wordpress:<version>' wordpress

Usage

Here is an example CR that you can use to deploy Wordpress to a fresh new cluster:

apiVersion: wordpress.apps.crossplane.io/v1alpha1
kind: WordpressInstance
metadata:
  name: testme
spec:
# You can use UseExistingTarget as well to schedule to a KubernetesTarget in the
# same namespace randomly.
  provisionPolicy: ProvisionNewCluster

#  This is the default value.
# image: wordpress:4.6.1-apache

Build

Run make.

Test Locally

Minikube

Run make and then run the following command to copy the image into your minikube node's image registry:

# Do not forget to specify <version>
docker save "crossplane/app-wordpress:<version>" | (eval "$(minikube docker-env --shell bash)" && docker load)

After running this, you can use the installation command and the image loaded into minikube node will be picked up.

Release

To create and publish a release, use the upbound Jenkins jobs. You'll want to have your release version handy.

A note about the multibranch pipelines we use. We're using multibranch pipeline jobs in Jenkins, which means that Jenkins creates a new job for each branch that it detects. This means that each time a new branch is created, such as from the create branch job, you may need to trigger a new scan of the repository. It also means you may need to run the job once and have it fail before you can enter in parameters for the job.

First, run the job to cut a new branch, if needed. The branch should be named release-MAJOR.MINOR. For example: release-0.0.
If needed, edit the stack version in the release branch, so that the stack version matches the version that will be released. Look for the stack's metadata block.
Run the job to tag the exact release we want. For example: v0.0.1. If you use the one on the release branch we created, that's the simplest.
Run the job to publish the release. It's easiest if you use the branch created earlier.