Shulou(Shulou.com)05/31 Report--

Based on KubeSphere CI/CD how to release the Spring Boot project to Kubernetes, many novices are not very clear about this. In order to help you solve this problem, the following editor will explain it in detail. People with this need can come and learn. I hope you can get something.

The open source KubeSphere container platform demonstrates how to create a pipeline through Jenkinsfile in the GitHub repository. The pipeline consists of eight stages, and finally a Hello World page is deployed to different namespace in the Kubernetes cluster.

Overview of pipelining

The following flowchart briefly illustrates the complete working process of the assembly line:

Process description:

Stage one. Checkout SCM: pull GitHub warehouse code

Stage two. Unit test: unit test. Proceed to the following task if the test passes.

Stage three. SonarQube analysis:sonarQube code quality detection

Stage four. Build & push snapshot image: build the image based on the branch selected in the behavior policy, and push the tag as SNAPSHOT-$BRANCH_NAME-$BUILD_NUMBER to Harbor (where $BUILD_NUMBER is the running sequence number of the pipeline activity list).

Stage five. Push latest image: type the master branch with tag as latest, and push it to DockerHub.

Stage six. Deploy to dev: deploy the master branch to the Dev environment, which requires auditing at this stage.

Stage seven. Push with tag: generate tag, release it to GitHub, and push it to DockerHub.

Stage eight. Deploy to production: deploy the released tag to the Production environment.

Create credential

Log in to KubeSphere using project-regular, enter the created devops-demo project, and start creating credentials.

1. The Jenkinsfile in this sample code repository requires a total of three credentials (credentials), such as DockerHub, GitHub and kubeconfig (kubeconfig is used to access the running Kubernetes cluster). 2. Then create a Token of Java and copy it.

3. Finally, enter the DevOps project of devops-demo in KubeSphere, similar to the above step. Click create under credentials to create a certificate with a secret text type. The certificate ID is named sonar-token, and the key is the token information copied in the previous step. Click OK when you are finished.

At this point, the four credentials have been created. The next step is to modify the corresponding four credential ID in the jenkinsfile in the sample repository for the credential ID created by the user.

The first step in modifying Jenkinsfile: Fork Project

Log in to GitHub and devops-java-sample Fork the GitHub repository used in this example to your personal GitHub.

Step 2: modify Jenkinsfile

1. After Fork to your personal GitHub, enter Jenkinsfile-online in the root directory.

2. Click the edit icon in GitHub UI to modify the value of the following environment variable (environment).

The meaning of the modified item value DOCKER_CREDENTIAL_IDdockerhub-id enter the DockerHub credential ID in the create credential step, which is used to log in to your DockerHubGITHUB_CREDENTIAL_IDgithub-id and enter the GitHub credential ID in the credential creation step, which is used to push tag to the GitHub repository KUBECONFIG_CREDENTIAL_IDdemo-kubeconfigkubeconfig credential ID, to access the running Kubernetes cluster REGISTRYdocker. Io defaults to the docker.io domain name, and the push DOCKERHUB_NAMESPACEyour-dockerhub-account for the image is replaced with your DockerHub account name.

(it can also be the Organization name under the account) GITHUB_ACCOUNTyour-github-account is replaced with your GitHub account name. For example, https://github.com/kubesphere/, enter kubesphere (it can also be the Organization name under the account) APP_NAMEdevops-java-sample application name SONAR_CREDENTIAL_IDsonar-token, enter the SonarQube token credential ID in the steps of creating credentials, and use it to check the code quality.

Note: the parameter-o of the mvn command in Jenkinsfile indicates that offline mode is turned on. In this example, in order to adapt to the interference of the network in some environments, and to avoid taking too long to download dependencies, the download of related dependencies has been completed in advance and offline mode is enabled by default.

3. After modifying the above environment variables, click Commit changes to submit the update to the current master branch.

Create a project

According to the yaml template file of the sample project, the CI/CD pipeline will eventually deploy the example to the two project (Namespace) environments of Dev and Production, namely kubesphere-sample-dev and kubesphere-sample-prod. These two projects need to be created in the console in advance. Refer to the following steps to create the project.

Step 1: create the first project

1. Log in to KubeSphere using the project-admin account of the project administrator. Under the enterprise space (demo-workspace) created earlier, click Project → to create a resource-based project as the development environment for this example. Fill in the basic information of the project, and then click next.

Name: fixed as kubesphere-sample-dev. If you need to modify the project name, you need to modify namespace in the yaml template file.

Aliases: customizable, such as development environment

Description information: the project can be briefly introduced to facilitate users to further understand

2. There are no resource requests and restrictions in this example, so there is no need to modify the default values in the advanced settings. Click create and the project can be created successfully.

Step 2: invite members

After the first project is created, the project administrator project-admin is also required to invite the current project ordinary user project-regular to enter the kubesphere-sample-dev project, enter the "Project Settings" → "Project members", click "invite members" to select the invite project-regular and grant the operator role.

Step 3: create a second project

As above, refer to the above two steps to create a project named kubesphere-sample-prod as the production environment, and invite the ordinary user project-regular to enter the kubesphere-sample-prod project and grant the operator role.

Note: when the subsequent execution of the CI/CD pipeline is successful, you will see the deployment (Deployment) and service (Service) created by the pipeline in the kubesphere-sample-dev and kubesphere-sample-prod projects.

Step 1 of creating an assembly line: fill in the basic information

1. Enter the created DevOps project, select the pipeline in the left menu bar, and then click create.

2. In the pop-up window, enter the basic information of the pipeline.

Name: a concise and clear name for the created assembly line, which is easy to understand and search

Description: a brief introduction to the main features of the pipeline to help further understand the role of the pipeline

Code repository: click to select a code repository. The code repository must already exist in Jenkinsfile

Step 2: add a warehouse

1. Click Code Warehouse to add a Github repository as an example.

2. Click "get Token" in the pop-up window.

3. Enter Token description on the access token page of GitHub and briefly describe the token, such as DevOps demo. There is no need to modify it in Select scopes. Click Generate token,GitHub to generate a string of letters and numbers of token to access the GitHub repo under the current account.

4. Copy the generated token, enter the token in the KubeSphere Token box, and then click Save.

5. After the verification is passed, all the code bases of the users associated with this Token will be listed on the right, and one of the repositories with Jenkinsfile will be selected. For example, select the prepared sample warehouse devops-java-sample here, click to select this warehouse, and click next when you are finished.

Step 3: advanced Settings

After completing the relevant settings of the code warehouse, go to the advanced settings page. The advanced settings support customization of pipeline construction records, behavior strategies, periodic scans and other settings. The following is a simple explanation of the relevant configurations used.

1. In the build settings, check discard the old build. Here, the number of days and the maximum number of retained branches defaults to-1.

Description:

The two options of keeping the number of days and the maximum number of branches can act on the branch at the same time, and the branch will be discarded as long as the number of days and the number of branches do not meet any of the set conditions. Assuming that the number of days and number of retention set is 2 and 3, the branch will be discarded once the number of days of retention exceeds 2 or the number of retention exceeds 3. The default two values are-1, which means that the branch is not automatically deleted.

Discarding the old branch determines when the branch record of the project should be discarded. Branch records include console output, archived artifacts, and other metadata related to a particular branch. Keeping fewer branches saves disk space used by Jenkins, and we provide two options to determine when old branches should be discarded:

Number of days to retain the branch: if the branch reaches a certain number of days, the branch is discarded.

Number of reserved branches: if a certain number of branches already exist, discard the oldest branches.

2. In the behavior policy, KubeSphere adds three policies by default. Since the policy of finding PR from the Fork repository has not been used in this example, you can delete the policy here and click the delete button on the right.

Description:

Three types of discovery policies are supported. It is important to note that when the Jenkins pipeline is triggered, the PR (Pull Request) submitted by the developer is also considered a separate branch.

Discover branches:

Exclude branches that are also submitted by PR: select to indicate that CI will not scan source branches (such as Origin's master branch), that is, branches that need to be merge

Only branches that are submitted as PR: scan only PR branches

All branches: all branches in the pulled warehouse (origin)

PR was found in the original warehouse:

Source code version of PR merged with target branch: a discovery operation that creates and runs the pipeline based on the combined source code version of PR and target branch

Source code version of PR itself: a discovery operation that creates and runs the pipeline based on the source code version of PR itself

When PR is discovered, two pipelines are created, one pipeline uses the source code version of PR itself, and one pipeline uses the source code version of PR merged with the target branch: two pipelines will be created for each discovery operation, the first pipeline uses the source code version of PR itself, and the second pipeline uses the source code version of the merged PR and target branch

3. The default script path is Jenkinsfile. Please modify it to Jenkinsfile-online.

Note: the path is the path of Jenkinsfile in the code repository, indicating that it is in the root directory of the sample repository. If the file location changes, you need to modify its script path.

4. Check the scan Repo Trigger box if there is no scan trigger, then scan regularly. The scan interval can be set according to the team habit. In this example, it is set to 5 minutes.

Note: regular scanning is to set a cycle to let the pipeline periodically scan the remote warehouse and check the warehouse for code updates or new PR according to the behavior policy.

Webhook push:

Webhook is an efficient way to allow pipelining to detect changes in remote repositories and automatically trigger new operations. Jenkins automatic scanning triggered by GitHub and Git (such as Gitlab) should be based on Webhook, supplemented by regular scanning in KubeSphere. In this example, you can run the pipeline manually. If you need to set the remote branch to scan automatically and trigger it, for more information, please see setting automatic trigger scan-GitHub SCM.

Click create after completing the advanced settings.

Step 4: run the assembly line

After the pipeline is created, click the refresh button of the browser to see a running record after the remote branch is automatically triggered.

1. Click run on the right, and the branch in the code repository will be automatically scanned according to the behavior policy in the previous step. Select the master branch that needs to build the pipeline in the pop-up window, and the system will load the Jenkinsfile-online according to the input branch (default is the Jenkinsfile in the root directory).

2. Since the default value of TAG_NAME: defaultValue is not set in the Jenkinsfile-online of the warehouse, the TAG_NAME here can enter a tag number, such as v0.0.1.

3. Click OK and a new assembly line will be generated to start running.

Note: tag is used to generate release and images with tag in Github and DockerHub, respectively. Note: when actively running the pipeline to release the release, the TAG_NAME should not repeat the tag name that existed in the previous code repository, which will cause the pipeline to fail.

At this point, the pipeline has been created and started running.

Note: click on the branch to switch to the branch list to see which branches the pipeline is running on, and the branch here depends on the discovery branch policy of the previous behavior policy.

Step 5: audit the assembly line

To facilitate the demonstration, the current account is used for verification by default. When the pipeline reaches the input step, the status will be paused. You need to click continue manually before the pipeline can continue. Note that three phases (stage) are defined in Jenkinsfile-online to deploy to the Dev environment and Production environment and to push tag, so the three phases deploy to dev, push with tag and deploy to production need to be audited three times in turn in the pipeline. If you do not audit or click to terminate, the pipeline will not continue to run.

Note: in actual development and production scenarios, administrators or operation and maintenance personnel with higher permissions may be required to review pipelines and images, and decide whether to push them to code or image repositories and deploy them to development or production environments. The input step in Jenkinsfile supports specifying the user audit pipeline. For example, to specify a user named project-admin to audit, you can append a field to the input function of Jenkinsfile. If multiple users are separated by commas, as shown below:

Input (id: 'release-image-with-tag', message:' release image with tag?', submitter: 'project-admin,project-admin1') View pipeline

1. Click the serial number of the currently running pipeline under the activity list in the pipeline, and the page shows the running status of each step in the pipeline. Note that the pipeline was in the initialization stage when it was first created, and only the log window may be displayed. You can see the pipeline after initialization (about one minute). The black box marks the step name of the pipeline. In the example, the pipeline has a total of 8 stage, which are defined in Jenkinsfile-online.

2. Click View Log on the top right of the current page to view the pipeline running log. The page shows the specific log, running status and time of each step. Click on a specific stage on the left to view the specific log. The log can be downloaded locally. If an error occurs, it is easier to analyze and locate the problem by downloading it locally.

Verify the running result

1. If the pipeline is executed successfully, click the code quality under the pipeline to see the code quality test result that has passed SonarQube, as shown in the figure below (for reference only).

2. The Docker image of the pipelined final build will also be successfully push to DockerHub. We have configured DockerHub in Jenkinsfile-online. Log in to DockerHub to check the push results of the image. You can see that the image with tag of snapshot, TAG_NAME (master-1) and latest has been push to DockerHub, and a new tag and release have been generated in GitHub. The Hello World sample page will eventually be deployed as deployment and service to KubeSphere's kubesphere-sample-dev and kubesphere-sample-prod project environments, respectively.

Project (Namespace) deployment (Deployment) Service (Service) Dev http://{$Virtual IP}: {$8080}

Or http://{$ private network / public network IP}: {$30861} kubesphere-sample-devks-sample-devks-sample-devProduction http://{$Virtual IP}: {$8080}

Or http://{$ private network / public network IP}: {$30961} kubesphere-sample-prodks-sampleks-sample

3. You can go back to the project list through KubeSphere and check the status of the deployment and services in the two previously created projects. For example, the following looks at the deployment under the kubesphere-sample-prod project.

Enter the project, click the workload → deployment in the menu bar on the left, and you can see that the ks-sample has been created successfully. Normally, the status of the deployment should show that it is running.

4. Select Network and Service → service in the menu bar to view the corresponding service. You can see that the Virtual IP of this service is 10.233.42.3, and the exposed node port (NodePort) is 30961.

View Servic

5. Looking at the image pushed to your personal DockerHub, you can see that devops-java-sample is the value of APP_NAME, and tag is also the tag defined in jenkinsfile-online.

6. Click release to view the v0.0.1 tag and release from Fork to your personal GitHub repo, which is generated by push with tag in jenkinsfile.

Access the sample service

If you access the deployed HelloWorld sample service in the private network environment, you can log in to the cluster node through SSH, or use the cluster administrator to log in to KubeSphere and enter the following command in web kubectl to verify the access, where Cluster IP and node port (NodePort) can be viewed in the services under the corresponding project:

Verify the sample service for the Dev environment

# curl {$Virtual IP}: {$Port} or curl {$intranet IP}: {$NodePort} curl 10.233.40.5 8080 HelloMagi World!

Verify the sample service for the Prodcution environment

# curl {$Virtual IP}: {$Port} or curl {$intranet IP}: {$NodePort} curl 10.233.42.3 Virgo 8080 HelloMagi World!

KubeSphere (https://github.com/kubesphere/kubesphere) is an open source application-centric container management platform that supports deployment on any infrastructure and provides easy-to-use UI, which greatly reduces the complexity of daily development, testing, operation and maintenance, and aims to solve the storage, network, security and ease of use of Kubernetes itself. Help enterprises easily cope with business scenarios such as agile development and automatic monitoring and maintenance, end-to-end application delivery, micro-service governance, multi-tenant management, multi-cluster management, service and network management, image warehouse, AI platform, edge computing and so on.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.