If you are using JBoss Enterprise Application Platform (EAP) for J2EE development, the CloudBees Jenkins Platform provides an enterprise-class toolchain for an automated CI/CD from development to production.
The CloudBees Jenkins Platform now supports integrations with both Red Hat JBoss Enterprise Application Platform (EAP) and Red Hat OpenShift across the software delivery pipeline. This enables developers to build, test and deploy applications, with Jenkins-based continuous delivery pipelines in JBoss via JBoss EAP 7 or JBoss EAP 7 on OpenShift.
The following examples are based in Jenkins Pipeline plugins, which create complex pipelines, if needed, , to model their software delivery process. If you are not familiar with with the CloudBees Jenkins Pipeline plugin you may find these two blog posts helpful for ramping up: Using the Pipeline Plugin to Accelerate Continuous Delivery -- Part 1 and Part 2.
Let's get started. In a typical CI/CD pipeline your process would be similar to this one:
- Developers commit code to the SCM, which will notify Jenkins via webhooks.
- Jenkins compiles the code and execute a series of test on it: static code analysis, code metrics, unit testing, etc.
- If everything goes well, Jenkins would deploy the code to a development environment. This step typically /may require a manual approval depending on the use of that environment. A typical use case is having the application deployed just to be able to run further validations with tools like Selenium.
- The steps that follow would promote the application between the various environments and to validate that the deployment was correct.
Let's see how the build, deployment and promotion between the various environment can be done for both types of JBoss installs, to JBoss EAP7 and to JBoss EAP 7 on OpenShift, and the differences between them.
Build and Deployment
JBoss EAP 7
In this case, we will take the produced artifact and directly deploy it to the server. There are two possible approaches to get the code deployed: JBoss CLI and Maven Wildfly Plugin.
Both of them produce very similar results, but our recommended approach is to use the JBoss CLI, as it will give you maximum flexibility and allow the use of a common tool between development and operations teams:
checkpoint 'Deploy to QA'
//we use a docker image that comes with the JBoss CLI preinstalled
docker.image('registry.access.redhat.com/jboss-eap-7/eap70-openshift').inside {
// Deploy to JBoss
def destinationWarFile = "movieplex-${env.BUILD_NUMBER}.war"
def versionLabel = "movieplex#${env.BUILD_NUMBER}"
def description = "${env.BUILD_URL}"
withCredentials([[$class: 'UsernamePasswordMultiBinding',
credentialsId: 'jboss-ec2',
passwordVariable: 'password',
usernameVariable: 'username']]) {
sh "/opt/eap/bin/jboss-cli.sh --controller=jboss.mydomain.org:9990 --connect --user=${env.username} --password=${env.password} --command='deploy target/movieplex.war --force'"
}
sleep 10L // wait for JBOSS to update the status
//Check for correct deployment
timeout(time: 5, unit: 'MINUTES') {
waitUntil {
withCredentials([[$class: 'UsernamePasswordMultiBinding',
credentialsId: 'jboss-ec2',
passwordVariable: 'password',
usernameVariable: 'username']]) {
sh "/opt/eap/bin/jboss-cli.sh --controller=jboss.mydomain.org:9990 --connect --user=a${env.username} --password=${env.password} --command='ls /deployment=movieplex.war'> .jboss-status"
}
// parse output
def jbossStatus = readFile(".jboss-status")
println "$jbossStatus"
return jbossStatus.toLowerCase().contains("status=ok")
}
}
}
- With the CLI we call deploy command with the produced war file as a parameter. Jenkins Credential store is being used to ensure that the credentials are kept in a secure way. The CLI will upload the file and deploy it to the server.
- After the deploy is finished we check for correctness.
This process can be made as complex as needed leveraging any of the needed commands from the CLI, introducing changes to the database, deploying additional artifacts, launching a Selenium script to check the application is running, etc.
JBoss EAP 7 on OpenShift
In the case of OpenShift, the approach is slightly different. Instead of producing the artifact in Jenkins anduploading it to JBoss, we will start a build in OpenShift.
This will trigger Source-to-Image (S2I), which will pull the source code, compile it and create a docker image with JBoss and the newly produced application. This image will then be pushed to the OpenShift’s internal Docker Registry.
Calling OpenShift from Jenkins is easily done by using CloudBees OpenShift CLI, which provides an automatic installer for the CLI, integration with Jenkins credentials for login and a wrapper to execute CLI commands from a pipeline.
wrap([$class: 'OpenShiftBuildWrapper', url: 'https://mydomain.openshift.com', credentialsId: 'openshift-credentials' ]) { // oc & source2image sh """ oc project movieplex oc start-build j2ee-application-build --wait=true """
In the previous example, we login into OpenShift, change to the desired project and launch the build.
After the build is finished, we have two possible approaches to deploy the application:
- Enable image change triggers. In this case an automatic deployment will be done after a successful build. In this case we only execute a command to check for correct deployment.
//with build triggers enabled get the current deploy number sh "oc deploy frontend > .openshift-deploy-number"
- Disable image change triggers and control the deployment from Jenkins. This would allow doing additional tasks before actually deploying. This is similar to sending an email for notification, manual validation, waiting for the best moment, etc.
//with build triggers disabled request a deploy with the latest build sh "oc deploy frontend --latest > .openshift-deploy-number"
After this, all that is left to do is check the status of the deployment:
def deployMessage = readFile(".openshift-deploy-number") def deployNumber = deployMessage.substring(deployMessage.indexOf('#')).tokenize()[0] echo "$deployMessage" // Wait for OpenShift deployment timeout(time: 5, unit: 'MINUTES') { waitUntil { sh "oc deploy frontend > .openshift-build-status" // parse `describe-environment-health` output def openshiftDeployStatus = readFile(".openshift-build-status") echo "Checking: '$deployNumber deployed'" def isDeployed = openshiftDeployStatus.indexOf("$deployNumber deployed") echo "$openshiftDeployStatus" echo "$isDeployed" return isDeployed>0 } } }
There could be some cases in which the organization may prefer not to use S2I, for these cases another possibility is to produce a docker image from Jenkins, deploy it to OpenShift and then promote that same image between environments.
Promotion between environments
Once the application is built and deployed to Dev it will have to be promoted to the next environments after each validation stage.
In the case of JBoss EAP 7 we will execute the exact same command for each environment, deploying the same war on each one of them.
For JBoss EAP 7 on OpenShift the recommended approach is to promote the same image from one environment to the other, by tagging the original image. Each environment will point its deployment config to a tag, e.g test, QA and production with a trigger to deploy when a change is detected. In that case by just issuing this command, the image will be promoted from dev to test, QA and production respectively:
//promote to test oc tag jboss-myapp-image:latest jboss-myapp-image:test //promote to qa oc tag jboss-myapp-image:test jboss-myapp-image:qa //promote to production oc tag jboss-myapp-image:qa jboss-myapp-image:prod
We hope these examples of Continuous Delivery with the CloudBees Jenkins Platform to Red Hat JBoss EAP 7 provided you with a base understanding to get you started.
For more information on our integrations with JBoss and other Red Hat Platforms, visit https://www.cloudbees.com/partners/platform/red-hat.
저자 소개
Deon Ballard is a product marketing manager focusing on customer experience, adoption, and renewals for Red Hat Enterprise Linux. Red Hat Enterprise Linux is the foundation for open hybrid cloud. In previous roles at Red Hat, Ballard has been a technical writer, doc lead, and content strategist for technical documentation, specializing in security technologies such as NSS, LDAP, certificate management, and authentication / authorization, as well as cloud and management. She also wrote and edited the Middleware Blog for Red Hat and led portfolio solution marketing for integration and business automation.
채널별 검색
오토메이션
기술, 팀, 인프라를 위한 IT 자동화 최신 동향
인공지능
고객이 어디서나 AI 워크로드를 실행할 수 있도록 지원하는 플랫폼 업데이트
오픈 하이브리드 클라우드
하이브리드 클라우드로 더욱 유연한 미래를 구축하는 방법을 알아보세요
보안
환경과 기술 전반에 걸쳐 리스크를 감소하는 방법에 대한 최신 정보
엣지 컴퓨팅
엣지에서의 운영을 단순화하는 플랫폼 업데이트
인프라
세계적으로 인정받은 기업용 Linux 플랫폼에 대한 최신 정보
애플리케이션
복잡한 애플리케이션에 대한 솔루션 더 보기
오리지널 쇼
엔터프라이즈 기술 분야의 제작자와 리더가 전하는 흥미로운 스토리
제품
- Red Hat Enterprise Linux
- Red Hat OpenShift Enterprise
- Red Hat Ansible Automation Platform
- 클라우드 서비스
- 모든 제품 보기
툴
체험, 구매 & 영업
커뮤니케이션
Red Hat 소개
Red Hat은 Linux, 클라우드, 컨테이너, 쿠버네티스 등을 포함한 글로벌 엔터프라이즈 오픈소스 솔루션 공급업체입니다. Red Hat은 코어 데이터센터에서 네트워크 엣지에 이르기까지 다양한 플랫폼과 환경에서 기업의 업무 편의성을 높여 주는 강화된 기능의 솔루션을 제공합니다.