Skip to main content

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

概要

To successfully launch your instance with the Bitrise AMI on AWS, you need to connect the Bitrise runner pool you added on bitrise.io to the instance, using the token you received during the process. This allows you to run builds on Bitrise using your AWS EC2 instance as your build stack.

成功するには 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 インスタンス

    重要

    When modifying the user data scripts for a macOS instance, make sure that there is no empty space before the start of the script. The first line should always be #!/bin/bash. If there is empty space before this line, the instance won't work.

    • ベアメタルの場合:

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

sudo sed -i '' “s/BITRISE_AGENT_TOKEN/$TOKEN/” /Users/ec2-user/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/” /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
    • 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>/' /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. Bitrise でエージェント プールを追加するプロセスからトークンを取得します。

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

    sudo sed -i '' 's/BITRISE_AGENT_TOKEN/<YOUR_AGENT_POOL_TOKEN>/' /Users/ec2-user/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ビルドを実行することもできます。たとえば、 オンプレミスランナー または AWS EC2インスタンスでビルドを実行するこのような環境では、1 つのビルドの製品が後続のビルドに影響を与える可能性があります。

セルフホスト型インフラストラクチャでは、1 つの Bitrise ランナーが複数のビルドを実行します。これにより、ローカル ファイルシステム上のビルド間でデータを共有できますが、1 つのビルドが別のビルドに影響を与えないように注意する必要があります。

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

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

リナックス

macOS

  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
  
  # Directory for the html reports
  BITRISE_HTML_REPORT_DIR: /opt/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/html_reports

    同じワークスペースの複数のプロジェクト

    同じワークスペースの複数のプロジェクトが同じエージェント上で実行される可能性があることを忘れないでください。必ず以下を含めてください。 $BITRISE_APP_SLUG ディレクトリ階層でプロジェクトとそのソース コードのチェックアウトを分離します。

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

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

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

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

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

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

    ネストされたワークフロー

    あ スクリプト ワークフローのステップは実行できる bitrise run nested_workflow ネストされたワークフローをトリガーします。このネストされたワークフローは、親ワークフローのすべての環境とパラメータを継承し、親ワークフローはネストされたワークフローの完了を待機します。ネストされたワークフローがこのように起動されると、予期しない動作を回避するために、このプロセスではフックとディレクトリのクリーンアップは実行されません。

  5. エージェント モードをテストするには、ビルドを開始します。ログの上部に次のメッセージが表示されます。

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

  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: /Users/ec2-user/bitrise
  
  # Directory for source code checkout.
  BITRISE_SOURCE_DIR: /Users/ec2-user/bitrise/workspace/$BITRISE_APP_SLUG
  
  # Directory for deployable artifacts.
  BITRISE_DEPLOY_DIR: /Users/ec2-user/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/artifacts
  
  # Directory for deployable test result artifacts.
  BITRISE_TEST_DEPLOY_DIR: /Users/ec2-user/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/test_results
  
  # Directory for the html reports
  BITRISE_HTML_REPORT_DIR: /Users/ec2-user/bitrise/$BITRISE_APP_SLUG/$BITRISE_BUILD_SLUG/html_reports

    同じワークスペースの複数のプロジェクト

    同じワークスペースの複数のプロジェクトが同じエージェント上で実行される可能性があることを忘れないでください。必ず以下を含めてください。 $BITRISE_APP_SLUG ディレクトリ階層でプロジェクトとそのソース コードのチェックアウトを分離します。

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

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

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

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

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

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

    ネストされたワークフロー

    あ スクリプト ワークフローのステップは実行できる bitrise run nested_workflow ネストされたワークフローをトリガーします。このネストされたワークフローは、親ワークフローのすべての環境とパラメータを継承し、親ワークフローはネストされたワークフローの完了を待機します。ネストされたワークフローがこのように起動されると、予期しない動作を回避するために、このプロセスではフックとディレクトリのクリーンアップは実行されません。

  5. エージェント モードをテストするには、ビルドを開始します。ログの上部に次のメッセージが表示されます。

    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

このセクションの内容: