marcoderama
diff --git a/‎jekyll/_cci2_ja/server-3-operator-backup-and-restore.adoc
Lines changed: 12 additions & 18 deletions b/‎jekyll/_cci2_ja/server-3-operator-backup-and-restore.adoc
Lines changed: 12 additions & 18 deletions
diff --git a/‎jekyll/_cci2_ja/server-3-operator-metrics-and-monitoring.adoc
Lines changed: 0 additions & 6 deletions b/‎jekyll/_cci2_ja/server-3-operator-metrics-and-monitoring.adoc
Lines changed: 0 additions & 6 deletions
diff --git a/‎jekyll/_cci2_ja/server/operator/backup-and-restore.adoc
Lines changed: 2 additions & 1 deletion b/‎jekyll/_cci2_ja/server/operator/backup-and-restore.adoc
Lines changed: 2 additions & 1 deletion
diff --git a/‎jekyll/_cci2_ja/using-docker.md
Lines changed: 9 additions & 7 deletions b/‎jekyll/_cci2_ja/using-docker.md
Lines changed: 9 additions & 7 deletions
@@ -1,5 +1,4 @@
 ---
-
 contentTags:
   platform:
   - Server v3.x
@@ -12,20 +11,19 @@ contentTags:
 :page-description: このドキュメントでは、CircleCI Server のインスタンスデータと状態のバックアップと復元方法についての推奨事項を説明します。
 :icons: font
 :toc: macro
-
 :toc-title:
 
 toc::[]
 
 == 概要
-
 _バックアップと復元は、CircleCI Server v3.1.0 以上で利用できます。_
 
 CircleCI Server の運用と管理においては、別のクラスタへの移行や深刻な事象からの復元が必要な事態を想定して、バックアップを維持し、システムを復元する方法を検討する必要があります。
 
 このドキュメントでは、CircleCI Server のインスタンスデータと状態のバックアップと復元方法についての推奨事項を説明します。
 
-CircleCI Server は、 https://kots.io/[KOTS] を使用して管理します。KOTS では、バックアップと復元に https://velero.io/[Velero] を使用しています。 この方法のメリットは、アプリケーションのデータだけでなく、バックアップ時点の Kubernetes クラスタの状態とリソースも復元することです。
+CircleCI Server は、 https://kots.io/[KOTS] を使用して管理します。KOTS では、バックアップと復元に https://velero.io/[Velero] を使用しています。 
+この方法のメリットは、アプリケーションのデータだけでなく、バックアップ時点の Kubernetes クラスタの状態とリソースも復元することです。
 つまり、管理者コンソールの設定や、クラスタに加えたカスタマイズ内容も復元できるのです。
 
 NOTE: CircleCI サービスのバックアップと復元は、Velero に依存しています。 クラスタが失われた場合、そのクラスタ内の Velero が正常に起動するまで、CircleCI を復元することはできません。 Velero が正常に起動すれば、CircleCI サービスを復元できます。
@@ -62,7 +60,6 @@ CircleCI Server のバックアップは、 https://kots.io/[KOTS] を介して
 * AWS SETUP *
 
 ////
-
 == AWS での CircleCI Server 3.x のバックアップ
 
 以下の手順では、プロバイダーが AWS であり、上記の <<prerequisites, 前提条件>> を満たしていることを前提としています。
@@ -80,7 +77,6 @@ aws s3api create-bucket \
     --create-bucket-configuration LocationConstraint=$REGION
 ----
-
 NOTE: `us-east-1` では、 https://docs.aws.amazon.com/AmazonS3/latest/API/API_CreateBucket.html#API_CreateBucket_RequestBody[LocationConstraint] がサポートされていません。 `us-east-1` リージョンを使用している場合、バケットの設定は省略してください。
 
 === 手順 2 - Velero の権限の設定
@@ -155,7 +151,6 @@ aws iam create-access-key --user-name velero
 ----
 
 このコマンドの結果は以下のようになります。
-
 [source,json]
 ----
 {
@@ -177,16 +172,14 @@ aws iam create-access-key --user-name velero
 aws_access_key_id=<AWS_ACCESS_KEY_ID>
 aws_secret_access_key=<AWS_SECRET_ACCESS_KEY>
 ----
-
 ここで、`AWS_ACCESS_KEY_ID` プレースホルダーと `AWS_SECRET_ACCESS_KEY` プレースホルダーには、前の手順の `create-access-key` リクエストで返された値を指定します。
 
 === 手順 3 - Velero のインストールと起動
 
 * 以下の `velero install` コマンドを実行します。 これにより、`velero` という名前空間が作成され、Velero を実行するのに必要なリソースがすべてインストールされます。
 必ず <<Step 2 - Setup permissions for Velero, 手順 2>> で作成した、AWS 認証情報が含まれる正しいファイル名を指定してください。
 
-NOTE: KOTS のバックアップには、 https://restic.net/[restic] が必要です。
- Velero のインストール時に、以下に示すように `--use-restic` フラグを設定してください。
+NOTE: KOTS のバックアップには、 https://restic.net/[restic] が必要です。Velero のインストール時に、以下に示すように `--use-restic` フラグを設定してください。
 
 [source, bash]
 ----
@@ -247,27 +240,30 @@ CircleCI Server を GKE クラスタ内で実行している場合、RBAC オブ
 ----
 gcloud config list
 ----
+
 . プロジェクトが適切に参照されていれば、以下のように変数を設定します。
 +
 [source,bash]
 ----
 PROJECT_ID=$(gcloud config get-value project)
 ----
+
 . 以下のコマンドを実行して、サービス アカウントを作成します。
 +
 [source,bash]
 ----
 gcloud iam service-accounts create velero \
     --display-name "Velero service account"
 ----
-+
 NOTE: Velero がインストールされたクラスタを複数実行している場合は、サービスアカウントに対して、上記の例で示している `velero` ではなく、具体的な名前を付けることをお勧めします。
+
 . 以下のコマンドを実行して、サービスアカウントが正常に作成されたことを確認します。
 +
 [source,bash]
 ----
 gcloud iam service-accounts list
 ----
+
 . 次に、サービスアカウントの電子メール アドレスを変数に格納します。
 +
 [source,bash]
@@ -276,8 +272,8 @@ SERVICE_ACCOUNT_EMAIL=$(gcloud iam service-accounts list \
   --filter="displayName:Velero service account" \
   --format 'value(email)')
 ----
-+
 サービスアカウントに付けた表示名に合わせて、必要に応じてコマンドを変更してください。
+
 . 必要な権限をサービスアカウントに付与します。
 +
 [source,bash]
@@ -310,18 +306,17 @@ gsutil iam ch serviceAccount:$SERVICE_ACCOUNT_EMAIL:objectAdmin gs://${BUCKET}
 ==== オプション 1: JSON キー ファイル
 
 サービスアカウントとしてアクションを実行できるように Velero を認証するには、JSON 認証情報ファイルを Velero に渡します。 それにはまず、以下のコマンドを実行してキーを作成します。
-
 [source,bash]
 ----
 gcloud iam service-accounts keys create credentials-velero \
     --iam-account $SERVICE_ACCOUNT_EMAIL
 ----
-
 このコマンドを実行すると、`credentials-velero` という名前のファイルがローカル作業ディレクトリに作成されます。
 
 ==== オプション 2: Workload Identity
 
-クラスタで既に https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity[Workload Identity] を使用している場合は、先ほど作成した GCP サービスアカウントを Velero の Kubernetes サービスアカウントにバインドします。 この場合、GCP サービスアカウントには、上記で指定済みの権限に加え、`iam.serviceAccounts.signBlob` ロールも必要です。
+クラスタで既に https://cloud.google.com/kubernetes-engine/docs/how-to/workload-identity[Workload Identity] を使用している場合は、先ほど作成した GCP サービスアカウントを Velero の Kubernetes サービスアカウントにバインドします。 
+この場合、GCP サービスアカウントには、上記で指定済みの権限に加え、`iam.serviceAccounts.signBlob` ロールも必要です。
 
 === 手順 3 - Velero のインストールと起動
 
@@ -379,7 +374,6 @@ restic はデーモンセットなので、Kubernetes クラスタ内のノー
 * S3-COMPATIBLE SETUP *
 
 ////
-
 == S3 互換ストレージでの CircleCI Server 3.x のバックアップ
 
 以下の手順では、S3 互換オブジェクトストレージ (AWS S3 に限らない) をバックアップに使用していることが前提です。
@@ -391,6 +385,7 @@ restic はデーモンセットなので、Kubernetes クラスタ内のノー
 
 最初に、ストレージ プロバイダーに接続できるよう https://docs.min.io/minio/baremetal/reference/minio-mc.html[`mc`] を設定します。
 
+
 [source,bash]
 ----
 # エイリアスは任意の名前でかまいませんが、以降のコマンドでも同じ値を使用してください。
@@ -458,8 +453,7 @@ aws_secret_access_key=<YOUR_VELERO_SECRET_ACCESS_KEY>
 
 以下の `velero install`  コマンドを実行します。 これにより、`velero` という名前空間が作成され、Velero を実行するのに必要なリソースがすべてインストールされます。
 
-NOTE: KOTS のバックアップには、 https://restic.net/[restic] が必要です。
- Velero のインストール時に、以下に示すように `--use-restic` フラグを設定してください。
+NOTE: KOTS のバックアップには、 https://restic.net/[restic] が必要です。Velero のインストール時に、以下に示すように `--use-restic` フラグを設定してください。
 
 [source, bash]
 ----
 
@@ -11,7 +11,6 @@ contentTags:
 :page-description: CircleCI Server 環境のメトリクスの収集と監視について
 :icons: font
 :toc: macro
-
 :toc-title:
 
 CPU やメモリの使用率などのメトリクス、および内部メトリクスを使用すると以下が可能になります。
@@ -25,34 +24,29 @@ toc::[]
 == メトリクスの収集
 
 === スコープ
-
 CircleCI Server では、システムのヘルス状態の監視や、システムの問題のデバッグに役立つ各種メトリクスとログをデフォルトで収集します。
 
 NOTE: データは最大 15 日間保持されます。
 
 NOTE: Prometheus のメトリクスの収集範囲は、CircleCI Server のみに限定されていません。 デフォルトでは、クラスタ全体からメトリクスを収集します。 必要に応じて、KOTS 管理者コンソールの [Config (設定)] から Prometheus を無効にできます。
 
 === Prometheus
-
 https://prometheus.io/[Prometheus] は、Kubernetes 用の優れた監視およびアラートシステムです。 CircleCI Server 3.x には、一般的なパフォーマンスメトリクスの監視が実装されています。
 
 WARNING: Prometheus の機能は、KOTS バージョン 1.65.0 - 1.67.0 で 破損しています。 この機能に依存している場合は、この問題が解決されるまで、KOTS のバージョンをアップグレードしないことをお勧めします。
 
 === KOTS 管理者 - メトリクス グラフ
-
 デフォルトでは、Prometheus インスタンスは CircleCI Server と一緒にデプロイされます。 デプロイ後、Prometheus インスタンスのアドレスを KOTS 管理者コンソールに追加できます。 KOTS ではこのアドレスを使用して、クラスタに含まれるコンテナの CPU とメモリ使用率のグラフデータを生成します。
 
 デフォルトの Prometheus アドレスは、`\http://prometheus-server` です。
 
 KOTS ダッシュボードの [Configure graphs (グラフの設定)] を選択します。 `\http://prometheus-server` と入力すると、KOTS でリソース使用率グラフが生成されます。
 
 === Telegraf
-
 CircleCI Server 上で実行されるほとんどのサービスは、サーバーで実行されている https://www.influxdata.com/time-series-platform/telegraf/[Telegraf] ポッドに StatsD メトリクスを報告します。
 この設定は完全にカスタマイズ可能で、 https://docs.influxdata.com/telegraf/v1.17/plugins/#output-plugins[出力プラグイン] を介して、Telegraf でサポートされている任意の出力先に Telegraf のメトリクスを転送できます。 デフォルトでは、Prometheus で収集するためのメトリクスエンドポイントが提供されます。
 
 === Telegraf から Datadog へのメトリクスの転送
-
 以下に、Telegraf から Datadog にメトリクスを出力する設定方法の例を示します。
 
 . 管理コンソールダッシュボードを開いて、メニューバーの **Config (設定)** を選択します。
 
@@ -1,5 +1,4 @@
 ---
-
 version:
 - Server v4.x
 - サーバー管理者
@@ -29,6 +28,8 @@ NOTE: CircleCI サービスのバックアップと復元は、Velero に依存
 [#creating-backups]
 == バックアップの作成
 
+[source,bash]
+
 ----
 K8S_NS=$(helm list -o yaml  | yq '.[].namespace')
 CHART=$(helm list -o yaml  | yq '.[].chart' )
 
@@ -10,7 +10,9 @@ contentTags:
     - Server v2.x
 ---
 
-[custom-images]: {{ site.baseurl }}/ja/custom-images/ [building-docker-images]: {{ site.baseurl }}/ja/building-docker-images/ [server-gpu]: {{ site.baseurl }}/ja/gpu/
+[custom-images]: {{ site.baseurl }}/ja/custom-images/
+[building-docker-images]: {{ site.baseurl }}/ja/building-docker-images/
+[server-gpu]: {{ site.baseurl }}/ja/gpu/
 
 **プレフィックスが「 circleci/ 」のレガシーイメージは、 2021 年 12 月 31 日に[サポートが終了](https://discuss.circleci.com/t/legacy-convenience-image-deprecation/41034)**しています。 ビルドを高速化するには、[次世代の CircleCI イメージ](https://circleci.com/blog/announcing-our-next-generation-convenience-images-smaller-faster-more-deterministic/)を使ってプロジェクトをアップグレードしてください。
 {: class="alert alert-warning"}
@@ -104,14 +106,14 @@ jobs:
 ## Docker のメリットと制限事項
 {: #docker-benefits-and-limitations }
 
-Docker にはもともとイメージのキャッシュ機能があり、\[リモート Docker\]\[building-docker-images\] を介した Docker イメージのビルド、実行、パブリッシュを可能にしています。 開発しているアプリケーションで Docker を利用する必要があるかどうか、再確認してください。 アプリケーションが下記内容に合致するなら、Docker を使うと良いでしょう。
+Docker にはもともとイメージのキャッシュ機能があり、[リモート Docker][building-docker-images] を介した Docker イメージのビルド、実行、パブリッシュを可能にしています。 開発しているアプリケーションで Docker を利用する必要があるかどうか、再確認してください。 アプリケーションが下記内容に合致するなら、Docker を使うと良いでしょう。
 
 - 自己完結型のアプリケーションである.
 - テストのために他のサービスが必要なアプリケーションである.
-- アプリケーションが Docker イメージとして配布される (\[リモート Docker\]\[building-docker-images\] の使用が必要)。
-- `docker-compose` を使用したい (\[リモート Docker\]\[building-docker-images\] の使用が必要)。
+- アプリケーションが Docker イメージとして配布される ([リモート Docker][building-docker-images] の使用が必要)。
+- `docker-compose` を使用したい ([リモート Docker][building-docker-images] の使用が必要)。
 
-Docker を使うと、Docker コンテナのなかで可能な範囲の機能に実行が制限されることになります (CircleCI における \[リモート Docker\]\[building-docker-images\] の機能も同様です)。 たとえば、ネットワークへの低レベルアクセスが必要な場合や、外部ボリュームをマウントする必要がある場合は、`machine` の使用を検討してください。
+Docker を使うと、Docker コンテナのなかで可能な範囲の機能に実行が制限されることになります (CircleCI における [リモート Docker][building-docker-images] の機能も同様です)。 たとえば、ネットワークへの低レベルアクセスが必要な場合や、外部ボリュームをマウントする必要がある場合は、`machine` の使用を検討してください。
 
 コンテナ環境として `docker` イメージを使用する場合と、Ubuntu ベースの `machine` イメージを使用する場合では、下表のような違いがあります。
 
@@ -131,9 +133,9 @@ Docker を使うと、Docker コンテナのなかで可能な範囲の機能に
 | [構成可能なリソース (CPU/RAM)]({{ site.baseurl }}/ja/configuration-reference/#resource_class) | はい                | はい        |
 {: class="table table-striped"}
 
-<sup>(1)</sup> \[カスタム Docker イメージの使用\]\[custom-images\] を参照してください。
+<sup>(1)</sup> [カスタム Docker イメージの使用][custom-images] を参照してください。
 
-<sup>(2)</sup> \[リモート Docker\]\[building-docker-images\] を使用する必要があります。
+<sup>(2)</sup> [リモート Docker][building-docker-images] を使用する必要があります。
 
 <sup>(3)</sup> Docker で複数のデータベースを実行することもできますが、その場合、すべてのイメージ (プライマリおよびセカンダリ) の間で、基になるリソース制限が共有されます。 このときのパフォーマンスは、ご契約のコンテナ プランで利用できるコンピューティング能力に左右されます。