OpenShift
OpenShift is Red Hat’s enterprise kubernetes distribution.
This library allows you to perform deployments to static or ephemeral application environments with Helm.
Steps Provided
| Step | Description |
|---|---|
|
Performs a deployment using Helm |
|
Creates a short-lived application environment for testing |
Library Configurations
The configurations for the OpenShift library can be specified at multiple levels. Given this additional configurability the typical table of configuration options would be less clear than examples, so we’ll be breaking it down per configuration portion.
OpenShift URL
The OpenShift URL can be defined in the library spec or on a per application environment basis.
For example, it’s common to have a cluster for lower environments with a separate cluster for production. You would specify this as follows:
application_environments{
dev{
short_name = "dev"
long_name = "Development"
}
test{
short_name = "test"
long_name = "Test"
}
prod{
short_name = "prod"
long_name = "Production"
openshift_url = "https://openshift.prod.example.com:8443"
}
}
libraries{
openshift{
url = "https://openshift.dev.example.com:8443"
}
}With this configuration, https://openshift.dev.example.com:8443 would be used when deploying to dev and test while https://openshift.prod.example.com:8443 would be used when deploying to prod
Helm Configuration
We use Helm for a deployment mechanism to OpenShift. Helm is a package manager and templating engine for Kubernetes manifests. Using Helm, the typical YAML manifests used to deploy to Kubernetes distributions can be templatized for reuse. In our case, a different values file is used for each static application environment.
Deploy the Tiller Server
Instead of using Helm as a package manager by bundling the charts and deploying them to a chart repository, we instead use a configuration repository as our infrastructure as code mechanism.
Create Helm Configuration Repository
You’ll need to create a GitHub repository to store the helm chart for your application(s). See the helm docs on provisioning a new chart to get intialize the repository with the skeleton for your chart.
How you choose to build your helm chart is up to you, you can put every api object in the templates directory or have subcharts for each individual microservice. SDP doesn’t care, as all it does is clone the github repository and deploy the chart using the specified values file.
Values File Conventions
Given that we tag container images using the git SHA, SDP will clone your helm configuration repository and update a key corresponding to the current version of each container image for each application environment.
As such, a certain syntax is required in your values file. You must have an image_shas key. SDP will automatically add subkeys for each repositories under this image_shas with a value that is the git SHA.
|
Given that YAML keys can’t have hypens, hyphens in repository names will be replaced with underscores. |
image_shas:
my_sample_application: abcdefgh
another_repo: abcdefyou can add whatever other keys are necessary to appropriately parameterize your helm chart.
Helm Configurations for the Library
The helm configuration repository, github credential, tiller namespace, and tiller credential can be configured globally in the library spec and overriden for specific application environments.
The values file to will default to values.${app_env.short_name}.yaml, or can be overridden via app_env.chart_values_file.
The name of the release will default to app_env.short_name, or can be overridden via app_env.tiller_release_name
An example of helm configurations:
application_environments{
dev{
short_name = "dev"
long_name = "Development"
chart_values_file = "dev_values.yaml"
}
test{
short_name = "test"
long_name = "Test"
tiller_release_name = "banana"
}
prod{
short_name = "prod"
long_name = "Production"
tiller_namespace = "rhs-tiller-prod"
tiller_credential = "rhs-tiller-prod"
}
}
libraries{
openshift{
helm_configuration_repository = "https://github.boozallencsn.com/Red-Hat-Summit/helm-configuration.git"
helm_configuration_repository_credential = "github"
tiller_namespace = "rhs-tiller"
tiller_credential = "rhs-tiller"
}
}Promoting Images
It’s often beneficial to build a container image once, and then promote that image through different application environments. This makes it possible to test the content of an image once in a lower environment, and remain confident that the results of those tests would be the same as an image is promoted. Promoting images also speeds up the CI/CD pipeline, as building a container image is often the most time-consuming part of the pipeline.
By default, the deploy_to() step of the Openshift pipeline library will promote a container image if it can expect one to exist, which is when the most recent code change was a merge into the given code branch. The image would be expected to be built from an earlier commit, or while there was an open PR.
You can override this default for the entire pipeline by setting the promote_previous_image config setting to false. You can also choose whether or not to promote images for each application environment individually through the promote_previous_image application_environment setting. This app_env setting takes priority over the config setting.
An example of these settings' usage:
application_environments{
dev{
short_name = "dev"
long_name = "Development"
promote_previous_image = false
}
prod{
short_name = "prod"
long_name = "Production"
}
}
libraries{
openshift{
helm_configuration_repository = "https://github.boozallencsn.com/Red-Hat-Summit/helm-configuration.git"
helm_configuration_repository_credential = "github"
tiller_namespace = "rhs-tiller"
tiller_credential = "rhs-tiller"
promote_previous_image = true //note: making this setting true is redundant, since true is the default
}
}Putting It All Together
| Field | Description | Default Value | Defined On |
|---|---|---|---|
openshift_url |
The OpenShift Console URL when specified per app env |
app_env |
|
url |
The OpenShift Console URL when specified globally |
library spec |
|
helm_configuration_repository |
The GitHub Repository containing the helm chart(s) for this application |
both |
|
helm_configuration_repository_credential |
The Jenkins credential ID to access the helm configuration GitHub repository |
both |
|
tiller_namespace |
The tiller namespace for this application |
both |
|
tiller_credential |
The Jenkins credential ID referencing an OpenShift credential |
both |
|
tiller_release_name |
The name of the release to deploy |
app env |
|
chart_values_file |
The values file to use for the release |
app_env |
|
promote_previous_image |
Whether or not to promote a previously-built image |
(Boolean) true |
both |
application_environments{
dev{
short_name = "dev"
long_name = "Development"
chart_values_file = "dev_values.yaml"
}
test{
short_name = "test"
long_name = "Test"
tiller_release_name = "banana"
}
prod{
short_name = "prod"
long_name = "Production"
tiller_namespace = "rhs-tiller-prod"
tiller_credential = "rhs-tiller-prod"
openshift_url = "https://openshift.prod.example.com:8443"
promote_previous_image = true
}
}
libraries{
openshift{
url = "https://openshift.dev.example.com:8443"
helm_configuration_repository = "https://github.boozallencsn.com/Red-Hat-Summit/helm-configuration.git"
helm_configuration_repository_credential = "github"
tiller_namespace = "rhs-tiller"
tiller_credential = "rhs-tiller"
promote_previous_image = false
}
}