diff --git a/README.md b/README.md index 70dbb57..ad99a54 100644 --- a/README.md +++ b/README.md @@ -1,12 +1,21 @@ [![LXD](https://linuxcontainers.org/static/img/containers.png)](https://linuxcontainers.org/ja/lxd/) - # LXD + + + 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 ## パッケージからのLXDのインストール + LXDのデーモンはLinuxでしか動作しませんが、クライアントツール(`lxc`)はほとんどのプラットフォームで利用可能です。 OS | フォーマット |コマンド diff --git a/doc/README.md b/doc/README.md index e0e3fbb..dfd4fe3 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,6 +1,6 @@ # LXD ドキュメント -LXDの日本語ドキュメントは、https://lxd-ja.readthedocs.io/ja/latest/ で閲覧できます。 +LXDの日本語ドキュメントは、 (原文のドキュメントは ) で閲覧できます。 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`を実行して、、レンダリングされたドキュメントを見ることができます。 diff --git a/doc/api-extensions.md b/doc/api-extensions.md index 14f2cfb..c09f568 100644 --- a/doc/api-extensions.md +++ b/doc/api-extensions.md @@ -3,8 +3,8 @@ それらの変更は全て後方互換であり、 `GET /1.0/` の `api_extensions` を 見ることでクライアントツールにより検出可能です。 - ## `storage_zfs_remove_snapshots` + `storage.zfs_remove_snapshots` というデーモン設定キーが導入されました。 値の型は Boolean でデフォルトは `false` です。 `true` にセットすると、スナップショットを @@ -15,6 +15,7 @@ ZFS でスナップショットの復元が出来るのは最新のスナップ この対応が必要になります。 ## `container_host_shutdown_timeout` + `boot.host_shutdown_timeout` というコンテナ設定キーが導入されました。 値の型は integer でコンテナを停止しようとした後 kill するまでどれだけ @@ -24,6 +25,7 @@ ZFS でスナップショットの復元が出来るのは最新のスナップ デフォルトは 30s です。 ## `container_stop_priority` + `boot.stop.priority` というコンテナ設定キーが導入されました。 値の型は integer でシャットダウン時のコンテナの優先度を指示します。 @@ -33,16 +35,18 @@ ZFS でスナップショットの復元が出来るのは最新のスナップ 同じ優先度のコンテナは並列にシャットダウンします。デフォルトは 0 です。 ## `container_syscall_filtering` + コンテナ設定キーに関するいくつかの新しい syscall が導入されました。 - * `security.syscalls.blacklist_default` - * `security.syscalls.blacklist_compat` - * `security.syscalls.blacklist` - * `security.syscalls.whitelist` +* `security.syscalls.blacklist_default` +* `security.syscalls.blacklist_compat` +* `security.syscalls.blacklist` +* `security.syscalls.whitelist` 使い方は [インスタンスの設定](instances.md) を参照してください。 ## `auth_pki` + これは PKI 認証モードのサポートを指示します。 このモードではクライアントとサーバは同じ PKI によって発行された証明書を使わなければなりません。 @@ -50,6 +54,7 @@ ZFS でスナップショットの復元が出来るのは最新のスナップ 詳細は [セキュリティ](security.md) を参照してください。 ## `container_last_used_at` + `GET /1.0/containers/` エンドポイントに `last_used_at` フィールドが追加されました。 これはコンテナが開始した最新の時刻のタイムスタンプです。 @@ -58,15 +63,16 @@ ZFS でスナップショットの復元が出来るのは最新のスナップ `1970-01-01T00:00:00Z` になります。 ## `etag` + 関連性のある全てのエンドポイントに ETag ヘッダのサポートが追加されました。 この変更により GET のレスポンスに次の HTTP ヘッダが追加されます。 - - ETag (ユーザーが変更可能なコンテンツの SHA-256) +* ETag (ユーザーが変更可能なコンテンツの SHA-256) また PUT リクエストに次の HTTP ヘッダのサポートが追加されます。 - - If-Match (前回の GET で得られた ETag の値を指定) +* If-Match (前回の GET で得られた ETag の値を指定) これにより GET で LXD のオブジェクトを取得して PUT で変更する際に、 レースコンディションになったり、途中で別のクライアントがオブジェクトを @@ -74,14 +80,17 @@ ZFS でスナップショットの復元が出来るのは最新のスナップ 変更できるようになります。 ## `patch` + HTTP の PATCH メソッドのサポートを追加します。 PUT の代わりに PATCH を使うとオブジェクトの部分的な変更が出来ます。 ## `usb_devices` + USB ホットプラグのサポートを追加します。 ## `https_allowed_credentials` + LXD API を全てのウェブブラウザで (SPA 経由で) 使用するには、 XHR の度に 認証情報を送る必要があります。それぞれの XHR リクエストで [`withCredentials=true`](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials) @@ -93,19 +102,23 @@ Firefox や Safari などいくつかのブラウザは `core.https_allowed_credentials=true` と設定してください。 ## `image_compression_algorithm` + この変更はイメージを作成する時 (`POST /1.0/images`) に `compression_algorithm` というプロパティのサポートを追加します。 このプロパティを設定するとサーバのデフォルト値 (`images.compression_algorithm`) をオーバーライドします。 ## `directory_manipulation` + LXD API 経由でディレクトリを作成したり一覧したりでき、ファイルタイプを X-LXD-type ヘッダに付与するようになります。 現状はファイルタイプは `file` か `directory` のいずれかです。 ## `container_cpu_time` + この拡張により実行中のコンテナの CPU 時間を取得できます。 ## `storage_zfs_use_refquota` + この拡張により新しいサーバプロパティ `storage.zfs_use_refquota` が追加されます。 これはコンテナにサイズ制限を設定する際に `quota` の代わりに `refquota` を設定する ように LXD に指示します。また LXD はディスク使用量を調べる際に `used` の代わりに @@ -115,37 +128,42 @@ LXD API 経由でディレクトリを作成したり一覧したりでき、フ みなすかどうかを実質的に切り替えることになります。 ## `storage_lvm_mount_options` + この拡張は `storage.lvm_mount_options` という新しいデーモン設定オプションを 追加します。デフォルト値は `discard` で、このオプションにより LVM LV で使用する ファイルシステムの追加マウントオプションをユーザーが指定できるようになります。 ## `network` + LXD のネットワーク管理 API 。 次のものを含みます。 - * `/1.0/networks` エントリーに `managed` プロパティを追加 - * ネットワーク設定オプションの全て (詳細は [ネットワーク設定](networks.md) を参照) - * `POST /1.0/networks` (詳細は [RESTful API](rest-api.md) を参照) - * `PUT /1.0/networks/` (詳細は [RESTful API](rest-api.md) を参照) - * `PATCH /1.0/networks/` (詳細は [RESTful API](rest-api.md) を参照) - * `DELETE /1.0/networks/` (詳細は [RESTful API](rest-api.md) を参照) - * `nic` タイプのデバイスの `ipv4.address` プロパティ (`nictype` が `bridged` の場合) - * `nic` タイプのデバイスの `ipv6.address` プロパティ (`nictype` が `bridged` の場合) - * `nic` タイプのデバイスの `security.mac_filtering` プロパティ (`nictype` が `bridged` の場合) +* `/1.0/networks` エントリーに `managed` プロパティを追加 +* ネットワーク設定オプションの全て (詳細は [ネットワーク設定](networks.md) を参照) +* `POST /1.0/networks` (詳細は [RESTful API](rest-api.md) を参照) +* `PUT /1.0/networks/` (詳細は [RESTful API](rest-api.md) を参照) +* `PATCH /1.0/networks/` (詳細は [RESTful API](rest-api.md) を参照) +* `DELETE /1.0/networks/` (詳細は [RESTful API](rest-api.md) を参照) +* `nic` タイプのデバイスの `ipv4.address` プロパティ (`nictype` が `bridged` の場合) +* `nic` タイプのデバイスの `ipv6.address` プロパティ (`nictype` が `bridged` の場合) +* `nic` タイプのデバイスの `security.mac_filtering` プロパティ (`nictype` が `bridged` の場合) ## `profile_usedby` + プロファイルを使用しているコンテナをプロファイルエントリーの一覧の `used_by` フィールド として新たに追加します。 ## `container_push` + コンテナが push モードで作成される時、クライアントは作成元と作成先のサーバ間の プロキシとして機能します。作成先のサーバが NAT やファイアウォールの後ろにいて 作成元のサーバと直接通信できず pull モードで作成できないときにこれは便利です。 ## `container_exec_recording` + 新しい Boolean 型の `record-output` を導入します。これは `/1.0/containers//exec` -のパラメータでこれを `true` に設定し `wait-for-websocket` を fales に設定すると +のパラメータでこれを `true` に設定し `wait-for-websocket` を `false` に設定すると 標準出力と標準エラー出力をディスクに保存し logs インタフェース経由で利用可能にします。 記録された出力の URL はコマンドが実行完了したら操作のメタデータに含まれます。 @@ -153,34 +171,41 @@ LXD のネットワーク管理 API 。 出力は他のログファイルと同様に、通常は 48 時間後に期限切れになります。 ## `certificate_update` + REST API に次のものを追加します。 - * 証明書の GET に ETag ヘッダ - * 証明書エントリーの PUT - * 証明書エントリーの PATCH +* 証明書の GET に ETag ヘッダ +* 証明書エントリーの PUT +* 証明書エントリーの PATCH ## `container_exec_signal_handling` + クライアントに送られたシグナルをコンテナ内で実行中のプロセスにフォワーディング するサポートを `/1.0/containers//exec` に追加します。現状では SIGTERM と SIGHUP がフォワードされます。フォワード出来るシグナルは今後さらに追加される かもしれません。 ## `gpu_devices` + コンテナに GPU を追加できるようにします。 ## `container_image_properties` + 設定キー空間に新しく `image` を導入します。これは読み取り専用で、親のイメージのプロパティを 含みます。 ## `migration_progress` + 転送の進捗が操作の一部として送信側と受信側の両方に公開されます。これは操作のメタデータの `fs_progress` 属性として現れます。 ## `id_map` + `security.idmap.isolated`, `security.idmap.isolated`, `security.idmap.size`, `raw.id_map` のフィールドを設定できるようにします。 ## `network_firewall_filtering` + `ipv4.firewall` と `ipv6.firewall` という 2 つのキーを追加します。 `false` に設置すると `iptables` の FORWARDING ルールの生成をしないように なります。 NAT ルールは対応する `ipv4.nat` や `ipv6.nat` キーが `true` に @@ -190,10 +215,12 @@ SIGHUP がフォワードされます。フォワード出来るシグナルは ために必要なルールは常に適用されます。 ## `network_routes` + `ipv4.routes` と `ipv6.routes` を導入します。これらは LXD ブリッジに 追加のサブネットをルーティングできるようにします。 ## `storage` + LXD のストレージ管理 API 。 これは次のものを含みます。 @@ -221,22 +248,28 @@ LXD のストレージ管理 API 。 * 全てのストレージ設定オプション (詳細は [ストレージの設定](storage.md) を参照) ## `file_delete` + `/1.0/containers//files` の DELETE メソッドを実装 ## `file_append` + `X-LXD-write` ヘッダを実装しました。値は `overwrite` か `append` のいずれかです。 ## `network_dhcp_expiry` + `ipv4.dhcp.expiry` と `ipv6.dhcp.expiry` を導入します。 DHCP のリース期限を設定 できるようにします。 ## `storage_lvm_vg_rename` + `storage.lvm.vg_name` を設定することでボリュームグループをリネームできるようにします。 ## `storage_lvm_thinpool_rename` + `storage.thinpool_name` を設定することで thin pool をリネームできるようにします。 ## `network_vlan` + `macvlan` ネットワークデバイスに `vlan` プロパティを新たに追加します。 これを設定すると、指定した VLAN にアタッチするように LXD に指示します。 @@ -245,18 +278,22 @@ LXD はホスト上でその VLAN を持つ既存のインタフェースを探 使用します。 ## `image_create_aliases` + `POST /1.0/images` に `aliases` フィールドを新たに追加します。イメージの 作成／インポート時にエイリアスを設定できるようになります。 ## `container_stateless_copy` + `POST /1.0/containers/` に `live` という属性を新たに導入します。 `false` に設定すると、実行状態を転送しようとしないように LXD に伝えます。 ## `container_only_migration` + `container_only` という Boolean 型の属性を導入します。 `true` に設定すると コンテナだけがコピーや移動されるようになります。 ## `storage_zfs_clone_copy` + ZFS ストレージプールに `storage_zfs_clone_copy` という Boolean 型のプロパティを導入します。 `false` に設定すると、コンテナのコピーは `zfs send` と receive 経由で行われる ようになります。これにより作成先のコンテナは作成元のコンテナに依存しないように @@ -267,6 +304,7 @@ ZFS ストレージプールに `storage_zfs_clone_copy` という Boolean 型 しない限り、空間効率の良いスナップショットが使われます。 ## `unix_device_rename` + `path` を設定することによりコンテナ内部で `unix-block`/`unix-char` デバイスをリネーム できるようにし、ホスト上のデバイスを指定する `source` 属性が追加されます。 `path` を設定せずに `source` を設定すると、 `path` は `source` と同じものとして @@ -275,48 +313,58 @@ ZFS ストレージプールに `storage_zfs_clone_copy` という Boolean 型 設定しなければなりません。 ## `storage_rsync_bwlimit` + ストレージエンティティを転送するために `rsync` が起動される場合に `rsync.bwlimit` を設定すると使用できるソケット I/O の量に上限を 設定します。 ## `network_vxlan_interface` + ネットワークに `tunnel.NAME.interface` オプションを新たに導入します。 このキーは VXLAN トンネルにホストのどのネットワークインタフェースを使うかを 制御します。 ## `storage_btrfs_mount_options` + Btrfs ストレージプールに `btrfs.mount_options` プロパティを導入します。 このキーは Btrfs ストレージプールに使われるマウントオプションを制御します。 ## `entity_description` + これはエンティティにコンテナ、スナップショット、ストレージプール、ボリュームの ような説明を追加します。 ## `image_force_refresh` + 既存のイメージを強制的にリフレッシュできます。 ## `storage_lvm_lv_resizing` + これはコンテナの root ディスクデバイス内に `size` プロパティを設定することで 論理ボリュームをリサイズできるようにします。 ## `id_map_base` + これは `security.idmap.base` を新しく導入します。これにより分離されたコンテナ に map auto-selection するプロセスをスキップし、ホストのどの UID/GID をベース として使うかをユーザーが指定できるようにします。 ## `file_symlinks` + これは file API 経由でシンボリックリンクを転送するサポートを追加します。 X-LXD-type に `symlink` を指定できるようになり、リクエストの内容はターゲットの パスを指定します。 ## `container_push_target` + `POST /1.0/containers/` に `target` フィールドを新たに追加します。 これはマイグレーション中に作成元の LXD ホストが作成先に接続するために 利用可能です。 ## `network_vlan_physical` + `physical` ネットワークデバイスで `vlan` プロパティが使用できるようにします。 設定すると、 `parent` インタフェース上で指定された VLAN にアタッチするように @@ -326,111 +374,139 @@ LXD に指示します。 LXD はホスト上でその `parent` と VLAN を既 その後コンテナにこのインタフェースを直接アタッチします。 ## `storage_images_delete` + これは指定したストレージプールからイメージのストレージボリュームを ストレージ API で削除できるようにします。 ## `container_edit_metadata` + これはコンテナの `metadata.yaml` と関連するテンプレートを `/1.0/containers//metadata` 配下の URL にアクセスすることにより API で編集できるようにします。コンテナからイメージを発行する前にコンテナを 編集できるようになります。 ## `container_snapshot_stateful_migration` + これは stateful なコンテナのスナップショットを新しいコンテナにマイグレート できるようにします。 ## `storage_driver_ceph` + これは Ceph ストレージドライバを追加します。 ## `storage_ceph_user_name` + これは Ceph ユーザーを指定できるようにします。 ## `instance_types` + これはコンテナの作成リクエストに `instance_type` フィールドを追加します。 値は LXD のリソース制限に展開されます。 ## `storage_volatile_initial_source` + これはストレージプール作成中に LXD に渡された実際の作成元を記録します。 ## `storage_ceph_force_osd_reuse` + これは Ceph ストレージドライバに `ceph.osd.force_reuse` プロパティを 導入します。 `true` に設定すると LXD は別の LXD インスタンスで既に使用中の OSD ストレージプールを再利用するようになります。 ## `storage_block_filesystem_btrfs` + これは `ext4` と `xfs` に加えて Btrfs をストレージボリュームファイルシステムとして サポートするようになります。 ## `resources` + これは LXD が利用可能なシステムリソースを LXD デーモンに問い合わせできるようにします。 ## `kernel_limits` + これは `nofile` でコンテナがオープンできるファイルの最大数といったプロセスの リミットを設定できるようにします。形式は `limits.kernel.[リミット名]` です。 ## `storage_api_volume_rename` + これはカスタムストレージボリュームをリネームできるようにします。 ## `external_authentication` + これは Macaroons での外部認証をできるようにします。 ## `network_sriov` + これは SR-IOV を有効にしたネットワークデバイスのサポートを追加します。 ## `console` + これはコンテナのコンソールデバイスとコンソールログを利用可能にします。 ## `restrict_devlxd` + `security.devlxd` コンテナ設定キーを新たに導入します。このキーは `/dev/lxd` インタフェースがコンテナで利用可能になるかを制御します。 `false` に設定すると、コンテナが LXD デーモンと連携するのを実質無効に することになります。 ## `migration_pre_copy` + これはライブマイグレーション中に最適化されたメモリ転送をできるようにします。 ## `infiniband` + これは InfiniBand ネットワークデバイスを使用できるようにします。 ## `maas_network` + これは MAAS ネットワーク統合をできるようにします。 デーモンレベルで設定すると、 `nic` デバイスを特定の MAAS サブネットに アタッチできるようになります。 ## `devlxd_events` + これは `devlxd` ソケットに Websocket API を追加します。 `devlxd` ソケット上で `/1.0/events` に接続すると、 Websocket 上で イベントのストリームを受け取れるようになります。 ## `proxy` + これはコンテナに `proxy` という新しいデバイスタイプを追加します。 これによりホストとコンテナ間で接続をフォワーディングできるようになります。 ## `network_dhcp_gateway` + 代替のゲートウェイを設定するための `ipv4.dhcp.gateway` ネットワーク設定キーを 新たに追加します。 ## `file_get_symlink` + これは file API を使ってシンボリックリンクを取得できるようにします。 ## `network_leases` + `/1.0/networks/NAME/leases` API エンドポイントを追加します。 LXD が管理する DHCP サーバが稼働するブリッジ上のリースデータベースに問い合わせできるように なります。 ## `unix_device_hotplug` + これは Unix デバイスに `required` プロパティのサポートを追加します。 ## `storage_api_local_volume_handling` + これはカスタムストレージボリュームを同じあるいは異なるストレージプール間で コピーしたり移動したりできるようにします。 ## `operation_description` + 全ての操作に `description` フィールドを追加します。 ## `clustering` + LXD のクラスタリング API 。 これは次の新しいエンドポイントを含みます (詳細は [RESTful API](rest-api.md) を参照)。 @@ -446,33 +522,38 @@ LXD のクラスタリング API 。 次の既存のエンドポイントは以下のように変更されます。 - * `POST /1.0/containers` 新しい `target` クエリパラメータを受け付けるようになります。 - * `POST /1.0/storage-pools` 新しい `target` クエリパラメータを受け付けるようになります - * `GET /1.0/storage-pool/` 新しい `target` クエリパラメータを受け付けるようになります - * `POST /1.0/storage-pool//volumes/` 新しい `target` クエリパラメータを受け付けるようになります - * `GET /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります - * `POST /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります - * `PUT /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります - * `PATCH /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります - * `DELETE /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります - * `POST /1.0/networks` 新しい `target` クエリパラメータを受け付けるようになります - * `GET /1.0/networks/` 新しい `target` クエリパラメータを受け付けるようになります +* `POST /1.0/containers` 新しい `target` クエリパラメータを受け付けるようになります。 +* `POST /1.0/storage-pools` 新しい `target` クエリパラメータを受け付けるようになります +* `GET /1.0/storage-pool/` 新しい `target` クエリパラメータを受け付けるようになります +* `POST /1.0/storage-pool//volumes/` 新しい `target` クエリパラメータを受け付けるようになります +* `GET /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります +* `POST /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります +* `PUT /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります +* `PATCH /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります +* `DELETE /1.0/storage-pool//volumes//` 新しい `target` クエリパラメータを受け付けるようになります +* `POST /1.0/networks` 新しい `target` クエリパラメータを受け付けるようになります +* `GET /1.0/networks/` 新しい `target` クエリパラメータを受け付けるようになります ## `event_lifecycle` + これはイベント API に `lifecycle` メッセージ種別を新たに追加します。 ## `storage_api_remote_volume_handling` + これはリモート間でカスタムストレージボリュームをコピーや移動できるようにします。 ## `nvidia_runtime` + コンテナに `nvidia_runtime` という設定オプションを追加します。これを `true` に 設定すると NVIDIA ランタイムと CUDA ライブラリーがコンテナに渡されます。 ## `container_mount_propagation` + これはディスクデバイスタイプに `propagation` オプションを新たに追加します。 これによりカーネルのマウントプロパゲーションの設定ができるようになります。 ## `container_backup` + コンテナのバックアップサポートを追加します。 これは次のエンドポイントを新たに追加します (詳細は [RESTful API](rest-api.md) を参照)。 @@ -488,19 +569,22 @@ LXD のクラスタリング API 。 次の既存のエンドポイントは以下のように変更されます。 - * `POST /1.0/containers` 新たな作成元の種別 `backup` を受け付けるようになります +* `POST /1.0/containers` 新たな作成元の種別 `backup` を受け付けるようになります ## `devlxd_images` + コンテナに `security.devlxd.images` 設定オプションを追加します。これに より `devlxd` 上で `/1.0/images/FINGERPRINT/export` API が利用可能に なります。 nested LXD を動かすコンテナがホストから生のイメージを 取得するためにこれは利用できます。 ## `container_local_cross_pool_handling` + これは同じ LXD インスタンス上のストレージプール間でコンテナをコピー・移動 できるようにします。 ## `proxy_unix` + proxy デバイスで Unix ソケットと abstract Unix ソケットの両方のサポートを 追加します。これらは `unix:/path/to/unix.sock` (通常のソケット) あるいは `unix:@/tmp/unix.sock` (abstract ソケット) のようにアドレスを指定して @@ -514,6 +598,7 @@ proxy デバイスで Unix ソケットと abstract Unix ソケットの両方 * `UNIX <-> TCP` ## `proxy_udp` + proxy デバイスで UDP のサポートを追加します。 現状サポートされている接続は次のとおりです。 @@ -527,6 +612,7 @@ proxy デバイスで UDP のサポートを追加します。 * `UNIX <-> UDP` ## `clustering_join` + これにより `GET /1.0/cluster` がノードに参加する際にどのようなストレージプールと ネットワークを作成する必要があるかについての情報を返します。また、それらを作成する 際にどのノード固有の設定キーを使う必要があるかについての情報も返します。 @@ -534,12 +620,14 @@ proxy デバイスで UDP のサポートを追加します。 ついての情報を受け付け、クラスタに参加する前にこれらが自動的に作成されるようになります。 ## `proxy_tcp_udp_multi_port_handling` + 複数のポートにトラフィックをフォワーディングできるようにします。フォワーディングは ポートの範囲が転送元と転送先で同じ (例えば `1.2.3.4 0-1000 -> 5.6.7.8 1000-2000`) 場合か転送元で範囲を指定し転送先で単一のポートを指定する (例えば `1.2.3.4 0-1000 -> 5.6.7.8 1000`) 場合に可能です。 ## `network_state` + ネットワークの状態を取得できるようになります。 これは次のエンドポイントを新たに追加します (詳細は [RESTful API](rest-api.md) を参照)。 @@ -547,18 +635,22 @@ proxy デバイスで UDP のサポートを追加します。 * `GET /1.0/networks//state` ## `proxy_unix_dac_properties` + これは抽象的 Unix ソケットではない Unix ソケットに GID, UID, パーミションのプロパティを追加します。 ## `container_protection_delete` + `security.protection.delete` フィールドを設定できるようにします。 `true` に設定すると コンテナが削除されるのを防ぎます。スナップショットはこの設定により影響を受けません。 ## `proxy_priv_drop` + proxy デバイスに `security.uid` と `security.gid` を追加します。これは root 権限を 落とし (訳注: 非 root 権限で動作させるという意味です)、 Unix ソケットに接続する 際に用いられる UID/GID も変更します。 ## `pprof_http` + これはデバッグ用の HTTP サーバを起動するために、新たに `core.debug_address` オプションを追加します。 @@ -566,23 +658,28 @@ proxy デバイスに `security.uid` と `security.gid` を追加します。こ と `print-goroutines` デバッグオプションを置き換えるものです。 ## `proxy_haproxy_protocol` + proxy デバイスに `proxy_protocol` キーを追加します。これは HAProxy PROXY プロトコルヘッダ の使用を制御します。 ## `network_hwaddr` + ブリッジの MAC アドレスを制御する `bridge.hwaddr` キーを追加します。 ## `proxy_nat` + これは最適化された UDP/TCP プロキシを追加します。設定上可能であれば プロキシ処理は proxy デバイスの代わりに `iptables` 経由で行われるように なります。 ## `network_nat_order` + LXD ブリッジに `ipv4.nat.order` と `ipv6.nat.order` 設定キーを導入します。 これらのキーは LXD のルールをチェイン内の既存のルールの前に置くか後に置くかを 制御します。 ## `container_full` + これは `GET /1.0/containers` に `recursion=2` という新しいモードを導入します。 これにより状態、スナップショットとバックアップの構造を含むコンテナの全ての構造を 取得できるようになります。 @@ -591,14 +688,17 @@ LXD ブリッジに `ipv4.nat.order` と `ipv6.nat.order` 設定キーを導入 なります。 ## `candid_authentication` + これは新たに `candid.api.url` 設定キーを導入し `core.macaroon.endpoint` を 削除します。 ## `backup_compression` + これは新たに `backups.compression_algorithm` 設定キーを導入します。 これによりバックアップの圧縮の設定が可能になります。 ## `candid_config` + これは `candid.domains` と `candid.expiry` 設定キーを導入します。 前者は許可された／有効な Candid ドメインを指定することを可能にし、 後者は macaroon の有効期限を設定可能にします。 `lxc remote add` コマンドに @@ -606,15 +706,17 @@ LXD ブリッジに `ipv4.nat.order` と `ipv6.nat.order` 設定キーを導入 指定可能になります。 ## `nvidia_runtime_config` + これは `nvidia.runtime` と `libnvidia-container` ライブラリーを使用する際に追加の いくつかの設定キーを導入します。これらのキーは NVIDIA container の対応する 環境変数にほぼそのまま置き換えられます。 - - `nvidia.driver.capabilities` => `NVIDIA_DRIVER_CAPABILITIES` - - `nvidia.require.cuda` => `NVIDIA_REQUIRE_CUDA` - - `nvidia.require.driver` => `NVIDIA_REQUIRE_DRIVER` +* `nvidia.driver.capabilities` => `NVIDIA_DRIVER_CAPABILITIES` +* `nvidia.require.cuda` => `NVIDIA_REQUIRE_CUDA` +* `nvidia.require.driver` => `NVIDIA_REQUIRE_DRIVER` ## `storage_api_volume_snapshots` + ストレージボリュームスナップショットのサポートを追加します。これらは コンテナスナップショットのように振る舞いますが、ボリュームに対してのみ 作成できます。 @@ -630,6 +732,7 @@ LXD ブリッジに `ipv4.nat.order` と `ipv6.nat.order` 設定キーを導入 * `DELETE /1.0/storage-pools//volumes///snapshots/` ## `storage_unmapped` + ストレージボリュームに新たに `security.unmapped` という Boolean 設定を導入します。 `true` に設定するとボリューム上の現在のマップをフラッシュし、以降の @@ -640,41 +743,50 @@ idmap のトラッキングとボリューム上のリマッピングを防ぎ 後にデータを共有します。 ## `projects` + 新たに project API を追加します。プロジェクトの作成、更新、削除ができます。 現時点では、プロジェクトは、コンテナ、プロファイル、イメージを保持できます。そして、プロジェクトを切り替えることで、独立した LXD リソースのビューを見せられます。 ## `candid_config_key` + 新たに `candid.api.key` オプションが使えるようになります。これにより、エンドポイントが期待する公開鍵を設定でき、HTTP のみの Candid サーバを安全に利用できます。 ## `network_vxlan_ttl` + 新たにネットワークの設定に `tunnel.NAME.ttl` が指定できるようになります。これにより、VXLAN トンネルの TTL を増加させることができます。 ## `container_incremental_copy` + 新たにコンテナのインクリメンタルコピーができるようになります。`--refresh` オプションを指定してコンテナをコピーすると、見つからないファイルや、更新されたファイルのみを コピーします。コンテナが存在しない場合は、通常のコピーを実行します。 ## `usb_optional_vendorid` + 名前が暗示しているように、コンテナにアタッチされた USB デバイスの `vendorid` フィールドが省略可能になります。これにより全ての USB デバイスが コンテナに渡されます (GPU に対してなされたのと同様)。 ## `snapshot_scheduling` + これはスナップショットのスケジューリングのサポートを追加します。これにより 3 つの新しい設定キーが導入されます。 `snapshots.schedule`, `snapshots.schedule.stopped`, そして `snapshots.pattern` です。スナップショットは最短で 1 分間隔で自動的に 作成されます。 ## `snapshots_schedule_aliases` + スナップショットのスケジュールはスケジュールエイリアスのカンマ区切りリストで設定できます。 インスタンスには `<@hourly> <@daily> <@midnight> <@weekly> <@monthly> <@annually> <@yearly> <@startup>`、 ストレージボリュームには `<@hourly> <@daily> <@midnight> <@weekly> <@monthly> <@annually> <@yearly>` のエイリアスが利用できます。 ## `container_copy_project` + コピー元のコンテナの dict に `project` フィールドを導入します。これにより プロジェクト間でコンテナをコピーあるいは移動できるようになります。 ## `clustering_server_address` + これはサーバのネットワークアドレスを REST API のクライアントネットワーク アドレスと異なる値に設定することのサポートを追加します。クライアントは 新しい `cluster.https_address` 設定キーを初期のサーバのアドレスを指定するために @@ -686,15 +798,18 @@ idmap のトラッキングとボリューム上のリマッピングを防ぎ コピーされます)。 ## `clustering_image_replication` + クラスタ内のノードをまたいだイメージのレプリケーションを可能にします。 新しい `cluster.images_minimal_replica` 設定キーが導入され、イメージの リプリケーションに対するノードの最小数を指定するのに使用できます。 ## `container_protection_shift` + `security.protection.shift` の設定を可能にします。これによりコンテナの ファイルシステム上で UID/GID をシフト (再マッピング) させることを防ぎます。 ## `snapshot_expiry` + これはスナップショットの有効期限のサポートを追加します。タスクは 1 分おきに実行されます。 `snapshots.expiry` 設定オプションは、`1M 2H 3d 4w 5m 6y` （それぞれ 1 分、2 時間、3 日、4 週間、5 ヶ月、6 年）といった形式を取ります。 この指定ではすべての部分を使う必要はありません。 @@ -710,52 +825,64 @@ idmap のトラッキングとボリューム上のリマッピングを防ぎ * `PUT /1.0/containers//snapshots/` ## `snapshot_expiry_creation` + コンテナ作成に `expires_at` を追加し、作成時にスナップショットの有効期限を上書きできます。 ## `network_leases_location` + ネットワークのリースリストに `Location` フィールドを導入します。 これは、特定のリースがどのノードに存在するかを問い合わせるときに使います。 ## `resources_cpu_socket` + ソケットの情報が入れ替わる場合に備えて CPU リソースにソケットフィールドを追加します。 ## `resources_gpu` + サーバリソースに新規にGPU構造を追加し、システム上で利用可能な全てのGPUを一覧表示します。 ## `resources_numa` + 全てのCPUとGPUに対するNUMAノードを表示します。 ## `kernel_features` + サーバの環境からオプショナルなカーネル機能の使用可否状態を取得します。 ## `id_map_current` + 内部的な `volatile.idmap.current` キーを新規に導入します。これはコンテナに 対する現在のマッピングを追跡するのに使われます。 実質的には以下が利用可能になります。 - - `volatile.last_state.idmap` => ディスク上の idmap - - `volatile.idmap.current` => 現在のカーネルマップ - - `volatile.idmap.next` => 次のディスク上の idmap +* `volatile.last_state.idmap` => ディスク上の idmap +* `volatile.idmap.current` => 現在のカーネルマップ +* `volatile.idmap.next` => 次のディスク上の idmap これはディスク上の map が変更されていないがカーネルマップは変更されている (例: `shiftfs`) ような環境を実装するために必要です。 ## `event_location` + API イベントの世代の場所を公開します。 ## `storage_api_remote_volume_snapshots` + ストレージボリュームをそれらのスナップショットを含んで移行できます。 ## `network_nat_address` + これは LXD ブリッジに `ipv4.nat.address` と `ipv6.nat.address` 設定キーを導入します。 これらのキーはブリッジからの送信トラフィックに使うソースアドレスを制御します。 ## `container_nic_routes` + これは `nic` タイプのデバイスに `ipv4.routes` と `ipv6.routes` プロパティを導入します。 ホストからコンテナへの NIC への静的ルートが追加できます。 ## `rbac` + RBAC (role based access control; ロールベースのアクセス制御) のサポートを追加します。 これは以下の設定キーを新規に導入します。 @@ -768,65 +895,77 @@ RBAC (role based access control; ロールベースのアクセス制御) のサ * `rbac.agent.public_key` ## `cluster_internal_copy` + これは通常の `POST /1.0/containers` を実行することでクラスタノード間で コンテナをコピーすることを可能にします。この際 LXD はマイグレーションが 必要かどうかを内部的に判定します。 ## `seccomp_notify` + カーネルが `seccomp` ベースの syscall インターセプトをサポートする場合に 登録された syscall が実行されたことをコンテナから LXD に通知することが できます。 LXD はそれを受けて様々なアクションをトリガーするかを決定します。 ## `lxc_features` + これは `GET /1.0/` ルート経由で `lxc info` コマンドの出力に `lxc_features` セクションを導入します。配下の LXC ライブラリーに存在するキー・フィーチャーに 対するチェックの結果を出力します。 ## `container_nic_ipvlan` + これは `nic` デバイスに `ipvlan` のタイプを導入します。 ## `network_vlan_sriov` + これは SR-IOV デバイスに VLAN (`vlan`) と MAC フィルタリング (`security.mac_filtering`) のサポートを導入します。 ## `storage_cephfs` + ストレージプールドライバとして CephFS のサポートを追加します。これは カスタムボリュームとしての利用のみが可能になり、イメージとコンテナは CephFS ではなく Ceph (RBD) 上に構築する必要があります。 ## `container_nic_ipfilter` + これは `bridged` の NIC デバイスに対してコンテナの IP フィルタリング (`security.ipv4_filtering` and `security.ipv6_filtering`) を導入します。 ## `resources_v2` + `/1.0/resources` のリソース API を見直しました。主な変更は以下の通りです。 - - CPU - - ソケット、コア、スレッドのトラッキングのレポートを修正しました - - コア毎の NUMA ノードのトラッキング - - ソケット毎のベースとターボの周波数のトラッキング - - コア毎の現在の周波数のトラッキング - - CPU のキャッシュ情報の追加 - - CPU アーキテクチャをエクスポート - - スレッドのオンライン／オフライン状態を表示 - - メモリ - - HugePages のトラッキングを追加 - - NUMA ノード毎でもメモリ消費を追跡 - - GPU - - DRM 情報を別の構造体に分離 - - DRM 構造体内にデバイスの名前とノードを公開 - - NVIDIA 構造体内にデバイスの名前とノードを公開 - - SR-IOV VF のトラッキングを追加 +* CPU + * ソケット、コア、スレッドのトラッキングのレポートを修正しました + * コア毎の NUMA ノードのトラッキング + * ソケット毎のベースとターボの周波数のトラッキング + * コア毎の現在の周波数のトラッキング + * CPU のキャッシュ情報の追加 + * CPU アーキテクチャをエクスポート + * スレッドのオンライン／オフライン状態を表示 +* メモリ + * HugePages のトラッキングを追加 + * NUMA ノード毎でもメモリ消費を追跡 +* GPU + * DRM 情報を別の構造体に分離 + * DRM 構造体内にデバイスの名前とノードを公開 + * NVIDIA 構造体内にデバイスの名前とノードを公開 + * SR-IOV VF のトラッキングを追加 ## `container_exec_user_group_cwd` + `POST /1.0/containers/NAME/exec` の実行時に `User`, `Group` と `Cwd` を指定するサポートを追加 ## `container_syscall_intercept` + `security.syscalls.intercept.*` 設定キーを追加します。これはどのシステムコールを LXD がインターセプトし昇格された権限で処理するかを制御します。 ## `container_disk_shift` + `disk` デバイスに `shift` プロパティを追加します。これは `shiftfs` のオーバーレイの使用を制御します。 ## `storage_shifted` + ストレージボリュームに新しく `security.shifted` という Boolean の設定を導入します。 これを `true` に設定すると複数の隔離されたコンテナが、それら全てがファイルシステムに @@ -835,117 +974,148 @@ CephFS ではなく Ceph (RBD) 上に構築する必要があります。 これは `shiftfs` をオーバーレイファイルシステムとして使用します。 ## `resources_infiniband` + リソース API の一部として InfiniBand キャラクタデバイス (`issm`, `umad`, `uverb`) の情報を公開します。 ## `daemon_storage` + これは `storage.images_volume` と `storage.backups_volume` という 2 つの新しい設定項目を導入します。これらは既存のプール上のストレージボリュームがデーモン全体のイメージとバックアップを保管するのに使えるようにします。 ## `instances` + これはインスタンスの概念を導入します。現状ではインスタンスの唯一の種別は `container` です。 ## `image_types` + これはイメージに新しく Type フィールドのサポートを導入します。 Type フィールドはイメージがどういう種別かを示します。 ## `resources_disk_sata` + ディスクリソース API の構造体を次の項目を含むように拡張します。 - - SATA デバイス(種別)の適切な検出 - - デバイスパス - - ドライブの RPM - - ブロックサイズ - - ファームウェアバージョン - - シリアルナンバー +* SATA デバイス(種別)の適切な検出 +* デバイスパス +* ドライブの RPM +* ブロックサイズ +* ファームウェアバージョン +* シリアルナンバー ## `clustering_roles` + これはクラスタのエントリーに `roles` という新しい属性を追加し、クラスタ内のメンバーが提供する role の一覧を公開します。 ## `images_expiry` + イメージの有効期限を設定できます。 ## `resources_network_firmware` + ネットワークカードのエントリーに `FirmwareVersion` フィールドを追加します。 ## `backup_compression_algorithm` + バックアップを作成する (`POST /1.0/containers//backups`) 際に `compression_algorithm` プロパティのサポートを追加します。 このプロパティを設定するとデフォルト値 (`backups.compression_algorithm`) をオーバーライドすることができます。 ## `ceph_data_pool_name` + Ceph RBD を使ってストレージプールを作成する際にオプショナルな引数 (`ceph.osd.data_pool_name`) のサポートを追加します。 この引数が指定されると、プールはメタデータは `pool_name` で指定されたプールに保持しつつ実際のデータは `data_pool_name` で指定されたプールに保管するようになります。 ## `container_syscall_intercept_mount` + `security.syscalls.intercept.mount`, `security.syscalls.intercept.mount.allowed`, `security.syscalls.intercept.mount.shift` 設定キーを追加します。 これらは `mount` システムコールを LXD にインターセプトさせるかどうか、昇格されたパーミションでどのように処理させるかを制御します。 ## `compression_squashfs` + イメージやバックアップを SquashFS ファイルシステムの形式でインポート／エクスポートするサポートを追加します。 ## `container_raw_mount` + ディスクデバイスに raw mount オプションを渡すサポートを追加します。 ## `container_nic_routed` + `routed` `nic` デバイスタイプを導入します。 ## `container_syscall_intercept_mount_fuse` + `security.syscalls.intercept.mount.fuse` キーを追加します。これはファイルシステムのマウントを fuse 実装にリダイレクトするのに使えます。 このためには例えば `security.syscalls.intercept.mount.fuse=ext4=fuse2fs` のように設定します。 ## `container_disk_ceph` + 既存の Ceph RBD もしくは CephFS を直接 LXD コンテナに接続できます。 ## `virtual_machines` + 仮想マシンサポートが追加されます。 ## `image_profiles` + 新しいコンテナを起動するときに、イメージに適用するプロファイルのリストが指定できます。 ## `clustering_architecture` + クラスタメンバーに `architecture` 属性を追加します。 この属性はクラスタメンバーのアーキテクチャを示します。 ## `resources_disk_id` + リソース API のディスクのエントリーに `device_id` フィールドを追加します。 ## `storage_lvm_stripes` + 通常のボリュームと thin pool ボリューム上で LVM ストライプを使う機能を追加します。 ## `vm_boot_priority` + ブートの順序を制御するため NIC とディスクデバイスに `boot.priority` プロパティを追加します。 ## `unix_hotplug_devices` + Unix のキャラクタデバイスとブロックデバイスのホットプラグのサポートを追加します。 ## `api_filtering` + インスタンスとイメージに対する GET リクエストの結果をフィルタリングする機能を追加します。 ## `instance_nic_network` + NIC デバイスの `network` プロパティのサポートを追加し、管理されたネットワークへ NIC をリンクできるようにします。 これによりネットワーク設定の一部を引き継ぎ、 IP 設定のより良い検証を行うことができます。 ## `clustering_sizing` + データベースの投票者とスタンバイに対してカスタムの値を指定するサポートです。 `cluster.max_voters` と `cluster.max_standby` という新しい設定キーが導入され、データベースの投票者とスタンバイの理想的な数を指定できます。 ## `firewall_driver` + `ServerEnvironment` 構造体にファイアーウォールのドライバが使用されていることを示す `Firewall` プロパティを追加します。 ## `storage_lvm_vg_force_reuse` + 既存の空でないボリュームグループからストレージボリュームを作成する機能を追加します。 このオプションの使用には注意が必要です。 というのは、同じボリュームグループ内に LXD 以外で作成されたボリュームとボリューム名が衝突しないことを LXD が保証できないからです。 このことはもし名前の衝突が起きたときは LXD 以外で作成されたボリュームを LXD が削除してしまう可能性があることを意味します。 ## `container_syscall_intercept_hugetlbfs` + mount システムコール・インターセプションが有効にされ `hugetlbfs` が許可されたファイルシステムとして指定された場合、 LXD は別の `hugetlbfs` インスタンスを UID と GID をコンテナの root の UID と GID に設定するマウントオプションを指定してコンテナにマウントします。 これによりコンテナ内のプロセスが huge page を確実に利用できるようにします。 ## `limits_hugepages` + コンテナが使用できる huge page の数を `hugetlb` cgroup を使って制限できるようにします。 この機能を使用するには `hugetlb` cgroup が利用可能になっている必要があります。 注意: `hugetlbfs` ファイルシステムの mount システムコールをインターセプトするときは、ホストの huge page のリソースをコンテナが使い切ってしまわないように huge page を制限することを推奨します。 ## `container_nic_routed_gateway` + この拡張は `ipv4.gateway` と `ipv6.gateway` という NIC の設定キーを追加します。 指定可能な値は `auto` か `none` のいずれかです。 値を指定しない場合のデフォルト値は `auto` です。 @@ -954,19 +1124,23 @@ mount システムコール・インターセプションが有効にされ `hug これにより複数のルートを持つ NIC デバイスをコンテナに追加できます。 ## `projects_restrictions` + この拡張はプロジェクトに `restricted` という設定キーを追加します。 これによりプロジェクト内でセキュリティセンシティブな機能を使うのを防ぐことができます。 ## `custom_volume_snapshot_expiry` + この拡張はカスタムボリュームのスナップショットに有効期限を設定できるようにします。 有効期限は `snapshots.expiry` 設定キーにより個別に設定することも出来ますし、親のカスタムボリュームに設定してそこから作成された全てのスナップショットに自動的にその有効期限を適用することも出来ます。 ## `volume_snapshot_scheduling` + この拡張はカスタムボリュームのスナップショットにスケジュール機能を追加します。 `snapshots.schedule` と `snapshots.pattern` という 2 つの設定キーが新たに追加されます。 スナップショットは最短で 1 分毎に作成可能です。 ## `trust_ca_certificates` + この拡張により提供された CA (`server.ca`) によって信頼されたクライアント証明書のチェックが可能になります。 `core.trust_ca_certificates` を `true` に設定すると有効にできます。 有効な場合、クライアント証明書のチェックを行い、チェックが OK であれば信頼されたパスワードの要求はスキップします。 @@ -974,12 +1148,15 @@ mount システムコール・インターセプションが有効にされ `hug この場合は、パスワードが求められます。 ## `snapshot_disk_usage` + この拡張はスナップショットのディスク使用量を示す `/1.0/instances//snapshots/` の出力に `size` フィールドを新たに追加します。 ## `clustering_edit_roles` + この拡張はクラスタメンバーに書き込み可能なエンドポイントを追加し、ロールの編集を可能にします。 ## `container_nic_routed_host_address` + この拡張は NIC の設定キーに `ipv4.host_address` と `ipv6.host_address` を追加し、ホスト側の veth インターフェースの IP アドレスを制御できるようにします。 これは同時に複数の routed NIC を使用し、予測可能な next-hop のアドレスを使用したい場合に有用です。 @@ -994,6 +1171,7 @@ auto に設定するとコンテナはデフォルトゲートウェイをそれ これは以前のデフォルトの挙動と後方互換性があります。 ## `container_nic_ipvlan_gateway` + この拡張は `ipv4.gateway` と `ipv6.gateway` の NIC 設定キーを追加し `auto` か `none` の値を指定できます。 指定しない場合のデフォルト値は `auto` です。 この場合は従来同様の挙動になりコンテナ内部に追加されるデフォルトゲートウェイと同じアドレスがホスト側のインターフェースにも追加されます。 @@ -1001,29 +1179,36 @@ auto に設定するとコンテナはデフォルトゲートウェイをそれ これによりコンテナに IPVLAN の NIC デバイスを複数追加することができます。 ## `resources_usb_pci` + この拡張は `/1.0/resources` の出力に USB と PC デバイスを追加します。 ## `resources_cpu_threads_numa` + この拡張は `numa_node` フィールドをコアごとではなくスレッドごとに記録するように変更します。 これは一部のハードウェアでスレッドを異なる NUMA ドメインに入れる場合があるようなのでそれに対応するためのものです。 ## `resources_cpu_core_die` + それぞれのコアごとに `die_id` 情報を公開します。 ## `api_os` + この拡張は `/1.0` 内に `os` と `os_version` の 2 つのフィールドを追加します。 これらの値はシステム上の OS-release のデータから取得されます。 ## `container_nic_routed_host_table` + この拡張は `ipv4.host_table` と `ipv6.host_table` という NIC の設定キーを導入します。 これで指定した ID のカスタムポリシーのルーティングテーブルにインスタンスの IP のための静的ルートを追加できます。 ## `container_nic_ipvlan_host_table` + この拡張は `ipv4.host_table` と `ipv6.host_table` という NIC の設定キーを導入します。 これで指定した ID のカスタムポリシーのルーティングテーブルにインスタンスの IP のための静的ルートを追加できます。 ## `container_nic_ipvlan_mode` + この拡張は `mode` という NIC の設定キーを導入します。 これにより `ipvlan` モードを `l2` か `l3s` のいずれかに切り替えられます。 指定しない場合、デフォルトは `l3s` （従来の挙動）です。 @@ -1034,93 +1219,109 @@ auto に設定するとコンテナはデフォルトゲートウェイをそれ `l2` モードでは `ipv4.gateway` と `ipv6.gateway` キーは単一の IP アドレスのみを受け付けます。 ## `resources_system` + この拡張は `/1.0/resources` の出力にシステム情報を追加します。 ## `images_push_relay` + この拡張はイメージのコピーに push と relay モードを追加します。 また以下の新しいエンドポイントも追加します。 - - `POST 1.0/images//export` + +* `POST 1.0/images//export` ## `network_dns_search` + この拡張はネットワークに `dns.search` という設定オプションを追加します。 ## `container_nic_routed_limits` + この拡張は routed NIC に `limits.ingress`, `limits.egress`, `limits.max` を追加します。 ## `instance_nic_bridged_vlan` + この拡張は `bridged` NIC に `vlan` と `vlan.tagged` の設定を追加します。 `vlan` には参加するタグなし VLAN を指定し、 `vlan.tagged` は参加するタグ VLAN のカンマ区切りリストを指定します。 ## `network_state_bond_bridge` + この拡張は `/1.0/networks/NAME/state` API に bridge と bond のセクションを追加します。 これらはそれぞれの特定のタイプに関連する追加の状態の情報を含みます。 Bond: - - Mode - - Transmit hash - - Up delay - - Down delay - - MII frequency - - MII state - - Lower devices +* Mode +* Transmit hash +* Up delay +* Down delay +* MII frequency +* MII state +* Lower devices Bridge: - - ID - - Forward delay - - STP mode - - Default VLAN - - VLAN filtering - - Upper devices +* ID +* Forward delay +* STP mode +* Default VLAN +* VLAN filtering +* Upper devices ## `resources_cpu_isolated` + この拡張は CPU スレッドに `Isolated` プロパティを追加します。 これはスレッドが物理的には `Online` ですがタスクを受け付けないように設定しているかを示します。 ## `usedby_consistency` + この拡張により、可能な時は `UsedBy` が適切な `?project=` と `?target=` に対して一貫性があるようになるはずです。 `UsedBy` を持つ 5 つのエンティティーは以下の通りです。 - - プロファイル - - プロジェクト - - ネットワーク - - ストレージプール - - ストレージボリューム +* プロファイル +* プロジェクト +* ネットワーク +* ストレージプール +* ストレージボリューム ## `custom_block_volumes` + この拡張によりカスタムブロックボリュームを作成しインスタンスにアタッチできるようになります。 カスタムストレージボリュームの作成時に `--type` フラグが新規追加され、 `fs` と `block` の値を受け付けます。 ## `clustering_failure_domains` + この拡張は `PUT /1.0/cluster/` API に `failure_domain` フィールドを追加します。 これはノードの failure domain を設定するのに使えます。 ## `container_syscall_filtering_allow_deny_syntax` + いくつかのシステムコールに関連したコンテナの設定キーが更新されました。 - * `security.syscalls.deny_default` - * `security.syscalls.deny_compat` - * `security.syscalls.deny` - * `security.syscalls.allow` +* `security.syscalls.deny_default` +* `security.syscalls.deny_compat` +* `security.syscalls.deny` +* `security.syscalls.allow` ## `resources_gpu_mdev` + `/1.0/resources` の利用可能な媒介デバイス (mediated device) のプロファイルとデバイスを公開します。 ## `console_vga_type` + この拡張は `/1.0/console` エンドポイントが `?type=` 引数を取るように拡張します。 これは `console` (デフォルト) か `vga` (この拡張で追加される新しいタイプ) を指定可能です。 `/1.0//console?type=vga` に `POST` する際はメタデータフィールド内の操作の結果ウェブソケットにより返されるデータはターゲットの仮想マシンの SPICE Unix ソケットにアタッチされた双方向のプロキシになります。 ## `projects_limits_disk` + 利用可能なプロジェクトの設定キーに `limits.disk` を追加します。 これが設定されるとプロジェクト内でインスタンスボリューム、カスタムボリューム、イメージボリュームが使用できるディスクスペースの合計の量を制限できます。 ## `network_type_macvlan` + ネットワークタイプ `macvlan` のサポートを追加し、このネットワークタイプに `parent` 設定キーを追加します。 これは NIC デバイスインターフェースを作る際にどの親インターフェースを使用するべきかを指定します。 @@ -1128,6 +1329,7 @@ Bridge: これは NIC デバイスの設定の基礎として使う network を指定します。 ## `network_type_sriov` + ネットワークタイプ `sriov` のサポートを追加し、このネットワークタイプに `parent` 設定キーを追加します。 これは NIC デバイスインターフェースを作る際にどの親インターフェースを使用するべきかを指定します。 @@ -1135,25 +1337,30 @@ Bridge: これは NIC デバイスの設定の基礎として使う network を指定します。 ## `container_syscall_intercept_bpf_devices` + この拡張はコンテナ内で `bpf` のシステムコールをインターセプトする機能を提供します。具体的には device cgroup の `bpf` のプログラムを管理できるようにします。 ## `network_type_ovn` + ネットワークタイプ `ovn` のサポートを追加し、 `bridge` タイプのネットワークを `parent` として設定できるようにします。 `ovn` という新しい NIC のデバイスタイプを追加します。これにより `network` 設定キーにどの `ovn` のタイプのネットワークに接続すべきかを指定できます。 さらに全ての `ovn` ネットワークと NIC デバイスに適用される 2 つのグローバルの設定キーを追加します。 - - `network.ovn.integration_bridge` - 使用する OVS 統合ブリッジ - - `network.ovn.northbound_connection` - OVN northbound データベース接続文字列 +* `network.ovn.integration_bridge` - 使用する OVS 統合ブリッジ +* `network.ovn.northbound_connection` - OVN northbound データベース接続文字列 ## `projects_networks` + プロジェクトに `features.networks` 設定キーを追加し、プロジェクトがネットワークを保持できるようにします。 ## `projects_networks_restricted_uplinks` + プロジェクトに `restricted.networks.uplinks` 設定キーを追加し、プロジェクト内で作られたネットワークがそのアップリンクのネットワークとしてどのネットワークが使えるかを（カンマ区切りリストで）指定します。 ## `custom_volume_backup` + カスタムボリュームのバックアップサポートを追加します。 この拡張は以下の新しい API エンドポイント （詳細は [RESTful API](rest-api.md) を参照）を含みます。 @@ -1169,23 +1376,27 @@ Bridge: 以下の既存のエンドポイントが変更されます。 - * `POST /1.0/storage-pools///` が新しいソースタイプとして `backup` を受け付けます +* `POST /1.0/storage-pools///` が新しいソースタイプとして `backup` を受け付けます ## `backup_override_name` + `InstanceBackupArgs` に `Name` フィールドを追加し、バックアップをリストアする際に別のインスタンス名を指定できるようにします。 `StoragePoolVolumeBackupArgs` に `Name` と `PoolName` フィールドを追加し、カスタムボリュームのバックアップをリストアする際に別のボリューム名を指定できるようにします。 ## `storage_rsync_compression` + ストレージプールに `rsync.compression` 設定キーを追加します。 このキーはストレージプールをマイグレートする際に `rsync` での圧縮を無効にするために使うことができます。 ## `network_type_physical` + 新たに `physical` というネットワークタイプのサポートを追加し、 `ovn` ネットワークのアップリンクとして使用できるようにします。 `physical` ネットワークの `parent` で指定するインターフェースは `ovn` ネットワークのゲートウェイに接続されます。 ## `network_ovn_external_subnets` + `ovn` ネットワークがアップリンクネットワークの外部のサブネットを使用できるようにします。 `physical` ネットワークに `ipv4.routes` と `ipv6.routes` の設定を追加します。 @@ -1195,6 +1406,7 @@ Bridge: これはプロジェクト内の OVN ネットワークで使用可能な外部のサブネットを指定します（未設定の場合はアップリンクネットワークで定義される全てのルートが使用可能です）。 ## `network_ovn_nat` + `ovn` ネットワークに `ipv4.nat` と `ipv6.nat` の設定を追加します。 これらの設定(訳注: `ipv4.nat` や `ipv6.nat`)を未設定でネットワークを作成する際、(訳注: `ipv4.address` や `ipv6.address` が未設定あるいは `auto` の場合に)対応するアドレス (訳注: `ipv4.nat` であれば `ipv4.address`、`ipv6.nat` であれば `ipv6.address`)がサブネット用に生成される場合は適切な NAT が生成され、`ipv4.nat` や `ipv6.nat` は `true` に設定されます。 @@ -1202,31 +1414,39 @@ Bridge: この設定がない場合は値は `false` として扱われます。 ## `network_ovn_external_routes_remove` + `ovn` ネットワークから `ipv4.routes.external` と `ipv6.routes.external` の設定を削除します。 ネットワークと NIC レベルの両方で指定するのではなく、 `ovn` NIC タイプ上で等価な設定を使えます。 ## `tpm_device_type` + `tpm` デバイスタイプを導入します。 ## `storage_zfs_clone_copy_rebase` + `zfs.clone_copy` に `rebase` という値を導入します。 この設定で LXD は先祖の系列上の `image` データセットを追跡し、その最上位に対して send/receive を実行します。 ## `gpu_mdev` + これは仮想 CPU のサポートを追加します。 GPU デバイスに `mdev` 設定キーを追加し、`i915-GVTg_V5_4` のようなサポートされる `mdev` のタイプを指定します。 ## `resources_pci_iommu` + これはリソース API の PCI エントリーに `IOMMUGroup` フィールドを追加します。 ## `resources_network_usb` + リソース API のネットワークカードエントリーに `usb_address` フィールドを追加します。 ## `resources_disk_address` + リソース API のディスクエントリーに `usb_address` と `pci_address` フィールドを追加します。 ## `network_physical_ovn_ingress_mode` + `physical` ネットワークに `ovn.ingress_mode` 設定を追加します。 OVN NIC ネットワークの外部 IP アドレスがアップリンクネットワークにどのように広告されるかの方法を設定します。 @@ -1234,35 +1454,43 @@ OVN NIC ネットワークの外部 IP アドレスがアップリンクネッ `l2proxy` (proxy ARP/NDP) か `routed` のいずれかを指定します。 ## `network_ovn_dhcp` + `ovn` ネットワークに `ipv4.dhcp` と `ipv6.dhcp` の設定を追加します。 DHCP (と IPv6 の RA) を無効にできます。デフォルトはオンです。 ## `network_physical_routes_anycast` + `physical` ネットワークに `ipv4.routes.anycast` と `ipv6.routes.anycast` の Boolean の設定を追加します。デフォルトは `false` です。 `ovn.ingress_mode=routed` と共に使うと physical ネットワークをアップリンクとして使う OVN ネットワークでサブネット／ルートのオーバーラップ検出を緩和できます。 ## `projects_limits_instances` + `limits.instances` を利用可能なプロジェクトの設定キーに追加します。 設定するとプロジェクト内で使われるインスタンス（VMとコンテナ）の合計数を制限します。 ## `network_state_vlan` + これは `/1.0/networks/NAME/state` API に `vlan` セクションを追加します。 これらは VLAN インターフェースに関連する追加の状態の情報を含みます。 - - `lower_device` - - `vid` + +* `lower_device` +* `vid` ## `instance_nic_bridged_port_isolation` + これは `bridged` NIC に `security.port_isolation` のフィールドを追加します。 ## `instance_bulk_state_change` + 一括状態変更（詳細は [REST API](rest-api.md) を参照）のために次のエンドポイントを追加します。 * `PUT /1.0/instances` ## `network_gvrp` + これはオプショナルな `gvrp` プロパティを `macvlan` と `physical` ネットワークに追加し、 さらに `ipvlan`, `macvlan`, `routed`, `physical` NIC デバイスにも追加します。 @@ -1270,76 +1498,96 @@ DHCP (と IPv6 の RA) を無効にできます。デフォルトはオンです デフォルトは `false` です。 ## `instance_pool_move` + これは `POST /1.0/instances/NAME` API に `pool` フィールドを追加し、プール間でインスタンスのルートディスクを簡単に移動できるようにします。 ## `gpu_sriov` + これは SR-IOV を有効にした GPU のサポートを追加します。 これにより `sriov` という GPU タイプのプロパティが追加されます。 ## `pci_device_type` + これは `pci` デバイスタイプを追加します。 ## `storage_volume_state` + `/1.0/storage-pools/POOL/volumes/VOLUME/state` API エンドポイントを新規追加しボリュームの使用量を取得できるようにします。 ## `network_acl` + これは `/1.0/network-acls` の API エンドポイントプリフィクス以下の API にネットワークの ACL のコンセプトを追加します。 ## `migration_stateful` + `migration.stateful` という設定キーを追加します。 ## `disk_state_quota` + これは `disk` デバイスに `size.state` というデバイス設定キーを追加します。 ## `storage_ceph_features` + ストレージプールに `ceph.rbd.features` 設定キーを追加し、新規ボリュームに使用する RBD の機能を制御します。 ## `projects_compression` + `backups.compression_algorithm` と `images.compression_algorithm` 設定キーを追加します。 これらによりプロジェクトごとのバックアップとイメージの圧縮の設定が出来るようになります。 ## `projects_images_remote_cache_expiry` + プロジェクトに `images.remote_cache_expiry` 設定キーを追加します。 これを設定するとキャッシュされたリモートのイメージが指定の日数使われない場合は削除されるようになります。 ## `certificate_project` + API 内の証明書に `restricted` と `projects` プロパティを追加します。 `projects` は証明書がアクセスしたプロジェクト名の一覧を保持します。 ## `network_ovn_acl` + OVN ネットワークと OVN NIC に `security.acls` プロパティを追加します。 これにより ネットワークに ACL をかけられるようになります。 ## `projects_images_auto_update` + `images.auto_update_cached` と `images.auto_update_interval` 設定キーを追加します。 これらによりプロジェクト内のイメージの自動更新を設定できるようになります。 ## `projects_restricted_cluster_target` + プロジェクトに `restricted.cluster.target` 設定キーを追加します。 これによりどのクラスタメンバーにワークロードを配置するかやメンバー間のワークロードを移動する能力を指定する --target オプションをユーザーに使わせないように出来ます。 ## `images_default_architecture` + `images.default_architecture` をグローバルの設定キーとプロジェクトごとの設定キーとして追加します。 これはイメージリクエストの一部として明示的に指定しなかった場合にどのアーキテクチャーを使用するかを LXD に指定します。 ## `network_ovn_acl_defaults` + OVN ネットワークと NIC に `security.acls.default.{in,e}gress.action` と `security.acls.default.{in,e}gress.logged` 設定キーを追加します。 これは削除された ACL の `default.action` と `default.logged` キーの代わりになるものです。 ## `gpu_mig` + これは NVIDIA MIG のサポートを追加します。 `mig` GPU type と関連する設定キーを追加します。 ## `project_usage` + プロジェクトに現在のリソース割り当ての情報を取得する API エンドポイントを追加します。 API の `GET /1.0/projects//state` で利用できます。 ## `network_bridge_acl` + `bridge` ネットワークに `security.acls` 設定キーを追加し、ネットワーク ACL を適用できるようにします。 さらにマッチしなかったトラフィックに対するデフォルトの振る舞いを指定する `security.acls.default.{in,e}gress.action` と `security.acls.default.{in,e}gress.logged` 設定キーを追加します。 ## `warnings` + LXD の警告 API です。 この拡張は次のエンドポイントを含みます（詳細は [Restful API](rest-api.md) 参照）。 @@ -1351,78 +1599,95 @@ LXD の警告 API です。 * `DELETE /1.0/warnings/` ## `projects_restricted_backups_and_snapshots` + プロジェクトに `restricted.backups` と `restricted.snapshots` 設定キーを追加し、ユーザーがバックアップやスナップショットを作成できないようにします。 ## `clustering_join_token` + トラスト・パスワードを使わずに新しいクラスタメンバーを追加する際に使用する参加トークンをリクエストするための `POST /1.0/cluster/members` API エンドポイントを追加します。 ## `clustering_description` + クラスタメンバーに編集可能な説明を追加します。 ## `server_trusted_proxy` + `core.https_trusted_proxy` のサポートを追加します。 この設定は、LXD が HAProxy スタイルの connection ヘッダーをパースし、そのような（HAProxy などのリバースプロキシサーバが LXD の前面に存在するような）接続の場合でヘッダーが存在する場合は、プロキシサーバが（ヘッダーで）提供するリクエストの（実際のクライアントの）ソースアドレスへ（LXDが）ソースアドレスを書き換え（て、LXDの管理するクラスタにリクエストを送出し）ます。（LXDのログにもオリジナルのアドレスを記録します） ## `clustering_update_cert` + クラスタ全体に適用されるクラスタ証明書を更新するための `PUT /1.0/cluster/certificate` エンドポイントを追加します。 ## `storage_api_project` + これはプロジェクト間でカスタムストレージボリュームをコピー／移動できるようにします。 ## `server_instance_driver_operational` + これは `/1.0` エンドポイントの `driver` の出力をサーバ上で実際にサポートされ利用可能であるドライバのみを含めるように修正します（LXD に含まれるがサーバ上では利用不可なドライバも含めるのとは違って）。 ## `server_supported_storage_drivers` + これはサーバの環境情報にサポートされているストレージドライバの情報を追加します。 ## `event_lifecycle_requestor_address` + lifecycle requestor に address のフィールドを追加します。 ## `resources_gpu_usb` + リソース API 内の `ResourcesGPUCard` (GPU エントリ) に `USBAddress` (`usb_address`) を追加します。 ## `clustering_evacuation` + クラスタメンバーを待避と復元するための `POST /1.0/cluster/members//state` エンドポイントを追加します。 また設定キー `cluster.evacuate` と `volatile.evacuate.origin` も追加します。 これらはそれぞれ待避の方法 (`auto`, `stop` or `migrate`) と移動したインスタンスのオリジンを設定します。 ## `network_ovn_nat_address` + これは LXD の `ovn` ネットワークに `ipv4.nat.address` と `ipv6.nat.address` 設定キーを追加します。 これらのキーで OVN 仮想ネットワークからの外向きトラフィックのソースアドレスを制御します。 これらのキーは OVN ネットワークのアップリンクネットワークが `ovn.ingress_mode=routed` という設定を持つ場合にのみ指定可能です。 ## `network_bgp` + これは LXD を BGP ルーターとして振る舞わせルートを `bridge` と `ovn` ネットワークに広告するようにします。 以下のグローバル設定が追加されます。 - - `core.bgp_address` - - `core.bgp_asn` - - `core.bgp_routerid` +* `core.bgp_address` +* `core.bgp_asn` +* `core.bgp_routerid` 以下のネットワーク設定キーが追加されます（`bridge` と `physical`）。 - - `bgp.peers..address` - - `bgp.peers..asn` - - `bgp.peers..password` - - `bgp.ipv4.nexthop` - - `bgp.ipv6.nexthop` +* `bgp.peers..address` +* `bgp.peers..asn` +* `bgp.peers..password` +* `bgp.ipv4.nexthop` +* `bgp.ipv6.nexthop` そして下記の NIC 特有な設定が追加されます（NIC type が `bridged` の場合）。 - - `ipv4.routes.external` - - `ipv6.routes.external` +* `ipv4.routes.external` +* `ipv6.routes.external` ## `network_forward` + これはネットワークアドレスのフォワード機能を追加します。 `bridge` と `ovn` ネットワークで外部 IP アドレスを定義して対応するネットワーク内の内部 IP アドレス(複数指定可能) にフォワード出来ます。 ## `custom_volume_refresh` + ボリュームマイグレーションに refresh オプションのサポートを追加します。 ## `network_counters_errors_dropped` + これはネットワークカウンターに受信エラー数、送信エラー数とインバウンドとアウトバウンドのドロップしたパケット数を追加します。 ## `metrics` + これは LXD にメトリクスを追加します。実行中のインスタンスのメトリクスを OpenMetrics 形式で返します。 この拡張は次のエンドポイントを含みます。 @@ -1430,98 +1695,116 @@ lifecycle requestor に address のフィールドを追加します。 * `GET /1.0/metrics` ## `image_source_project` + `POST /1.0/images` に `project` フィールドを追加し、イメージコピー時にコピー元プロジェクトを設定できるようにします。 ## `clustering_config` + クラスタメンバーに `config` プロパティを追加し、キー・バリュー・ペアを設定可能にします。 ## `network_peer` + ネットワークピアリングを追加し、 OVN ネットワーク間のトラフィックが OVN サブシステムの外に出ずに通信できるようにします。 ## `linux_sysctl` + `linux.sysctl.*` 設定キーを追加し、ユーザーが一コンテナ内の一部のカーネルパラメータを変更できるようにします。 ## `network_dns` + 組み込みの DNS サーバとゾーン API を追加し、 LXD インスタンスに DNS レコードを提供します。 以下のサーバ設定キーが追加されます。 - - `core.dns_address` +* `core.dns_address` 以下のネットワーク設定キーが追加されます。 - - `dns.zone.forward` - - `dns.zone.reverse.ipv4` - - `dns.zone.reverse.ipv6` +* `dns.zone.forward` +* `dns.zone.reverse.ipv4` +* `dns.zone.reverse.ipv6` 以下のプロジェクト設定キーが追加されます。 - - `restricted.networks.zones` +* `restricted.networks.zones` DNS ゾーンを管理するために下記の REST API が追加されます。 - - `/1.0/network-zones` (GET, POST) - - `/1.0/network-zones/` (GET, PUT, PATCH, DELETE) +* `/1.0/network-zones` (GET, POST) +* `/1.0/network-zones/` (GET, PUT, PATCH, DELETE) ## `ovn_nic_acceleration` + OVN NIC に `acceleration` 設定キーを追加し、ハードウェアオフロードを有効にするのに使用できます。 設定値は `none` または `sriov` です。 ## `certificate_self_renewal` + これはクライアント自身の信頼証明書の更新のサポートを追加します。 ## `instance_project_move` + これは `POST /1.0/instances/NAME` API に `project` フィールドを追加し、インスタンスをプロジェクト間で簡単に移動できるようにします。 ## `storage_volume_project_move` + これはストレージボリュームのプロジェクト間での移動のサポートを追加します。 ## `cloud_init` + これは以下のキーを含む `project` 設定キー名前空間を追加します。 - - `cloud-init.vendor-data` - - `cloud-init.user-data` - - `cloud-init.network-config` +* `cloud-init.vendor-data` +* `cloud-init.user-data` +* `cloud-init.network-config` これはまた `devlxd` にインスタンスのデバイスを表示する `/1.0/devices` エンドポイントを追加します。 ## `network_dns_nat` + これはネットワークゾーン (DNS) に `network.nat` を設定オプションとして追加します。 デフォルトでは全てのインスタンスの NIC のレコードを生成するという現状の挙動になりますが、 `false` に設定すると外部から到達可能なアドレスのレコードのみを生成するよう LXD に指示します。 ## `database_leader` + クラスタ・リーダーに設定される `database-leader` ロールを追加します。 ## `instance_all_projects` + 全てのプロジェクトのインスタンス表示のサポートを追加します。 ## `clustering_groups` + クラスタ・メンバーのグループ化のサポートを追加します。 これは以下の新しいエンドポイントを追加します。 - - `/1.0/cluster/groups` (GET, POST) - - `/1.0/cluster/groups/` (GET, POST, PUT, PATCH, DELETE) +* `/1.0/cluster/groups` (GET, POST) +* `/1.0/cluster/groups/` (GET, POST, PUT, PATCH, DELETE) 以下のプロジェクトの制限が追加されます。 - - `restricted.cluster.groups` +* `restricted.cluster.groups` ## `ceph_rbd_du` + Ceph ストレージブールに `ceph.rbd.du` という Boolean の設定を追加します。 実行に時間がかかるかもしれない `rbd du` の呼び出しの使用を無効化できます。 ## `instance_get_full` + これは `GET /1.0/instances/{name}` に `recursion=1` のモードを追加します。 これは状態、スナップショット、バックアップの構造体を含む全てのインスタンスの構造体が取得できます。 ## `qemu_metrics` + これは `security.agent.metrics` という Boolean 値を追加します。デフォルト値は `true` です。 `false` に設定するとメトリクスや他の状態の取得のために `lxd-agent` に接続することはせず、 QEMU からの統計情報に頼ります。 ## `gpu_mig_uuid` + NVIDIA `470+` ドライバ (例. `MIG-74c6a31a-fde5-5c61-973b-70e12346c202`) で使用される MIG UUID 形式のサポートを追加します。 `MIG-` の接頭辞は省略できます。 @@ -1529,147 +1812,225 @@ NVIDIA `470+` ドライバ (例. `MIG-74c6a31a-fde5-5c61-973b-70e12346c202`) で 同時には設定できません。 ## `event_project` + イベントの API にイベントが属するプロジェクトを公開します。 ## `clustering_evacuation_live` + `cluster.evacuate` への設定値 `live-migrate` を追加します。 これはクラスタ待避の際にインスタンスのライブマイグレーションを強制します。 ## `instance_allow_inconsistent_copy` + `POST /1.0/instances` のインスタンスソースに `allow_inconsistent` フィールドを追加します。 `true` の場合、 `rsync` はコピーからインスタンスを生成するときに `Partial transfer due to vanished source files` (code 24) エラーを無視します。 ## `network_state_ovn` + これにより、`/1.0/networks/NAME/state` APIに `ovn` セクションが追加されます。これにはOVNネットワークに関連する追加の状態情報が含まれます: -- chassis (シャーシ) + +* chassis (シャーシ) ## `storage_volume_api_filtering` + ストレージボリュームの GET リクエストの結果をフィルタリングする機能を追加します。 ## `image_restrictions` + この拡張機能は、イメージのプロパティに、イメージの制限やホストの要件を追加します。これらの要件は インスタンスとホストシステムとの互換性を決定するのに役立ちます。 ## `storage_zfs_export` + `zfs.export` を設定することで、プールのアンマウント時に zpool のエクスポートを無効にする機能を導入しました。 ## `network_dns_records` + network zones (DNS) APIを拡張し、カスタムレコードの作成と管理機能を追加します。 これにより、以下が追加されます。 - - `GET /1.0/network-zones/ZONE/records` - - `POST /1.0/network-zones/ZONE/records` - - `GET /1.0/network-zones/ZONE/records/RECORD` - - `PUT /1.0/network-zones/ZONE/records/RECORD` - - `PATCH /1.0/network-zones/ZONE/records/RECORD` - - `DELETE /1.0/network-zones/ZONE/records/RECORD` +* `GET /1.0/network-zones/ZONE/records` +* `POST /1.0/network-zones/ZONE/records` +* `GET /1.0/network-zones/ZONE/records/RECORD` +* `PUT /1.0/network-zones/ZONE/records/RECORD` +* `PATCH /1.0/network-zones/ZONE/records/RECORD` +* `DELETE /1.0/network-zones/ZONE/records/RECORD` ## `storage_zfs_reserve_space` + `quota`/`refquota` に加えて、ZFSプロパティの `reservation`/`refreservation` を設定する機能を追加します。 ## `network_acl_log` + ACL ファイアウォールのログを取得するための API `GET /1.0/networks-acls/NAME/log` を追加します。 ## `storage_zfs_blocksize` + ZFS ストレージボリュームに新しい `zfs.blocksize` プロパティを導入し、ボリュームのブロックサイズを設定できるようになります。 ## `metrics_cpu_seconds` + LXDが使用するCPU時間をミリ秒ではなく秒単位で出力するように修正されたかどうかを検出するために使用されます。 ## `instance_snapshot_never` + `snapshots.schedule`に`@never`オプションを追加し、継承を無効にすることができます。 ## `certificate_token` + トラストストアに、トラストパスワードに代わる安全な手段として、トークンベースの証明書を追加します。 これは `POST /1.0/certificates` に `token` フィールドを追加します。 ## `instance_nic_routed_neighbor_probe` + これは `routed` NIC が親のネットワークが利用可能かを調べるために IP 近傍探索するのを無効化できるようにします。 `ipv4.neighbor_probe` と `ipv6.neighbor_probe` の NIC 設定を追加します。未指定の場合のデフォルト値は `true` です。 ## `event_hub` + これは `event-hub` というクラスタメンバの役割と `ServerEventMode` 環境フィールドを追加します。 ## `agent_nic_config` + これを `true` に設定すると、仮想マシンの起動時に `lxd-agent` がインスタンスの NIC デバイスの名前と MTU を変更するための NIC 設定を適用します。 ## `projects_restricted_intercept` + `restricted.container.intercept` という設定キーを追加し通常は安全なシステムコールのインターセプションオプションを可能にします。 ## `metrics_authentication` + `core.metrics_authentication` というサーバ設定オプションを追加し `/1.0/metrics` のエンドポイントをクライアント認証無しでアクセスすることを可能にします。 ## `images_target_project` + コピー元とは異なるプロジェクトにイメージをコピーできるようにします。 ## `cluster_migration_inconsistent_copy` + `POST /1.0/instances/` に `allow_inconsistent` フィールドを追加します。 `true` に設定するとクラスタメンバー間で不整合なコピーを許します。 ## `cluster_ovn_chassis` + `ovn-chassis` というクラスタロールを追加します。これはクラスタメンバーが OVN シャーシとしてどう振る舞うかを指定できるようにします。 ## `container_syscall_intercept_sched_setscheduler` + `security.syscalls.intercept.sched_setscheduler` を追加し、コンテナ内の高度なプロセス優先度管理を可能にします。 ## `storage_lvm_thinpool_metadata_size` + `storage.thinpool_metadata_size` により thin pool のメタデータボリュームサイズを指定できるようにします。 指定しない場合のデフォルトは LVM が適切な thin pool のメタデータボリュームサイズを選択します。 ## `storage_volume_state_total` + これは `GET /1.0/storage-pools/{name}/volumes/{type}/{volume}/state` API に `total` フィールドを追加します。 ## `instance_file_head` + `/1.0/instances/NAME/file` に HEAD を実装します。 ## `instances_nic_host_name` + `instances.nic.host_name` サーバ設定キーを追加します。これは `random` か `mac` を指定できます。 指定しない場合のデフォルト値は `random` です。 `random` に設定するとランダムなホストインタフェース名を使用します。 `mac` に設定すると `lxd1122334455` の形式で名前を生成します。 ## `image_copy_profile` + イメージをコピーする際にプロファイルの組を修正できるようにします。 ## `container_syscall_intercept_sysinfo` + `security.syscalls.intercept.sysinfo` を追加し `sysinfo` システムコールで cgroup ベースのリソース使用状況を追加できるようにします。 ## `clustering_evacuation_mode` + 退避リクエストに `mode` フィールドを追加します。 これにより従来 `cluster.evacuate` で設定されていた退避モードをオーバーライドできます。 ## `resources_pci_vpd` + PCI リソースエントリに VPS 構造体を追加します。 この構造体には完全な製品名と追加の設定キーバリューペアを含むベンダー提供のデータが含まれます。 ## `qemu_raw_conf` + 生成された qemu.conf の指定したセクションをオーバライドするための `raw.qemu.conf` 設定キーを追加します。 ## `storage_cephfs_fscache` + CephFS プール上の `fscache`/`cachefilesd` をサポートするための `cephfs.fscache` 設定オプションを追加します。 ## `network_load_balancer` + これはネットワークのロードバランサー機能を追加します。 `ovn` ネットワークで外部 IP アドレス上にポートを定義し、ポートから対応するネットワーク内部の単一または複数の内部 IP にトラフィックをフォワードできます。 ## `vsock_api` + これは双方向の vsock インタフェースを導入し、 lxd-agent と LXD サーバがよりよく連携できるようにします。 ## `instance_ready_state` + インスタンスに新しく `Ready` 状態を追加します。これは `devlxd` を使って設定できます。 ## `network_bgp_holdtime` + 特定のピアの BGP ホールドタイムを制御するために `bgp.peers..holdtime` キーを追加します。 ## `storage_volumes_all_projects` + 全てのプロジェクトのストレージボリュームを一覧表示できるようにします。 ## `metrics_memory_oom_total` + `/1.0/metrics` API に `lxd_memory_OOM_kills_total` メトリックを追加します。 メモリーキラー (`OOM`) が発動された回数を報告します。 ## `storage_buckets` + storage bucket API を追加します。ストレージプールのために S3 オブジェクトストレージのバケットの管理をできるようにします。 + +## `storage_buckets_create_credentials` + +これはバケット作成時に管理者の初期クレデンシャルを返すようにストレージバケット API を更新します。 + +## `metrics_cpu_effective_total` + +これは `lxd_cpu_effective_total` メトリックを `/1.0/metrics` API に追加します。 +有効な CPU の総数を返します。 + +## `projects_networks_restricted_access` + +プロジェクト内でアクセスできるネットワークを (カンマ区切りリストで) 示す `restricted.networks.access` プロジェクト設定キーを追加します。 +指定しない場合は、全てのネットワークがアクセスできます (後述の `restricted.devices.nic` 設定でも許可されている場合)。 + +これはまたプロジェクトの `restricted.devices.nic` 設定で制御されるネットワークアクセスにも変更をもたらします。 + +* `restricted.devices.nic` が `managed` に設定される場合 (未設定時のデフォルト), マネージドネットワークのみがアクセスできます。 +* `restricted.devices.nic` が `allow` に設定される場合、全てのネットワークがアクセスできます (`restricted.networks.access` 設定に依存)。 +* `restricted.devices.nic` が `block` に設定される場合、どのネットワークにもアクセスできません。 + +## `storage_buckets_local` + +これは `core.storage_buckets_address` グローバル設定を指定することでローカルストレージプール上のストレージバケットを使用できるようにします。 + +## `loki` + +これはライフサイクルとロギングのイベントを Loki サーバに送れるようにします。 + +以下のグローバル設定キーを追加します。 + +* `loki.api.ca_cert`: イベントを Loki サーバに送る際に使用する CA 証明書。 +* `loki.api.url`: Loki サーバのURL。 +* `loki.auth.username` と `loki.auth.password`: Loki が BASIC 二症を有効にしたリバースプロキシの背後にいる場合に使用。 +* `loki.labels`: Loki イベントのラベルに使用されるカンマ区切りリストの値。 +* `loki.loglevel`: Loki サーバに送るイベントの最低のログレベル。 +* `loki.types`: Loki サーバに送られるイベントのタイプ (`lifecycle` および/または `logging`)。 diff --git a/doc/architectures.md b/doc/architectures.md index 0d79557..aaa1bae 100644 --- 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 index 2d5582d..d1ccac1 100644 --- 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 index ad4c19e..3fdc029 100644 --- 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 index 180e04d..5147ccd 100644 --- 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 index e9682ec..64005f1 100644 --- a/doc/clustering.md +++ b/doc/clustering.md @@ -43,6 +43,7 @@ lxc cluster add 参加トークンは持っていないがトラスト・パスワードを持っている場合は参加トークンを持っているかの質問に `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 index 46066ea..28ca597 100644 --- a/doc/configuration.md +++ b/doc/configuration.md @@ -1,4 +1,5 @@ # 設定 + LXD は次のコンポーネントの設定を保管しています。 ```{toctree} @@ -9,6 +10,6 @@ containers プリシード YAML profiles プロジェクト -サーバ +サーバ設定 仮想マシン ``` diff --git a/doc/container-environment.md b/doc/container-environment.md index 78de9fa..bc763f8 100644 --- 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 index ea5060c..059ab26 100644 --- 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 index 9d4f94a..9b96b93 100644 --- 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` サービスが設定されている場合はバージョン衝突を避けるためにサービスを無効にすると良いでしょう。 diff --git a/doc/daemon-behavior.md b/doc/daemon-behavior.md index fb6cca9..ab6917b 100644 --- a/doc/daemon-behavior.md +++ b/doc/daemon-behavior.md @@ -4,6 +4,7 @@ 振る舞いの一部を取り扱います。 ## 起動 + 起動する度に LXD はディレクトリ構造が存在することをチェックします。 もし存在しない場合は、必要なディレクトリを作成し、キーペアを生成し、 データベースを初期化します。 @@ -15,7 +16,9 @@ 開始します。 ## シグナル処理 + ### `SIGINT`, `SIGQUIT`, `SIGTERM` + これらのシグナルについては LXD は一時的に停止し、後に再開してインスタンスの 処理を継続することを想定しています。 @@ -23,6 +26,7 @@ でしょう。 ### `SIGPWR` + LXD にホストがシャットダウンしようとしていることを伝えます。 LXD は全てのインスタンスをクリーンにシャットダウンしようと試みます。30秒後、 @@ -33,4 +37,5 @@ LXD は残りのインスタンスを kill します。 元の電源状態を記録しておきます。 ### `SIGUSR1` + メモリプロファイルを `--memprofile` で指定したファイルにダンプします。 diff --git a/doc/database.md b/doc/database.md index 5cfab21..858edc4 100644 --- a/doc/database.md +++ b/doc/database.md @@ -5,6 +5,7 @@ relatedlinks: https://github.com/canonical/dqlite # データベース ## イントロダクション + そもそも、なぜデータベースなのでしょう？ 従来 LXC で行われていたように設定と状態をそれぞれのインスタンスのディレクトリに @@ -12,7 +13,6 @@ relatedlinks: https://github.com/canonical/dqlite 持っています。これによりすべてのインスタンスの設定に対する問い合わせをとても 高速に行えます。 - 例えば、 「どのインスタンスが `br0` を使っているのか」というかなり分かりやすい問いが あります。この問いにデータベース無しで答えるとすると、 LXD は一つ一つの インスタンスに対して、設定を読み込んでパースし、そこにどのネットワークデバイスが @@ -23,8 +23,8 @@ relatedlinks: https://github.com/canonical/dqlite 代わりにデータベースを使うことで、非常に単純なクエリでキャッシュ済みの データベースにアクセスするだけで良くなるのです。 - ## データベースエンジン + LXD はクラスタリングをサポートし、クラスタの全てのメンバは同じデータベースの 状態を共有する必要があるため、データベースエンジンは SQLite の [分散対応バージョン](https://github.com/canonical/dqlite) をベースにしています。 @@ -50,12 +50,14 @@ LXD は単なる SQLite のデータベース (「ローカル」データベー アップグレード前の状態に戻す必要がある場合は、このバックアップを使うことができます。 ## データベースのデータとスキーマをダンプする + データベースのデータまたはスキーマの SQL テキスト形式でのダンプを取得したい場合は、 `lxd sql [.dump|.schema]` コマンドを使ってください。これにより sqlite3 コマンドラインツールの `.dump` または `.schema` ディレクティブと同じ出力を 生成できます。 ## コンソールからカスタムクエリを実行する + ローカルまたはグローバルデータベースに SQL クエリ (例 `SELECT`, `INSERT`, `UPDATE`) を 実行する必要がある場合、 `lxd sql` コマンドを使うことができます (詳細は `lxd sql --help` を実行してください)。 @@ -66,6 +68,7 @@ sqlite3 コマンドラインツールの `.dump` または `.schema` ディレ [フォーラム](https://discuss.linuxcontainers.org/) に投稿)。 ## LXD デーモン起動時にカスタムクエリを実行する + SQL のデータマイグレーションのバグあるいは関連する問題のために アップグレード後に LXD デーモンが起動に失敗する場合、 壊れたアップデートを修復するクエリを含んだ `.sql` ファイルを @@ -83,6 +86,7 @@ SQL のデータマイグレーションのバグあるいは関連する問題 上記の通り、まず LXD チームに相談してみてください。 ## クラスタデータベースをディスクに同期 + クラスタデータベースの内容をディスクにフラッシュしたいなら、 `lxd sql global .sync` コマンドを使ってください。これは SQLite そのままの 形式のデータベースのファイルを `./database/global/db.bin` に書き込みます。 diff --git a/doc/debugging.md b/doc/debugging.md index a5771a8..7578400 100644 --- a/doc/debugging.md +++ b/doc/debugging.md @@ -30,7 +30,6 @@ lxd --debug --group lxd 上記の `--group lxd` は非特権ユーザーにアクセス権限を与えるために必要です。 - ## ローカルソケット経由でのREST API サーバサイドでLXDとやりとりするのに最も簡単な方法はローカルソケットを @@ -50,7 +49,6 @@ curl --unix-socket /var/snap/lxd/common/lxd/unix.socket lxd/1.0 | jq . 利用可能なAPIについては [RESTful API](rest-api.md) をご参照ください。 - ## HTTPS経由でのREST API [LXDへのHTTPS接続](security.md)には有効なクライアント証明書が diff --git a/doc/dev-lxd.md b/doc/dev-lxd.md index a45f5e9..dba4da4 100644 --- a/doc/dev-lxd.md +++ b/doc/dev-lxd.md @@ -1,4 +1,8 @@ # インスタンス〜ホスト間の通信 + +```{youtube} https://www.youtube.com/watch?v=xZSnqqWykmo +``` + ホストされているワークロード (インスタンス) とそのホストのコミュニケーションは 厳密には必要とされているわけではないですが、とても便利な機能です。 @@ -8,7 +12,12 @@ LXD ではこの機能は `/dev/lxd/sock` というノードを通して実装 このファイルはインスタンス内部のプロセスが接続できる Unix ソケットです。 マルチスレッドで動いているので複数のクライアントが同時に接続できます。 +```{note} +インスタンスのソケットへのアクセスを許可するには [`security.devlxd`](instance-configuration) を `true` (これがデフォルトです) に設定する必要があります。 +``` + ## 実装詳細 + ホストでは LXD は `/var/lib/lxd/devlxd/sock` をバインドして新しいコネクションの リッスンを開始します。 @@ -20,11 +29,13 @@ LXD は各々のインスタンスに異なるソケットをバインドする ファイルディスクリプタ数の上限にすぐ到達してしまいます。 ## 認証 + `/dev/lxd/sock` への問い合わせは依頼するインスタンスに関連した情報のみを 返します。リクエストがどこから来たかを知るために、 LXD は初期のソケットの ユーザクレデンシャルを取り出し、 LXD が管理しているインスタンスのリストと比較します。 ## プロトコル + `/dev/lxd/sock` のプロトコルは JSON メッセージを用いたプレーンテキストの HTTP であり、 LXD プロトコルのローカル版に非常に似ています。 @@ -32,19 +43,24 @@ HTTP であり、 LXD プロトコルのローカル版に非常に似ていま 認証サポートはありません。 ## REST-API + ### API の構造 - * `/` - * `/1.0` - * `/1.0/config` - * `/1.0/config/{key}` - * `/1.0/devices` - * `/1.0/events` - * `/1.0/images/{fingerprint}/export` - * `/1.0/meta-data` + +* `/` + * `/1.0` + * `/1.0/config` + * `/1.0/config/{key}` + * `/1.0/devices` + * `/1.0/events` + * `/1.0/images/{fingerprint}/export` + * `/1.0/meta-data` ### API の詳細 + #### `/` + ##### GET + * 説明: サポートされている API のリスト * 出力: サポートされている API エンドポイント URL のリスト (デフォルトでは ['/1.0']`) @@ -55,8 +71,11 @@ HTTP であり、 LXD プロトコルのローカル版に非常に似ていま "/1.0" ] ``` + #### `/1.0` + ##### GET + * 説明: 1.0 API についての情報 * 出力: dict 形式のオブジェクト @@ -72,21 +91,24 @@ HTTP であり、 LXD プロトコルのローカル版に非常に似ていま ``` #### PATCH - * 説明: インスタンスの状態を更新する (有効な状態は `Ready` と `Started`) - * 戻り値: 無し - 入力: +* 説明: インスタンスの状態を更新する (有効な状態は `Ready` と `Started`) +* 戻り値: 無し + +入力: - ```json - { - "state": "Ready" - } +```json +{ + "state": "Ready" +} ``` #### `/1.0/config` + ##### GET - * 説明: 設定キーの一覧 - * 出力: 設定キー URL のリスト + +* 説明: 設定キーの一覧 +* 出力: 設定キー URL のリスト 設定キーの名前はインスタンスの設定の名前と一致するようにしています。 しかし、設定の namespace の全てが `/dev/lxd/sock` にエクスポート @@ -104,16 +126,20 @@ HTTP であり、 LXD プロトコルのローカル版に非常に似ていま ``` #### `/1.0/config/` + ##### GET - * 説明: そのキーの値 - * 出力: プレーンテキストの値 + +* 説明: そのキーの値 +* 出力: プレーンテキストの値 戻り値: blah #### `/1.0/devices` + ##### GET + * 説明: インスタンスのデバイスのマップ * 出力: dict @@ -136,18 +162,20 @@ HTTP であり、 LXD プロトコルのローカル版に非常に似ていま #### `/1.0/events` + ##### GET - * 説明: この API ではプロトコルが WebSocket にアップグレードされます。 - * 出力: 無し (イベントのフローが終わることがなくずっと続く) + +* 説明: この API ではプロトコルが WebSocket にアップグレードされます。 +* 出力: 無し (イベントのフローが終わることがなくずっと続く) サポートされる引数は以下の通りです。 - * type: 購読する通知の種別のカンマ区切りリスト (デフォルトは all) +* type: 購読する通知の種別のカンマ区切りリスト (デフォルトは all) 通知の種別には以下のものがあります。 - * `config` (あらゆる `user.*` 設定キーの変更) - * `device` (あらゆるデバイスの追加、変更、削除) +* `config` (あらゆる `user.*` 設定キーの変更) +* `device` (あらゆるデバイスの追加、変更、削除) この API は決して終了しません。それぞれの通知は別々の JSON の dict として @@ -181,20 +209,23 @@ HTTP であり、 LXD プロトコルのローカル版に非常に似ていま ``` #### `/1.0/images//export` + ##### GET - * 説明: 公開されたあるいはキャッシュされたイメージをホストからダウンロードする - * 出力: 生のイメージあるいはエラー - * アクセス権: `security.devlxd.images` を `true` に設定する必要があります + +* 説明: 公開されたあるいはキャッシュされたイメージをホストからダウンロードする +* 出力: 生のイメージあるいはエラー +* アクセス権: `security.devlxd.images` を `true` に設定する必要があります 戻り値: LXD デーモン API の /1.0/images//export を参照してください。 - #### `/1.0/meta-data` + ##### GET - * 説明: cloud-init と互換性のあるコンテナのメタデータ - * 出力: cloud-init のメタデータ + +* 説明: cloud-init と互換性のあるコンテナのメタデータ +* 出力: cloud-init のメタデータ 戻り値: diff --git a/doc/doc-cheat-sheet.md b/doc/doc-cheat-sheet.md index 5af24e5..80f38bc 100644 --- a/doc/doc-cheat-sheet.md +++ b/doc/doc-cheat-sheet.md @@ -63,7 +63,9 @@ myst: ## コードブロック -コードブロックの開始と終了は3つのバックティックで行います。`` ``` `` +コードブロックの開始と終了は3つのバックティックで行います。 + + ``` バックティックの後にコード言語を指定して、特定のレキサーを強制することもできますが、多くの場合、デフォルトのレキサーで十分に機能します。 @@ -74,25 +76,31 @@ myst: * - 入力 - 出力 * - ```` + ``` # コードブロックのデモ コードを表示します。 - 例：真 ``` + ```` + - ``` # コードブロックのデモ コードを表示します。 - 例：真 ``` + * - ```` ``yaml # コードブロックのデモ コードを表示します。 - 例：真 ``` + ```` - - ``yaml + + - ```yaml # コードブロックのデモ コードを表示します。 - 例：真 @@ -107,14 +115,22 @@ myst: * - 入力 - 出力 -* - ````` +* - + ````` + ```` ``` ```` + ````` - - ```` + + - + ```` + ``` + ```` + ``` ## リンク @@ -167,12 +183,12 @@ URL をテキストとして表示し、リンクされないようにするに - {doc}`index` - {doc}`index` - 望ましいのは -* - `[](インデックス)` - - [](インデックス) +* - `[](インデクス)` + - [](インデクス) - - 使用しないでください。 -* - `[LXDドキュメント](インデックス)` - - [LXDドキュメント](インデックス) +* - `[LXDドキュメント](インデクス)` + - [LXDドキュメント](インデクス) - LXDドキュメンテーション](index) - リンクテキストをオーバーライドするときに好ましい。 * - `` {doc}`LXD documentation ` `` @@ -191,6 +207,7 @@ URL をテキストとして表示し、リンクされないようにするに ドキュメント内のセクション（同じページまたは別のページ）を参照するには、セクションにターゲットを追加してそのターゲットを参照するか、自動生成されたアンカーとファイル名を組み合わせて使用します。 以下のような規約を守ってください。 + - 中心となるセクションにはターゲットを追加し、「典型的な」リンク先であることから、頻繁にリンクされることが予想されます。単発的なリンクには、自動生成されたアンカーを使用する。 - 必要な場合のみリンクテキストを上書きする。セクションのタイトルをリンクテキストとして使用できる場合は、そうしてください。タイトルが変更された場合、テキストは自動的に更新されます。 - リンクテキストを、自動生成されるテキストと同じもので「上書き」してはいけません。 @@ -200,8 +217,7 @@ URL をテキストとして表示し、リンクされないようにするに ドキュメント内の任意の場所にターゲットを追加することができます。ただし、対象となる要素に見出しやタイトルがない場合は、リンクテキストを指定する必要があります。 (a_random_target)= - -``{list-table}. +```{list-table}. :header-rows: 1 * - 入力 @@ -324,6 +340,7 @@ orphan: true ``` 以下の規則に従ってください。 + - 番号付きリストでは、ステップ番号を自動的に生成するために、すべての項目に ``1.`` を使用してください。 - 順不同のリストには`-`を使用してください。入れ子のリストを使用する場合は、入れ子のレベルに `*` を使用します。 @@ -469,6 +486,7 @@ orphan: true ``` 以下のような規約があります。 + - `doc` フォルダー内の画像は、パスを `/` で始めてください (例: `/images/image.png`)。 - スクリーンショットはPNG形式、グラフィックはSVG形式を使用してください。 @@ -477,6 +495,7 @@ orphan: true あまり多くのマークアップや特殊なフォーマットをせずに文や段落を再利用するには、置換を使用します。 置換機能は以下の場所で定義できます。 + - `substitutions.yaml` というファイルがあります。このファイルで定義された置換は、すべてのドキュメントページで利用できます。 - 次のような形式の単一のファイルの先頭に。 @@ -523,50 +542,61 @@ orphan: true * - 入力 - 出力 * - ```` + % Include parts of the content from file [../README.md](../README.md) ```{include} ../README.md :start-after: Installing LXD from packages :end-before: ``` + ```` - - % Include parts of the content from file [../README.md](../README.md) + + - + % Include parts of the content from file [../README.md](../README.md) ```{include} ../README.md :start-after: Installing LXD from packages :end-before: ``` + ````` 以下の規則に従ってください。 + - ファイルのインクルードはGitHubでは機能しません。そのため、必ずインクルードしたファイルにリンクするコメントを追加してください。 - テキストの一部を選択するには、開始点と終了点にHTMLコメントを追加し、可能であれば `:start-after:` と `:end-before:` を使用します。必要に応じて、`:start-after:`と`:end-before:`を`:start-line:`と`:end-line:`と組み合わせることができます。ただし`:start-line:`と`:end-line:`だけの使用はエラーになりやすいです。 ## タブ - ``````{list-table} :header-rows: 1 * - 入力 - 出力 * - ````` + ````{tabs} ```{group-tab} Tab 1 Content Tab 1 ``` + ```{group-tab} Tab 2 Content Tab 2 ``` + ```` + ````` + - ````{tabs} ```{group-tab} Tab 1 Content Tab 1 ``` + ```{group-tab} Tab 2 Content Tab 2 @@ -590,11 +620,13 @@ rSTには詳細セクションのサポートはありませんが、HTMLを挿 Content ``` + -
Details Content
+ ``` ## 用語集 @@ -607,17 +639,21 @@ rSTには詳細セクションのサポートはありませんが、HTMLを挿 * - 入力 - 出力 * - ```` + ```{glossary} example term Definition of the example term. ``` + ```` + - ```{glossary} example term Definition of the example term. ``` + * - ``{term}`example term` `` - {term}`example term` ````` diff --git a/doc/environment.md b/doc/environment.md index a97aaf7..155cc26 100644 --- a/doc/environment.md +++ b/doc/environment.md @@ -1,9 +1,13 @@ # 環境変数 + +## イントロダクション + 以下の環境変数を設定することで、 LXD のクライアントとデーモンを ユーザーの環境に適合させることができ、いくつかの高度な機能を有効または 無効にすることができます。 ## クライアントとサーバ共通の環境変数 + 名前 | 説明 :--- | :---- `LXD_DIR` | LXD のデータディレクトリ @@ -13,6 +17,7 @@ `no_proxy` | プロキシが不要なドメイン、IPアドレスあるいは CIDR レンジのリスト ## クライアントの環境変数 + 名前 | 説明 :--- | :---- `EDITOR` | 使用するテキストエディタ @@ -22,6 +27,7 @@ `LXC_REMOTE` | 使用するリモートの名前（設定されたデフォルトのリモートよりも優先されます） ## サーバの環境変数 + 名前 | 説明 :--- | :---- `LXD_EXEC_PATH` | (サブコマンド実行時に使用される) LXD 実行ファイルのフルパス diff --git a/doc/events.md b/doc/events.md index 356636b..a4ad383 100644 --- a/doc/events.md +++ b/doc/events.md @@ -1,16 +1,21 @@ # イベント -## はじめに +## イントロダクション + イベントとは LXD 上で発生したアクションに関するメッセージです。 `/1.0/events` の API エンドポイントを直接使うか `lxc monitor` コマンドを使うことでウェブソケットに接続しログとライフサイクルメッセージがストリーム出力されます。 ## イベント種別 + LXD は現在 3 つのイベント種別をサポートします。 + - `logging`: サーバのログレベルに関係なく全てのログメッセージを表示します。 - `operation`: 作成から完了までの（状態と進捗メタデータの更新を含む）全ての実行中のオペレーションを表示します。 - `lifecycle`: LXD 上で発生する特定のアクションの監査証跡を表示します。 ## イベント構造 + ### 例: + ```yaml location: cluster_name metadata: @@ -22,17 +27,20 @@ metadata: timestamp: "2021-03-14T00:00:00Z" type: lifecycle ``` + - `location`: クラスタメンバー名（クラスタであれば）。 - `timestamp`: RFC3339 形式のイベント発生時刻。 - `type`: イベント種別（`logging`, `operation`, `lifecycle` のいずれか）。 - `metadata`: 特定のイベント種別に関する情報。 ### logging イベントの構造 + - `message`: ログメッセージ。 - `level`: ログのログレベル。 - `context`: イベントに含まれる追加情報。 ### operation イベントの構造 + - `id`: オペレーションの UUID - `class`: オペレーション種別（`task`, `token`, `websocket` のいずれか）。 - `description`: オペレーションの説明。 @@ -47,6 +55,7 @@ type: lifecycle - `location`: クラスタメンバー名（クラスタであれば）。 ### ライフサイクルイベントの構造 + - `action`: 発生したライフサイクルアクション。 - `requestor`: 誰がリクエストを作成したかの情報（該当するものがあれば）。 - `source`: アクションの対象のパス。 @@ -103,6 +112,7 @@ type: lifecycle | `instance-metadata-template-retrieved` | インスタンスのイメージテンプレートファイルがダウンロードされた。 | `path`: ファイルの相対パス。 | | `instance-metadata-updated` | インスタンスのイメージメタデータが変更された。 | | | `instance-paused` | インスタンスが休止状態にされた。 | | +| `instance-ready` | インスタンスが準備完了になった。 | | | `instance-renamed` | インスタンスがリネームされた。 | `old_name`: 以前の名前。 | | `instance-restarted` | インスタンスが再起動された。 | | | `instance-restored` | インスタンスがスナップショットから復元された。 | `snapshot`: 復元されたスナップショット名。 | @@ -151,11 +161,11 @@ type: lifecycle | `storage-volume-backup-deleted` | ストレージボリュームのバックアップが削除された。 | | | `storage-volume-backup-renamed` | ストレージボリュームのバックアップがリネームされた。 | `old_name`: 以前の名前。 | | `storage-volume-backup-retrieved` | ストレージボリュームのバックアップがダウンロードされた。 | | -| `storage-volume-created` | 新しいストレージボリュームが作成された。 | `type`: `container`, `virtual-machine`, `image`, `custom` のいずれか。 | +| `storage-volume-created` | 新しいストレージボリュームが作成された。 | `type`: `container`, `virtual-machine`, `image`, `custom` のいずれか。 | | `storage-volume-deleted` | ストレージボリュームが削除された。 | | | `storage-volume-renamed` | ストレージボリュームがリネームされた。 | `old_name`: 以前の名前。 | | `storage-volume-restored` | ストレージボリュームがスナップショットから復元された。 | `snapshot`: 復元されたスナップショット名。 | -| `storage-volume-snapshot-created` | 新しいストレージボリュームスナップショットが作成された。 | `type`: `container`, `virtual-machine`, `image`, `custom` のいずれか。 | +| `storage-volume-snapshot-created` | 新しいストレージボリュームスナップショットが作成された。 | `type`: `container`, `virtual-machine`, `image`, `custom` のいずれか。 | | `storage-volume-snapshot-deleted` | ストレージボリュームのスナップショットが削除された。 | | | `storage-volume-snapshot-renamed` | ストレージボリュームのスナップショットがリネームされた。 | `old_name`: 以前の名前。 | | `storage-volume-snapshot-updated` | ストレージボリュームのスナップショットの設定が変更された。 | | diff --git a/doc/explanation/networks.md b/doc/explanation/networks.md index 0169e71..e37d2de 100644 --- a/doc/explanation/networks.md +++ b/doc/explanation/networks.md @@ -130,5 +130,6 @@ LXD は以下のネットワークタイプをサポートします。 OVN は適切な運用には共有された L2 のアップリンクネットワークが必要です。 このため、パブリッククラウドで LXD を動かしている場合は通常 OVN は使用できません。 ``` + - インスタンス NIC をマネージドネットワークに接続するためには、可能であれば `parent` プロパティより `network` プロパティを使用してください。 こうすることで、 NIC はネットワークの設定を引き継ぎ、 `nictype` を指定する必要がなくなります。 diff --git a/doc/explanation/performance_tuning.md b/doc/explanation/performance_tuning.md new file mode 100644 index 0000000..1b31f63 --- /dev/null +++ b/doc/explanation/performance_tuning.md @@ -0,0 +1,57 @@ +(performance-tuning)= +# パフォーマンスチューニング + +お使いの LXD 環境を本番稼働に移行する準備が出来たら、システムのパフォーマンスを最適化するためにいくらか時間を取るほうが良いです。 +パフォーマンスに影響を与えるいくつかの視点があります。 +お使いの LXD 環境を改善するためにチューニングするべき選択肢と設定を決定するのに以下の手順が役立ちます。 + +## ベンチマークを実行する + +LXD はシステムのパフォーマンスを評価するためにベンチマークツールを提供しています。 +このツールを使って複数のコンテナを初期化・起動し、システムがコンテナを作成するのに必要な時間を計測できます。 +異なる LXD の設定、システム設定、さらにはハードウェア構成に対して繰り返しツールを実行することで、パフォーマンスを比較し、どの設定が理想的か評価できます。 + +ツールを実行する手順については {ref}`benchmark-performance` を参照してください。 + +## インスタンスのメトリクスをモニターする + +% Include content from [../metrics.md](../metrics.md) +```{include} ../metrics.md + :start-after: + :end-before: +``` + +あなたのインスタンスが使用しているリソースを見積もるために定期的にメトリクスをモニターするほうが良いです。 +スパイクやボトルネックがある場合や、使用量のパターンが変化したり、設定を見直す必要がある場合に、これらの数値が役立ちます。 + +メトリクス収集についての詳細な情報は {ref}`instance-metrics` を参照してください。 + +## サーバ設定をチューニングする + +ほとんどの Linux ディストリビューションのデフォルトのカーネル設定は大量のコンテナや仮想マシンを稼働させるのに最適化されていません。 +ですので、デフォルトの設定で引き起こされる制限にひっかかるのを避けるため、関連する設定を確認、変更するほうが良いです。 + +これらの制限にひっかかかった場合の典型的なエラーは以下のようなものです。 + +* `Failed to allocate directory watch: Too many open files` +* ` : Too many open files` +* `failed to open stream: Too many open files in...` +* `neighbour: ndisc_cache: neighbor table overflow!` + +関連するサーバ設定と提案される値の一覧は {ref}`server-settings` を参照してください。 + +## ネットワーク帯域幅をチューニングする + +インスタンス間あるいは LXD ホストとインスタンス間で大量のローカルなアクティビティがある場合、あるいは高速なインターネット接続をお持ちの場合、 LXD のセットアップのネットワーク帯域幅を増やすことを検討すると良いです。 +これは送信と受信のキューの長さを拡張することで実現できます。 + +手順については {ref}`network-increase-bandwidth` を参照してください。 + +```{toctree} +:maxdepth: 1 +:hidden: + +パフォーマンスのベンチマーク <../howto/benchmark_performance> +帯域幅の拡大 <../howto/network_increase_bandwidth> +サーバ設定 <../reference/server_settings> +``` diff --git a/doc/explanation/storage.md b/doc/explanation/storage.md index 88c4a08..f7e55d6 100644 --- a/doc/explanation/storage.md +++ b/doc/explanation/storage.md @@ -1,8 +1,12 @@ -# ストレージプールとストレージボリュームについて +# ストレージプール、ボリューム、バケットについて LXD はデータを（イメージやインスタンスのように）コンテントタイプに応じて別のストレージボリュームに分けてストレージプールに保管します。 ストレージプールはデータを保管するためのディスクであり、ストレージボリュームは特定の目的に使用されるディスク上の別々のパーティションであると考えることも出来るでしょう。 +ストレージボリュームに加えて、ストレージバケットというものもあります。これは [Amazon {abbr}`S3 (Simple Storage Service)`](https://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html) プロトコルを使用します。 +ストレージボリュームと同様に、ストレージバケットはストレージプールの一部です。 + +(storage-pools)= ## ストレージプール 初期化時に、 LXD は最初のストレージプールを作成するためのプロンプトを表示します。 @@ -19,6 +23,11 @@ LXD はデータを（イメージやインスタンスのように）コンテ - [CephFS - `cephfs`](storage-cephfs) - [Ceph Object - `cephobject`](storage-cephobject) +さらなる情報については以下の how-to ガイドを参照してください。 + +- {ref}`howto-storage-pools` +- {ref}`howto-storage-create-instance` + (storage-location)= ### データストレージのロケーション @@ -40,11 +49,13 @@ LXD のデータをどこに保管するかは設定と選択したストレー この選択肢は `dir` ドライバ、 `btrfs` ドライバ (ホストが Btrfs で LXD に専用のサブボリュームを使用する場合)、 `zfs` ドライバ (ホストが ZFS で zpool 上で LXD に専用のデータセットを使用する場合) でサポートされます。 #### 専用のディスク/パーティション + メインのディスク上で LXD に空のパーティションを使用するか、ホストから完全に独立したストレージを保管する完全な専用のディスクを使用します。 この選択肢は `btrfs` ドライバ、 `lvm` ドライバ、 `zfs` ドライバでサポートされます。 #### ループディスク + LXD ではメインドライブ上にループファイルを作成して選択したストレージドライバでそれを使用できます。 この方法はディスクやパーティションを使用する方法と機能的には似ていますが、大きな 1 つのファイルをメインドライブとして使用する点が異なります。 これはそれぞれの書き込みがストレージドライバとメインドライブのファイルシステムを通過することを意味し、パフォーマンスは低くなります。 @@ -56,6 +67,7 @@ LXD ではメインドライブ上にループファイルを作成して選択 しかしサイズを増やすことはできます。 {ref}`storage-resize-pool` を参照してください。 ### リモートストレージ + `ceph`, `cephfs`, `cephobject` ドライバはデータを完全に独立な Ceph ストレージクラスターに保管します。これは別途セットアップが必要です。 (storage-default-pool)= @@ -86,9 +98,18 @@ LXD にはデフォルトストレージプールという概念はありませ (storage-volumes)= ## ストレージボリューム +```{youtube} https://www.youtube.com/watch?v=dvQ111pbqtk +``` + インスタンスを作成する際、 LXD は必要なストレージボリュームを自動的に作成します。 追加のストレージボリュームを作成することもできます。 +さらなる情報については以下の how-to ガイドを参照してください。 + +- {ref}`howto-storage-volumes` +- {ref}`howto-storage-move-volume` +- {ref}`howto-storage-backup-volume` + (storage-volume-types)= ### ストレージボリュームタイプ @@ -112,6 +133,8 @@ LXD にはデフォルトストレージプールという概念はありませ : インスタンスから分離して保管したいデータを保持する 1 つあるいは複数のカスタムストレージボリュームを追加できます。 カスタムストレージボリュームはインスタンス間で共有でき、インスタンスが削除されても残ります。 + バックアップやイメージを保管するためにカスタムストレージボリュームを使用することもできます。 + カスタムボリュームの作成時は使用するストレージプールを指定する必要があります。 (storage-content-types)= @@ -137,6 +160,16 @@ LXD にはデフォルトストレージプールという概念はありませ ストレージバケットは S3 プロトコルを使用してオブジェクトストレージの機能を提供します。 -それぞれのストレージバケットはそれ自身の URL を使ってアプリケーションから直接アクセスします。 +これはカスタムストレージボリュームと同様の方法で使用されます。 +しかし、ストレージボリュームとは異なり、ストレージバケットはインスタンスに紐付けされません。 +代わりに、アプリケーションはストレージバケットにその URL を使って直接アクセスできます。 + +それぞれのストレージバケットには 1 つまたは複数のアクセスキーが割り当てられ、アプリケーションはアクセスの際にこれを使う必要があります。 + +ストレージバケットはローカルのストレージ (`dir`, `btrfs`, `lvm` あるいは `zfs` プールの場合) あるいはリモートストレージ (`cephobject` プールの場合) 上に配置できます。 + +ローカルストレージドライバでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには、`core.storage_buckets_address` サーバ設定 ({ref}`server` 参照) を調整する必要があります。 + +さらなる情報については以下の how-to ガイドを参照してください。 -それぞれのストレージバケットには 1 つまたは複数のアクセスキーが割り当てられ、アプリケーションがアクセスする際にそれらのアクセスキーが使用されます。 +- {ref}`howto-storage-buckets` diff --git a/doc/faq.md b/doc/faq.md index 48d8ed3..5de2de6 100644 --- a/doc/faq.md +++ b/doc/faq.md @@ -3,6 +3,7 @@ ## 一般的な問題 ### LXD サーバをリモートからアクセス可能にするには？ + デフォルトでは LXD サーバはローカルの Unix ソケットのみをリッスンしているためネットワークからはアクセス可能ではありません。 リッスンする追加のアドレスを指定することでネットワークから LXD を利用可能にできます。 これは `core.https_address` 設定で実現できます。 @@ -23,6 +24,7 @@ lxc config set core.https_address 192.168.1.15 {ref}`security_remote_access` も参照してください。 ### HTTPS 経由で `lxc remote add` を実行したらパスワードを聞かれたがどうすればよいか？ + デフォルトではセキュリティ上の理由から LXD はパスワードを設定していないため、 `lxc remote add` でリモートは追加できません。 パスワードを設定するには LXD が実行中のホスト上で以下のコマンドを実行します。 @@ -40,28 +42,8 @@ lxc config trust add client.crt 詳細は {doc}`authentication` を参照してください。 -### LXD を使ってコンテナをマイグレートするには？ -ライブマイグレーションには [CRIU](https://criu.org) と呼ばれるツールを両方のホストにインストールする必要があります。 -Ubuntu では以下のコマンドでインストールできます。 - -```bash -sudo apt install criu -``` - -次に以下のコマンドでコンテナを起動します。 - -```bash -lxc launch ubuntu SOME-NAME -sleep 5s # コンテナの起動が完了するのをを待ちます。 -lxc move host1:SOME-NAME host2:SOME-NAME -``` - -これでコンテナがマイグレートされるはずです。 -マイグレーションはいまだ実験的な段階にあり環境によっては動かないかもしれないことに注意してください。 -動かない場合は `lxc-devel` メーリングリストに報告してください。 -そうすれば私たちが必要に応じて CRIU メーリングリストに報告します。 - ### 自分のホームディレクトリをコンテナ内にバインドマウントできますか？ + はい。ディスクデバイスを使って以下のようにすればできます。 ```bash @@ -70,9 +52,9 @@ lxc config device add container-name home disk source=/home/${USER} path=/home/u 非特権コンテナの場合は、以下のいずれかも必要です。 - - `lxc config device add` の実行に `shift=true` を指定する。これは `shiftfs` がサポートされているかに依存します（`lxc info` 参照）。 - - `raw.idmap` エントリーを使用する（[ユーザー名前空間 (user namespace) 用の ID のマッピング](userns-idmap.md) 参照）。 - - マウントしたいホームディレクトリに再帰的な POSIX ACL を設定する。 +- `lxc config device add` の実行に `shift=true` を指定する。これは `shiftfs` がサポートされているかに依存します（`lxc info` 参照）。 +- `raw.idmap` エントリーを使用する（[ユーザー名前空間 (user namespace) 用の ID のマッピング](userns-idmap.md) 参照）。 +- マウントしたいホームディレクトリに再帰的な POSIX ACL を設定する。 上記のいずれかを実行すればコンテナ内のユーザーは read/write パーミッションに沿ってアクセス可能です。 上記のいずれも設定しない場合、アクセスしようとすると UID/GID (65536:65536) のオーバーフローが発生し、全ユーザーで読み取り可能 (world readable) 以外のファイルへのアクセスは失敗します。 @@ -81,6 +63,7 @@ lxc config device add container-name home disk source=/home/${USER} path=/home/u しかしこれは特権コンテナのセキュリティの問題のほとんどの原因でもあります。 ### LXD コンテナ内で Docker を動かすには？ + LXD のコンテナ内で Docker を動かすにはコンテナの `security.nesting` プロパティを `true` にする必要があります。 ```bash @@ -98,6 +81,7 @@ lxc config set linux.kernel_modules コンテナ内に `/.dockerenv` ファイルを作成するとネストした環境内で実行しているために発生するエラーを Docker が無視するようにできるという報告もあります。 ## コンテナの起動に関する問題 + もしコンテナが起動しない場合や、期待通りの動きをしない場合に最初にすべきことは、コンテナが生成したコンソールログを見ることです。 これには `lxc console --show-log CONTAINERNAME` コマンドを使います。 @@ -113,7 +97,7 @@ lxc config set linux.kernel_modules [!!!!!!] Failed to mount API filesystems, freezing. ここでのエラーは、`/sys` と `/proc` がマウントできないというエラーです。これは非特権コンテナでは正しい動きです。 -しかし、LXD は _可能であれば_ 自動的にこれらのファイルシステムをマウントします。 +しかし、LXD は可能であれば自動的にこれらのファイルシステムをマウントします。 [コンテナの要件](container-environment.md) では、コンテナには `/sbin/init` が存在するだけでなく、空の `/dev`、`/proc`、`/sys` フォルダーが存在していなければならないと定められています。 もしこれらのフォルダーが存在しなければ、LXD はこれらをマウントできません。そして、`systemd` がこれらをマウントしようとします。 @@ -151,7 +135,7 @@ LXD は自動修復を試みますので、起動時に作成されたフォル ## ネットワークの問題 -大規模な[プロダクション環境](production-setup.md)では、複数の VLAN を持ち、LXD クライアントを直接それらの VLAN に接続するのが一般的です。 +大規模な[プロダクション環境](performance-tuning)では、複数の VLAN を持ち、LXD クライアントを直接それらの VLAN に接続するのが一般的です。 `netplan` と `systemd-networkd` を使っている場合、いくつかの最悪の問題を引き起こす可能性があるバグに遭遇するでしょう。 ### VLAN ベースのブリッジでは `netplan` で `systemd-networkd` が使えない @@ -198,9 +182,9 @@ LXD は自動修復を試みますので、起動時に作成されたフォル #### 注意事項 -* `eth0` はデフォルトゲートウェイの指定がある管理インターフェースです -* `vlan102` は `eth1` を使います -* `br102` は `vlan102` を使います。そして bogus な /32 の IP アドレスが割り当てられています。 +- `eth0` はデフォルトゲートウェイの指定がある管理インターフェースです +- `vlan102` は `eth1` を使います +- `br102` は `vlan102` を使います。そして bogus な /32 の IP アドレスが割り当てられています。 他に重要なこととして、`stp: false` を設定することがあります。そうしなければ、ブリッジは最大で 10 秒間 `learning` 状態となります。これはほとんどの DHCP リクエストが投げられる期間よりも長いです。 クロスコネクトされてループを引き起こす可能性はありませんので、このように設定しても安全です。 @@ -208,7 +192,7 @@ LXD は自動修復を試みますので、起動時に作成されたフォル ### port security に気をつける スイッチは MAC アドレスの変更を許さず、不正な MAC アドレスのトラフィックをドロップするか、ポートを完全に無効にするものが多いです。 -ホストから LXD インスタンスに ping できたとしても、_異なった_ ホストから ping できない場合は、これが原因の可能性があります。 +ホストから LXD インスタンスに ping できたとしても、異なったホストから ping できない場合は、これが原因の可能性があります。 この原因を突き止める方法は、アップリンク（この場合は `eth1`）で `tcpdump` を実行することです。 すると、応答は送るが ACK を取得できない "ARP Who has `xx.xx.xx.xx` tell `yy.yy.yy.yy`"、もしくは ICMP パケットが行き来しているものの、決して他のホストで受け取られないのが見えるでしょう。 diff --git a/doc/howto/benchmark_performance.md b/doc/howto/benchmark_performance.md new file mode 100644 index 0000000..0e0f30c --- /dev/null +++ b/doc/howto/benchmark_performance.md @@ -0,0 +1,103 @@ +(benchmark-performance)= +# パフォーマンスをベンチマークするには + +```{youtube} https://www.youtube.com/watch?v=z_OKwO5TskA +``` + +LXD サーバあるいはクラスタのパフォーマンスは、ハードウェア、サーバ設定、選択されたストレージドライバ、ネットワーク帯域幅から全体的な利用パターンに至るまでの多数の異なる因子によって変わります。 + +最適な設定を見つけるには、異なるセットアップを評価するためベンチマークテストを実行するほうが良いです。 + +LXD ではこの目的のためベンチマークツールを提供しています。 +このツールを使って複数のコンテナを初期化・起動し、システムがコンテナを作成するのに必要な時間を計測できます。 +異なる LXD の設定、システム設定、さらにはハードウェア構成に対して繰り返しツールを実行することで、パフォーマンスを比較し、どの設定が理想的か評価できます。 + +## ツールを取得する + +snap をご利用の場合、ベンチマークツールは自動でインストールされます。 +`lxd.benchmark` で利用できます。 + +それ以外、 LXD をディストリビューションのパッケージマネージャからインストールしたかソースからビルドした場合は、ツールは `lxd-benchmark` で利用できます。 +もし存在しない場合は、 `go` (バージョン 1.18 以降) がインストールされていることを確認の上、以下のコマンドでツールをインストールしてください。 + + go install github.com/lxc/lxd/lxd-benchmark@latest + +## ツールを実行する + +あなたの LXD のパフォーマンスを測定するには `lxd.benchmark [action]` を実行してください。 +(このコマンドはあなたが snap を使用していると想定しています。そうでない場合 `lxd.benchmark` を `lxd-benchmark` と読み替えてください。以下の例でも同様です) + +ベンチマークは現在の LXD 設定を使用します。 +別のプロジェクトを使用したい場合は、`--project` で指定してください。 + +全てのアクションについて、使用する並列スレッド数 (デフォルトはダイナミックなバッチサイズを使用) を指定できます。 +また結果を CSV のレポートファイルに追加し、一定の方法でラベル付けすることもできます。 + +利用可能なアクションとフラグについては `lxd.benchmark help` を参照してください。 + +### イメージを選択する + +ベンチマークを実行する前に、使用したいイメージの種別を選んでください。 + +ローカルイメージ +: コンテナの作成にかかる時間を計測し、イメージをダウンロードするのにかかる時間を無視したい場合は、ベンチマークツールを実行する前にイメージをローカルのイメージストアにコピーするのが良いです。 + + そうするには、以下のようなコマンドを実行し、 `lxd.benchmark` の実行時にはイメージのフィンガープリント(例えば `2d21da400963`)を指定します。 + + lxc image copy images:ubuntu/22.04 local: + + またイメージにエイリアスを割り当てて、`lxd.benchmark` の実行時にエイリアス (例えば `ubuntu`) を指定することもできます。 + + lxc image copy images:ubuntu/22.04 local: --alias ubuntu + +リモートイメージ +: 全体の結果にダウンロード時間も含めたい場合は、リモートイメージ (例えば `images:ubuntu/22.04`) を指定します。 + `lxd.benchmark` が使用するデフォルトのイメージは最新の Ubuntu イメージ (`ubuntu:`) ですので、このイメージを使用したい場合は、ツール実行時にイメージ名を省略できます。 + +### コンテナを作成、起動する + +指定した数のコンテナを作成するには以下のコマンドを実行します。 + + lxd.benchmark init --count + +特権コンテナを作成するにはコマンドに `--privileged` を追加します。 + +例 + +```{list-table} + :header-rows: 1 + +* - コマンド + - 説明 +* - `lxd.benchmark init --count 10 --privileged` + - 最新の Ubuntu イメージを使用して 10 個の特権コンテナを作成する。 +* - `lxd.benchmark init --count 20 --parallel 4 images:alpine/edge` + - Alpine Edge イメージを使用する 20 個のコンテナを 4 つのパラレルスレッドを使用して作成する。 +* - `lxd.benchmark init 2d21da400963` + - フィンガープリントが `2d21da400963` のローカルイメージを使用して 1 個のコンテナを作成する。 +* - `lxd.benchmark init --count 10 ubuntu` + - `ubuntu` のエイリアスを設定されたイメージを使用して 10 個のコンテナを作成する。 + +``` + +`init` アクションを使用するとコンテナを作成するが起動はせずにベンチマークを実行します。 +作成したコンテナを起動するには、以下のコマンドを実行します。 + + lxd.benchmark start + +あるいは `launch` アクションを使用してコンテナを作成し起動します。 + + lxd.benchmark launch --count 10 + +このアクションでは、`--freeze` フラグを追加するとコンテナの起動直後に凍結できます。 +コンテナを凍結するとプロセスは一時停止しますので、このフラグは各コンテナ内でプロセスが起動後に干渉するのを回避して純粋な起動時間を計測できます。 + +### コンテナを削除する + +作成したベンチマーク用のコンテナを削除するには、以下のコマンドを実行します。 + + lxd.benchmark --delete + +```{note} +新しいベンチマークを実行する前には既存のベンチマーク用コンテナを全て削除する必要があります。 +``` diff --git a/doc/howto/import_machines_to_instances.md b/doc/howto/import_machines_to_instances.md index 99d9f27..0f756ef 100644 --- a/doc/howto/import_machines_to_instances.md +++ b/doc/howto/import_machines_to_instances.md @@ -1,3 +1,7 @@ +--- +discourse: 14345 +--- + (import-machines-to-instances)= # 物理または仮想マシンを LXD インスタンスにインポートするには @@ -8,6 +12,7 @@ LXD は既存のディスクやイメージに基づく LXD インスタンス 次にこのツールはあなたが用意したディスクまたはイメージからインスタンスにデータをコピーします。 このツールはコンテナと仮想マシンの両方を作成できます。 + * コンテナを作成する際は、コンテナのルートファイルシステムを含むディスクまたはパーティションを用意する必要があります。 例えば、これはあなたがツールを実行しているマシンまたはコンテナの `/` ルートディスクかもしれません。 * 仮想マシンを作成する際は、起動可能なディスク、パーティション、またはイメージを用意する必要があります。 @@ -150,4 +155,5 @@ LXD は既存のディスクやイメージに基づく LXD インスタンス Please pick one of the options above [default=1]: 1 Instance foo successfully created ``` + diff --git a/doc/howto/migrate_from_lxc.md b/doc/howto/migrate_from_lxc.md new file mode 100644 index 0000000..a2af5fb --- /dev/null +++ b/doc/howto/migrate_from_lxc.md @@ -0,0 +1,94 @@ +(migrate-from-lxc)= +# LXC から LXD にコンテナをマイグレートするには + +LXD は LXC のコンテナを LXD サーバにインポートするためのツール (`lxc-to-lxd`) を提供しています。 +LXD コンテナは LXD サーバと同じマシン上に存在する必要があります。 + +このツールは LXC コンテナを分析し、データと設定の両方を新しい LXD コンテナにマイグレートします。 + +```{note} +あるいは LXC コンテナ内で `lxd-migrate` ツールを使用して LXD にマイグレートすることもできます ({ref}`import-machines-to-instances` 参照)。 +しかし、このツールは LXC コンテナの設定は一切マイグレートしません。 +``` + +## ツールを取得する + +snap をお使いの場合、`lxc-to-lxd` は自動でインストールされます。 +`lxd.lxc-to-lxd` で利用できます。 + +そうでない場合、 `go` (バージョン 1.18 以降) がインストールされていることを確認の上、以下のコマンドでツールをインストールしてください。 + + go install github.com/lxc/lxd/lxc-to-lxd@latest + +## LXC コンテナを用意する + +一度に1つのコンテナをマイグレートすることもできますし、同時にあなたの全ての LXC コンテナをマイグレートすることもできます。 + +```{note} +マイグレートされたコンテナは元のコンテナと同じ名前を使用します。 +LXD にインスタンス名としてすでに存在する名前を持つコンテナをマイグレートすることはできません。 + +このため、マイグレーションプロセスを開始する前に名前の衝突を引き起こす可能性のある LXC コンテナはリネームしてください。 +``` + +マイグレーションプロセスを開始する前に、マイグレートしたいコンテナを停止してください。 + +## マイグレーションプロセスを開始する + +コンテナをマイグレートするには `sudo lxd.lxc-to-lxd [flags]` と実行してください。 +(このコマンドはあなたが snap を使用していると想定しています。そうでない場合 `lxd.lxc-to-lxd` を `lxc-to-lxd` と読み替えてください。以下の例でも同様です) + +例えば、全てのコンテナをマイグレートするには + + sudo lxd.lxc-to-lxd --all + +`lxc1` コンテナだけをマイグレートするには + + sudo lxd.lxc-to-lxd --containers lxc1 + +2 つのコンテナ (`lxc1` と `lxc2`) をマイグレートし LXD 内の `my-storage` ストレージプールを使用するには + + sudo lxd.lxc-to-lxd --containers lxc1,lxc2 --storage my-storage + +実際に実行せずに全てのコンテナのマイグレートをテストするには + + sudo lxd.lxc-to-lxd --all --dry-run + +全てのコンテナをマイグレートするが、`rsync` の帯域幅を 5000 KB/s に限定するには + + sudo lxd.lxc-to-lxd --all --rsync-args --bwlimit=5000 + +全ての利用可能なフラグを確認するには `sudo lxd.lxc-to-lxd --help` と実行してください。 + +```{note} +`linux64` アーキテクチャがサポートされない (`linux64` architecture isn't supported) というエラーが出る場合、ツールを最新版にアップデートするか LXC コンテナ内のアーキテクチャを `linux64` から `amd64` か `x86_64` に変更してください。 +``` + +## 設定を確認する + +このツールは LXC の設定と (1つまたは複数の) コンテナの設定を分析し、可能な限りの範囲で設定をマイグレートします。 +以下のような実行結果が出力されます。 + +```bash +Parsing LXC configuration +Checking for unsupported LXC configuration keys +Checking for existing containers +Checking whether container has already been migrated +Validating whether incomplete AppArmor support is enabled +Validating whether mounting a minimal /dev is enabled +Validating container rootfs +Processing network configuration +Processing storage configuration +Processing environment configuration +Processing container boot configuration +Processing container apparmor configuration +Processing container seccomp configuration +Processing container SELinux configuration +Processing container capabilities configuration +Processing container architecture configuration +Creating container +Transferring container: lxc1: ... +Container 'lxc1' successfully created +``` + +マイグレーションプロセスが完了したら、設定を確認し、必要に応じて、マイグレートした LXD コンテナを起動する前に LXD 内の設定を更新してください。 diff --git a/doc/howto/move_instances.md b/doc/howto/move_instances.md index 60bef38..d6ecacf 100644 --- a/doc/howto/move_instances.md +++ b/doc/howto/move_instances.md @@ -7,7 +7,9 @@ ```{note} コンテナを移動する際にはまず停止する必要があります。 -詳細は {ref}`live-migration` を参照してください。 +詳細は {ref}`live-migration-containers` を参照してください。 + +仮想マシンを移動する際は、{ref}`live-migration-containers` を有効にするか、まず仮想マシンを停止する必要があります。 ``` 移動元のリモートがデフォルトのリモートの場合は省略可能で、移動先でも同じインスタンス名を使用する場合は移動先インスタンス名は省略できます。 @@ -30,16 +32,38 @@ (live-migration)= ## ライブマイグレーション +ライブマイグレーションとはインスタンスの稼働中にマイグレートするという意味です。 +仮想マシンではフルにサポートされています。 +コンテナでは限定的にサポートされています。 + +(live-migration-vms)= +### 仮想マシンのライブマイグレーション + 仮想マシンは稼働したまま、つまり一切のダウンタイムなしで、別のサーバに移動できます。 -コンテナについては、[{abbr}`CRIU (Checkpoint/Restore in Userspace)`](https://criu.org/) を使ったライブマイグレーションが限定的にサポートされています。 -しかし、カーネル依存が激しいため、確実にマイグレートできるのは非常に基本的なコンテナ (ネットワークデバイスなしの `systemd` を使用しないコンテナ) のみとなっています。 -ほとんどの現実のシナリオでは、コンテナを停止し、移動して、再度起動するべきです。 +ライブマイグレーションを可能にするには、ステートフルマイグレーションのサポートを有効にする必要があります。 +そのためには、以下の設定を確認してください。 + +* インスタンスの [`migration.stateful`](instance-configuration) を `true` に設定する。 +* 仮想マシンのルートディスクデバイスの [`size.state`](instance_device_type_disk) を少なくとも仮想マシンの [`limits.memory`](instance-configuration) 設定のサイズに設定する。 -コンテナのライブマイグレーションを使用したい場合、移動元と移動先の両方で CRIU を有効にする必要があります。 -snap を使っている場合、以下のコマンドで CRIU を有効にしてください。 +(live-migration-containers)= +### コンテナのライブマイグレーション + +コンテナについては [{abbr}`CRIU (Checkpoint/Restore in Userspace)`](https://criu.org/) を使用したライブマイグレーションが限定的にサポートされています。 +しかし、広範囲に及ぶカーネルへの依存のため、非常にベーシックなコンテナ (ネットワークデバイスなしの非 `systemd` コンテナ) のみが安定してマイグレートできます。 +ほとんどの実世界でのシナリオでは、コンテナを停止、移動してその後起動するのが良いです。 + +コンテナのライブマイグレーションを使用したい場合、マイグレーション元と先の両方のサーバで CRIU を有効にする必要があります。 +snap をお使いの場合、以下のコマンドを使用して CRIU を有効にしてください。 snap set lxd criu.enable=true systemctl reload snap.lxd.daemon -それ以外の場合、両方のシステムで CRIU がインストールされていることを確認してください。 +それ以外の場合、両方のシステムに CRIU がインストールされていることを確認してください。 + +コンテナのメモリ転送を最適化するには [`migration.incremental.memory`](instance-configuration) プロパティを `true` に設定して CRIU の事前コピー機能を使用してください。 +この設定では LXD はコンテナの一連のメモリダンプを実行するよう CRIU に指示します。 +それぞれのダンプの後、 LXD はメモリダンプを指定されたリモートに送信します。 +理想的なシナリオでは、各メモリダンプを前のメモリダンプとの差分にまで減らし、それによりすでに同期されたメモリの割合を増やします。 +同期されたメモリの割合が [`migration.incremental.memory.goal`](instance-configuration) で設定した閾値と等しいか超えた場合、あるいは [`migration.incremental.memory.iterations`](instance-configuration) で指定された許容される繰り返し回数の最大値に達した場合、 LXD は CRIU に最終的なメモリダンプを実行し、転送するように要求します。 diff --git a/doc/howto/network_acls.md b/doc/howto/network_acls.md index 7848dab..47e175a 100644 --- a/doc/howto/network_acls.md +++ b/doc/howto/network_acls.md @@ -82,15 +82,14 @@ lxc network acl rule remove [properties...] LXD は以下のように `action` プロパティに基づいてルールの順番を自動的に決めます。 - - `drop` - - `reject` - - `allow` - - 上記の全てにマッチしなかったトラフィックに対する自動のデフォルトアクション (デフォルトでは `reject`、{ref}`network-acls-defaults` 参照)。 +- `drop` +- `reject` +- `allow` +- 上記の全てにマッチしなかったトラフィックに対する自動のデフォルトアクション (デフォルトでは `reject`、{ref}`network-acls-defaults` 参照)。 これは NIC に複数の ACL を適用する際、組み合わせたルールの順番を指定する必要がないことを意味します。 ACL 内のあるルールがマッチすれば、そのルールが採用され、他のルールは考慮されません。 - ### ルールのプロパティ ACL ルールには次のプロパティがあります。 diff --git a/doc/howto/network_bgp.md b/doc/howto/network_bgp.md index bfb0af2..afe26d1 100644 --- a/doc/howto/network_bgp.md +++ b/doc/howto/network_bgp.md @@ -22,10 +22,14 @@ BGP サーバ機能は LXD サーバやクラスタが正しいホストへル こうすることで、トラフィックを対象のインスタンスにフォワードできます。 ブリッジネットワークについては、以下のアドレスとネットワークが広告されます。 - - `ipv4.address` または `ipv6.address` サブネットのネットワーク (対応する `nat` プロパティが `true` に設定されていない場合) - - `ipv4.nat.address` または `ipv6.nat.address` サブネットのネットワーク (対応する `nat` プロパティが `true` に設定されていない場合) - - ネットワークフォワードアドレス - - ブリッジネットワークに接続されているインスタンス NIC 上の `ipv4.routes.external` または `ipv6.routes.external` で指定されているアドレスまたはサブネット + +- `ipv4.address` または `ipv6.address` サブネットのネットワーク (対応する `nat` プロパティが `true` に設定されていない場合) +- `ipv4.nat.address` または `ipv6.nat.address` サブネットのネットワーク (対応する `nat` プロパティが `true` に設定されていない場合) +- ネットワークフォワードアドレス +- ブリッジネットワークに接続されているインスタンス NIC 上の `ipv4.routes.external` または `ipv6.routes.external` で指定されているアドレスまたはサブネット + +サブネットを対応する設定オプションに確実に追加してください。 +さもなければ、広告されません。 物理ネットワークについては、物理ネットワークのレベルに直接広告されるアドレスはありません。 代わりに、全てのダウンストリームネットワーク (`network` オプションで物理ネットワークをアップリンクネットワークとして指定するネットワーク) のネットワーク、フォワードとルートがブリッジネットワークに対するのと同じように広告されます。 @@ -37,7 +41,7 @@ BGP サーバ機能は LXD サーバやクラスタが正しいホストへル ## BGP サーバを設定する -LXD を BGP サーバとして設定するには、以下のサーバ設定オプションを設定してください ({ref}`server` 参照)。 +LXD を BGP サーバとして設定するには、以下のサーバ設定オプションを全てのクラスタメンバで設定してください ({ref}`server` 参照)。 - `core.bgp_address` - BGP サーバの IP アドレス - `core.bgp_asn` - ローカルサーバの {abbr}`ASN (Autonomous System Number)` @@ -63,6 +67,8 @@ lxc config set core.bgp_routerid=192.0.2.50 ### OVN ネットワークに BGP ピアを設定する OVN ネットワークをアップリンクネットワーク (`physical` または `bridge`) と使用する場合、アップリンクネットワークは許可されるサブネット一覧と BGP 設定を持つネットワークです。 +このため、 BGP サーバに接続するのに必要な情報を含むアップリンクネットワーク上に BGP ピアを設定する必要があります。 + アップリンクネットワークに対して以下の設定オプションを設定してください。 - `bgp.peers..address` - ダウンストリームネットワークで使用されるピアアドレス diff --git a/doc/howto/network_bridge_firewalld.md b/doc/howto/network_bridge_firewalld.md index 0e3f436..51a87cf 100644 --- a/doc/howto/network_bridge_firewalld.md +++ b/doc/howto/network_bridge_firewalld.md @@ -63,10 +63,12 @@ LXD のファイアウォールルールをどのように無効化し、 `firew sudo firewall-cmd --reload + ```{warning} 上に示したコマンドはシンプルな例です。 あなたの使い方に応じて、より高度なルールが必要な場合があり、その場合上の例をそのまま実行するとうっかりセキュリティリスクを引き起こす可能性があります。 ``` + ### UFW でブリッジにルールを追加する diff --git a/doc/howto/network_bridge_resolved.md b/doc/howto/network_bridge_resolved.md index 40e4760..6aa212d 100644 --- a/doc/howto/network_bridge_resolved.md +++ b/doc/howto/network_bridge_resolved.md @@ -76,6 +76,8 @@ After=sys-subsystem-net-devices-.device Type=oneshot ExecStart=/usr/bin/resolvectl dns ExecStart=/usr/bin/resolvectl domain +ExecStopPost=/usr/bin/resolvectl revert +RemainAfterExit=yes [Install] WantedBy=sys-subsystem-net-devices-.device @@ -104,7 +106,7 @@ WantedBy=sys-subsystem-net-devices-.device Main PID: 9434 (code=exited, status=0/SUCCESS) ``` -`resolved` に設定が反映されたか確認するには、 `sudo resolvectl status ` を実行します。 +`resolved` に設定が反映されたか確認するには、 `resolvectl status ` を実行します。 ``` Link 6 (lxdbr0) diff --git a/doc/howto/network_increase_bandwidth.md b/doc/howto/network_increase_bandwidth.md new file mode 100644 index 0000000..9358286 --- /dev/null +++ b/doc/howto/network_increase_bandwidth.md @@ -0,0 +1,44 @@ +(network-increase-bandwidth)= +# ネットワーク帯域幅を拡大するには + +あなたの LXD 環境のネットワーク帯域幅を送信キューの長さ (`txqueuelen`) を調整することで拡大できます。 +以下のようなシナリオでは適しているでしょう。 + +- 大量のローカルアクティビティ (インスタンス間接続あるいはホストあるいはインスタンス間の接続) がある LXD ホスト上に 1 GbE あるいはそれ以上の NIC 1 GbE あるいはそれ以上の NIC がある場合 +- LXD ホストで 1 GbE あるいはそれ以上のインターネット接続がある場合 + +使用するインスタンス数が多いほど、この設定変更の利益があります。 + +```{note} +以下の手順では `txqueuelen` の値として 10000 (10GbE NIC でよく使用されます) を、`net.core.netdev_max_backlog` の値として 182757 を使用しています。 +ネットワークによっては、異なる値を使用する必要があるかもしれません。 + +一般的に、低速なデバイスでレイテンシが高い場合は小さい `txqueuelen` の値を、レイテンシが低いデバイスでは大きな `txqueuelen` の値を使用するのが良いです。 +`net.core.netdev_max_backlog` の値について、良い指標は `net.ipv4.tcp_mem` 設定の最小値を使用することです。 +``` + +## LXD ホスト上のネットワーク帯域幅を拡大する + +LXD ホスト上のネットワーク帯域幅を拡大するには以下の手順を実行してください。 + +1. 実 NIC と LXD NIC (例: `lxdbr0`) の両方で送信キューの長さ (`txqueuelen`) を拡大します。 + テストのために一時的にこれを行うには以下のコマンドが使用できます。 + + ifconfig txqueuelen 10000 + + 変更を恒久的にするには `/etc/network/interfaces` 内のインタフェース設定に以下のコマンドを追加します。 + + up ip link set eth0 txqueuelen 10000 + +1. 受信キューの長さ (`net.core.netdev_max_backlog`) を拡大します。 + テストのために一時的にこれを行うには以下のコマンドが使用できます。 + + echo 182757 > /proc/sys/net/core/netdev_max_backlog + + 変更を恒久的にするには `/etc/sysctl.conf` に以下の設定を追加します。 + + net.core.netdev_max_backlog = 182757 + +## インスタンス上の送信キューの長さを拡大する + +インスタンス上の全ての Ethernet インタフェースの `txqueulen` の値も、 LXD ホスト用の上記の説明と同様にして、変更する必要があります。 diff --git a/doc/howto/network_zones.md b/doc/howto/network_zones.md index 9301130..5c5d4b7 100644 --- a/doc/howto/network_zones.md +++ b/doc/howto/network_zones.md @@ -44,12 +44,12 @@ LXD は全てのインスタンス、ネットワークゲートウェイ、ダ 例えば、 `dig @ -p 1053 axfr lxd.example.net` と実行すると以下のように出力されます。 ```bash -lxd.example.net. 3600 IN SOA lxd.example.net. hostmaster.lxd.example.net. 1648118965 120 60 86400 30 +lxd.example.net. 3600 IN SOA lxd.example.net. hostmaster.lxd.example.net. 1648118965 120 60 86400 30 default-my-ovn.uplink.lxd.example.net. 300 IN A 192.0.2.100 -my-instance.lxd.example.net. 300 IN A 192.0.2.76 -my-uplink.gw.lxd.example.net. 300 IN A 192.0.2.1 -foo.lxd.example.net. 300 IN A 8.8.8.8 -lxd.example.net. 3600 IN SOA lxd.example.net. hostmaster.lxd.example.net. 1648118965 120 60 86400 30 +my-instance.lxd.example.net. 300 IN A 192.0.2.76 +my-uplink.gw.lxd.example.net. 300 IN A 192.0.2.1 +foo.lxd.example.net. 300 IN A 8.8.8.8 +lxd.example.net. 3600 IN SOA lxd.example.net. hostmaster.lxd.example.net. 1648118965 120 60 86400 30 ``` `192.0.2.0/24` を使用するネットワークに `2.0.192.in-addr.arpa` の IPv4 逆引き DNS レコードのゾーンを設定すると、例えば `192.0.2.100` に対する逆引き DNS レコードを生成します。 diff --git a/doc/howto/storage_backup_volume.md b/doc/howto/storage_backup_volume.md index 0bd59cd..0b862fb 100644 --- a/doc/howto/storage_backup_volume.md +++ b/doc/howto/storage_backup_volume.md @@ -1,3 +1,4 @@ +(howto-storage-backup-volume)= # カスタムストレージボリュームをバックアップするには カスタムストレージボリュームをバックアップするには以下の方法があります。 diff --git a/doc/howto/storage_buckets.md b/doc/howto/storage_buckets.md new file mode 100644 index 0000000..1c22f2d --- /dev/null +++ b/doc/howto/storage_buckets.md @@ -0,0 +1,124 @@ +(howto-storage-buckets)= +# ストレージバケットとキーを管理するには + +{ref}`storage-buckets` を作成、設定、表示、リサイズするための手順およびストレージバケットキーを管理する方法については以下のセクションを参照してください。 + +## ストレージバケットを管理する + +ストレージバケットは S3 プロトコルを使って公開されるオブジェクトストレージを提供します。 + +カスタムストレージボリュームとは異なり、ストレージバケットはインスタンスに追加されるのではなく、それらの URL を通してアプリケーションから直接アクセスされます。 + +詳細は {ref}`storage-buckets` を参照してください。 + +## ストレージバケットを作成する + +ストレージプール内にストレージバケットを作成するには、以下のコマンドを使用します。 + + lxc storage bucket create [configuration_options...] + +それぞれのドライバで利用可能なストレージバケット設定オプションの一覧については {ref}`storage-drivers` を参照してください。 + +クラスタメンバにストレージバケットを追加するには `--target` フラグを追加してください。 + + lxc storage bucket create --target= [configuration_options...] + +```{note} +ほとんどのストレージドライバでは、ストレージバケットはクラスタ間でリプリケートされず、作成されたメンバ上にのみ存在します。 +この挙動は `cephobject` ストレージプールでは異なります。 `cephobject` ではバケットはどのクラスタメンバからも利用できます。 +``` + +### ストレージバケットを設定するには + +各ストレージドライバで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 + +ストレージバケットの設定オプションを設定するには以下のコマンドを使用します。 + + lxc storage bucket set + +例えば、バケットにクォータサイズを設定するには、以下のコマンドを使用します。 + + lxc storage bucket set my-pool my-bucket size 1MiB + +以下のコマンドでストレージバケットの設定を編集することもできます。 + + lxc storage bucket edit + +ストレージバケットとそのキーを削除するには以下のコマンドを使用します。 + + lxc storage bucket delete + +### ストレージバケットを表示するには + +ストレージプール内の全ての利用可能なストレージバケットの一覧を表示し設定を確認できます。 + +ストレージプール内の全ての利用可能なストレージバケットを一覧表示するには、以下のコマンドを使用します。 + + lxc storage bucket list + +特定のバケットの詳細情報を表示するには、以下のコマンドを使用します。 + + lxc storage bucket show + +### ストレージバケットをリサイズするには + +デフォルトではストレージバケットにはクォータは適用されません。 + +ストレージバケットクォータを設定するには、サイズを設定します。 + + lxc storage bucket set size + +```{important} +- ストレージバケットの拡大は通常は正常に動作します (ストレージプールが十分なストレージを持つ場合)。 +- ストレージバケットを現在の使用量より縮小することはできません。 + +``` + +## ストレージバケットキーを管理する + +アプリケーションがストレージバケットにアクセスするためには *アクセスキー* と *シークレットキー* からなる S3 クレデンシャルを使う必要があります。 +特定のバケットに対して複数のセットのクレデンシャルを作成できます。 + +それぞれのクレデンシャルのセットにはキー名を設定します。 +キー名は参照のためだけに用いられ、アプリケーションがクレデンシャルを使用する際に提供する必要はありません。 + +それぞれのクレデンシャルのセットには *ロール* が設定されます。それはバケットにどの操作を実行できるかを指定します。 + +使用可能なロールは以下のとおりです。 + + - `admin` - バケットへのフルアクセス。 + - `read-only` - バケットへの読み取り専用アクセス (一覧とファイルの取得のみ)。 + +バケットキー作成時にロールが指定されない場合、使用されるロールは `read-only` になります。 + +### ストレージバケットキーを作成する + +ストレージバケットにクレデンシャルのセットを作成するには、以下のコマンドを使用します。 + + lxc storage bucket key create [configuration_options...] + +ストレージバケットに特定のロールを持つクレデンシャルのセットを作成するには、以下のコマンドを使用します。 + + lxc storage bucket key create --role=admin [configuration_options...] + +これらのコマンドはランダムなクレデンシャルキーのセットを生成し表示します。 + +### ストレージバケットキーを編集または削除するには + +既存のバケットキーを編集するには以下のコマンドを使用します。 + + lxc storage bucket edit + +既存のバケットキーを削除するには以下のコマンドを使用します。 + + lxc storage bucket key delete + +### ストレージバケットのキーを表示するには + +既存のバケットに定義されているキーを表示するには以下のコマンドを使用します。 + + lxc storage bucket key list + +特定のバケットキーを表示するには以下のコマンドを使用します。 + + lxc storage bucket key show diff --git a/doc/howto/storage_configure_bucket.md b/doc/howto/storage_configure_bucket.md deleted file mode 100644 index bf11fd9..0000000 --- a/doc/howto/storage_configure_bucket.md +++ /dev/null @@ -1,29 +0,0 @@ -# ストレージバケットを設定するには - -各ストレージドライバで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 - -ストレージバケットの設定オプションを設定するには以下のコマンドを使用します。 - - lxc storage bucket set - -例えば、バケットにクォータサイズを設定するには、以下のコマンドを使用します。 - - lxc storage bucket set my-pool my-bucket size 1MiB - -以下のコマンドでストレージバケットの設定を編集することもできます。 - - lxc storage bucket edit - -ストレージバケットとそのキーを削除するには以下のコマンドを使用します。 - - lxc storage bucket delete - -## ストレージバケットキーを設定するには - -既存のバケットキーを編集するには以下のコマンドを使用します。 - - lxc storage bucket edit - -既存のバケットキーを削除するには以下のコマンドを使用します。 - - lxc storage bucket key delete diff --git a/doc/howto/storage_configure_pool.md b/doc/howto/storage_configure_pool.md deleted file mode 100644 index 29e3bc5..0000000 --- a/doc/howto/storage_configure_pool.md +++ /dev/null @@ -1,18 +0,0 @@ -# ストレージプールを設定する - -各ストレージドライバで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 - -(`source` のような) ストレージプールの一般的なキーはトップレベルです。 -ドライバ固有のキーはドライバ名で名前空間が分けられています。 - -ストレージプールに設定オプションを設定するには以下のコマンドを使用します。 - - lxc storage set - -例えば、 `dir` ストレージプールでストレージプールのマイグレーション中に圧縮をオフにするには以下のコマンドを使用します。 - - lxc storage set my-dir-pool rsync.compression false - -ストレージプールの設定を編集するには以下のコマンドを使用します。 - - lxc storage edit diff --git a/doc/howto/storage_configure_volume.md b/doc/howto/storage_configure_volume.md deleted file mode 100644 index a683be4..0000000 --- a/doc/howto/storage_configure_volume.md +++ /dev/null @@ -1,33 +0,0 @@ -(storage-configure-volume)= -# ストレージボリュームを設定するには - -各ストレージドライバで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 - -ストレージボリュームの設定オプションを設定するには以下のコマンドを使用します。 - - lxc storage volume set - -例えば、スナップショットの破棄期限を 1 ヶ月に設定するには以下のコマンドを使用します。 - - lxc storage volume set my-pool my-volume snapshots.expiry 1M - -インスタンスのストレージボリュームを設定するには、 {ref}`ストレージボリュームタイプ ` を含めたボリューム名を指定します。例えば - - lxc storage volume set my-pool container/my-container-volume user.XXX value - -ストレージボリューム設定を編集するには以下のコマンドを使用します。 - - lxc storage volume edit - -(storage-configure-vol-default)= -## ストレージボリュームのデフォルト値を変更する - -ストレージプールのデフォルトのボリューム設定を定義できます。 -そのためには、 `volume` 接頭辞をつけたストレージプール設定`volume.=` をセットします。 - -新しいストレージボリュームまたはインスタンスに明示的に設定されない限り、この値はプール内の全ての新しいストレージボリュームに使用されます。 -一般的に、ストレージプールのレベルに設定されたデフォルト値は (ボリュームが作成される前であれば) ボリューム設定でオーバーライドでき、ボリューム設定はインスタンス設定 ({ref}`type ` `container` か `vm` のストレージボリュームについて) でオーバーライドできます。 - -例えば、ストレージプールにデフォルトのボリュームサイズを設定するには以下のコマンドを使用します。 - - lxc storage set [:] volume.size diff --git a/doc/howto/storage_create_bucket.md b/doc/howto/storage_create_bucket.md deleted file mode 100644 index d331ca6..0000000 --- a/doc/howto/storage_create_bucket.md +++ /dev/null @@ -1,51 +0,0 @@ -# ストレージバケットを作成するには - -ストレージバケットは S3 プロトコルを使って公開されるオブジェクトストレージを提供します。 - -カスタムストレージボリュームとは異なり、ストレージバケットはインスタンスに追加されるのではなく、それらの URL を通してアプリケーションから直接アクセスされます。 - -詳細は {ref}`storage-buckets` を参照してください。 - -## ストレージバケットを作成する - -ストレージプール内にストレージバケットを作成するには、以下のコマンドを使用します。 - - lxc storage bucket create [configuration_options...] - -それぞれのドライバで利用可能なストレージバケット設定オプションの一覧については {ref}`storage-drivers` を参照してください。 - -クラスタメンバにストレージバケットを追加するには `--target` フラグを追加してください。 - - lxc storage bucket create --target= [configuration_options...] - -```{note} -ほとんどのストレージドライバでは、ストレージバケットはクラスタ間でリプリケートされず、作成されたメンバ上にのみ存在します。 -この挙動は `cephobject` ストレージプールでは異なります。 `cephobject` ではバケットはどのクラスタメンバからも利用できます。 -``` - -## ストレージバケットキーを作成する - -アプリケーションがストレージバケットにアクセスするためには *アクセスキー* と *シークレットキー* からなる S3 クレデンシャルを使う必要があります。 -特定のバケットに対して複数のセットのクレデンシャルを作成できます。 - -それぞれのクレデンシャルのセットにはキー名を設定します。 -キー名は参照のためだけに用いられ、アプリケーションがクレデンシャルを使用する際に提供する必要はありません。 - -それぞれのクレデンシャルのセットには *ロール* が設定されます。それはバケットにどの操作を実行できるかを指定します。 - -使用可能なロールは以下のとおりです。 - - - `admin` - バケットへのフルアクセス。 - - `read-only` - バケットへの読み取り専用アクセス (一覧とファイルの取得のみ)。 - -バケットキー作成時にロールが指定されない場合、使用されるロールは `read-only` になります。 - -ストレージバケットにクレデンシャルのセットを作成するには、以下のコマンドを使用します。 - - lxc storage bucket key create [configuration_options...] - -ストレージバケットに特定のロールを持つクレデンシャルのセットを作成するには、以下のコマンドを使用します。 - - lxc storage bucket key create --role=admin [configuration_options...] - -これらのコマンドはランダムなクレデンシャルキーのセットを生成し表示します。 diff --git a/doc/howto/storage_create_instance.md b/doc/howto/storage_create_instance.md index fbbefcb..637c989 100644 --- a/doc/howto/storage_create_instance.md +++ b/doc/howto/storage_create_instance.md @@ -1,3 +1,4 @@ +(howto-storage-create-instance)= # 特定のストレージプール内にインスタンスを作成するには インスタンスストレージボリュームはインスタンスのルートディスクデバイスにより指定されたストレージプール内に作成されます。 diff --git a/doc/howto/storage_create_volume.md b/doc/howto/storage_create_volume.md deleted file mode 100644 index 23f12ec..0000000 --- a/doc/howto/storage_create_volume.md +++ /dev/null @@ -1,76 +0,0 @@ -# カスタムストレージボリュームを作成するには - -インスタンスを作成する際に、 LXD はインスタンスのルートディスクとして使用するストレージボリュームを自動的に作成します。 - -インスタンスにカスタムストレージボリュームを追加できます。 -このカスタムストレージボリュームはインスタンスから独立しています。これは別にバックアップできたり、カスタムストレージボリュームを削除するまで残っていることを意味します。 -コンテントタイプが `filesystem` のカスタムストレージボリュームは異なるインスタンス間で共有もできます。 - -詳細な情報は {ref}`storage-volumes` を参照してください。 - -## カスタムストレージボリュームを作成する - -ストレージプール内にカスタムストレージボリュームを作成するには以下のコマンドを使用します。 - - lxc storage volume create [configuration_options...] - -各ドライバで利用可能なストレージボリューム設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 - -デフォルトではカスタムストレージボリュームは `filesystem` {ref}`コンテントタイプ ` を使用します。 -`block` コンテントタイプのカスタムストレージボリュームを作成するには `--type` フラグを追加してください。 - - lxc storage volume create --type=block [configuration_options...] - -クラスターメンバー上にカスタムストレージボリュームを追加するには `--target` フラグを追加してください。 - - lxc storage volume create --target= [configuration_options...] - -```{note} -ほとんどのストレージドライバではカスタムストレージボリュームはクラスター間で同期されず作成されたメンバー上にのみ存在します。 -この挙動は Ceph ベースのストレージプール (`ceph` and `cephfs`) では異なり、ボリュームはどのクラスターメンバーでも利用可能です。 -``` - -(storage-attach-volume)= -## インスタンスにカスタムストレージボリュームをアタッチする - -カスタムストレージボリュームを作成したら、それを 1 つあるいは複数のインスタンスに {ref}`ディスクデバイス ` として追加できます。 - -以下の制限があります。 - -- {ref}`コンテントタイプ ` `block` のカスタムストレージボリュームはコンテナにはアタッチできず、仮想マシンのみにアタッチできます。 -- データ破壊を防ぐため、 {ref}`コンテントタイプ ` `block` のカスタムストレージボリュームは同時に複数の仮想マシンには決してアタッチするべきではありません。 - -コンテントタイプ `filesystem` のカスタムストレージボリュームは以下のコマンドを使用します。ここで `` はインスタンス内でストレージボリュームにアクセスするためのパス (例: `/data`) です。 - - lxc storage volume attach - -コンテントタイプ `block` のカスタムストレージボリュームは `` を指定しません。 - - lxc storage volume attach - -デフォルトではカスタムストレージボリュームはインスタンスに {ref}`デバイス ` の名前でボリュームが追加されます。 -異なるデバイス名を使用したい場合は、コマンドにデバイス名を追加できます。 - - lxc storage volume attach - lxc storage volume attach - -(storage-configure-IO)= -## I/O 制限値の設定 - -ストレージボリュームをインスタンスに {ref}`ディスクデバイス ` としてアタッチする際に、 I/O 制限値を設定できます。 -そのためには `limits.read`, `limits.write`, `limits.max` に対応する制限値を設定します。 -詳細な情報は {ref}`instance_device_type_disk` リファレンスを参照してください。 - -制限値は Linux の `blkio` cgroup コントローラー経由で適用されます。これによりディスクのレベルで I/O を制限することができます (しかしそれより細かい単位では制限できません)。 - -```{note} -制限値はパーティションやパスではなく物理ディスク全体に適用されるため、以下の制約があります。 - -- 仮想デバイス (例えば device mapper) 上に存在するファイルシステムには制限値は適用されません -- ファイルシステムが複数のブロックデバイス上に存在する場合、各デバイスは同じ制限を受けます。 -- 同じディスク上に存在する 2 つのディスクデバイスが同じインスタンスにアタッチされた場合は、 2 つのデバイスの制限値は平均されます -``` - -全ての I/O 制限値は実際のブロックデバイスアクセスにのみ適用されます。 -そのため、制限値を設定する際はファイルシステム自体のオーバーヘッドを考慮してください。 -キャッシュされたデータへのアクセスはこの制限値に影響されません。 diff --git a/doc/howto/storage_move_volume.md b/doc/howto/storage_move_volume.md index 6115de1..e0e57e5 100644 --- a/doc/howto/storage_move_volume.md +++ b/doc/howto/storage_move_volume.md @@ -2,6 +2,7 @@ discourse: 10877 --- +(howto-storage-move-volume)= # ストレージボリュームを移動やコピーするには カスタムストレージボリュームはあるストレージプールから別のストレージプールに {ref}`コピー ` や {ref}`移動 ` したり、同じストレージプール内でコピーやリネームできます。 diff --git a/doc/howto/storage_create_pool.md b/doc/howto/storage_pools.md similarity index 53% rename from doc/howto/storage_create_pool.md rename to doc/howto/storage_pools.md index 667d191..05cad8d 100644 --- a/doc/howto/storage_create_pool.md +++ b/doc/howto/storage_pools.md @@ -1,5 +1,14 @@ +--- +discourse: 1333 +--- + +(howto-storage-pools)= +# ストレージプールを管理するには + +{ref}`storage-pools` を作成、設定、表示、リサイズするための手順については以下のセクションを参照してください。 + (storage-create-pool)= -# ストレージプールを作成するには +## ストレージプールを作成する LXD は初期化中にストレージプールを作成します。 同じドライバあるいは別のドライバを使用して、後からさらにストレージプールを追加できます。 @@ -12,7 +21,7 @@ LXD は初期化中にストレージプールを作成します。 それぞれのドライバで利用可能な設定オプションの一覧は {ref}`storage-drivers` ドキュメントを参照してください。 -## 例 +### 例 それぞれのストレージドライバでストレージプールを作成する例は以下を参照してください。 @@ -134,11 +143,13 @@ CephFS ドライバを使用する際は、事前に CephFS ファイルシス Ceph Object ドライバを使用する場合、事前に稼働中の Ceph Object Gateway [`radosgw`](https://docs.ceph.com/en/latest/radosgw/) の URL を用意しておく必要があります。 ``` - lxc storage create s3 cephobject cephobject.radosgsw.endpoint=http:// +既存の Ceph Object Gateway `https://www.example.com/radosgw` を使用して `pool1` を作成する。 + + lxc storage create pool1 cephobject cephobject.radosgw.endpoint=https://www.example.com/radosgw ```` ````` -## クラスター内にストレージプールを作成する +### クラスター内にストレージプールを作成する LXD クラスターを稼働していてストレージプールを追加したい場合、それぞれのクラスターメンバー内にストレージを別々に作る必要があります。 この理由は、設定、例えばストレージのロケーションやプールのサイズがクラスターメンバー間で異なるかもしれないからです。 @@ -159,5 +170,128 @@ LXD クラスターを稼働していてストレージプールを追加した ほとんどのストレージドライバでは、ストレージプールは各クラスターメンバー上にローカルに存在します。 これは 1 つのメンバー上のストレージプール内にストレージボリュームを作成しても、別のクラスターメンバー上では利用可能にはならないことを意味します。 -この挙動は Ceph ベースのストレージプール (`ceph` and `cephfs`) では異なります。これらではストレージプールは 1 つの中央のロケーション上に存在し、全てのクラスターメンバーが同じストレージボリュームを持つ同じストレージプールにアクセスします。 +この挙動は Ceph ベースのストレージプール (`ceph`、 `cephfs`、 `cephobject`) では異なります。これらではストレージプールは 1 つの中央のロケーション上に存在し、全てのクラスターメンバーが同じストレージボリュームを持つ同じストレージプールにアクセスします。 +``` + +## ストレージプールを設定する + +各ストレージドライバで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 + +(`source` のような) ストレージプールの一般的なキーはトップレベルです。 +ドライバ固有のキーはドライバ名で名前空間が分けられています。 + +ストレージプールに設定オプションを設定するには以下のコマンドを使用します。 + + lxc storage set + +例えば、 `dir` ストレージプールでストレージプールのマイグレーション中に圧縮をオフにするには以下のコマンドを使用します。 + + lxc storage set my-dir-pool rsync.compression false + +ストレージプールの設定を編集するには以下のコマンドを使用します。 + + lxc storage edit + +## ストレージプールを表示する + +全ての利用可能なストレージプールの一覧を表示し設定を確認できます。 + +以下のコマンドで全ての利用可能なストレージプールを一覧表示できます。 + + lxc storage list + +出力結果の表には (訳注: LXD の) 初期化時に作成した (通常 `default` や `local` と呼ばれる) ストレージプールとあなたが追加したあらゆるストレージプールが含まれます。 + +特定のプールに関する詳細情報を表示するには、以下のコマンドを使用します。 + + lxc storage show + +(storage-resize-pool)= +## ストレージプールをリサイズする + +ストレージがもっと必要な場合、ストレージプールのサイズを拡大できます。 + +ストレージプールのサイズを拡大するには以下の一般的なステップに従います。 + +1. ディスク上のストレージのサイズを拡大する。 +1. サイズの変更をファイルシステムに知らせる。 + +ストレージドライバごとの固有のコマンドは以下を参照してください。 + +````{tabs} + +```{group-tab} Btrfs + +ループバックの Btrfs プールを 5 ギガバイト拡大するには以下のコマンドを入力します。 + + sudo truncate -s +5G /disks/.img + sudo losetup -c + sudo btrfs filesystem resize max /storage-pools// + +以下の変数を置き換えてください。 + +`` +: snap を使用している場合 `/var/snap/lxd/common/mntns/var/snap/lxd/common/lxd/` またはそれ以外の場合 `/var/lib/lxd/`。 + +`` +: ストレージプールの名前 (例えば `my-pool`)。 + +`` +: ストレージプールイメージに関連付けられているマウントされたループデバイス (例 `/dev/loop8`)。 + ループデバイスを見つけるには `losetup -j /disks/.img` と入力します。 +　`losetup -l` を使ってマウントされた全てのループデバイスのを一覧表示することもできます。 ``` +```{group-tab} LVM + +ループバックの LVM プールを 5 ギガバイト拡大するには以下のコマンドを入力します。 + + sudo truncate -s +5G /disks/.img + sudo losetup -c + sudo pvresize + +LVM thin pool を使っている場合は、次にプール内の `LXDThinPool`論理ボリュームを拡大する必要があります (thin pool を使っていない場合はこのステップをスキップします)。 + + sudo lvextend /LXDThinPool -l+100%FREE + +以下の変数を置き換えてください。 + +`` +: snap を使用している場合 `/var/snap/lxd/common/lxd/` またはそれ以外の場合 `/var/lib/lxd/`。 + +`` +: ストレージプールの名前 (例えば `my-pool`)。 + +`` +: ストレージプールイメージに関連付けられているマウントされたループデバイス (例 `/dev/loop8`)。 + ループデバイスを見つけるには `losetup -j /disks/.img` と入力します。 +　`losetup -l` を使ってマウントされた全てのループデバイスのを一覧表示することもできます。 + +プールが期待通りリサイズされたかは以下のコマンドで確認できます。 + + sudo pvs # 物理ボリュームのサイズを確認 + sudo vgs # ボリュームグループのサイズを確認 + sudo lvs /LXDThinPool # thin pool のみ: thin-pool 論理ボリュームのサイズを確認 +``` +```{group-tab} ZFS + +ループバックの ZFS プールを 5 ギガバイト拡大するには以下のコマンドを入力します。 + + sudo truncate -s +5G /disks/.img + sudo zpool set autoexpand=on + sudo zpool online -e + sudo zpool set autoexpand=off + +以下の変数を置き換えてください。 + +`` +: snap を使用している場合 `/var/snap/lxd/common/lxd/` またはそれ以外の場合 `/var/lib/lxd/`。 + +`` +: ストレージプールの名前 (例えば `my-pool`)。 + +`` +: ZFS デバイスの ID。 + ID を見つけるには `sudo zpool status -vg ` を入力します。 +``` + +```` diff --git a/doc/howto/storage_resize_bucket.md b/doc/howto/storage_resize_bucket.md deleted file mode 100644 index eb7da70..0000000 --- a/doc/howto/storage_resize_bucket.md +++ /dev/null @@ -1,13 +0,0 @@ -# ストレージバケットをリサイズするには - -デフォルトではストレージバケットにはクォータは適用されません。 - -ストレージバケットクォータを設定するには、サイズを設定します。 - - lxc storage bucket set size - -```{important} -- ストレージバケットの拡大は通常は正常に動作します (ストレージプールが十分なストレージを持つ場合)。 -- ストレージバケットを現在の使用量より縮小することはできません。 - -``` diff --git a/doc/howto/storage_resize_pool.md b/doc/howto/storage_resize_pool.md deleted file mode 100644 index 281e94f..0000000 --- a/doc/howto/storage_resize_pool.md +++ /dev/null @@ -1,93 +0,0 @@ ---- -discourse: 1333 ---- - -(storage-resize-pool)= -# ストレージプールをリサイズするには - -ストレージがもっと必要な場合、ストレージプールのサイズを拡大できます。 - -ストレージプールのサイズを拡大するには以下の一般的なステップに従います。 - -1. ディスク上のストレージのサイズを拡大する。 -1. サイズの変更をファイルシステムに知らせる。 - -ストレージドライバごとの固有のコマンドは以下を参照してください。 - -````{tabs} - -```{group-tab} Btrfs - -ループバックの Btrfs プールを 5 ギガバイト拡大するには以下のコマンドを入力します。 - - sudo truncate -s +5G /disks/.img - sudo losetup -c - sudo btrfs filesystem resize max /storage-pools// - -以下の変数を置き換えてください。 - -`` -: snap を使用している場合 `/var/snap/lxd/common/mntns/var/snap/lxd/common/lxd/` またはそれ以外の場合 `/var/lib/lxd/`。 - -`` -: ストレージプールの名前 (例えば `my-pool`)。 - -`` -: ストレージプールイメージに関連付けられているマウントされたループデバイス (例 `/dev/loop8`)。 - ループデバイスを見つけるには `losetup -j /disks/.img` と入力します。 -　`losetup -l` を使ってマウントされた全てのループデバイスのを一覧表示することもできます。 -``` -```{group-tab} LVM - -ループバックの LVM プールを 5 ギガバイト拡大するには以下のコマンドを入力します。 - - sudo truncate -s +5G /disks/.img - sudo losetup -c - sudo pvresize - -LVM thin pool を使っている場合は、次にプール内の `LXDThinPool`論理ボリュームを拡大する必要があります (thin pool を使っていない場合はこのステップをスキップします)。 - - sudo lvextend /LXDThinPool -l+100%FREE - -以下の変数を置き換えてください。 - -`` -: snap を使用している場合 `/var/snap/lxd/common/lxd/` またはそれ以外の場合 `/var/lib/lxd/`。 - -`` -: ストレージプールの名前 (例えば `my-pool`)。 - -`` -: ストレージプールイメージに関連付けられているマウントされたループデバイス (例 `/dev/loop8`)。 - ループデバイスを見つけるには `losetup -j /disks/.img` と入力します。 -　`losetup -l` を使ってマウントされた全てのループデバイスのを一覧表示することもできます。 - -プールが期待通りリサイズされたかは以下のコマンドで確認できます。 - - sudo pvs # 物理ボリュームのサイズを確認 - sudo vgs # ボリュームグループのサイズを確認 - sudo lvs /LXDThinPool # thin pool のみ: thin-pool 論理ボリュームのサイズを確認 -``` -```{group-tab} ZFS - -ループバックの ZFS プールを 5 ギガバイト拡大するには以下のコマンドを入力します。 - - sudo truncate -s +5G /disks/.img - sudo zpool set autoexpand=on - sudo zpool online -e - sudo zpool set autoexpand=off - -以下の変数を置き換えてください。 - -`` -: snap を使用している場合 `/var/snap/lxd/common/lxd/` またはそれ以外の場合 `/var/lib/lxd/`。 - -`` -: ストレージプールの名前 (例えば `my-pool`)。 - -`` -: ZFS デバイスの ID。 - ID を見つけるには `sudo zpool status -vg ` を入力します。 -``` - -```` diff --git a/doc/howto/storage_resize_volume.md b/doc/howto/storage_resize_volume.md deleted file mode 100644 index f5d844d..0000000 --- a/doc/howto/storage_resize_volume.md +++ /dev/null @@ -1,16 +0,0 @@ -# ストレージボリュームをリサイズするには - -ボリュームにもっとストレージが必要案場合、ストレージボリュームのサイズを拡大できます。 -場合によっては、ストレージボリュームのサイズを縮小することもできます。 - -ストレージボリュームをリサイズするにはサイズ設定を設定します。 - - lxc storage volume set size - -```{important} -- ストレージボリュームの拡大は通常は正常に動作します (ストレージプールが十分なストレージを持つ場合)。 -- ストレージボリュームの縮小はコンテントタイプ `filesystem` のストレージボリュームでのみ可能です。 - ただし現在使用しているサイズより小さく縮小はできないので、縮小が保証されているわけではありません。 -- コンテントタイプ `block` のストレージボリュームの縮小は不可能です。 - -``` diff --git a/doc/howto/storage_view_buckets.md b/doc/howto/storage_view_buckets.md deleted file mode 100644 index 50b942e..0000000 --- a/doc/howto/storage_view_buckets.md +++ /dev/null @@ -1,22 +0,0 @@ -# ストレージバケットを表示するには - -ストレージプール内の全ての利用可能なストレージバケットの一覧を表示し設定を確認できます。 - -ストレージプール内の全ての利用可能なストレージバケットを一覧表示するには、以下のコマンドを使用します。 - - lxc storage bucket list - -特定のバケットの詳細情報を表示するには、以下のコマンドを使用します。 - - lxc storage bucket show - -## ストレージバケットのキーを表示するには - -既存のバケットに定義されているキーを表示するには以下のコマンドを使用します。 - - lxc storage bucket key list - -特定のバケットキーを表示するには以下のコマンドを使用します。 - - lxc storage bucket key show - diff --git a/doc/howto/storage_view_pools.md b/doc/howto/storage_view_pools.md deleted file mode 100644 index cace8b6..0000000 --- a/doc/howto/storage_view_pools.md +++ /dev/null @@ -1,13 +0,0 @@ -# ストレージプールを表示するには - -全ての利用可能なストレージプールの一覧を表示し設定を確認できます。 - -以下のコマンドで全ての利用可能なストレージプールを一覧表示できます。 - - lxc storage list - -出力結果の表には (訳注: LXD の) 初期化時に作成した (通常 `default` や `local` と呼ばれる) ストレージプールとあなたが追加したあらゆるストレージプールが含まれます。 - -特定のプールに関する詳細情報を表示するには、以下のコマンドを使用します。 - - lxc storage show diff --git a/doc/howto/storage_view_volumes.md b/doc/howto/storage_view_volumes.md deleted file mode 100644 index afe0756..0000000 --- a/doc/howto/storage_view_volumes.md +++ /dev/null @@ -1,23 +0,0 @@ -# ストレージプールとボリュームを表示するには - -ストレージブール内の全ての利用可能なストレージボリュームを一覧表示しそれらの設定を確認できます。 - -あるストレージプール内の全ての利用可能なストレージボリュームを一覧表示するには以下のコマンドを使用します。 - - lxc storage volume list - -結果の表にはそのプール内の各ストレージボリュームについて {ref}`ストレージボリュームタイプ ` と {ref}`コンテントタイプ ` が含まれます。 - -```{note} -カスタムストレージボリュームはインスタンスボリュームと同じ名前を使うこともできます (例えば `c1` という名前のコンテナストレージボリュームと `c1` という名前のカスタムストレージボリュームを持つ `c1` という名前のコンテナを作成することもできます)。 -このため、インスタンスストレージボリュームとカスタムストレージボリュームを区別するには、全てのインタンスストレージボリュームは `/` (例えば `container/c1` または `virtual-machine/vm`) のようにコマンド内で指定する必要があります。 -``` - - -特定のカスタムボリュームについて詳細な情報を表示するには以下のコマンドを使用します。 - - lxc storage volume show - -特定のインスタンスボリュームについて詳細な情報を表示するには以下のコマンドを使用します。 - - lxc storage volume show / diff --git a/doc/howto/storage_volumes.md b/doc/howto/storage_volumes.md new file mode 100644 index 0000000..b307306 --- /dev/null +++ b/doc/howto/storage_volumes.md @@ -0,0 +1,172 @@ +(howto-storage-volumes)= +# ストレージボリュームを管理するには + +{ref}`storage-volumes` を作成、設定、表示、リサイズするための手順については以下のセクションを参照してください。 + +## カスタムストレージボリュームを作成する + +インスタンスを作成する際に、 LXD はインスタンスのルートディスクとして使用するストレージボリュームを自動的に作成します。 + +インスタンスにカスタムストレージボリュームを追加できます。 +このカスタムストレージボリュームはインスタンスから独立しています。これは別にバックアップできたり、カスタムストレージボリュームを削除するまで残っていることを意味します。 +コンテントタイプが `filesystem` のカスタムストレージボリュームは異なるインスタンス間で共有もできます。 + +詳細な情報は {ref}`storage-volumes` を参照してください。 + +### ボリュームを作成する + +ストレージプール内にカスタムストレージボリュームを作成するには以下のコマンドを使用します。 + + lxc storage volume create [configuration_options...] + +各ドライバで利用可能なストレージボリューム設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 + +デフォルトではカスタムストレージボリュームは `filesystem` {ref}`コンテントタイプ ` を使用します。 +`block` コンテントタイプのカスタムストレージボリュームを作成するには `--type` フラグを追加してください。 + + lxc storage volume create --type=block [configuration_options...] + +クラスターメンバー上にカスタムストレージボリュームを追加するには `--target` フラグを追加してください。 + + lxc storage volume create --target= [configuration_options...] + +```{note} +ほとんどのストレージドライバではカスタムストレージボリュームはクラスター間で同期されず作成されたメンバー上にのみ存在します。 +この挙動は Ceph ベースのストレージプール (`ceph` and `cephfs`) では異なり、ボリュームはどのクラスターメンバーでも利用可能です。 +``` + +(storage-attach-volume)= +### インスタンスにカスタムストレージボリュームをアタッチする + +カスタムストレージボリュームを作成したら、それを 1 つあるいは複数のインスタンスに {ref}`ディスクデバイス ` として追加できます。 + +以下の制限があります。 + +- {ref}`コンテントタイプ ` `block` のカスタムストレージボリュームはコンテナにはアタッチできず、仮想マシンのみにアタッチできます。 +- データ破壊を防ぐため、 {ref}`コンテントタイプ ` `block` のカスタムストレージボリュームは同時に複数の仮想マシンには決してアタッチするべきではありません。 + +コンテントタイプ `filesystem` のカスタムストレージボリュームは以下のコマンドを使用します。ここで `` はインスタンス内でストレージボリュームにアクセスするためのパス (例: `/data`) です。 + + lxc storage volume attach + +コンテントタイプ `block` のカスタムストレージボリュームは `` を指定しません。 + + lxc storage volume attach + +デフォルトではカスタムストレージボリュームはインスタンスに {ref}`デバイス ` の名前でボリュームが追加されます。 +異なるデバイス名を使用したい場合は、コマンドにデバイス名を追加できます。 + + lxc storage volume attach + lxc storage volume attach + +(storage-configure-IO)= +#### I/O 制限値の設定 + +ストレージボリュームをインスタンスに {ref}`ディスクデバイス ` としてアタッチする際に、 I/O 制限値を設定できます。 +そのためには `limits.read`, `limits.write`, `limits.max` に対応する制限値を設定します。 +詳細な情報は {ref}`instance_device_type_disk` リファレンスを参照してください。 + +制限値は Linux の `blkio` cgroup コントローラー経由で適用されます。これによりディスクのレベルで I/O を制限することができます (しかしそれより細かい単位では制限できません)。 + +```{note} +制限値はパーティションやパスではなく物理ディスク全体に適用されるため、以下の制約があります。 + +- 仮想デバイス (例えば device mapper) 上に存在するファイルシステムには制限値は適用されません +- ファイルシステムが複数のブロックデバイス上に存在する場合、各デバイスは同じ制限を受けます。 +- 同じディスク上に存在する 2 つのディスクデバイスが同じインスタンスにアタッチされた場合は、 2 つのデバイスの制限値は平均されます +``` + +全ての I/O 制限値は実際のブロックデバイスアクセスにのみ適用されます。 +そのため、制限値を設定する際はファイルシステム自体のオーバーヘッドを考慮してください。 +キャッシュされたデータへのアクセスはこの制限値に影響されません。 + +(storage-volume-special)= +### バックアップやイメージにボリュームを使用する + +カスタムボリュームをディスクデバイスとしてインスタンスにアタッチする代わりに、{ref}`バックアップ ` あるいは {ref}`イメージ ` を格納する特別な種類のボリュームとして使うこともできます。 + +このためには、対応する {ref}`server` を設定する必要があります。 + +- バックアップ tarball を保管するためにカスタムボリュームを使用する。 + + lxc config set storage.backups_volume / + +- イメージ tarball を保管するためにカスタムボリュームを使用する。 + + lxc config set storage.images_volume / + +(storage-configure-volume)= +## ストレージボリュームを設定する + +各ストレージドライバで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 + +ストレージボリュームの設定オプションを設定するには以下のコマンドを使用します。 + + lxc storage volume set + +例えば、スナップショットの破棄期限を 1 ヶ月に設定するには以下のコマンドを使用します。 + + lxc storage volume set my-pool my-volume snapshots.expiry 1M + +インスタンスのストレージボリュームを設定するには、 {ref}`ストレージボリュームタイプ ` を含めたボリューム名を指定します。例えば + + lxc storage volume set my-pool container/my-container-volume user.XXX value + +ストレージボリューム設定を編集するには以下のコマンドを使用します。 + + lxc storage volume edit + +(storage-configure-vol-default)= +### ストレージボリュームのデフォルト値を変更する + +ストレージプールのデフォルトのボリューム設定を定義できます。 +そのためには、 `volume` 接頭辞をつけたストレージプール設定`volume.=` をセットします。 + +新しいストレージボリュームまたはインスタンスに明示的に設定されない限り、この値はプール内の全ての新しいストレージボリュームに使用されます。 +一般的に、ストレージプールのレベルに設定されたデフォルト値は (ボリュームが作成される前であれば) ボリューム設定でオーバーライドでき、ボリューム設定はインスタンス設定 ({ref}`タイプ ` が `container` か `vm` のストレージボリュームについて) でオーバーライドできます。 + +例えば、ストレージプールにデフォルトのボリュームサイズを設定するには以下のコマンドを使用します。 + + lxc storage set [:] volume.size + +## ストレージボリュームを表示する + +ストレージブール内の全ての利用可能なストレージボリュームを一覧表示しそれらの設定を確認できます。 + +あるストレージプール内の全ての利用可能なストレージボリュームを一覧表示するには以下のコマンドを使用します。 + + lxc storage volume list + +全てのプロジェクト (デフォルトのプロジェクトだけでなく) ストレージボリュームを表示するには、 `--all-projects` フラグを追加してください。 + +結果の表にはそのプール内の各ストレージボリュームについて {ref}`ストレージボリュームタイプ ` と {ref}`コンテントタイプ ` が含まれます。 + +```{note} +カスタムストレージボリュームはインスタンスボリュームと同じ名前を使うこともできます (例えば `c1` という名前のコンテナストレージボリュームと `c1` という名前のカスタムストレージボリュームを持つ `c1` という名前のコンテナを作成することもできます)。 +このため、インスタンスストレージボリュームとカスタムストレージボリュームを区別するには、全てのインタンスストレージボリュームは `/` (例えば `container/c1` または `virtual-machine/vm`) のようにコマンド内で指定する必要があります。 +``` + +特定のカスタムボリュームについて詳細な情報を表示するには以下のコマンドを使用します。 + + lxc storage volume show + +特定のインスタンスボリュームについて詳細な情報を表示するには以下のコマンドを使用します。 + + lxc storage volume show / + +## ストレージボリュームをリサイズする + +ボリュームにもっとストレージが必要案場合、ストレージボリュームのサイズを拡大できます。 +場合によっては、ストレージボリュームのサイズを縮小することもできます。 + +ストレージボリュームをリサイズするにはサイズ設定を設定します。 + + lxc storage volume set size + +```{important} +- ストレージボリュームの拡大は通常は正常に動作します (ストレージプールが十分なストレージを持つ場合)。 +- ストレージボリュームの縮小はコンテントタイプ `filesystem` のストレージボリュームでのみ可能です。 + ただし現在使用しているサイズより小さく縮小はできないので、縮小が保証されているわけではありません。 +- コンテントタイプ `block` のストレージボリュームの縮小は不可能です。 + +``` diff --git a/doc/image-handling.md b/doc/image-handling.md index a357f99..203d919 100644 --- a/doc/image-handling.md +++ b/doc/image-handling.md @@ -2,12 +2,14 @@ discourse: 9310 --- +(image-handling)= # イメージの扱い ```{youtube} https://www.youtube.com/watch?v=wT7IDjo0Wgg ``` ## イントロダクション + LXD はイメージをベースとしたワークフローを使用します。 LXD にはビルトイン のイメージ・ストアがあり、ユーザーが外部のツールがそこからイメージをインポート できます。 @@ -19,13 +21,15 @@ LXD はイメージをベースとしたワークフローを使用します。 ケースではイメージはターゲットの LXD にキャッシュされます。 ## ソース + LXD は 3 つの異なるソースからのイメージのインポートをサポートします。 - - リモートのイメージサーバ (LXD か simplestreams) - - イメージファイルの direct push - - リモートのウェブサーバ上のファイル +- リモートのイメージサーバ (LXD か simplestreams) +- イメージファイルの direct push +- リモートのウェブサーバ上のファイル ### リモートのイメージサーバ (LXD か simplestreams) + これは最も一般的なイメージソースで 3 つの選択肢のうちインスタンスの作成時に直接サポートされている唯一の選択肢です。 この選択肢では、イメージサーバは検証されるために必要な証明書（HTTPS のみがサポートされます）と共にターゲットの LXD サーバに提供されます。 @@ -44,6 +48,7 @@ CLI の視点では、これは以下の一般的なアクションによって `my-server` リモートのケースでは別の LXD サーバがあり、上記の例ではフィンガープリントによってイメージを選択します。 ### イメージファイルの direct push + これは主に外部サーバから直接イメージを取得できない隔離された環境で有用です。 そのような状況ではイメージファイルは他のシステムで以下のコマンドを使ってダウンロードできます。 @@ -58,18 +63,18 @@ CLI の視点では、これは以下の一般的なアクションによって 上の例では後者を使用しています。 ### リモートのウェブサーバ上のファイル + 単一のイメージをユーザーに配布するためだけにフルのイメージサーバを動かすことの代替として、 LXD は URL を指定してイメージをインポートするのもサポートしています。 ただし、この方法にはいくつか制限があります。 - - 統合ファイル（単一ファイル）のみがサポートされます - - リモートサーバが追加の HTTP ヘッダーを返す必要があります +- 統合ファイル（単一ファイル）のみがサポートされます +- リモートサーバが追加の HTTP ヘッダーを返す必要があります LXD はサーバに問い合わせをする際に以下のヘッダーを設定します。 - - `LXD-Server-Architectures` にはクライアントがサポートするアーキテクチャーのカンマ区切りリストを設定します - - `LXD-Server-Version` には使用している LXD のバージョンを設定します - +- `LXD-Server-Architectures` にはクライアントがサポートするアーキテクチャーのカンマ区切りリストを設定します +- `LXD-Server-Version` には使用している LXD のバージョンを設定します リモートサーバが `LXD-Image-Hash` と `LXD-Image-URL` を設定することを期待します。 前者はダウンロードされるイメージの SHA256 ハッシュで後者はイメージをダウンロードする URL です。 @@ -81,6 +86,7 @@ LXD はサーバに問い合わせをする際に以下のヘッダーを設定 lxc image import URL --alias some-name ### インスタンスやスナップショットを新しいイメージとして公開する + インスタンスやスナップショットの 1 つを新しいイメージに変換できます。 これは `lxc publish` で CLI 上で実行できます。 @@ -91,6 +97,7 @@ LXD はサーバに問い合わせをする際に以下のヘッダーを設定 この操作は特に I/O と CPU の負荷が高いので、公開操作は LXD により 1 つずつ順に実行されます。 ## キャッシュ + リモートのイメージからインスタンスを起動する時、リモートのイメージが ローカルのイメージ・ストアにキャッシュ・ビットをセットした状態で ダウンロードされます。イメージは、 `images.remote_cache_expiry` に @@ -102,6 +109,7 @@ LXD はイメージから新しいインスタンスが起動される度にイ プロパティを更新することで、イメージの利用状況を記録しています。 ## 自動更新 + LXD はイメージを最新に維持できます。デフォルトではエイリアスで指定し リモートサーバから取得したイメージは LXD によって自動更新されます。 これは `images.auto_update_cached` という設定で変更できます。 @@ -127,6 +135,7 @@ LXD はイメージを最新に維持できます。デフォルトではエイ 発生し、 `images.auto_update_interval` を 0 にすることで無効にできます。 ## プロファイル + `lxc image edit` コマンドを使ってイメージにプロファイルのリストを関連付けできます。 イメージにプロファイルを関連付けた後に起動したインスタンスはプロファイルを順番に適用します。 プロファイルのリストとして `nil` を指定すると `default` プロファイルのみがイメージに関連付けされます。 @@ -134,6 +143,7 @@ LXD はイメージを最新に維持できます。デフォルトではエイ イメージに関連付けされたプロファイルは `lxc launch` の `--profile` と `--no-profiles` オプションを使ってインスタンス起動時にオーバーライドできます。 ## 特別なイメージプロパティ + プレフィックス***requirements***で始まるイメージプロパティ(例：`requirements.XYZ`)は、 LXDがホストシステムと当該イメージで生成されるインスタンスの互換性を判断するために使用されます。 これらの互換性がない場合にはLXDはそのインスタンスを起動しません。 @@ -146,6 +156,7 @@ LXDがホストシステムと当該イメージで生成されるインスタ `requirements.cgroup` | string | - | `v1` に設定されている場合、ホストで`CGroupV1`が実行されている必要があることを示します。 ## イメージの形式 + LXD は現状 2 つの LXD に特有なイメージの形式をサポートします。 1 つめは統合された tarball で、単一の tarball がインスタンスの root と @@ -161,21 +172,23 @@ LXD 自身によって生成されるのは前者の形式で、 LXD 特有の を使ってイメージを簡単に作成できるように想定されているものです。 ### 統合された tarball + tarball は圧縮できます。そして次のものを含みます。 - - `rootfs/` - - `metadata.yaml` - - `templates/` (省略可能) +- `rootfs/` +- `metadata.yaml` +- `templates/` (省略可能) このモードではイメージの識別子は tarball の SHA-256 です。 ### 分離された tarball + 2 つの (圧縮しても良い) tarball 。 1 つはメタデータ、もう 1 つは rootfs です。 `metadata.tar` は以下のものを含みます。 - - `metadata.yaml` - - `templates/` (省略可能) +- `metadata.yaml` +- `templates/` (省略可能) `rootfs.tar` は、そのルートに Linux の root ファイルシステムを含みます。 @@ -183,12 +196,14 @@ tarball は圧縮できます。そして次のものを含みます。 結合したものの SHA-256 です。 ### サポートされている圧縮形式 + LXD は広範な tarball の圧縮アルゴリズムをサポートしますが、互換性のために `gzip` か `xz` が望ましいです。 分離されたイメージではコンテナの場合は rootfs ファイルはさらに SquashFS 形式でフォーマットすることもできます。 仮想マシンでは `rootfs.img` ファイルは常に `qcow2` であり、オプションで `qcow2` のネイティブ圧縮を使って圧縮することもできます。 ### 中身 + コンテナでは rootfs のディレクトリ (あるいは tarball) は完全なファイルシステムのツリーを含み、それが `/` になります。 VM ではこれは代わりに `rootfs.img` ファイルでメインのディスクデバイスになります。 @@ -229,19 +244,19 @@ templates: テンプレートで `when` キーは以下の 1 つあるいは複数が指定可能です。 - - `create` (そのイメージから新しいインスタンスが作成されたときに実行される) - - `copy` (既存のインスタンスから新しいインスタンスが作成されたときに実行される) - - `start` (インスタンスが開始される度に実行される) +- `create` (そのイメージから新しいインスタンスが作成されたときに実行される) +- `copy` (既存のインスタンスから新しいインスタンスが作成されたときに実行される) +- `start` (インスタンスが開始される度に実行される) テンプレートは常に以下のコンテキストを受け取ります。 - - `trigger`: テンプレートを呼び出したイベントの名前 (string) - - `path`: テンプレートを使うファイルのパス (string) - - `container`: インスタンスのプロパティ (name, architecture, privileged そして ephemeral) の key/value の map (map[string]string) (廃止予定。代わりに `instance` を使用してください) - - `instance`: インスタンスのプロパティ (name, architecture, privileged そして ephemeral) の key/value の map (map[string]string) - - `config`: インスタンスの設定の key/value の map (map[string]string) - - `devices`: インスタンスに割り当てられたデバイスの key/value の map (map[string]map[string]string) - - `properties`: `metadata.yaml` に指定されたテンプレートのプロパティの key/value の map (map[string]string) +- `trigger`: テンプレートを呼び出したイベントの名前 (string) +- `path`: テンプレートを使うファイルのパス (string) +- `container`: インスタンスのプロパティ (name, architecture, privileged そして ephemeral) の key/value の map (map[string]string) (廃止予定。代わりに `instance` を使用してください) +- `instance`: インスタンスのプロパティ (name, architecture, privileged そして ephemeral) の key/value の map (map[string]string) +- `config`: インスタンスの設定の key/value の map (map[string]string) +- `devices`: インスタンスに割り当てられたデバイスの key/value の map (map[string]map[string]string) +- `properties`: `metadata.yaml` に指定されたテンプレートのプロパティの key/value の map (map[string]string) `create_only` キーを設定すると LXD が存在しないファイルだけを生成し、 既存のファイルを上書きしないようにできます。 @@ -252,4 +267,4 @@ templates: 利便性のため、以下の関数が Pongo2 のテンプレートで利用可能となっています。 - - `config_get("user.foo", "bar")` => `user.foo` の値か、未設定の場合は `"bar"` を返します。 +- `config_get("user.foo", "bar")` => `user.foo` の値か、未設定の場合は `"bar"` を返します。 diff --git a/doc/index.md b/doc/index.md index 433ca59..dbb0217 100644 --- a/doc/index.md +++ b/doc/index.md @@ -1,5 +1,11 @@ +--- +relatedlinks: https://linuxcontainers.org/, https://ubuntu.com/lxd, https://ubuntu.com/blog/open-source-for-beginners-dev-environment-with-lxd +--- + [![LXD](../doc/_static/download/containers.png)](https://linuxcontainers.org/lxd) +# LXD + % Include content from [../README.md](../README.md) ```{include} ../README.md :start-after: @@ -14,7 +20,7 @@ :end-before: ``` -詳細は[](security.md)をご覧ください。 +詳細は[セキュリティ](security.md)をご覧ください。 ````{important} % Include content from [../README.md](../README.md) diff --git a/doc/installing.md b/doc/installing.md index af56371..3e482b1 100644 --- a/doc/installing.md +++ b/doc/installing.md @@ -15,6 +15,7 @@ LXD をインストールする最も簡単な方法は提供されているパ (installing_from_source)= ## LXD のソースからのインストール + LXD の開発には `liblxc` の最新バージョン（4.0.0 以上が必要）を使用することをおすすめします。 さらに LXD が動作するためには Golang 1.18 以上が必要です。 Ubuntu では次のようにインストールできます: @@ -24,7 +25,7 @@ sudo apt update sudo apt install acl attr autoconf automake dnsmasq-base git golang libacl1-dev libcap-dev liblxc1 liblxc-dev libsqlite3-dev libtool libudev-dev liblz4-dev libuv1-dev make pkg-config rsync squashfs-tools tar tcl xz-utils ebtables ``` -デフォルトのストレージドライバである `directory` ドライバに加えて、LXD ではいくつかのストレージドライバが使えます。 +デフォルトのストレージドライバである `dir` ドライバに加えて、LXD ではいくつかのストレージドライバが使えます。 これらのツールをインストールすると、initramfs への追加が行われ、ホストのブートが少しだけ遅くなるかもしれませんが、特定のドライバを使いたい場合には必要です: ```bash @@ -39,6 +40,7 @@ sudo apt install curl gettext jq sqlite3 socat bind9-dnsutils ``` ### ソースからの最新版のビルド + この方法は LXD の最新版をビルドしたい開発者や Linux ディストリビューションで提供されない LXD の特定のリリースをビルドするためのものです。 Linux ディストリビューションへ統合するためのソースからのビルドはここでは説明しません。それは将来、別のドキュメントで取り扱うかもしれません。 ```bash @@ -90,6 +92,7 @@ export LD_LIBRARY_PATH="$(go env GOPATH)/deps/dqlite/.libs/:$(go env GOPATH)/dep これで `lxd` と `lxc` コマンドの実行ファイルが利用可能になり LXD をセットアップするのに使用できます。 `LD_LIBRARY_PATH` 環境変数のおかげで実行ファイルは `$(go env GOPATH)/deps` にビルドされた依存ライブラリーを自動的に見つけて使用します。 ### マシンセットアップ + LXD が非特権コンテナを作成できるように、root ユーザーに対する sub{u,g}id の設定が必要です: ```bash @@ -105,3 +108,16 @@ sudo -E PATH=${PATH} LD_LIBRARY_PATH=${LD_LIBRARY_PATH} $(go env GOPATH)/bin/lxd ```{note} `newuidmap/newgidmap`ツールがシステムに存在し、`/etc/subuid`、`/etc/subgid`が存在する場合は、rootユーザーに少なくとも10MのUID/GIDの連続した範囲を許可するように設定する必要があります。 ``` + +## LXD のアップグレード + +LXD を新しいバージョンにアップグレードした後、 LXD はデータベースを新しいスキーマにアップデートする必要があるかもしれません。 +このアップデートは LXD のアップグレードの後のデーモン起動時に自動的に実行されます。 +アップデート前のデータベースのバックアップはアクティブなデータベースと同じ場所 (例えば snap の場合は `/var/snap/lxd/common/lxd/database`) に保存されます。 + +```{important} +スキーマのアップデート後は、古いバージョンの LXD はデータベースを無効とみなすかもしれません。 +これはつまり LXD をダウングレードしてもあなたの LXD の環境は利用不可能と言われるかもしれないということです。 + +このようなダウングレードが必要な場合は、ダウングレードを行う前にデータベースのバックアップをリストアしてください。 +``` diff --git a/doc/instance-exec.md b/doc/instance-exec.md index c2217a2..46e0116 100644 --- a/doc/instance-exec.md +++ b/doc/instance-exec.md @@ -1,4 +1,5 @@ # インスタンスのコマンド実行 + LXDは与えられたインスタンス内でコマンドを実行することを容易にします。 コンテナでは、これは常に動作し、LXDによって直接処理されます。 仮想マシンでは、これは仮想マシン内で動作する`lxd-agent`プロセスに依存します。 @@ -10,6 +11,7 @@ CLIレベルでは、これは`lxc exec`コマンドによって達成されま APIレベルでは、`/1.0/instances/NAME/exec`で実現されます。 ## 実行モード + LXDはコマンドを対話的にも非対話的にも実行できます。 インタラクティブモードでは、入力(stdin)と出力(stdout, stderr)を扱うために疑似端末装置(PTS)が使用されます。 @@ -19,6 +21,7 @@ LXDはコマンドを対話的にも非対話的にも実行できます。 これにより、多くのスクリプトで必要とされるように、コマンドを実行しながら、stdin、stdout、stderrを別々に適切に取得することができます。 ## ユーザー、グループ、作業ディレクトリ + LXDはインスタンス内のデータを読まない、あるいはその中にあるものを信用しないというポリシーを持っています。 これは、LXDがユーザーやグループの解決を処理するために、`/etc/passwd`、`/etc/group`や`/etc/nsswitch.conf`のようなものを解析しないことを意味しています。 @@ -31,18 +34,21 @@ LXDはインスタンス内のデータを読まない、あるいはその中 LXDが解決してくれるわけではないので、利用者が指定する必要があります。 ## 環境 + execセッション中に設定される環境変数は、いくつかのソースから得られます。 - - インスタンスに直接設定される`environment.KEY=VALUE` - - execセッション中に直接渡される環境変数 - - LXDによって設定されるデフォルト変数 + +- インスタンスに直接設定される`environment.KEY=VALUE` +- execセッション中に直接渡される環境変数 +- LXDによって設定されるデフォルト変数 最後のカテゴリでは、LXDは`PATH`を`/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin`に設定し、 必要に応じて `/snap` と `/etc/NIXOS` で拡張されます。 さらに、`LANG`には`C.UTF-8`が設定されます。 root (UID 0) として実行する場合は、以下の変数も設定されます。 - - `HOME` に `/root` が設定されます。 - - `USER` に `root` が設定される。 + +- `HOME` に `/root` が設定されます。 +- `USER` に `root` が設定されます。 他のユーザーとして実行する場合、正しい値を指定するのはそのユーザーの責任です。 diff --git a/doc/instances.md b/doc/instances.md index df10bbe..d8b4116 100644 --- a/doc/instances.md +++ b/doc/instances.md @@ -5,42 +5,46 @@ discourse: 8355 # インスタンスの設定 ## インスタンス + ### プロパティ + 次のプロパティは、インスタンスに直接結びつくプロパティであり、プロファイルの一部ではありません: - - `name` - - `architecture` +- `name` +- `architecture` `name` はインスタンス名であり、インスタンスのリネームでのみ変更できます。 有効なインスタンス名は次の条件を満たさなければなりません: - - 1 ～ 63 文字 - - ASCII テーブルの文字、数字、ダッシュのみから構成される - - 1 文字目は数字、ダッシュではない - - 最後の文字はダッシュではない +- 1 ～ 63 文字 +- ASCII テーブルの文字、数字、ダッシュのみから構成される +- 1 文字目は数字、ダッシュではない +- 最後の文字はダッシュではない この要件は、インスタンス名が DNS レコードとして、ファイルシステム上で、色々なセキュリティプロファイル、そしてインスタンス自身のホスト名として適切に使えるように定められています。 ### Key/value 形式の設定 + key/value 形式の設定は、名前空間構造を取っており、現在は次のような名前空間があります: - - `boot` (ブートに関連したオプション、タイミング、依存性、…) - - `cloud-init` (cloud-init の設定) - - `environment` (環境変数) - - `image` (作成時のイメージプロパティのコピー) - - `limits` (リソース制限) - - `nvidia` (NVIDIA と CUDA の設定) - - `raw` (生のインスタンス設定を上書きする) - - `security` (セキュリティポリシー) - - `user` (ユーザーの指定するプロパティを保持。検索可能) - - `volatile` (インスタンス固有の内部データを格納するために LXD が内部的に使用する設定) +- `boot` (ブートに関連したオプション、タイミング、依存性、…) +- `cloud-init` (cloud-init の設定) +- `environment` (環境変数) +- `image` (作成時のイメージプロパティのコピー) +- `limits` (リソース制限) +- `nvidia` (NVIDIA と CUDA の設定) +- `raw` (生のインスタンス設定を上書きする) +- `security` (セキュリティポリシー) +- `user` (ユーザーの指定するプロパティを保持。検索可能) +- `volatile` (インスタンス固有の内部データを格納するために LXD が内部的に使用する設定) 現在設定できる項目は次のものです: ```{rst-class} dec-font-size break-col-1 min-width-1-15 min-width-5-6 ``` +(instance-configuration)= キー | 型 | デフォルト値 | ライブアップデート | 条件 | 説明 :-- | :--- | :------ | :---------- | :---------- | :---------- `agent.nic_config` | bool | `false` | n/a | 仮想マシン | デフォルトのネットワークインタフェースの名前と MTU をインスタンスデバイスと同じにするかどうか(これはコンテナでは自動でそうなります) @@ -166,6 +170,7 @@ lxc config set 生（raw）の設定は、LXD が使うバックエンドの機能に直接アクセスできます。これを設定することは、自明ではない方法で LXD を破壊する可能性がありますので、可能な限り避ける必要があります。 #### CPU 制限 + CPU 制限は cgroup コントローラの `cpuset` と `cpu` を組み合わせて実装しています。 `limits.cpu` は `cpuset` コントローラを使って、使う CPU を固定（ピンニング）します。 @@ -185,6 +190,7 @@ CPU 制限は cgroup コントローラの `cpuset` と `cpu` を組み合わせ `limits.cpu.priority` は、CPU の組を共有するいくつかのインスタンスに割り当てられた CPU の割合が同じ場合に、スケジューラの優先度スコアを計算するために使われます。 #### VM CPU トポロジー + LXD の仮想マシンはデフォルトでは vCPU を 1 つだけ割り当てて、それは ホストの CPU のベンダーとタイプにマッチしたものとして表示されますが シングルコアでスレッドはありません。 @@ -209,20 +215,21 @@ NUMA レイアウトも同様に複製され、このシナリオではゲスト ソケット、コア、スレッドについて適切に判断し、 NUMA トポロジーも考慮できるからです。 ## デバイス設定 + LXD は、標準の POSIX システムが動作するのに必要な基本的なデバイスを常にインスタンスに提供します。これらはインスタンスやプロファイルの設定では見えず、上書きもできません。 このデバイスには次のようなデバイスが含まれます: - - `/dev/null` (キャラクターデバイス) - - `/dev/zero` (キャラクターデバイス) - - `/dev/full` (キャラクターデバイス) - - `/dev/console` (キャラクターデバイス) - - `/dev/tty` (キャラクターデバイス) - - `/dev/random` (キャラクターデバイス) - - `/dev/urandom` (キャラクターデバイス) - - `/dev/net/tun` (キャラクターデバイス) - - `/dev/fuse` (キャラクターデバイス) - - `lo` (ネットワークインターフェース) +- `/dev/null` (キャラクターデバイス) +- `/dev/zero` (キャラクターデバイス) +- `/dev/full` (キャラクターデバイス) +- `/dev/console` (キャラクターデバイス) +- `/dev/tty` (キャラクターデバイス) +- `/dev/random` (キャラクターデバイス) +- `/dev/urandom` (キャラクターデバイス) +- `/dev/net/tun` (キャラクターデバイス) +- `/dev/fuse` (キャラクターデバイス) +- `lo` (ネットワークインターフェース) これ以外に関しては、インスタンスの設定もしくはインスタンスで使われるいずれかのプロファイルで定義する必要があります。デフォルトのプロファイルには、インスタンス内で `eth0` になるネットワークインターフェースが通常は含まれます。 @@ -246,6 +253,7 @@ lxc profile device add [key=value]... (devices)= ### デバイスタイプ + LXD では次のデバイスタイプが使えます: ID (データベース) | 名前 | 条件 | 説明 @@ -276,6 +284,7 @@ none タイプのデバイスはプロパティを一切持たず、インスタ (instance_device_type_nic)= #### タイプ: `nic` + LXD では、様々な種類のネットワークデバイス（ネットワークインターフェースコントローラーや NIC と呼びます）が使えます: インスタンスにネットワークデバイスを追加する際には、追加したいデバイスのタイプを選択するのに 2 つの方法があります。 @@ -295,21 +304,20 @@ NIC ごとにどのプロパティが設定可能かの詳細については下 次の NIC は `nictype` か `network` プロパティを使って選択できます。 - - [`bridged`](#nic-bridged): ホスト上に存在するブリッジを使います。ホストのブリッジとインスタンスを接続する仮想デバイスペアを作成します。 - - [`macvlan`](#nic-macvlan): 既存のネットワークデバイスをベースに MAC が異なる新しいネットワークデバイスを作成します。 - - [`sriov`](#nic-sriov): SR-IOV が有効な物理ネットワークデバイスの仮想ファンクション（virtual function）をインスタンスに与えます。 +- [`bridged`](#nic-bridged): ホスト上に存在するブリッジを使います。ホストのブリッジとインスタンスを接続する仮想デバイスペアを作成します。 +- [`macvlan`](#nic-macvlan): 既存のネットワークデバイスをベースに MAC が異なる新しいネットワークデバイスを作成します。 +- [`sriov`](#nic-sriov): SR-IOV が有効な物理ネットワークデバイスの仮想ファンクション（virtual function）をインスタンスに与えます。 次の NIC は `network` プロパティのみを使って選択できます。 - - [`ovn`](#nic-ovn): 既存の OVN ネットワークを使用し、インスタンスが接続する仮想デバイスペアを作成します。 +- [`ovn`](#nic-ovn): 既存の OVN ネットワークを使用し、インスタンスが接続する仮想デバイスペアを作成します。 -次の NIC は `nictype` プロパティのみを使って選択できます。 + の NIC は `nictype` プロパティのみを使って選択できます。 - - [`physical`](#nic-physical): ホストの物理デバイスを直接使います。対象のデバイスはホスト上では見えなくなり、インスタンス内に出現します。 - - [`ipvlan`](#nic-ipvlan): 既存のネットワークデバイスをベースに MAC アドレスは同じですが IP アドレスが異なる新しいネットワークデバイスを作成します。 - - [`p2p`](#nic-p2p): 仮想デバイスペアを作成し、片方をインスタンス内に置き、残りの片方をホスト上に残します。 - - [`routed`](#nic-routed): 仮想デバイスペアを作成し、ホストからインスタンスに繋いで静的ルートをセットアップし ARP/NDP エントリーをプロキシします。これにより指定された親インタフェースのネットワークに -インスタンスが参加できるようになります。 +- [`physical`](#nic-physical): ホストの物理デバイスを直接使います。対象のデバイスはホスト上では見えなくなり、インスタンス内に出現します。 +- [`ipvlan`](#nic-ipvlan): 既存のネットワークデバイスをベースに MAC アドレスは同じですが IP アドレスが異なる新しいネットワークデバイスを作成します。 +- [`p2p`](#nic-p2p): 仮想デバイスペアを作成し、片方をインスタンス内に置き、残りの片方をホスト上に残します。 +- [`routed`](#nic-routed): 仮想デバイスペアを作成し、ホストからインスタンスに繋いで静的ルートをセットアップし ARP/NDP エントリーをプロキシします。これにより指定された親インタフェースのネットワークにインスタンスが参加できるようになります。 (instance_device_type_nic_bridged)= ##### `nic`: `bridged` @@ -631,18 +639,20 @@ net.ipv6.conf..proxy_ndp=1 `vlan` | integer | - | no | アタッチ先の VLAN ID `gvrp` | bool | `false` | no | GARP VLAN Registration Protocol を使って VLAN を登録する -##### ブリッジ、`macvlan`、`ipvlan` を使った物理ネットワークへの接続 +##### `bridge`、`macvlan`、`ipvlan` を使った物理ネットワークへの接続 + `bridged`、`macvlan`、`ipvlan` インターフェースタイプのいずれも、既存の物理ネットワークへ接続できます。 `macvlan` は、物理 NIC を効率的に分岐できます。つまり、物理 NIC からインスタンスで使える第 2 のインターフェースを取得できます。`macvlan` を使うことで、ブリッジデバイスと `veth` ペアの作成を減らせますし、通常はブリッジよりも良いパフォーマンスが得られます。 `macvlan` の欠点は、`macvlan` は外部との間で通信はできますが、自身の親デバイスとは通信できないことです。つまりインスタンスとホストが通信する必要がある場合は `macvlan` は使えません。 -そのような場合は、ブリッジを選ぶのが良いでしょう。`macvlan` では使えない MAC フィルタリングと I/O 制限も使えます。 +そのような場合は、 `bridge` デバイスを選ぶのが良いでしょう。`macvlan` では使えない MAC フィルタリングと I/O 制限も使えます。 `ipvlan` は `macvlan` と同様ですが、フォークされたデバイスが静的に割り当てられた IP アドレスを持ち、ネットワーク上の親の MAC アドレスを受け継ぐ点が異なります。 ##### SR-IOV + `sriov` インターフェースタイプで、SR-IOV が有効になったネットワークデバイスを使えます。このデバイスは、複数の仮想ファンクション（Virtual Functions: VFs）をネットワークデバイスの単一の物理ファンクション（Physical Function: PF）に関連付けます。 PF は標準の PCIe ファンクションです。一方、VFs は非常に軽量な PCIe ファンクションで、データの移動に最適化されています。 VFs は PF のプロパティを変更できないように、制限された設定機能のみを持っています。 @@ -661,6 +671,7 @@ lxc config device add nic nictype=sriov parent= nic nictype=sriov parent= infiniband nictype=physical paren ``` ##### InfiniBand デバイスでの SR-IOV + InfiniBand デバイスは SR-IOV をサポートしますが、他の SR-IOV と違って、SR-IOV モードでの動的なデバイスの作成はできません。 つまり、カーネルモジュール側で事前に仮想ファンクション（virtual functions）の数を設定する必要があるということです。 @@ -717,22 +729,27 @@ lxc config device add infiniband nictype=sriov parent=< LXD では以下の追加のソースタイプをサポートします。 - Ceph RBD: 外部で管理されている既存の Ceph RBD デバイスからマウントします。 LXD は Ceph をインスタンスの内部のファイルシステムを管理するのに使用できます。ユーザーが事前に既存の Ceph RBD を持っておりそれをインスタンスに使いたい場合はこのコマンドを使用できます。 -コマンド例 -``` -lxc config device add ceph-rbd1 disk source=ceph:/ ceph.user_name= ceph.cluster_name= path=/ceph -``` + + コマンド例 + + ``` + lxc config device add ceph-rbd1 disk source=ceph:/ ceph.user_name= ceph.cluster_name= path=/ceph + ``` + - CephFS: 外部で管理されている既存の Ceph FS からマウントします。 LXD は Ceph をインスタンスの内部のファイルシステムを管理するのに使用できます。ユーザーが事前に既存の Ceph ファイルシステムを持っておりそれをインスタンスに使いたい場合はこのコマンドを使用できます。 -コマンド例 -``` -lxc config device add ceph-fs1 disk source=cephfs:/ ceph.user_name= ceph.cluster_name= path=/cephfs -``` + + コマンド例 + + ``` + lxc config device add ceph-fs1 disk source=cephfs:/ ceph.user_name= ceph.cluster_name= path=/cephfs + ``` + - VM cloud-init: `user.vendor-data`, `user.user-data` と `user.meta-data` 設定キーから cloud-init 設定の ISO イメージを生成し VM にアタッチできるようにします。この ISO イメージは VM 内で動作する cloud-init が起動時にドライバを検出し設定を適用します。仮想マシンのインスタンスでのみ利用可能です。 -コマンド例 -``` -lxc config device add config disk source=cloud-init:config -``` -現状では仮想マシンではルートディスク (`path=/`) と `config` ドライブ (`source=cloud-init:config`) のみがサポートされます。 + コマンド例 + ``` + lxc config device add config disk source=cloud-init:config + ``` 次に挙げるプロパティがあります: @@ -826,10 +843,10 @@ GPU デバイスエントリーは、シンプルにリクエストのあった 以下の GPU が `gputype` プロパティを使って指定できます。 - - [`physical`](#gpu-physical) GPU 全体をパススルーします。 `gputype` が指定されない場合これがデフォルトです。 - - [`mdev`](#gpu-mdev) 仮想 GPU を作成しインスタンスにパススルーします。 - - [`mig`](#gpu-mig) MIG (Multi-Instance GPU) を作成しインスタンスにパススルーします。 - - [`sriov`](#gpu-sriov) SR-IOV を有効にした GPU の仮想ファンクション（virtual function）をインスタンスに与えます。 +- [`physical`](#gpu-physical) GPU 全体をパススルーします。 `gputype` が指定されない場合これがデフォルトです。 +- [`mdev`](#gpu-mdev) 仮想 GPU を作成しインスタンスにパススルーします。 +- [`mig`](#gpu-mig) MIG (Multi-Instance GPU) を作成しインスタンスにパススルーします。 +- [`sriov`](#gpu-sriov) SR-IOV を有効にした GPU の仮想ファンクション（virtual function）をインスタンスに与えます。 ##### `gpu`: `physical` @@ -909,15 +926,16 @@ SR-IOV が有効な GPU の仮想ファンクション（virtual function）を このデバイスを使って、ホストのアドレスの一つに到達したトラフィックをインスタンス内のアドレスに転送したり、その逆を行ったりして、ホストを通してインスタンス内にアドレスを持てます。 利用できる接続タイプは次の通りです: -* `tcp <-> tcp` -* `udp <-> udp` -* `unix <-> unix` -* `tcp <-> unix` -* `unix <-> tcp` -* `udp <-> tcp` -* `tcp <-> udp` -* `udp <-> unix` -* `unix <-> udp` + +- `tcp <-> tcp` +- `udp <-> udp` +- `unix <-> unix` +- `tcp <-> unix` +- `unix <-> tcp` +- `udp <-> tcp` +- `tcp <-> udp` +- `udp <-> unix` +- `unix <-> udp` プロキシデバイスは `nat` モードもサポートします。 `nat` モードではパケットは別の接続を通してプロキシされるのではなく NAT を使ってフォワードされます。 @@ -933,8 +951,8 @@ lxc config device set ipv4.address= ipv6.address= NAT モードでサポートされる接続のタイプは以下の通りです。 -* `tcp <-> tcp` -* `udp <-> udp` +- `tcp <-> tcp` +- `udp <-> udp` IPv6 アドレスを設定する場合は以下のような角括弧の記法を使います。 @@ -1008,56 +1026,58 @@ PCI デバイスエントリーは生の PCI デバイスをホストから仮 (instances-limit-units)= ### ストレージとネットワーク制限の単位 + バイト数とビット数を表す値は全ていくつかの有用な単位を使用し特定の制限がどういう値かをより理解しやすいようにできます。 10進と2進 (kibi) の単位の両方がサポートされており、後者は主にストレージの制限に有用です。 現在サポートされているビットの単位の完全なリストは以下の通りです。 - - bit (1) - - kbit (1000) - - Mbit (1000^2) - - Gbit (1000^3) - - Tbit (1000^4) - - Pbit (1000^5) - - Ebit (1000^6) - - Kibit (1024) - - Mibit (1024^2) - - Gibit (1024^3) - - Tibit (1024^4) - - Pibit (1024^5) - - Eibit (1024^6) +- bit (1) +- kbit (1000) +- Mbit (1000^2) +- Gbit (1000^3) +- Tbit (1000^4) +- Pbit (1000^5) +- Ebit (1000^6) +- Kibit (1024) +- Mibit (1024^2) +- Gibit (1024^3) +- Tibit (1024^4) +- Pibit (1024^5) +- Eibit (1024^6) 現在サポートされているバイトの単位の完全なリストは以下の通りです。 - - B または bytes (1) - - kB (1000) - - MB (1000^2) - - GB (1000^3) - - TB (1000^4) - - PB (1000^5) - - EB (1000^6) - - KiB (1024) - - MiB (1024^2) - - GiB (1024^3) - - TiB (1024^4) - - PiB (1024^5) - - EiB (1024^6) +- B または bytes (1) +- kB (1000) +- MB (1000^2) +- GB (1000^3) +- TB (1000^4) +- PB (1000^5) +- EB (1000^6) +- KiB (1024) +- MiB (1024^2) +- GiB (1024^3) +- TiB (1024^4) +- PiB (1024^5) +- EiB (1024^6) ### インスタンスタイプ + LXD ではシンプルなインスタンスタイプが使えます。これは、インスタンスの作成時に指定できる文字列で表されます。 3 つの指定方法があります: - - `` - - `:` - - `c-m` +- `` +- `:` +- `c-m` 例えば、次の 3 つは同じです: - - `t2.micro` - - `aws:t2.micro` - - `c1-m1` +- `t2.micro` +- `aws:t2.micro` +- `c1-m1` コマンドラインでは、インスタンスタイプは次のように指定します: @@ -1070,6 +1090,7 @@ lxc launch ubuntu:22.04 my-instance -t t2.micro [`https://github.com/dustinkirkland/instance-type`](https://github.com/dustinkirkland/instance-type) ### `limits.hugepages.[size]` を使った huge page の制限 + LXD では `limits.hugepage.[size]` キーを使ってコンテナが利用できる huge page の数を制限できます。 huge page の制限は `hugetlb` cgroup コントローラーを使って行われます。 これはつまりこれらの制限を適用するためにホストシステムが `hugetlb` コントローラーを legacy あるいは unified cgroup の階層に公開する必要があることを意味します。 @@ -1082,6 +1103,7 @@ LXD が `hugetlbfs` `mount` システムコールをインターセプトする しかし、ホストで利用可能な huge page をコンテナが使い切ってしまうのを防ぐため、 `limits.hugepages.[size]` を使ってコンテナが利用可能な huge page の数を制限することを推奨します。 ### `limits.kernel.[limit name]` を使ったリソース制限 + LXD では、指定したインスタンスのリソース制限を設定するのに、 `limits.kernel.*` という名前空間のキーが使えます。 LXD は `limits.kernel.*` のあとに指定されるキーのリソースについての妥当性の確認は一切行ないません。 LXD は、使用中のカーネルで、指定したリソースがすべてが使えるのかどうかを知ることができません。 @@ -1111,29 +1133,34 @@ LXD は単純に `limits.kernel.*` の後に指定されるリソースキーと 明示的に設定されないリソースは、インスタンスを起動したプロセスから継承されます。この継承は LXD でなく、カーネルによって強制されます。 ### スナップショットの定期実行と設定 + LXD は 1 分毎に最大 1 回作成可能なスナップショットの定期実行をサポートします。 3 つの設定項目があります。 + - `snapshots.schedule` には短縮された cron 書式: `<分> <時> <日> <月> <曜日>` を指定します。 -これが空 (デフォルト) の場合はスナップショットは作成されません。 -- `snapshots.schedule.stopped` は停止したインスタンスのスナップショットを自動的に作成するか -どうかを制御します。デフォルトは `false` です。 + これが空 (デフォルト) の場合はスナップショットは作成されません。 +- `snapshots.schedule.stopped` は停止したインスタンスのスナップショットを自動的に作成するかどうかを制御します。 + デフォルトは `false` です。 - `snapshots.pattern` は Pongo2 のテンプレート文字列を指定し、 Pongo2 のコンテキストには -`creation_date` 変数を含みます。スナップショットの名前に禁止された文字が含まれないように -日付をフォーマットする (例: `{{ creation_date|date:"2006-01-02_15-04-05" }}`) べきで -あることに注意してください。名前の衝突を防ぐ別の方法はプレースホルダ `%d` を使うことです。 -(プレースホルダを除いて) 同じ名前のスナップショットが既に存在する場合、 -既存の全てのスナップショットの名前を考慮に入れてプレースホルダの最大の番号を見つけます。 -新しい名前にはこの番号を 1 増やしたものになります。スナップショットが存在しない場合の -開始番号は `0` になります。 `snapshots.pattern` のデフォルトの挙動は `snap%d` の -フォーマット文字列と同じです。 + `creation_date` 変数を含みます。スナップショットの名前に禁止された文字が含まれないように + 日付をフォーマットする (例: `{{ creation_date|date:"2006-01-02_15-04-05" }}`) べきで + あることに注意してください。名前の衝突を防ぐ別の方法はプレースホルダ `%d` を使うことです。 + (プレースホルダを除いて) 同じ名前のスナップショットが既に存在する場合、 + 既存の全てのスナップショットの名前を考慮に入れてプレースホルダの最大の番号を見つけます。 + 新しい名前にはこの番号を 1 増やしたものになります。スナップショットが存在しない場合の + 開始番号は `0` になります。 `snapshots.pattern` のデフォルトの挙動は `snap%d` の + フォーマット文字列と同じです。 Pongo2 の文法を使ってスナップショット名にタイムスタンプを含める例: + ```bash lxc config set INSTANCE snapshots.pattern "{{ creation_date|date:'2006-01-02_15-04-05' }}" ``` + これにより作成日時 `{date/time of creation}` を秒の精度まで含んだスナップショット名になります。 ### QEMU 設定をオーバーライドする + 仮想マシンのインスタンスでは LXD は `-readconfig` コマンドラインオプションを 指定して QEMU に渡されるドキュメント化されていない設定ファイル形式を通じて QEMU を設定します。 各インスタンスは起動前に生成された設定ファイルを持ちます。 diff --git a/doc/metrics.md b/doc/metrics.md index dc2ba89..0f69022 100644 --- a/doc/metrics.md +++ b/doc/metrics.md @@ -3,17 +3,25 @@ discourse: 12281,11735 relatedlinks: https://grafana.com/grafana/dashboards/15726 --- +(instance-metrics)= # インスタンスメトリクス ```{youtube} https://www.youtube.com/watch?v=EthK-8hm_fY ``` -LXD は全ての実行中のインスタンスについてのメトリクスを提供します。これは CPU、メモリー、ネットワーク、ディスク、プロセスの使用量を含み、Prometheus で読み取って Grafana でグラフを表示するのに使うことを想定しています。 + +LXD は全ての実行中のインスタンスについてのメトリクスを収集します。 +これは CPU、メモリー、ネットワーク、ディスク、プロセスの使用量を含みます。 +Prometheus で読み取って Grafana でグラフを表示するのに使うことを想定しています。 + + クラスタ環境では、 LXD はアクセスされているサーバ上で稼働中のインスタンスの値だけを返します。各クラスタメンバーから別々にデータを取得する想定です。 + インスタンスメトリクスは `/1.0/metrics` エンドポイントを呼ぶと更新されます。 メトリクスは複数のスクレイパーに対応するため 8 秒キャッシュします。メトリクスの取得は比較的重い処理ですので、影響が大きすぎるようならデフォルトの間隔より長い間隔でスクレイピングすることを検討してください。 ## メトリクス用証明書の作成 + `1.0/metrics` エンドポイントは他の証明書に加えて `metrics` タイプの証明書を受け付けるという点で特別なエンドポイントです。 このタイプの証明書はメトリクス専用で、インスタンスや他の LXD のオブジェクトの操作には使用できません。 @@ -32,6 +40,7 @@ lxc config trust add metrics.crt --type=metrics ``` ## Prometheus にターゲットを追加 + Prometheus が LXD からメトリクスを取得するためには、 LXD をターゲットに追加する必要があります。 まず、 LXD にネットワーク越しにアクセスできるように `core.https_address` を設定しているかを確認してください。 @@ -60,7 +69,6 @@ cp /var/snap/lxd/common/lxd/server.crt /etc/prometheus/tls chown -R prometheus:prometheus /etc/prometheus/tls ``` - 最後に、 LXD をターゲットに追加する必要があります。 これは `/etc/prometheus/prometheus.yaml` を編集する必要があります。 設定を以下のようにします。 @@ -183,3 +191,45 @@ scrape_configs: key_file: 'tls/metrics.key' server_name: 'saturn' ``` + +## 提供されるメトリクス + +以下のメトリクスが提供されます。 + +* `lxd_cpu_seconds_total{cpu="", mode=""}` +* `lxd_disk_read_bytes_total{device=""}` +* `lxd_disk_reads_completed_total{device=""}` +* `lxd_disk_written_bytes_total{device=""}` +* `lxd_disk_writes_completed_total{device=""}` +* `lxd_filesystem_avail_bytes{device="",fstype=""}` +* `lxd_filesystem_free_bytes{device="",fstype=""}` +* `lxd_filesystem_size_bytes{device="",fstype=""}` +* `lxd_memory_Active_anon_bytes` +* `lxd_memory_Active_bytes` +* `lxd_memory_Active_file_bytes` +* `lxd_memory_Cached_bytes` +* `lxd_memory_Dirty_bytes` +* `lxd_memory_HugepagesFree_bytes` +* `lxd_memory_HugepagesTotal_bytes` +* `lxd_memory_Inactive_anon_bytes` +* `lxd_memory_Inactive_bytes` +* `lxd_memory_Inactive_file_bytes` +* `lxd_memory_Mapped_bytes` +* `lxd_memory_MemAvailable_bytes` +* `lxd_memory_MemFree_bytes` +* `lxd_memory_MemTotal_bytes` +* `lxd_memory_OOM_kills_total` +* `lxd_memory_RSS_bytes` +* `lxd_memory_Shmem_bytes` +* `lxd_memory_Swap_bytes` +* `lxd_memory_Unevictable_bytes` +* `lxd_memory_Writeback_bytes` +* `lxd_network_receive_bytes_total{device=""}` +* `lxd_network_receive_drop_total{device=""}` +* `lxd_network_receive_errs_total{device=""}` +* `lxd_network_receive_packets_total{device=""}` +* `lxd_network_transmit_bytes_total{device=""}` +* `lxd_network_transmit_drop_total{device=""}` +* `lxd_network_transmit_errs_total{device=""}` +* `lxd_network_transmit_packets_total{device=""}` +* `lxd_procs_total` diff --git a/doc/migration.md b/doc/migration.md index 1db9b2e..1c68325 100644 --- a/doc/migration.md +++ b/doc/migration.md @@ -19,10 +19,13 @@ LXD から LXD へインスタンスをマイグレートする : LXC を使っていて全てまたは一部の LXC コンテナを同じマシン上の LXD に移動したい場合、 `lxc-to-lxd` ツールが使えます。 このツールは LXC 設定を解析し、既存の LXC コンテナのデータと設定を新しい LXD コンテナにコピーします。 + 詳細は {ref}`migrate-from-lxc` を参照してくだい。 + ```{toctree} :maxdepth: 1 :hidden: インスタンスの移動 既存のマシンのインポート +LXCからのマイグレート ``` diff --git a/doc/operation.md b/doc/operation.md index cf53bf9..18829a1 100644 --- a/doc/operation.md +++ b/doc/operation.md @@ -6,7 +6,7 @@ バックアップ clustering instance-exec -production-setup +explanation/performance_tuning remotes authentication migration diff --git a/doc/production-setup.md b/doc/production-setup.md deleted file mode 100644 index c4a046e..0000000 --- a/doc/production-setup.md +++ /dev/null @@ -1,112 +0,0 @@ -# プロダクション環境のセットアップ -## イントロダクション -あなたは [LXD live online](https://linuxcontainers.org/lxd/try-it/) か、 -なんらかのサーバで LXD を試してみました。結果に満足して、今度は LXD で -本格的な作業を試してみたいと思います。 - -大多数の Linux ディストリビューションでは大量のコンテナを稼働させるのに最適化されたカーネルの設定はされていません。 -このドキュメントでの指示はコンテナを稼働させる際にひっかかりがちな制限値のほとんどとお勧めの変更後の値をカバーしています。 - - -### よく遭遇するエラー - -`Failed to allocate directory watch: Too many open files` - -` : Too many open files` - -`failed to open stream: Too many open files in...` - -`neighbour: ndisc_cache: neighbor table overflow!` - -## サーバの変更 -### `/etc/security/limits.conf` - -ドメイン | 種別 | 項目 | 値 | デフォルト | 説明 -:----- | :--- | :---- | :-------- | :-------- | :---------- -`*` | soft | `nofile` | 1048576 | 未設定 | オープンするファイルの最大数 -`*` | hard | `nofile` | 1048576 | 未設定 | オープンするファイルの最大数 -`root` | soft | `nofile` | 1048576 | 未設定 | オープンするファイルの最大数 -`root` | hard | `nofile` | 1048576 | 未設定 | オープンするファイルの最大数 -`*` | soft | `memlock` | unlimited | 未設定 | ロックされたメモリ内の最大のアドレス空間 (KB) -`*` | hard | `memlock` | unlimited | 未設定 | ロックされたメモリ内の最大のアドレス空間 (KB) -`root` | soft | `memlock` | unlimited | 未設定 | ロックされたメモリ内の最大のアドレス空間 (KB) (`bpf` システムコール監視にのみ必要) -`root` | hard | `memlock` | unlimited | 未設定 | ロックされたメモリ内の最大のアドレス空間 (KB) (`bpf` システムコール監視にのみ必要) - - -注意: snap ユーザーの場合はこれらの制限は snap/LXD によって自動的に上げられます。 - -### `/etc/sysctl.conf` - -パラメータ | 値 | デフォルト | 説明 -:----- | :--- | :--- | :--- -`fs.aio-max-nr` | `524288` | `65536` | これは並行に実行される非同期 I/O 操作の最大数です。 AIO サブシステムを使うワークロードが大量にある場合（例: MySQL ）、これを増やす必要があるかもしれません。 -`fs.inotify.max_queued_events` | `1048576` | `16384` | これは対応する `inotify` のインスタンスにキューイングされるイベント数の上限を指定します。 [1] -`fs.inotify.max_user_instances` | `1048576` | `128` | これは実ユーザー ID ごとに作成可能な `inotify` のインスタンス数の上限を指定します。 [1] -`fs.inotify.max_user_watches` | `1048576` | `8192` | これは実ユーザー ID ごとに作成可能な watch 数の上限を指定します。 [1] -`kernel.dmesg_restrict` | `1` | `0` | この設定を有効にするとコンテナがカーネルのリングバッファー内のメッセージにアクセスするのを拒否します。この設定はホスト・システム上の非 root ユーザーへのアクセスも拒否することに注意してください。 -`kernel.keys.maxbytes` | `2000000` | `20000` | 非 root ユーザーが使用できる key ring の最大サイズ -`kernel.keys.maxkeys` | `2000` | `200` | 非 root ユーザーが使用できるキーの最大数で、コンテナ数より大きくなければなりません -`net.ipv4.neigh.default.gc_thresh3` | `8192` | `1024` | これは ARP テーブル (IPv4) 内のエントリーの最大数です。1024 個を超えるコンテナを作成するなら増やすべきです。増やさなければ ARP テーブルがフルになったときに `neighbour: ndisc_cache: neighbor table overflow!` というエラーが発生し、コンテナがネットワーク設定を取得できなくなります。 [2] -`net.ipv6.neigh.default.gc_thresh3` | `8192` | `1024` | これは ARP テーブル (IPv6) 内のエントリーの最大数です。1024 個を超えるコンテナを作成するなら増やすべきです。増やさなければ ARP テーブルがフルになったときに `neighbour: ndisc_cache: neighbor table overflow!` というエラーが発生し、コンテナがネットワーク設定を取得できなくなります。 [2] -`vm.max_map_count` | `262144` | `65530` | このファイルはプロセスが持つメモリマップ領域の最大数を含みます。`malloc` の呼び出しの副作用として、 直接的には `mmap` と `mprotect` によって、また、共有ライブラリーをロードすることによって、メモリマップ領域を使います。 - -設定後、サーバの再起動が必要です。 - -[1]: https://man7.org/linux/man-pages/man7/inotify.7.html -[2]: https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt - -### コンテナ名の漏洩防止 -`/sys/kernel/slab` と `/proc/sched_debug` はともにシステム上の全ての cgroup の一覧を表示し、拡張を使えばコンテナ一覧を表示するのを容易にします。 - -一覧が見られるのを防ぐためには、コンテナを開始する前に以下のコマンドを忘れずに実行してください。 - - chmod 400 /proc/sched_debug - chmod 700 /sys/kernel/slab/ - -### ネットワーク帯域の調整 -大量の (コンテナ・コンテナ間、あるいはホスト・コンテナ間の) ローカル・アクティビティを持つ -LXD ホスト上に 1GbE 以上の NIC をお持ちか、 LXD ホストに 1GbE 以上のインターネット接続を -お持ちでしたら、 `txqueuelen` を調整する価値があります。これらの設定は 10GbE NIC ではさらに -よく機能します。 - -#### サーバの変更 - -##### `txqueuelen` -(あなたにとっての最適な値はわかりませんが) あなたの実 NIC の `txqueuelen` を -10000 に変える必要がある場合、 `lxdbr0` インタフェースの `txqueuelen` も 10000 に -変更してください。 - -Debian ベースのディストリビューションでは `/etc/network/interfaces` 内で -`txqueuelen` を恒久的に変更できます。 -例えば `up ip link set eth0 txqueuelen 10000` という設定を加えることで -起動時にインタフェースの `txqueuelen` の値を設定できます。 - -##### `/etc/sysctl.conf` - -`net.core.netdev_max_backlog` の値も増やす必要があります。 -`/etc/sysctl.conf` に `net.core.netdev_max_backlog = 182757` という設定を加えれば -(再起動後に) 恒久的に設定できます。 -(テストの目的で) `netdev_max_backlog` を一時的に設定するには -`echo 182757 > /proc/sys/net/core/netdev_max_backlog` と実行します。 -注意: この値が大きすぎると思うかもしれません。多くの人は -`netdev_max_backlog` = `net.ipv4.tcp_mem` の最小値と設定することを好んでいます。 -例えば私は `net.ipv4.tcp_mem = 182757 243679 365514` という値を使用しています。 - -#### コンテナの変更 - -コンテナ内のイーサネット・インタフェース全ての `txqueuelen` の値を変更する必要も -あります。 -Debian ベースのディストリビューションでは `/etc/network/interfaces` 内で恒久的に -`txqueuelen` を変更できます。 -例えば `up ip link set eth0 txqueuelen 10000` という設定を加えることで -起動時にインタフェースの `txqueuelen` の値を設定できます。 - -#### この変更についての注意 - -10000 という `txqueuelen` の値は 10GbE NIC ではよく使われます。基本的には、 小さな -`txqueuelen` の値は高レイテンシで低速なデバイスと低レイテンシで高速なデバイスで -使われます。個人的にはこれらの設定で (ホスト・コンテナ間、コンテナ・コンテナ間の) -ローカル通信とインターネット接続が 3〜5% 改善しています。 -`txqueuelen` の値の調整の良いところは、使用するコンテナ数が増えれば増えるほど、この -調整の恩恵を受けられることです。そして、この値はいつでも一時的に変更することができ、 -あなたの環境で LXD ホストの再起動無しに変更の結果を確認することができます。 diff --git a/doc/profiles.md b/doc/profiles.md index d72b252..013dbf0 100644 --- a/doc/profiles.md +++ b/doc/profiles.md @@ -1,4 +1,7 @@ # プロファイル + +## イントロダクション + プロファイルはインスタンスが保持できる（キー・バリューやデバイスなどの）あらゆる 設定を保持することができ、プロファイルをいくつでもインスタンスに適用することが できます。 @@ -9,6 +12,7 @@ どのような場合でも、インスタンス固有の設定はプロファイル由来のものを上書きします。 ## デフォルトのプロファイル + まだ存在していない場合は、LXDは `default` プロファイルを作成します。 `default` プロファイルはリネームや削除はできません。 @@ -16,6 +20,7 @@ 新規のインスタンスに設定されます。 ## 設定 + プロファイルはコンテナや仮想マシンに固有なものではないため、どちらのインスタンスタイプでも有効な設定やデバイスを含めることができます。 これはこれらの設定やデバイスをインスタンスに直接適用するときの挙動とは異なります。 diff --git a/doc/projects.md b/doc/projects.md index c7cd1ca..d88dd6c 100644 --- a/doc/projects.md +++ b/doc/projects.md @@ -4,6 +4,7 @@ relatedlinks: https://www.youtube.com/watch?v=6O0q3rSWr8A (projects)= # プロジェクト設定 + LXD は LXD サーバを分割する方法としてプロジェクトをサポートしています。 それぞれのプロジェクトは独自のインスタンスのセットを保持し、さらに独自のイメージとプロファイルも持ちます。 @@ -17,9 +18,9 @@ LXD は LXD サーバを分割する方法としてプロジェクトをサポ key/value 設定は現在サポートされている以下のネームスペースによって 名前空間が分けられています。 - - `features` プロジェクトのフィーチャーセットのどの部分が使用中か - - `limits` プロジェクトに属するコンテナと VM に適用されるリソース制限 - - `user` ユーザーメタデータに対する自由形式の key/value +- `features` プロジェクトのフィーチャーセットのどの部分が使用中か +- `limits` プロジェクトに属するコンテナと VM に適用されるリソース制限 +- `user` ユーザーメタデータに対する自由形式の key/value キー | 型 | 条件 | デフォルト値 | 説明 :-- | :-- | :-- | :-- | :-- @@ -54,7 +55,7 @@ key/value 設定は現在サポートされている以下のネームスペー `restricted.devices.disk.paths` | string | - | - | `restricted.devices.disk` が `allow` に設定された場合これは `disk` デバイスに設定される `source` 設定を制限するパスのプリフィクスのカンマ区切りを設定する。空の場合は全てのパスが許可される。 `restricted.devices.gpu` | string | - | `block` | `block` と設定すると `gpu` タイプのデバイスの使用を防ぐ `restricted.devices.infiniband` | string | - | `block` | `block` と設定すると `infiniband` タイプのデバイスの使用を防ぐ -`restricted.devices.nic` | string | - | `managed` | `block` と設定すると全てのネットワークデバイスの使用を防ぐ。`managed` と設定すると `network=` が設定されているときだけネットワークデバイスの使用を許可する。`allow` と設定すると制限なし。 +`restricted.devices.nic` | string | - | `managed` | `block` と設定すると全てのネットワークデバイスの使用を防ぐ。`managed` と設定すると `network=` が設定されているときだけネットワークデバイスの使用を許可する。`allow` と設定すると制限なし。これはネットワークへのアクセスも制御する。 `restricted.devices.pci` | string | - | `block` | `pci` タイプのデバイスの使用を防ぐ `restricted.devices.proxy` | string | - | `block` | `proxy` タイプのデバイスの使用を防ぐ `restricted.devices.unix-block` | string | - | `block` | `block` と設定すると `unix-block` タイプのデバイスの使用を防ぐ @@ -63,6 +64,7 @@ key/value 設定は現在サポートされている以下のネームスペー `restricted.devices.usb` | string | - | `block` | `block` と設定すると `usb` タイプのデバイスの使用を防ぐ `restricted.idmap.uid` | string | - | - | インスタンスの `raw.idmap` 設定で使用可能なホストの UID の範囲を指定 `restricted.idmap.gid` | string | - | - | インスタンスの `raw.idmap` 設定で使用可能なホストの GID の範囲を指定 +`restricted.networks.access` | string | - | - | このプロジェクト内で使用が許可されるネットワーク名のカンマ区切りリスト。未設定の場合は全てのネットワークがアクセス可能 (`restricted.devices.nic` 設定に依存)。 `restricted.networks.subnets` | string | - | `block` | このプロジェクトで使用するために割り当てられるアップリンクネットワークのネットワークサブネット（`:` 形式）のカンマ区切りリスト `restricted.networks.uplinks` | string | - | `block` | このプロジェクト内のネットワークでアップリンクとして使用可能なネットワークのカンマ区切りリスト `restricted.networks.zones` | string | - | `block` | このプロジェクト内の使用可能なネットワークゾーン（またはそれらの下のサブゾーン） のカンマ区切りリスト diff --git a/doc/reference/network_bridge.md b/doc/reference/network_bridge.md index f8848fb..278ac1f 100644 --- a/doc/reference/network_bridge.md +++ b/doc/reference/network_bridge.md @@ -18,6 +18,15 @@ LXD で作成されたブリッジは "managed" です。 LXD ブリッジネットワークでファイアウォールを設定するための手順については {ref}`network-bridge-firewall` を参照してください。 + + +```{note} +静的な DHCP 割当は MAC アドレスを DHCP 識別子として使用するクライアントに依存します。 +この方法はインスタンスをコピーする際に衝突するリースを回避し、静的に割り当てられたリースが正しく動くようにします。 +``` + + + ## IPv6 プリフィクスサイズ ブリッジネットワークで IPv6 を使用する場合、 64 のプリフィクスサイズを使用するべきです。 @@ -31,17 +40,17 @@ LXD ブリッジネットワークでファイアウォールを設定するた `bridge` ネットワークタイプでは現在以下の設定キーネームスペースがサポートされています。 - - `bgp` (BGP ピア設定) - - `bridge` (L2 インタフェースの設定) - - `dns` (DNS サーバと名前解決の設定) - - `fan` (Ubuntu FAN overlay に特有な設定) - - `ipv4` (L3 IPv4 設定) - - `ipv6` (L3 IPv6 設定) - - `maas` (MAAS ネットワーク識別) - - `security` (ネットワーク ACL 設定) - - `raw` (raw の設定のファイルの内容) - - `tunnel` (ホスト間のトンネリングの設定) - - `user` (key/value の自由形式のユーザメタデータ) +- `bgp` (BGP ピア設定) +- `bridge` (L2 インタフェースの設定) +- `dns` (DNS サーバと名前解決の設定) +- `fan` (Ubuntu FAN overlay に特有な設定) +- `ipv4` (L3 IPv4 設定) +- `ipv6` (L3 IPv6 設定) +- `maas` (MAAS ネットワーク識別) +- `security` (ネットワーク ACL 設定) +- `raw` (raw の設定のファイルの内容) +- `tunnel` (ホスト間のトンネリングの設定) +- `user` (key/value の自由形式のユーザメタデータ) ```{note} {{note_ip_addresses_CIDR}} @@ -124,7 +133,6 @@ LXD ブリッジネットワークでファイアウォールを設定するた - {ref}`network-bgp` - [`systemd-resolved` と統合するには](network-bridge-resolved) - ```{toctree} :maxdepth: 1 :hidden: diff --git a/doc/reference/network_macvlan.md b/doc/reference/network_macvlan.md index e102072..5894b07 100644 --- a/doc/reference/network_macvlan.md +++ b/doc/reference/network_macvlan.md @@ -15,8 +15,8 @@ macvlan は仮想的な {abbr}`LAN (Local Area Network)` で同じネットワ `macvlan` ネットワークタイプでは現在以下の設定キーネームスペースがサポートされています。 - - `maas` (MAAS ネットワーク識別) - - `user` (key/value の自由形式のユーザメタデータ) +- `maas` (MAAS ネットワーク識別) +- `user` (key/value の自由形式のユーザメタデータ) ```{note} {{note_ip_addresses_CIDR}} diff --git a/doc/reference/network_ovn.md b/doc/reference/network_ovn.md index 85d0607..b79b71e 100644 --- a/doc/reference/network_ovn.md +++ b/doc/reference/network_ovn.md @@ -19,17 +19,23 @@ LXD の OVN ネットワークはより広いネットワークへの外向き OVN ネットワークをセットアップする基本的な手順については {ref}`network-ovn-setup` をご参照ください。 +% Include content from [network_bridge.md](network_bridge.md) +```{include} network_bridge.md + :start-after: + :end-before: +``` + (network-ovn-options)= ## 設定オプション `ovn` ネットワークタイプでは現在以下の設定キーネームスペースがサポートされています。 - - `bridge` (L2 インタフェースの設定) - - `dns` (DNS サーバと名前解決の設定) - - `ipv4` (L3 IPv4 設定) - - `ipv6` (L3 IPv6 設定) - - `security` (ネットワーク ACL 設定) - - `user` (key/value の自由形式のユーザメタデータ) +- `bridge` (L2 インタフェースの設定) +- `dns` (DNS サーバと名前解決の設定) +- `ipv4` (L3 IPv4 設定) +- `ipv6` (L3 IPv6 設定) +- `security` (ネットワーク ACL 設定) +- `user` (key/value の自由形式のユーザメタデータ) ```{note} {{note_ip_addresses_CIDR}} diff --git a/doc/reference/network_physical.md b/doc/reference/network_physical.md index 8bca44e..dc9ce83 100644 --- a/doc/reference/network_physical.md +++ b/doc/reference/network_physical.md @@ -12,13 +12,13 @@ 物理ネットワークでは現在以下の設定キーネームスペースがサポートされています。 - - `bgp` (BGP ピア設定) - - `dns` (DNS サーバと名前解決の設定) - - `ipv4` (L3 IPv4 設定) - - `ipv6` (L3 IPv6 設定) - - `maas` (MAAS ネットワーク識別) - - `ovn` (OVN 設定) - - `user` (key/value の自由形式のユーザメタデータ) +- `bgp` (BGP ピア設定) +- `dns` (DNS サーバと名前解決の設定) +- `ipv4` (L3 IPv4 設定) +- `ipv6` (L3 IPv6 設定) +- `maas` (MAAS ネットワーク識別) +- `ovn` (OVN 設定) +- `user` (key/value の自由形式のユーザメタデータ) ```{note} {{note_ip_addresses_CIDR}} diff --git a/doc/reference/network_sriov.md b/doc/reference/network_sriov.md index 9fa430b..fc1042e 100644 --- a/doc/reference/network_sriov.md +++ b/doc/reference/network_sriov.md @@ -13,8 +13,8 @@ `sriov` ネットワークでは現在以下の設定キーネームスペースがサポートされています。 - - `maas` (MAAS ネットワーク識別) - - `user` (key/value の自由形式のユーザメタデータ) +- `maas` (MAAS ネットワーク識別) +- `user` (key/value の自由形式のユーザメタデータ) ```{note} {{note_ip_addresses_CIDR}} diff --git a/doc/reference/server_settings.md b/doc/reference/server_settings.md new file mode 100644 index 0000000..cda76b3 --- /dev/null +++ b/doc/reference/server_settings.md @@ -0,0 +1,42 @@ +(server-settings)= +# LXD プロダクション環境のサーバ設定 + +あなたの LXD サーバで多数のインタンスを稼働できるようにするには、サーバの制限値にひっかからないよう以下の設定を調整してください。 + +`値` のカラムに各パラメータの推奨値を記載しています。 + +## `/etc/security/limits.conf` + +```{note} +snap ユーザーの場合はこれらの制限は自動的に上げられます。 +``` + +ドメイン | 種別 | 項目 | 値 | デフォルト | 説明 +:----- | :--- | :---- | :-------- | :-------- | :---------- +`*` | soft | `nofile` | `1048576` | 未設定 | オープンするファイルの最大数 +`*` | hard | `nofile` | `1048576` | 未設定 | オープンするファイルの最大数 +`root` | soft | `nofile` | `1048576` | 未設定 | オープンするファイルの最大数 +`root` | hard | `nofile` | `1048576` | 未設定 | オープンするファイルの最大数 +`*` | soft | `memlock` | `unlimited` | 未設定 | ロックされたメモリ内の最大のアドレス空間 (KB) +`*` | hard | `memlock` | `unlimited` | 未設定 | ロックされたメモリ内の最大のアドレス空間 (KB) +`root` | soft | `memlock` | `unlimited` | 未設定 | ロックされたメモリ内の最大のアドレス空間 (KB) (`bpf` システムコール監視にのみ必要) +`root` | hard | `memlock` | `unlimited` | 未設定 | ロックされたメモリ内の最大のアドレス空間 (KB) (`bpf` システムコール監視にのみ必要) + +## `/etc/sysctl.conf` + +```{note} +これらのパラメータを変更した後、サーバを再起動してください。 +``` + +パラメータ | 値 | デフォルト | 説明 +:----- | :--- | :--- | :--- +`fs.aio-max-nr` | `524288` | `65536` | これは並行に実行される非同期 I/O 操作の最大数です。 AIO サブシステムを使うワークロードが大量にある場合（例: MySQL ）、これを増やす必要があるかもしれません +`fs.inotify.max_queued_events` | `1048576` | `16384` | これは対応する `inotify` のインスタンスにキューイングされるイベント数の上限を指定します ([`ionotify`](https://man7.org/linux/man-pages/man7/inotify.7.html) 参照) +`fs.inotify.max_user_instances` | `1048576` | `128` | これは実ユーザー ID ごとに作成可能な `inotify` のインスタンス数の上限を指定します ([`ionotify`](https://man7.org/linux/man-pages/man7/inotify.7.html) 参照) +`fs.inotify.max_user_watches` | `1048576` | `8192` | これは実ユーザー ID ごとに作成可能な watch 数の上限を指定します ([`ionotify`](https://man7.org/linux/man-pages/man7/inotify.7.html) 参照) +`kernel.dmesg_restrict` | `1` | `0` | この設定を有効にするとコンテナがカーネルのリングバッファー内のメッセージにアクセスするのを拒否します。この設定はホスト・システム上の非 root ユーザーへのアクセスも拒否することに注意してください +`kernel.keys.maxbytes` | `2000000` | `20000` | 非 root ユーザーが使用できる key ring の最大サイズ +`kernel.keys.maxkeys` | `2000` | `200` | 非 root ユーザーが使用できるキーの最大数で、コンテナ数より大きくなければなりません +`net.ipv4.neigh.default.gc_thresh3` | `8192` | `1024` | これは ARP テーブル (IPv4) 内のエントリーの最大数です。1024 個を超えるコンテナを作成するなら増やすべきです。増やさなければ ARP テーブルがフルになったときに `neighbour: ndisc_cache: neighbor table overflow!` というエラーが発生し、コンテナがネットワーク設定を取得できなくなります ([`ip-sysctl`](https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) 参照) +`net.ipv6.neigh.default.gc_thresh3` | `8192` | `1024` | これは ARP テーブル (IPv6) 内のエントリーの最大数です。1024 個を超えるコンテナを作成するなら増やすべきです。増やさなければ ARP テーブルがフルになったときに `neighbour: ndisc_cache: neighbor table overflow!` というエラーが発生し、コンテナがネットワーク設定を取得できなくなります ([`ip-sysctl`](https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) 参照) +`vm.max_map_count` | `262144` | `65530` | このファイルはプロセスが持つメモリマップ領域の最大数を含みます。`malloc` の呼び出しの副作用として、 直接的には `mmap` と `mprotect` によって、また、共有ライブラリーをロードすることによって、メモリマップ領域を使います diff --git a/doc/reference/storage_btrfs.md b/doc/reference/storage_btrfs.md index d074fab..ae8e710 100644 --- a/doc/reference/storage_btrfs.md +++ b/doc/reference/storage_btrfs.md @@ -1,6 +1,9 @@ (storage-btrfs)= # Btrfs - `btrfs` +```{youtube} https://www.youtube.com/watch?v=2r5FYuusxNc +``` + {abbr}`Btrfs (B-tree file system)` は {abbr}`COW (copy-on-write)` 原則に基づいたローカルファイルシステムです。 COW はデータが修正された後に既存のデータを上書きするのではなく別のブロックに保管され、データ破壊のリスクが低くなることを意味します。 他のファイルシステムと異なり、Btrfs はエクステントベースです。これはデータを連続したメモリ領域に保管することを意味します。 @@ -11,8 +14,8 @@ Btrfs を使うにはマシンに `btrfs-progs` がインストールされて ## 用語 -Btrfs ファイルシステムは *サブボリューム* を持つことができます。これはファイルシステムのメインツリーの名前をつけられたバイナリサブツリーでそれ自身の独立したファイルとディレクトリ階層を持ちます。 -*Btrfs スナップショット*　は特殊なタイプのサブボリュームで別のサブボリュームの特定の状態をキャプチャーします。 +Btrfs ファイルシステムは*サブボリューム*を持つことができます。これはファイルシステムのメインツリーの名前をつけられたバイナリサブツリーでそれ自身の独立したファイルとディレクトリ階層を持ちます。 +*Btrfs スナップショット*は特殊なタイプのサブボリュームで別のサブボリュームの特定の状態をキャプチャーします。 スナップショットは読み書き可または読み取り専用にできます。 ## LXD の `btrfs` ドライバ @@ -20,6 +23,10 @@ Btrfs ファイルシステムは *サブボリューム* を持つことがで LXD の `btrfs` ドライバはインスタンス、イメージ、スナップショットごとにサブボリュームを使用します。 新しいオブジェクトを作成する際 (例えば、新しいインスタンスを起動する)、 Btrfs スナップショットを作成します。 +Btrfs はブロックデバイスの保管をネイティブにはサポートしていません。 +このため、仮想マシンに Btrfs を使用する場合、 LXD は仮想マシンを格納するディスク上に巨大なファイルを作成します。 +このアプローチはあまり効率的ではなく、スナップショット作成時に問題を引き起こすかもしれません。 + Btrfs はネストした LXD 環境内のコンテナ内部でストレージバックエンドとして使用できます。 この場合、親のコンテナ自体は Btrfs を使う必要があります。 しかし、ネストした LXD のセットアップは親から Btrfs のクォータは引き継がないことに注意してください (以下の {ref}`storage-btrfs-quotas` 参照)。 @@ -54,6 +61,7 @@ Btrfs qgroups は階層的ですが、新しいサブボリュームは親のサ (storage-btrfs-pool-config)= ## ストレージプール設定 + キー | 型 | デフォルト値 | 説明 :-- | :--- | :-------- | :---------- `btrfs.mount_options` | string | `user_subvol_rm_allowed` | ブロックデバイスのマウントオプション @@ -62,11 +70,20 @@ Btrfs qgroups は階層的ですが、新しいサブボリュームは親のサ {{volume_configuration}} ### ストレージボリューム設定 + キー | 型 | 条件 | デフォルト値 | 説明 :-- | :--- | :-------- | :------ | :---------- -`security.shifted` | bool | custom volume | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | `volume.security.unmapped` と同じか `false` | ボリュームへの id マッピングを無効にする -`size` | string | appropriate driver | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ -`snapshots.expiry` | string | custom volume | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} -`snapshots.schedule` | string | custom volume | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} +`security.shifted` | bool | カスタムボリューム | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} +`security.unmapped` | bool | カスタムボリューム | `volume.security.unmapped` と同じか `false` | ボリュームへの id マッピングを無効にする +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ +`snapshots.expiry` | string | カスタムボリューム | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} +`snapshots.pattern` | string | カスタムボリューム | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} +`snapshots.schedule` | string | カスタムボリューム | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} + +### ストレージバケット設定 + +ローカルのストレージプールドライバでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには `core.storage_buckets_address` サーバ設定 ({ref}`server` 参照) を調整する必要があります。 + +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージバケットのサイズ/クォータ diff --git a/doc/reference/storage_ceph.md b/doc/reference/storage_ceph.md index afcd2b7..0806797 100644 --- a/doc/reference/storage_ceph.md +++ b/doc/reference/storage_ceph.md @@ -34,6 +34,7 @@ Ceph RBD ドライバを使用するには `ceph` と指定する必要があり 別の方法として、コンテントタイプ `filesystem` でストレージボリュームを作成するのに {ref}`CephFS ` を使用することもできます。 ``` + 他のストレージドライバとは異なり、このドライバはストレージシステムをセットアップはせず、既に Ceph クラスタをインストール済みであると想定します。 @@ -79,6 +80,7 @@ Ceph RBD 内で copy-on-write が動作する方法のため、親の RBD イメ (storage-ceph-pool-config)= ### ストレージプール設定 + キー | 型 | デフォルト値 | 説明 :-- | :--- | :------ | :---------- `ceph.cluster_name` | string | `ceph` | 新しいストレージプールを作成する Ceph クラスタの名前 @@ -96,13 +98,14 @@ Ceph RBD 内で copy-on-write が動作する方法のため、親の RBD イメ (storage-ceph-vol-config)= ### ストレージボリューム設定 -キー | 型 | 条件 | デフォルト値 | 説明 -:-- | :--- | :-------- | :------ | :---------- -`block.filesystem` | string | block based driver | `volume.block.filesystem` と同じ | {{block_filesystem}} -`block.mount_options` | string | block based driver | `volume.block.mount_options` と同じ | ブロックデバイスのマウントオプション -`security.shifted` | bool | custom volume | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | `volume.security.unmapped` と同じか `false` | ボリュームの ID マッピングを無効にする -`size` | string | appropriate driver | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ -`snapshots.expiry` | string | custom volume | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} -`snapshots.schedule` | string | custom volume | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} + +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`block.filesystem` | string | ブロックベースドライバ | `volume.block.filesystem` と同じ | {{block_filesystem}} +`block.mount_options` | string | ブロックベースドライバ | `volume.block.mount_options` と同じ | ブロックデバイスのマウントオプション +`security.shifted` | bool | カスタムボリューム | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} +`security.unmapped` | bool | カスタムボリューム | `volume.security.unmapped` と同じか `false` | ボリュームの ID マッピングを無効にする +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ +`snapshots.expiry` | string | カスタムボリューム | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} +`snapshots.pattern` | string | カスタムボリューム | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} +`snapshots.schedule` | string | カスタムボリューム | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} diff --git a/doc/reference/storage_cephfs.md b/doc/reference/storage_cephfs.md index a526d42..dcca5b0 100644 --- a/doc/reference/storage_cephfs.md +++ b/doc/reference/storage_cephfs.md @@ -60,6 +60,7 @@ LXD の `cephfs` ドライバはサーバ側でスナップショットが有効 (storage-cephfs-pool-config)= ## ストレージプール設定 + キー | 型 | デフォルト値 | 説明 :-- | :--- | :------ | :---------- `cephfs.cluster_name` | string | `ceph` | CephFS ファイルシステムを含む Ceph クラスタの名前 @@ -72,11 +73,12 @@ LXD の `cephfs` ドライバはサーバ側でスナップショットが有効 {{volume_configuration}} ## ストレージボリューム設定 + キー | 型 | 条件 | デフォルト値 | 説明 :-- | :--- | :-------- | :------ | :---------- -`security.shifted` | bool | custom volume | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | `volume.security.unmapped` と同じか `false` | ボリュームの ID マッピングを無効にする -`size` | string | appropriate driver | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ -`snapshots.expiry` | string | custom volume | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} -`snapshots.schedule` | string | custom volume | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} +`security.shifted` | bool | カスタムボリューム | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} +`security.unmapped` | bool | カスタムボリューム | `volume.security.unmapped` と同じか `false` | ボリュームの ID マッピングを無効にする +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ +`snapshots.expiry` | string | カスタムボリューム | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} +`snapshots.pattern` | string | カスタムボリューム | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} +`snapshots.schedule` | string | カスタムボリューム | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} diff --git a/doc/reference/storage_cephobject.md b/doc/reference/storage_cephobject.md index 38fc6f3..b6ee4de 100644 --- a/doc/reference/storage_cephobject.md +++ b/doc/reference/storage_cephobject.md @@ -40,9 +40,9 @@ Amazon S3 RESTful API の大きなサブセットと互換性を持つオブジ ``` 事前に `radosgw` 環境をセットアップし、 HTTP/HTTPS エンドポイント URL が LXD サーバからアクセス可能なことを確認してください。 -Ceph クラスタをどのようにセットアップするかの情報については [Manual Deployment](https://docs.ceph.com/en/latest/install/manual-deployment/) を、そして `radosgw` 環境をどのようにセットアップするかについては [`radosgw`](https://docs.ceph.com/en/latest/radosgw/) を参照してください。 +Ceph クラスタをどのようにセットアップするかの情報については [Manual Deployment](https://docs.ceph.com/en/latest/install/manual-deployment/) を、そして `radosgw` 環境をどのようにセットアップするかについては [Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/) を参照してください。 -`radosgw` URL はプールの作成時に [`cephobject.radosgsw.endpoint`](storage-cephobject-pool-config) オプションを使って指定できます。 +`radosgw` URL はプールの作成時に [`cephobject.radosgw.endpoint`](storage-cephobject-pool-config) オプションを使って指定できます。 また LXD はバケットの管理に `radosgw-admin` コマンドを使用しています。ですのでこのコマンドが LXD サーバ上で利用可能で操作可能である必要があります。 % Include content from [storage_ceph.md](storage_ceph.md) @@ -63,16 +63,18 @@ Ceph クラスタをどのようにセットアップするかの情報につい (storage-cephobject-pool-config)= ### ストレージプール設定 -キー | 型 | デフォルト値 | 説明 -:-- | :--- | :------ | :---------- -`cephobject.bucket.name_prefix` | string | - | Ceph 内のバケット名に追加する接頭辞 -`cephobject.cluster_name` | string | `ceph` | 使用する Ceph クラスタ -`cephobject.radosgsw.endpoint` | string | - | `radosgw` ゲートウェイプロセスのURL -`cephobject.radosgsw.endpoint_cert_file` | string | - | エンドポイント通信に使用する TLS クライアント証明書を含むファイルへのパス -`cephobject.user.name` | string | `admin` | 使用する Ceph ユーザ -`volatile.pool.pristine` | string | `true` | 作成時に `radosgw` `lxd-admin` ユーザが存在したかどうか + +キー | 型 | デフォルト値 | 説明 +:-- | :--- | :------ | :---------- +`cephobject.bucket.name_prefix` | string | - | Ceph 内のバケット名に追加する接頭辞 +`cephobject.cluster_name` | string | `ceph` | 使用する Ceph クラスタ +`cephobject.radosgw.endpoint` | string | - | `radosgw` ゲートウェイプロセスのURL +`cephobject.radosgw.endpoint_cert_file` | string | - | エンドポイント通信に使用する TLS クライアント証明書を含むファイルへのパス +`cephobject.user.name` | string | `admin` | 使用する Ceph ユーザ +`volatile.pool.pristine` | string | `true` | 作成時に `radosgw` `lxd-admin` ユーザが存在したかどうか ### ストレージバケット設定 + キー | 型 | デフォルト値 | 説明 :-- | :--- | :------ | :---------- `size` | string | - | ストレージバケットのクォータ diff --git a/doc/reference/storage_dir.md b/doc/reference/storage_dir.md index 237d9cd..d99004f 100644 --- a/doc/reference/storage_dir.md +++ b/doc/reference/storage_dir.md @@ -1,6 +1,9 @@ (storage-dir)= # ディレクトリ - `dir` +```{youtube} https://www.youtube.com/watch?v=imWkPM9GjCY +``` + ディレクトリストレージドライバは基本的なバックエンドで通常のファイルとディレクトリ構造にデータを保管します。 このドライバは素早くセットアップできディスク上のファイルを直接見ることができるので、テストには便利かもしれません。 しかし、 LXD の操作はこのドライバ用には {ref}`最適化されていません `。 @@ -22,6 +25,7 @@ LXD の `dir` ドライバは完全に機能し、他のドライバと同じ機 `dir` ドライバを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。 ## ストレージプール設定 + キー | 型 | デフォルト値 | 説明 :-- | :--- | :------ | :---------- `rsync.bwlimit` | string | `0` (no limit) | ストレージエンティティの転送に rsync を使う必要があるときにソケット I/O に指定する上限を設定 @@ -31,11 +35,19 @@ LXD の `dir` ドライバは完全に機能し、他のドライバと同じ機 {{volume_configuration}} ## ストレージボリューム設定 + キー | 型 | 条件 | デフォルト値 | 説明 :-- | :--- | :-------- | :------ | :---------- -`security.shifted` | bool | custom volume | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | `volume.security.unmapped` と同じか `false` | ボリュームの ID マッピングを無効にする -`size` | string | appropriate driver | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ -`snapshots.expiry` | string | custom volume | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} -`snapshots.schedule` | string | custom volume | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} +`security.shifted` | bool | カスタムボリューム | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} +`security.unmapped` | bool | カスタムボリューム | `volume.security.unmapped` と同じか `false` | ボリュームの ID マッピングを無効にする +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ +`snapshots.expiry` | string | カスタムボリューム | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} +`snapshots.pattern` | string | カスタムボリューム | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} +`snapshots.schedule` | string | カスタムボリューム | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} + +### ストレージバケット設定 + +ローカルのストレージプールドライバでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには `core.storage_buckets_address` サーバ設定 ({ref}`server` 参照) を調整する必要があります。 + +ストレージバケットは `dir` プール用の設定はありません。 +他のストレージプールドライバとは異なり、 `dir` ドライバは `size` 設定によるバケットクォータのサポートはありません。 diff --git a/doc/reference/storage_drivers.md b/doc/reference/storage_drivers.md index df9eb4b..84b419b 100644 --- a/doc/reference/storage_drivers.md +++ b/doc/reference/storage_drivers.md @@ -23,23 +23,24 @@ storage_cephobject (storage-drivers-features)= ## 機能比較 + 可能であれば、各システムの高度な機能を使って、LXD は操作を最適化しようとします。 -機能 | ディレクトリ | Btrfs | LVM | ZFS | Ceph RBD | CephFS | Ceph Object -:--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- -{ref}`storage-optimized-image-storage` | no | yes | yes | yes | yes | n/a | n/a -最適化されたインスタンスの作成 | no | yes | yes | yes | yes | n/a | n/a -最適化されたスナップショットの作成 | no | yes | yes | yes | yes | yes | n/a -最適化されたイメージの転送 | no | yes | no | yes | yes | n/a | n/a -{ref}`storage-optimized-instance-transfer` | no | yes | no | yes | yes | n/a | n/a -コピーオンライト | no | yes | yes | yes | yes | yes | n/a -ブロックデバイスベース | no | no | yes | no | yes | no | n/a -インスタントクローン | no | yes | yes | yes | yes | yes | n/a -コンテナ内でストレージドライバの使用 | yes | yes | no | no | no | n/a | n/a -古い（最新ではない）スナップショットからのリストア | yes | yes | yes | no | yes | yes | n/a -ストレージクオータ | yes{ref}`* `] | yes | yes | yes | yes | yes | yes -`lxd init` で利用可能 | yes | yes | yes | yes | yes | no | no -オブジェクトストレージ | no | no | no | no | no | no | yes +機能 | ディレクトリ | Btrfs | LVM | ZFS | Ceph RBD | CephFS | Ceph Object +:--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- +{ref}`storage-optimized-image-storage` | no | yes | yes | yes | yes | n/a | n/a +最適化されたインスタンスの作成 | no | yes | yes | yes | yes | n/a | n/a +最適化されたスナップショットの作成 | no | yes | yes | yes | yes | yes | n/a +最適化されたイメージの転送 | no | yes | no | yes | yes | n/a | n/a +{ref}`storage-optimized-instance-transfer` | no | yes | no | yes | yes | n/a | n/a +コピーオンライト | no | yes | yes | yes | yes | yes | n/a +ブロックデバイスベース | no | no | yes | no | yes | no | n/a +インスタントクローン | no | yes | yes | yes | yes | yes | n/a +コンテナ内でストレージドライバの使用 | yes | yes | no | no | no | n/a | n/a +古い（最新ではない）スナップショットからのリストア | yes | yes | yes | no | yes | yes | n/a +ストレージクオータ | yes{ref}`* ` | yes | yes | yes | yes | yes | yes +`lxd init` で利用可能 | yes | yes | yes | yes | yes | no | no +オブジェクトストレージ | yes | yes | yes | yes | no | no | yes (storage-optimized-image-storage)= ### 最適化されたイメージストレージ diff --git a/doc/reference/storage_lvm.md b/doc/reference/storage_lvm.md index fa218d8..7c04b7b 100644 --- a/doc/reference/storage_lvm.md +++ b/doc/reference/storage_lvm.md @@ -1,6 +1,9 @@ (storage-lvm)= # LVM - `lvm` +```{youtube} https://www.youtube.com/watch?v=AqLl2eMZE6U +``` + {abbr}`LVM (Logical Volume Manager)` はファイルシステムというよりストレージマネージメントフレームワークです。 これは物理ストレージデバイスを管理するのに使用され、複数のストレージボリュームを作成し、配下の物理ストレージデバイスを使用し仮想化できるようにします。 @@ -21,8 +24,8 @@ LVM は複数の物理ストレージデバイスを組み合わせて *ボリ LXD の `lvm` ドライバはイメージに論理ボリュームを、インスタンスとスナップショットにボリュームスナップショットを使用します。 LXD はボリュームグループを完全制御できると想定しています。 - -このため、 LXD が所有しないファイルシステムエンティティは LXD が消してしまうかもしれないので、LVM ボリュームグループ内に決して置くべきではありません。 +このため、 LXD が所有しないファイルシステムエンティティは LXD が消してしまうかもしれないので、LVM ボリュームグループ内に置くべきではありません。 +しかし、既存のボリュームグループを再利用する必要がある場合 (例えば、あなたの環境ではボリュームグループが 1 つしかない場合)、[`lvm.vg.force_reuse`](storage-lvm-pool-config) を設定することでこれは可能です。 デフォルトでは LVM ストレージプールは LVM thin pool を使用しその中に全ての LXD ストレージエンティティ (イメージ、インスタンス、カスタムボリューム) の論理ボリュームを作成します。 この挙動はプール作成時に [`lvm.use_thinpool`](storage-lvm-pool-config) を `false` に設定することで変更できます。 @@ -40,6 +43,7 @@ LXD はボリュームグループを完全制御できると想定していま (storage-lvm-pool-config)= ## ストレージプール設定 + キー | 型 | デフォルト値 | 説明 :-- | :--- | :------ | :---------- `lvm.thinpool_name` | string | `LXDThinPool` | ボリュームが作成される thin pool @@ -56,15 +60,24 @@ LXD はボリュームグループを完全制御できると想定していま (storage-lvm-vol-config)= ## ストレージボリューム設定 -キー | 型 | 条件 | デフォルト値 | 説明 -:-- | :--- | :-------- | :------ | :---------- -`block.filesystem` | string | block based driver | `volume.block.filesystem` と同じ | {{block_filesystem}} -`block.mount_options` | string | block based driver | `volume.block.mount_options` と同じ | ブロックデバイスのマウントオプション -`lvm.stripes` | string | LVM driver | `volume.lvm.stripes` と同じ | 新しいボリューム (あるいは thin pool ボリューム) に使用するストライプ数 -`lvm.stripes.size` | string | LVM driver | `volume.lvm.stripes.size` と同じ | 使用するストライプのサイズ (最低 4096 バイトで 512 バイトの倍数を指定) -`security.shifted` | bool | custom volume | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | `volume.security.unmapped` と同じか `false` | ボリュームへの ID マッピングを無効にする -`size` | string | appropriate driver | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ -`snapshots.expiry` | string | custom volume | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} -`snapshots.schedule` | string | custom volume | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} + +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`block.filesystem` | string | ブロックベースドライバ | `volume.block.filesystem` と同じ | {{block_filesystem}} +`block.mount_options` | string | ブロックベースドライバ | `volume.block.mount_options` と同じ | ブロックデバイスのマウントオプション +`lvm.stripes` | string | LVMドライバ | `volume.lvm.stripes` と同じ | 新しいボリューム (あるいは thin pool ボリューム) に使用するストライプ数 +`lvm.stripes.size` | string | LVMドライバ | `volume.lvm.stripes.size` と同じ | 使用するストライプのサイズ (最低 4096 バイトで 512 バイトの倍数を指定) +`security.shifted` | bool | カスタムボリューム | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} +`security.unmapped` | bool | カスタムボリューム | `volume.security.unmapped` と同じか `false` | ボリュームへの ID マッピングを無効にする +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ +`snapshots.expiry` | string | カスタムボリューム | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} +`snapshots.pattern` | string | カスタムボリューム | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} +`snapshots.schedule` | string | カスタムボリューム | `volume.snapshots.schedule` と同じ | {{snapshot_schedule_format}} + +### ストレージバケット設定 + +ローカルのストレージプールドライバでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには `core.storage_buckets_address` サーバ設定 ({ref}`server` 参照) を調整する必要があります。 + +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージバケットのサイズ/クォータ diff --git a/doc/reference/storage_zfs.md b/doc/reference/storage_zfs.md index 737c450..e5d47ee 100644 --- a/doc/reference/storage_zfs.md +++ b/doc/reference/storage_zfs.md @@ -20,6 +20,7 @@ ZFS は物理ストレージデバイスに基づいた論理ユニットを作 これらの論理ユニットは *ZFS pools* または *zpools* と呼ばれます。 さらにそれぞれの zpool は複数の *`データセット`* に分割されます。 これらの`データセット`は以下の異なるタイプがあります。 + - *ZFS ファイルシステム* はパーティションまたはマウントされたファイルシステムとして扱えます。 - *ZFS ボリューム* はブロックデバイスを表します。 - *ZFS スナップショット* は ZFS ファイルシステムまたは ZFS ボリュームの特定の状態をキャプチャーします。 @@ -93,6 +94,7 @@ ZFS は `quota` と `refquota` という 2 種類の異なるクォータのプ (storage-zfs-pool-config)= ## ストレージプール設定 + キー | 型 | デフォルト値 | 説明 :-- | :--- | :------ | :---------- `size` | string | 自動 (空きディスクスペースの 20%, >= 5 GiB and <= 30 GiB) | ループベースのプールを作成する際のストレージプールのサイズ (バイト単位、接尾辞のサポートあり) @@ -105,15 +107,24 @@ ZFS は `quota` と `refquota` という 2 種類の異なるクォータのプ (storage-zfs-vol-config)= ## ストレージボリューム設定 + キー | 型 | 条件 | デフォルト値 | 説明 :-- | :--- | :-------- | :------ | :---------- -`security.shifted` | bool | custom volume | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | `volume.security.unmapped` と同じか `false` | ボリュームの ID マッピングを無効にする -`size` | string | appropriate driver | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ -`snapshots.expiry` | string | custom volume | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} -`snapshots.schedule` | string | custom volume | `snapshots.schedule` と同じ | {{snapshot_schedule_format}} -`zfs.blocksize` | string | ZFS driver | `volume.zfs.blocksize` と同じ | ZFSブロックのサイズを512～16MiBの範囲で指定します（2の累乗でなければなりません）。ブロックボリュームでは、より大きな値が設定されていても、最大値の128KiBが使用されます。 -`zfs.remove_snapshots` | bool | ZFS driver | `volume.zfs.remove_snapshots` と同じか `false` | 必要に応じてスナップショットを削除するかどうか -`zfs.use_refquota` | bool | ZFS driver | `volume.zfs.use_refquota` と同じか `false` | 領域の `quota` の代わりに `refquota` を使うかどうか +`security.shifted` | bool | カスタムボリューム | `volume.security.shifted` と同じか `false` | {{enable_ID_shifting}} +`security.unmapped` | bool | カスタムボリューム | `volume.security.unmapped` と同じか `false` | ボリュームの ID マッピングを無効にする +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージボリュームのサイズ/クォータ +`snapshots.expiry` | string | カスタムボリューム | `volume.snapshots.expiry` と同じ | {{snapshot_expiry_format}} +`snapshots.pattern` | string | カスタムボリューム | `volume.snapshots.pattern` と同じか `snap%d` | {{snapshot_pattern_format}} +`snapshots.schedule` | string | カスタムボリューム | `snapshots.schedule` と同じ | {{snapshot_schedule_format}} +`zfs.blocksize` | string | ZFSドライバ | `volume.zfs.blocksize` と同じ | ZFSブロックのサイズを512～16MiBの範囲で指定します（2の累乗でなければなりません）。ブロックボリュームでは、より大きな値が設定されていても、最大値の128KiBが使用されます。 +`zfs.remove_snapshots` | bool | ZFSドライバ | `volume.zfs.remove_snapshots` と同じか `false` | 必要に応じてスナップショットを削除するかどうか +`zfs.use_refquota` | bool | ZFSドライバ | `volume.zfs.use_refquota` と同じか `false` | 領域の `quota` の代わりに `refquota` を使うかどうか `zfs.reserve_space` | bool | ZFS driver | `volume.zfs.reserve_space` と同じか `false` | `qouta`/`refquota` に加えて `reservation`/`refreservation` も使用するかどうか + +### ストレージバケット設定 + +ローカルのストレージプールドライバでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには `core.storage_buckets_address` サーバ設定 ({ref}`server` 参照) を調整する必要があります。 + +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`size` | string | 適切なドライバ | `volume.size` と同じ | ストレージバケットのサイズ/クォータ diff --git a/doc/remotes.md b/doc/remotes.md index 15b45b9..90c26f5 100644 --- a/doc/remotes.md +++ b/doc/remotes.md @@ -1,5 +1,7 @@ # リモート + ## イントロダクション + リモートは LXD のコマンドラインクライアント内の概念でありさまざまな LXD サーバやクラスタを参照するのに使用します。 リモートは実質的には特定の LXD サーバをサーバにログインしたり認証するのに必要な認証情報も含めて指定する URL を指す名前です。 LXD には次の 4 種類のリモートがあります。 @@ -10,6 +12,7 @@ LXD には次の 4 種類のリモートがあります。 - Local (ユーザーごと) ### Static + Static リモートは - `local` (default) - `ubuntu` @@ -18,15 +21,18 @@ Static リモートは これらはハードコードされておりユーザーが変更できません。 ### Default + 初回の使用時に自動的に追加されます。 ### Global (システムごと) + デフォルトでは global の設定ファイルは `/etc/lxc/config.yml` に置かれます。 `LXD_GLOBAL_CONF` 環境変数でパスを変更できます。 この設定ファイルを手動で編集して global リモートを追加できます。 これらのリモートの証明書は `servercerts` ディレクトリ (例: `/etc/lxc/servercerts/`) に置き、リモートの名前にマッチ (例: `foo.crt`) させます。 設定例を以下に示します。 + ``` remotes: foo: @@ -44,6 +50,7 @@ remotes: ``` ### Local (ユーザーごと) + local レベルのリモートは CLI (`lxc`) で次のように管理します。 `lxc remote [command]` diff --git a/doc/requirements.md b/doc/requirements.md index b6e8014..1b2faac 100644 --- a/doc/requirements.md +++ b/doc/requirements.md @@ -1,50 +1,59 @@ # 動作環境 + +## Go + LXD は Go 1.18 以上を必要とし、 Golang のコンパイラのみでテストされています。 (訳注: 以前は gccgo もサポートされていましたが Golang のみになりました) ビルドには最低 2GB の RAM を推奨します。 ## 必要なカーネルバージョン + サポートされる最小のカーネルバージョンは 5.4 です。 LXD には以下の機能をサポートするカーネルが必要です。 - * Namespaces (`pid`, `net`, `uts`, `ipc` と `mount`) - * Seccomp +* Namespaces (`pid`, `net`, `uts`, `ipc` と `mount`) +* Seccomp +* Native Linux AIO + ([`io_setup(2)`](https://man7.org/linux/man-pages/man2/io_setup.2.html) など) 以下のオプションの機能はさらなるカーネルオプションを必要とします。 - * Namespaces (`user` と `cgroup`) - * AppArmor (mount mediation に対する Ubuntu パッチを含む) - * Control Groups (`blkio`, `cpuset`, `devices`, `memory`, `pids` と `net_prio`) - * CRIU (正確な詳細は CRIU のアップストリームを参照のこと) +* Namespaces (`user` と `cgroup`) +* AppArmor (mount mediation に対する Ubuntu パッチを含む) +* Control Groups (`blkio`, `cpuset`, `devices`, `memory`, `pids` と `net_prio`) +* CRIU (正確な詳細は CRIU のアップストリームを参照のこと) さらに使用している LXC のバージョンで必要とされる他のカーネルの機能も 必要です。 ## LXC + LXD は以下のビルドオプションでビルドされた LXC 4.0.0 以上を必要とします。 - * `apparmor` (もし LXD の AppArmor サポートを使用するのであれば) - * `seccomp` +* `apparmor` (もし LXD の AppArmor サポートを使用するのであれば) +* `seccomp` Ubuntu を含む、さまざまなディストリビューションの最近のバージョンを 動かすためには、 LXCFS もインストールする必要があります。 ## QEMU + 仮想マシンを利用するには QEMU 6.0 以降が必要です。 ## 追加のライブラリー(と開発用のヘッダ) + LXD はデータベースとして `dqlite` を使用しています。 ビルドしセットアップするためには `make deps` を実行してください。 LXD は他にもいくつかの (たいていはパッケージ化されている) C ライブラリーを使用しています。 - - `libacl1` - - `libcap2` - - `liblz4` (`dqlite` で使用) - - `libuv1` (`dqlite` で使用) - - `libsqlite3` >= 3.25.0 (`dqlite` で使用) +* `libacl1` +* `libcap2` +* `liblz4` (`dqlite` で使用) +* `libuv1` (`dqlite` で使用) +* `libsqlite3` >= 3.25.0 (`dqlite` で使用) ライブラリーそのものとライブラリーの開発用ヘッダ (`-dev` パッケージ)の全てを インストールしたことを確認してください。 diff --git a/doc/rest-api.md b/doc/rest-api.md index 7db2bcb..9299a87 100644 --- a/doc/rest-api.md +++ b/doc/rest-api.md @@ -1,10 +1,13 @@ # REST API + ## イントロダクション + LXD とクライアントの間の全ての通信は HTTP 上の RESTful API を使って 行います。リモートの操作は SSL で暗号化して通信し、ローカルの操作は Unix ソケットを使って通信します。 ## API のバージョニング + サポートされている API のメジャーバージョンのリストは `GET /` を使って 取得できます。 @@ -15,13 +18,15 @@ Unix ソケットを使って通信します。 利用できます。 ## 戻り値 + 次の 3 つの標準的な戻り値の型があります。 - * 標準の戻り値 - * バックグラウンド操作 - * エラー +* 標準の戻り値 +* バックグラウンド操作 +* エラー ### 標準の戻り値 + 標準の同期的な操作に対しては以下のような dict が返されます。 ```js @@ -33,10 +38,10 @@ Unix ソケットを使って通信します。 } ``` - HTTP ステータスコードは必ず 200 です。 ### バックグラウンド操作 + リクエストの結果がバックグラウンド操作になる場合、 HTTP ステータスコードは 202 (Accepted) になり、操作の URL を指す HTTP の Location ヘッダが返されます。 @@ -52,7 +57,6 @@ HTTP ステータスコードは必ず 200 です。 } ``` - 操作のメタデータの構造は以下のようになります。 ```js @@ -79,13 +83,13 @@ HTTP ステータスコードは必ず 200 です。 } ``` - 対象の操作に対して追加のリクエストを送って情報を取り出さなくても、 何が起こっているかユーザーにとってわかりやすい形でボディは構成されています。 ボディに含まれる全ての情報はバックグラウンド操作の URL から取得する こともできます。 ### エラー + さまざまな状況によっては操作を行う前に直ぐに問題が起きる場合があり、 そういう場合には以下のような値が返されます。 @@ -98,7 +102,6 @@ HTTP ステータスコードは必ず 200 です。 } ``` - HTTP ステータスコードは 400, 401, 403, 404, 409, 412, 500 のいずれかです。 ## ステータスコード @@ -116,10 +119,10 @@ API クライアントが個々の値に依存できます。文字列表記の 整数表記のコードは常に 3 桁の数字で以下の範囲の値となっています。 - * 100 to 199: リソースの状態 (started, stopped, ready, ...) - * 200 to 399: 成功したアクションの結果 - * 400 to 599: 失敗したアクションの結果 - * 600 to 999: 将来使用するために予約されている番号の範囲 +* 100 to 199: リソースの状態 (started, stopped, ready, ...) +* 200 to 399: 成功したアクションの結果 +* 400 to 599: 失敗したアクションの結果 +* 600 to 999: 将来使用するために予約されている番号の範囲 ### 現在使用されているステータスコード一覧 @@ -143,6 +146,7 @@ API クライアントが個々の値に依存できます。文字列表記の 401 | キャンセルされた ## 再帰 + 巨大な一覧のクエリを最適化するために、コレクションに対して再帰が実装されています。 コレクションに対するクエリの GET リクエストに `recursion` パラメータを指定できます。 @@ -154,6 +158,7 @@ API クライアントが個々の値に依存できます。文字列表記の 実装されています。 ## フィルタ + 検索結果をある値でフィルタするために、コレクションにフィルタが実装されています。 コレクションに対する GET クエリに `filter` 引数を渡せます。 @@ -187,6 +192,7 @@ device の属性についてフィルタするには以下のように指定し images?filter=Properties.os eq Centos and not UpdateSource.Protocol eq simplestreams ## 非同期操作 + 完了までに 1 秒以上かかるかもしれない操作はバックグラウンドで実行しなければ なりません。そしてクライアントにはバックグラウンド操作 ID を返します。 @@ -194,6 +200,7 @@ device の属性についてフィルタするには以下のように指定し 通知を待つことが出来ます。 ## 通知 + 通知のために WebSocket ベースの API が利用できます。クライアントへ送られる トラフィックを制限するためにいくつかの異なる通知種別が存在します。 @@ -201,6 +208,7 @@ device の属性についてフィルタするには以下のように指定し 前に操作の通知をクライアントが常に購読しておくのがお勧めです。 ## PUT と PATCH の使い分け + LXD API は既存のオブジェクトを変更するのに PUT と PATCH の両方をサポートします。 PUT はオブジェクト全体を新しい定義で置き換えます。典型的には GET で現在の @@ -216,6 +224,7 @@ PATCH は変更したいプロパティだけを指定することでオブジ PUT を使う必要がある場合もあります。 ## インスタンス、コンテナと仮想マシン + このドキュメントでは `/1.0/instances/...` のようなパスを常に示します。 これらはかなり新しく、仮想マシンがサポートされた LXD 3.19 で導入されました。 @@ -226,6 +235,7 @@ PUT を使う必要がある場合もあります。 `/1.0/virtual-machines` に追加のエンドポイントも存在し、 `/1.0/containers` とほぼ同様ですが、仮想マシンのタイプのインスタンスのみを表示します。 ## API 構造 + LXD は API エンドポイントを記述する [Swagger](https://swagger.io/) 仕様を自動生成しています。 この API 仕様の YAML 版が [`rest-api.yaml`](https://github.com/lxc/lxd/blob/master/doc/rest-api.yaml) にあります。 手軽にウェブで見る場合は [`https://linuxcontainers.org/lxd/api/master/`](https://linuxcontainers.org/lxd/api/master/) を参照してください。 diff --git a/doc/rest-api.yaml b/doc/rest-api.yaml index 4800014..5f75f9b 100644 --- a/doc/rest-api.yaml +++ b/doc/rest-api.yaml @@ -12305,8 +12305,8 @@ paths: produces: - application/json responses: - "200": - $ref: '#/responses/EmptySyncResponse' + "202": + $ref: '#/responses/Operation' "400": $ref: '#/responses/BadRequest' "403": @@ -14087,7 +14087,7 @@ paths: - application/json responses: "200": - $ref: '#/responses/EmptySyncResponse' + $ref: '#/definitions/StorageBucketKey' "400": $ref: '#/responses/BadRequest' "403": @@ -14206,7 +14206,7 @@ paths: - application/json responses: "200": - $ref: '#/responses/EmptySyncResponse' + $ref: '#/definitions/StorageBucketKey' "400": $ref: '#/responses/BadRequest' "403": diff --git a/doc/security.md b/doc/security.md index 0c85b1e..d6502ee 100644 --- a/doc/security.md +++ b/doc/security.md @@ -19,6 +19,7 @@ :start-after: :end-before: ``` + ## LXDデーモンへのアクセス LXDはUnixソケットを介してローカルにアクセスできるデーモンで、設定されていれば{abbr}`TLS(Transport Layer Security)`ソケットを介してリモートにアクセスすることもできます。 @@ -67,6 +68,16 @@ LXDはまた、*特権* (*privileged*) コンテナを実行することがで コンテナのセキュリティと私たちが使っているカーネルの機能についてのより詳細な情報は [LXCセキュリティページ](https://linuxcontainers.org/ja/lxc/security/)にあります。 +### コンテナ名の漏洩 + +デフォルトの設定ではシステム上の全ての cgroup と、さらに転じて、全ての実行中のコンテナを一覧表示することが簡単にできてしまいます。 + +コンテナを開始する前に `/sys/kernel/slab` と `/proc/sched_debug` へのアクセスをブロックすることでコンテナ名の漏洩を防げます。 +このためには以下のコマンドを実行してください。 + + chmod 400 /proc/sched_debug + chmod 700 /sys/kernel/slab/ + ## ネットワークセキュリティ ネットワークインターフェースは必ず安全に設定してください。 @@ -112,7 +123,7 @@ lxc config device override security.mac_filtering=true これらの機能を併用することで、ブリッジに接続されているインスタンスがMACアドレスやIPアドレスを詐称することを防ぐことができます。 これらのオプションは、ホスト上で利用可能なものに応じて、`xtables`（`iptables`、`ip6tables`、`ebtables`）または`nftables`を使用して実装されます。 -これらのオプションは、ネストされたコンテナが異なるMACアドレスを持つ親ネットワークを使用すること（ブリッジされたNICや`macvlan` NICを使用すること）を効果的に防止することができます。 +これらのオプションは、ネストされたコンテナが異なるMACアドレスを持つ親ネットワークを使用すること（ブリッジされたNICや`macvlan` NICを使用すること）を効果的に防止することができるのは注目に値します。 IPフィルタリング機能は、スプーフィングされたIPを含むARPおよびNDPアドバタイジングをブロックし、スプーフィングされたソースアドレスを含むすべてのパケットをブロックします。 diff --git a/doc/server.md b/doc/server.md index fffda08..eae4ff5 100644 --- a/doc/server.md +++ b/doc/server.md @@ -4,14 +4,14 @@ key/value 設定は現在サポートされている以下のネームスペースによって 名前空間が分けられています。 - - `backups` (バックアップ設定) - - `candid` (Candid を使った外部のユーザー認証) - - `cluster` (クラスタ設定) - - `core` (コア・デーモン設定) - - `images` (イメージ設定) - - `instances` (インスタンス設定) - - `maas` (MAAS 統合) - - `rbac` (外部の Candid と Canonical の RBAC を使ったロールベースのアクセス制御) +- `backups` (バックアップ設定) +- `candid` (Candid を使った外部のユーザー認証) +- `cluster` (クラスタ設定) +- `core` (コア・デーモン設定) +- `images` (イメージ設定) +- `instances` (インスタンス設定) +- `maas` (MAAS 統合) +- `rbac` (外部の Candid と Canonical の RBAC を使ったロールベースのアクセス制御) ```{rst-class} break-col-4 min-width-4-8 ``` @@ -45,6 +45,7 @@ key/value 設定は現在サポートされている以下のネームスペー `core.proxy_http` | string | global | - | HTTP プロキシを使用する場合はその URL (未指定の場合は `HTTP_PROXY` 環境変数を参照) `core.proxy_ignore_hosts` | string | global | - | プロキシが不要なホスト (`NO_PROXY` と同様な形式、例えば 1.2.3.4,1.2.3.5, を指定。未指定の場合は `NO_PROXY` 環境変数を参照) `core.shutdown_timeout` | integer | global | `5` | LXD サーバがシャットダウンを完了するまでに待つ時間を分で指定 +`core.storage_buckets_address` | string | local | - | ストレージオブジェクトサーバをバインドする先の (HTTPS) アドレス `core.trust_ca_certificates` | bool | global | - | CA に署名されたクライアント証明書を自動的に信頼するかどうか `core.trust_password` | string | global | - | 信頼を確立するためにクライアントに要求するパスワード `images.auto_update_cached` | bool | global | `true` | LXD がキャッシュしているイメージを自動的に更新するかどうか @@ -53,6 +54,13 @@ key/value 設定は現在サポートされている以下のネームスペー `images.default_architecture` | string | - | - | アーキテクチャーが混在するクラスタ内で使用するデフォルトのアーキテクチャー `images.remote_cache_expiry` | integer | global | `10` | キャッシュされたが未使用のイメージを破棄するまでの日数 `instances.nic.host_name` | string | global | `random` | `random` に設定するとランダムなホストインタフェース名を使用し、`mac` に設定すると `lxd` の形式 (先頭2桁を除いた MAC アドレス) で名前を生成 +`loki.api.ca_cert` | string | global | - | Loki サーバの CA 証明書 +`loki.api.url` | string | global | - | Loki サーバの URL +`loki.auth.password` | string | global | - | 認証に使用するパスワード +`loki.auth.username` | string | global | - | 認証に使用するユーザ名 +`loki.labels` | string | global | - | Loki ログエントリにラベルとして使用する値のカンマ区切りリスト +`loki.loglevel` | string | global | - | Loki サーバに送信する最低のログレベル +`loki.types` | string | global | - | Loki サーバに送信するイベント種別 `maas.api.key` | string | global | - | MAAS を管理するための API キー `maas.api.url` | string | global | - | MAAS サーバの URL `maas.machine` | string | local | ホスト名 | この LXD ホストの MAAS での名前 @@ -77,6 +85,7 @@ lxc config set クラスタの一部として動作するときは、上記の表でスコープが `global` のキーは全てのクラスタメンバーに即座に反映されます。スコープが `local` のキーはコマンドラインツールの `--target` オプションを使ってメンバーごとに設定する必要があります。 ## LXD をネットワーク上に公開する + デフォルトでは LXD は Unix ソケット経由でローカルのユーザーのみが使用できます。 LXD をネットワーク上に公開するには `core.https_address` を設定する必要があります。 @@ -88,6 +97,7 @@ LXD をネットワーク上に公開するには `core.https_address` を設定 認証についての詳細は [セキュリティ](security.md) を参照してください。 ## 外部認証 + ネットワーク経由で LXD にアクセスする場合は [Candid](https://github.com/canonical/candid) による外部認証を使うように設定できます。 上記の `candid.*` 設定キーをデプロイ済みの Candid に対応する値に設定することでユーザーはウェブブラウザーで認証し LXD に信頼されることができます。 diff --git a/doc/storage.md b/doc/storage.md index 9bbf504..d886578 100644 --- a/doc/storage.md +++ b/doc/storage.md @@ -8,20 +8,11 @@ discourse: 7735 :maxdepth: 1 ストレージについて -プールの作成 -プールの設定 -プールの表示 -プールのリサイズ +プールの管理 プール内にインスタンスを作成 -ボリュームの作成 -ボリュームの設定 -ボリュームの表示 -ボリュームのリサイズ +ボリュームの管理 ボリュームの移動とコピー ボリュームのバックアップ -バケットの作成 -バケットの設定 -バケットの表示 -バケットのリサイズ +バケットの管理 reference/storage_drivers ``` diff --git a/doc/syscall-interception.md b/doc/syscall-interception.md index e7c25aa..fe40167 100644 --- a/doc/syscall-interception.md +++ b/doc/syscall-interception.md @@ -1,4 +1,5 @@ # システムコールのインターセプション + LXD では非特権コンテナで、いくつか特定のシステムコールをインターセプトできます。もし、それが安全であると見なせるのであれば、ホスト上で特権を昇格させて実行します。 これを行うことで、対象のシステムコールではパフォーマンスに影響があり、LXD ではリクエストを評価するための作業が必要となり、もし許可されれば昇格した特権で実行されます。 @@ -6,7 +7,9 @@ LXD では非特権コンテナで、いくつか特定のシステムコール 特定のシステムコールインターセプションのオプションの有効化はコンテナの設定オプションを使ってコンテナ単位で行われます。 ## 利用できるシステムコール + ### `mknod` / `mknodat` + `mknod` と `mknodat` システムコールを使用して、色々なスペシャルファイルを作成できます。 もっとも一般的にはコンテナ内部で、ブロックデバイスやキャラクターデバイスを作成するために呼び出されます。このようなデバイスを作成することは、非特権コンテナ内では許可されません。これは、ディスクやメモリのようなリソースに直接書き込みのアクセスを許可することになり、特権を昇格するのに非常に簡単な方法であるためです。 @@ -15,20 +18,21 @@ LXD では非特権コンテナで、いくつか特定のシステムコール 現時点で許可されているデバイスは次のものです: - - overlayfs whiteout (char 0:0) - - `/dev/console` (char 5:1) - - `/dev/full` (char 1:7) - - `/dev/null` (char 1:3) - - `/dev/random` (char 1:8) - - `/dev/tty` (char 5:0) - - `/dev/urandom` (char 1:9) - - `/dev/zero` (char 1:5) +- overlayfs whiteout (char 0:0) +- `/dev/console` (char 5:1) +- `/dev/full` (char 1:7) +- `/dev/null` (char 1:3) +- `/dev/random` (char 1:8) +- `/dev/tty` (char 5:0) +- `/dev/urandom` (char 1:9) +- `/dev/zero` (char 1:5) キャラクターデバイス以外のすべてのファイルタイプは、現時点では通常通りカーネルに送られるので、この機能を有効にしても動作は全く変わりません。 この機能は `security.syscalls.intercept.mknod` を `true` に設定することで有効に出来ます。 ### `bpf` + カーネル内の eBPF プログラムを管理するために `bpf` システムコールを使用します。 これらは様々なカーネルサブシステムにアタッチされます。 @@ -40,6 +44,7 @@ LXD の eBPF サポートは現在のところデバイスの cgroup エント `security.syscalls.intercept.bpf.devices` の両方を true に設定する必要があります。 ### `mount` + `mount` システムコールは物理と仮想ファイルシステムの両方のマウントを可能にします。 デフォルトでは、非特権コンテナはカーネルにより制限され、いくつかの仮想とネットワーク ファイルシステムのみに限定されています。 @@ -72,6 +77,7 @@ UID/GID マップでマウントした結果をシフトさせるのに使用で 過大な負荷をかける簡単な方法になることを留意しておくべきです。 ### `sched_setscheduler` + `sched_setscheduler` システムコールはプロセスの優先度を管理するのに使えます。 これを許可するとユーザが自分のプロセスの優先度を著しく上げることを許すため、 @@ -83,11 +89,12 @@ UID/GID マップでマウントした結果をシフトさせるのに使用で のみがこれの使用を許すべきです。 ### `setxattr` + `setxattr` システムコールは、拡張ファイル属性を設定するのに使われます。 現時点で、これにより処理される属性は次のものです: - - trusted.overlay.opaque (overlayfs directory whiteout) +- trusted.overlay.opaque (overlayfs directory whiteout) この介入は多数の文字列で行う必要があるため、現在のところ、対象の少数の属性のみインターセプトする簡単な方法がありません。上記の属性のみを許可しているため、カーネルが以前に許可していた他の属性を破損する可能性があります。 diff --git a/doc/userns-idmap.md b/doc/userns-idmap.md index 4d42886..303491f 100644 --- a/doc/userns-idmap.md +++ b/doc/userns-idmap.md @@ -1,5 +1,7 @@ # ユーザー名前空間 (user namespace) 用の ID のマッピング + ## イントロダクション + LXD は安全なコンテナを実行します。これは主にユーザー・ネームスペースの使用 によって実現されています。ユーザー・ネームスペースはコンテナを非特権で実行 することを可能にし、攻撃対象を大幅に限定します。 @@ -7,7 +9,6 @@ LXD は安全なコンテナを実行します。これは主にユーザー・ ユーザー・ネームスペースはコンテナの UID と GID の組をホストの UID と GID の組にマッピングすることで機能します。 - 例えば、 100000 から 165535 までのホストの UID と GID を LXD が使用できる ようにし、コンテナで 0 から 65535 までの UID/GID にマッピングするように 設定できます。 @@ -19,10 +20,12 @@ root (0) と nobody (65534) の POSIX の範囲をカバーするため、割当 最低 65535 個の UID と GID であるべきです。 ## カーネルのサポート + ユーザー・ネームスペースの使用にはカーネル 3.12 以上が必要です。 LXD は 古いカーネルでも起動しますが、コンテナを起動するのは拒否します。 ## 使用可能な範囲 + ほとんどのホストでは、 LXD は初回起動時に `lxd` ユーザーの割当のために `/etc/subuid` と `/etc/subgid` をチェックし、そこで指定されている範囲の 最初の 65536 個の UID と GID をデフォルト・プロファイルで使用するように @@ -43,10 +46,12 @@ LXD はコンテナの起動に失敗します。 （コンテナランタイム自身はユーザー権限で実行するような場合）に、通常は推奨される設定です。 ## ホスト間で異なる範囲の使用 + ホスト間でコンテナを移動する時、送信側のマッピングが送られるので、受信側の ホストで異なる範囲にマッピング可能です。 ## コンテナ毎に異なる ID マッピング + コンテナを他のコンテナからより一層隔離するために、 LXD はコンテナ毎に 異なる ID マッピングを使用することをサポートしています。これはコンテナ毎に `security.idmap.isolated` と `security.idmap.size` という 2 つの設定項目で @@ -69,6 +74,7 @@ ID の範囲を持つように設定されます (もしそのようなコンテ これらのプロパティを反映するにはコンテナの再起動が必要です。 ## カスタムの ID マッピング + さらに LXD は ID マッピングの一部をカスタマイズすることをサポートします。例えば、 UID を変更するファイルシステムを必要とせずに、ホストのファイルシステムの一部を コンテナにバインドマウントすることをユーザーに許可できます。このためのコンテナ毎の diff --git a/doc/virtual-machines.md b/doc/virtual-machines.md index cf7c102..fb3f929 100644 --- a/doc/virtual-machines.md +++ b/doc/virtual-machines.md @@ -3,8 +3,8 @@ discourse: 7519,9281,9223 --- # 仮想マシン -## イントロダクション -仮想マシンはコンテナと共に LXD でサポートされる新しいインスタンスタイプです。 + +仮想マシンはコンテナと共に LXD でサポートされるインスタンスタイプです。 仮想マシンは `qemu` を使って実装されています。 @@ -12,4 +12,5 @@ discourse: 7519,9281,9223 しかし、私達はコンテナと同等の機能を目指して引き続き努力します。 ## 設定 + 有効な設定項目については [インスタンスの設定](instances.md) を参照してください。