Linux Shell 用のランナーをセットアップする
Linux Shell ランナーによって Docker なしで Bitbucket Pipelines ビルドを独自の Linux インフラストラクチャ上で実行できるようになるので、セルフホスト ランナーが使用したビルド時間に対して課金されなくなります。
前提条件
OpenJDK 11 (11.0.15 以上) をインストール済み
Git 2.35.0 以上
Bash 3.2 以降
ランナー用のホストとして少なくとも 8GB の RAM を持つ 64 ビット Linux インスタンス。
ランナーの使用
1 台のマシンに複数のランナーをデプロイすると、共有ビルド環境が原因で、リソースの共有や使用量の競合に関連する問題が発生する可能性があります。
ランナー ページに移動します。
For Workspace runners, visit Workspace settings, then Workspace runners.
For Repository runners, visit Repository settings, then Runners.
[ランナーを追加] を選択します。
[ランナー インストール] ダイアログの [システムとアーキテクチャ] で [Linux Shell (x86_64)] を選択します。
[ランナー インストール] ダイアログの [Run] ステップに表示された
tar.gzファイルをダウンロードします。ファイルを任意のディレクトリに解凍します。次に例を示します。
tar -xv \ -f atlassian-bitbucket-pipelines-runner-x.y.tar.gz \ -C /home/<your_user_name>/atlassian-bitbucket-pipelines-runner/Runner フォルダーの
binディレクトリに移動して、[ランナー インストール] ダイアログの [Run] ステップに表示されたコマンドを実行します。
Linux Shell ランナーは Bash によって、パイプライン ステップを Linux マシン (ホスト デバイス) で実行します。これによってランナーはアプリをホストで実行できますが、クリーンなビルド環境が全ステップで提供されるわけではありません。ステップによって発生する副作用 (アプリのインストール、データベース サービスの開始、ビルド ディレクトリ外部におけるファイルの編集など) は、(新しいパイプラインの実行を含む) 次に実行するステップに影響を与える可能性があります。これを補うために、ランナーは各ステップの後にビルド ディレクトリを空にしようとします。各ステップで実行するスクリプトが他のステップに大きな影響を与えないようにするのは、ユーザーの責任です。
Linux Shell ランナーの制限事項
ランナーが使用したメモリ
スワップ メモリがホスト マシンで有効にされている際は、ランナーで実行されるステップによって作成されたプロセスがスワップ メモリを使用する可能性があります。これによって、メモリ使用量エラーと OOM (メモリ不足) エラーに関する暫定的なビルド結果が生じる可能性があります。これは、利用可能なスワップ メモリが十分にあってビルドが成功する場合もあれば、十分なスワップができずに同じビルドがメモリ不足になる場合があります。この制限によるメモリの問題がないかを必ずご確認ください。
共有ビルド環境
ランナーはシェルによってステップ スクリプトを実行するので、ホスト マシンはランナーで実行するようにスケジュールされた複数のステップによって共有されます。スクリプトのインストール、または新しいライブラリのインストールなど、システム全体の変更がステップ内のランナーに加えられた場合、その変更はホスト マシンで実行される後続のすべてのステップに影響します。
サポートされない機能
次の機能は実装方法に制限があってセキュリティが複雑なため、セルフホスト ランナーではサポート対象外です。
Step size — There is no restriction on memory usage for runners.
Windows ランナーは PowerShell で直接実行されるため、これらの機能のほとんどはサポートされていません。つまり、Docker コンテナーは関与しません。
その他の制限と回避策
キャッシュ
事前定義された Docker キャッシュはサポート対象外 - Docker と Pipelines の事前定義済み Docker キャッシュは、Linux Shell ランナーでサポートされていません。
キャッシュを異なる OS 間で共有する - Linux ランナーや MacOS ランナーなど、異なるキャッシュ名をランナー タイプごとに指定することをお勧めします。次に例を示します。
pipelines: custom: customPipelineWithRunnerAndCache: - step: name: Step 1 runs-on: - 'linux.shell' script: - echo "This step will run on a linux shell runner."; caches: - linux_bundler - step: name: Step 2 runs-on: - 'macos' script: - echo "This step will run on a macos runner."; caches: - macos_bundler definitions: caches: linux_bundler: vendor/bundle macos_bundler: vendor/bundleキャッシュには、他のオペレーティング システムでは動作しないプラットフォーム固有のファイルを含められます。キャッシュを異なるオペレーティング システム間で共有すると、MacOS ランナーが Linux 専用に生成されたファイルを使用しようとした際など、エラーが発生する可能性があります。
Bloated cache folder — Due to performance implications, we do not clean up the cache folder at the end of step execution. This may lead to the size of cache directories increasing rapidly, particularly for a workspace runner. If this occurs, we recommend creating a cron job to clean up cache folders on a regular basis.
キャッシュ フォルダーの場所は制限されていないため、キャッシュはデバイスにある任意のディレクトリに保存できます。キャッシュを定義する場所の技術的な影響にご留意のうえ、ホスト マシンが復旧可能であることをご確認ください。
Git LFS
In order to use Git LFS, you need to install Git LFS on your hosted machine. For instructions on how to install Git LFS, visit: Bitbucket Git Tutorials — Install LFS.
SSH キー
次のような場合、Bitbucket Pipelines で SSH キーをセットアップすることができます。
ビルドで Bitbucket やその他のホスティング サービスとの認証を行い、非公開の依存関係を取得する必要があります。
デプロイで成果物をアップロードする前にリモート ホストまたはサービスとの認証を行う必要があります。
SSH、SFTP、または SCP などのツールによってビルドする場合
For security reasons, a runner will not add your SSH keys to the build environment automatically. If required, SSH keys can be passed to a runner using a secure variable.
非公開キーをリポジトリ変数として受け渡す場合、次のようなセキュリティ上のリスクがあります。
パイプライン ビルドが子プロセスを生成する場合は、リポジトリ変数がその子プロセスにコピーされる。
セキュアな環境変数は、リポジトリへの書き込みアクセスを持つすべてのユーザーが取得できる。
We recommend that you never reuse an SSH key as a repository variable. Generate a new SSH key-pair for Pipelines, so the key can be disabled if it is compromised. It is possible to use deployment variables, which you can use with deployment permissions to control access. For details, see: Variables and secrets — Deployment variables.
セキュアなリポジトリ変数を OpenSSH で使用して SSH キーを追加するには、次の手順に従います。
ターミナルで次のような新しい SSH キーを生成します。
ssh-keygen -t rsa -b 4096 -N '' -f ~/.ssh/my_ssh_key非公開キーを base64 にエンコードします。現在、Pipelines では環境変数の改行はサポートされていません。次に例を示します。
base64 -w 0 ~/.ssh/my_ssh_keyエンコードされたキーを保護された変数として追加します。暗号化されたキーをターミナルからコピーして、次のようにセキュアな Bitbucket Pipelines 環境変数としてリポジトリに追加します。
In the Bitbucket repository, select Repository settings, then Repository variables.
ターミナルで、base64 エンコード済みの非公開キーをコピーします。
エンコード済みのキーを環境変数の値としてペーストします。[セキュア] が選択されていることを確認します。
公開キーをリモート ホストにインストールします。Pipelines がそのホストを認証できるようになる前に、リモート ホストに公開キーをインストールする必要があります。Pipelines ビルドに他の Bitbucket リポジトリに対するアクセス権を付与する場合は、公開キーをそのリポジトリに追加する必要があります。
SSH によってリモート ホストに公開キーをコピーするには、
ssh-copy-idコマンドを使用します。このコマンドは、キーをリモート ホスト上の~/.ssh/authorized_keysファイルに追加します。ssh-copy-id -i my_ssh_key <username>@<remote_host><username>はリモート ホスト上のユーザーです。サーバーへの SSH アクセスをテストするには、次の手順に従います。
ssh -i ~/.ssh/my_ssh_key user@hostホスト キーを取得して、ホスト VM (仮想マシン) の
~/.ssh/known_hostsファイルに追加します。known_hostsファイルには、ユーザーがアクセスする SSH サーバーの DSA ホスト キーが格納されます。適切なリモート ホストに接続していることを確認することが重要です。任意のリモート サーバーの DSA ホスト キーを取得します。これを行うには、次のコマンドを実行します。
ssh-keyscan -t rsa server.example.comこれらのキーをホスト仮想マシンの
~/.ssh/known_hostsファイルに追加します。無関係な行はすべて削除できます。
SSH キーを
bitbucket-pipelines.ymlファイルに追加してデコードします。次に例を示します。pipelines: default: - step: runs-on: self.hosted script: - (umask 077 ; echo $MY_SSH_KEY | base64 --decode > ./id_rsa) - ssh -i ./id_rsa <user>@<host> 'echo "connected to `host` as $USER"'
上記のスクリプトでは、~/.ssh/another_private_key ではなく ./id_rsa を代用します。これによって、ランナーはランナーのビルド フォルダーに生成されたファイルを監視して、ステップの最後にそのファイルの削除を試みます。ランナーのビルド フォルダー外に作成されたファイルは削除されず、ランナーは非公開キーを ~/.ssh に残すので、この場合はキーが悪用される可能性が高くなります。
ビルド フォルダーをクリーン アップできない可能性はまだあります。いかなるデータが侵害される可能性も減らすため、このステップで用いた SSH キーペアを定期的に更新することをお勧めします。
この内容はお役に立ちましたか?