VM サービス

このセクションでは、CircleCI Server の VM サービスをセットアップしてカスタマイズする方法について説明します。 VM サービスでは、machine Executor (Linux および Windows イメージ) とリモート Docker ジョブの実行方法を制御できます。

このページの情報は、AWS 上の CircleCI Server のみに適用されます。 静的インストール向けの VM サービスのセットアップ手順などについては、CircleCI のアカウント担当者に問い合わせてください。

概要

AWS にインストールされた CircleCI Server では、VM サービスを介して、https://circleci.com/docs/ja/2.0/building-docker-images[リモート Docker 環境]と machine Executor を使用してジョブを実行できます。

Configuring VM Service on CircleCI Server
Figure 1. VM サービスの設定
管理コンソール設定に変更を加えると、CircleCI アプリケーションが再起動し、ダウンタイムが生じます。

以下のセクションでは、上記に示した VM サービスのスクリーンショットに表示される設定とオプションについてひととおり説明します。

VM サービスを設定する場合、管理コンソールの設定で [AWS EC2] オプションを選択することをお勧めします。 これで、CircleCI が専用の EC2 インスタンスを使用して、リモート Docker および machine Executor ジョブを実行できるようになります。

1. AMI の指定

以下のセクションで説明するように、VM サービス用にカスタムの Amazon マシン イメージ (AMI) を指定できます。 カスタム イメージを指定しない場合、すべての machine Executor とリモート Docker ジョブは、CircleCI のデフォルトの AMI (下記参照) のいずれかで構築されたインスタンスで実行されます。このデフォルトの AMI は、Ubuntu 16.04、Docker バージョン 18.06.3 を使用し、一般的な言語、ツール、フレームワークのセットがインストールされています。 詳細については、https://github.com/circleci/image-builder/tree/picard-vm-image/circleci-provision-scripts[image-builder リポジトリの picard-vm-image ブランチ]を参照してください。 Windows ジョブを実行するには、Windows AMI を指定する必要があります。これを指定しないと、Windows ジョブの実行は失敗します。

デフォルトの VM サービス用 Linux AMI

  • Ap-northeast-1:ami-0e49af0659db9fc5d

  • Ap-northeast-2:ami-03e485694bc2da249

  • Ap-south-1:ami-050370e57dfc6574a

  • Ap-southeast-1:ami-0a75ff7b28897268c

  • Ap-southeast-2:ami-072b1b45245549586

  • Ca-central-1:ami-0e44086f0f518ad2d

  • Eu-central-1:ami-09cbcfe446101b4ea

  • Eu-west-1:ami-0d1cbc2cc3075510a

  • Eu-west-2:ami-0bd22dcdc30fa260b

  • Sa-east-1:ami-038596d5a4fc9893b

  • Us-east-1:ami-0843ca047684abe87

  • Us-east-2:ami-03d60a35576647f63

  • Us-west-1:ami-06f6efb13d9ccf93d

  • Us-west-2:ami-0b5b8ad02f405a909

VM サービス イメージの作成とカスタマイズ

お使いの CircleCI 環境に合わせて VM サービス イメージをカスタマイズすることで、Docker や Docker Compose のバージョンを指定したり、CI/CD パイプラインに依存関係を追加インストールしたりすることができます。 リモート Docker や machine Executor を使用するジョブの個別の AMI を作成したり、machine 向けに Linux と Windows の個別の AMI を指定したりできます。 ベース Linux イメージをカスタマイズしない場合、こうした追加インストールや更新のステップをコミットのたびに実行するように、config.yml ファイルのジョブを構成する必要があります。

*CircleCI Server v2.18 以降*では、以下の画像で "1" とマークされているフィールドを使用することで、1 つのカスタム Linux AMI を machine ジョブとリモート Docker ジョブの両方に指定できるようになりました。また、"2" とマークされているフィールドにもう 1 つのカスタム AMI を指定することで、それぞれのジョブに異なる設定を使用することもできます。

Custom VM Service Images
Figure 2. カスタム VM サービス イメージ

カスタム Linux AMI

前提条件

カスタム Linux AMI の作成

  1. https://github.com/circleci/image-builder/tree/picard-vm-imageをクローンします。

  2. エディターで aws-vm.json を開きます。 このファイルは、Packer で AMI を作成するための基本テンプレートです。 AWS アクセス キー ID とシークレット アクセス キーをアップロードする必要があります。 Packer での AWS 認証の管理に関する詳細は、https://packer.io/docs/builders/amazon.html#authentication[こちら]を参照してください。 基本テンプレートでは足りない場合は、https://packer.io/docs/builders/amazon.html[こちら]にある追加の AWS 構成オプションを参照してください。

  3. (オプション) ami_groups は組織内のみに制限することをお勧めします。 AMI グループの詳細については、https://packer.io/docs/builders/amazon-ebs.html#ami_groupsを参照してください。

  4. https://github.com/circleci/image-builder/blob/picard-vm-image/provision.sh には、構成済みの依存関係リストが提供されています。 お使いの環境のニーズに合わせて、この provision.sh スクリプトをカスタマイズします。

  5. packer build aws-vm.json を実行します。

AMI を作成したら、AMI ID を上記スクリーンショットの該当するフィールドにコピーします。

Windows AMI の作成

CircleCI Server v2. 18.3 からサポート

Windows イメージを作成して VM サービスの設定で指定すると、専用の Windows VM でユーザーがジョブを実行できるようになります。 To create your Windows image run through the steps listed in our image builder repo, then copy the generated AMI ID and paste into the Custom Windows VM AMI field in your Management Console settings, under VM Provider (for example, <your-hostname.com:8800/settings>).

Windows イメージは CircleCI Server 上で構築されるため、このプロセスは CircleCI Server が起動してから行うことをお勧めします。 または、別の CircleCI アカウント (クラウド版 CircleCI を含む) を使用してイメージを作成します。

2. インスタンス タイプの定義

使用する AWS インスタンス タイプを定義するためのフィールドは 2 つあります。 1 つ目にはデフォルトのインスタンス タイプを指定します。2 つ目には、ジョブで large リソース クラスを指定しているときに使用するインスタンス タイプを設定します。

3. オンデマンド インスタンスと事前割り当てインスタンス

リモート Docker インスタンスと machine Executor インスタンスは、オンデマンドでスピンアップされます。 リモート Docker および machine ジョブの実行に備えて、インスタンスを事前に割り当てて稼動させておくこともできます (図 1 の最後 2 つのフィールドを参照)。

Docker レイヤー キャッシュ (DLC) を使用する場合、VM サービス インスタンスをオンデマンドでスピンアップする必要があります。 これを確実に実現する方法は 2 つあります。1 つは、事前割り当てインスタンスを使用中にすること、もう 1 つは、リモート Docker と machine 用の事前割り当てインスタンスのフィールドの両方を 0 に設定することです。
事前割り当てインスタンスを使用する場合、インスタンスが動作不可能状態にならないように、それらのインスタンスを 1 日に 1 回切り替えるように cron ジョブがスケジュールされていることに注意してください。

ジョブとインスタンスの管理

リモート Docker 環境または machine Executor を使用して実行するジョブは、Nomad サーバーから Nomad クライアントにスケジュールに沿ってディスパッチされ、そこからリモート Docker または machine に渡されます。 つまり、リモート Docker および machine Executor で実行されるジョブは、通常どおり Nomad CLI を使用して監視できます。 See our Introduction to Nomad Cluster Operation for more about Nomad commands and terminology.

すべてのデフォルト インスタンスと事前割り当てインスタンスが動作不可能状態にならないよう、それらを少なくとも 1 日 1 回切り替えるように cron ジョブがスケジュールされています。

リモート Docker インスタンスおよび machine インスタンスへのアクセス

デフォルトでは、VM サービス インスタンスとの通信にはプライベート IP アドレスが使用されます。 開発者に SSH でのアクセスを許可するなど、より広いアクセス権を付与する必要がある場合は、VM プロバイダーの [Show Advanced Settings (高度な設定を表示)] チェックボックスを使用して設定できます。

VM Provider Advanced Settings
Figure 3. VM サービス インスタンスへのアクセス許可


Help make this document better

This guide, as well as the rest of our docs, are open-source and available on GitHub. We welcome your contributions.