Skip to main content

AWS インスタンスを Bitrise ワークスペースに接続する

成功するには AWS 上の Bitrise AMI を使用してインスタンスを起動しますを接続する必要があります。 bitrise.io に追加した Bitrise エージェント プール プロセス中に受け取ったトークンを使用してインスタンスに接続します。これにより、AWS EC2 インスタンスをビルド スタックとして使用して Bitrise でビルドを実行できるようになります。

インスタンスに接続するには 2 つの方法があります。

  • AWS Secret Manager を使用し、必要なスクリプトをセットアップする インスタンスを起動する。

  • SSH を使用してインスタンスに直接接続します。この方法は、トラブルシューティングの目的でのみ使用することをお勧めします。

AWS Secret Manager の使用

  1. Bitrise でエージェント プールを追加するプロセスからトークンを取得します。

  2. AWS マネージャーのシークレットを作成する そしてトークンをシークレットに保存します。

  3. IAM ロールを作成する シークレットを読み取り、EC2 インスタンスにアタッチする権限が必要です。

  4. インスタンスのユーザーデータを変更する: AWS Secret Manager で作成したシークレットを使用して、Bitrise エージェントを起動するコマンドを追加します。

    Mac インスタンス

    Linux インスタンス

    • ベアメタルの場合:

      TOKEN=$(aws --region ${Region} secretsmanager get-secret-value --secret-id MY_SECRET | jq -r '.SecretString')

sudo sed -i '' “s/BITRISE_AGENT_TOKEN/$TOKEN/” ~/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist

    • 仮想化製品の場合は、同時実行数と実行するスタックも指定する必要があります。

      利用可能なスタック

      次のコマンドを使用して、使用可能なスタックのリストを取得できます。

      /opt/virtualization-cli/bin/virtualization-cli list

      出力から必要となるのは、 name スタックの属性。

      利用可能な同時実行数

      同時実行設定に許可される値は 1 または 2 です。

      • 1 CC の場合、エージェントは 8 vCPU と 12 GB RAM を備えた 1 つの VM をスケジュールします。

      • 2 CC の場合、エージェントはそれぞれ 4 vCPU と 6 GB RAM を備えた 2 つの VM をスケジュールします。

      TOKEN=$(aws secretsmanager get-secret-value --secret-id MY_SECRET | jq  -r '.SecretString')
sudo sed -i '' 's/BITRISE_AGENT_CC/<YOUR_CONCURRENCY_PREFERENCE>/' /Users/ec2-user/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist
sudo sed -i '' 's/BITRISE_AGENT_STACK/<YOUR_DESIRED_STACK>/' /Users/ec2-user/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist
sudo sed -i '' “s/BITRISE_AGENT_TOKEN/$TOKEN/” ~/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist
    • TOKEN=$(aws secretsmanager get-secret-value --secret-id MY_SECRET | jq  -r '.SecretString')

sudo sed -i “s/BITRISE_AGENT_TOKEN/$TOKEN/” /etc/systemd/system/bitrise-den-agent.service
sudo systemctl start bitrise-den-agent.service

インスタンス接続のトラブルシューティング

EC2 インスタンスでエラーが発生した場合は、まず次のことを確認してください。

  • EC2 ダッシュボードで、インスタンスが EC2 インスタンスの下に表示されているかどうかを確認します。そうでない場合は、インスタンスが正しく起動されていないため、再度起動する必要があります。

  • インスタンスが表示され、スタックしているように見える場合は、 起動 状態の場合は、インスタンスの起動が完了するまで数分間待ちます。

  • インスタンスは出現したが、その状態がどちらでもない場合 起動 または ランニング場合は、新しいインスタンスを開始して終了する必要があります。

  • インスタンスの状態が ランニング しかしステータスは 初期化中、インスタンスの初期化が完了するまで数分間待ちます。

  • インスタンスの状態が ランニング そしてステータスは 障害のある場合は、インスタンスを再起動する必要があります。

  • インスタンスの状態が ランニング、ステータスは 準備ができて ただし、Bitrise ワークスペースのページにインスタンスが表示されない場合は、数分待ってから、それでも表示されない場合は、インスタンスのワークスペースへの接続の確認に進むことをお勧めします。

ワークスペースへのインスタンスの接続を確認するには、EC2 インスタンスに直接接続します。 SSHを使用する。

ベアメタル Mac インスタンス

仮想化された Mac インスタンス

Linux インスタンス

  1. インスタンスが次のエンドポイントにアクセスできることを確認してください。

    • https://den.services.bitrise.io

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

    これらのエンドポイントにアクセスしないと、インスタンスに接続した後でもビルドを実行できません。

  2. トークンを取得する エージェント プールの追加プロセスから ビットライズで。

  3. AWS 上のインスタンスに接続する そして、その上で次のコマンドを実行します。

    sudo sed -i '' 's/BITRISE_AGENT_TOKEN/<YOUR_AGENT_POOL_TOKEN>/' ~/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist
sudo launchctl load -w /Users/ec2-user/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist

  4. エージェント プールがインスタンス上で実行されていることを検証します。

    ps aux | grep bitrise-den-agent

  1. インスタンスが次のエンドポイントにアクセスできることを確認してください。

    • https://den.services.bitrise.io

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

    これらのエンドポイントにアクセスしないと、インスタンスに接続した後でもビルドを実行できません。

  2. Bitrise でエージェント プールを追加するプロセスからトークンを取得します。

  3. AWS 上のインスタンスに接続し、そこで次のコマンドを実行します。

    sudo sed -i '' 's/BITRISE_AGENT_TOKEN/<YOUR_AGENT_POOL_TOKEN>/' ~/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist
sudo sed -i '' 's/BITRISE_AGENT_CC/<YOUR_CONCURRENCY_PREFERENCE>/' /Users/ec2-user/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist
sudo sed -i '' 's/BITRISE_AGENT_STACK/<YOUR_DESIRED_STACK>/' /Users/ec2-user/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist
sudo launchctl load -w /Users/ec2-user/Library/LaunchDaemons/io.bitrise.self-hosted-agent.plist

  4. エージェント プールがインスタンス上で実行されていることを検証します。

    ps aux | grep bitrise-den-agent

  1. インスタンスが次のエンドポイントにアクセスできることを確認してください。

    • https://den.services.bitrise.io

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

    これらのエンドポイントにアクセスしないと、インスタンスに接続した後でもビルドを実行できません。

  2. AWS 上のインスタンスに接続し、そこで次のコマンドを実行します。

    sudo sed -i 's/BITRISE_AGENT_TOKEN/<YOUR_AGENT_POOL_TOKEN>/' /etc/systemd/system/bitrise-den-agent.service
sudo systemctl start bitrise-den-agent.service

  3. エージェント プールがインスタンス上で実行されていることを検証します。

    ps aux | grep bitrise-den-agent

or

sudo systemctl status bitrise-den-agent.service

永続的なビルド環境のクリーンアップ

概要

Bitrise CLI をエージェント モードで実行するように設定できます。これにより、セルフホスト エージェントでビルドを実行するときに永続的なビルド環境をクリーンアップできます。

Bitrise では、ビルドが開始されるたびに新しい仮想マシンが作成され、ビルドが完了すると仮想マシンは破棄されます。ただし、Bitrise ビルドを永続的なビルド環境で実行することはできます。このような環境では、あるビルドの製品が後続のビルドに影響を与える可能性があります。

セルフホスト型エージェントでは、1 つのエージェントが複数のビルドを (同時にまたは次々に) 実行します。これにより、ローカル ファイル システム上のビルド間でデータを共有できますが、あるビルドが別のビルドに影響を与えないように注意する必要もあります。

この問題を回避するには、Bitrise CLI を次の環境で実行するように設定できます。 エージェントモード。エージェントモードでは、 agent-config.yml ホストマシンの ~/.bitrise/ ディレクトリ。このファイルでは、新しいビルドの開始時またはビルドの終了時にクリーンアップするディレクトリを指定できます。単純なクリーンアップよりも高度な使用例がある場合は、独自のカスタム スクリプトを実行することもできます。

エージェントモードの設定

  1. を追加します。 agent-config.yml ファイルをあなたの ~/.bitrise/ ディレクトリ。

  2. クリーンアップ操作を実行するフォルダーを正確に構成したい場合は、 bitrise_dirs 財産。このプロパティはデフォルト設定をオーバーライドします。たとえば、 BITRISE_DEPLOY_DIR 環境変数をデフォルトよりも大きくします。

  3. 下 bitrise_dirs、ビルドの開始時または終了時に何らかのアクションを実行するディレクトリを定義します。 KEY: path フォーマット。たとえば、すべてのソース コード チェックアウト、デプロイ可能な成果物、およびデプロイ可能なテスト結果成果物に対して個別のディレクトリを定義できます。

    # Customize the common Bitrise directories
bitrise_dirs:
  # Root directory for all Bitrise data produced at runtime
  BITRISE_DATA_HOME_DIR: /opt/bitrise
  
  # Directory for source code checkout.
  BITRISE_SOURCE_DIR: /opt/bitrise/workspace/$BITRISE_APP_SLUG
  
  # Directory for deployable artifacts.
  BITRISE_DEPLOY_DIR: /opt/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/artifacts
  
  # Directory for deployable test result artifacts.
  BITRISE_TEST_DEPLOY_DIR: /opt/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/test_results

    Multiple projects of the same Workspace

    Don’t forget that multiple projects of the same Workspace could run on the same agent. Make sure to always include $BITRISE_APP_SLUG in the directory hierarchy to separate projects and their source code checkouts.

    # wrong:
BITRISE_SOURCE_DIR: /opt/bitrise/workspace
# correct:
BITRISE_SOURCE_DIR: /opt/bitrise/$BITRISE_APP_SLUG/workspace

  4. 追加 hooks の財産 agent-config.yml ファイル。このプロパティは、ビルドの開始時または終了時に実行するアクションを定義します。これには 4 つの異なるパラメータがあります。

    • cleanup_on_build_start: 新しいビルドの開始時にクリーンアップされるディレクトリを定義します。

    • cleanup_on_build_end: ビルドが完了するたびにクリーンアップされるディレクトリを定義します。ビルドに失敗した場合の実行は保証されません。

    • do_on_build_start: 新しいビルドの開始時に実行されるカスタム スクリプトを定義します。

    • do_on_build_end: ビルドの完了時に実行されるカスタム スクリプトを定義します。ビルドが失敗した場合の実行は保証されません。

    Nested Workflows

    A Script Step in a Workflow can execute bitrise run nested_workflow and trigger a nested workflow. This nested Workflow inherits all the envs and parameters of the parent Workflow, and the parent Workflow waits for the completion of the nested Workflow. When the nested Workflow is launched this way, hooks and directory cleanups are not executed in this process to avoid unexpected behavior.

  5. To test the agent mode, start a build. The log should show the following message at the top:

    Running in agent mode
Config file: .bitrise/agent-config.yml

一般的な構成例

例1 完全に分離されたビルド

状態を最小限に抑え、信頼性を最大限に高めるために、各ビルドには一意のディレクトリが割り当てられます。ソース コードはビルドごとに最初からチェックアウトされます。

bitrise_dirs:
  BITRISE_DATA_HOME_DIR: /opt/bitrise
  BITRISE_SOURCE_DIR: /opt/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/workspace
  BITRISE_DEPLOY_DIR: /opt/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/artifacts
  BITRISE_TEST_DEPLOY_DIR: /opt/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/test_results

hooks:
  # Since dirs are unique to each build, there is nothing to clean up here:
  cleanup_on_build_start: []
  
  # Clean up everything after the build ends:
  cleanup_on_build_end:
    - $BITRISE_SOURCE_DIR
    - $BITRISE_DEPLOY_DIR
    - $BITRISE_TEST_DEPLOY_DIR

例2 ウォーム チェックアウト用の共有ソース コード ディレクトリ

ソース コードのチェックアウトを高速化するために、以前のビルドのソース コード ディレクトリを再利用できます。

bitrise_dirs:
  BITRISE_DATA_HOME_DIR: /opt/bitrise
  # Use a warm clone of the repo for all builds:
  BITRISE_SOURCE_DIR: /opt/bitrise/$BITRISE_APP_SLUG/workspace
  # For artifacts and test results, it's still a good idea to place them into unique dirs
  BITRISE_DEPLOY_DIR: /opt/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/artifacts
  BITRISE_TEST_DEPLOY_DIR: /opt/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/test_results

hooks:
  # Since dirs are unique to each build, there is nothing to clean up here:
  cleanup_on_build_start: []
  
  # Optional: clean up artifacts and test results.
  # Note that $BITRISE_SOURCE_DIR is NOT clean up here!
  cleanup_on_build_end:
    - $BITRISE_DEPLOY_DIR
    - $BITRISE_TEST_DEPLOY_DIR

このセクションの内容: