Search Results for ""

管理者向けの概要

システム管理者を対象に、以下のセクションに沿って CircleCI 2.0 インストール、機能、環境、およびアーキテクチャの概要について説明します。

CircleCI は、最新の継続的インテグレーションおよび継続的デリバリー (CI/CD) のプラットフォームです。 プライベートクラウドまたはデータセンター内にインストールでき、一定期間は無料でお試しいただけます。 評価版ライセンスをご希望の方は、お問い合わせください。

CircleCI 2.0 では、以下の改善点を含む新しいインフラストラクチャが提供されています。

  • 任意の数のジョブとワークフローを組織化できる新しい設定機能
  • ジョブごとの実行を行えるカスタムイメージ
  • カスタムキャッシュ、ジョブごとの CPU またはメモリの割り当てなど、きめ細かいパフォーマンス

ユーザーまたは開発者の方は、「CircleCI を始める」を参照しながら、ホスティングされているアプリケーションの使用を開始してください。

インストールオプション

お使いの環境に CircleCI をインストールするには、3 つの基本的な方法があります (現在いずれのオプションでも AWS が必須です)。

  1. 評価版ライセンスの利用時や小規模チームに適しているシングルボックスインストール
  2. 多くのチームでの本稼働使用に適しているクラスタ化インストール
  3. 高度な稼働時間要件を満たすための高可用性設定 (ライセンスでサポートされている場合)

ビルド環境

デフォルトでは、CircleCI 2.0 Builder インスタンスは、.circleci/config.yml ファイルでジョブごとに設定されたイメージに従ってコンテナを自動的にプロビジョニングします。 CircleCI は、CircleCI 2.0 のプライマリジョブスケジューラとして Nomad を使用します。ジョブスケジューラ、およびクライアントとクラスタの基本的な操作方法については、「CircleCI での Nomad クラスタの操作ガイド」を参照してください。

アーキテクチャ

CircleCI は、Services と Nomad クライアントという 2つのプライマリコンポーネントで構成されます。 Services は通常、コアアプリケーション、ストレージ、ネットワーク通信機能から成る単一のインスタンス上で動作します。 任意の数の Nomad クライアントがジョブを実行し、Services と通信します。 2つのコンポーネントはどちらも、以下のアーキテクチャ図に示すように、ネットワーク上で GitHub または GitHub Enterprise のホスティングされたインスタンスにアクセスする必要があります。

CircleCI のアーキテクチャの図

Services

Service インスタンスが動作するマシンは、再起動してはならず、組み込みの VM スナップショット機能を使用してバックアップできます。 メモ: 高可用性を実現するには、PostgreSQL と Mongo を使用して外部データストレージを設定します。また、データベースのバックアップには、標準のツールを使用します。詳細については、高可用性のための外部データベースホストの追加に関するドキュメントを参照してください。 DNS 解決は、Services がインストールされているマシンの IP アドレスを指す必要があります。 以下の表に、Service インスタンスでトラフィックに使用されるポートを示します。

ソース ポート 用途
エンドユーザー 80、443、4434 HTTP/HTTPS トラフィック
管理者 22 SSH
管理者 8800 管理者コンソール
Builder Boxes すべてのトラフィック/すべてのポート 内部通信
GitHub (Enterprise または .com) 80、443 受信 Web フック

Nomad クライアント

Nomad クライアントは実行時に状態を保存しないため、必要に応じてコンテナ数を増減することができます。 すべてのビルドを処理するために十分な数のクライアントマシンが確実に実行されるようにするには、キューイングされているビルドを追跡し、必要に応じて Nomad クライアントマシンを増やして負荷を分散させます。

マシンには、ビルドを調整するために 2つの CPU と 4 GB のメモリが予約されています。 そのうえで、残りのプロセッサーとメモリでコンテナが作成されます。 マシンの規模が大きくなれば、その分多くのコンテナを実行することができますが、調整用に予約してある 2つ以外に使用できるコアの数によって制限されます。 以下の表に、Builder インスタンスで使用されるポートを示します。

ソース ポート 用途
エンドユーザー 64535-65535 ビルド機能への SSH 接続
管理者 80 または 443 CircleCI API アクセス (正しいシャットダウンなど)
管理者 22 SSH
Services Box すべてのトラフィック/すべてのポート 内部通信
Nomad クライアント (それ自身を含む) すべてのトラフィック/すべてのポート 内部通信

GitHub

CircleCI では、認証に GitHub または GitHub Enterprise 認証情報が使用され、認証時には LDAP、SAML、または SSH を使用してアクセスできます。 つまり CircleCI では、一元管理された SSO インフラストラクチャによってサポートされる認証が継承されます。 以下の表に、GitHub を実行するマシンで Services および Builder インスタンスと通信する際に使用されるポートを示します。

ソース ポート 用途
Services 22 Git アクセス
Services 80、443 API アクセス
Nomad クライアント 22 Git アクセス
Nomad クライアント 80、443 API アクセス

お客様事例

Coinbase は、セキュリティと信頼性を確保するために CircleCI をファイアウォールの内側で実行しています。 Coinbase のケーススタディレポートによれば、CircleCI を使用することでマージからデプロイまでの平均時間が半分になり、CI のメンテナンスに費やす操作時間は要員 1人の時間の 50% を占めていたものが週 1時間未満に短縮され、開発者のスループットが 20% 増加しています。

GM 傘下の Cruise Automation では、CircleCI の導入により、コードの実地テストを行う前に多数のシミュレーションを行うことが可能になりました。詳しくは Cruise のケーススタディレポートをご覧ください。

CircleCI のカスタマーページでは、CircleCI を導入されている大企業および中小企業のすべてのケーススタディを参照していただけます。