Bitriseワークフローでのコンテナの使用
コンテナサポートにより、任意のDockerコンテナイメージをワークフロー内のステップグループの実行環境として使用できます。また、バックグラウンドサービスの実行も可能です。たとえば、高度なテストシナリオを実行する場合などに使用できます
コンテナーサポートにより、任意の Docker コンテナイメージを Steps グループの実行環境として使用できます。また、バックグラウンドサービスの実行も可能です。たとえば、高度なテストシナリオを実行する場合などに使用できます
コンテナを使用することには、次のような利点が考えられます。
-
ビルド環境を完全に制御できます。
-
ビルド中に依存関係をインストールする必要はありません。これにより、ビルド時間が短縮され、複雑さが軽減されます。
-
ローカル開発環境で使用しているのと同じ環境を使用して、アプリのテストとビルドを行うことができます。
リナックスのみ
これは Linux のみの機能で、macOS ベースの環境はサポートされていません。
ステップ実行コンテナ
Dockerコンテナは、以下のどのBitriseアプリでも定義できます bitrise.yml
設定ファイル。設定ファイルの最上位でコンテナを定義し、そのコンテナをで参照します with
ワークフロー設定内のグループ。
そのためには、以下を追加する必要があります containers
プロパティをあなたのものに bitrise.yml
ファイル。このプロパティでは、以下を定義する必要があります
-
コンテナの ID。このコンテナを参照するために使用されます。
-
使用したい Docker イメージの名前。
-
画像のバージョン。
containers: node-21: image: node:21.6 node-18: image: node:18.19
コンテナを定義したら、以下で参照できます with
ワークフロー内のグループ。同じ中のステップ with
グループは同じコンテナ内で実行されます。複数定義できます with
同じワークフロー内のグループ。
containers: node_22: image: node:22 python: image: python:3.12 workflows: ci: steps: - git-clone: {} - with: container: python steps: - script: title: Validate our changes using a custom python script inputs: - content: python3 validate.py - with: container: node_22 steps: - script: title: NPM install
画像を取得する
から任意のパブリック Docker イメージを使用できます Docker Hub。
詳細な設定オプションについては、以下をご覧ください コンテナ API リファレンス。
この例は、containerプロパティの簡単な使用方法で、ステップまたはステップのグループがさまざまな実行環境を使用できるようにする方法を示しています。
Docker Hub のパブリックノードイメージを使用して、2 つの異なるバージョンの Node.js を使用してアプリケーションをテストします。また、テスト前にカスタム Python スクリプトを実行して変更を検証します
containers: node_22: image: node:22 node_20: image: node:20 python: image: python:3.12 workflows: ci: steps: - git-clone@8: {} - with: container: python steps: - script: title: Validate our changes using a custom python script inputs: - content: python3 validate.py - with: container: node_22 steps: - script: title: NPM install inputs: - content: npm ci - script: title: NPM test inputs: - content: npm test - with: container: node_20 steps: - script: title: NPM install inputs: - content: npm ci - script: title: NPM test inputs: - content: npm test
いつ ci
ワークフローは実行中です:
-
ザ・
git-clone
ステップはデフォルトの Bitrise 環境で実行されます。 -
最初の
script
ステップは a で囲まれています。with
group にコンテナイメージが定義されているので、そのイメージから新しいコンテナが作成されます。python:3.12
。ホストは必要な作業ディレクトリをコンテナと共有するので、クローンされたリポジトリはコンテナ内で使用できるようになります -
Python スクリプトを実行するステップは、この新しく作成された Python コンテナ内で実行されます。
-
-ザ・
ci
ワークフローにはさらに 2 つあります。with
グループ。これらは次々に実行され、どちらもノード用に異なるコンテナイメージで設定されます。それぞれwith
グループは、グループ間で共有されない複数のイメージで構成できますが、ファイル共有が必要な場合に備えて、すべて同じボリュームマウントを使用します。 -
どちらのグループも、それぞれ異なる Node.js バージョンを使用してそれぞれの環境で npm パッケージをインストールし、テストを実行します。
Debian/Ubuntu イメージを使う
私たち スクリプト ステップは bash を使用するため、次のような場合に失敗する可能性があります。 alpine
ベースのイメージは、通常はインストールされていません。を使用することをおすすめします debian/ubuntu
ベースイメージ。
コンテナ間でのファイル共有
異なるコンテナやホストのBitrise環境間でのファイル共有を可能にするために、BitriseでDockerコンテナを実行するたびに以下のフォルダが共有されます。
-
/bitrise
-
/root/.bitrise:/root/.bitrise/
-
tmp:/tmp
デフォルトでは、Bitriseは以下を使用します /bitrise/src
作業ディレクトリとして、これらのフォルダーのいずれかで作成されたものはすべて、すべての Step 実行コンテナで使用できます。
ステップ実行コンテナのみ
これはステップ実行コンテナにのみ適用されます。サービスコンテナとのボリュームおよびファイル共有はサポートされていません。
サービスコンテナ
ステップのグループに1つ以上のサービスを設定できるため、Dockerコンテナを高度な統合テスト用のサービスとして実行できます。これらは、のライフサイクルと結びついています with
グループ化し、バックグラウンドで一緒に実行します。グループ内のすべてのステップが終了すると、クリーンアップされます。
そのためには、以下を追加する必要があります services
のトップレベルにあるプロパティ bitrise.yml
アプリのファイル。以下を定義する必要があります
-
でサービスを参照するために使用されるサービスの ID
with
グループ。 -
サービスのイメージ名。
-
サービスのイメージバージョン。
その後、ワークフロー内のサービスの ID を参照できます。 with
グループ。グループ内のステップは参照先のサービスにアクセスできるようになります。
containers: node-21: image: node:21.6 services: postgres: image: postgres:16 envs: - POSTGRES_USER: postgres - POSTGRES_DB: bitrise # You can reference Bitrise secrets here, e.g: $POSTGRES_PASSWORD - POSTGRES_PASSWORD: password ports: - 5432:5432 options: >- --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5 redis: image: redis:7 ports: - 6379:6379 options: >- --health-cmd "redis-cli ping" --health-interval 10s --health-timeout 5s --health-retries 5 workflows: e2e-tests: envs: - POSTGRES_DSN: "postgres://postgres:password@postgres:5432/bitrise" - REDIS_DSN: "redis://redis:6379/1" steps: - with: container: node-21 services: - postgres - redis steps: - script: title: e2e tests inputs: - content: npm run e2e-tests
設定例では、というワークフローが定義されています。 e2e-tests
。
このワークフローの with
group はサービスコンテナを使用して Postgres と Redis を使ったより高度な統合テストシナリオを実現しています。また、コンテナを利用して Node 環境でテストを実行します
次の 2 つのサービスが定義されています。 postgres
そして redis
。各サービスは、以下のように構成されています ヘルスチェック オプションパラメータを使用する。CLI はこれらのオプションを尊重し、すべてのサービスが正常と報告されて初めてステップの実行を開始します。
各サービスはポートで公開されていますが、コンテナを利用しているため、名前を使用してアクセスできます postgres:5432
そして redis:6379
それぞれ。
注記
コンテナの設定を省く (ステップ実行コンテナを使わない) と、以下のアドレスのサービスにアクセスできるようになります。
-
:postgres: localhost:5432
-
redis: localhost:6379
サービスの準備が整うと、ステップは npm run e2e-tests
環境変数を利用できるコマンド POSTGRES_DSN
と REDIS_DSN
サービスに接続するためにワークフローによって定義されます。
詳細な設定オプションについては、以下をご覧ください コンテナ API リファレンス。
サービスコンテナのネットワークアクセス
サービスコンテナはすべて同じコンテナに結合されています Docker ネットワーク と呼ばれる bitrise
。これにより、他のサービスコンテナやステップ実行コンテナからすべてにアクセスできるようになります。
独自のバックグラウンドワーカーの実行
Docker コマンドを自分で実行するか、次のようなものを使用して、独自のバックグラウンドワーカーを実行できます。 docker-compose
ただし、必ず同じネットワークを使用してください。
コンテナのデバッグ
ビルドが完了すると、ログは構造化されたビューに変換されます。これにより、ステップ間で作成されたすべてのログが削除されます。コンテナ機能はワークフローレベルで機能するため、そのログは各ワークフローの最初のステップの直前に表示されます。
コンテナログを確認するには、必ずビルドページから完全なログをダウンロードしてください。 ビルドログのダウンロード.