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

The

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/).

CodePudding user response：

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

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}" } } } }

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

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.