The first time I used gitlab to submit code in my work, it was automatically deployed to gitlab CICD to the pits encountered by k8s, and the process of final resolution.

background

I didn't build it from scratch, but under certain conditions, because I was responsible for the rewriting of a server in the cluster. The leader asked me to create a warehouse on gitlab and submit the code myself. I have never used gitlab before. The previous company used svn for work, so to me, everything is unknown. My project is written in golang.
My purpose is: package the project into a mirror —> upload to the mirror warehouse —> deploy to k8s

Build the warehouse first

Log in to gitlab—>choose New project, you will go to the following page, fill in according to your own situation

One thing to note here is that after you create the project, you will see some guidelines, such as asking you to upload a readme.md. I didn't have permission at the beginning, so I can't get anything done. Until you get permission, you can operate the warehouse.

After obtaining permission, first pull the warehouse to the local

Enter your project, select clone, then choose the method you want, use git clone to pull the warehouse to your local. After pulling, you can use git add. —>git commit -m "xxxx" —>git push origin master to submit to the warehouse.
Note: Generally, when git commits, some files need to be ignored, just add a .gitignore to the project directory.
The files I submitted are probably as follows, of which only two need to be known. Gitignore is used

to ignore some files that do not need to be submitted.
Gitlab-ci.yaml is used for automatic deployment

First explain gitlab cicd

In fact, this thing is not difficult, I don't know why there are so many explanations on the Internet, and what I cannot write is a long list of concepts that are not easy for novices to understand. cicd needs two things: .gitlab-ci.yaml file, gitlab-runner

.gitlab-ci.yaml
actually describes the automatic deployment process you need. For example, if you need to package a docker image and upload it, then you need to use its syntax in gitlab-ci, yaml to describe this process.
gitlab-runner
is easier to understand. I don’t know what kind of explanations on the Internet. Now that you have written an automatic deployment script, you need something to execute the automatic deployment script you wrote, and gitlab-runner is this thing (similar to a pod in k8s, if you are not right, welcome to point it out).

In fact, these two are very simple things, anyway, after I have understood them, I will just say so. The place where gitlab-runner runs is your gitlab project address. In other words, the script you write is equivalent to a linux machine with a folder for your project, and you write the script under this folder (This is my own understanding, and I did do this. If there is anything wrong, please discuss it) , you can write a script in your .gitlab-ci.yaml and use the ls, pwd commands to know Up.

Deployment phase

Write .gitlab-ci.yaml file

I didn’t know at the beginning, but I used golang’s cicd demo directly (you don’t need to add cicd to gitlab, you can choose demo). After execution, I found that in fact, .gitlab-ci.yaml is written as a shell script. (I didn't know at the time, in fact, this is related to gitlab-runner, I will talk about it later). This is simple.
Regarding the grammar, I won’t explain
it here. As it is a project, only part of it can be posted here. The
whole script is divided into three stages

stages:
    - build
    - docker_publish
    - deploy

After the build code is uploaded, write the script go build directly, for example in my file

build:
    image: golang:1.15.6
    stage: build
    before_script:
      - mkdir -p $GOPATH/src/$(dirname $REPO_NAME)
      - ln -svf $CI_PROJECT_DIR $GOPATH/src/$REPO_NAME
      - cd $GOPATH/src/$REPO_NAME
    script:
      - pwd
      - ls
      - cd realTimeMsg
      - go mod download
      - go build -o $CI_PROJECT_DIR/RtmServer
    artifacts:
      paths:
        - RtmServer
      expire_in: 2 mos

This is very easy to understand, mainly looking at the script, you can see it at a glance.

docker_pulish packages the output into a mirror. This requires docker to be used in docker, and services are as follows.

This build is not difficult, just upload the Dockerfile you wrote in gitlab and build it directly.

docker_publish:
  image: docker:latest
  services:
    - docker:dind
  script:
   	...
    - docker build -f Dockerfile --pull -t xxx
    - docker image ls 
    - docker push xxx

Some attention should be paid here. In the .gitlab-ci.yaml file, the environment variables that need to be defined can be set in setting—>cicd

deploy deployment, the biggest problem I encountered is here

In my deployment script, it just cannot be deployed in dev k8s. I used the script kubectl cluster-info and found that the place where my script is running is not my dev k8s at all, so it definitely cannot be deployed. In this case, I went to check.

The reason for this problem is: gitlab-runner does not run in the environment I want. Therefore, it cannot be associated with the cluster.
When I deployed the project, I did not create gitlab-runner, but my deployment script did run.
After inquiring, it turns out that there is a default shared gitlab-runner in the project I participated in, so I ran directly with this.

I first tried to add my project to k8s, which is this button. It turned out to be add. After I added it, it became this. The

method of adding is here: https://segmentfault.com/a/1190000020947651 , I refer to this article .
But it didn't solve my problem.

Finally, I registered a gitlab-runner for my project in the k8s environment of dev. My development environment already exists gitlab-runner. If yours does not exist, just install it.
After that, first open setting—>cicd—>runners

and then use gitlab-runner register to

input the url of the
previous runner image. Enter the token
entry and exit description of the previous runner image.
Enter the tag. This is very important, the .gitlab-ci.yaml script Through the tag associated runner
input selection execution method, I chose shell

After registration, you will find that setting—>cicd—>runners has one more runner

and still cannot be used here, even if the tag is associated in the .gitlab-ci.yaml file. Such association, add tags

deploy:
  image: dtzar/helm-kubectl:2.9.1
  stage: deploy
  tags:
    - goRtm

Because this runner can't run, if it can run, the front is green, and the tag has been changed. It is different from the corresponding one in the picture above. Explain.

I also need to call gitlab-runner run. After the call, it becomes green and ready to use. After


finishing this, I can automatically deploy to the k8s I want after submitting the code.

Because the article involves company projects, many things cannot be explained clearly. Probably it can only be written like this.