Update translation of LXD 5.6 (Closes #231)

Signed-off-by: Hiroaki Nakamura <[email protected]>
lxc-jp · Sep 27, 2022 · d9d4054 · d9d4054
1 parent 440a017
commit d9d4054
Show file tree

Hide file tree

Showing 85 changed files with 2,135 additions and 1,069 deletions.
diff --git a/README.md b/README.md
@@ -1,12 +1,21 @@
 [![LXD](https://linuxcontainers.org/static/img/containers.png)](https://linuxcontainers.org/ja/lxd/)
 
-<!-- Include start LXD intro -->
 # LXD
+
+<!-- Include start LXD intro -->
+
 LXDは、次世代のシステムコンテナおよび仮想マシンマネージャです。
+
 コンテナや仮想マシンの中で動作する完全なLinuxシステムに統一されたユーザーエクスペリエンスを提供します。
+LXD は [数多くの Linuxディストリビューション](https://images.linuxcontainers.org) のイメージを提供しており、非常にパワフルでありながら、それでいてシンプルなREST APIを中心に構築されています。
+LXD は単一のマシン上の単一のインスタンスからデータセンターのフルラック内のクラスタまでスケールし、開発とプロダクションの両方のワークロードに適しています。
+
+LXD を使えば小さなプライベートクラウドのように感じられるシステムを簡単にセットアップできます。
+あなたのマシン資源を最適に利用しながら、あらゆるワークロードを効率よく実行できます。
 
-LXDはイメージベースで、[多くのLinuxディストリビューション](https://images.linuxcontainers.org)に対応しています。
-そして、非常にパワフルでありながら、非常にシンプルなREST APIを中心に構築されています。
+さまざまな環境をコンテナ化したい場合や仮想マシンを稼働させたい場合、あるいは一般にあなたのインフラを費用効率よく稼働および管理したい場合には LXD を使うのを検討するのがお勧めです。
+
+## 使い始めるには
 
 LXDとは何か、何ができるのか、より良いアイデアを得るためには、[オンラインで試す](https://linuxcontainers.org/ja/lxd/try-it/)ことができます!
 また、ローカルで動作させたい場合は、[LXDを使い始めるには](https://linuxcontainers.org/ja/lxd/getting-started-cli/)をご覧ください。
@@ -30,6 +39,7 @@ Goドキュメント     | Godoc              | [![GoDoc](https://godoc.org/gith
 <!-- Include start installing -->
 
 ## パッケージからのLXDのインストール
+
 LXDのデーモンはLinuxでしか動作しませんが、クライアントツール(`lxc`)はほとんどのプラットフォームで利用可能です。
 
 OS      | フォーマット                                      |コマンド

diff --git a/doc/README.md b/doc/README.md
@@ -1,6 +1,6 @@
 # LXD ドキュメント
 
-LXDの日本語ドキュメントは、https://lxd-ja.readthedocs.io/ja/latest/ で閲覧できます。
+LXDの日本語ドキュメントは、 <https://lxd-ja.readthedocs.io/ja/latest/> (原文のドキュメントは <https://linuxcontainers.org/lxd/docs/latest/>) で閲覧できます。
 
 GitHubでもドキュメントの基本的なレンダリングを提供していますが、includeやクリッカブルリンクなどの重要な機能が欠落しています。そのため、[公開ドキュメント](https://lxd-ja.readthedocs.io/ja/latest/)を読むことをお勧めします。
 
@@ -14,4 +14,4 @@ GitHubでもドキュメントの基本的なレンダリングを提供して
 
 ドキュメントをビルドするには、リポジトリのルートフォルダから `make doc` を実行します。このコマンドは必要なツールをインストールして、出力を `doc/html/` フォルダにレンダリングします。変更されたファイルのみを対象にドキュメントを更新するには（ツールを再インストールすることなく）、`make doc-incremental`を実行します。
 
-ビルド後、`make doc-serve`を実行して、http://localhost:8001、レンダリングされたドキュメントを見ることができます。
+ビルド後、`make doc-serve`を実行して、<http://localhost:8001>、レンダリングされたドキュメントを見ることができます。
diff --git a/doc/api-extensions.md b/doc/api-extensions.md
diff --git a/doc/architectures.md b/doc/architectures.md
@@ -1,6 +1,7 @@
 # アーキテクチャ
 
 ## イントロダクション
+
 LXD はちょうど LXC と同じように Linux カーネルと Go でサポートされる
 あらゆるアーキテクチャで稼働することができます。
 
@@ -11,7 +12,6 @@ LXD はちょうど LXC と同じように Linux カーネルと Go でサポー
 （データベースで使われる）ユニークな識別子、それらがどのように名前付け
 されるべきかといくつかの注釈をリストアップします。
 
-
 LXD が問題とするのはカーネルアーキテクチャであり、ツールチェインで
 決定される特定のユーザースペースのフレーバーではないことに注意してください。
 

diff --git a/doc/authentication.md b/doc/authentication.md
@@ -15,7 +15,6 @@ LXDデーモンとのリモート通信は、HTTPS上のJSONを使って行わ
 - {ref}`authentication-candid`
 - {ref}`authentication-rbac`
 
-
 (authentication-tls-certs)=
 ## TLSクライアント証明書
 
@@ -55,6 +54,7 @@ LXDサーバが信頼するTLS証明書のリストは、`lxc config trust list`
 1. ユーザーが `lxc remote add` でサーバーを追加すると、HTTPS でサーバーに接続され、その証明書がダウンロードされ、フィンガープリントがユーザーに表示されます。
 1. ユーザーは、これが本当にサーバーのフィンガープリントであることを確認するよう求められます。これは、サーバーに接続して手動で確認するか、サーバーにアクセスできる人に info コマンドを実行してフィンガープリントを比較してもらうことで確認できます。
 1. サーバーはクライアントの認証を試みます。
+
    - クライアント証明書がサーバーのトラストストアにある場合は、接続が許可されます。
    - クライアント証明書がサーバーのトラストストアにない場合、サーバーはユーザーにトークンまたはトラストパスワードの入力を求めます。
      提供されたトークンまたはトラストパスワードが一致した場合、クライアント証明書はサーバーのトラストストアに追加され、接続が許可されます。
@@ -178,8 +178,8 @@ Candidベースの認証と組み合わせることで、{abbr}`RBAC (Role Based
 
 以下のような場合、サーバーの証明書が変更されている可能性があります。
 
- * サーバを完全に再インストールしたため、新しい証明書が発行された。
- * 接続が傍受されている（{abbr}`MITM (Machine in the middle)`）。
+- サーバを完全に再インストールしたため、新しい証明書が発行された。
+- 接続が傍受されている（{abbr}`MITM (Machine in the middle)`）。
 
 このような場合、クライアントは、証明書のフィンガープリントが、このリモート用の設定にあるフィンガープリントと一致しないため、サーバーへの接続を拒否します。
 

diff --git a/doc/backup.md b/doc/backup.md
@@ -2,8 +2,11 @@
 discourse: 11296
 ---
 
+(backups)=
 # LXD サーバをバックアップする
+
 ## 何をバックアップするか
+
 LXD サーバのバックアップを計画する際は、 LXD に保管／管理されている
 全ての異なるオブジェクトについて考慮してください。
 
@@ -21,6 +24,7 @@ LXD サーバのバックアップを計画する際は、 LXD に保管／管
 使用している LXD の全ての異なるピースを考慮してください。
 
 ## フルバックアップ
+
 フルバックアップは `/var/lib/lxd` あるいは snap ユーザーの場合は `/var/snap/lxd/common/lxd` の全体を含みます。
 
 LXD が外部ストレージを使用している場合はそれらも適切にバックアップする
@@ -38,6 +42,7 @@ snap パッケージを使っておらず、かつシステムに `/etc/subuid`
 その後再び LXD を起動し、全てが正常に動作するか確認してください。
 
 ## LXD サーバのセカンダリバックアップ
+
 LXD は 2 つのホスト間でインスタンスとストレージボリュームのコピーと移動を
 サポートしています。
 
@@ -47,6 +52,7 @@ LXD は 2 つのホスト間でインスタンスとストレージボリュー
 インスタンスをコピーして戻すことができます。
 
 ## インスタンスのバックアップ
+
 `lxc export` コマンドがインスタンスをバックアップの tarball にエクスポートする
 のに使えます。これらの tarball はデフォルトで全てのスナップショットを含みますが、
 同じストレージプールバックエンドを使っている LXD サーバにリストアすることが
@@ -60,6 +66,7 @@ LXD 側でのバリデーションはなく、 LXD から実行可能で `-c`
 戻すことができます。
 
 ## ディザスタリカバリ
+
 LXD は `lxd recover` コマンドを提供しています（通常の `lxc` コマンドではなく `lxd` コマンドであることに注意）。
 これはインタラクティブな CLI ツールでデータベース内に存在する全てのストレージプールをスキャンしリカバリー可能な焼失したボリュームを探します。
 また（ディスク上には存在するがデータベース内には存在しない）任意の未知のストレージプールの詳細をユーザーが指定してそれらに対してもスキャンを試みることもできます。

diff --git a/doc/cloud-init.md b/doc/cloud-init.md
@@ -91,6 +91,7 @@ cloud-init は `user-data` (と `vendor-data`) セクションをパッケージ
 * `/var/lib/cloud/instance/user-data.txt`
 
 #### インスタンス作成時にパッケージをアップグレードする
+
 インスタンス用のレポジトリからパッケージのアップグレードをトリガーするには `package_upgrade` キーを使用します。
 
 ```yaml
@@ -101,6 +102,7 @@ config:
 ```
 
 #### インスタンス作成時にパッケージをインストールする
+
 インスタンスをセットアップするときに特定のパッケージをインストールするには `packages` キーを使用しパッケージ名をリストで指定します。
 
 ```yaml
@@ -113,6 +115,7 @@ config:
 ```
 
 #### インスタンス作成時にタイムゾーンを設定する
+
 インスタンスのタイムゾーンを設定するには `timezone` キーを使用します。
 
 ```yaml
@@ -123,6 +126,7 @@ config:
 ```
 
 #### コマンドを実行する
+
 (マーカーファイルを書き込むなど) コマンドを実行するには `runcmd` キーを使用しコマンドをリストで指定します。
 
 ```yaml
@@ -134,6 +138,7 @@ config:
 ```
 
 #### ユーザーアカウントを追加する
+
 ユーザーアカウントを追加するには `user` キーを使用します。デフォルトユーザとどのキーがサポートされるかについての詳細は [ドキュメント](https://cloudinit.readthedocs.io/en/latest/topics/examples.html#including-users-and-groups) を参照してください。
 
 ```yaml
@@ -146,7 +151,7 @@ config:
 
 ### カスタムネットワーク設定
 
-cloud-init は、`network-config` データを使い、Ubuntu リリースに応じて
+`cloud-init` は、`network-config` データを使い、Ubuntu リリースに応じて
 `ifupdown` もしくは `netplan` のどちらかを使って、システム上の関連する設定
 を行います。
 

diff --git a/doc/clustering.md b/doc/clustering.md
@@ -43,6 +43,7 @@ lxc cluster add <new member name>
 参加トークンは持っていないがトラスト・パスワードを持っている場合は参加トークンを持っているかの質問に `no` と答えます。その後クラスタ内の既存のノードのアドレスを 1 つ選び表示されたフィンガープリントが既存メンバーのクラスタ証明書にマッチするかをチェックします。
 
 ### サーバごとの設定
+
 上で述べたように LXD のクラスタメンバーはたいていは同一のシステムであると想定されます。
 
 しかしディスクの多少の順序の違いやネットワークインターフェースの名前が違いに適応するため、 LXD は一部の設定をサーバごとに記録します。
@@ -384,7 +385,6 @@ LXD はイメージを複製します。これは通常はクラスタ内で最
 
 特別な値である "-1" は全てのノードにイメージをコピーするために使用できます。
 
-
 この数を 1 に設定することでイメージの複製を無効にできます。
 
 ```bash
@@ -496,6 +496,7 @@ lxc config set core.https_address my.lxd.cluster:8443
 なるでしょう。
 
 ## クラスタ証明書の更新
+
 LXD のクラスタ内の全てのサーバは同じ共有された証明書で応答します。
 これは通常は有効期限が10年の標準的な自己署名証明書です。
 
@@ -517,6 +518,7 @@ lxc cluster group assign cluster:node1 gpu
 これは `--target` を使うときに `@` の接頭辞を使うことで実現できます。
 
 例
+
 ```bash
 lxc launch ubuntu/22.04 cluster:ubuntu --target=@gpu
 ```

diff --git a/doc/configuration.md b/doc/configuration.md
@@ -1,4 +1,5 @@
 # 設定
+
 LXD は次のコンポーネントの設定を保管しています。
 
 ```{toctree}
@@ -9,6 +10,6 @@ containers
 プリシード YAML <preseed>
 profiles
 プロジェクト <projects>
-サーバ <server>
+サーバ設定 <server>
 仮想マシン <virtual-machines>
 ```
diff --git a/doc/container-environment.md b/doc/container-environment.md
@@ -1,10 +1,12 @@
 # コンテナ実行環境
+
 LXD は実行するコンテナに一貫性のある環境を提供しようとします。
 
 正確な環境はカーネルの機能やユーザーの設定によって若干異なりますが、それ以外は
 全てのコンテナに対して同一です。
 
 ## PID1
+
 LXD は何であれ `/sbin/init` に置かれているものをコンテナの初期プロセス (PID 1) として起動します。
 このバイナリは親が変更されたプロセス (訳注: ゾンビプロセスなど) の処理を含めて適切な init
 システムとして振る舞う必要があります。
@@ -21,6 +23,7 @@ PID1 の初期環境は `container=lxc` 以外は空です。 init システム
 PID1 が起動される前に閉じられます。
 
 ## ファイルシステム
+
 LXD は使用するどのイメージから生成する新規のコンテナは少なくとも以下のファイルシステムを
 含むことを前提とします。
 
@@ -30,6 +33,7 @@ LXD は使用するどのイメージから生成する新規のコンテナは
  - `/sys` (空のディレクトリ)
 
 ## デバイス
+
 LXD のコンテナは `tmpfs` ファイルシステムをベースとする最低限で一時的な `/dev` を
 持ちます。これは `tmpfs` であって `devtmpfs` ではないので、デバイスノードは手動で作成
 されたときのみ現れます。
@@ -57,6 +61,7 @@ LXD のコンテナは `tmpfs` ファイルシステムをベースとする最
  - `/dev/mqueue`
 
 ## マウント
+
 LXD では以下のマウントがデフォルトでセットアップされます。
 
  - `/proc` (`proc`)
@@ -79,17 +84,20 @@ LXD では以下のマウントがデフォルトでセットアップされま
 ですらなく)、特権コンテナ内では LXD の AppArmor ポリシーによってブロックされます。
 
 ## ネットワーク
+
 LXD コンテナはネットワークデバイスをいくつでもアタッチできます。
 これらの名前はユーザーにオーバーライドされない限りは `ethX` で X は
 連番です。
 
 ## コンテナからホストへのコミュニケーション
+
 LXD は `/dev/lxd/sock` にソケットをセットアップし、コンテナ内の root ユーザーはこれを使ってホストの
 LXD とコミュニケーションできます。
 
 API は [ここにドキュメント化されています](dev-lxd.md).
 
 ## LXCFS
+
 ホストに LXCFS がある場合は、コンテナ用に自動的にセットアップされます。
 
 これは通常いくつかの `/proc` ファイルになり、それらは bind mount を通してオーバーライド

diff --git a/doc/containers.md b/doc/containers.md
@@ -3,19 +3,13 @@ discourse: 8767
 ---
 
 # コンテナ
-## イントロダクション
+
 コンテナは LXD のデフォルトタイプであり、現時点では最も完全な LXD インスタンスの実装であり、一番機能が充実しています。
 
 これは `liblxc` (LXC) を使って実装しています。
 
+{ref}`live-migration` は限定的にサポートされています。
+
 ## 設定
-設定オプションについては [インスタンスの設定](instances.md) をご覧ください。
 
-## ライブマイグレーション
-LXD では、[CRIU](http://criu.org) を使ったコンテナのライブマイグレーションが使えます。
-コンテナのメモリ転送を最適化するために、`migration.incremental.memory` プロパティを `true` に設定することで、CRIU の pre-copy 機能を使うように LXD を設定できます。
-つまり、LXD は CRIU にコンテナの一連のメモリダンプを実行するように要求します。
-ダンプが終わると、LXD はメモリダンプを指定したリモートホストに送ります。
-理想的なシナリオでは、各メモリダンプを前のメモリダンプとの差分にまで減らし、それによりすでに同期されたメモリの割合を増やします。
-同期されたメモリの割合が `migration.incremental.memory.goal` で設定した閾値と等しいか超えた場合、LXD は CRIU に最終的なメモリダンプを実行し、転送するように要求します。
-`migration.incremental.memory.iterations` で指定したメモリダンプの最大許容回数に達した後、まだ閾値に達していない場合は、LXD は最終的なメモリダンプを CRIU に要求し、コンテナを移行します。
+設定オプションについては [インスタンスの設定](instances.md) をご覧ください。
diff --git a/doc/contributing.md b/doc/contributing.md
@@ -39,6 +39,6 @@ git push myfork [name_of_your_new_branch]
 - 永続データは `LXD_DIR` ディレクトリに保管されます。これは `lxd init` で作成されます。 `LXD_DIR` のデフォルトは `/var/lib/lxd` か snap ユーザーは `/var/snap/lxd/common/lxd` です。
 - 開発中はバージョン衝突を避けるため LXD のあなたの fork 用に `LXD_DIR` の値を変更すると良いでしょう。
 - あなたのソースからコンパイルされる実行ファイルはデフォルトでは `$(go env GOPATH)/bin` に生成されます。
-    - あなたの変更をテストするときはこれらの実行ファイル（インストール済みかもしれないグローバルの `lxd` ではなく）を明示的に起動する必要があります。
-    - これらの実行ファイルを適切なオプションを指定してもっと便利に呼び出せるように `~/.bashrc` にエイリアスを作るという選択も良いでしょう。
+  - あなたの変更をテストするときはこれらの実行ファイル（インストール済みかもしれないグローバルの `lxd` ではなく）を明示的に起動する必要があります。
+  - これらの実行ファイルを適切なオプションを指定してもっと便利に呼び出せるように `~/.bashrc` にエイリアスを作るという選択も良いでしょう。
 - 既存のインストール済み LXD のデーモンを実行するための `systemd` サービスが設定されている場合はバージョン衝突を避けるためにサービスを無効にすると良いでしょう。