Start Building for Free
CircleCI.comアカデミーブログコミュニティサポート

コンテナエージェント (コンテナランナー) のオープンプレビュー

3 weeks ago3 min read
クラウド
このページの内容

こちらは、オープンプレビューでご利用いただけるようになった、CircleCI の新しいタイプのセルフホストランナーに関するドキュメントです。

概要と経緯

CircleCI の セルフホストランナー はこれまで、ジョブと、セルフホストランナーのバイナリと同じ環境で起動された 仮想マシン (VM) を 1 対 1 でマッピングして各ジョブを実行していました。 このように VM でジョブを排他的に実行すると、 Docker Executor の使用時に CircleCI のクラウドが提供する次のようなコンテナベースソリューションのメリットが失われます。

  • ジョブ実行時に、カスタム Docker イメージをシームレスに定義、パブリッシュ、使用する

  • .circleci/config.yml のステップで依存関係を列挙せずに、カスタム Docker イメージを使って依存関係やライブラリを簡単に管理する

  • ジョブの実行のたびに Docker イメージをダウンロードし、コンテナでジョブを実行することで、クリーンなビルド環境を使用できるという軽量なコンテナ技術の利点を最大限に活用する

コンテナエージェント (正式名称は未定) は、現在オープンプレビューで利用できるテクノロジーです。これをプライベートの Kubernetes (k8s) クラスタにインストールすると、ネイティブな Docker Executor を使用するジョブを CircleCI のクラウドプラットフォームで実行するのと同じように、Docker ジョブをセルフホストコンピューティング環境で実行できます。

コンテナエージェントは既存のセルフホストランナーの補完機能であり、代替機能ではありません。

コンテナエージェントのバイナリをインストールすると、コンテナエージェントは Docker ジョブを要求し、それらをエフェメラルポッドでスケジュール設定し、コンテナベースの実行環境で処理を実行します。

Container agent model
Figure 1. コンテナエージェントモデル -多数のコンテナエージェントとタスクエージェント

インストールと使用に関する注意事項

CircleCI でセルフホストランナーエージェント (コンテナエージェントを含む) を使用する場合は、あらかじめ リソースクラス とそれに関連するリソースクラストークンを 作成 してください。 これは、CircleCI Web アプリまたは CircleCI CLI を使って行えます (CircleCI Web アプリを推奨)。 リソースクラストークンは、以下に示す agent.resourceClasses パラメーターで使用されます。

前提条件

  • Kubernetes 1.12 以上

  • Helm 3.x

  • ランナーのリソースクラストークン

  • コンテナエージェントが、他のワークロードがない状態で、Kubernetes 名前空間で実行されていること (エージェントまたはガベージコレクション (GC) によって、同じ名前空間内のジョブが削除される可能性があるため)

  • checkout ステップで、SSH でチェックアウトするように git が設定されていること。 これを使用する場合は、ポート 22 からのアウトバウンド接続を許可するようにクラスタが設定されていることを確認してください。

Helm チャートのインストール

コンテナエージェントは、インストールに Helm チャートを使用します。 container-agent というリリース名で Helm チャートをインストールするには、次を実行します。

  • helm repo add circleci https://circleci-binary-releases.s3.amazonaws.com/charts/ を実行してコンテナエージェント Helm repo を追加した後で helm repo update を実行します。

  • helm show values circleci/container-agent を実行するとデフォルト値を確認できます。これらを、以下の install コマンドに --values フラグまたは --set name=value フラグを指定することで上書きします。

    • 上書きが必要なデフォルト値は agent.resourceClasses のみです。

  • チャートをインストールするには helm install container-agent circleci/container-agent -n circleci を実行します。

この結果、コンテナエージェントが container-agent というリリース名で Kubernetes クラスタにデプロイされます。 次の「パラメーター」セクションは、コンテナエージェントのインストール時に設定できるパラメーターを示しています。

リソースクラスの設定とカスタマイズされたタスクポッドの設定

カスタマイズなしでジョブを実行するには、次の設定を Helm チャートの values.yaml に追加します。 MY_TOKEN は、ランナーのリソースクラストークンです。

agent:
  resourceClasses:
    namespace/my-rc:
      token: MY_TOKEN

ジョブの実行 に進んで最初のジョブを実行するか、このまま、ポッドへのカスタマイズされた設定の適用方法をお読みください。

コンテナエージェントでは、複数のリソースクラスから同時にタスクを要求または実行できます。また、特定のリソースクラス用のタスクを実行するために作成された Kubernetes リソースをカスタマイズすることもできます。 設定は、Helm チャート values.yaml にあるマップオブジェクトによって提供されます。

各リソースクラスは、次のパラメーターをサポートしています。

  • token: タスクを要求するために使用される、ランナーのリソースクラストークン (必須)

  • CircleCI ジョブの実行に使用するポッド用のカスタマイズされた Kubernetes ポッド設定

このポッド設定は、通常の Kubernetes ポッド 用のフィールドをすべて取得します。 サービスコンテナが CircleCI ジョブで使用される場合、最初の container 仕様が、タスクポッド内のすべてのコンテナに使用されます。 現在、サービスコンテナとメインタスクコンテナで異なるコンテナ設定を使用することはできません。

以下は、タスクが正しく機能し、CircleCI 設定が問題なく動作するように、コンテナエージェントによって上書きされるフィールドです。

  • spec.containers[0].name

  • spec.containers[0].container.image

  • spec.containers[0].container.args

  • spec.containers[0].container.command

  • spec.containers[0].container.workingDir

  • spec.restartPolicy

  • metadata.name

  • metadata.namespace

以下は、2 つのリソースクラスを使用した完全版の設定例です。

agent:
  resourceClasses:
    circleci-runner/resourceClass:
      token: TOKEN1
      metadata:
        annotations:
          custom.io: my-annotation
      spec:
        containers:
          - resources:
              limits:
                cpu: 500m
            volumeMounts:
              - name: xyz
                mountPath: /path/to/mount
        securityContext:
          runAsNonRoot: true
        imagePullSecrets:
          - name: my_cred
        volumes:
          - name: xyz
            emptyDir: {}

    circleci-runner/resourceClass2:
      token: TOKEN2
      spec:
        imagePullSecrets:
          - name: "other"

ジョブの実行

クラスタにコンテナエージェントをインストールしたら、CircleCI Docker ジョブを作成してトリガーし、インストールを検証します。

  • circleci/config.yml ファイルで、 Docker Executor 構文 を、コンテナエージェントのインストール環境の resourceClasses セクションに含めたリソースクラスと組み合わせて使用します。

  • 具体的には、ジョブをルーティングして、クラスタ内のコンテナエージェントを使って実行されるようにするため、コンテナエージェントのジョブ用に作成したリソースクラスを使用するようにリソースクラスのスタンザを更新します。

    resource_class: <namespace>/<name-of-resource-class-created>

設定ファイルを更新したら、ジョブが正常に実行されたかどうかを実際にトリガーして検証し、CircleCI Web アプリを使ってグリーンビルド (成功したビルド) であることを確認します。 一から始める場合は、 FAQ セクション にあるサンプル設定を参照してください。

Helm チャートのパラメーター

以下は CircleCI 固有の設定です。

パラメーター説明デフォルト

agent.runnerAPI

ランナー API の URL

https://runner.circleci.com

agent.name

この特定の container-agent インスタンスに割り当てる名前 (できれば一意の名前)。 この名前は、CircleCI UI の Runner Inventory ページに表示されます。 指定しない場合は、デプロイの名前がデフォルトで設定されます。

container-agent (デプロイの名前)

agent.resourceClasses ジョブを正常に実行するため、デフォルト値の更新が必要

リソースクラスタスクの設定。 以下のリソースクラスの設定に関するセクションを参照してください。

" "

agent.terminationGracePeriodSeconds

コンテナエージェントをシャットダウンする際の、終了までの猶予期間

18300

agent.maxRunTime

タスクの最大実行時間。 この値は、上記の猶予期間より短くなければなりません。指定可能な値については ドキュメント を参照してください。

5 時間

agent.maxConcurrentTasks

同時に要求または実行できるタスクの最大数

20

agent.kubeGCEnabled

ガベージコレクションを有効または無効にするオプション

true

agent.agent.kubeGCThreshold

ガベージコレクションで削除されるまでにポッドが実行できる時間

5 時間 5 分


以下は Kubernetes オブジェクトの設定です。 先頭に agent が付いたパラメーターはコンテナエージェントポッド用で、ジョブが実行されるエフェメラルポッド用ではありません。

パラメーター説明デフォルト

nameOverride

チャート名を上書き

" "

fullnameOverride

生成されたフルネームを上書き

" "

agent.replicaCount

デプロイするコンテナエージェントの数。 デフォルト値の 1 のままにすることをお勧めします。

1

agent.image.registry

エージェントイメージのレジストリ

" "

agent.image.repository

エージェントイメージのリポジトリ

circleci/container-agent

agent.pullPolicy

エージェントイメージのプルポリシー

ifNotPresent

agent.tag

エージェントイメージのタグ

latest

agent.pullSecrets

コンテナエージェントポッド用 (タスクを実行するエフェメラルポッド用ではない) の シークレットオブジェクト コンテナのプライベートレジストリの認証情報

[]

agent.matchLabels

エージェントポッドで使用されるマッチラベル

app: container-agent

agent.podAnnotations

エージェントポッドに追加する追加の注釈

{}

agent.podSecurityContext

エージェントポッドに追加するセキュリティコンテキストポリシー

{}

agent.containerSecurityContext

エージェントコンテナに追加するセキュリティコンテキストポリシー

{}

agent.resources

コンテナエージェントポッド用のカスタマイズされたリソース仕様

{}

agent.nodeSelector

エージェントポッドの Node Selector

{}

agent.tolerations

エージェントポッドの Node Toleration

{}

agent.tolerations

エージェントポッドの Node Toleration

[]

agent.affinity

エージェントポッドの Node Affinity

{}

serviceAccount.create

エージェントのカスタマイズされたサービスアカウントを作成

true

rbac.create

サービスアカウントの Role と RoleBinding を作成

コンテナエージェントには、次に示す Kubernetes の権限が必要です。

  • Pod、 Pod/Exec、Pod/Log

    • Get

    • Watch

    • List

    • Create

    • Delete

  • シークレット

    • List

    • Create

    • Delete

デフォルトでは RoleRoleBinding 、およびサービスアカウントが作成され、コンテナエージェントポッドにアタッチされますが、これらをカスタマイズする場合は上記が最低限必要な権限です。

コンテナエージェントは、他のワークロードがない状態で、Kubernetes 名前空間で実行されていることを前提としています。 エージェントまたはガベージコレクション (GC) は、同じ名前空間のポッドを削除してしまうことがあります。

ガベージコレクション

コンテナエージェントは、クラスタに残ったままの、 app.kubernetes.io/managed-by=circleci-container-agent というラベルが付いたポッドやシークレットを削除するガベージコレクタを備えています。 デフォルトでは、これによって、5 時間 5 分を経過したジョブがすべて削除されます。 この時間は agent.kubeGCThreshold パラメーターを使って短くも長くもできます。 ただし、ガベージコレクション (GC) の頻度を下げた場合は、 agent.maxRunTime パラメーターの値を GC の頻度より小さくして、タスクの最大実行時間も短くしてください。 そうしないと、実行中のタスクポッドが GC によって削除されてしまう場合があります。

コンテナエージェントは、終了シグナルを送信すると、ドレインして再起動します。 現時点のオープンプレビューでは、コンテナエージェントが、起動に失敗したタスクを自動的にローンチ しようとすることはありません。 これは、CircleCI Web アプリで行うことができます。

現時点では、コンテナエージェントがクラッシュすると、処理中またはキューで待機中のタスクが安全に処理されるとは期待できません。 オープンプレビューの今後の過程で、クラッシュ時の対処方法が追加され、文書化される予定です。

料金と提供プラン

コンテナエージェントのジョブは ランナーネットワーク通信 の対象です。 これは、セルフホストランナーの既存の料金モデルに沿っており、今後は、CircleCI の他のネットワークやストレージの料金設定にも合わせていく予定です。 ご不明な点がありましたら、CircleCI の担当者にお問い合わせください。

セルフホストランナーの 同時実行制限 を含む同様のプラン別設定は、コンテナエージェントのオープンプレビューにも適用されます。 最終的な料金設定と提供プランは、製品の販売開始が近づきましたらご案内いたします。

制限事項

コンテナエージェントは現在プレビュー段階であり、ご利用時にはいくつかの制限があります。 これは制限を網羅するものではなく、重要な事項のみを取り上げます。 以下の内容は変わる可能性があり、現時点でサポートされていない機能も今後サポートされる可能性があります。

  • SSH を使用したジョブの再実行

  • 既存のセルフホストランナーに対する既知の 制限事項は、コンテナエージェントにも引き続き適用されます。

  • Docker イメージのビルド:

    • 現在、コンテナエージェントを使ったコンテナイメージのビルド (例: setup_remote_docker) はサポートされていません。

    • 現在、コンテナエージェントで使用する Docker イメージのビルド方法として、Docker in Docker (DIND) よりも推奨される次の 3 つのオプションがあります。

      1. セルフホストランナー:

        • Docker イメージのビルドのみを目的とした、ランナーのリソースクラスを個別に作成します。

        • VM に machine ランナーをインストールし、それを、Docker イメージのビルド用に予約しておいたリソースクラスに割り当てます。 VM にも Docker をインストールします。

        • CircleCI の設定ファイルで、イメージのビルドジョブを作成します。 setup_remote_docker を使用せずに、イメージをビルドするための Docker コマンドを列挙し、前の手順で作成したビルドイメージのリソースクラスを指定します。 イメージのビルドジョブが、ビルドするイメージを使用するジョブより先に実行されるようにしてください。 イメージのビルドジョブの最後で、イメージをプッシュしてからコンテナエージェントを使用してそのイメージをプルし、Docker ジョブを実行します。

      2. CircleCI がホストするコンピューティング環境:

        • 前述の「Docker イメージのビルド」の箇条書き項目で説明したように、リモート Docker または Linux Machine Executor を使用して、CircleCI がホストするコンピューティング環境を使ってイメージのビルドジョブの Docker コマンドを実行します。

        • CircleCI の設定ファイルで、イメージのビルドジョブを、そのイメージを使用するジョブより先に実行します。 「イメージのビルド」ジョブの最後で、イメージをプッシュしてからコンテナエージェントを使用してそのイメージをプルし、Docker ジョブを実行します。

        • Docker in Docker は、クラスタに対するセキュリティリスクを招く可能性があるため推奨されません。

      3. Podman:

        • Podman などのテクノロジーを使って Docker ジョブ内で Docker イメージをビルドすることは可能です。

  • Kubernetes を除き、コンテナ環境のサポートは現時点ではありません。

  • Web アプリでの UI ベースのインストールフローを使用したコンテナエージェントのインストールはサポート対象外です。ただし、コンテナエージェントで使用できる、ランナーのリソースクラスの作成は例外です。

  • Docker レイヤーキャッシュ は、セルフホストランナーでもコンテナエージェントでも機能しません。

  • コンテナエージェントとクラウド版 CircleCI では、 プライマリコンテナ のエントリポイント設定方法が異なります。 クラウドの場合、プライマリコンテナのエントリポイントは com.circleci.preserve-entrypoint=true LABEL 指示を使用して保持されていない限り無視されます ( エントリポイントの追加 を参照)。 一方、コンテナエージェントには常にシェル (/bin/sh) がデフォルト設定されるか、ジョブ設定でエントリポイントが指定されている場合はそれが設定されます。

    • 注: エントリポイントは、失敗せずに最後まで実行される必要があります。 失敗した場合、またはビルドの途中で停止した場合は、ビルドも停止します。 ログまたはビルドステータスにアクセスする必要がある場合は、エントリポイントの代わりにバックグラウンドステップを使用します。

    • 指定したイメージのエントリポイントが無効な場合、ジョブは以下のエラーとともに失敗します。 could not run task: launch circleci-agent on "container-0" failed: command terminated with exit code 139

  • コンテナエージェントは CircleCI Server ではまだ動作しません。

技術サポートを受けるには

CircleCI の担当者に直接ご連絡いただくか、 Discuss の投稿 からお問い合わせください。

FAQ

CircleCI でのタスクとジョブの違いを教えてください。

タスクは CircleCI での作業の最小単位です。 あるジョブに 並列実行 が 1 つある場合、それは 1 つのタスクと見なされます。 ジョブに並列実行が n 個あり、n が 1 より大きい場合、そのジョブは n 個のタスクを作成して実行します。

ランナーのリソースクラスとは何ですか。 リソースクラストークンとは何ですか。

リソースクラスは、CircleCI ジョブとそのジョブを処理するために識別されたランナー (またはコンテナエージェント) のタイプを一致させるためのラベルです。 リソースクラスの最初の部分は組織の名前空間です。 たとえば、 circleci/documentation などです。

リソースクラスを使用すると、セルフホストランナーのプールを特定して、特定のリソースにジョブを送信するように設定できます。 たとえば、macOS を実行する複数のマシンと Linux を実行する複数のマシンがある場合、ぞれぞれに対して、orgname/macOS と orgname/linux のリソースクラスを作成することができます。 .circleci/config.yml のジョブレベルでは、リソースクラスに基づいて、ジョブの送信先となるセルフホストランナーのリソースを関連付けることができます。

リソースクラスを作成するたびに、指定したリソースクラスと関連付けられた リソースクラストークン が生成されます。 このトークンは、リソースクラスが有効であることを CircleCI が認証する仕組みです。

1 つのコンテナエージェントのデプロイで使用できるリソースクラスは 1 つだけですか。

いいえ。コンテナエージェントのデプロイにはリソースクラスをいくつでも使用できます。 コンテナエージェントでジョブを正常に実行するには、少なくとも 1 つのリソースクラスが必要です。

コンテナエージェントで使用されるのは、プッシュベースモデルとプルベースモデルのどちらですか。

コンテナエージェントはプルベースモデルを使用します。

コンテナエージェントを使って、現在使用中の Kubernetes クラスタをスケーリングできますか。

コンテナエージェント自体が単一のレプリカセットの独自デプロイメントであり、スケーリングは今のところ必要ありません。 コンテナエージェントが Kubernetes クラスタ自体をスケーリングすることはありません。 ただし、クラスタ内に利用可能なリソースがあれば、作業をスケジュールします。

このテクノロジーは誕生からまだ日が浅く、コンテナエージェントが問題なくスケジュール設定できる同時実行タスクの最大数についてはテスト中です。

クラスタスケーリングのシグナルとして queue depth API の使用をご検討ください。

コンテナエージェントが扱える同時実行タスクの数に上限はありますか。

コンテナエージェントは、ランナーの最大同時実行数を上限として作業を要求およびスケジュールします。 また、デフォルトでは、コンテナエージェントは最大 20 個のタスクを同時にスケジュールおよび実行できるように設定されています。ご利用のランナーで 20 個を上回る同時実行数が許可されている場合は、Helm を使用して別の値に設定できます。 前述の パラメーター セクションにある agent.maxConcurrentTasks パラメーターを参照してください。

組織でのランナーの同時実行制限は、既存の machine セルフホストランナーと共有されます。 組織で使用しているランナーの同時実行制限がわからない場合は、CircleCI の担当者にお問い合わせいただくか、 サポートチケット をお送りください。

リモート Docker または Docker in Docker (DIND) を介してコンテナエージェントで Docker イメージをビルドすることは可能ですか。

現在、コンテナエージェントを使ったコンテナイメージのビルド (例: setup_remote_docker) はサポートされていません。

Docker in Docker は、クラスタに対するセキュリティリスクを招く可能性があるため推奨されません。 現時点では、既存の machine セルフホストランナーを使用した専用の VM を使ってワークフローで Docker イメージをビルドするか、CircleCI がホストするコンピューティング環境を使用するか、または Podman などのテクノロジーを使用することをお勧めします。

Kubernetes 以外をコンテナエージェントで使用できますか。

現時点ではできません。 Kubernetes と Helm をご使用いただく必要があります。

コンテナエージェントでは特定の Kubernetes プロバイダを使用する必要がありますか。

現時点ではその必要はありません。

既存の Kubernetes ランナーとコンテナエージェントの違いは何ですか。

既存の Kubernetes ランナー

既存の Kubernetes ランナーは launch-agent (CircleCI の作業のポーリングを担当するコンポーネント) を Kubernetes で実行します。 これは、VM 上で実行しているかのように、同じポッド内で task-agent (作業の実行を担当するコンポーネント) を実行します。

task-agent は、Kubernetes 上で実行しているかどうかを認識しません。

従来の Kubernetes ランナーは今でも launch-agenttask-agent を 1 対 1 で使用しています。

コンテナエージェント

コンテナエージェントは Kubernetes を認識し、これを使用して task-agent のスケジュールを設定します。 これらは別々のポッドで実行され、コンテナエージェントとタスクエージェントは 1 対多の関係で使用されます。

コンテナエージェントは、ポッドをデプロイしたクラスタに置く必要がありますか。

現時点ではそのとおりです。

コンテナエージェントをインストールできるプラットフォームを教えてください。

現時点で、コンテナエージェント自体とタスクを実行するポッドの両方の amd64 Linux で amd64 Linux または arm64 Linux を使用できます。

コンテナエージェントは arm64 Docker イメージをサポートしていますか?

はい、コンテナエージェントは amd64 イメージや arm64 Docker イメージを使用するジョブ、および amd64 ノードや arm64 ノードが混在する Kubernetes クラスタを使用するジョブをサポートしています。 特定のアーキテクチャ用にビルドされたイメージを使用する場合、その CPU アーキテクチャを持つノードをターゲットにするようにリソースクラスを設定する必要があります。 Kubernetes では複数のノードラベルが自動的に用意され、ジョブのリソースクラスのポッド仕様が正しいノードにデプロイされるように設定する際に役立ちます。 下記の例はリソースクラスの設定例です。 これらのラベルの詳細については、 Kubernetes のドキュメント を参照してください。

agent:
   resourceClasses:
      <amd64 image resource class>:
         token: <amd64 resource class token>
         spec:
            nodeSelector: # nodeSelector will cause this resource class to only create pods on nodes with the specified labels and values
               kubernetes.io/arch=amd64

      <arm64 image resource class>:
         token: <arm64 resource class token>
         spec:
            nodeSelector:
               kubernetes.io/arch=arm64

      <multiarchitecture image resource class>: # note no nodeSelector is defined for the multiarchitecture image resource class
         token: <multiarchitecture resource class token>

ライフサイクルフックを使用して、コンテナエージェントから Kubernetes クラスタの他の部分にメッセージを送信する方法はありますか。

現時点ではありません。

コンテナエージェントのアンインストール方法を教えてください。

container-agent デプロイをアンインストールするには、次を実行します。

$ helm uninstall container-agent

このコマンドは、チャートに関連付けられた Kubernetes オブジェクトをすべて削除し、リリースを削除します。

コンテナエージェントは、CircleCI の既存のセルフホストランナーの代わりとなる機能ですか。

いいえ。コンテナエージェントは、既存の machine セルフホストランナーを補完する製品です。 コンテナエージェントと既存の machine セルフホストランナーが両方あることで、CircleCI ユーザーは、CircleCI のクラウドプラットフォームの場合と同じように、実行環境を柔軟に選べます (Docker または Machine)。

agent.ReplicaCount を増やすとどうなりますか。

現時点では、Kubernetes が追加のコンテナエージェントをデプロイしようとします。 このシナリオはテストがまだ完了しておらず、期待どおりに動作しない可能性があるため、現時点では推奨されません。

1 つの Kubernetes クラスタに 2 つのコンテナエージェントをデプロイした場合、 agent.maxConcurrentTasks パラメーターはどのように適用されますか。

agent.maxConcurrentTasks パラメーターは、各エージェントに個別に適用されます。 ただし、1 つの Kubernetes クラスタに複数のコンテナエージェントをデプロイすることは、現時点では推奨されません。

オープンプレビューの間に、コンテナエージェントの機能が更新される可能性はありますか。

はい。この製品では現在も開発が進んでいます。 コンテナエージェント自体への更新は、自動的にデプロイされているコンテナエージェントに及ぶはずです。 ご利用中のお客様に行っていただく操作はありません。

Helm チャートに対する更新内容は、次のコマンドを使用して 適用 できます。

$ helm repo update
$ helm upgrade container-agent

大幅な機能変更があった場合は、このページの内容を更新いたします。

コンテナエージェントについてセキュリティ上の注意事項はありますか。

コンテナエージェントでは、既存のセルフホストランナーと同じく、コンテナエージェントをホストするインフラストラクチャ内でユーザーが任意のコードを実行できます。つまり、悪意のある攻撃者がこれを悪用して内部システムの知識を得て、インフラストラクチャに侵入する可能性があります。 このリスクを軽減するため、セキュリティ上のベストプラクティスに従ってください。

コンテナエージェントを使った設定例の完全版はありますか。

version: 2.1

jobs:
  build:
    docker:
      - image: cimg/base:2021.11
        auth:
          username: mydockerhub-user
          password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
    resource_class: <namespace>/<resource-class>
    steps:
      - checkout
      - ...

workflows:
  build-workflow:
    jobs:
      - build

ドキュメントの改善にご協力ください

このガイドは、CircleCI の他のドキュメントと同様にオープンソースであり、 GitHub でご利用いただけます。 ご協力いただき、ありがとうございます。

サポートが必要ですか

CircleCI のサポートエンジニアによる、サービスに関する問題、請求およびアカウントについての質問への対応、設定の構築に関する問題解決のサポートを行っています。 サポートチケットを送信して、CircleCI のサポートエンジニアにお問い合わせください。日本語でお問い合わせいただけます。

または、 サポートサイト から、サポート記事やコミュニティフォーラム、トレーニングリソースをご覧いただけます。