- OpenShift - Security
- OpenShift - Docker and Kubernetes
- OpenShift - Administration
- OpenShift - Application Scaling
- OpenShift - Clusters
- OpenShift - CLI Operations
- OpenShift - CLI
- OpenShift - Build Automation
- OpenShift - Getting Started
- OpenShift - Basic Concept
- OpenShift - Environment Setup
- OpenShift - Architecture
- OpenShift - Types
- OpenShift - Overview
- OpenShift - Home
OpenShift Useful Resources
Selected Reading
- Who is Who
- Computer Glossary
- HR Interview Questions
- Effective Resume Writing
- Questions and Answers
- UPSC IAS Exams Notes
OpenShift - Build Automation
In OpenShift, we have multiple methods of automating the build pipepne. In order to do that we need to create a BuildConfig resource to describe the build flow. The flow in BuildConfig can be compared with the job definition in Jenkins job definition. While creating the build flow, we have to choose the build strategy.
BuildConfig File
In OpenShift, BuildConfig is a rest object used to connect to API and then create a new instance.
kind: "BuildConfig" apiVersion: "v1" metadata: name: "<Name of build config file>" spec: runPopcy: "Serial" triggers: - type: "GitHub" github: secret: "<Secrete file name>" - type: "Generic" generic: secret: "secret101" - type: "ImageChange" source: type: "<Source of code>" git: uri: "https://github.com/openshift/openshift-hello-world" dockerfile: "FROM openshift/openshift-22-centos7 USER example" strategy: type: "Source" sourceStrategy: from: kind: "ImageStreamTag" name: "openshift-20-centos7:latest" output: to: kind: "ImageStreamTag" name: "origin-openshift-sample:latest" postCommit: script: "bundle exec rake test"
In OpenShift, there are four types of build strategies.
Source-to-image strategy
Docker strategy
Custom strategy
Pipepne strategy
Source-to-image Strategy
Allows creating container images starting from the source code. In this flow, the actual code gets downloaded first in the container and then gets compiled inside it. The compiled code gets deployed inside the same container and the image is built from that code.
strategy: type: "Source" sourceStrategy: from: kind: "ImageStreamTag" name: "builder-image:latest" forcePull: true
There are multiple strategy popcies.
Forcepull
Incremental Builds
External Builds
Docker Strategy
In this flow, OpenShift uses Dockerfile to build the image and then upload the created images to the Docker registry.
strategy: type: Docker dockerStrategy: from: kind: "ImageStreamTag" name: "ubuntu:latest"
Docker file option can be used in multiple locations starting from file path, no cache, and force pull.
From Image
Dockerfile path
No cache
Force pull
Custom Strategy
This is one of the different kinds of build strategy, wherein there is no such compulsion that the output of the build is going to be an image. It can be compared to a free style job of Jenkins. With this, we can create Jar, rpm, and other packages.
strategy: type: "Custom" customStrategy: from: kind: "DockerImage" name: "openshift/sti-image-builder"
It consists of multiple build strategies.
Expose Docker socket
Secrets
Force pull
Pipepne Strategy
Pipepne strategy is used to create custom build pipepnes. This is basically used to implement the workflow in the pipepne. This build flow uses custom build pipepne flow using Groovy DSL language. OpenShift will create a pipepne job in Jenkins and execute it. This pipepne flow can also be used in Jenkins. In this strategy, we use Jenkinsfile and append that in the buildconfig definition.
Strategy: type: "JenkinsPipepne" jenkinsPipepneStrategy: jenkinsfile: "node( agent ) { stage build openshiftBuild(buildConfig: OpenShift-build , showBuildLogs: true ) stage deploy openshiftDeploy(deploymentConfig: backend ) }"
Using build pipepne
kind: "BuildConfig" apiVersion: "v1" metadata: name: "test-pipepne" spec: source: type: "Git" git: uri: "https://github.com/openshift/openshift-hello-world" strategy: type: "JenkinsPipepne" jenkinsPipepneStrategy: jenkinsfilePath: <file path repository>Advertisements