こんにちは！ 最近、Docker イメージの構築と Kubernetes へのデプロイメントの両方のために、多くの優れた自動化ツールがリリースされました。 この点で、私は GitLab を試してみて、その機能を徹底的に研究し、そしてもちろんパイプラインをセットアップすることにしました。

この作品はウェブサイトからインスピレーションを得て制作されました kubernetes.ioから生成されます。 ソースコード ロボットは、プール リクエストが送信されるたびに、変更を加えたサイトのプレビュー バージョンを自動的に生成し、表示用のリンクを提供します。

私も同様のプロセスをゼロから構築しようとしましたが、完全に Gitlab CI と、アプリケーションを Kubernetes にデプロイするために使い慣れている無料ツールに基づいて構築されました。 今日はいよいよそれらについて詳しくお話します。

この記事では、次のようなツールについて説明します。
ヒューゴー, ケベック, かにこ, git-crypt и GitLab CI 動的な環境を作成します。

コンテンツ

1. ヒューゴに会う
2. Dockerfileの準備
3. カニコとの出会い
4. キューベックを知る
5. Kubernetes-executor で Gitlab-runner を試す
6. qbec を使用した Helm チャートのデプロイ
7. git-crypt の紹介
8. ツールボックスイメージの作成
9. 最初のパイプラインとタグによる画像のアセンブリ
10. 導入の自動化
11. マスターにプッシュする際のアーティファクトとアセンブリ
12. 動的な環境
13. アプリを確認する

1. ヒューゴについて知る

私たちのプロジェクトの例として、Hugo 上に構築されたドキュメント公開サイトを作成してみます。 Hugo は静的コンテンツ ジェネレーターです。

静電気発生器について詳しくない方のために、静電気発生器についてもう少し詳しく説明します。 ユーザーのリクエストに応じてその場でページを生成する、データベースと一部の PHP を備えた従来の Web サイト エンジンとは異なり、静的ジェネレーターは少し異なる設計になっています。 これらを使用すると、ソース (通常はマークダウン マークアップとテーマ テンプレート内の一連のファイル) を取得し、それらをコンパイルして完全に完成した Web サイトを作成できます。

つまり、結果として、ディレクトリ構造と生成された HTML ファイルのセットを受け取り、それを安価なホスティングにアップロードするだけで、機能する Web サイトを取得できます。

Hugo をローカルにインストールして試してみることができます。

新しいサイトの初期化:

hugo new site docs.example.org

そして同時に git リポジトリ:

cd docs.example.org
git init

これまでのところ、私たちのサイトは手つかずの状態であり、そこに何かを表示するには、まずテーマを接続する必要があります。テーマとは、サイトを生成するためのテンプレートと指定されたルールのセットにすぎません。

今回使用するテーマとしては、 リソース私の意見では、これはドキュメント サイトに最適です。

テーマ ファイルをプロジェクト リポジトリに保存する必要はなく、代わりに次を使用して簡単に接続できるという事実に特に注意を払いたいと思います。 gitサブモジュール:

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/ 新しく作成された Web サイトをチェックしてください。ディレクトリ内で行われたすべての変更は、ブラウザで開いているページを自動的に更新します。非常に便利です。

で表紙を作ってみましょう コンテンツ/_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

• ドッカーファイル/ — Dockerfile を含むディレクトリと、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 には XNUMX つのファイルが含まれています。 FROM、この機能はと呼ばれます 多段階ビルド 最終的な Docker イメージから不要なものをすべて除外できます。
したがって、最終的な画像には、 ダークhttpd (軽量のHTTPサーバー)および 公衆/ — 静的に生成された Web サイトのコンテンツ。

変更をコミットすることを忘れないでください。

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

3. カニコを知る

Dockerイメージビルダーとして、私は使用することにしました かにこなぜなら、その操作には Docker デーモンが必要なく、ビルド自体は任意のマシン上で実行でき、キャッシュはレジストリに直接保存できるため、本格的な永続ストレージが必要なくなります。

イメージをビルドするには、次のようにコンテナを実行します。 カニコ執行者 そして、現在のビルド コンテキストを渡します。これは、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 イメージの名前。ビルド後、Docker レジストリに自動的に起動されます。

パラメーター - キャッシュ レイヤーを Docker レジストリにキャッシュできます。この例では、レイヤーは次の場所に保存されます。 registry.gitlab.com/kvaps/docs.example.org/website/cacheただし、パラメータを使用して別のパスを指定することもできます --キャッシュリポジトリ.

docker-registry のスクリーンショット

4. qbec について知る

ケベック は、アプリケーション マニフェストを宣言的に記述し、Kubernetes にデプロイできるデプロイメント ツールです。 Jsonnet をメイン構文として使用すると、複数の環境間の相違点の説明が大幅に簡素化され、コードの繰り返しもほぼ完全に排除されます。

これは、異なるパラメーターを使用して複数のクラスターにアプリケーションをデプロイする必要があり、それらを Git で宣言的に記述したい場合に特に当てはまります。

Qbec では、必要なパラメーターを渡して Helm チャートをレンダリングし、通常のマニフェストと同じ方法で操作することもできます。これには、さまざまなミューテーションを適用することもできます。これにより、次の必要性を取り除くことができます。チャートミュージアムを利用します。 つまり、グラフが属する 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、そこにはパラメータを取得する場所が記載されています。

次に XNUMX つのディレクトリが表示されます。

• コンポーネント/ — アプリケーションのすべてのマニフェストはここに保存され、jsonnet ファイルと通常の yaml ファイルの両方で記述できます。
• 環境/ — ここでは、環境のすべての変数 (パラメーター) について説明します。

デフォルトでは、次の XNUMX つのファイルがあります。

• 環境/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,
                },
              },
            ],
          },
        },
      ],
    },
  },
]

このファイルでは、次の XNUMX つの Kubernetes エンティティを一度に説明しました。 展開, カスタマーサービス и 進入。 必要に応じて、それらを別のコンポーネントに含めることもできますが、この段階では XNUMX つで十分です。

構文 ジェソネット 通常の json と非常によく似ています。原則として、通常の json はすでに有効な jsonnet であるため、最初は次のようなオンライン サービスを使用する方が簡単かもしれません。 yaml2json 通常の yaml を json に変換するか、コンポーネントに変数が含まれていない場合は、通常の yaml の形式で記述することができます。

で作業するとき ジェソネット エディタ用のプラグインをインストールすることを強くお勧めします

たとえば、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 でそのようなランナーをいくつかグローバルに定義していました。 彼らはすべてのプロジェクトの Docker イメージを収集しました。

しかし、実践が示しているように、このオプションは実用性と安全性の両方の点で最も理想的ではありません。 プロジェクトごと、さらには環境ごとに個別のランナーをデプロイする方がはるかに優れており、イデオロギー的にもより正確です。

幸いなことに、これはまったく問題ではありません。これからデプロイするからです。 gitlab ランナー Kubernetes のプロジェクトの一部として直接。

Gitlab は、gitlab-runner を Kubernetes にデプロイするための既製の Helm チャートを提供します。 だからあなたがしなければならないのはそれを見つけることだけです 登録トークン 私たちのプロジェクトのために 設定 -> CI / CD -> ランナー そしてそれをヘルムに渡します。

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 クラスターごとに XNUMX 回だけデプロイされます。 そこで、それ用に別のアプリケーションを初期化しましょう。

cd deploy
qbec init gitlab-runner
cd gitlab-runner

今回は、Kubernetes エンティティを手動で記述するのではなく、既製の Helm チャートを使用します。 qbec の利点の XNUMX つは、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 チャートへのパスを渡します。 params.values、環境パラメータから取得し、オブジェクトに付属します。

• 名前テンプレート — リリース名
• 名前空間 — 名前空間が 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 の概要

Git 暗号化 は、リポジトリに透過的な暗号化を設定できるツールです。

現時点では、gitlab-runner のディレクトリ構造は次のようになります。

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

しかし、Git にシークレットを保存するのは安全ではありません。 したがって、それらを適切に暗号化する必要があります。

通常、XNUMX つの変数の場合、これは常に意味があるわけではありません。 シークレットを転送できるのは、 ケベック CI システムの環境変数を介して。
ただし、さらに多くのシークレットを含む可能性のあるより複雑なプロジェクトも存在することは注目に値します。環境変数を介してそれらすべてを転送するのは非常に困難です。

さらに、この場合、次のような素晴らしいツールについて説明することはできません。 git-crypt.

git-crypt また、Git の場合と同じ方法で、シークレットの履歴全体を保存したり、比較、マージ、競合を解決したりできるという点でも便利です。

インストール後の最初のこと git-crypt リポジトリのキーを生成する必要があります。

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-crypt、ほとんどを除いて .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 によって生成されたポッドのロールを構成する必要があります。

これを行うには、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',
    },
  },
}

注意 $.components.rbac.name を指します 名 コンポーネント用 rbac

何が変わったのかを確認してみましょう:

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 タグに関連付けられます。 新しいタグを使用してプッシュするたびに、このタグを使用してイメージのビルドが初期化されます。

やりましょう git Push --tagsでは、最初のパイプラインを見てみましょう。

最初のパイプラインのスクリーンショット

タグによるアセンブリは Docker イメージの構築には適していますが、Kubernetes へのアプリケーションのデプロイには適していないという事実に注意を払う価値があります。 新しいタグは古いコミットに割り当てることができるため、この場合、それらのタグのパイプラインを初期化すると、古いバージョンがデプロイされます。

この問題を解決するには、通常、Docker イメージのビルドをタグに関連付け、アプリケーションをブランチにデプロイします。 マスター、収集されたイメージのバージョンがハードコーディングされています。 ここで、単純な元に戻すことでロールバックを初期化できます。 マスター-枝。

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 のいくつかの新しいオプションを有効にしました。

• --root some/app — 特定のアプリケーションのディレクトリを特定できます。
• --force:k8s-context __incluster__ - これは、gtilab-runner が実行されているのと同じクラスターでデプロイメントが行われることを示すマジック変数です。 これが必要なのは、そうしないと qbec が kubeconfig で適切な Kubernetes サーバーを見つけようとするためです。
• - 待って — qbec は、作成したリソースが Ready 状態になるまで待機し、その後、成功した終了コードで終了します。
• -はい - インタラクティブシェルを無効にするだけです 本気ですか？ 導入時。

変更をコミットすることを忘れないでください。

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

そしてその後 git push アプリケーションがどのようにデプロイされているかを見てみましょう。

XNUMX 番目のパイプラインのスクリーンショット

11. マスターにプッシュする際のアーティファクトとアセンブリ

通常、上記の手順でほぼすべてのマイクロサービスを構築して配信できますが、サイトを更新する必要があるたびにタグを追加する必要はありません。 したがって、より動的なルートを選択し、master ブランチにダイジェスト デプロイメントをセットアップします。

アイデアはシンプルです。今、私たちのイメージが ウェブサイト 押し込むたびに再構築されます マスター、その後、自動的に Kubernetes にデプロイされます。

これら XNUMX つのジョブを更新しましょう .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"

スレッドを追加しましたのでご了承ください マスター к ヒント 仕事のために ビルドウェブサイト そして私たちは今使用しています $CI_COMMIT_REF_NAME 代わりに $CI_COMMIT_TAGつまり、Git のタグから解放され、パイプラインを初期化したコミット ブランチの名前を持つイメージをプッシュします。 これはタグでも機能するので、特定のバージョンのサイトのスナップショットを docker レジストリに保存できることは注目に値します。

サイトの新しいバージョンの 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',
    },
  },
}

完了しました。コミットが完了しました。 マスター の Docker イメージのビルドを初期化します。 ウェブサイトを作成し、それを 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. 動的環境

動的な環境でパイプラインを多様化する時期が来ています。

まず、ジョブを更新しましょう ビルドウェブサイト 私たちの中に .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 がジョブを 突く 環境を修正し、その環境への正しいリンクを表示します。

次に、さらに XNUMX つのジョブを追加しましょう。

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',
    },
  },
}

ジョブについても詳しく見てみましょう ストップレビュー、ブランチが削除されたときにトリガーされ、gitlab がチェックアウトしようとしないように使用されます。 GIT_STRATEGY: なし、後でクローンを作成します マスター-分岐してレビューを削除します。
少しややこしいですが、これより美しい方法はまだ見つかりません。
代替オプションは、各レビューをホテルの名前空間にデプロイすることです。これはいつでも完全に破棄できます。

変更をコミットすることを忘れないでください。

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

git push, git チェックアウト -b テスト, gitプッシュオリジンテスト、 チェック：

Gitlab で作成された環境のスクリーンショット

すべてが機能していますか？ - わかりました。テスト ブランチを削除します。 git checkout master, git プッシュオリジン:テスト、環境削除ジョブがエラーなしで機能したことを確認します。

ここで、プロジェクト内の開発者は誰でもブランチを作成でき、変更もできることをすぐに明確にしたいと思います。 .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