GitLab-CI 可観測性のベストプラクティス¶

GitLab¶

GitLab は、GitLab Inc. によって開発された、MIT ライセンスに基づくWebベースの Git リポジトリ管理ツールであり、wiki および Issue 追跡機能を備えています。Git をコード管理ツールとして使用し、その上に構築された Web サービスです。

CI/CD¶

CI/CD は、継続的インテグレーション（Continuous Integration: CI）、継続的デリバリー（Continuous Delivery: CD）、継続的デプロイメント（Continuous Deployment: CD）の総称です。
継続的インテグレーションの重点は、各開発者の作業を1つのコードリポジトリに統合することです。通常、1日に数回実行され、主な目的は統合エラーを早期に発見し、チームの結束を強化し、より良いコラボレーションを実現することです。
継続的デリバリーの目的は、デプロイメントまたはリリースに固有の摩擦を最小限に抑えることです。その実現により、通常はビルドからデプロイまでの各ステップが自動化され、いつでも安全にコードをリリースできるようになります（理想的には）。
継続的デプロイメントはさらに高度な自動化であり、コードに重要な変更が加えられるたびに、自動的にビルド/デプロイが実行されます。
いくつかの CI/CD ツール:

Jenkins

GitLab CI

Travis CI

GoCD

GitLab CI¶

GitLab CI/CD（以下、GitLab CI）は、GitLab ベースの CI/CD システムであり、CI/CD 分野では比較的新しいプレイヤーですが、Forrester Wave の継続的インテグレーションツールにおいてすでにリーダー的な地位を占めています。開発者は .gitlab-ci.yml を使用してプロジェクトに CI/CD パイプラインを設定でき、コミット後、システムは自動的または手動でジョブを実行し、CI/CD 操作を完了します。また、その設定は非常に簡単で、CI Runner は Go 言語で記述され、最終的に単一ファイルにパッケージ化されるため、1つの Runner プログラムと、ジョブを実行するための実行プラットフォーム（ベアメタル + SSH、Docker、Kubernetes など。Docker はセットアップが非常に簡単なため推奨）があれば、完全な CI/CD システムを実行できます。

Guance¶

「Guance」は、クラウド時代のシステム可観測性プラットフォームです。このプラットフォームには、インフラストラクチャ、ログ、メトリクス、イベント、APM、RUM、Synthetic モニタリング、システムレベルのセキュリティチェックなどの機能モジュールが含まれており、これら機能によって生成されるログ、メトリクス、トレースの3種類のデータに対して、全リンクレベルのデータ分析とインサイト機能を提供します。H5、iOS、Android、ミニプログラムなどのアプリケーションを完全にカバーし、ユーザーアクセス行動と実際のエクスペリエンスを完全に追跡し、ページパフォーマンス、リソース呼び出し、エラーアラート、ビジネスアクセスなどの一連のデータと分析ビューを提供します。分散型トレーシングと連携し、アプリケーションのパフォーマンスと各リクエストの背後にある真のニーズをリアルタイムで把握するのに役立ちます。柔軟なシナリオレイアウト、豊富なチャートオプション、ドラッグアンドドロップによるインタラクティブな操作により、自分だけのダッシュボードを簡単に構築できます。統一されたデータクエリ方式により、さまざまなデータの設定がサポートされ、簡単に使い始めることができます。

DataKit¶

DataKit は Guance のオープンソース収集ツールです。オープンソースアドレス: https://github.com/DataFlux-cn/datakit

背景¶

マイクロサービスの普及に伴い、企業はモノリシックなサービスアーキテクチャからマイクロサービスアーキテクチャへと徐々に移行し始めています。マイクロサービスの特徴の1つは、多数のエンジニアリングモジュールが存在し、デプロイも比較的複雑になることです。CICD ツールは統合されたデプロイメントをうまく実現できますが、デプロイプロセス中に発生するいくつかの問題を統計的に分析することは困難です。Guance の強力な可観測性とカスタムビュー機能を活用することで、継続的デプロイプロセス中に発生する問題を効果的に表示および分析できます。

アーキテクチャフロー¶

開発者がコードをコミット＆プッシュ

GitLab Runner が GitLab に登録

GitLab がトリガーを実行し、GitLab CI を起動

GitLab CI の実行完了後、Webhook をトリガーしてデータを DataKit にプッシュ

DataKit がタグを付与し、Guance プラットフォームにプッシュ

前提条件¶

DataKit のインストール
DataKit の接続バージョン >= 1.2.13

DataKit で GitLab CI を有効化¶

gitlab.conf の編集¶

cd conf.d/gitlab cp gitlab.conf.sample gitlab.conf

gitlab.conf 全文

[[inputs.gitlab]]
## 以下の URL からメトリクスを収集する場合は true に設定
enable_collect = false

## パラメータタイプ: string - デフォルト: http://127.0.0.1:80/-/metrics
prometheus_url = "http://127.0.0.1:80/-/metrics"

## パラメータタイプ: string - オプション: 時間単位は "ms", "s", "m", "h" - デフォルト: 10s
interval = "10s"

## 有効にすると、datakit は /v1/gitlab で GitLab CI データをリスン可能
enable_ci_visibility = true

## GitLab CI データ用の追加タグ。
## これらのタグは既存のタグを上書きしません。
[inputs.gitlab.ci_extra_tags]
# some_tag = "some_value"
# more_tag = "some_other_value"

## GitLab メトリクス用の追加タグ
[inputs.gitlab.tags]
# some_tag = "some_value"
# more_tag = "some_other_value"

パラメータ説明
enable_collect: false # メトリクス収集を無効化
prometheus_url: メトリクス収集アドレス
enable_ci_visibility: true # GitLab CI を有効化

DataKit の再起動¶

datakit --restart

GitLab のインストールと設定¶

すでにインストール済みの場合は、この手順をスキップしてください。

Docker で GitLab をインストール¶

docker run --name=gitlab -d -p 8899:8899 -p 2443:443 --restart always --volume /data/midsoftware/gitlab/config:/etc/gitlab --volume /data/midsoftware/gitlab/logs:/var/log/gitlab --volume /data/midsoftware/gitlab/data:/var/opt/gitlab docker.io/gitlab/gitlab-ce

ポートの説明

ポート	説明
8899	GitLab UI ポート
2443	GitLab SSL ポート

設定ファイルの修正: gitlab.rb¶

# アクセス URL
external_url 'http://192.168.91.11:8899'

# タイムアウト時間を設定、デフォルトは 10（単位: 秒）
gitlab_rails['webhook_timeout'] = 60

GitLab の再起動¶

docker restart gitlab

GitLab バージョンの確認¶

[root@middle config]# docker exec -it gitlab cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
14.6.2

GitLab 初期パスワードの確認¶

[root@middle config]# docker exec -it gitlab cat /etc/gitlab/initial_root_password |grep Password
#          2. Password hasn't been changed manually, either via UI or via command line.
Password: yBY9toQ0SJ8fxh3mndHPzfWclVUDZ/J8e8O4bDsal2E=

アカウントは root、ブラウザで http://ip:8899 にアクセスし、パスワードを変更してください。

最初のプロジェクトを作成¶

menu -> Projects -> your projects -> new projects -> select create blank project. プロジェクト名を入力します。

GitLab Runner のインストールと設定¶

すでにインストール済みの場合は、この手順をスキップしてください。

Docker で GitLab Runner をインストール¶

docker run -d --name gitlab-runner --restart always \
    -v /data/midsoftware/gitlab-runner/config:/etc/gitlab-runner \
    -v /var/run/docker.sock:/var/run/docker.sock \
    gitlab/gitlab-runner:latest

GitLab Runner 認証トークン¶

GitLab Runner は現在グローバル設定をサポートしていないため、Runner のトークンはプロジェクト内で確認する必要があります。作成したばかりのプロジェクトに移動し、Settings -> Runners の順に選択し、トークンをコピーします。これは次の Runner 登録手順で必要になります。

GitLab Runner の GitLab への登録¶

docker run --rm -v /data/midsoftware/gitlab-runner/config:/etc/gitlab-runner gitlab/gitlab-runner register \
  --non-interactive \
  --executor "docker" \
  --docker-image alpine:latest \
  --url "http://192.168.91.11:8899" \
  --registration-token "U6uhCZGPrZ7tGs6aV8rY" \
  --description "gitlab-runner" \
  --tag-list "docker,localMachine" \
  --run-untagged="true" \
  --locked="false" \
  --access-level="not_protected"

パラメータの説明

パラメータ名	値	説明
executor	docker	他のものを使用することも、このパラメータを省略することも可能です。Docker 環境にデプロイする場合は、docker を推奨します。
docker-image	alpine:latest	docker-image のバージョン。executor と組み合わせて使用します。
url	http://192.168.91.11:8899	GitLab のアクセス URL
registration-token	token	GitLab 管理者トークン
description	gitlab-runner	説明情報
tag-list	docker,localMachine	タグに基づいて対応する Executor を選択できます。

その他のパラメータについては、https://docs.gitlab.com/runner/configuration/advanced-configuration.html を参照してください。

GitLab Webhook の設定¶

作成したばかりのプロジェクトに移動し、Settings -> Webhooks を選択し、URL を入力し、Pipeline events にチェックを入れて保存します。

説明:

URL: http:///v1/gitlab

Job events を有効化

Pipeline events を有効化

Test -> Pipeline events を選択すると、パイプラインイベントがトリガーされ、設定した Webhook アドレスにデータがプッシュされます。状態を確認し、このプロセスが正常に動作しているかどうかを検出します。

.gitlab-ci.yml の作成¶

作成したばかりのプロジェクトに移動し、CI/CD -> Editor を選択します。

スクリプトの内容を入力します。内容は以下の通りです。

# 実行イメージを設定
image: busybox:latest

# パイプライン全体には2つのステージがある
stages:
  - build
  - test

before_script:
  - echo "Before script section"

after_script:
  - echo "After script section"


build_job:
  stage: build
  only:
    - master
  script:
    - echo "将内容写入缓存"
    - sleep 80s
    # - d ps 

test_job:
  stage: test
  script:
    - echo "从缓存读取内容"

保存をクリックすると、自動的に CI/CD がトリガーされます。トリガー後、プロセスは Webhook を通じて、先ほど設定した Webhook アドレスにプッシュされます。

Webhook プッシュ記録の確認¶

ステータスが 200 の場合は、プッシュが成功したことを示します。

Guance¶

パイプラインのプッシュが成功したら、Guance プラットフォームを通じて、ダッシュボードとエクスプローラーを使用して、パイプラインの実行状況を視覚的に観測できます。

CI エクスプローラー¶

メニューの CI エクスプローラーから、gitlab_pipeline と gitlab_job の詳細を確認できます。

gitlab_pipeline:

gitlab_job:

詳細をクリックすると、フレームグラフとジョブリストを表示できます。
フレームグラフ

CI 概要¶

CI 概要では、GitLab CI のパイプラインとジョブの実行状況を確認できます。例えば、パイプラインの実行成功率、実行時間、ジョブの実行成功率、実行時間などです。

GitLab-CI 可観測性のベストプラクティス¶

GitLab¶

CI/CD¶

GitLab CI¶

Guance¶

DataKit¶

背景¶

アーキテクチャフロー¶

前提条件¶

DataKit で GitLab CI を有効化¶

gitlab.conf の編集¶

DataKit の再起動¶

GitLab のインストールと設定¶

Docker で GitLab をインストール¶

設定ファイルの修正: gitlab.rb¶

GitLab の再起動¶

GitLab バージョンの確認¶

GitLab 初期パスワードの確認¶

最初のプロジェクトを作成¶

GitLab Runner のインストールと設定¶

Docker で GitLab Runner をインストール¶

GitLab Runner 認証トークン¶

GitLab Runner の GitLab への登録¶

GitLab Webhook の設定¶

.gitlab-ci.yml の作成¶

Webhook プッシュ記録の確認¶

Guance¶

CI エクスプローラー¶

CI 概要¶

このページは役に立ちましたか？ ×

このページは役に立ちましたか？