Índice
Problema 1: Código redundante e práticas ineficientes
Problema 2: Difícil manutenção e carga de trabalho pesada
Benefício 1: uma modificação entra em vigor em muitos lugares
Benefício 2: Construção eficiente, simples e conveniente
Construção de armazém de componentes
Runner, uma ferramenta para construção eficiente de CI/CD
Exclusivo + Compartilhado, opções mais flexíveis
Expanda e reduza dinamicamente a capacidade para melhorar a utilização de recursos
Linha de montagem de conformidade, auxiliando no uso seguro e compatível de linhas de montagem
JiHu GitLab CI está integrado à plataforma integrada JiHu GitLab, fornecendo recursos de CI/CD prontos para uso e também é uma das ferramentas de CI adoradas por muitos usuários. O mecanismo de design exclusivo e os recursos funcionais de nível empresarial do Jihu GitLab CI podem ajudar as empresas a melhorar a eficiência da construção de CI/CD e reduzir os custos de manutenção de pipeline ao implementar práticas de CI/CD em grande escala, enquanto mantêm conformidade de segurança suficiente .
Este artigo parte da construção do Pipeline CI/CD e descreve o uso do Jihu GitLab CI em três aspectos principais:
-
Use
template,componentpara reduzir o tempo de gravação do pipeline e melhorar a capacidade de manutenção; -
Use a jogabilidade “extravagante” do Runner para atender às necessidades de operação do CI/CD Pipeline em diferentes cenários e, ao mesmo tempo, reduzir os custos de uso;
-
Use uma estrutura de conformidade para garantir o uso compatível do pipeline de CI/CD.
referência de modelo, reduzindo a redundância de código e melhorando a escalabilidade de construção de CI/CD
Dentro de uma empresa, um cenário muito comum é que diferentes equipes ou diferentes linhas de produtos tenham seus próprios projetos exclusivos, e cada projeto tenha um pipeline de CI/CD correspondente. À medida que o número de projetos aumenta, o número de pipelines continuará a aumentar. Cada vez mais. , pode haver centenas ou até milhares de linhas de montagem dentro de uma empresa.
Como o pipeline de CI/CD é uma forma automatizada de entrega de software (da codificação ao on-line), a maioria dos pipelines terá um grau relativamente alto de similaridade e alguns estágios ou trabalhos são exatamente iguais, como em cenários de entrega nativa da nuvem. O aplicativo precisa ser empacotado em um espelho. O código para construir usando Jihu GitLab CI é o seguinte:
build:
image: docker:latest
stage: build
services:
- docker:20.10.7-dind
script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:1.0.0 .
- docker push $CI_REGISTRY_IMAGE:1.0.0
Além disso, se todos forem projetos java ou golang, os comandos de compilação ou teste podem ser semelhantes. Essa "repetição" aumentará à medida que o pipeline aumentar, e também surgirão os seguintes problemas:
Problema 1: Código redundante e práticas ineficientes
Se cada pipeline tiver um estágio ou trabalho semelhante com cerca de 10 linhas de código, o número de códigos duplicados em centenas ou milhares de pipelines será de dezenas de milhares. Esse tipo de redundância de código é em si uma prática ineficiente no campo do desenvolvimento de software. Se não for refatorado a tempo, se tornará uma dívida técnica à medida que o projeto evolui.
Problema 2: Difícil manutenção e carga de trabalho pesada
No processo de otimização do pipeline de CI/CD, algumas partes do pipeline precisam ser modificadas, como atualizar a versão dind ou alterar o método de construção de dind para kaniko para construir a imagem com segurança, então o código correspondente deve ser mudado. tornar-se:
services:
- docker:24.0.3-dind
e:
build:
stage: build
image:
name: registry.jihulab.com/jh-xiaomage-devops/go-demo/kaniko:debug
entrypoint: [""]
script:
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
- >-
/kaniko/executor
--context "${CI_PROJECT_DIR}"
--dockerfile "${CI_PROJECT_DIR}/Dockerfile"
--destination "${CI_REGISTRY_IMAGE}:1.0.0"
Neste momento, todos os pipelines devem ser transformados.A transformação de centenas ou mesmo milhares de pipelines será uma enorme carga de trabalho, e o processo de "copiar e colar" de uma grande quantidade de código é difícil de evitar sem erros.
No campo de pesquisa e desenvolvimento de software, uma forma importante de resolver código redundante é por meio de abstração + reutilização: ou seja, abstrair o mesmo conteúdo (ou similar) em modelos, “armazenar” os modelos em um determinado local e simplesmente consultá-los. os modelos em outros lugares. É isso .
O mesmo se aplica ao pipeline de CI/CD. O modelo GiFox GitLab é a função de mecanismo de modelo integrada do GiFox GitLab CI, que pode armazenar modelos abstraídos no warehouse do projeto e outros projetos podem include referenciar o modelo por meio de sintaxe.
O uso do template Jihu GitLab é relativamente flexível, primeiro você precisa "fazer" o template, ou seja, extrair o código "duplicado" e salvá-lo em um arquivo YAML. Por exemplo, o conteúdo de compilação da imagem acima pode ser gravado em um arquivo docker-image-build.gitlab-ci.yml. Em seguida, use include citação. Dependendo de onde o modelo está armazenado, include há quatro maneiras de referenciá-lo:
➤ locais
Os modelos estão localizados no projeto atual e local são referenciados por meio de palavras-chave . A sintaxe de uso é a seguinte:
include:
- local: '/templates/docker-image-build.gitlab-ci.yml'
➤ arquivo
O modelo e o projeto estão localizados na mesma instância, mas em repositórios diferentes, e são file referenciados por meio de palavras-chave . A sintaxe de uso é a seguinte:
include
- project: xiaomage/templates
- ref: main
file: /templates/docker-image-build.gitlab-ci.yml
➤ remoto
Referências a pipelines em armazéns remotos, geralmente entre instâncias diferentes . A sintaxe de uso é a seguinte:
include:
- remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'
➤ modelo
Uma referência ao modelo integrado do JiHu GitLab . Com base em seus muitos anos de experiência, o GitLab acumulou muitos modelos que podem ser reutilizados diretamente, que podem ser usados usando a sintaxe do modelo. O mais típico é a referência do modelo Jihu GitLab DevSecOps. GitLab DevSecOps possui funções de verificação de chave, verificação de dependência, SAST, DAST, verificação de imagem de contêiner, teste fuzz e detecção de conformidade de licença. Todas as funções podem ser ativadas com duas linhas de código.
Portanto, usar template pode trazer os seguintes benefícios:
Benefício 1: uma modificação entra em vigor em muitos lugares
Se você precisar otimizar o conteúdo do pipeline, como dind atualizar a versão do , você só precisará fazer modificações no modelo, e outros locais referenciados entrarão em vigor, realizando verdadeiramente "modificar em um local, entrar em vigor em vários locais" , que evita completamente a duplicação de trabalho causada por "mudar uma vez, modificar em qualquer lugar" também reduzirá a redundância do pipeline.
Benefício 2: Construção eficiente, simples e conveniente
O modelo pode obter aninhamento multinível, ou seja, os modelos são referenciados dentro dos modelos. A vantagem disso é que o conteúdo do modelo pode ser refinado. Pode ser um estágio ou um trabalho. Por exemplo, a construção da imagem do contêiner é um modelo e a verificação de segurança da imagem do contêiner é outro modelo. Se quiser construir um pipeline para um novo projeto, você pode usar vários modelos diretamente para "construir blocos de construção" para concluir rapidamente a construção do pipeline e, em seguida, fazer algumas alterações nos parâmetros ou processos de acordo com o processo de construção real do o projeto.
É claro que para usar os templates de forma eficiente, há outra questão que precisa ser atenta, que é a sobregravação de variáveis nos templates .
Para usar modelos de maneira flexível, use o mesmo conjunto de modelos para construir diversas instâncias diferentes. A chave está no uso de variáveis no modelo. Por exemplo, ao construir uma imagem de contêiner, a tag pode diferir de versão para versão. Nesse caso, a tag pode ser definida como uma variável:
variables:
IMAGE_TAG: 1.0.0
build:
image: docker:latest
stage: build
services:
- docker:20.10.7-dind
script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
- docker build -t $CI_REGISTRY_IMAGE:$IMAGE_TAG .
- docker push $CI_REGISTRY_IMAGE:$IMAGE_TAG
Basta sobrescrever a variável diretamente no ponto de referência:
variables:
IMAGE_TAG: "2.0.0"
include:
- remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'
1.0.0 Após a substituição, o valor da tag de imagem muda do padrão 2.0.0 , que pode atender aos requisitos de diferentes cenários e é eficiente e flexível.
Componente, criando uma única fonte de confiança para o pipeline de CI/CD e simplificando a construção do pipeline de CI/CD
O uso de modelos reduz muito a dificuldade para os usuários criarem pipelines de CI/CD. Por meio do modo de referência + cobertura de parâmetros, os pipelines correspondentes aos cenários podem ser criados rapidamente. No entanto, atualmente não há uma única fonte confiável de modelos para facilitar aos usuários encontrar o que eles querem. Ao usar o Pipeline, os usuários que desejam contribuir não podem contribuir com os modelos disponíveis para construir em conjunto um ecossistema próspero do Pipeline.
Para este fim, Jihu GitLab lançou o recurso CI/CD Component, cujo objetivo é criar uma única fonte confiável para CI/CD Pipeline, transformando diferentes pipelines (ou trabalhos separados) em diferentes componentes e depois publicando-os no armazém de componentes. os usuários podem pesquisar neste warehouse para encontrar o componente que desejam. Eles podem referenciá-lo diretamente ao construir o pipeline. A referência de vários componentes pode construir rapidamente todo o pipeline completo. Esta é uma grande mudança. Melhore a experiência do usuário ao usar CI/ CD.
O que é mais importante é que os usuários possam publicar alguns pipelines excelentes (ou trabalhos individuais) que eles acham que foram praticados na forma de componentes no armazém de componentes e, em conjunto, criar um ecossistema próspero de pipeline de CI/CD por meio de contribuições e iterações contínuas de diferentes usuários. e, finalmente, criar uma única fonte confiável para o pipeline interno de CI/CD da empresa , o que não apenas melhora a eficiência da construção do pipeline de CI/CD, mas também melhora muito a segurança.
Observação: o componente CI/CD é atualmente experimental.
Diagrama de componentes CI/CD
Portanto, o núcleo do componente é: a construção do armazém de componentes, o lançamento do componente e a referência do componente .
Construção de armazém de componentes
Crie um repositório de componentes inicial criando um repositório GitLab e marcando-o como um repositório de componentes. O repositório requer pelo menos dois arquivos README.md e template.yml:
-
README.mdOs componentes contidos no warehouse podem ser descritos para facilitar o aprendizado e o uso dos usuários; -
template.ymlÉ o conteúdo específico do componente.
Diferentes componentes podem ser distinguidos por meio de diferentes estruturas de diretório (ramificação, tag, etc.), como:
├── template.yml
├── README.md
├── .gitlab-ci.yml
├── forntend/
│ └── template.yml
└── backend/
└── template.yml
O diretório acima indica que existem três componentes disponíveis neste armazém de componentes:
-
template.ymlO componente representado no diretório raiz ; -
template.ymlO componente representado no diretório frontend ; -
template.ymlO componente representado no diretório backend .
Você pode marcar um warehouse como um warehouse de componentes em Projeto → Configurações → Geral → Visibilidade, Funções do projeto, Geral → Ativar recursos do diretório CI/CD.
Liberação de Componente
Se precisar publicar um componente, você precisará gravar o conteúdo correspondente em um template.yml arquivo e, em seguida, enviar o arquivo para o armazém de componentes. Tomando a construção da imagem acima como exemplo, escreva o seguinte conteúdo em um arquivo template.yml :
spec:
inputs:
stage:
default: test
image:
default: docker:latest
tags:
default: tags
image_tag:
default: 1.0.0
component-job-build-image:
image: $[[ inputs.image ]]
stage: $[[ inputs.stage ]]
tags:
- $[[ inputs.tags ]]
script:
- docker login -u "$REGISTRY_USER" -p "$REGISTRY_PWD" REGISTRY_URL
- docker build -t dllhb/cicd-component:$[[ inputs.image_tag ]] .
- docker push dllhb/cicd-component:$[[ inputs.image_tag ]]
Em seguida, envie-o jh.instance.url/username/component-project para o diretório. Descrição do parâmetro:
-
jh.instance.url: Endereço da instância de implantação privada do Jihu GitLab; -
username：Nome de usuário Jihu GitLab; -
component-project:nome do armazém do componente.
O componente acima está localizado no diretório raiz do warehouse e possui um component-job-build-image trabalho.
Referência ao Componente
Caso queira referenciar o componente publicado acima em outros Pipelines, .gitlab-ci.yml utilize a seguinte sintaxe para referenciá-lo:
include:
- component: jh.instance.url/username/component-project@main
inputs:
stage: build
image: docker:latest
tags: cicd
image_tag: 2.0.0
stages: [build]
As coisas a serem observadas são:
-
includeEscreva completamente o caminho do componente (ou seja,tempate.ymlo caminho existente) nele e use @ para deixar claro qual versão do componente está sendo referenciada (pode ser representada por ramificações, hash de commit, tags, etc.); -
inputsEscreva parâmetros específicos em .
Acione o pipeline de CI/CD e você verá que component-job-build-image joba execução foi bem-sucedida:
Da mesma forma, se você quiser dind alterar o método de construção kaniko, não precisará substituir o conteúdo do componente acima, basta publicar um componente com tema kaniko novamente.
Existem muitas maneiras de conseguir isso, como colocá-lo template.yml em outro diretório do warehouse do componente (não no diretório raiz, porque já dind existe ), ramificações e tags para indicar que este é um componente diferente ; por exemplo, para o componente acima , a ramificação principal representa dind o componente, então você pode criar uma nova kaniko ramificação para armazenar o componente correspondente a kaniko e, finalmente, .gitlab-ci.yml especificar a ramificação ao referenciá-la:
include:
- component: jh-jhma.gitlab.cn/cicd-component/cicd-component-demo@kaniko
inputs:
stage: build
image: gcr.io/kaniko-project/executor:debug
tags: cicd
image_tag: 2.0.0
stages: [build]
dindClaro, a imagem também deve ser alterada em relação à originalkinako, o que requer apenas a modificaçãoinputsdos parâmetros.
Você pode obter os mesmos resultados executando um pipeline de CI/CD.
A introdução do componente deu início a um novo paradigma para CI/CD do GitLab. Esta abordagem de criar uma única fonte de confiança para o Pipeline CI/CD através de contribuições dos utilizadores é de grande ajuda para os utilizadores na construção de um Pipeline completo.Não só acelera a construção do Pipeline CI/CD,mas também reduz significativamente o custo para os utilizadores para aprender a sintaxe YAML complicada.
Os códigos demonstrados acima são todos armazenados na instância de implantação privatizada do Jihu GitLab e o endereço é https://jh-jhma.gitlab.cn/cicd-component .
Runner, uma ferramenta para construção eficiente de CI/CD
Runner é um componente importante do GitLab CI, que pode ajudar a executar trabalhos definidos no pipeline de CI/CD . Quando os desenvolvedores enviam alterações no código, o Jihu GitLab "notificará" o Runner para .gitlab-ci.yml concluir a construção, teste, implantação, etc. do código alterado de acordo com as etapas definidas do pipeline. Durante esse processo, o Runner seguirá o executor selecionado (como o shell para PowerShell). , docker para contêineres, etc.) para executar trabalhos em diferentes ambientes. Em relação à seleção de executores, consulte Jihu GitLab Executor Network .
Runner é como um "agente" que aceita solicitações do lado do "servidor" (instância Jihu GitLab).Portanto, para atender às necessidades de diferentes cenários, o Runner deve ser capaz de executar diferentes métodos de instalação em diferentes sistemas operacionais e diferentes CPUs. arquiteturas.
Exclusivo + Compartilhado, opções mais flexíveis
O Runner é dividido em duas categorias: proprietário e compartilhado:
-
Proprietário: significa que o Runner é utilizado apenas para projetos designados, geralmente utilizando algumas informações do projeto (token de registro do Runner) para registrar o Runner no projeto correspondente;
-
Compartilhamento: significa que o Runner é para toda a instância do GitLab, o que significa que todos os projetos em toda a instância podem usar esses Runners. Quanto a como usá-lo, quem usa primeiro e quem usa depois, é implementado pelo mecanismo de agendamento interno do GitLab.
As maiores vantagens dos corredores proprietários são:
-
Economize tempo : o Runner dedicado executa apenas o pipeline de CI/CD para o projeto correspondente, portanto, não há necessidade de entrar na fila e esperar que o Runner compartilhado execute o pipeline de CI/CD. À medida que o número de projetos e pipelines aumenta, o enfileiramento levará muito tempo;
-
Autônomo e controlável : O Runner proprietário é instalado pelo usuário em um servidor controlável pelo usuário.Durante o uso, se você deseja depurar o processo do pipeline ou modificar a configuração do Runner, ou mesmo deseja obter alguns dados durante o processo em execução , você pode fazer login diretamente no Runner correspondente para realizar operações.
Informações de configuração do Runner proprietário
Os benefícios de compartilhar o Runner também são óbvios: os usuários não precisam saber muitas informações sobre o Runner, nem precisam instalá-lo e operá-lo por conta própria . É uma maneira relativamente livre de problemas.
Portanto, os usuários podem escolher diferentes métodos Runner de acordo com suas próprias necessidades para concluir a operação correspondente do pipeline de CI/CD.
Expanda e reduza dinamicamente a capacidade para melhorar a utilização de recursos
O Runner pode estar intimamente ligado ao recurso de escalonamento dinâmico dos recursos da nuvem para alcançar o escalonamento dinâmico do Runner: quando um pipeline de CI/CD precisa ser executado, o Runner usa alguns recursos (CPU, memória, etc.) para executar todos os trabalhos. Pipeline CI/CD Após o término da operação (sucesso ou falha), os recursos correspondentes são liberados e o ambiente é restaurado.
Por exemplo, você pode usar contêineres para executar o Runner. O mais comum é usar o Kubernetes para executar o Jihu GitLab Runner.
Ao executar CI/CD, o Kubernetes criará dinamicamente um pod, e o pod gerará .gitlab-ci.yml contêineres correspondentes com base no estágio e na imagem correspondente descrita no arquivo (todos os contêineres estão em um pod e compartilham os recursos internos do pod). do pipeline estiver dentro do contêiner, quando o pipeline terminar, o pod será excluído e os dados e recursos necessários durante a operação serão liberados.
Além disso, você também pode usar produtos sem servidor fornecidos por fornecedores de nuvem para expandir dinamicamente a capacidade do Runner e melhorar a utilização de recursos.
Linha de montagem de conformidade, auxiliando no uso seguro e compatível de linhas de montagem
Há também um cenário encontrado durante o uso de pipelines: um determinado processo requer a execução de todos os pipelines do projeto. Por exemplo, uma verificação de segurança da imagem deve ser executada no final da construção da imagem. Se houver uma vulnerabilidade de segurança, a execução de o pipeline precisa ser encerrado. A solução neste caso é muitas vezes adicionar um include link de digitalização de imagem de contêiner ao pipeline para todos os projetos.No entanto, à medida que o número de projetos aumenta (centenas ou mesmo milhares), isso significa uma enorme duplicação de trabalho, e a operação não pode ser garantida.
E a solução certa é: um pipeline de conformidade.
O pipeline de conformidade é um recurso de segurança integrado ao pipeline de CI/CD do GitLab e garante principalmente que todos os projetos do grupo possam executar trabalhos de conformidade especificados . Ao configurar a estrutura de conformidade no nível do grupo e selecionar o trabalho de pipeline de conformidade que cada projeto deve executar, todos os projetos neste grupo executarão esse trabalho de conformidade, mesmo os projetos recém-criados neste grupo. Os projetos também executam esse trabalho de conformidade por padrão.
Para usar o pipeline de conformidade, primeiro você precisa configurar a estrutura de conformidade no nível do grupo. Em Grupos → Configurações → Geral → Estrutura de conformidade , selecione Nova estrutura de conformidade, preencha o nome da estrutura de conformidade, a descrição, a configuração do pipeline de conformidade (ou seja, onde o pipeline de conformidade está armazenado) e, por fim, selecione uma cor de fundo.
Se esta estrutura de conformidade for definida como a estrutura de conformidade padrão do grupo, todos os novos projetos neste grupo usarão esta estrutura de conformidade por padrão, executarão este pipeline de conformidade por padrão e haverá um rótulo de estrutura de conformidade na página do projeto. gerar .
Em seguida, você precisa gravar o pipeline de conformidade em um projeto nesse grupo (como Compliance-Pipeline). Tomando como exemplo o pipeline de construção e verificação da imagem do contêiner, .gitlab-ci.yml escreva o seguinte conteúdo no arquivo:
include:
- remote: 'https://jihulab.com/xiaomage/teamplates/raw/main/docker-image-build.gitlab-ci.yml'
- template: Security/Container-Scanning.gitlab-ci.yml
Todos os novos projetos subsequentes realizarão a construção e a digitalização de imagens de contêiner, em vez do pipeline do próprio projeto.
Se você quiser que o pipeline do próprio projeto seja executado, basta mesclar o conteúdo do pipeline de conformidade com o conteúdo do pipeline do próprio projeto. Por exemplo, o pipeline integrado precisa usar cosgin para assinar e verificar a imagem do contêiner empacotado para evitar que a imagem seja adulterada:
stages:
- singature
- verfication
image-singature:
stage: singature
tags:
- cosign
image:
name: dllhb/cosign:1.0.0
entrypoint: [""]
before_script:
- mkdir ~/.docker
- cat "$DOCKER_CRED_FILE" > ~/.docker/config.json
- cat "$COSIGN_KEY" > /tmp/cosign.key
- export COSIGN_PASSWORD="$COSIGN_PASSWORD"
script:
- cosign sign --key /tmp/cosign.key $CI_REGISTRY_IMAGE:1.0.0
image-verfication:
stage: verfication
tags:
- cosign
image:
name: dllhb/cosign:1.0.0
entrypoint: [""]
before_script:
- cat "$COSIGN_PUB" > /tmp/cosign.pub
- export COSIGN_PASSWORD="$COSIGN_PASSWORD"
script:
- cosign verify --key /tmp/cosign.pub $CI_REGISTRY_IMAGE:1.0.0
O pipeline acima precisa ser introduzido no pipeline de conformidade:
include:
- project: 'Compliance-Pipeline-Group/regular-pipeline'
file: '.gitlab-ci.yml'
Eventualmente, os pipelines de outros projetos deste grupo realizarão as quatro etapas de empacotamento, digitalização, assinatura e verificação de imagens de contêineres.
Portanto, a estrutura de conformidade é selecionada para marcar determinados projetos que devem atender a determinados requisitos de conformidade ou exigir supervisão adicional e, em seguida, concluir o trabalho de conformidade executando o pipeline de conformidade.