前書き
GitLabは、ソフトウェアチームが完全な開発および配信ライフサイクルを管理するために使用するオープンソースツールです。 GitLabは、問題追跡、gitリポジトリ、継続的統合、コンテナレジストリ、展開、監視などの幅広い機能を提供します。 これらの機能はすべて、単一のアプリケーションとしてゼロから構築されています。 独自のサーバーでGitLabをホストするか、https://gitlab.com [GitLab.com]を使用できます。これは、オープンソースプロジェクトがすべての最上位機能を無料で入手できるクラウドサービスです。
GitLabの継続的インテグレーション/継続的デリバリー(CI / CD)機能は、展開する前にすべてのコードをテストする習慣を構築する効果的な方法です。 GitLab CI / CDは、追加のツールであるGitLab Runnerのおかげで非常にスケーラブルです。GitLabRunnerは、コードをリリースしようとする開発チームの長い待ち時間を避けるために、ビルドキューのスケーリングを自動化します。
このガイドでは、独自のコストを管理し、使用可能なサーバー容量を増減することで負荷に自動的に対応する、高度にスケーラブルなGitLabインフラストラクチャを構成する方法を示します。
目標
プラットフォーム上に新しいサーバーを作成し、キューが空になるとそれらを破棄することにより、需要に自動的に応答するスケーラブルなCI / CDプロセスをDigitalOcean上に構築します。
これらの再利用可能なサーバーはGitLab Runnerプロセスによって生成され、ジョブが実行されていないときに自動的に削除されるため、チームのコストと管理オーバーヘッドが削減されます。
このチュートリアルで説明するように、任意の時点で作成されるマシンの数と、それらが破壊されるまで保持される時間の長さを制御できます。
このプロジェクトを構築するために3つの個別のサーバーを使用するので、最初に用語について説明します。
-
* GitLab *:コードリポジトリが保存されているホストされたGitLabインスタンスまたは自己ホストされたインスタンス。
-
* GitLab Bastion *:_bastion_サーバーまたはDropletは、構成するものの中核です。 DigitalOcean APIと対話してドロップレットを作成し、必要に応じてドロップレットを破棄するために使用されるのは、コントロールインスタンスです。 このサーバーではジョブは実行されません。
-
* GitLab Runners *:_runners_は、ビルドキューでCI / CDジョブを実行する必要があるときに、_bastion_サーバーによってオンザフライで作成される一時的なサーバーまたはドロップレットです。 これらのサーバーは使い捨てであり、ビルドが合格または失敗としてマークされる前にコードが実行またはテストされる場所です。
image:https://assets.digitalocean.com/articles/gitlab-runner/Autoscaling-GitLab-Runners.png [GitLab Runners Diagram]
GitLabの各コンポーネントを活用することにより、CI / CDプロセスでは、要求に応じてレスポンシブにスケーリングできます。 これらの目標を念頭に置いて、GitLabとDigitalOceanによる継続的な展開のセットアップを開始する準備ができています。
前提条件
このチュートリアルでは、ご使用のサーバー上またはホストされたサービスを介してGitLabが既に構成されており、既存のDigitalOceanアカウントがあることを前提としています。
Ubuntu 16.04ドロップレットでこれを設定するには、DigitalOceanのワンクリックイメージを使用するか、ガイドに従ってください:“ https://www.digitalocean.com/community/tutorials/how-to-install-and-configure- gitlab-on-ubuntu-16-04 [Ubuntu 16.04でGitLabをインストールおよび構成する方法]。
このチュートリアルでは、このDropletでプライベートネットワークが有効になっていることを前提としています。これは、「https://www.digitalocean.com/community/tutorials/how-to-enable-digitalocean- private-networking-on-existing-droplets [既存のドロップレットでDigitalOceanプライベートネットワーキングを有効にする方法]、しかし必須ではありません。
このチュートリアルでは、Dropletsで管理者権限を持つ非ルートユーザーを使用します。
ステップ1-JavaScriptプロジェクトのインポート
まず、サンプルのNode.jsアプリケーションを含む既存のGitLabインスタンスに新しいサンプルプロジェクトを作成します。
image:https://assets.digitalocean.com/articles/gitlab-runner/gitlab.jpg [GitLab Interface]
GitLabインスタンスにログインし、プラスアイコン*をクリックして、ドロップダウンメニューから[*新しいプロジェクト]を選択します。
新しいプロジェクト画面で、* Import project タグを選択し、 Repo by URL *をクリックして、サンプルプロジェクトをGitHubから直接インポートします。
以下のクローンURLをGitリポジトリURLに貼り付けます。
https://github.com/do-community/hello_hapi.git
このリポジトリはデモンストレーションを目的とした基本的なJavaScriptアプリケーションであり、実稼働環境では実行しません。 インポートを完了するには、[新しいプロジェクト]ボタンをクリックします。
新しいプロジェクトがGitLabに追加され、CIパイプラインのセットアップを開始できます。
ステップ2-インフラストラクチャをセットアップする
GitLab Code Runnerには、CIロードの増減に応じて処理するドロップレットをプログラムで作成することを計画しているため、特定の構成が必要です。
このチュートリアルでは、新しいマシンを制御および生成する* bastion インスタンスと、必要に応じてコードを構築するために要塞Dropletによって生成される一時サーバーである runner *インスタンスの2種類のマシンを作成します。 要塞インスタンスは、Dockerを使用してランナーを作成します。
使用するDigitalOcean製品と、各コンポーネントの用途は次のとおりです。
-
柔軟なドロップレット-コンテナ化のためにDockerを使用して実行されるメモリ集約型プロセスであるため、GitLab Runner向けにメモリ最適化されたドロップレットを作成します。 将来、必要に応じてこのドロップレットを縮小または拡大できますが、負荷がかかった状態でパイプラインがどのように実行されるかを理解するための出発点として、柔軟なドロップレットオプションをお勧めします。
-
* DigitalOcean Spaces(オブジェクトストレージ)*-https://www.digitalocean.com/products/spaces/[DigitalOcean Spaces]を使用して、ランナーの作成および破棄時にキャッシュされたビルドコンポーネントをランナー全体に保持します。 これにより、CIパイプラインがビジー状態のときに新しいランナーを設定するのに必要な時間が短縮され、新しいランナーは他の人がすぐに中断したところを見つけることができます。
-
プライベートネットワーキング-安全なコードコンパイルを確保し、必要なファイアウォール構成を削減するために、要塞DropletおよびGitLabランナー用のプライベートネットワークを作成します。
まず、要塞ドロップレットを作成します。 new Dropletを作成し、画像を選択*で、*ワンクリックアプリ*タブを選択します。 そこから、 16.04のDocker *(このバージョンは執筆時点で最新であることに注意してください)を選択し、要塞Dropletが実際にテストを実行するのではなく、他のDropletの作成を管理するため、利用可能な最小のDropletサイズを選択します。
オブジェクトストレージキャッシュ機能を使用するには、https://www.digitalocean.com/community/tutorials/an-introduction-to-digitalocean-spaces [DigitalOcean Spaces]を含むデータセンターにサーバーを作成することをお勧めします。先に述べた。
*プライベートネットワーキング*および*モニタリング*オプションの両方を選択し、*ドロップレットの作成*をクリックします。
また、キャッシュに使用されるストレージスペースを設定する必要があります。 「https://www.digitalocean.com/community/tutorials/how-to-create-a-digitalocean-space-and-api-key[DigitalOceanスペースとAPIキーを作成する方法]」の手順に従って作成しますホストされているGitLabインスタンスと同じまたは最も近いデータセンターにある新しいスペースとAPIキー。
このキーは、チュートリアルの後半で必要になるため、メモしておいてください。
さあ、CIを始めましょう!
ステップ3-GitLab Runner Bastion Serverを構成する
新しいDropletの準備ができたら、GitLab Runnerを構成できます。 GitLabおよびGitHubリポジトリからスクリプトをインストールします。
ベストプラクティスとして、以下のすべてのコマンドを実行する前に、スクリプトを調べて、インストールする内容を確認してください。
SSHを使用してDropletに接続し、 `+ / tmp +`ディレクトリに移動して、https://docs.gitlab.com/runner/install/linux-repository.html [公式GitLab Runnerリポジトリ]をUbuntuのパッケージマネージャーに追加します。
cd /tmp
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
追加したら、GitLab Runnerアプリケーションをインストールします。
sudo apt-get install gitlab-runner
また、* https://docs.docker.com/machine/install-machine/#install-machine-directly [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
これらのインストールが完了したら、GitLab RunnerをGitLabインストールに接続します。
ステップ4-ランナー登録トークンを取得する
GitLab Runnerを既存のGitLabインストールにリンクするには、ランナーをコードリポジトリに認証するトークンを取得して、2つのインスタンスをリンクする必要があります。
既存のGitLabインスタンスに管理ユーザーとしてログインし、レンチアイコンをクリックして管理設定領域に入ります。
画面の左側にある[概要]にカーソルを合わせ、表示されるリストから[ランナー]を選択します。
[新しいプロジェクトの共有ランナーをセットアップする方法]セクションの[ランナー]ページで、ステップ3に示すトークンをコピーし、ステップ2のGitLabインスタンスのパブリックにアクセス可能なURLとともにメモします。 GitlabにHTTPSを使用している場合、それが自己署名証明書ではないことを確認してください。そうしないと、GitLab Runnerが起動に失敗します。
手順5-BastionドロップレットでGitLabを構成する
要塞ドロップレットを使用してSSH接続に戻り、次のコマンドを実行します。
sudo gitlab-runner register
これによりリンクプロセスが開始され、一連の質問が表示されます。
次のステップで、前のステップの* GitLabインスタンスURL *を入力します。
Please enter the gitlab-ci coordinator URL (e.g. https://gitlab.com)
GitLabインスタンスから取得したトークンを入力します。
Please enter the gitlab-ci token for this runner
GitLab Webインターフェースで認識しやすい説明を入力してください。 わかりやすくするために、このインスタンスに「+ runner-bastion +」のような一意の名前を付けることをお勧めします。
Please enter the gitlab-ci description for this runner
関連する場合は、ランナーでビルドするコードのタグを入力できます。 ただし、この段階では空白のままにすることをお勧めします。 これは、後でGitLabインターフェイスから簡単に変更できます。
Please enter the gitlab-ci tags for this runner (comma separated):
ランナーがタグなしジョブを実行できるかどうかを選択します。 この設定により、ランナーがタグなしでリポジトリを構築するか、特定のタグを必要とするかを選択できます。 この場合はtrueを選択して、ランナーがすべてのリポジトリを実行できるようにします。
Whether to run untagged jobs [true/false]:
このランナーをプロジェクト間で共有するか、現在のプロジェクトにロックするかを選択して、指定されたもの以外のコードのビルドをブロックします。 現時点ではfalseを選択します。これは後でGitLabのインターフェースで変更できます。
Whether to lock Runner to current project [true/false]:
マシンをビルドするエグゼキューターを選択します。 Dockerを使用して新しいドロップレットを作成するので、ここでは「+ docker + machine +」を選択しますが、このhttps://docs.gitlab.com/runner/executors/で各アプローチの利点について詳しく読むことができますREADME.html#compatibility-chart [互換性チャート]:
Please enter the executor: ssh, docker+machine, docker-ssh+machine, kubernetes, docker, parallels, virtualbox, docker-ssh, shell:
明示的に定義していないプロジェクトに使用する画像を尋ねられます。 基本的な安全なデフォルトを選択します。
Please enter the Docker image (e.g. ruby:2.1):
コア要塞ランナーの構成が完了しました! この時点で、トークンを取得するためにアクセスしたGitLab管理者設定のGitLab Runnerページ内に表示されます。
これらの手順で問題が発生した場合、https://docs.gitlab.com/runner/register/index.html [GitLab Runner documentation]にトラブルシューティングのオプションが含まれています。
ステップ6-Docker CachingおよびDocker Machineを構成する
ビルドキューがビジー状態のときにドロップレットの作成を高速化するために、Bastion DropletのDockerのキャッシュツールを活用して、DigitalOcean Spacesでよく使用されるコンテナーの画像を保存します。
これを行うには、次のコマンドを使用してSSHシェルでDocker Machineをアップグレードします。
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がアップグレードされたら、GitLab Runnerが使用するアクセストークンのセットアップに進むことができます。
ステップ7-DigitalOcean資格情報を収集する
ここで、GitLab RunnerがDigitalOceanアカウントを使用して新しいドロップレットを作成するために使用する資格情報を作成する必要があります。
DigitalOcean https://cloud.digitalocean.com [dashboard]にアクセスし、* API をクリックします。 次の画面で、*パーソナルアクセストークン*を探して、 Generate New Token *をクリックします。
新しいトークンに「+ GitLab Runner Access +」などの名前を付け、読み取りと書き込みの両方のスコープが有効になっていることを確認します。人間の介入なしで新しいマシンを作成するにはDropletが必要です。
次の手順で使用するため、安全な場所にトークンをコピーします。 再生成せずにこのトークンを再度取得することはできませんので、安全に保管してください。
ステップ8-GitLab Runner構成ファイルの編集
これらのコンポーネントをすべてまとめるには、要塞ドロップレットの設定を完了して、DigitalOceanアカウントと通信する必要があります。
要塞ドロップレットへのSSH接続で、nanoなどのお気に入りのテキストエディターを使用してGitLab Runner構成ファイルを開いて編集します。
nano /etc/gitlab-runner/config.toml
この構成ファイルは、CIセットアップがオンデマンドでスケールアップおよびスケールダウンするために使用するルールを担当します。 要塞をオンデマンドで自動スケーリングするように設定するには、次の行を追加する必要があります。
/etc/gitlab-runner/config.toml
concurrent = 50 # All registered Runners can run up to 50 concurrent builds
[[runners]]
url = ""
token = "" # 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=", # Access token from Step 7
"digitalocean-region=", # The data center to spawn runners in
"digitalocean-size=", # 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 = ".spaces.digitaloceanspaces.com"
AccessKey = ""
SecretKey = ""
BucketName = ""
Insecure = true # We do not have a SSL certificate, as we are only running locally
新しい行を追加したら、設定に基づいてアクセストークン、リージョン、ドロップレットサイズをカスタマイズします。 このチュートリアルでは、1GBの最小のドロップレットサイズを使用し、NYC3でドロップレットを作成しました。 あなたのケースに関連する情報を使用してください。
また、キャッシュコンポーネントをカスタマイズし、インフラストラクチャ設定ステップからアクセスするスペースのサーバーアドレス、アクセスキー、シークレットキー、作成したスペースの名前を入力する必要があります。
完了したら、GitLab Runnerを再起動して、構成が使用されていることを確認します。
gitlab-runner restart
オフピーク時間など、利用可能なすべてのオプションについて詳しく知りたい場合は、https://docs.gitlab.com/runner/configuration/autoscale.html [GitLabの高度なドキュメント]をご覧ください。
ステップ9-GitLabランナーをテストする
この時点で、GitLab Runner要塞ドロップレットが構成され、CIキューがいっぱいになると、必要に応じてDigitalOceanドロップレットを作成できます。 GitLabインスタンスとステップ1でインポートしたプロジェクトに移動して、動作することを確認するためにテストする必要があります。
ビルドをトリガーするには、 `+ readme.md`ファイルをクリックして編集し、* edit をクリックし、関連するテストテキストをファイルに追加してから、 Commit changes *をクリックします。
これで、左側のナビゲーションのプロジェクトの* CI / CD *オプションにあるビルドが自動的にトリガーされます。
このページには、ステータスが「実行中」のパイプラインエントリが表示されます。 DigitalOceanアカウントには、この変更を作成するためにGitLab Runnerによって自動的に作成されたいくつかのドロップレットが表示されます。
おめでとうございます。 CIパイプラインはクラウドスケーラブルであり、独自のリソース使用量を管理するようになりました。 指定されたアイドル時間が経過すると、マシンは自動的に破棄されますが、予想外の請求が行われないように、これを手動で確認することをお勧めします。
トラブルシューティング
場合によっては、GitLabがランナーに到達できないと報告し、その結果、新しいランナーのデプロイを含むアクションを実行しないことがあります。 これをトラブルシューティングするには、GitLab Runnerを停止してから、デバッグモードで再度起動します。
gitlab-runner stop
gitlab-runner --debug start
出力はエラーをスローするはずです。これは、どの構成が問題の原因であるかを判断するのに役立ちます。
構成で作成されるマシンが多すぎる場合、それらをすべて同時に削除する場合は、次のコマンドを実行してすべてを破棄できます。
docker-machine rm $(docker-machine ls -q)
その他のトラブルシューティング手順と追加の構成オプションについては、https://docs.gitlab.com/runner/ [GitLabのドキュメント]を参照してください。
結論
GitLab RunnerとDockerを使用して、自動化されたCI / CDパイプラインを正常にセットアップしました。 ここから、パフォーマンスを最適化するためにDocker Registryでより高いレベルのキャッシュを構成したり、特定のGitLabコードランナーへのコードビルドのタグ付けの使用を検討したりできます。
GitLab Runnerの詳細、https://docs.gitlab.com/runner/ [詳細なドキュメントを参照]、または詳細については、https://docs.gitlab.com/ee/ci/ [GitLabのシリーズ]を参照してください。継続的な統合パイプラインを最大限に活用する方法についてのブログ投稿]。
_この投稿はhttps://about.gitlab.com/2018/06/19/autoscale-continuous-deployment-gitlab-runner-digital-ocean/[GitLab Blog]にも掲載されています。