Getting to the cloud faster with Binary Builds on OpenShift

Posted: March 6th, 2016 | Author: sabre1041 | Filed under: Technology | 5 Comments »

To demonstrate how to perform binary builds in OpenShift, let’s walk through a few different scenarios to emphasize these concepts. These scenarios are located in a Git repository that can be cloned to the local machine.

git clone https://github.com/sabre1041/ose-binary-builds

The repository contains examples in multiple programming languages, ideal for a polyglot developer. In addition, there are templates that can be used to quickly instantiate the examples in OpenShift. The first example leverages the out of the box CakePHP OpenShift example in the cakephp-binary-build-with-src folder. To provide a location for the contents of this example, create a new project in OpenShift called cakephp-binary in either the OpenShift web interface or CLI. The following can be specified when using the CLI to create the new project:

oc new-project cakephp-binary

Now, navigate to the templates folder in the Git repository and instantiate the template which will create the necessary objects in OpenShift:

oc process -f cakephp-binary-build.json | oc create -f -

After the template has been instantiated, a build is automatically triggered.

oc get builds

NAME                TYPE      FROM      STATUS    STARTED          DURATION
cakephp-binary-app-1   Source    Binary    Running   34 seconds ago   32s

Recall that binary builds does not retrieve source code, but expects it to be provided. We can confirm this by viewing the logs of the pods:

oc logs cakephp-binary-app-1-build

Notice the last line from the output

I0301 23:20:49.625284       1 source.go:167] Receiving source from STDIN as archive

The builder is expecting some form of input at standard in for it to begin the build process. Since none was provided, it will sit and wait forever. Let’s go ahead and cancel this build, and trigger a new build while also providing the source content.

oc cancel-build cakephp-binary-app-1

A new build can be triggered using the oc start-build command. Earlier, we reviewed several subcommands that are associated with the start-build command. The CakePHP application is fully contained within the cakephp-binary-build-with-src folder. The –-from-dir subcommand can be used to archive the contents of the folder, stream the contents to OpenShift, and extract the contents into the builder for the OpenShift build process. Run the following command at the root of the repository to start the build process:

oc start-build cakephp-binary-app --from-dir=cakephp-binary-build-with-src

The contents of this folder should have been uploaded to the builder, extracted used for the resulting build. Track the state of the build by running the oc get builds command. Once the build completes, the application can be accessed through a route which the template automatically created when it was instantiated.

To determine the application URL, run oc get routes and locate the host/port column. The value should be in the format cakephp-binary-app-cakephp-binary.<openshift_app_subdomain>. Navigate to this URL to validate the application can be accessed.

Now, let’s take an example of a Java developer who is developing a small web application to be run on JBoss. They want to be able to quickly validate their latest updates in the cloud. After their latest local build, they have a resulting artifact in a web archive (.war) format as input for the binary build. Let’s create a new project in OpenShift called jboss-binary for the application.

oc new-project jboss-binary

Navigate to the templates directory and instantiate the Java template:

oc process -f jboss-eap64-binary-build.json | oc create -f -

Once again, cancel the initial build that was automatically created as we will need to provide the binary content to the builder.

oc cancel-build eap-binary-app-1

With the project components in place and ready, the focus can shift to the content that will be uploaded as part of the binary build. Circling back to the developer example, once they have their artifact (.war) available from the latest development iteration, they can place it in a folder structure that when combined with a Source to Image (S2I) build strategy, will be automatically deployed to the platform. Recall the usage of a binary build only affects the source of the build and not the build strategy. Any of the build strategies (S2I, docker, or custom) supported by OpenShift can by utilized. For JBoss based S2I builds, any artifacts found in a folder called deployments will be automatically deployed. In the sample repository, a folder called jboss-binary-build-with-artifact contains a folder called deployments with the artifact that should be deployed. The artifact is called ROOT.war so that it is automatically deployed to the root context of the JBoss server. Navigate to the root of the repository and run the following command to produce the binary content for the build.

oc start-build eap-binary-app --from-dir=jboss-binary-build-with-artifact

The folder is then uploaded and used as the content for the binary build. Since this is the second build, the logs can be viewed by running oc logs eap-binary-app-2-build -f. In the log output, notice the following line, which denotes that the Java artifact that was uploaded as part of the binary build was copied to the JBoss deployments folder.

Copying all deployments war ear jar artifacts from /home/jboss/source/deployments directory into /opt/eap/standalone/deployments for later deployment...
'/home/jboss/source/deployments/ROOT.war' -> '/opt/eap/standalone/deployments/ROOT.war'

Run oc get routes to determine the application URL and navigate to this URL in a web browser to confirm the page is accessible.

Even existing Git repositories can also take advantage of binary builds. One of the benefits of git is in its’ distributed repository model. A developer can work on a repository on their local machine and before they are ready to share it with the world in a public repository, such as GitHub, they can test their code in OpenShift. This paradigm is a very similar model to previous versions of OpenShift where developers were provided a repository by OpenShift and any changes they made were pushed up to OpenShift directly. To provide the contents of an existing git repository as input for a binary build, the following command is used:

oc start-build <build_name> --from-repo=<path_to_repository>

Note: The –commit flag can be added to denote a specific tag, branch or commit to target

As we have seen, binary builds provides developers with yet another avenue to get their code into the cloud whether it be a folder containing source code, a software artifact, or an existing git repository. The ability to rapidly build, test and deploy changes to a cloud environment shortens the overall development cycle and enables greater developer productivity.

---