TeamCity とコンテナーマネージャーの統合
TeamCity は、コンテナーマネージャー (Docker、Podman) と複数のレベルで統合されます。
Docker ビルドランナーはビルド中に Docker コマンドを起動し、Docker イメージを作成します。
Docker Compose ビルドランナーは、ビルド中に Docker Compose ツール(英語)を使用してサービスを開始します。
コンテナーラッパー 拡張機能は、コンテナー内でビルドステップを実行します。Docker と Podman をサポートします。複数のランナーで使用できます。
Docker で実行ビルド機能を使用すると、すべてのビルドステップを同じコンテナー内でまとめて実行できます。
Docker レジストリ接続 ビルド機能は、ビルドを開始する前に、Docker または Podman を使用してコンテナーレジストリに自動的にサインインします。この機能は、ビルド中にレジストリに公開されたイメージに関する情報を含むビルド結果のコンテナー情報タブも追加します。
リストされているツールの詳細については、上記のリンク先にある専用のヘルプ記事を参照してください。次の記事には、これらのツールに共通する情報が含まれています。
互換性と要件
環境要件
Docker または Podman 関連の操作を実行するには、ビルドエージェントが docker または podman 実行可能ファイルを使用できる必要があります。
Docker は、Linux、Windows、macOS ビルドエージェントにインストールできます。
Linux では、インストールされている Docker が検出されると、Docker レジストリ接続統合が実行されます。
Windows では、統合は Linux および Windows コンテナーモードで機能します。
macOS では、ビルドエージェントを実行しているユーザー用に公式の Mac の Docker サポート(英語)をインストールする必要があります。
Podman は、主に Linux 向けに設計されたツールです。Windows および macOS で実行するには、Podman に Linux 仮想マシン (「Podman マシン」) がインストールされている必要があります。さまざまなオペレーティングシステムに Podman をインストールする方法の詳細については、次の記事を参照してください: ポッドマンのインストール手順(英語)。
ビルドエージェントコンピューター上の
registries.confファイルでコンテナーレジストリドメインを指定します。例:unqualified-search-registries = ["docker.io"]Podman と TeamCity では、次の目的でこのレジストリのリストが必要です。podman ...コマンドで短いイメージ名 (たとえば、podman pull registry.access.redhat.com/ubi8:latestではなくpodman pull ubi8) が使用される場合、完全なコンテナーアドレスを解決します。ビルド構成に Docker レジストリ接続ビルド機能がある場合は、レジストリに正常にログインします。
registries.confファイルの詳細については、次の記事を参照してください: Linux コンテナーレジストリを管理する方法(英語)。systemd 経由で自動的に起動するように構成された Linux ビルドエージェントを実行している場合は、ユーザーセッションを実行し続けるためにユーザーの残留(英語)を有効にします:
loginctl enable-linger my_agent_user
ツール
エージェントマシンに Docker(英語) または Podman(英語) をインストールします。Windows および macOS エージェントの場合は、さらにポッドマンマシン(英語)が必要です。
Docker Compose ビルドランナーを使用するには、Docker Compose(英語) もインストールする必要があります。
ビルドパラメーターとエージェント要件
TeamCity は、次のパラメーターをチェックして、利用可能なエージェントソフトウェアを識別します。
container.engine— エージェントマシンにインストールされているコンテナーマネージャーに応じて、「docker」、「podman」、「docker,podman」を返します。Docker と Podman の両方がインストールされている場合、TeamCity はデフォルトで Docker を使用します。teamcity.default. с ontainer.engine— このプロパティをdockerまたはpodmanに設定すると、常に希望のツールが使用されます。このプロパティを使用すると、両方のツールが利用可能な場合に TeamCity が Docker を使用するように強制するデフォルトのロジックをオーバーライドできます。このプロパティは、構成パラメーターとして、または個々のエージェントの設定（buildAgent.properties ファイル内）として設定できます。docker.server.version、docker.version— インストールされている Docker エンジン(英語)および Docker CLI(英語) のバージョンをそれぞれ返します。podman.version— インストールされている Podman ソフトウェアのバージョンを保存します。docker.server.osType、podman.osType— エージェント OS のタイプを返します。サポートされる値は、「linux」(Linux エージェントと macOS エージェントの両方) と「windows」です。dockerCompose.version— Docker Compose ビルドステップが使用されている場合は、Docker Compose ファイルバージョンを返します。
使用する Docker/Podman 統合に応じて、TeamCity は異なるエージェント互換性要件を指定します。たとえば、ビルド構成で Docker ランナーを使用する場合、この構成は docker.server.version exists 要件を満たすエージェントでのみ実行できます。
Docker ディスクスペースクリーナー
Docker ディスクスペースクリーナーは、空きディスク容量ビルド機能の拡張機能であり、ビルドに必要な量のディスクスペースを確保します。
TeamCity は、タグ付け / プルされた関連 Docker イメージを定期的にクリーンアップします。
Docker レジストリ接続ビルド機能を使用したビルド、または
Docker または Docker Compose ビルドステップで、または
コンテナーラッパー拡張機能が有効になっているビルドステップ。
そのようなビルドの場合
TeamCity エージェントは、ビルド中にタグ付けまたはプルされた Docker イメージを追跡します（イメージのリストは
buildAgent/system/docker-used-images.datファイルに保存されます）。クリーンアップ / ディスク領域の解放中に、TeamCity エージェントは、これらのイメージが 3 日以内（またはその後のディスク領域の解放の試行で 1 日または 0 日）に使用されなかった場合、これらのイメージを削除しようとします。
さらに、TeamCity は docker/podman system prune --volumes コマンドを使用してローカルキャッシュを消去します。Docker インストールの場合、このクリーンアップは v.17.06.1 以降で機能します。
プッシュされたイメージを報告するためのサービスメッセージ
何らかの理由で、TeamCity がイメージがプッシュされたことを判断できない場合、ユーザーは特別なサービスメッセージを送信して、この情報を TeamCity サーバーに報告できます。
例:
Docker のダウンロードレート制限に準拠
2020 年 11 月 1 日以降、Docker Hub では、パブリックイメージプルのダウンロードレート制限(英語)が導入されています。
TeamCity ビルドでコンテナーラッパーまたは Docker Compose を使用して Docker Hub からイメージをプルする場合は、これらのプルが次の制限を超えないようにしてください。
匿名の Docker ユーザー: 6 時間あたり 100 プル
無料プランの Docker ユーザー: 6 時間あたり 200 プル
Team または Pro Docker アカウントをお持ちの場合、プルの数は無制限のままです。
通常の TeamCity エージェントは、一度プルしたイメージをキャッシュに保存します。これにより、同じプルしたイメージを使用して、定期的に無制限の数のビルドを実行できます。
ただし、考慮すべきケースがいくつかあります。
クラウドエージェントを使用している場合、新しいクラウドエージェントが起動されるたびに、必要なすべてのイメージがダウンロードされます。
ビルドステップ設定で各実行時に強制的にプルするオプションが有効になっている場合、ローカルエージェントであっても、新しいビルドが実行されるたびにイメージがダウンロードされます。レート制限に達しないように、このオプションを無効にすることをお勧めします。
ビルド用にディスク領域を解放している間、TeamCity はローカルキャッシュから古い未使用の Docker イメージをクリーンアップする場合があります。
以前にビルドが Docker Hub に匿名でアクセスしていた場合は、無料の Docker ユーザープロファイルを作成し、TeamCity プロジェクトで Docker 接続を構成することで、許可されるプルの数を 2 倍にすることができます。TeamCity エージェントは、この接続を使用して、各ビルドの前に Docker Hub で認証できるようになります。
関連ページ：
Docker
Docker ビルドステップでは、ビルド内で、Docker コマンドを起動できます。新しくビルドされたイメージをレジストリにプッシュする必要がある場合は、次のように Docker レジストリ接続ビルド機能を構成することで、Docker または Podman レジストリに承認することができます。プロジェクト設定を開き、接続設定タブに移動します。プロジェクトに新しい Docker または Podman 接続を追加します。ビルド構成設定で、前の手順で作成した接続を使用して Docker レジストリ接続ビルド機能...
Docker レジストリ接続
Docker レジストリ接続ビルド機能により、TeamCity はビルドの開始前に DockerHub またはその他のコンテナーレジストリに自動的にサインインできます。この機能を次の場所に追加します。TeamCity による Docker/Podman 操作 (たとえば、および) の監視と検出を許可します。ビルド前に認証されたレジストリに自動的にログインし、ビルド後にログアウトします。ローカル (Docker と Podman の両方) イメージをクリーンアップし、レジストリにプッシュ (Doc...
ビルドパラメーターの設定
パラメーターは、TeamCity 設定およびビルドスクリプトの構文を介して参照するペアです。パラメーター部分は、生の値 () にすることも、別のパラメーターへの参照 () を含めることもできます。パラメーター型：TeamCity は次の 3 種類のパラメーターをサポートします。構成パラメーター — ビルド構成内で設定を共有することを主な目的とするパラメーター。これらのパラメーターを使用して、テンプレートから作成された構成やレシピを使用する構成をカスタマイズすることもできます。TeamCity は...
エージェント要件の設定
エージェントの要件は、ビルド構成を実行できるエージェントを指定する条件です。現在存在するすべての要件を表示して新しい要件を作成し、特定の構成を実行できるエージェントを確認するには、ビルド設定 | エージェント要件にアクセスしてください。エージェント要件ビデオガイド：要件構文：エージェント要件は式です。ここは、定義済みまたはカスタム (ユーザー定義) のビルドパラメーターです。例: エージェントにインストールされているオペレーティングシステムを報告するパラメーター。要件では、エージェントがこの特...
コマンドライン (スクリプト)
コマンドライン（ビルド構成内）またはスクリプト（パイプライン内）は、TeamCity の中で最も柔軟なビルドステップです。エージェントマシン上で直接コマンドを実行するため、インストールされている任意のツール（cURL、Homebrew、Python、Unreal Engine など）との連携が可能になります。ツール固有の TeamCity ステップの代替として使用することもできます。たとえば、ゴールで Maven ステップを使用する代わりに、スクリプトを実行します。ステップ設定：スクリプトステップ...
サービスメッセージ
サービスメッセージは、ビルドに関するコマンド / 情報をビルドスクリプトから TeamCity サーバーに渡す特別に構成されたテキストです。TeamCity、それらはビルドの標準出力ストリームに書き込まれる必要があり、ビルドステップから出力またはエコーされますによって処理されます。例:echo ##teamcity[<messageName> 'value']echo