TeamCity On-Premises 2026.2 Help

Amazon EC2 向け TeamCity のセットアップ

TeamCity Amazon EC2 統合により、TeamCity は現在のビルドキューのワークロードに応じて、クラウドでホストされるエージェントをオンデマンドで自動的に開始および停止し、ビルドリソースを自動スケーリングできます。

共通情報

TeamCity では、さまざまなタイプの EC2 統合をセットアップできます。 使用する設定とソースに応じて、クラウド AWS ホスト型エージェントは以下で実行できます。

概要イメージ

  • 同じ Amazon マシンイメージ (AMI) から複製された複数の同一のインスタンス。 オンデマンドまたはスポットインスタンスとして起動できます。

  • TeamCity によって管理される単一の永続 EC2 インスタンス。 複数の TeamCity サーバー間で共有できます。

  • AWS からリクエストされたスポットインスタンスのセット (スポットフリート (英語))。

前提条件

このセクションでは、TeamCity UI でクラウドプロファイルを設定する前に AWS アカウントで実行する必要がある手順について説明します。

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

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

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

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

  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 ファイルから次のプロパティを削除します。

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

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

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

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

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

    AMI を作成する

TeamCity での EC2 統合のセットアップ

必要なインスタンスまたは AMI を作成したら、TeamCity UI でクラウドプロファイルを設定できます。

クラウドプロファイルの作成

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

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

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

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

  4. クラウドタイプ を「Amazon EC2」に設定します。

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

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

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

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

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

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

エージェントの終了条件

  1. 作成 または 変更を適用 をクリックしてプロファイルを保存し、プロファイル設定ページを終了します。

クラウドイメージの追加

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

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

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

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

    TeamCity が同一のインスタンスを生成するために使用する AMI を選択します。

    3.1. TeamCity に特定の 起動テンプレートをインポートして使用させる場合は、 起動テンプレートを使用 オプションをオンにします。 テンプレートのデフォルト/最新バージョンがサーバー上で更新されると、TeamCity はこれらの変更を検出し、実行中のインスタンスを更新します。

    3.2. 必要な AMI を選択します。

    • 独自の AMI — TeamCity は、クラウドプロファイル設定で指定された資格情報で利用可能な AMI のコレクションをスキャンします。 見つかったすべての AMI を参照し、必要なイメージを選択できます。

    • ID による AMI — 共有 AMI(英語) を利用できるようにします。

    • タグによる AMI — AWS タグ(英語)のコンマ区切りリスト (例: 所有者=Mike、プロジェクト=Glacier、サブネット=Public) を指定します。 指定されたタグが複数の AMI を指している場合、TeamCity は最後に作成された AMI を使用します。 AMI が見つからなかった場合、 エージェント セクションのイメージ名は「イメージ名 (ami-xxxxxxxxx)」ではなく「イメージ名 (データなし)」になります。

      無効な AMI タグ

    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 インスタンスのネットワーク設定を指定します。

    このオプションを使用すると、特定のインスタンスを TeamCity に追加できます。 TeamCity が複数の同一インスタンスを起動できる AMI と比較すると、このタイプは TeamCity が開始および停止できる静的仮想マシンがあることを意味します。

    3.1. 目的の インスタンスタイプを指定します。 アクティブなインスタンスは 1 つだけなので、選択できるタイプも 1 つだけです。

    3.2.  SSH を使用してEC2 インスタンスに接続する必要がある場合は、 鍵ペア を選択します。

    Amazon スポットフリート(英語)を使用すると、指定された条件に基づいて、通常のインスタンス (オンデマンド) と スポット(英語)インスタンスの組み合わせを予約できます。 サンプルリクエストについては、次の AWS ドキュメント記事を参照してください: スポット Fleet の構成例(英語)。

    3.1.  AWS Management Consoleで、 インスタンス | スポットリクエスト | スポットインスタンスをリクエスト に移動します。

    3.2. 必要な AMI、最小コンピュートユニット、アベイラビリティゾーン、その他のリクエスト詳細を指定します。

    3.3.  JSON 設定 をクリックして、スポットフリート構成パラメーターを含む JSON ファイルをダウンロードします。 Spot Fleet リクエスト構成データ クラスのフィールドのみがサポートされることに注意してください。

    Amazon のスポットフリート設定生成ボタン

    3.4. 生成された JSON 構成ファイルを TeamCity の Spot 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 回スポットインスタンスの起動を再試行します。

クラウドエージェントの管理

ビルドがキューに入れられると、TeamCity はまず通常の (非クラウド) エージェントで、キューに入れられたビルドの実行を試みます。 現在利用可能なものがない場合、TeamCity は互換性のあるクラウドイメージを見つけ、(同時に実行中のインスタンスの制限にまだ達していない場合) 新しいインスタンスを開始します。

エージェント タブからクラウドエージェントを手動で開始および停止できます。 アクティブなクラウドエージェントの数がプロファイルまたはイメージ設定で指定された制限に達すると、 開始 ボタンが無効になることに注意してください。

クラウドエージェントの起動と停止

実行中のインスタンス ブロックには、この特定のイメージから開始されたすべてのエージェントが表示されます。

  • 正常に開始されたものの、まだ TeamCity サーバーに接続していないインスタンスには、名前として AWS インスタンス ID ("i-xxxxxxxxxxxx") が付けられます。

  • 接続され承認されたインスタンスには、親イメージ名と AWS インスタンス ID (「Ubuntu-22.04-Large-i-xxxxxxxxxxxx」) が結合された名前が付けられます。

  • 接続されているエージェントが古いビルドツールを報告すると、アップグレードのために自動的に切断されます。 必要なソフトウェアがすべて更新されると、エージェントはサーバーに再接続します。 TeamCity は、古いエージェントイメージに対応する警告を表示します。

    古いエージェントのイメージ

ターミナルを開く ボタンを使用して、アクティブなエージェントインスタンスへの 対話型ターミナルを開くことができます。 ターミナルを使用すると、クラウドエージェントマシンをデバッグおよび保守できます。

EC2 固有のエージェントパラメーター

AWS ホストエージェントは、これらのマシンに関する EC2 固有の情報を格納するいくつかの システムプロパティを報告し、必要なエージェントを識別できるようにします。 これらのパラメーターの大部分は、標準の AWS イメージメタデータ(英語)の値を返します。

system.ec2.AMI ID｜システム.ec2.AMI ID?? wait no invalid?

エージェントマシンが Amazon Machine Image から起動された場合、このプロパティは対応する AMI ID を返します。

例: ami-08b0a7588100450ff

system.ec2.ami-launch-index

インスタンスが起動された順序を示します。

サンプル: 0

system.ec2.ami-manifest-path

Amazon S3 内の AMI マニフェストファイルへのパス。 Amazon EBS-backed AMI を使用してインスタンスを起動した場合、返される結果は不明です。

サンプル: (不明)

system.ec2.instance-id

このインスタンスの ID。

サンプル: i-07a39ee4b882caa3e

system.ec2.instance-life-cycle

このインスタンスの購入オプション。

サンプル: スポット

system.ec2.instance-type

インスタンスタイプ。

サンプル: t2.2xlarge

system.ec2.local-hostname

エージェントインスタンスの プライベートホスト名。

サンプル: ip-10-128-93-39.eu-west-1.compute.internal

system.ec2.local-ipv4

インスタンスのプライベート IPv4 アドレス。

サンプル: 10.128.93.39

proposed-agent-name

公開エージェント名。通常は クラウドプロファイル名-インスタンス ID 形式です。

サンプル: Win-サーバー-2022-xLarge-i-07a39ee4b882caa3e

system.ec2.public-hostname

インスタンスのパブリック DNS (IPv4)。

サンプル: ec2-54-154-113-80.eu-west-1.compute.amazonaws.com

public-ipv4

パブリック IPv4 アドレス。 Elastic IP アドレスがインスタンスに関連付けられている場合、返される値は Elastic IP アドレスです。

サンプル: 54.154.113.80

system.ec2.reservation-id

予約の ID。

サンプル: r-0461cf168b52cd309

DSL 構成

次の Kotlin スニペットは、ローカルに保存された認証情報を使用し、異なる設定を持つ 3 つのイメージを含むクラウドプロファイルのサンプル DSL 構成を示しています。

import jetbrains.buildServer.configs.kotlin.* import jetbrains.buildServer.configs.kotlin.amazonEC2CloudImage import jetbrains.buildServer.configs.kotlin.amazonEC2CloudProfile // ... version = "%product-version%" project { vcsRoot(MyRoot) buildType(Build) features { // Image 1: On-Demand Instances for a Specific AMI amazonEC2CloudImage { id = "PROJECT_EXT_14" profileId = "amazon-4" name = "Ubuntu-22.04-Large(AMI)" vpcSubnetId = "mySubnet123" iamProfile = "john-doe-ec2-role" keyPairName = "john-doe-u2204-key" instanceType = "t2.large" securityGroups = listOf("security-group-1") instanceTags = mapOf( "LaunchedBy" to "TeamCity" ) maxInstancesCount = 4 source = Source("ami-1234567890") } // Image 2: Spot Instances for an AMI Located by Tags amazonEC2CloudImage { id = "PROJECT_EXT_20" profileId = "amazon-4" name = "Ubuntu-22.04-Medium-Spot(Tags)" vpcSubnetId = "mySubnet123" instanceType = "t3a.medium,t3a.small" securityGroups = listOf("security-group-1,security-group-2") useSpotInstances = true spotInstanceBidPrice = 1.0 instanceTags = mapOf( "LaunchedBy" to "TeamCity" ) maxInstancesCount = 4 source = Source("tags") param("source-tags", "OS=Ubuntu, OSVersion=22.04") } // Image 3: A Single EC2 Instance amazonEC2CloudImage { id = "PROJECT_EXT_22" profileId = "amazon-4" agentPoolId = "-2" name = "Windows-Server2022(Instance)" vpcSubnetId = "mySubnet123" keyPairName = "john-doe-w2022s-keys" instanceType = "m2.xlarge" securityGroups = listOf("security-group-1") source = Source("i-1234567890") } // Parent Profile for All Images amazonEC2CloudProfile { id = "amazon-4" name = "AWS EC2 Profile" description = "A sample Amazon EC2 profile with AMI and Instance images" serverURL = "https://MyTeamCityBuildFarm.dev.gg" terminateIdleMinutes = 30 region = AmazonEC2CloudProfile.Regions.EU_WEST_DUBLIN maxInstancesCount = 20 authType = instanceIAMRole() param("terminate-after-build", "false") param("terminateTimeOut_checkbox", "true") } } } object Build : BuildType({ name = "Build" allowExternalStatus = true vcs { root(MyRoot) } steps { // Build Steps } triggers { vcs {} } features { // Build Features } }) object MyRoot : GitVcsRoot({ name = "https://github.com/...#refs/heads/main" url = "https://github.com/..." branch = "refs/heads/main" branchSpec = "refs/heads/*" authMethod = password { userName = "JohnDoe" password = "..." } param("oauthProviderId", "PROJECT_EXT_8") })

追加セットアップ

必要な 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 ポリシー定義を示しています:

{ "Version": "2012-10-17", "Statement": [ { "Sid": "1", "Action": [ "ec2:Describe*", "ec2:StartInstances", "ec2:StopInstances", "ec2:TerminateInstances", "ec2:RebootInstances", "ec2:RunInstances", "ec2:ModifyInstanceAttribute", "ec2:*Tags", "ec2:RequestSpotInstances", "ec2:CancelSpotInstanceRequests", "ec2:GetSpotPlacementScores", "ec2:RequestSpotFleet", "ec2:DescribeSpotFleetRequests", "ec2:CancelSpotFleetRequests" ], "Effect": "Allow", "Condition": { "IpAddress": { "aws:SourceIp": "<TeamCity server IP address>" } }, "Resource": "*" }, { "Sid": "2", "Action": [ "kms:CreateGrant", "kms:Decrypt", "kms:DescribeKey", "kms:GenerateDataKeyWithoutPlainText", "kms:ReEncrypt*" ], "Effect": "Allow", "Condition": { "IpAddress": { "aws:SourceIp": "<TeamCity server IP address>" } }, "Resource": "*" }, { "Sid": "3", "Action": [ "iam:CreateServiceLinkedRole", "iam:ListInstanceProfiles", "iam:PassRole" ], "Effect": "Allow", "Condition": { "IpAddress": { "aws:SourceIp": "<TeamCity server IP address>" } }, "Resource": "*" } ] }

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

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

Windows で TeamCity エージェントと EC2 API の適切な通信 (追加ドライブへのアクセスを含む) を確保するには 、TeamCity Build Agent サービスから AmazonSSMAgent または EC2Launch/EC2Config サービス (AWS インフラストラクチャの使用に関してマシンが完全に初期化されるようにするサービス) への依存関係を追加します。 これは、たとえば レジストリ経由または sc config を使用して実行できます (例: sc config TCBuildAgent depend=EC2Config)。
または、"Automatic (delayed start)" サービス開始モードを使用できます。

Amazon EBS 最適化インスタンス

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

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

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

タグ付け

TeamCity によって起動されたインスタンスのタグ付け

TeamCity によって起動されたインスタンスにタグを付けるには、次の要件を満たす必要があります:

タグ付け権限がなくても、TeamCity はタグが適用されていない Amazon AMI および EBS イメージを起動できますが、Amazon EC2 スポットインスタンスを起動できません

TeamCity では、作成されたインスタンスを <サーバー UUID>:-<クラウドプロファイル ID>:-<イメージ参照> を含む teamcity:TeamcityData タグでマークすることで、インスタンスの起動情報を取得できます。 TeamCity と EC2 の連携にはこのタグが必要であり、削除しないでください。

EC2 クラウドエージェントインスタンスにはカスタムタグを適用できます。クラウドプロファイル設定を構成する際、 画像を追加/画像を編集 ダイアログで インスタンスのタグ: フィールドを使用して、 <鍵1>=<値1>、<鍵2>=<値2> 形式でタグを指定します。 Amazon タグ制限を考慮する必要があります。

タグ値に等号（=）を使用する場合、エスケープする必要はありません。 たとえば、文字列 extraParam=お名前=John は <鍵=extraParam> と値 <お名前=John>。 に解析されます

インスタンス依存リソースのタグ付け

Amazon EC2 インスタンスを起動するとき、TeamCity は作成されたインスタンスに関連付けられたすべてのリソース (たとえば、ボリュームやネットワークアダプター) にタグを付けます。これは、インスタンスの全体的なコストを評価する際に重要です (ストレージドライブの種類とサイズ、I/O 操作 (標準ドライブの場合)、ネットワーク (送信転送) などを考慮します。

複数の TeamCity サーバー間で EBS インスタンスを共有する

前述のように、TeamCity は起動するすべてのインスタンスに、サーバー、クラウドプロファイル、ソース (AMI または EBS インスタンス) に関する情報を保存する teamcity:TeamcityData タグを付けます。 そのため、複数の TeamCity サーバーが同じ EBS インスタンスを使用しようとすると、2 番目のサーバーには次のメッセージ "Instance is used by another TeamCity server. 起動 / 停止できません」というメッセージが表示されます。 このインスタンスで動作している他の TeamCity サーバーがないことが確実な場合は、 teamcity:TeamcityData タグを削除すると、インスタンスはすべての TeamCity サーバーで再び利用できるようになります。

プロキシ設定

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 認証用のプロキシアクセスワークステーション

EC2 コストの見積もり

標準の Amazon EC2 料金が適用されます。 Amazon の料金は、TeamCity をデプロイするために実装された特定の構成によって異なる場合があります。 予期せぬ出費をできるだけ早く発見して防ぐために、構成と Amazon アカウントデータを定期的に確認することをお勧めします。

トラフィック量と必要なサーバーおよびエージェントマシンの特性は、TeamCity のセットアップと実行されるビルドの性質に大きく依存することに注意してください。 TeamCity のハードウェア要件の見積もりも参照してください。

トラフィックの見積もり

TeamCity 関連のトラフィックを見積もる際に役立つポイントをいくつか示します：

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

  • トラフィックを見積もる際は、TeamCity に関連するトラフィックには多くの種類があることに留意してください (以下の不完全なリストを参照)。

サーバーから発信された外部接続 は:

  • VCS サーバー

  • E メールサーバー

  • Maven リポジトリ

サーバーから発信された内部接続 は:

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

エージェントから発信された外部接続 は:

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

  • Maven リポジトリ

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

エージェントから発信された内部接続 は:

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

サーバーが処理する通常の接続 は:

  • ウェブブラウザー

  • IDE プラグイン

稼働時間のコスト

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

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

2026 年 9 月 11 日
クラウドでビルドエージェントをホストするKubernetes 向け TeamCity のセットアップ