OpenShift Origin
While I wait for my invitation to join Openshift Online, I’ve been experimenting locally with Openshift Origin. To keep things easy, I opted for the Vagrant all-in-one vm.
Openshift is a distribution of Kubernetes which provides easy-to-build and deploy docker container environments. There’s plenty info on their website, and the documentation is good.
Once I got up and running, I followed the CakePHP tutorial, as it’s mainly PHP web apps I’m interested in using this for.
CLI Client
As well as the Vagrant vm, I locally installed the ‘oc’ CLI client which can be downloaded from here (latest release at time of writing)
If you don’t want to install the CLI client, you can SSH into the vm and it’s already available to you there.
Automated Builds
I want my Openshift project builds to be triggered automatically by pushes to my repos on GitHub, so I’m using webhooks to achieve this.
In order for GitHub to reach my local private installation of Openshift, I’m using Ultrahook, which you can integrate very easily by following along with an Openshift blog post.
Private Repository
If pulling from a private Github repository, you need to generate a secret to hold your GitHub credentials (either username and password or public SSH key).
The first step, is to make sure you’re logged in via the CLI client (oc login). Then follow the instructions in the link above to generate a new basicauth or SSH secret.
Secrets
Ignore the instructions to link the secret to the builder, however, as this command is obsolete. Instead, you can discover how to do it correctly by running oc secret add -h where you'll find that the correct command isoc secrets add serviceaccounts/builder secrets/
The instructions on how to add the secret to your YAML file are correct.
Service Accounts
I almost pulled my hair out trying to connect to a private repo. For some reason, the builder service account couldn’t reach my credentials secret so the build would hang in “pending” state. I couldn’t understand why, then I found a command that helped me solve it:
oc describe serviceaccount builder
Including the service account name (builder in this case) is optional. If you leave it out, all service accounts are listed.
The output of this command showed me that the builder service account was operating in a specific Namespace. I must have made some sort of error when following the cakephp tutorial and somehow associated my builder service account with a “cakephp-ex” namespace (a value I entered when I followed the tutorial to make that project). I still don’t know what I did wrong, but by editing the GitHub repo URL in the cakephp project (adding a private GitHub repo URL that I owned instead), I was able to successfully clone it using the authentication secret that I defined in the YAML build config file.
I need to read up some more on what’s going on here, because it’s bizarre that the builder can only see a secret if a build has already successfully occurred. I’m sure it’s a simple matter of EBKAC and I’ll post the answer when I’ve discovered it.
Next Steps
This is as far as I’ve got to-date. I’m now trying to successfully build a Symfony web app with a database in a separate pod. I’ve got the MySQL pod up and running, but I need to work out how to either import a seed database, or at least execute the build schema command during a post-build hook so that Composer’s cache:clear command doesn’t fail and break the webserver build! Another blog post will follow when I’ve got this sorted out.
