Getting to the cloud faster with Binary Builds on OpenShift

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

Binary Build LogoOne of the benefits of a Platform as a Service is the ability for developers to rapidly deploy applications to an elastic, cloud based environment. The application workflow typically involves a developer providing the location of source code in a Git repository that is remotely accessible by the platform for it to retrieve, and to facilitate the build and deployment process. In OpenShift, the two most common build types, Docker and Source to Image (S2I), follow this paradigm. The developer will provide the location of a Git repository, and OpenShift will retrieve the source and perform the build depending on the type. While this workflow is extremely effective, it does require the developer to complete several intermediately steps beforehand, such as allocating and pushing to a Git repository for the platform to pull from. An alternative solution is to utilize another source type supported in OpenShift, called binary builds. Instead of OpenShift using a remote Git repository to pull a source from, the developer directly pushes their content to OpenShift.

OpenShift Builds Workflow

This type of build workflow has several benefits developers can take advantage of. First, they can quickly deploy their application to the platform without requiring the allocation of other resources or dependencies, such as a Git repository. Secondly, if the developer has an existing binary artifact, such as precompiled Java web archives (.war), they can deploy it directly to the platform instead of storing it in a Git repository, which is not recommended.

First, let’s understand the entire process behind a binary build in OpenShift. As mentioned previously, the build process is driven by the developer in a push manner, and in most cases, facilitated by the OpenShift Command Line Interface (CLI), which will upload the binary content and start the build process. The start-build subcommand of the OpenShift CLI is used to initiate the entire process. When using a binary build, several types of content can be provided, each with their own subcommand flag: directories, compressed files, or a git repository:

Content Type Subcommand Flag
A system file folder –from-dir
A compressed file –from-file
A git repository –from-repo

The builds section of the OpenShift documentation provides a summary of the subcommand options including a list of flags that can be added to further customize their behavior.

With a high level understanding of the binary build process, let’s discuss the steps necessary to configure a binary build. As with all builds in OpenShift, these are set in the BuildConfig object. A typical configuration for a PHP application looks similar to the following:

        {
            "kind": "BuildConfig",
            "apiVersion": "v1",
            "metadata": {
                "name": "${APPLICATION_NAME}",
                "annotations": {
                    "description": "Defines how to build the application"
                }
            },
            "spec": {
                "source": {
                    "type": "Binary",
                    "binary": {
                        "asFile": ""
                    },
                    "contextDir": "${CONTEXT_DIR}"
                },
                "strategy": {
                    "type": "Source",
                    "sourceStrategy": {
                        "from": {
                            "kind": "ImageStreamTag",
                            "namespace": "openshift",
                            "name": "php:5.6"
                        }
                    }
                },
                "output": {
                    "to": {
                        "kind": "ImageStreamTag",
                        "name": "${APPLICATION_NAME}:latest"
                    }
                },
                "triggers": [
                    {
                        "type": "ImageChange"
                    },
                    {
                        "type": "ConfigChange"
                    },
                    {
                        "type": "GitHub",
                        "github": {
                            "secret": "${GITHUB_WEBHOOK_SECRET}"
                        }
                    }
                ]
            }
        },

The most important section in the BuildConfig is the source type in the spec section. In this example, Git is specified as the source type and when a build is run, the contents of the git repository will be cloned into the builder prior to performing the build. To switch over to a binary build type, the source section would look be modified to the following:

"source": {
    "type": "Binary",
     "binary": {
        "asFile": ""
   }
},

The type value is replaced with Binary to indicate the binary build type, and the details of the binary build is entered in a binary section replacing the git section details. The asFile value is used to provide the name of a file containing the binary content that should be created inside the OpenShift builder. Since this field is empty in this example, the contents of the binary source will be extracted into the builder.


5 Comments on “Getting to the cloud faster with Binary Builds on OpenShift”

  1. 1 Getting to the cloud faster with Binary Builds on OpenShift – Red Hat Services Speak said at 12:23 pm on March 8th, 2016:

    […] Article written on Block 87 by Andrew Block […]

  2. 2 Srinivas Kotaru said at 1:47 pm on March 8th, 2016:

    Hi

    This is exactly what am looking. This info is very helpful to understand binary deployment procedure.

    I want you guys continue write similar article s to understand OSE internals and basic features in a simple understable examples.

    Can you explain how it works if we want update configuration files? say for example usr want to update with his own values, tuning in standalone.xml. How to do that? in OSE 2.x we used .openshift folder.

    Can you give example demonstration how to do that?

    Srinivas Kotaru

  3. 3 sabre1041 said at 6:04 pm on March 16th, 2016:

    Srinivas,

    You can create a configuration folder in your source repository. Inside this folder, the JBoss configuration file can be used by putting content in a file called standalone-openshift.xml

    – Andy

  4. 4 Mark Buck said at 3:17 pm on March 15th, 2016:

    Can this technique be used to deploy binaries archived from a Jenkins build job? At Red Hat OpenShift training, we were taught how to modify the build config to set the environment variable DISABLE_ASSET_COMPILATION to true and then set APPLICATION_ARTIFACT_URL to point to the archived build job output. How do these two approaches compare and which is preferred?

  5. 5 Sibongiseni Ngcobo said at 7:00 am on June 6th, 2016:

    Thank you so much for this, I was struggling with this for a few days and couldn’t figure out why my build was stuck.


Leave a Reply