안녕하세요! 최근 Docker 이미지 구축과 Kubernetes 배포를 위한 멋진 자동화 도구가 많이 출시되었습니다. 이런 점에서 나는 GitLab을 시험해보고 그 기능을 철저하게 연구하고 물론 파이프라인을 설정하기로 결정했습니다.

본 작품은 홈페이지에서 영감을 받아 제작되었습니다 쿠버네티스.io, 이는 다음에서 생성됩니다. 소스 코드 자동으로 전송된 각 풀 요청에 대해 로봇은 변경 사항이 포함된 사이트의 미리 보기 버전을 자동으로 생성하고 볼 수 있는 링크를 제공합니다.

유사한 프로세스를 처음부터 구축하려고 시도했지만 Kubernetes에 애플리케이션을 배포하는 데 사용했던 Gitlab CI와 무료 도구를 기반으로 완전히 구축되었습니다. 오늘은 마침내 그들에 대해 더 자세히 알려 드리겠습니다.

이 기사에서는 다음과 같은 도구에 대해 설명합니다.
휴고, 큐벡, 카니코, 자식 암호 и 깃랩 CI 역동적인 환경을 조성합니다.

내용물

1. 휴고를 만나보세요
2. Dockerfile 준비
3. 카니코를 알아가는 중
4. qbec에 대해 알아가기
5. Kubernetes-executor로 Gitlab-runner 사용해 보기
6. qbec을 사용하여 Helm 차트 배포
7. git-crypt 소개
8. 도구 상자 이미지 만들기
9. 첫 번째 파이프라인과 태그별 이미지 조립
10. 배포 자동화
11. 마스터로 푸시할 때 아티팩트 및 어셈블리
12. 동적 환경
13. 앱 검토

1. 휴고에 대해 알아가기

우리 프로젝트의 예로 Hugo를 기반으로 구축된 문서 게시 사이트를 만들어 보겠습니다. Hugo는 정적 콘텐츠 생성기입니다.

정적 생성기에 대해 잘 모르시는 분들을 위해 조금 더 설명드리겠습니다. 사용자가 요청할 때 즉시 페이지를 생성하는 데이터베이스와 일부 PHP를 갖춘 기존 웹 사이트 엔진과 달리 정적 생성기는 약간 다르게 설계되었습니다. 이를 통해 일반적으로 Markdown 마크업 및 테마 템플릿의 파일 세트인 소스를 가져온 다음 완전히 완성된 웹 사이트로 컴파일할 수 있습니다.

즉, 결과적으로 디렉토리 구조와 생성된 HTML 파일 세트를 받게 되며, 이를 저렴한 호스팅에 업로드하고 작동하는 웹사이트를 얻을 수 있습니다.

Hugo를 로컬에 설치하고 사용해 볼 수 있습니다.

새 사이트 초기화:

hugo new site docs.example.org

동시에 git 저장소는 다음과 같습니다.

cd docs.example.org
git init

지금까지 우리 사이트는 깨끗했으며 여기에 뭔가를 표시하려면 먼저 테마를 연결해야 합니다. 테마는 사이트가 생성되는 템플릿과 지정된 규칙의 집합일 뿐입니다.

우리가 사용할 테마는 자료실, 제 생각에는 문서 사이트에 완벽하게 적합합니다.

테마 파일을 프로젝트 저장소에 저장할 필요가 없다는 사실에 특별한 주의를 기울이고 싶습니다. 대신 다음을 사용하여 간단히 연결할 수 있습니다. 자식 하위 모듈:

git submodule add https://github.com/matcornic/hugo-theme-learn themes/learn

따라서 저장소에는 프로젝트와 직접 관련된 파일만 포함되며 연결된 테마는 특정 저장소에 대한 링크와 커밋으로 유지됩니다. 즉, 항상 원본 소스에서 가져올 수 있으며 걱정할 필요가 없습니다. 호환되지 않는 변경 사항.

설정을 수정해보자 config.toml:

baseURL = "http://docs.example.org/"
languageCode = "en-us"
title = "My Docs Site"
theme = "learn"

이미 이 단계에서 다음을 실행할 수 있습니다.

hugo server

그리고 주소에는 http://localhost:1313/ 새로 생성된 웹사이트를 확인하세요. 디렉토리의 모든 변경 사항은 브라우저에 열려 있는 페이지를 자동으로 업데이트하므로 매우 편리합니다!

표지를 만들어 보겠습니다. 콘텐츠/_index.md:

# My docs site

## Welcome to the docs!

You will be very smart :-)

새로 생성된 페이지의 스크린샷

사이트를 생성하려면 다음을 실행하세요.

hugo

디렉토리 내용 공공의/ 그리고 당신의 웹사이트가 될 것입니다.
네, 그런데 즉시 추가해 보겠습니다. .gitignore:

echo /public > .gitignore

변경 사항을 커밋하는 것을 잊지 마세요.

git add .
git commit -m "New site created"

2. Dockerfile 준비

이제 저장소의 구조를 정의할 차례입니다. 나는 보통 다음과 같은 것을 사용합니다.

.
├── deploy
│   ├── app1
│   └── app2
└── dockerfiles
    ├── image1
    └── image2

• 도커파일/ — Dockerfiles가 있는 디렉터리와 Docker 이미지를 구축하는 데 필요한 모든 것이 포함되어 있습니다.
• 배포/ — 애플리케이션을 Kubernetes에 배포하기 위한 디렉터리가 포함되어 있습니다.

따라서 경로를 따라 첫 번째 Dockerfile을 생성합니다. dockerfiles/웹사이트/Dockerfile

FROM alpine:3.11 as builder
ARG HUGO_VERSION=0.62.0
RUN wget -O- https://github.com/gohugoio/hugo/releases/download/v${HUGO_VERSION}/hugo_${HUGO_VERSION}_linux-64bit.tar.gz | tar -xz -C /usr/local/bin
ADD . /src
RUN hugo -s /src

FROM alpine:3.11
RUN apk add --no-cache darkhttpd
COPY --from=builder /src/public /var/www
ENTRYPOINT [ "/usr/bin/darkhttpd" ]
CMD [ "/var/www" ]

보시다시피 Dockerfile에는 두 가지가 포함되어 있습니다. FROM, 이번 기회를 다단계 빌드 최종 Docker 이미지에서 불필요한 모든 것을 제외할 수 있습니다.
따라서 최종 이미지에는 다음과 같은 내용만 포함됩니다. darkhttpd (경량 HTTP 서버) 및 공공의/ — 정적으로 생성된 웹사이트의 콘텐츠.

변경 사항을 커밋하는 것을 잊지 마세요.

git add dockerfiles/website
git commit -m "Add Dockerfile for website"

3. 카니코를 알아가다

도커 이미지 빌더로서 저는 다음을 사용하기로 결정했습니다. 카니코, 작업에는 도커 데몬이 필요하지 않고 빌드 자체는 모든 시스템에서 수행될 수 있으며 캐시는 레지스트리에 직접 저장될 수 있으므로 본격적인 영구 저장소가 필요하지 않습니다.

이미지를 빌드하려면 다음을 사용하여 컨테이너를 실행하세요. 카니코 집행자 현재 빌드 컨텍스트를 전달합니다. 이는 docker를 통해 로컬로 수행할 수도 있습니다.

docker run -ti --rm 
  -v $PWD:/workspace 
  -v ~/.docker/config.json:/kaniko/.docker/config.json:ro 
  gcr.io/kaniko-project/executor:v0.15.0 
  --cache 
  --dockerfile=dockerfiles/website/Dockerfile 
  --destination=registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1

Где Registry.gitlab.com/kvaps/docs.example.org/website — 도커 이미지의 이름, 빌드 후 도커 레지스트리에서 자동으로 시작됩니다.

매개 변수 --은닉처 docker 레지스트리에서 레이어를 캐시할 수 있습니다. 주어진 예에서는 해당 레이어가 다음 위치에 저장됩니다. Registry.gitlab.com/kvaps/docs.example.org/website/cache하지만 매개변수를 사용하여 다른 경로를 지정할 수 있습니다. --캐시 저장소.

docker-registry 스크린샷

4. qbec에 대해 알아가기

퀘벡 애플리케이션 매니페스트를 선언적으로 설명하고 이를 Kubernetes에 배포할 수 있는 배포 도구입니다. Jsonnet을 기본 구문으로 사용하면 여러 환경 간의 차이점에 대한 설명을 크게 단순화할 수 있으며 코드 반복을 거의 완전히 제거할 수 있습니다.

이는 서로 다른 매개변수를 사용하여 여러 클러스터에 애플리케이션을 배포해야 하고 이를 Git에서 선언적으로 설명하려는 경우에 특히 그렇습니다.

Qbec을 사용하면 필요한 매개변수를 전달하여 Helm 차트를 렌더링한 다음 다양한 변형을 적용할 수 있는 것을 포함하여 일반 매니페스트와 동일한 방식으로 작동할 수 있습니다. ChartMuseum을 사용하세요. 즉, 차트가 속한 Git에서 직접 차트를 저장하고 렌더링할 수 있습니다.

앞서 말했듯이 우리는 모든 배포를 디렉터리에 저장합니다. 배포/:

mkdir deploy
cd deploy

첫 번째 애플리케이션을 초기화해 보겠습니다.

qbec init website
cd website

이제 우리 애플리케이션의 구조는 다음과 같습니다:

.
├── components
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
└── qbec.yaml

파일을 살펴보자 qbec.yaml:

apiVersion: qbec.io/v1alpha1
kind: App
metadata:
  name: website
spec:
  environments:
    default:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443
  vars: {}

여기서 우리는 주로 다음 사항에 관심이 있습니다. 사양 환경, qbec은 이미 우리를 위한 기본 환경을 생성했으며 현재 kubeconfig에서 서버 주소와 네임스페이스를 가져왔습니다.
이제 배포할 때 디폴트 값 환경에서 qbec은 항상 지정된 Kubernetes 클러스터와 지정된 네임스페이스에만 배포됩니다. 즉, 배포를 수행하기 위해 더 이상 컨텍스트와 네임스페이스 사이를 전환할 필요가 없습니다.
필요한 경우 언제든지 이 파일의 설정을 업데이트할 수 있습니다.

모든 환경은 다음에 설명되어 있습니다. qbec.yaml, 그리고 파일에서 params.libsonnet, 여기에는 해당 매개변수를 가져올 수 있는 위치가 나와 있습니다.

다음으로 두 개의 디렉터리가 표시됩니다.

• 구성 요소 / — 애플리케이션의 모든 매니페스트가 여기에 저장됩니다. jsonnet 및 일반 yaml 파일 모두에서 설명할 수 있습니다.
• 환경/ — 여기서는 환경에 대한 모든 변수(매개변수)를 설명합니다.

기본적으로 두 개의 파일이 있습니다.

• 환경/base.libsonnet - 모든 환경에 대한 공통 매개변수가 포함됩니다.
• 환경/default.libsonnet — 환경에 대해 재정의된 매개변수를 포함합니다. 디폴트 값

열어보자 환경/base.libsonnet 거기에 첫 번째 구성요소에 대한 매개변수를 추가합니다.

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website:v0.0.1',
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

첫 번째 구성 요소도 만들어 보겠습니다. 구성 요소/website.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.website;

[
  {
    apiVersion: 'apps/v1',
    kind: 'Deployment',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      replicas: params.replicas,
      selector: {
        matchLabels: {
          app: params.name,
        },
      },
      template: {
        metadata: {
          labels: { app: params.name },
        },
        spec: {
          containers: [
            {
              name: 'darkhttpd',
              image: params.image,
              ports: [
                {
                  containerPort: params.containerPort,
                },
              ],
            },
          ],
          nodeSelector: params.nodeSelector,
          tolerations: params.tolerations,
          imagePullSecrets: [{ name: 'regsecret' }],
        },
      },
    },
  },
  {
    apiVersion: 'v1',
    kind: 'Service',
    metadata: {
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      selector: {
        app: params.name,
      },
      ports: [
        {
          port: params.servicePort,
          targetPort: params.containerPort,
        },
      ],
    },
  },
  {
    apiVersion: 'extensions/v1beta1',
    kind: 'Ingress',
    metadata: {
      annotations: {
        'kubernetes.io/ingress.class': params.ingressClass,
      },
      labels: { app: params.name },
      name: params.name,
    },
    spec: {
      rules: [
        {
          host: params.domain,
          http: {
            paths: [
              {
                backend: {
                  serviceName: params.name,
                  servicePort: params.servicePort,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

이 파일에서는 세 가지 Kubernetes 엔터티를 한 번에 설명했습니다. 전개, 예배 и 입구. 원한다면 이를 다른 구성 요소에 넣을 수 있지만 이 단계에서는 하나만 있어도 충분합니다.

구문 jsonnet 일반 json과 매우 유사합니다. 원칙적으로 일반 json은 이미 유효한 jsonnet이므로 처음에는 다음과 같은 온라인 서비스를 사용하는 것이 더 쉬울 수 있습니다. yaml2json 일반적인 yaml을 json으로 변환하거나 구성 요소에 변수가 포함되어 있지 않은 경우 일반 yaml 형식으로 설명할 수 있습니다.

작업할 때 jsonnet 편집기용 플러그인을 설치하는 것이 좋습니다.

예를 들어 vim용 플러그인이 있습니다. vim-jsonnet, 구문 강조를 켜고 자동으로 실행됩니다. jsonnet fmt 저장할 때마다(jsonnet 설치 필요)

모든 것이 준비되었습니다. 이제 배포를 시작할 수 있습니다.

우리가 얻은 것을 확인하기 위해 다음을 실행해 봅시다:

qbec show default

출력에는 기본 클러스터에 적용될 렌더링된 yaml 매니페스트가 표시됩니다.

좋습니다. 이제 신청하세요.

qbec apply default

출력에서 클러스터에서 수행될 작업을 항상 볼 수 있으며, qbec는 다음을 입력하여 변경 사항에 동의하도록 요청합니다. y 당신의 의도를 확인할 수 있을 것입니다.

우리의 애플리케이션이 준비되어 배포되었습니다!

변경하는 경우 언제든지 다음을 수행할 수 있습니다.

qbec diff default

이러한 변경 사항이 현재 배포에 어떤 영향을 미치는지 확인하려면

변경 사항을 커밋하는 것을 잊지 마세요.

cd ../..
git add deploy/website
git commit -m "Add deploy for website"

5. Kubernetes-executor로 Gitlab-runner 사용해 보기

최근까지는 일반만 사용했는데 gitlab 러너 쉘 또는 docker-executor가 있는 사전 준비된 머신(LXC 컨테이너)에서. 처음에는 gitlab에 전역적으로 정의된 여러 러너가 있었습니다. 그들은 모든 프로젝트에 대한 도커 이미지를 수집했습니다.

그러나 실습에서 알 수 있듯이 이 옵션은 실용성과 안전성 측면에서 가장 이상적인 것은 아닙니다. 각 프로젝트 또는 각 환경에 대해 별도의 실행기를 배포하는 것이 훨씬 더 좋고 이념적으로 더 정확합니다.

다행히도 이는 전혀 문제가 되지 않습니다. 이제 우리는 배포할 것이기 때문입니다. gitlab 러너 Kubernetes에서 프로젝트의 일부로 직접적으로.

Gitlab은 Kubernetes에 gitlab-runner를 배포하기 위해 미리 만들어진 Helm 차트를 제공합니다. 그러니 당신이 해야 할 일은 알아내는 것뿐입니다 등록 토큰 우리 프로젝트를 위해 설정 -> CI/CD -> 런너 그리고 이를 helm에 전달합니다.

helm repo add gitlab https://charts.gitlab.io

helm install gitlab-runner 
  --set gitlabUrl=https://gitlab.com 
  --set runnerRegistrationToken=yga8y-jdCusVDn_t4Wxc 
  --set rbac.create=true 
  gitlab/gitlab-runner

장소 :

• https://gitlab.com — Gitlab 서버의 주소입니다.
• yga8y-jdCusVDn_t4Wxc — 프로젝트의 등록 토큰.
• rbac.create=true — kubernetes-executor를 사용하여 작업을 수행하기 위한 포드를 생성하는 데 필요한 권한을 실행자에게 제공합니다.

모든 것이 올바르게 완료되면 해당 섹션에 등록된 주자가 표시됩니다. 주자, 프로젝트 설정에서.

추가된 실행기의 스크린샷

그렇게 간단합니까? - 네, 정말 간단해요! 더 이상 수동으로 러너를 등록하는 번거로움이 없습니다. 이제부터 러너는 자동으로 생성되고 삭제됩니다.

6. QBEC를 사용하여 Helm 차트 배포

우리가 고려하기로 결정했기 때문에 gitlab 러너 프로젝트의 일부이므로 Git 저장소에 설명할 차례입니다.

별도의 구성 요소로 설명할 수 있습니다. 웹 사이트하지만 앞으로는 다른 복사본을 배포할 계획입니다. 웹 사이트 매우 자주, 달리 gitlab 러너, 이는 Kubernetes 클러스터당 한 번만 배포됩니다. 따라서 이를 위한 별도의 애플리케이션을 초기화해 보겠습니다.

cd deploy
qbec init gitlab-runner
cd gitlab-runner

이번에는 Kubernetes 엔터티를 수동으로 설명하지 않고 미리 만들어진 Helm 차트를 사용하겠습니다. qbec의 장점 중 하나는 Git 저장소에서 직접 Helm 차트를 렌더링하는 기능입니다.

git 하위 모듈을 사용하여 연결해 보겠습니다.

git submodule add https://gitlab.com/gitlab-org/charts/gitlab-runner vendor/gitlab-runner

이제 디렉토리 벤더/gitlab-runner gitlab-runner에 대한 차트가 있는 저장소가 있습니다.

비슷한 방식으로 다른 저장소(예: 공식 차트가 있는 전체 저장소)를 연결할 수 있습니다. https://github.com/helm/charts

구성품을 설명하자면 구성 요소/gitlab-runner.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.gitlabRunner;

std.native('expandHelmTemplate')(
  '../vendor/gitlab-runner',
  params.values,
  {
    nameTemplate: params.name,
    namespace: env.namespace,
    thisFile: std.thisFile,
    verbose: true,
  }
)

첫 번째 주장 ExpandHelmTemplate 차트의 경로를 전달한 다음 매개변수.값, 환경 매개변수에서 가져온 다음

• 이름템플릿 — 릴리스 이름
• 네임 스페이스 — helm으로 네임스페이스가 전송됨
• 이 파일 — 현재 파일의 경로를 전달하는 필수 매개변수
• 말 수가 많은 - 명령을 보여줍니다 조타 템플릿 차트를 렌더링할 때 모든 인수 포함

이제 구성요소의 매개변수를 설명하겠습니다. 환경/base.libsonnet:

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
      },
    },
  },
}

주의 러너등록토큰 우리는 외부 파일에서 가져옵니다 비밀/base.libsonnet, 만들어 보겠습니다.

{
  runnerRegistrationToken: 'yga8y-jdCusVDn_t4Wxc',
}

모든 것이 작동하는지 확인해 보겠습니다.

qbec show default

모든 것이 정상이면 Helm을 통해 이전에 배포한 릴리스를 삭제할 수 있습니다.

helm uninstall gitlab-runner

동일한 방식으로 배포하되, qbec을 통해:

qbec apply default

7. git-crypt 소개

힘내 암호화 저장소에 대한 투명한 암호화를 설정할 수 있는 도구입니다.

현재 gitlab-runner의 디렉토리 구조는 다음과 같습니다.

.
├── components
│   ├── gitlab-runner.jsonnet
├── environments
│   ├── base.libsonnet
│   └── default.libsonnet
├── params.libsonnet
├── qbec.yaml
├── secrets
│   └── base.libsonnet
└── vendor
    └── gitlab-runner (submodule)

하지만 Git에 비밀을 저장하는 것은 안전하지 않습니다. 그렇죠? 그래서 우리는 그것들을 적절하게 암호화해야 합니다.

일반적으로 하나의 변수 때문에 이것이 항상 의미가 있는 것은 아닙니다. 다음으로 비밀을 전송할 수 있습니다. 큐벡 CI 시스템의 환경 변수를 통해.
그러나 더 많은 비밀을 포함할 수 있는 더 복잡한 프로젝트도 있다는 점은 주목할 가치가 있으며, 이를 모두 환경 변수를 통해 전송하는 것은 매우 어려울 것입니다.

게다가 이 경우에는 다음과 같은 훌륭한 도구에 대해 말할 수 없습니다. 자식 암호.

자식 암호 Git의 경우와 동일한 방식으로 비밀의 전체 기록을 저장하고 충돌을 비교, 병합 및 해결할 수 있다는 점에서도 편리합니다.

설치 후 가장 먼저 할 일은 자식 암호 저장소에 대한 키를 생성해야 합니다.

git crypt init

PGP 키가 있으면 즉시 이 프로젝트의 공동 작업자로 자신을 추가할 수 있습니다.

git-crypt add-gpg-user [email protected]

이렇게 하면 언제든지 개인 키를 사용하여 이 저장소의 암호를 해독할 수 있습니다.

PGP 키가 없고 예상하지 못한 경우 다른 방법으로 프로젝트 키를 내보낼 수 있습니다.

git crypt export-key /path/to/keyfile

따라서 수출을 한 사람은 누구나 키 파일 저장소를 해독할 수 있습니다.

이제 첫 번째 비밀을 설정할 시간입니다.
우리가 아직 디렉토리에 있다는 것을 상기시켜 드리겠습니다. 배포/gitlab-runner/, 디렉토리가 있는 곳 비밀/, 그 안에 있는 모든 파일을 암호화하겠습니다. 이를 위해 파일을 생성하겠습니다. 비밀/.gitattributes 다음 내용으로:

* filter=git-crypt diff=git-crypt
.gitattributes !filter !diff

내용에서 볼 수 있듯이 모든 파일이 마스크되어 있습니다. * 통해 구동됩니다 자식 암호, 대부분을 제외하고 .git속성

다음을 실행하여 이를 확인할 수 있습니다.

git crypt status -e

출력은 암호화가 활성화된 저장소의 모든 파일 목록입니다.

그게 다입니다. 이제 변경 사항을 안전하게 커밋할 수 있습니다.

cd ../..
git add .
git commit -m "Add deploy for gitlab-runner"

저장소를 차단하려면 다음을 실행하세요.

git crypt lock

암호화된 모든 파일은 즉시 바이너리로 변환되어 읽을 수 없게 됩니다.
저장소를 복호화하려면 다음을 실행하세요.

git crypt unlock

8. 도구 상자 이미지 만들기

도구 상자 이미지는 프로젝트를 배포하는 데 사용할 모든 도구가 포함된 이미지입니다. Gitlab 실행기가 일반적인 배포 작업을 수행하는 데 사용됩니다.

여기서는 모든 것이 간단합니다. 새 것을 만들어 보겠습니다. dockerfiles/도구 상자/Dockerfile 다음 내용으로:

FROM alpine:3.11

RUN apk add --no-cache git git-crypt

RUN QBEC_VER=0.10.3 
 && wget -O- https://github.com/splunk/qbec/releases/download/v${QBEC_VER}/qbec-linux-amd64.tar.gz 
     | tar -C /tmp -xzf - 
 && mv /tmp/qbec /tmp/jsonnet-qbec /usr/local/bin/

RUN KUBECTL_VER=1.17.0 
 && wget -O /usr/local/bin/kubectl 
      https://storage.googleapis.com/kubernetes-release/release/v${KUBECTL_VER}/bin/linux/amd64/kubectl 
 && chmod +x /usr/local/bin/kubectl

RUN HELM_VER=3.0.2 
 && wget -O- https://get.helm.sh/helm-v${HELM_VER}-linux-amd64.tar.gz 
     | tar -C /tmp -zxf - 
 && mv /tmp/linux-amd64/helm /usr/local/bin/helm

보시다시피 이 이미지에서는 애플리케이션을 배포하는 데 사용한 모든 유틸리티를 설치합니다. 여기서는 필요하지 않습니다. 쿠 베틀, 그러나 파이프라인 설정 단계에서 이를 가지고 놀고 싶을 수도 있습니다.

또한 Kubernetes와 통신하고 배포하려면 gitlab-runner에서 생성된 Pod에 대한 역할을 구성해야 합니다.

이를 위해 gitlab-runner가 있는 디렉터리로 이동해 보겠습니다.

cd deploy/gitlab-runner

그리고 새로운 컴포넌트를 추가하세요 구성 요소/rbac.jsonnet:

local env = {
  name: std.extVar('qbec.io/env'),
  namespace: std.extVar('qbec.io/defaultNs'),
};
local p = import '../params.libsonnet';
local params = p.components.rbac;

[
  {
    apiVersion: 'v1',
    kind: 'ServiceAccount',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'Role',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    rules: [
      {
        apiGroups: [
          '*',
        ],
        resources: [
          '*',
        ],
        verbs: [
          '*',
        ],
      },
    ],
  },
  {
    apiVersion: 'rbac.authorization.k8s.io/v1',
    kind: 'RoleBinding',
    metadata: {
      labels: {
        app: params.name,
      },
      name: params.name,
    },
    roleRef: {
      apiGroup: 'rbac.authorization.k8s.io',
      kind: 'Role',
      name: params.name,
    },
    subjects: [
      {
        kind: 'ServiceAccount',
        name: params.name,
        namespace: env.namespace,
      },
    ],
  },
]

또한 환경/base.libsonnet, 이제 다음과 같습니다.

local secrets = import '../secrets/base.libsonnet';

{
  components: {
    gitlabRunner: {
      name: 'gitlab-runner',
      values: {
        gitlabUrl: 'https://gitlab.com/',
        rbac: {
          create: true,
        },
        runnerRegistrationToken: secrets.runnerRegistrationToken,
        runners: {
          serviceAccountName: $.components.rbac.name,
          image: 'registry.gitlab.com/kvaps/docs.example.org/toolbox:v0.0.1',
        },
      },
    },
    rbac: {
      name: 'gitlab-runner-deploy',
    },
  },
}

주의 $.comComponents.rbac.name ~을 참고하여 name 구성요소용 백팩

무엇이 변경되었는지 확인해 보겠습니다.

qbec diff default

Kubernetes에 변경 사항을 적용합니다.

qbec apply default

또한 변경 사항을 git에 커밋하는 것을 잊지 마세요.

cd ../..
git add dockerfiles/toolbox
git commit -m "Add Dockerfile for toolbox"
git add deploy/gitlab-runner
git commit -m "Configure gitlab-runner to use toolbox"

9. 첫 번째 파이프라인과 태그별 이미지 조립

프로젝트의 루트에서 우리는 만들 것입니다 .gitlab-ci.yml 다음 내용으로:

.build_docker_image:
  stage: build
  image:
    name: gcr.io/kaniko-project/executor:debug-v0.15.0
    entrypoint: [""]
  before_script:
    - echo "{"auths":{"$CI_REGISTRY":{"username":"$CI_REGISTRY_USER","password":"$CI_REGISTRY_PASSWORD"}}}" > /kaniko/.docker/config.json

build_toolbox:
  extends: .build_docker_image
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR/dockerfiles/toolbox --dockerfile $CI_PROJECT_DIR/dockerfiles/toolbox/Dockerfile --destination $CI_REGISTRY_IMAGE/toolbox:$CI_COMMIT_TAG
  only:
    refs:
      - tags

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_TAG
  only:
    refs:
      - tags

우리가 사용하는 것을 참고하십시오 GIT_SUBMODULE_STRATEGY: 정상 실행 전에 하위 모듈을 명시적으로 초기화해야 하는 작업의 경우.

변경 사항을 커밋하는 것을 잊지 마세요.

git add .gitlab-ci.yml
git commit -m "Automate docker build"

나는 이것을 버전이라고 안전하게 부를 수 있다고 생각합니다. v0.0.1 태그를 추가합니다.

git tag v0.0.1

새 버전을 출시해야 할 때마다 태그를 추가할 것입니다. Docker 이미지의 태그는 Git 태그에 연결됩니다. 새 태그가 포함된 각 푸시는 이 태그를 사용하여 이미지 빌드를 초기화합니다.

해보자 자식 푸시 --태그, 첫 번째 파이프라인을 살펴보겠습니다.

첫 번째 파이프라인의 스크린샷

태그를 통한 어셈블리는 Docker 이미지 구축에는 적합하지만 Kubernetes에 애플리케이션을 배포하는 데는 적합하지 않다는 사실에 주목할 가치가 있습니다. 이전 커밋에 새 태그를 할당할 수 있으므로 이 경우 해당 태그에 대한 파이프라인을 초기화하면 이전 버전이 배포됩니다.

이 문제를 해결하기 위해 일반적으로 도커 이미지 빌드가 태그에 연결되고 애플리케이션을 분기에 배포됩니다. 석사, 수집된 이미지의 버전이 하드코딩됩니다. 간단한 되돌리기로 롤백을 초기화할 수 있는 곳입니다. 석사-가지.

10. 배포 자동화

Gitlab-runner가 비밀을 해독하려면 저장소 키를 내보내고 이를 CI 환경 변수에 추가해야 합니다.

git crypt export-key /tmp/docs-repo.key
base64 -w0 /tmp/docs-repo.key; echo

결과 줄을 Gitlab에 저장하겠습니다. 이를 위해 프로젝트 설정으로 이동하겠습니다.
설정 -> CI/CD -> 변수

그리고 새 변수를 만들어 보겠습니다.

타입
키
가치관
보호
가면
범위

File
GITCRYPT_KEY
<your string>
true (훈련 중에 당신은 할 수 있습니다 false)
true
All environments

추가된 변수의 스크린샷

이제 업데이트해 보겠습니다. .gitlab-ci.yml 그것에 추가 :

.deploy_qbec_app:
  stage: deploy
  only:
    refs:
      - master

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes

deploy_website:
  extends: .deploy_qbec_app
  script:
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes

여기에서는 qbec에 대한 몇 가지 새로운 옵션을 활성화했습니다.

• --일부/앱 루트 — 특정 응용 프로그램의 디렉터리를 결정할 수 있습니다.
• --force:k8s-컨텍스트 __incluster__ - 이는 gtilab-runner가 실행 중인 동일한 클러스터에서 배포가 발생함을 나타내는 마법 변수입니다. 그렇지 않으면 qbec이 kubeconfig에서 적합한 Kubernetes 서버를 찾으려고 시도하기 때문에 이는 필요합니다.
• --기다리다 — qbec이 생성한 리소스가 준비 상태가 될 때까지 기다린 다음 성공적인 종료 코드로 종료하도록 강제합니다.
• -예 - 단순히 대화형 쉘을 비활성화합니다. 확실합니까? 배포할 때.

변경 사항을 커밋하는 것을 잊지 마세요.

git add .gitlab-ci.yml
git commit -m "Automate deploy"

그리고 후에 git push 애플리케이션이 어떻게 배포되었는지 살펴보겠습니다.

두 번째 파이프라인의 스크린샷

11. 마스터로 푸시할 때 아티팩트 및 어셈블리

일반적으로 위에 설명된 단계는 거의 모든 마이크로서비스를 구축하고 제공하는 데 충분하지만 사이트를 업데이트해야 할 때마다 태그를 추가하고 싶지는 않습니다. 따라서 보다 동적인 경로를 선택하고 마스터 브랜치에 다이제스트 배포를 설정하겠습니다.

아이디어는 간단합니다. 이제 우리의 이미지는 웹 사이트 밀어넣을 때마다 다시 작성됩니다. 석사, Kubernetes에 자동으로 배포됩니다.

이 두 가지 작업을 업데이트해 보겠습니다. .gitlab-ci.yml:

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/
  only:
    refs:
      - master
      - tags

deploy_website:
  extends: .deploy_qbec_app
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

스레드를 추가했습니다. 석사 к 심판 일자리를 위해 build_website 이제 우리는 $CI_COMMIT_REF_NAME 대신 $CI_COMMIT_TAG즉, Git의 태그에서 연결이 해제되었으며 이제 파이프라인을 초기화한 커밋 브랜치의 이름으로 이미지를 푸시합니다. 이는 태그와 함께 작동하므로 docker-registry의 특정 버전으로 사이트의 스냅샷을 저장할 수 있다는 점은 주목할 가치가 있습니다.

사이트의 새 버전에 대한 Docker 태그 이름을 변경할 수 있는 경우에도 Kubernetes에 대한 변경 사항을 설명해야 합니다. 그렇지 않으면 새 이미지에서 애플리케이션을 재배포하지 않습니다. 배포 매니페스트.

옵션 —vm:ext-str 다이제스트=”$DIGEST” qbec의 경우 - 외부 변수를 jsonnet에 전달할 수 있습니다. 우리는 애플리케이션이 릴리스될 때마다 클러스터에 이를 재배포하기를 원합니다. 이미지의 특정 버전에 연결하고 변경 시 배포를 트리거해야 하므로 이제 변경할 수 없는 태그 이름을 더 이상 사용할 수 없습니다.

여기에서는 다이제스트 이미지를 파일에 저장하는 Kaniko의 기능을 통해 도움을 받을 수 있습니다(옵션 --다이제스트 파일)
그런 다음 이 파일을 전송하고 배포 시 읽어보겠습니다.

매개변수를 업데이트해 보겠습니다. 배포/웹사이트/환경/base.libsonnet 이제 다음과 같이 보일 것입니다:

{
  components: {
    website: {
      name: 'example-docs',
      image: 'registry.gitlab.com/kvaps/docs.example.org/website@' + std.extVar('digest'),
      replicas: 1,
      containerPort: 80,
      servicePort: 80,
      nodeSelector: {},
      tolerations: [],
      ingressClass: 'nginx',
      domain: 'docs.example.org',
    },
  },
}

완료되었습니다. 이제 모든 커밋이 완료되었습니다. 석사 도커 이미지 빌드를 초기화합니다. 웹 사이트, Kubernetes에 배포합니다.

변경 사항을 커밋하는 것을 잊지 마세요.

git add .
git commit -m "Configure dynamic build"

나중에 확인해보겠습니다 git push 우리는 다음과 같은 것을 보게 될 것입니다:

마스터용 파이프라인 스크린샷

원칙적으로 푸시할 때마다 gitlab-runner를 다시 배포할 필요는 없습니다. 물론 구성이 변경되지 않은 한 수정해 보겠습니다. .gitlab-ci.yml:

deploy_gitlab_runner:
  extends: .deploy_qbec_app
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  before_script:
    - base64 -d "$GITCRYPT_KEY" | git-crypt unlock -
  script:
    - qbec apply default --root deploy/gitlab-runner --force:k8s-context __incluster__ --wait --yes
  only:
    changes:
      - deploy/gitlab-runner/**/*

변경 변경사항을 모니터링할 수 있습니다. 배포/gitlab-runner/ 있는 경우에만 작업을 트리거합니다.

변경 사항을 커밋하는 것을 잊지 마세요.

git add .gitlab-ci.yml
git commit -m "Reduce gitlab-runner deploy"

git push, 그게 낫다:

업데이트된 파이프라인의 스크린샷

12. 동적 환경

이제 역동적인 환경으로 파이프라인을 다양화할 때입니다.

먼저 작업을 업데이트하겠습니다. build_website 우리의 .gitlab-ci.yml, 블록을 제거합니다. 만, 이는 Gitlab이 모든 브랜치에 대한 커밋에서 이를 트리거하도록 강제합니다.

build_website:
  extends: .build_docker_image
  variables:
    GIT_SUBMODULE_STRATEGY: normal
  script:
    - mkdir -p $CI_PROJECT_DIR/artifacts
    - /kaniko/executor --cache --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/dockerfiles/website/Dockerfile --destination $CI_REGISTRY_IMAGE/website:$CI_COMMIT_REF_NAME --digest-file $CI_PROJECT_DIR/artifacts/website.digest
  artifacts:
    paths:
      - artifacts/

그런 다음 작업을 업데이트하세요. 배포_웹사이트, 거기에 블록을 추가하세요 환경:

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

이를 통해 Gitlab은 작업을 다음과 연결할 수 있습니다. 찌르다 환경에 대한 올바른 링크를 표시합니다.

이제 두 가지 작업을 더 추가해 보겠습니다.

deploy_website:
  extends: .deploy_qbec_app
  environment:
    name: prod
    url: https://docs.example.org
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply default --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST"

deploy_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    url: http://$CI_ENVIRONMENT_SLUG.docs.example.org
    on_stop: stop_review
  script:
    - DIGEST="$(cat artifacts/website.digest)"
    - qbec apply review --root deploy/website --force:k8s-context __incluster__ --wait --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  only:
    refs:
    - branches
  except:
    refs:
      - master

stop_review:
  extends: .deploy_qbec_app
  environment:
    name: review/$CI_COMMIT_REF_NAME
    action: stop
  stage: deploy
  before_script:
    - git clone "$CI_REPOSITORY_URL" master
    - cd master
  script:
    - qbec delete review --root deploy/website --force:k8s-context __incluster__ --yes --vm:ext-str digest="$DIGEST" --vm:ext-str subdomain="$CI_ENVIRONMENT_SLUG" --app-tag "$CI_ENVIRONMENT_SLUG"
  variables:
    GIT_STRATEGY: none
  only:
    refs:
    - branches
  except:
    refs:
      - master
  when: manual

마스터를 제외한 모든 분기에 푸시하면 시작되며 사이트의 미리 보기 버전이 배포됩니다.

qbec에 대한 새로운 옵션이 표시됩니다. --앱 태그 — 배포된 애플리케이션 버전에 태그를 지정하고 이 태그 내에서만 작업할 수 있습니다. Kubernetes에서 리소스를 생성하고 삭제할 때 qbec은 해당 리소스로만 작동합니다.
이렇게 하면 각 리뷰마다 별도의 환경을 만들 수 없고 단순히 동일한 환경을 재사용할 수 있습니다.

여기서 우리도 사용합니다 qbec 적용 검토대신에 qbec 기본값 적용 - 이것이 바로 환경(검토 및 기본값)의 차이점을 설명하려고 시도하는 순간입니다.

추가 리뷰 환경 배포/웹사이트/qbec.yaml

spec:
  environments:
    review:
      defaultNamespace: docs
      server: https://kubernetes.example.org:8443

그러면 우리는 그것을 선언할 것이다. 배포/웹사이트/params.libsonnet:

local env = std.extVar('qbec.io/env');
local paramsMap = {
  _: import './environments/base.libsonnet',
  default: import './environments/default.libsonnet',
  review: import './environments/review.libsonnet',
};

if std.objectHas(paramsMap, env) then paramsMap[env] else error 'environment ' + env + ' not defined in ' + std.thisFile

그리고 이에 대한 맞춤 매개변수를 적어두세요. 배포/웹사이트/환경/review.libsonnet:

// this file has the param overrides for the default environment
local base = import './base.libsonnet';
local slug = std.extVar('qbec.io/tag');
local subdomain = std.extVar('subdomain');

base {
  components+: {
    website+: {
      name: 'example-docs-' + slug,
      domain: subdomain + '.docs.example.org',
    },
  },
}

조부도 좀 더 자세히 살펴보자 stop_review, 브랜치가 삭제되면 트리거되며 gitlab이 체크아웃을 시도하지 않도록 사용됩니다. GIT_STRATEGY: 없음, 나중에 복제합니다 석사-브랜치를 통해 리뷰를 삭제합니다.
조금 헷갈리긴 하지만 아직은 이보다 더 아름다운 방법을 찾지 못했습니다.
또 다른 옵션은 각 리뷰를 호텔 네임스페이스에 배포하는 것입니다. 이 네임스페이스는 항상 완전히 철거될 수 있습니다.

변경 사항을 커밋하는 것을 잊지 마세요.

git add .
git commit -m "Enable automatic review"

git push, 자식 체크 아웃 -b 테스트, git 푸시 오리진 테스트, 확인하다:

Gitlab에서 생성된 환경의 스크린샷

모든 것이 작동하고 있나요? - 좋습니다. 테스트 브랜치를 삭제하세요. 자식 체크 아웃 마스터, git push 원점 : 테스트, 환경 삭제 작업이 오류 없이 작동했는지 확인합니다.

여기서는 프로젝트의 모든 개발자가 브랜치를 생성할 수 있고 변경할 수도 있다는 점을 즉시 명확히 하고 싶습니다. .gitlab-ci.yml 파일을 저장하고 비밀 변수에 액세스합니다.
따라서 보호된 분기에만 사용을 허용하는 것이 좋습니다. 석사, 또는 각 환경에 대해 별도의 변수 세트를 생성합니다.

13. 앱 검토

앱 검토 저장소의 각 파일에 버튼을 추가하여 배포된 환경에서 빠르게 볼 수 있는 GitLab 기능입니다.

이 버튼을 표시하려면 파일을 만들어야 합니다. .gitlab/route-map.yml 그리고 그 안의 모든 경로 변환을 설명합니다. 우리의 경우에는 매우 간단합니다.

# Indices
- source: /content/(.+?)_index.(md|html)/ 
  public: '1'

# Pages
- source: /content/(.+?).(md|html)/ 
  public: '1/'

변경 사항을 커밋하는 것을 잊지 마세요.

git add .gitlab/
git commit -m "Enable review apps"

git push, 확인:

앱 검토 버튼 스크린샷

작업이 완료되었습니다!

프로젝트 소스:

• Gitlab에서: https://gitlab.com/kvaps/docs.example.org
• GitHub에서: https://github.com/kvaps/docs.example.org

관심을 가져주셔서 감사합니다. 마음에 드셨기를 바랍니다.

출처 : habr.com