Deploy microservice (spring boot app) on Openshift via Jenkins pipeline

Viewed 488

I need to deploy a spring boot app (docker image) in openshift via jenkins, to achieve this I am doing the below steps,

  1. I created the docker image of spring boot app using the jenkins pipeline 'freestyle' template -
  2. pushed that docker image in 'Artifactory' registory

The above two steps are completed and working, But I am struggling to deploy that docker image (which is in Artifactory registory) to openshift server via jenkins pipeline, It seems like its a common requirement but I did not find any good documentation on this, any help would be much appreciated.

2 Answers

Unfortunately there is no code snippet from your side that I could extend to give you a copy paster solution, however, the easiest way to deploy to Kubernetes using Jenkins is the exact same way as one would do for other CI/CD tools as well, simply execute a kubeactl apply within the pipeline.

To do so you should have a folder called k8s (or similar) within your repository that contains all necessary files for the deployment process:

stackoverflow-repo
├── docker
│   └── Dockerfile
├── Jenkinsfile
├── k8s
│   ├── configmap.yaml
│   └── deployment.yaml
└── src
    └── main
        ├── java
        ├── main.java
        └── resources
            └── app.properties

For security reasons it would be appropriate to create a ServiceAccount or User in Kubernetes and assign it roles that are necessary for deployment (i.e. updating, patching and creating Services, Deployments and so on) using RBAC.

There is also the option of using the Kubernetes plugin for Jenkins, however, it is more complicated to use and results in a vendor lock which I would try to avoid, especially since Jenkins is somewhat on a path of extinction (compared to other CI/CD tools that are simpler, faster and more efficient in what they offer).

Keep in mind that many modern Kubernetes architectures deploy via ArgoCD:

enter image description here

The reason this is preferred is because it uses an approach called GitOps and can easily be combined with any CI/CD tool, making it more easy to switch around since ArgoCD is doing the actually deployment. Furthermore it also offers a nice UI that gives clear and understandable information to people that are not used to working with Kubernetes on a daily basis.

Having said all that it is totally up to you what path you want to take but keep in mind that a simple kubectl apply -f k8s/ inside your Jenkinsfile will accomplish excactly what you want and only requires you to place a kubeconfig file somewhere the running pipeline can access it (you can specify the path by doing something like kubectl --kubeconfig /path/to/kubeconfig apply -f k8s/).

There are a few solutions ranging depending on your level of commitment and level of automation DevOps integration wanted:

  1. fast and dirty solution - If you insert the oc command line tool into your Jenkins agents\slaves (usually best if you ran on machines or VMs), you can create an environment variable to hold the application name and as long as you created it with oc new-app or similar you can execute oc import-image followed by the ImageStream name nad it will check the docker repo tag for changes in the version hash (and if the hash changed it will update it). check here for basic token injecting to avoid password spills through git.

example Jenkinsfile snippet:

pipeline {
    agent { 'jenkins_slave_vm' }
    environment {
        SERVICE='myapp'
    }

    stages {
        stage('build&push') {
            steps {
                sh "docker build -t myrepo/${SERVICE}:latest -f Dockerfile.production ."
                sh "docker push myrepo/${SERVICE}:latest"
            }
        }
        stage('deploy') {
            steps {
                sh "oc login --token=${OC_IMAGE_UPDATE_TOKEN}"
                sh "oc import-image ${SERVICE}"
            }
        }
    }
}
  1. more robust enterprise solution - using the k8s\openshift plugin (different plugins) for Jenkins, the general k8s plugin is used to spin up pods with the environment needed (like node for frontend applications), bring back down at the end of usage, run the build stages while building the docker\container images with openshift BuildConfig object and basing the behavior on either Dockerfile configuration, S2I or fully managed by openshift using the pipeline method (though more complex and very platform invested compared to the other two), here's a fairly latest explanation for openshift 4.6 though existed since version 3.x as well. This method allows for a more declarative, reproducible, and in the long term consistent build strategy and is the one we at my current organization are currently using for the resource-saving and the consistency that originally came with the rise of containers.

pipeline examples

  1. halfway - trigger an openshift build with a webhook from the SCM platform (can check this out here). removes some of the relience from Jenkins (and personally not tested) but if you really can't make it with the other options this might be the last straw.
Related