CircleCI ランナーに関するよくあるご質問

CircleCI ランナーのセキュリティモデルは、どのようになっていますか。

CircleCI ランナーをインストールする際に、ジョブを実行するユーザーを選択できます。このユーザーにはジョブの実行に必要な権限だけを付与するようにご注意ください。

ジョブに Docker デーモンへのアクセスを許可することは、ユーザーにマシンへの root アクセスを許可することと同等です。

ジョブに必要な依存関係をインストールする方法を教えてください。

依存関係をインストールする方法は、主に 2 つあります。

  • 必要な依存関係をインストールすることをジョブに許可する

柔軟性は高くなりますが、ツールを全体にインストール、または重複しない方法で (作業ディレクトリなどに) ツールをインストールできる権限をジョブに付与する必要があります。

  • ランナーをインストールするマシンに手動でプリインストールする

安全性は確保されますが、ジョブの依存関係が変わったときには、ランナー マシンの再構成が必要になります。

どのような接続が必要ですか。

ジョブの取得と実行の際に CircleCI に接続するために、runner.circleci.comcircleci-binary-releases.s3.amazonaws.com へのアウトバウンド HTTPS 接続が必要です。

ランナーにインバウンド接続は必要ありません。それ以外では、ジョブの内容に応じた接続が必要になります。
チェックアウト ステップでは、VCS プロバイダーへのアクセスが必要です。キャッシュ、ワークスペース、アーティファクトを使用する場合は、circle-production-customer-artifacts.s3.amazonaws.com へのアウトバウンド HTTPS 接続が必要になります。

CircleCI ランナーを使用する場合、キャッシュ、ワークスペース、アーティファクトはどのように処理されますか。

キャッシュ、ワークスペース、アーティファクトは、S3 の us-east-1 リージョンに保存されます。ランナーが別のリージョンでセットアップされている場合、パフォーマンスが低下する可能性があります。また、現時点では料金は課されていませんが、今後、データ転送や保存に対して料金が設定される可能性があります。

アーティファクト ストレージを自社で完全に管理したい場合は、ビルトイン ステップを使用せず、ご希望のストレージ バックエンドに直接アーティファクトをアップロードすることをお勧めします。

ジョブ間の状態管理に関するベスト プラクティスを教えてください。

ランナー自体には、この点に関する厳格な決まりはありません。ジョブごとに専用の作業ディレクトリを作成し、後で削除するようランナーを構成できますが、必須ではありません。デフォルトでは、作業ディレクトリの外にファイルを配置することも制限されていません。

一般的には、再現性が高まるよう、ジョブが状態に依存することは最小限に抑えることをお勧めします。そのためには、前のジョブの内容に依存せずに確実にジョブが実行されるように、ジョブの最初にクリーンにするステップを配置するのが効果的です。

ホスト上に保持されるキャッシュをジョブ間で利用すると、ビルド時間の短縮を期待できますが、一方で、再現性は低下します。また、長期的には、ディスク容量を使い果たす可能性もあります。

1 つのホスト上で複数のランナーを実行することはできますか。

はい。launch-agent の複数のレプリカを、それぞれに一意の名前を設定して実行すれば、1 つのホスト上で必要な数のランナー (言い換えると、必要な数のジョブ) を実行できます。ただし、同時に実行したときに競合が発生しないように、ジョブが相互に十分に分離されるよう特に注意してください。