[Kubernetes series] Part 7: component deployment of CI/CD

Posted by zfred09 on Thu, 24 Oct 2019 05:59:24 +0200

Preface

In response to the needs of agile development, a higher standard is proposed for ci (continuous integration) / CD (continuous delivery). Today, we will discuss how to use CI/CD based on open source components (gitlab/jenkins/harbor/kubernetes) to enable the development, operation and maintenance of the team.

Core components

Basic process

  1. Create the corresponding project in GitLab.
  2. Developers submit code to GitLab.
  3. Jenkins creates the corresponding Job to integrate the Git address and Kubernetes cluster of the project.
  4. If there is a configuration hook, the Push code will automatically trigger the Jenkins build. If there is no configuration hook, it needs to be built manually.
  5. Jenkins controls Kubernetes (using the Kubernetes plug-in) to create Jenkins Slave.
  6. Jenkins Slave performs the build according to the steps defined by the Pipeline.

    1. Check out code, package and compile.
    2. Image generation through Dockerfile.
    3. Push the image to private Harbor.
    4. Jenkins again controls Kubernetes for the latest image deployment.

In the first place,

  • The above steps are general steps. In the middle, steps such as automated testing may also be involved, which can be added according to business scenarios.
  • The above pipeline steps are generally determined by Jenkins file in the root directory of the application code base, which Jenkins will automatically read; in addition, if it is necessary to implement strong control over the specific application pipeline, you can manage the Jenkins file template independently, and then generate the pipeline immediately according to the jenkins API interface.
  • The Dockerfile used by default is placed in the root directory of the code warehouse.

Component deployment

  1. kubernetes Part 3 Kubernetes cluster installation and deployment
  2. gitlab How to build your own GitLab Library
  3. harbor Installation configuration guide
  4. jenkins

_Note: This article mainly describes the deployment and configuration of jenkins. If you have any problems with the deployment of other components, please leave a message.

Jenkins deployment and configuration

Note:

  • The following yaml files are all in the / home / Jenkins [deploy directory of k8s master node.
  • Annotation for deployment.yaml of deployment example

    • NodeName IPAddress, IPAddress please confirm it is a valid ip.
    • In the example, the directory / var / jenkins? Home of jenkins is directly mounted to the host? Path. If you have conditions, it is recommended to replace it with shared storage.
    • Because the basic image of Jenkins master is from the public network, the k8s maste r node should also be able to access the external network, or you can push Jenkins / Jenkins: lts Alpine to your own intranet image warehouse.
  • Notes for deploying the example's ingress.yaml

    • You also need to access the office network (outside the cluster). Please change jenkins.dev.hanker.net to a valid domain name address, or you can declare service in the form of NodePort, and then you can access Jenkins directly in the form of ip:port.

1. Prepare to deploy yaml

  • deployment.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: devops
  
# Deployment 
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: jenkins
  namespace: devops
spec:
  replicas: 1
  revisionHistoryLimit: 3
  template:
    metadata:
      labels:
        app: jenkins
    spec:
      nodeName: 1.1.1.1
      serviceAccountName: jenkins-admin
      containers:
      - image: jenkins/jenkins:lts-alpine
        imagePullPolicy: IfNotPresent
        name: jenkins
        volumeMounts:
        - name: jenkins-volume
          mountPath: /var/jenkins_home
        - name: jenkins-localtime
          mountPath: /etc/localtime
        env:
          - name: JAVA_OPTS
            value: '-Xms256m -Xmx1024m -Duser.timezone=Asia/Shanghai'
          - name: TRY_UPGRADE_IF_NO_MARKER
            value: 'true'
        ports:
        - name: http
          containerPort: 8080
        - name: agent
          containerPort: 50000
        resources:
          requests:
            cpu: 1000m
            memory: 1Gi
          limits:
            cpu: 1200m
            memory: 2Gi
      volumes:
        - name: jenkins-localtime
          hostPath:
            path: /etc/localtime
        - name: jenkins-volume
          hostPath:
            path: /home/jenkins/jenkins_home
  • Configure service, services.yaml
---
apiVersion: v1
kind: Service
metadata:
  name: jenkins-service
  namespace: devops
spec:
  ports:
  - name: http
    protocol: TCP
    port: 8080
    targetPort: 8080
  - port: 50000
    targetPort: 50000
    name: agent
  selector:
    app: jenkins
  • Authorize jenkins to visit rbac.yaml for k8s
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: jenkins
  name: jenkins-admin
  namespace: devops

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: jenkins-rbac
  namespace: devops
rules:
  - apiGroups: ["","extensions","app"]
    resources: ["pods","pods/exec","deployments","replicasets"]
    verbs: ["get","list","watch","create","update","patch","delete"]

---

apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: jenkins-admin
  namespace: devops
  labels:
    k8s-app: jenkins
subjects:
  - kind: ServiceAccount
    name: jenkins-admin
    namespace: devops
roleRef:
  kind: ClusterRole
  name: jenkins-rbac
  apiGroup: rbac.authorization.k8s.io
  • In order to facilitate access to the office network (outside the cluster), ingress.yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: jenkins-ingress
  namespace: devops
spec:
  rules:
  - host: jenkins.dev.hanker.net
    http:
      paths:
      - backend:
          serviceName: jenkins-service
          servicePort: 8080
        path: /

2. Apply yaml and deploy jenkins

$ pwd
$ /home/jenkins_deploy
$ kubectl apply -f *.yaml

3. Confirm the jenkins service status

[root@node0 jenkins_deploy]# kubectl -n devops get deployment jenkins
NAME      READY   UP-TO-DATE   AVAILABLE   AGE
jenkins   1/1     1            1           51d
[root@node0 jenkins_deploy]# 

4. Access jenkins installation plug-ins and settings

Note: the domain name jenkins.dev.hanker.net declared in step 1 has been resolved to ingress, so it can be accessed directly; if you want to access Jenkins through a custom domain name, please resolve to the correct ingress service node.

  1. Make sure you have installed the kubernetes/ kubernetes cli plug-in

_Operation instructions: Manage Jenkins - > Manage Plugins

You should be able to get the Jenkins master password through similar instructions.

$ kubectl -n devops exec jenkins-pod-name cat /var/jenkins_home/secrets/initialAdminPassword

  1. Configure Kubernetes plug-in

_Operation instructions: Manage Jenkins - > Configure System


Note in the figure:

  1. Please change it to k8s master corresponding to your environment
  2. Declare the command space of Jenkins agent, which can also be adjusted as needed.
  3. The access address of Jenkins master. This example uses the form of service name.
  4. Test the connection with k8s sharing group. If you get the
    Connection test successful, congratulations on continuing.
  5. Configure Kubernetes Pod Template

Note in the figure:

  1. Set up the basic Jenkins agent image;
  2. Specify working directory;

    • If you need to download, export, or cache build, it makes sense to specify a directory for shared storage.
  3. Set directory mount

    • As in step 2, you can mount the host directory or network storage to Jenkins agent.

Topics: Linux jenkins Kubernetes GitLab network