Skip to main content

マシンプールの構成

AWSコントローラーを作成しました、マシン プールを設定できます。プールは、同じ設定を共有し、Bitrise ビルドを実行できるインスタンスのグループです。コントローラーは、必要な量の一致するリソースが AWS 上で開始されるようにします。

新しいプールを作成する

新しいプールの作成は、プールに関する詳細情報を提供する必要がある、複数段階のウィザードを通じて行われます。

  1. 開く ワークスペース設定 ページ。

  2. 選択する セルフホスト型インフラストラクチャ そして、 AWS 上の Bitrise タブをクリックして プールを作成

    create-pool.png
  3. 最初の画面で、エージェント プールの設定を構成します。

    • プール名 (必須): プール名は スタックとマシン ワークフロー エディターのタブで、ビルドを実行するプールを選択できます。名前は、ワークスペース内、他のプール、および Bitrise エージェント プール間で一意である必要があります。名前が一意でない場合、プールを作成できません。

    • マシンの数 (必須): 作成されるマシンの数。数値が大きいほど、利用可能な同時実行の範囲内でより多くのビルドを並行して実行できます。

    • ローリング更新率 (必須): ローリング アップデート パーセンテージは、マシンの再起動中に予想されるシステムの可用性を構成します。数値が低いほど、変更のロールアウト中に使用できるマシンの数が増えますが、ロールアウトに必要な全体的な時間が大幅に長くなる可能性があります。指定する値は、1% から 100% までの範囲でなければなりません。システムは、パーセンテージ ベースの値を切り上げます。ローリング アップデート パーセンテージが 95% のマシンが 5 台ある場合、5 台すべてのマシンの再起動が同時に試行されます。この数値は、破壊的またはブロッキングな変更 (SSH キーのローテーションなど) がリリースされた場合に備えて高くしておくことをお勧めします。また、小さな変更 (ディスク サイズの縮小など) の場合は低くすることができます。

  4. クリック後 次の画面でマシンパラメータを入力します。

    machine-parameters.png
    • Amazon マシンイメージ (AMI) ID (必須): AMI は、モバイル ビルドを実行するために必要なすべてのツールがプリインストールされた Bitrise 構築環境です。サブスクライブした AMI の ID をここで設定する必要があります。現在のバージョンでは、Bitrise が管理する AMI のみが受け入れられます。

    • スタック (VM ベースの AMI に必須): スタック セレクターは、選択した AMI が VM ベースの MacOS AMI である場合にのみ使用可能になります。この場合、ユーザーはドロップダウンから 1 つのスタックを選択する必要があります。

    • 仮想マシンの数: VM の数の選択は、選択した AMI が VM ベースの MacOS AMI である場合にのみ使用可能になります。この場合、ユーザーはビルド マシンで実行する VM の数 (1 または 2) を選択する必要があります。

    • 可用性ゾーン (必須): 可用性ゾーンはリソースが予約される場所を定義します。コントローラーは、 マック2 または mac2-m2 インスタンスファミリーは、すべてのAWSアベイラビリティゾーンで利用できるわけではありません。有効なアベイラビリティゾーンを選択してください。 リストから

    • マシンタイプ(必須): マシン タイプ セレクターは、アベイラビリティー ゾーンが指定された後のみ使用可能になります。コントローラーは、選択されたマシン タイプに従ってビルド マシンを起動します。

    適切な地域を選択してください

    コントローラーは、コントローラーが配置されているのと同じリージョンでのみリソースを起動できます。選択したアベイラビリティーゾーンが同じリージョンにない場合、マシンは起動しません。

  5. 次の画面で、 ネットワークとセキュリティの設定、マシンに関する詳細をさらに指定できます。

    network-and-security.png
    • サブネットID (必須): 以前に設定したアベイラビリティ ゾーンから、マシンに使用するサブネット ID を指定します。作成されたすべてのマシンは同じサブネットで実行されます。マシンはサブネットから Bitrise サービスにアクセスできる必要がありますが、Bitrise は通信を開始しないため、パブリック サブネットである必要はありません。インスタンスが次のエンドポイントにアクセスできることを確認してください。

      • https://exec.bitrise.io

      • https://build-log.services.bitrise.io

      これらのエンドポイントにアクセスしないと、インスタンスに接続した後でもビルドを実行することはできません。サブネットの詳細については、 公式AWSドキュメント

    • パブリックIPアドレスの自動割り当て: このフィールドを有効にすると、EC2 インスタンスにパブリック IPv4 アドレスが作成されます。

    • セキュリティグループ (必須): 1 つ以上のセキュリティグループ ID を指定できます。セキュリティグループを使用すると、AWS リソースへのトラフィックを制御できます。

      少なくとも、 empty-default セキュリティグループが必要です。このセキュリティグループは受信側からは空で、送信側では 0.0.0.0/0 を許可します。インスタンスへのアクセスに SSH を使用する場合は、セキュリティグループで受信ポート 22 が開いている必要があります。SSH アクセス機能が不要な場合は、関連するセキュリティグループを削除することをお勧めします。セキュリティグループの詳細については、 公式AWSドキュメント

      For more details about security groups, check the official AWS documentation.

      ネットワーク設定

      選択したサブネットとセキュリティ グループが同じネットワークに属していることを確認してください。そうでない場合、マシンは起動しません。

    • インスタンスプロファイル (オプション): インスタンス プロファイルを使用して、マシンに追加の IAM ロールを設定できます。これは、AWS 内の他のリソースにアクセスする場合に必要です。たとえば、S3 バケットをアーティファクト ストアとして使用する場合などです。このような機能が必要ない場合は、プロファイルを空のままにしておきます。

      このオプションはストリーミングの権限を含めるために使用できます BitriseエージェントはCloudWatchに直接ログを記録しますログ管理と監視のための集中ソリューションを提供します。AWS CloudFormationパラメータが正しく設定されていれば、 bitrise-agent-log-instance-profile 生成されました。AWS では、ここでそのプロファイルの生成された ARN を取得できます。

    • SSHキー (オプション): インスタンスのデバッグを容易にします。SSH キーが提供され、正しいセキュリティ グループ設定が構成されている場合は、作成されたインスタンスに SSH 経由でアクセスできます。デバッグが不要な場合は、このフィールドを空のままにしておくことをお勧めします。

  6. クリック後 ストレージ要件を構成します。

    prewarm.png
    • ディスクタイプ (必須): さまざまなルートボリュームタイプから選択できます。少なくともgp3設定を使用することをお勧めします。詳細については、 AWSドキュメント

    • ストレージサイズ (必須): ルート ボリュームのサイズを GB 単位で指定します。必要な最小ディスク サイズとは異なるディスク サイズで、異なるイメージが作成されます。ディスク サイズは、最小サイズより少なくとも 50 GB 大きく設定することをお勧めします。

    • ディスクの予熱: 確実に動作させるために、すべての EBS デバイスでディスクの事前ウォーミングを行うことをお勧めします。この事前ウォーミングには、ストレージ サイズの構成が大きい場合は最大数時間かかるなど、かなりの時間がかかる場合があります。事前ウォーミングを無効にすることはできますが、その場合、ビルド マシンで実行される最初の数回のビルドは失敗します。

  7. 完了したらクリック プールを作成

プールが作成されると、プールの詳細が画面に表示されます。

pool-details.png

ヘッダーには、プールの名前とその状態が表示されます。プールが目的の状態にまだ達していない場合、状態は「更新中」です。完全に機能しているプールのステータスは「最新」です。

プール構成に関するセクションと、それに続く個々のマシンも表示されます。各マシンには状態があり、そのマシンで実行されているビルドの有無と、どのビルドが実行されているかを示します。

プールの再構成

プールの設定が正しくない場合(たとえば、異なるSSHキーと異なるサブネットを必要とするものを調査する必要がある場合)、 編集 構成されているプールのボタンをクリックして、プールを再構成します。

再構成が要求されると、コントローラーは実行中のリソースと誤って構成されたリソースの一部を終了します。終了が完了すると、代わりに新しいリソースが作成されます。このアプローチは、コストを可能な限り削減することを目的としています。

確認することをお勧めします ローリング更新率 設定値が高いと可用性が低下する可能性があるため、構成時に設定値を変更しないでください。ただし、設定値が低いとロールアウトが遅くなることもあります。

再構成が開始されると、プールのステータスは 更新中、すべてのリソースが新しい構成に従って実行されるまでこの状態のままになります。その時点で、プールの状態は 最新の また。

VMからのAWS AMIロールベース認証の使用

VM からの AWS ロールベース認証には、当社のプロキシを使用できます。プロキシはホスト上で実行され、AWS CLI クエリを AWS メタデータサーバーに転送し、ロールベース認証をシームレスに使用できるようにします。

セットアップ HTTP_PROXY 実行する AWS CLI コマンド専用の環境変数を設定します。これにより、AWS CLI のみがプロキシを使用するようになり、他のアプリケーションが誤ってプロキシを使用することがなくなります。

たとえば、S3 バケットから VM にファイルをコピーする方法は次のとおりです。

HTTP_PROXY=<http://192.168.64.1:42769> aws s3 cp s3://test-bucket/test_file.txt /tmp/test_file.txt

変数のスコープ

他のアプリケーションに影響を与えないようにするには、コマンドの範囲内で HTTP_PROXY 変数を使用します。グローバルに設定すると、他のアプリケーションが意図せずプロキシを使用する可能性があります。