A primeira vez que usei o gitlab para enviar código em meu trabalho, ele foi automaticamente implantado no gitlab CICD para os poços encontrados pelo k8s e o processo de resolução final.

fundo

Eu não construí do zero, mas sob certas condições, porque fui responsável pela reescrita de um servidor no cluster.O líder me pediu para criar um warehouse no gitlab e enviar o código sozinho. Nunca usei o gitlab antes, a empresa anterior usava o svn para trabalhar, então para mim tudo é desconhecido. Meu projeto foi escrito em golang.
Meu objetivo é: empacotar o projeto em um espelho -> fazer upload para o warehouse espelho -> implantar no k8s

Construa o armazém primeiro

Faça login no gitlab—> escolha Novo projeto, você irá para a página seguinte, preencha de acordo com sua própria situação

Uma coisa a observar aqui é que, depois de criar o projeto, você verá algumas diretrizes, como solicitar que você carregue um readme.md. Eu não tinha permissão no início, então não posso fazer nada. Até obter permissão, você pode operar o warehouse.

Depois de obter permissão, primeiro leve o armazém para o local

Digite seu projeto, selecione clone e escolha o método que deseja, use git clone para puxar o warehouse para seu local. Após o pull, você pode usar git add. -> git commit -m “xxxx” -> git push origin master para enviar ao warehouse.
Nota: Geralmente, quando git commits, alguns arquivos precisam ser ignorados, apenas adicione um .gitignore ao diretório do projeto.
Os arquivos que enviei são provavelmente os seguintes, dos quais apenas dois precisam ser conhecidos. Gitignore é usado

para ignorar alguns arquivos que não precisam ser enviados.
Gitlab-ci.yaml é usado para implantação automática

Primeiro, explique o gitlab cicd

Na verdade, isso não é difícil, não sei por que existem tantas explicações na Internet, e o que não consigo escrever é uma longa lista de conceitos que não são fáceis de entender para os novatos. cicd precisa de duas coisas: arquivo .gitlab-ci.yaml, gitlab-runner

.gitlab-ci.yaml
na verdade descreve o processo de implantação automática de que você precisa. Por exemplo, se você precisa empacotar uma imagem docker e carregá-la, então você precisa usar sua sintaxe em gitlab-ci, yaml para descrever este processo.
gitlab-runner
é mais fácil de entender. Não sei que tipo de explicações na Internet. Agora que você escreveu um script de implantação automática, você precisa de algo para executar o script de implantação automática que você escreveu, e gitlab-runner é isso (semelhante a um pod em k8s, se você não estiver certo, bem-vindo).

Na verdade, essas duas coisas são muito simples, de qualquer forma, depois de entendê-las, direi apenas isso. O local onde o gitlab-runner é executado é o endereço do seu projeto gitlab. Em outras palavras, o script que você escreve é ​​equivalente a uma máquina linux com uma pasta para o seu projeto, e você escreve o script nesta pasta (este é o meu próprio entendimento, e Eu fiz isso. Se houver algo errado, por favor, discuta) , você pode escrever um script em seu .gitlab-ci.yaml e usar os comandos ls, pwd para saber o Up.

Fase de implantação

Grave o arquivo .gitlab-ci.yaml

Eu não sabia no início, mas usei a demonstração cicd do golang diretamente (você não precisa adicionar cicd ao gitlab, você pode escolher a demonstração). Após a execução, descobri que, na verdade, .gitlab-ci.yaml é escrito como um script de shell (eu não sabia na época, na verdade, isso está relacionado ao gitlab-runner, falarei sobre isso mais tarde). Isso é simples.
Quanto à gramática, não vou explicar aqui.
Por se tratar de um projeto, só uma parte dele pode ser postada aqui.
Todo o roteiro está dividido em três etapas

stages:
    - build
    - docker_publish
    - deploy

Depois que o código de construção for carregado, escreva o script e vá construir diretamente, por exemplo em meu arquivo

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

Isso é muito fácil de entender, principalmente olhando o script, dá para ver de relance.

docker_pulish empacota a saída em um espelho. Isso requer que o docker seja usado no docker e os serviços são os seguintes.

Esta compilação não é difícil, basta fazer upload do Dockerfile que você escreveu no gitlab e compilá-lo diretamente.

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

Alguma atenção deve ser dada aqui. No arquivo .gitlab-ci.yaml, as variáveis ​​de ambiente que precisam ser definidas podem ser definidas em setting—> cicd

implantar implantação, o maior problema que encontrei é aqui

Em meu script de implantação, ele simplesmente não pode ser implantado em dev k8s. Usei o script kubectl cluster-info e descobri que o lugar onde meu script é executado não é meu dev k8s, então definitivamente não posso implantar. Nesse caso, fui verificar.

O motivo desse problema é: gitlab-runner não funciona no ambiente que desejo. Portanto, ele não pode ser associado ao cluster.
Quando implantei o projeto, não criei gitlab-runner, mas meu script de implantação foi executado.
Depois de perguntar, descobri que há um gitlab-runner compartilhado padrão no projeto do qual participei, então executei diretamente com ele.

Tentei primeiro adicionar o meu projeto ao k8s, que é este botão. Acabou por ser adicionado. Depois de o adicionar, tornou-se este. O

método de adição está aqui: https://segmentfault.com/a/1190000020947651 , Refiro-me a este artigo.
Mas não resolveu meu problema.

Por fim, registrei um gitlab-runner para meu projeto no ambiente k8s de dev. Meu ambiente de desenvolvimento já existe gitlab-runner. Se o seu não existir, basta instalá-lo.
Depois disso, primeiro abra setting—> cicd—> runners

e, em seguida, use gitlab-runner register para

inserir o url da
imagem do runner anterior. Digite a
entrada do token e a descrição de saída da imagem do runner anterior.
Digite a tag. Isso é muito importante , o script .gitlab-ci.yaml Por meio do
método de execução de seleção de entrada do executor associado à tag , escolhi shell

Após o registro, você descobrirá que setting—> cicd—> runners tem mais um runner

e ainda não pode ser usado aqui, mesmo se a tag estiver associada ao arquivo .gitlab-ci.yaml. Tal associação, adicionar tags

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

Como este corredor não pode correr, se puder, a frente fica verde e a etiqueta foi trocada. É diferente da correspondente na figura acima. Explique.

Também preciso chamar gitlab-runner run. Após a chamada, ele fica verde e pronto para uso. Depois de


terminar isso, posso implantar automaticamente no k8s que desejo depois de enviar o código.

Como o artigo envolve projetos da empresa, muitas coisas não podem ser explicadas com clareza. Provavelmente, só pode ser escrito assim.