Shulou(Shulou.com)06/03 Report--

This series of articles:

Chapter 1: Nine Analysis takes you to play with rancher-installation

Chapter 2: Nine Analysis takes you to play rancher-Import Cluster

Chapter 3: Nine Analysis takes you to play rancher-Integrated gitlab

Chapter 4: Nine Analysis takes you to play rancher-Integrated harbor

Chapter 5: Nine Analysis takes you to play with rancher-Pipeline release

Catalogue

1 preface

2 set the assembly line

2.1 associated code base

2.1.1 specify project space

2.1.2 set up the code base

2.2 Associated Mirror Library

2.3 Global pipelining settings

2.4 Project space pipelining settings

3 execution pipeline

4 pipelined execution successfully

1 preface

This article is configured on the basis of "Nine Analysis takes you to play rancher-Integrated gitlab" in the previous chapter, so make sure that rancher and gitlab are associated before releasing the rancher pipeline.

Pipeline is the implementation of DevOps, which provides a very friendly interface UI, so that developers can complete the release and launch of the entire micro-service just through the mouse. In rancher, a microservice corresponds to a pipeline.

2 set the assembly line

To set up the pipeline, you need to set the global pipeline and the project pipeline at the same time. The setting of the global pipeline will affect the project pipeline.

2.1 associated code base

2.1.1 specify project space

Configure pipelining under the default project space in this article:

Under the default project space, select "Resources"-> "Pipeline" menu:

2.1.2 set up the code base

Select the set Code Base button:

Select the Refresh Code Base button:

Because gitlab is already associated with rancher, after refreshing the code base, your service code in gitlab will be displayed:

Enable services:

Click finish:

2.2 Associated Mirror Library

In this paper, we associate the mirror library in default space.

Add credentials:

Fill in the relevant information:

2.3 Global pipelining settings

Select the specified cluster (zcy-arch-k8s), then select "tools", and finally select "pipeline":

The modifications are as follows:

The global pipeline will control the concurrent number of project pipelines, the proportion of resources, and so on.

2.4 Project space pipelining settings

The project space pipeline needs to select both "zcy-arch-k8s" and "project space" (default):

Select the Edit configuration submenu:

Click on the "set assembly line" link and the figure is as follows:

Pipeline "stages" can be added according to their respective needs. In general, four stages of the entire assembly line are sufficient, that is:

1 clone phase: this is the default required phase of the system, which refers to downloading the source code of the microservice from the code base.

2 build phase: compile the source code and generate the Dockerfile file

3 publish phase: generate an image based on the Dockerfile file of the previous stage, and then upload the image to the specified image repository

4 deploy phase: download the service image generated in the previous stage from the image repository, and then start the container to run

Take the java language as an example, create the rancher general pipeline file. Rancher-pipeline.yml in the service (here: chapter-001-helloworld) code base, as shown below:

The file defines three stages of the pipeline, and the contents of the file are as follows:

Stages:

-name: Build

Steps:

-runScriptConfig:

Image: jiuxi.harbor.org/stable/maven-3.6.0-jdk-8

ShellScript: mvn-B-U-DskipTests clean package spring-boot:repackage

-name: Publish

Steps:

-publishImageConfig:

DockerfilePath:. / Dockerfile

BuildContext:.

Tag: stable/$ {CICD_GIT_REPO_NAME}: ${CICD_GIT_COMMIT}

PushRemote: true

Registry: jiuxi.harbor.org

Env:

PLUGIN_DEBUG: "true"

PLUGIN_INSECURE: "true"

-name: Deploy

Steps:

-applyYamlConfig:

Path:. / Deployment.yaml

Notification: {}

In the Publish phase, the jar file generated in the Build phase is made into a service image based on the predefined Dockerfile file, and then pushed to the private image repository. The custom Dockerfile file is defined as follows:

FROM jiuxi.harbor.org/stable/java:8

MAINTAINER "jiuxi"

ADD. / target/application.jar application.jar

EXPOSE 8080

CMD ["/ bin/sh", "- c", "java-jar application.jar"]

The Deploy phase is to execute the custom deployment file Deployment.yaml in K8s, create the service and deployment resources for the service, and run the container. The custom Deployment.yaml file is as follows:

ApiVersion: v1

Kind: Service

Metadata:

Name: ${CICD_GIT_REPO_NAME}

Labels:

App: ${CICD_GIT_REPO_NAME}

Spec:

Type: ClusterIP

Selector:

App: ${CICD_GIT_REPO_NAME}

Ports:

-port: 8080

TargetPort: 8080

-

ApiVersion: apps/v1

Kind: Deployment

Metadata:

Name: ${CICD_GIT_REPO_NAME}

Spec:

Replicas: 1

Selector:

MatchLabels:

App: ${CICD_GIT_REPO_NAME}

MinReadySeconds: 5

Strategy:

Type: RollingUpdate

Template:

Metadata:

Labels:

App: ${CICD_GIT_REPO_NAME}

Spec:

Containers:

-name: ${CICD_GIT_REPO_NAME}

Image: jiuxi.harbor.org/stable/$ {CICD_GIT_REPO_NAME}: ${CICD_GIT_COMMIT}

LivenessProbe:

TcpSocket:

Port: 8080

ImagePullPolicy: Always

Env:

-name: TZ

Value: "Asia/Shanghai"

-name: MY_POD_IP

ValueFrom:

FieldRef:

FieldPath: status.podIP

-name: jiuxi_logs_$ {CICD_GIT_REPO_NAME}-stdout

Value: "stdout"

-name: jiuxi_logs_$ {CICD_GIT_REPO_NAME}-logs

Value: "/ data/logs/$ {CICD_GIT_REPO_NAME} / * .log"

VolumeMounts:

-name: logs

MountPath: / data/logs/$ {CICD_GIT_REPO_NAME}

-name: time

MountPath: / etc/localtime

Resources:

Limits:

Memory: 1Gi

Volumes:

-name: time

HostPath:

Path: / etc/localtime

-name: logs

EmptyDir: {}

RestartPolicy: Always

Submit .rancher-pipeline.yaml, Deployment.yaml, Dockerfile files to gitlab. Then click "set Code Base" again in rancher:

"Refresh Code Base", click "finish":

Then click "Edit configuration":

The pipeline has been automatically configured:

Check whether the address of the image repository in the Publish phase is correct:

Click the finish button:

Click OK, the configuration of the entire assembly line has been completed.

3 execution pipeline

Select the run menu to execute the pipeline:

Select the specified code branch. Here is "master":

Click "run":

The execution of the pipeline starts. When you start the pipeline for the first time, you need to download jenkins, minio, docker-registry and other images, so it takes a certain amount of time. If the execution is reported as follows:

This indicates that the pipeline runtime container does not recognize the custom domain name. You need to restart the pipeline.

After startup, jenkins will dynamically generate the pipeline container. At this time, you need to enter its console while the pipeline container is generated (so you'd better open two rancher pages at the same time, one is the pipelined execution page, as shown above, and the other is the default project space page, as shown below):

Note that when jenkins generates the pipeline container, the page refreshes automatically (so you don't have to refresh the page manually); second, you need to make sure that the state in front of the pipeline is Running, and the "more" button after the operation can display the "execute Command Line" menu:

In the pop-up "execute Command Line" interface, enter the following command to modify the / etc/hosts file:

Echo "10.110.101.100 jiuxi.gitlab.com jiuxi.harbor.org jiuxi.nexus.org" > > / etc/hosts

4 pipelined execution successfully

View services under the default project space:

Chapter-001-helloworld was found to have run successfully:

Click to enter chapter-001-helloworld to view the pod log:

The discovery service is running properly:

Since then, the rancher assembly line has been released easily.

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.