Skip to content

Instantly share code, notes, and snippets.

@dhana-git

dhana-git/devops-implementation-using-openshift-summary.md

Last active March 24, 2017 14:10
Show Gist options

  • Select an option

    Learn more about clone URLs
  • Save dhana-git/c4c57541bfdd20a7be189c3ad10c10d2 to your computer and use it in GitHub Desktop.

Select an option

Learn more about clone URLs
Save dhana-git/c4c57541bfdd20a7be189c3ad10c10d2 to your computer and use it in GitHub Desktop.
Download ZIP
Summary of DevOps implementation in IEP using OpenShift (PaaS) to try various development approaches in Fuse Integration Services (FIS) iPaaS capabilities
Raw
devops-implementation-using-openshift-summary.md

DevOps implementation for Fuse Applications using FIS for OpenShift

Table of Contents

FIS Development Approaches

Fuse Integration Services (FIS) is an iPaaS/xPaaS capability bringing Routing/Brokering (Apache Camel) and Messaging (Apache CXF and JBoss AMQ) capabilities to the trending Containers (Docker) and PaaS (OpenShift).

FIS supports the following application development workflows,

  1. Fabric8 Maven Workflow
  2. OpenShift Source-to-Image (S2I) Workflow

Fabric8 Maven workflow

This default workflow consists in having Maven building the Java artifacts and the Docker image locally and then pushing the generated image into the OpenShift registry / to an external Docker registry.

Pros:

  • The developer can use the same configuration to build and run the application in a pre-Docker world and to have it deployed on OpenShift.
  • Issues in assembling and building an image can be identified early in build stage itself.

Cons:

  • The developer will need to have Docker instance available (locally/remotely) where the build happens.

Implementation instructions,

  1. Add required Maven Plugins (fabric8-maven-plugin, docker-maven-plugin, karaf-maven-plugin,..) into your pom.xml file.
  2. Configure Karaf assembly, Docker registry, OpenShift project, and other build info on the respective plugins.
  3. Use the maven goals (i.e. clean install docker:build docker:push) to build and push an image into internal/external Docker registry.
  4. Use the maven goals (i.e. fabric8:apply) to trigger build and deployment in OpenShift.
  5. Find more info here.

Source-To-Image (S2I) workflow

The build happens directly in OpenShift, it builds an image out of source using an integrated S2I builder, pushes the built image into an integrated/external Registry and deploys it onto the Docker container(s).

Source-To-Image (S2I)

A framework/library provided by OpenShift that makes it easy to create Docker images from source code.

S2I process

  • Extracts the code from your source repository.
  • Creates a container that builds your source code.
  • Generates a Docker image for your application.
  • Pushes it into the OpenShift registry.

Pros

  • Developer no need to have Docker instance available locally/remotely.

Cons

  • From development perspective, need to commit into a Git repository every change you are trying out. But this could be mitigated by Binary Build.

Binary Build

Binary build consists in streaming your source code directly from your computer to the builder container using (oc start-build). You can use the same build configuration that you use for your CI build.

Implementation instructions

  1. It starts with Image/Template addition into a project.
  2. Get base image (e.g. fis-karaf-openshift) loaded into our local registry/repository using Load ImageStream/Template feature.
  3. Select the image/template available in catalog and add it into the specific project/namespace.
  4. Provide Git Repository info, Route info, and other build and deployment configurations.
  5. Upon addition, the Build gets triggered and subsequently the deployment, if opted. If not opted, trigger Build and/or Deployment manually.
  6. During build,
  • OpenShift identifies the programming language used (i.e. Java) and picks the Build tool to be used (i.e. Maven in our case).
  • OpenShift derives the build strategy (Source, Docker or Custom) to be used based on the ImageStream/Template (Source in our case).
  1. On successful completion of Build and Deployment, we could see the required service created and running for us.

Jenkins as a service in Openshift

Use Jenkins job to create a service, trigger and verify a build, trigger and verify a deployment, scale up/down the deployed pods on OpenShift from Jenkins remotely.

Implementation instructions

  1. Select "jenkins-persistent-template” template from catalog of images/templates and add it into default or your custom project.
  2. Build and deploy the image. This deploys Jenkins with the required plugins (OpenShift/Fabric8/Kubernetes) added by default.
  3. Open Jenkins web console and configure a job.
  4. Create a project for application image build and deployment.
  5. Create Build Config and Deployment Config in OpenShift by following one of the above mentioned approaches (Source-To-Image (S2I) workflow or Fabric8 Maven workflow).
  6. Use these build and deployment config information and configure Jenkins Job.
  7. Trigger Jenkins Job and see the result (Build triggered successfully, Deployment triggered successfully,..).

Appendix

For your reference, I have created a quick start project (fis-openshift-s2i-karaf-camel-qs) to explore Fuse Integration Services (FIS) iPaaS solution approaches.

There are gists for our quick reference.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment