Amazon EC2 用の TeamCity のセットアップ

EC2 インスタンスの作成とセットアップ

1. Amazon EC2 コンソール(英語)を開きます。

2. 必要なインスタンスを作成します。詳細については、Amazon チュートリアル（Linux(英語)、Windows(英語)、macOS）(英語)を参照してください。

3. インスタンスにエージェントをインストールします。OS の種類によって必要な手順が異なる場合があります。詳細については、次の記事を参照してください。

   • TeamCity エージェントをインストールする

   • エージェントのインストールを構成する

4. ビルドステップと TeamCity エージェント自体の実行に必要な追加ソフトウェア (JDK と JRE、SDK、ランタイムフレームワーク、Git や Docker などの構築ツールなど) をインストールします。

5. エージェントを実行し、TeamCity サーバーに正常に接続し、必要なすべての構成と互換性があることを確認します。

6. インスタンスの起動時に TeamCity エージェントを自動的に実行するようにシステムを構成します。

7. Windows インスタンスの場合は、次の手順に従います: Windows エージェントの追加構成。

8. インスタンスを再起動して、ビルドエージェントが自動的に起動し、サーバーに接続できることを確認します。

AMI を作成する

前の手順で作成したインスタンスを TeamCity サーバーに直接接続し、スタンドアロンエージェントマシンとして機能させる場合は、このセクションをスキップしてください。それ以外の場合、TeamCity で現在のワークロードに基づいてアクティブなクラウドエージェントの数を自動的にスケーリングする場合は、このインスタンスから AMI を作成します。

1. ビルドエージェントを停止します。Windows インスタンスの場合は、エージェントサービスを停止しますが、スタートアップタイプは自動のままにします。

2. インストールウィザード、ダウンロードしたアーカイブ、ビルドログなどの一時データと余分なデータをすべてインスタンスから削除します。

3. オプション: <agent_home>/logs ディレクトリと <agent_home>/temp ディレクトリを削除します。

4. オプション: <agent_home>/conf/amazon-* ファイルを削除します。

5. <agent_home>/conf/buildAgent.properties ファイルから次のプロパティを削除します。

   • name — TeamCity はインスタンスに一意の名前を自動的に割り当てます。

   • serverUrl — EC2 統合プラグインの場合、クラウドプロファイルを設定するときにすべてのインスタンスにサーバー URL を指定するため、このプロパティは削除しても安全です。他のプラグインでは、このプロパティが存在し、正しい値に設定されている必要がある場合があります。

   • (オプション) authorizationToken — 新しいクラウドエージェントは自動的に承認されます。

6. インスタンスを停止します。

7. インスタンスの概要ページで、アクション | イメージとテンプレート | イメージの作成をクリックします。

   

クラウドプロファイルを作成する

クラウドプロファイルは、TeamCity が仮想マシンを起動するための一般的な設定のコレクションです。

1. 必要なプロジェクトに移動します。このプロファイルのクラウドエージェントをグローバルに使用できるようにするには、ルートプロジェクトを選択します。個々のプロジェクトが所有するプロファイルを使用して、これらのプロジェクトでのみ使用できるエージェントを生成できます。

2. プロジェクト設定を開き、クラウドプロファイル設定タブに移動します。

3. 新規プロファイルの作成をクリックします。

4. クラウドの種類を「Amazon EC2」に設定します。

5. プロファイル名とオプションの説明を入力します。

6. AWS ベースのイメージとインスタンスにアクセスするために使用する AWS 接続を選択します。「IAM ロール」タイプの AWS 接続が動作するには、アクセスキーまたはデフォルトの認証情報プロバイダーチェーンタイプのいずれかの基盤となる接続が必要であることに注意してください。

7. インスタンスがホストされている AWS リージョンを選択します。

8. オプション: エージェントの制限を設定します。この数値は、このプロファイルのすべてのクラウドイメージから作成されるエージェントの全体的な制限を指定します。

9. オプション: TeamCity サーバーの URL を指定します。この値はエージェントの buildAgent.properties ファイルに自動的に渡されます。指定されていない場合、エージェントは管理 | グローバル設定ページと同じ値を使用します。

10. アクティブなクラウドエージェントを終了するための一連の基準を指定します。エージェントがアイドル状態を維持できる時間、および実際のビルドルーチンを実行できる時間を選択できます。いずれかの条件が満たされた場合、エージェントは現在のビルドを完了した後にのみ終了します。

クラウドイメージを追加する

クラウドプロファイルは、認証資格情報やインスタンスリージョンなどのグローバル設定を指定します。各プロファイルには、起動する必要がある特定のタイプのクラウドインスタンスに関連する設定を保存する 1 つまたは複数のイメージを含めることができます。必要に応じて、プロファイルにイメージをいくつでも追加できます。ただし、すべてのイメージによって起動されるエージェントの合計数は、プロファイル設定で設定された制限 (およびライセンスで許可されているエージェントの数) を超えることはできません。

1. イメージの追加ボタンをクリックしてください。

2. オプションのイメージ名を指定します。

3. 必要なイメージタイプを選択します。

   TeamCity が同一のインスタンスを生成するために使用する AMI を選択します。 3.1. TeamCity で特定の起動テンプレート(英語)をインポートして使用する場合、起動テンプレートを使用するオプションをオンにします。サーバー上でテンプレートのデフォルト / 最新バージョンが更新されると、TeamCity はこれらの変更を検出し、実行中のインスタンスを更新します。 3.2. 必要な AMI を選択します。 独自の AMI — TeamCity は、クラウドプロファイル設定で指定された認証情報で使用可能な AMI のコレクションをスキャンします。見つかったすべての AMI を参照し、必要なイメージを選択できます。 ID による AMI — 共有 AMI(英語) を利用できるようにします。 タグ別 AMI — AWS タグ(英語)のコンマ区切りリスト (例: Owner=Mike,Project=Glacier,Subnet=Public) を指定します。指定されたタグが複数の AMI を指している場合、TeamCity は最後に作成された AMI を使用します。AMI が見つからなかった場合、エージェントセクションのイメージ名は「イメージ名 (ami-xxxxxxxxx)」ではなく「イメージ名 (データなし)」になります。 3.3. 1 つまたは複数のインスタンスタイプ(英語)を指定します。 オンデマンドまたはこの特定のタイプのスポットインスタンスのみを起動する必要がある場合は、タイプを 1 つ指定します (たとえば、t2.medium)。異なるインスタンスタイプ値を持つ同じ AMI をターゲットとする複数のイメージを追加できます。これにより、タイプごとに異なるアクティブインスタンス制限を設定し、特定のタイプのインスタンスを手動で開始できます。 スポットインスタンスを並べ替える場合は、複数のタイプ ( t2.small、t2.medium、t2.large など) を設定します。このアプローチにより、スポットインスタンスが割り当てられる可能性が高まります。 3.4. オプション: 追加のイメージ設定を指定します。 IAM ロール — 起動されたすべてのインスタンスが引き受ける IAM ロール。このロールは、EC2 インスタンスで実行されているアプリケーションに付与される(英語)アクセス許可を指定します。TeamCity で使用される AWS アカウントには、IAM ロールを利用するための iam:ListInstanceProfiles および iam:PassRole 権限が必要です。 キーペア — SSH を使用して (英語)EC2 インスタンスに接続する必要がある場合は必須です。 ユーザーデータ — インスタンスの起動時に実行されるスクリプトを指定できます。詳細: Windows(英語)、Linux(英語)。 タグ — コンマで区切られたインスタンスタグのリスト。たとえば、LaunchedBy=TeamCity,TeamCityCloudProfileName=MyProfile1 タグ付けには ec2:*Tags 権限が必要です。詳細については、次のセクションを参照してください: タグ付け。 3.5. オンデマンドインスタンスよりも安価なスポットインスタンス(英語)を希望する場合は、スポットインスタンスを使用するをチェックしてください。最高負荷格フィールドでは、スポットインスタンスの最大入札価格 (ドル) を指定できます。入札価格が指定されていない場合は、デフォルトのオンデマンド価格が使用されます。 TeamCity は、スポット配置スコア(英語)に基づいて、スポットリクエストが成功する可能性が最も高いリージョンまたはアベイラビリティゾーンを自動的に選択できます。TeamCity がこれらのスコアを要求して利用できるようにするには、ec2:GetSpotPlacementScores IAM 権限を追加します。 3.6. EC2 インスタンスのネットワーク設定を指定します。 VPC — 新しいインスタンスが属する仮想プライベートクラウド(英語)。 サブネット — VPS 用の IP アドレスの範囲(英語)。 セキュリティグループ — EC2 インスタンスへの (からの) 受信接続および送信接続のルール(英語)を指定します。 このオプションを使用すると、特定のインスタンスを TeamCity に追加できます。TeamCity が複数の同一インスタンスを起動できる AMI と比較して、このタイプは、TeamCity が起動および停止できる静的仮想マシンがあることを意味します。 3.1. 希望するインスタンスタイプ(英語)を指定します。アクティブなインスタンスは 1 つだけなので、選択できるタイプは 1 つだけです。 3.2. SSH を使用して (英語)EC2 インスタンスに接続する必要がある場合は、キーペアを選択してください。 Amazon スポットフリート(英語)を使用すると、指定された条件に基づいて、通常のインスタンス (オンデマンド) とスポット(英語)インスタンスの組み合わせを予約できます。サンプルリクエストについては、次の AWS ドキュメント記事を参照してください: スポット Fleet の構成例(英語)。 3.1. AWS マネジメントコンソール(英語)で、インスタンス数 | スポットリクエスト | スポットインスタンスのリクエストに移動します。 3.2. 必要な AMI、最小計算単位、アベイラビリティーゾーン、その他のリクエストの詳細を指定します。 3.3. JSON 構成をクリックして、スポットフリート構成パラメーターを含む JSON ファイルをダウンロードします。 SpotFleetRequestConfigData (英語) クラスのフィールドのみがサポートされていることに注意してください。 3.4. 生成された JSON 構成ファイルを TeamCity のスポット Fleet リクエストフィールドに貼り付けます。 TeamCity は、イメージを実行するために、スポットフリート構成で指定された割り当て戦略に一致するスポットインスタンスを起動します。

4. イメージの優先順位フィールドに -10000 から 10000 の範囲の整数を入力します (デフォルトの優先順位は 0)。TeamCity は、新しいクラウドエージェントを起動する必要がある場合、最も高い優先度の値を持つイメージを選択します。

   TeamCity は、優先度の値を使用して、既存のすべてのプロファイルからイメージを範囲指定します。例: 新しくキューに入れられたビルドは、プロファイル A および B から生成されたクラウドエージェント上で実行できます。プロファイル A には、優先順位 20, 40,, 60 を持つ 3 つのイメージがあります。プロファイル B には 10, 30,, 50 優先イメージが含まれています。TeamCity は次の順序で新しいエージェントを起動します。

   • プロファイル A、イメージ優先度 60。

   • プロファイル B、イメージ優先度 50。

   • プロファイル A、イメージ優先度 40 など。

   優先度の低いイメージは、利用可能な優先度の高いイメージがアクティブなエージェントの制限に達した場合にのみ使用されます。

5. このイメージから開始して、アクティブなクラウドエージェントの最大数を設定します。プロファイルに追加されたすべてのイメージから起動されるエージェントの総数は、このプロファイルの設定ページで設定された制限を超えることができないことに注意してください。

6. 新しく作成したインスタンスが属するエージェントプールを指定します。

7. 保存をクリックしてイメージ設定ページを終了します。

イメージを構成した後、TeamCity はこのイメージに対して 1 つのテストエージェントを作成し、起動してサーバーに接続できるかどうかをテストします。エージェントが接続されて認証されると、TeamCity はそのパラメーターを保存して、互換性のあるエージェントにビルドを正しく割り当てます。

イメージのスポットインスタンスを使用する設定がチェックされていて、現時点でテストインスタンスを起動できない場合 (たとえば、利用可能な容量がない場合、入札価格が低すぎる場合)、TeamCity はスポットインスタンスの起動を 1 分に 1 回繰り返し試行します。このエージェント上で実行できるキューに入れられたビルドが存在する限り。

必要な IAM アクセス許可

TeamCity では、Amazon EC2 リソースに対して次の権限が必要です。

• ec2:Describe*

• ec2:StartInstances

• ec2:StopInstances

• ec2:TerminateInstances

• ec2:RebootInstances

• ec2:RunInstances

• ec2:ModifyInstanceAttribute

• ec2:*Tags

スポットインスタンスを使用するには、上記の権限に加えて次の権限を付与します。

• ec2:RequestSpotInstances

• ec2:CancelSpotInstanceRequests

• ec2:GetSpotPlacementScores (オプション。TeamCity がスポット配置スコア(英語)に基づいて AWS リージョンまたはアベイラビリティーゾーンを選択できるようにします)。

スポットフリートを使用するには、次の追加の権限が必要です。

• ec2:RequestSpotFleet

• ec2:DescribeSpotFleetRequests

• ec2:CancelSpotFleetRequests

• iam:CreateServiceLinkedRole (「提供された認証情報には、EC2 スポット Fleet のサービスにリンクされたロールを作成する権限がありません」エラーが発生した場合、サービスロールが作成されたらこの権限を安全に取り消すことができます。)

想定された IAM ロール (AMI および起動テンプレートから複製されたインスタンスに適用) でインスタンスを起動するには、次の追加の権限が必要です。

• iam:ListInstanceProfiles

• iam:PassRole

暗号化された EBS ボリューム(英語)を使用するには、次の追加のアクセス許可が必要です。

• kms:CreateGrant

• kms:Decrypt

• kms:DescribeKey

• kms:GenerateDataKeyWithoutPlainText

• kms:ReEncrypt*

以下のスニペットは、特定の IP アドレスから TeamCity によって開始されるすべての EC2 オペレーションを許可するカスタム IAM ポリシー定義を示しています。

ポリシーの例 (Linux)(英語)、ポリシーの例 (Windows)(英語) も参照してください。

Windows エージェントの追加構成

Windows で TeamCity エージェントと EC2 API（追加ドライブへのアクセスを含む）との適切な通信を確保するには、TeamCity ビルドエージェントサービスから AmazonSSMAgent(英語) または EC2Launch/EC2Config(英語) サービス (AWS インフラストラクチャの使用に関してマシンが完全に初期化されていることを保証するサービス) への依存関係を追加します。これは、たとえば、レジストリ(英語)経由または sc config(英語) (たとえば、sc config TCBuildAgent depend=EC2Config) を使用して実行できます。
あるいは、「自動（遅延開始）」サービス開始モードを使用することもできます。

Amazon EBS 最適化インスタンス

TeamCity における EBS 最適化(英語)の動作は、EC2 コンソールで提供される動作と似ています。Amazon クラウドプロファイルのイメージを構成するときに、インスタンスタイプの対応するボックスを使用して最適化を設定できます。次の点に注意してください。

• EBS 最適化は、c4.*、d2.*、m4.* ではデフォルトでオンになります (構成不可)。

• EBS 最適化は、他のインスタンスタイプではデフォルトでオフになっていますが、それをサポートするインスタンス ( c3.xlarge など) ではオンにすることができます。

タグ付け

プロキシ設定

TeamCity サーバーがプロキシを使用して AWS API エンドポイントに接続する必要がある場合は、次のサーバー内部プロパティを設定して Amazon AWS アドレスに接続します。

• teamcity.http.proxy.host.ec2 — プロキシサーバーのホスト名

• teamcity.http.proxy.port.ec2 — プロキシサーバーポート

プロキシサーバー認証の場合:

• teamcity.http.proxy.user.ec2 — プロキシアクセスユーザー名

• teamcity.http.proxy.password.ec2 — プロキシアクセスユーザーパスワード

NTLM 認証の場合:

• teamcity.http.proxy.domain.ec2 — NTLM 認証用のプロキシユーザードメイン

• teamcity.http.proxy.workstation.ec2 — NTLM 認証用のプロキシアクセスワークステーション

トラフィックの見積もり

TeamCity 関連のトラフィックを推定するのに役立ついくつかのポイントがあります。

• TeamCity サーバーが、エージェントの TeamCity EC2 設定で構成された同じ EC2 リージョンまたはアベイラビリティーゾーン内にない場合、サーバーとエージェント間のトラフィックは、通常の Amazon EC2 外部トラフィック料金の対象となります。

• トラフィックを推定する場合、TeamCity に関連するトラフィックには多くのタイプがあることに留意してください（以下の完全でないリストを参照してください）。

サーバーによって開始された外部接続 :

• VCS サーバー

• E メールサーバー

• Maven リポジトリ

サーバーによって開始された内部接続 :

• TeamCity エージェント (ステータスの確認、コマンドの送信、スレッドダンプなどの情報の取得など)

エージェントによって開始された外部接続 :

• VCS サーバー (エージェント側のチェックアウトの場合)

• Maven リポジトリ

• ビルドプロセス自体から実行される接続

エージェントによって開始された内部接続 :

• TeamCity サーバー (サーバー側のチェックアウトまたは個人用ビルドの場合はビルドソースを取得する、アーティファクトをダウンロードするなど)

サーバーによって提供される通常の接続 :

• ウェブブラウザー

• IDE プラグイン

稼働時間コスト

一部の構成では Amazon がマシンの稼働時間を 1 時間に丸めるため（Amazon EC2 インスタンス時間はどのように請求されますか？ (英語) でさらに）、通常のビルドの長さに応じて、TeamCity クラウド統合設定の EC2 イメージ設定のタイムアウト設定を調整します。

また、すべてのビルドの実行タイムアウトを設定して、ビルドがハングしてもペイロードなしで長時間インスタンスが実行されないようにすることを強くお勧めします。