Overview

CircleCI Server v2.x uses the CircleCI 2.0 architecture.
version: 2.0 should be used in all .circleci/config.yml files.
Currently not supported for Server: orbs, reusable commands, pipelines.

CircleCI Server is a modern continuous integration and continuous delivery (CI/CD) platform installable inside your private cloud or data center. Refer to the Changelog for what’s new in this CircleCI Server release.

Services 稼働環境
Figure 1. CircleCI Services Architecture

ビルド環境

CircleCI 2.0 uses Nomad as the primary job scheduler. Refer to our Introduction to Nomad Cluster Operation to learn more about the job scheduler and how to perform basic client and cluster operations.

By default, CircleCI 2.0 Nomad clients automatically provision containers according to the image configured for each job in your .circleci/config.yml file.

Architecture

Figure 1.1 illustrates CircleCI core components, build orchestration services, and executors. CircleCI API は、全面的な機能を備えた RESTful API で、CircleCI のすべての情報にアクセスでき、すべてのアクションをトリガーできます。

Within the CircleCI UI is the Insights page, which acts as a dashboard showing the health of all repositories you are following including:

  • median build time

  • median queue time

  • last build time

  • success rate

  • parallelism

CircleCI は、Services と Nomad クライアントという 2つのプライマリコンポーネントで構成されます。 任意の数の Nomad クライアントがジョブを実行し、Services と通信します。 All components must access GitHub or your hosted instance of GitHub Enterprise on the network, as illustrated below.

CircleCI Core Components

Services マシン

The Services machine must not be restarted and may be backed up using VM snapshotting. If you must restart the Services machine, do so only as a last resort, because a restart will result in downtime. Refer to the Backup and Recovery chapter for instructions.

DNS resolution may point to the IP address of the Services machine. It is also possible to point to a load balancer, for example an ELB in AWS. The following table describes the ports used for traffic on the Service machine:

ソース ポート 用途

エンド ユーザー

80, 443, 4434

HTTP/HTTPS トラフィック

管理者

22

SSH

管理者

8800

管理者コンソール

Builder Boxes

すべてのトラフィック、すべてのポート

内部通信

GitHub (Enterprise または .com)

80、443

受信 Web フック

Nomad クライアント

Nomadクライアントは実行後に状態を保持しないため、必要に応じてコンテナ数を増減することができます。

すべてのビルドを処理できる十分な数の Nomad クライアントが確実に実行されるようにするには、キューイングされているビルドを追跡し、必要に応じて Nomad クライアント マシンの数を増やして負荷を分散させます。 For more on tracking metrics see Monitoring Your Installation.

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

The maximum machine size for a Nomad client is 128GB RAM/ 64 CPUs, contact your CircleCI account representative to request use of larger machines for Nomad Clients.

以下の表に、Nomad クライアントで使用されるポートを示します。

ソース ポート 用途

エンド ユーザー

64535-65535

ビルドへの SSH 接続機能

管理者

80 または 443

CCI API アクセス

管理者

22

SSH

Services マシン

すべてのトラフィック、すべてのポート

内部通信

Nomad クライアント (それ自身を含む)

すべてのトラフィック、すべてのポート

内部通信

GitHub

CircleCI uses GitHub or GitHub Enterprise credentials for authentication which, in turn, may use LDAP, SAML, or SSH for access. つまり、CircleCI は、一元管理された SSO インフラストラクチャでサポートされる認証を継承します。

CircleCI では、セットアップ後の URL やバックエンドの GitHub インスタンスの変更には対応していません。 以下の表に、GitHub を実行するマシンで Services および Nomad クライアント インスタンスと通信する際に使用されるポートを示します。
ソース ポート 用途

Services

22

Git アクセス

Services

80、443

API アクセス

Nomad クライアント

22

Git アクセス

Nomad クライアント

80、443

API アクセス



Help make this document better

This guide, as well as the rest of our docs, are open-source and available on GitHub. We welcome your contributions.