Rancher's Pipeline JAVA Demo

Rancher PIpeline

Pipeline, in a nutshell, is a set of workflow frameworks running on rancher that connect tasks that were originally run independently of individual or multiple nodes to achieve a complex release process that is difficult to accomplish with a single task.

Rancher Pipeline is primarily used to run continuous integration, continuous delivery, and continuous deployment tasks in Rancher environments, where Pipeline is the product of an extension of agile development, and we have to say continuous integration, continuous delivery and continuous deployment.

Continuous Integration: Code is integrated into the trunk frequently (multiple times a day). Each integration is validated through automated builds, including compilation, release, and automated testing, to identify integration errors early.

There are two main benefits:

• Quickly find errors. With each update, it is integrated into the trunk, which makes it easy to find errors quickly and locate errors.
• Prevents branches from significantly deviating from the trunk. If it is not often integrated, the trunk is constantly updated, resulting in future integration difficulties become larger, or even difficult to integrate.

The purpose of continuous integration is to enable rapid iteration of products while maintaining high quality. Its core measure is that the code is integrated into the trunk before it has to pass the automated test. You cannot integrate as long as there is a test case failure.

Continuous Delivery: Deploy the integrated code into a quasi-production environment that is closer to the real-world operating environment. For example, after we have completed the unit tests, we can deploy the code to more tests in the Staging environment where the database is connected. If the code is not problematic, you can continue to manually deploy to the production environment.

Continuous deployment: On the basis of continuous delivery, the premise of deployment is the ability to automate the steps of testing, building, deployment, and so on.

Rancher pipeline is made up of Rancherui service, pipeline service and Jenkins three parts,

Gossip less, do not understand the direct can crossing net, official website address. It's a direct whole demo.

Rancher Pipeline DEMO

1. Ranche Pipeline is a new feature released by Rancher V1.6.13 update. So if it's not V1.6.13 first to upgrade the rancher, the upgrade method

2, after upgrading to V1.6.13, we can search the App Store "Pipeline", click on the deployment is OK. When the deployment is complete, a more streamlined page will appear in the UI. (Here the environment is before the deployment is OK)

3, Rancher pipeline, Rancher users can simultaneously use GitHub and Gitlab for OAuth-based authentication, without plugins, to simultaneously pull, use, and manage code hosted on GitHub and Gitlab in a single environment.

The case is the OAuth validation in Gitlab:

1, because the Gitlab is privatized, so click on privatisation deployment.

2. Fill in Gitlab address

3. Click Gitlab to verify

The name here is optional. Redirect URI fill in the address provided by the first picture.

Backfill the application ID and secret record to the first page

Such a pipeline is ready for completion. Now let's talk about the Java demo

First, we first introduce several basic concepts of pipeline:

• Source code: Integrated Gitlab Repository.

• Stage: A pipeline can be divided into stages, each stage representing a set of actions. Note that stage is the concept of a logical grouping.
• Step: Steps is the most basic operating unit, small to create a directory, large to build a docker image.

Configure source Code To configure a project that you want to publish.

To add a stage, the first configuration should be a packaged compilation, named Build. Can be freely selected in both serial or parallel tasks, and a well-integrated approval system can greatly improve the security controllability of CI/CD pipeline.

Add a built task because it is a Java Gradle project, so you need a gradle dependency.

Take a look at Gradle's dockerfile, build it into a mirror by dockerfile, and upload it to your own image library.

1From OpenJDK:8-JDK2 3CMD ["Gradle"]4 5ENV gradle_home/opt/Gradle6ENV gradle_version2.14.17 8ARG gradle_download_sha256=cfc61eda71f2d12a572822644ce13d2919407595c2aec3e3566d2aab6f97ef399RUN Set-o Errexit-o nounsetTen&&Echo "Downloading Gradle"  One&&wget--no-verbose--output-document=gradle.Zip "Https://services.gradle.org/distributions/gradle-${gradle_version}-bin.zip"  A          -&&Echo "Checking Download Hash"  -&&Echo "${gradle_download_sha256} *gradle.zip"| Sha256sum--check-  the          -&&Echo "Installing Gradle"  -&&UnzipGradle.Zip  -&&RMGradle.Zip  +&&MV "Gradle-${gradle_version}" "${gradle_home}/"  -&&LN--symbolic"${gradle_home}/bin/gradle"/usr/bin/Gradle +          A&&Echo "Adding gradle user and group"  at&&mkdir-p/home/gradle/. Gradle -&&Chown--recursive root:root/home/Gradle -          -&&Echo "symlinking root Gradle cache to Gradle Gradle cache"  -&&LN-s/home/gradle/.gradle/root/. Gradle -  in # Create Gradle Volume - USER Root toVOLUME"/home/gradle/.gradle" +workdir/home/Gradle -  theRUN Set-o Errexit-o nounset *&&Echo "Testing Gradle Installation"  $&& Gradle--version

Built by the Gradle environment under the Gradle mirror.

Then I'll pack it up and upload it to the product library

Update stack

This is a simple pipeline process.

Pull source-->> Build--->> package--->> release.

We can define the pipeline to fit the situation.

Recommended Articles for rancher pipeline

Preliminary study on Rancher Pipeline

Video Tutorials

Rancher's Pipeline JAVA Demo