DigitalOceanでGitLabRunnerを使用してGitLabの継続的デプロイを自動スケーリングする方法

序章

GitLabは、ソフトウェアチームが完全な開発と配信のライフサイクルを管理するために使用するオープンソースツールです。 GitLabは、問題追跡、gitリポジトリ、継続的インテグレーション、コンテナレジストリ、デプロイ、モニタリングなど、幅広い機能セットを提供します。 これらの機能はすべて、単一のアプリケーションとしてゼロから構築されています。 独自のサーバーでGitLabをホストすることも、 GitLab.com を使用することもできます。これは、オープンソースプロジェクトがすべての最上位機能を無料で利用できるクラウドサービスです。

GitLabの継続的インテグレーション/継続的デリバリー（CI / CD）機能は、デプロイする前にすべてのコードをテストする習慣を身に付けるための効果的な方法です。 GitLab CI / CDは、追加のツールであるGitLab Runnerのおかげで非常にスケーラブルです。このツールは、開発チームがコードをリリースしようとする長い待機時間を回避するために、ビルドキューのスケーリングを自動化します。

このガイドでは、独自のコストを管理し、使用可能なサーバー容量を増減することで負荷に自動的に応答する、高度にスケーラブルなGitLabインフラストラクチャを構成する方法を示します。

目標

DigitalOcean上にスケーラブルなCI/CDプロセスを構築します。このプロセスは、プラットフォーム上に新しいサーバーを作成し、キューが空になるとそれらを破棄することで、需要に自動的に応答します。

これらの再利用可能なサーバーはGitLabRunnerプロセスによって生成され、ジョブが実行されていないときに自動的に削除されるため、チームのコストと管理オーバーヘッドが削減されます。

このチュートリアルで説明するように、任意の時点で作成されるマシンの数と、それらが破棄されるまでに保持される時間の長さを制御できます。

このプロジェクトを構築するために3つの別々のサーバーを使用するので、最初に用語を確認しましょう。

• GitLab ：コードリポジトリが保存されているホストされたGitLabインスタンスまたは自己ホストされたインスタンス。

• GitLab Bastion ： Bastion サーバーまたはDropletは、構成するものの中核です。 これは、DigitalOcean APIと対話してドロップレットを作成し、必要に応じてそれらを破棄するために使用されるコントロールインスタンスです。 このサーバーではジョブは実行されません。

• GitLab Runners ： runners は、ビルドでCI / CDジョブを実行する必要がある場合に、bastionサーバーによってオンザフライで作成される一時サーバーまたはドロップレットです。列。 これらのサーバーは使い捨てであり、ビルドが合格または不合格としてマークされる前にコードが実行またはテストされる場所です。

CI / CDプロセスは、GitLabの各コンポーネントを活用することで、要求に応じて迅速にスケーリングできるようにします。 これらの目標を念頭に置いて、GitLabとDigitalOceanを使用した継続的デプロイのセットアップを開始する準備が整いました。

前提条件

このチュートリアルでは、独自のサーバーまたはホストされたサービスを介してGitLabを構成済みであり、既存のDigitalOceanアカウントを持っていることを前提としています。

これをUbuntu16.04ドロップレットに設定するには、DigitalOceanのワンクリックイメージを使用するか、ガイド「 Ubuntu16.04にGitLabをインストールして構成する方法」に従ってください。

このチュートリアルでは、このドロップレットでプライベートネットワークが有効になっていることを前提としています。これは、「既存のドロップレットでDigitalOceanプライベートネットワークを有効にする方法」のガイドに従うことで実現できますが、必須ではありません。 。

このチュートリアル全体を通して、Dropletsの管理者権限を持つroot以外のユーザーを使用します。

ステップ1—JavaScriptプロジェクトをインポートする

まず、サンプルのNode.jsアプリケーションを含む既存のGitLabインスタンスに新しいサンプルプロジェクトを作成します。

GitLabインスタンスにログインし、プラスアイコンをクリックして、ドロップダウンメニューから新規プロジェクトを選択します。

新しいプロジェクト画面で、プロジェクトのインポートタグを選択し、 URLによるリポジトリをクリックして、サンプルプロジェクトをGitHubから直接インポートします。

以下のクローンURLをGitリポジトリのURLに貼り付けます。

https://github.com/do-community/hello_hapi.git

このリポジトリは、デモンストレーションを目的とした基本的なJavaScriptアプリケーションであり、本番環境では実行しません。 インポートを完了するには、新規プロジェクトボタンをクリックします。

これで新しいプロジェクトがGitLabに追加され、CIパイプラインのセットアップを開始できます。

ステップ2—インフラストラクチャをセットアップする

GitLabコードランナーでは、CIの負荷が拡大および縮小するときに処理するドロップレットをプログラムで作成することを計画しているため、特定の構成が必要です。

このチュートリアルでは、2種類のマシンを作成します。新しいマシンを制御して生成する bastion インスタンスと、要塞ドロップレットによって生成される一時サーバーであるrunnerインスタンスです。必要に応じてコードを記述します。 要塞インスタンスはDockerを使用してランナーを作成します。

使用するDigitalOcean製品と、各コンポーネントの用途は次のとおりです。

• フレキシブルドロップレット—コンテナ化にDockerを使用して実行されるメモリを大量に消費するプロセスであるため、GitLabランナー用にメモリ最適化ドロップレットを作成します。 将来、必要に応じてこのドロップレットを縮小または拡大できますが、負荷がかかった状態でパイプラインがどのように機能するかを理解するための開始点として、柔軟なドロップレットオプションをお勧めします。

• DigitalOcean Spaces（オブジェクトストレージ） — DigitalOcean Spaces を使用して、キャッシュされたビルドコンポーネントが作成および破棄されたときに、ランナー全体で永続化します。 これにより、CIパイプラインがビジー状態のときに新しいランナーをセットアップするために必要な時間が短縮され、新しいランナーが他のランナーが中断したところからすぐに再開できるようになります。

• プライベートネットワーク—安全なコードコンパイルを保証し、必要なファイアウォール構成を減らすために、要塞DropletおよびGitLabランナー用のプライベートネットワークを作成します。

まず、要塞ドロップレットを作成します。 新しいドロップレットを作成し、画像を選択で、ワンクリックアプリタブを選択します。 そこから、 Docker 17.12.0-ce on 16.04 を選択し（このバージョンは執筆時点で最新であることに注意してください）、利用可能な最小のドロップレットサイズを選択します。これは、要塞のドロップレットが他のドロップレットの作成を管理するためです。ドロップレットは実際にテストを実行するのではなく。

前述のオブジェクトストレージキャッシュ機能を使用するには、 DigitalOceanSpacesを含むデータセンターにサーバーを作成することをお勧めします。

プライベートネットワークとモニタリングの両方のオプションを選択し、ドロップレットの作成をクリックします。

また、キャッシュに使用するストレージスペースを設定する必要があります。 「DigitalOceanスペースとAPIキーを作成する方法」の手順に従って、ホストされているGitLabインスタンスと同じまたは最も近いデータセンターにAPIキーとともに新しいスペースを作成します。

チュートリアルの後半で必要になるため、このキーを押し下げてください。

それでは、CIを開始しましょう。

ステップ3—GitLabRunner要塞サーバーを構成する

新しいDropletの準備ができたら、GitLabRunnerを構成できます。 GitLabおよびGitHubリポジトリからスクリプトをインストールします。

以下の完全なコマンドを実行する前に、ベストプラクティスとして、スクリプトを調べてインストールするものを確認してください。

SSHを使用してドロップレットに接続し、に移動します /tmp ディレクトリを作成し、公式GitLabRunnerリポジトリをUbuntuのパッケージマネージャーに追加します。

cd /tmp
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash

追加したら、GitLabRunnerアプリケーションをインストールします。

sudo apt-get install gitlab-runner

また、 Docker Machine をインストールする必要があります。これは、クラウドプロバイダーでのコンテナーのデプロイの自動化を支援する追加のDockerツールです。

curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && \
sudo install /tmp/docker-machine /usr/local/bin/docker-machine

これらのインストールが完了したら、GitLabRunnerをGitLabインストールに接続することに進むことができます。

ステップ4—ランナー登録トークンを取得する

GitLab Runnerを既存のGitLabインストールにリンクするには、コードリポジトリに対してランナーを認証するトークンを取得して、2つのインスタンスをリンクする必要があります。

管理者ユーザーとして既存のGitLabインスタンスにログインし、レンチアイコンをクリックして管理者設定領域に入ります。

画面の左側で、概要にカーソルを合わせ、表示されるリストからランナーを選択します。

新しいプロジェクトの共有ランナーを設定する方法セクションの[ランナー]ページで、手順3に示したトークンをコピーし、手順からGitLabインスタンスのパブリックにアクセス可能なURLと一緒にメモします。 2.2。 GitlabにHTTPSを使用している場合は、それが自己署名証明書でないことを確認してください。そうでない場合、GitLabRunnerは起動に失敗します。

ステップ5—バスティオンドロップレットでGitLabを構成する

要塞ドロップレットを使用してSSH接続に戻り、次のコマンドを実行します。

sudo gitlab-runner register

これにより、リンクプロセスが開始され、一連の質問が表示されます。

次のステップで、前のステップのGitLabインスタンスURLを入力します。

Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com)
https://example.digitalocean.com

GitLabインスタンスから取得したトークンを入力します。

Please enter the gitlab-ci token for this runner
sample-gitlab-ci-token

GitLabWebインターフェースでそれを認識するのに役立つ説明を入力します。 このインスタンスに、次のような一意の名前を付けることをお勧めします runner-bastion 明確にするために。

Please enter the gitlab-ci description for this runner
[yourhostname] runner-bastion

必要に応じて、ランナーで作成するコードのタグを入力できます。 ただし、この段階では空白のままにしておくことをお勧めします。 これは、後でGitLabインターフェースから簡単に変更できます。

Please enter the gitlab-ci tags for this runner (comma separated):
code-tag

ランナーがタグなしのジョブを実行できるかどうかを選択します。 この設定により、ランナーがタグなしでリポジトリを構築するか、特定のタグを要求するかを選択できます。 この場合はtrueを選択して、ランナーがすべてのリポジトリを実行できるようにします。

Whether to run untagged jobs [true/false]: true

このランナーをプロジェクト間で共有するか、現在のランナーにロックして、指定されたコード以外のコードをビルドできないようにするかを選択します。 後でGitLabのインターフェースで変更できるため、今のところfalseを選択します。

Whether to lock Runner to current project [true/false]: false

マシンを構築するエグゼキュータを選択します。 Dockerを使用して新しいドロップレットを作成するため、 docker+machine ここにありますが、この互換性チャートで各アプローチの利点について詳しく読むことができます。

Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
docker+machine

明示的に定義されていないプロジェクトに使用する画像を尋ねられます。 基本的で安全なデフォルトを選択します。

Please enter the Docker image (e.g. ruby:2.1):
alpine:latest

これで、コア要塞ランナーの構成が完了しました。 この時点で、トークンを取得するためにアクセスしたGitLab管理者設定のGitLabRunnerページに表示されます。

これらの手順で問題が発生した場合は、GitLabRunnerのドキュメントにトラブルシューティングのオプションが含まれています。

ステップ6—DockerキャッシングとDockerマシンを構成する

ビルドキューがビジー状態のときにDropletの作成を高速化するために、Bastion DropletのDockerのキャッシュツールを利用して、DigitalOceanSpacesで一般的に使用されるコンテナーのイメージを保存します。

これを行うには、次のコマンドを使用してSSHシェルのDockerマシンをアップグレードします。

curl -L https://github.com/docker/machine/releases/download/v0.14.0/docker-machine-`uname -s`-`uname -m` >/tmp/docker-machine && sudo install /tmp/docker-machine /usr/local/bin/docker-machine

Docker Machineをアップグレードすると、GitLabRunnerが使用するアクセストークンの設定に進むことができます。

ステップ7—DigitalOceanクレデンシャルを収集する

次に、GitLabRunnerがDigitalOceanアカウントを使用して新しいドロップレットを作成するために使用するクレデンシャルを作成する必要があります。

DigitalOcean ダッシュボードにアクセスし、APIをクリックします。 次の画面で、パーソナルアクセストークンを探し、新しいトークンの生成をクリックします。

新しいトークンに、認識できる名前を付けます。 GitLab Runner Access 人間の介入なしに新しいマシンを作成するにはDropletが必要なので、読み取りスコープと書き込みスコープの両方が有効になっていることを確認してください。

次のステップで使用するので、トークンを安全な場所にコピーします。 このトークンを再生成せずに再度取得することはできないため、安全に保管されていることを確認してください。

ステップ8—GitLabRunner構成ファイルを編集する

これらすべてのコンポーネントをまとめるには、DigitalOceanアカウントと通信するための要塞ドロップレットの構成を完了する必要があります。

要塞ドロップレットへのSSH接続で、nanoなどのお気に入りのテキストエディターを使用して、編集用にGitLabRunner構成ファイルを開きます。

nano /etc/gitlab-runner/config.toml

この構成ファイルは、CIセットアップがオンデマンドでスケールアップおよびスケールダウンするために使用するルールを担当します。 オンデマンドで自動スケーリングするように要塞を構成するには、次の行を追加する必要があります。

concurrent = 50   # All registered Runners can run up to 50 concurrent builds

[[runners]]
  url = "https://example.digitalocean.com"
  token = "existinggitlabtoken"             # Note this is different from the registration token used by `gitlab-runner register`
  name = "example-runner"
  executor = "docker+machine"        # This Runner is using the 'docker+machine' executor
  limit = 10                         # This Runner can execute up to 10 builds (created machines)
  [runners.docker]
    image = "alpine:latest"               # Our secure image
  [runners.machine]
    IdleCount = 1                    # The amount of idle machines we require for CI if build queue is empty
    IdleTime = 600                   # Each machine can be idle for up to 600 seconds, then destroyed
    MachineName = "gitlab-runner-autoscale-%s"    # Each machine will have a unique name ('%s' is required and generates a random number)
    MachineDriver = "digitalocean"   # Docker Machine is using the 'digitalocean' driver
    MachineOptions = [
        "digitalocean-image=coreos-stable", # The DigitalOcean system image to use by default
        "digitalocean-ssh-user=core", # The default SSH user
        "digitalocean-access-token=DO_ACCESS_TOKEN", # Access token from Step 7
        "digitalocean-region=nyc3", # The data center to spawn runners in
        "digitalocean-size=1gb", # The size (and price category) of your spawned runners
        "digitalocean-private-networking" # Enable private networking on runners
    ]
  [runners.cache]
    Type = "s3"   # The Runner is using a distributed cache with the S3-compatible Spaces service
    ServerAddress = "nyc3.spaces.digitaloceanspaces.com"
    AccessKey = "YOUR_SPACES_KEY"
    SecretKey = "YOUR_SPACES_SECRET"
    BucketName = "your_bucket_name"
    Insecure = true # We do not have a SSL certificate, as we are only running locally 

新しい行を追加したら、設定に基づいてアクセストークン、リージョン、およびドロップレットのサイズをカスタマイズします。 このチュートリアルでは、最小のドロップレットサイズである1GBを使用し、NYC3でドロップレットを作成しました。 自分のケースに関連する情報を必ず使用してください。

また、キャッシュコンポーネントをカスタマイズし、インフラストラクチャの構成手順からSpaceのサーバーアドレス、アクセスキー、秘密キー、および作成したSpaceの名前を入力する必要があります。

完了したら、GitLab Runnerを再起動して、構成が使用されていることを確認します。

gitlab-runner restart

オフピーク時間を含む、利用可能なすべてのオプションについて詳しく知りたい場合は、GitLabの高度なドキュメントをお読みください。

ステップ9—GitLabランナーをテストする

この時点で、GitLab Runner要塞ドロップレットが構成され、CIキューがいっぱいになると、オンデマンドでDigitalOceanドロップレットを作成できるようになります。 GitLabインスタンスとステップ1でインポートしたプロジェクトに移動して、動作することを確認するためにテストする必要があります。

ビルドをトリガーするには、 readme.md ファイルをクリックし、編集をクリックして、関連するテストテキストをファイルに追加し、変更のコミットをクリックします。

これで、ビルドが自動的にトリガーされます。これは、左側のナビゲーションのプロジェクトの CI /CDオプションの下にあります。

このページには、ステータスがrunningのパイプラインエントリが表示されます。 DigitalOceanアカウントには、この変更を構築するためにGitLabRunnerによって自動的に作成された多数のドロップレットが表示されます。

おめでとう！ CIパイプラインはクラウドスケーラブルであり、独自のリソース使用量を管理するようになりました。 指定されたアイドル時間の後、マシンは自動的に破棄されますが、予期せず請求されないように、これを手動で確認することをお勧めします。

トラブルシューティング

場合によっては、GitLabがランナーに到達できないことを報告し、その結果、新しいランナーのデプロイを含むアクションを実行しないことがあります。 これをトラブルシューティングするには、GitLab Runnerを停止してから、デバッグモードで再開します。

gitlab-runner stop
gitlab-runner --debug start

出力はエラーをスローするはずです。これは、問題の原因となっている構成を特定するのに役立ちます。

構成によって作成されるマシンが多すぎて、それらをすべて同時に削除する場合は、次のコマンドを実行してすべてを破棄できます。

docker-machine rm $(docker-machine ls -q)

その他のトラブルシューティング手順と追加の構成オプションについては、GitLabのドキュメントを参照してください。

結論

これで、GitLabRunnerとDockerを使用して自動CI/CDパイプラインを正常にセットアップできました。 ここから、Docker Registryを使用してより高いレベルのキャッシュを構成し、パフォーマンスを最適化したり、特定のGitLabコードランナーへのタグ付けコードビルドの使用を検討したりできます。

GitLab Runnerの詳細については、詳細なドキュメントを参照してください。詳細については、GitLabの一連のブログ投稿で継続的インテグレーションパイプラインを最大限に活用する方法をご覧ください。

この投稿は、GitLabブログにも掲載されています。