diff --git a/.textlint-incus-ja-prh-rules.yml b/.textlint-incus-ja-prh-rules.yml new file mode 100644 index 00000000000..7b94ee53508 --- /dev/null +++ b/.textlint-incus-ja-prh-rules.yml @@ -0,0 +1,74 @@ +meta: + reviewer: + - hnakamur + - tenforward +related: https://github.com/lxc-jp/incus-ja/ +version: 1 +rules: + # カタカナの長音記号をつけない単語 + - expected: アーキテクチャ + pattern: アーキテクチャー + - expected: エディタ + pattern: エディター + - expected: コンテナ + pattern: コンテナー + - expected: セマフォ + pattern: セマフォー + - expected: ダーティ + pattern: ダーティー + - expected: ブラウザ + pattern: ブラウザー + + # カタカナの長音記号をつける単語 + # https://github.com/prh/prh/blob/602794323a717b9511ea23e32c5b1e760cf16227/misc/prh.yml#L86 + - expected: コントローラー + pattern: /コントローラ(?!ー)/ + - expected: コンピューター + pattern: /コンピュータ(?!ー)/ + - expected: サーバー + pattern: /サーバ(?!ー)/ + - expected: セキュリティー + pattern: /セキュリティ(?!ー)/ + - expected: ディスクリプター + pattern: /ディスクリプタ(?!ー)/ + - expected: ディレクトリー + pattern: /ディレクトリ(?!ー)/ + - expected: ドライバー + pattern: /ドライバ(?!ー)/ + - expected: バッファー + pattern: /バッファ(?!ー)/ + - expected: パラメーター + pattern: /パラメータ(?!ー)/ + - expected: プロセッサー + pattern: /プロセッサ(?!ー)/ + - expected: メモリー + pattern: /メモリ(?!ー)/ + - expected: ユーザー + pattern: /ユーザ(?!ー)/ + - expected: リーダー + pattern: /リーダ(?!(ー|ブル))/ + specs: + - from: リーダ + to: リーダー + - from: リーダブル + to: リーダブル + + # カタカナではなく英語にする単語 + - expected: Namespace + pattern: ネームスペース + + # 一般的なカタカタ語の表記ゆれ + - expected: インターフェース + pattern: /インタ(ーフェイ|フェー|フェイ)ス/ + - expected: レプリケーション + pattern: リプリケーション + + # ひらがなに開く単語 + - expected: すべて + pattern: 全て + - expected: たとえば + pattern: 例えば + + # LXDからの移行 + - expected: Incus + pattern: /LXD(?!_DIR)/ diff --git a/.textlintignore b/.textlintignore new file mode 100644 index 00000000000..bd88ca9c96c --- /dev/null +++ b/.textlintignore @@ -0,0 +1,10 @@ +client/** +cmd/** +doc/html/** +internal/** +grafana/** +node_modules/** +po/** +scripts/** +shared/** +test/** diff --git a/.textlintrc.json b/.textlintrc.json index 5a92fa82a87..aca95a56e7c 100644 --- a/.textlintrc.json +++ b/.textlintrc.json @@ -4,25 +4,22 @@ "comments": true }, "rules": { + "ja-space-between-half-and-full-width": { + "space": ["alphabets", "numbers"] + }, "@textlint-ja/textlint-rule-no-insert-dropping-sa": true, - "textlint-rule-ja-hiragana-fukushi": true, - "textlint-rule-ja-hiragana-hojodoushi": true, - "textlint-rule-ja-hiragana-keishikimeishi": true, "textlint-rule-ja-no-inappropriate-words": true, - "textlint-rule-ja-no-mixed-period": true, - "textlint-rule-ja-no-redundant-expression": true, + "textlint-rule-ja-no-mixed-period": { + "periodMark": "。", + "allowPeriodMarks": [":"] + }, "textlint-rule-ja-unnatural-alphabet": true, - "textlint-rule-no-doubled-conjunction": true, - "textlint-rule-no-doubled-conjunctive-particle-ga": true, - "textlint-rule-no-doubled-joshi": true, - "textlint-rule-no-double-negative-ja": true, "textlint-rule-no-dropping-the-ra": true, "textlint-rule-no-hankaku-kana": true, - "textlint-rule-no-mix-dearu-desumasu": true, "textlint-rule-no-mixed-zenkaku-and-hankaku-alphabet": true, "textlint-rule-prh": { "rulePaths": [ - ".textlint-prh-rules/media/WEB+DB_PRESS.yml" + ".textlint-incus-ja-prh-rules.yml" ] } } diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index b840f4c16fa..abe53e02995 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,68 +1,61 @@ -# Contributing +# コントリビュート -The Incus team appreciates contributions to the project, through pull requests, issues on the [GitHub repository](https://github.com/lxc/incus/issues), or discussions or questions on the [forum](https://discuss.linuxcontainers.org). +Pull Request、[GitHubレポジトリ](https://github.com/lxc/incus/issues)でのイシュー、[f フォーラム](https://discuss.linuxcontainers.org)での議論や質問を通してプロジェクトに貢献していただけることをIncusチームは感謝します。 -Check the following guidelines before contributing to the project. +プロジェクトへ貢献する前に、以下のガイドラインを確認してください。 ## Code of Conduct -When contributing, you must adhere to the Code of Conduct, which is available at: [`https://github.com/lxc/incus/blob/main/CODE_OF_CONDUCT.md`](https://github.com/lxc/incus/blob/main/CODE_OF_CONDUCT.md) +コントリビュートする際には、行動規範を遵守しなければなりません。行動規範は、以下のサイトから入手できます。[`https://github.com/lxc/incus/blob/main/CODE_OF_CONDUCT.md`](https://github.com/lxc/incus/blob/main/CODE_OF_CONDUCT.md) -## License and copyright +## ライセンスと著作権 -By default, any contribution to this project is made under the Apache -2.0 license. +デフォルトで、このプロジェクトに対するいかなる貢献も Apache 2.0 ライセンスの下で行われます。 -The author of a change remains the copyright holder of their code -(no copyright assignment). +変更の著者は、そのコードに対する著作権を保持します (著作権の譲渡はありません)。 -## Pull requests +## Pull Request -Changes to this project should be proposed as pull requests on GitHub -at: [`https://github.com/lxc/incus`](https://github.com/lxc/incus) +このプロジェクトへの変更は、GitHubの[`https://github.com/lxc/incus`](https://github.com/lxc/incus)でPull Requestとして提案してください。 -Proposed changes will then go through review there and once approved, -be merged in the main branch. +提案された変更はそこでコードレビューを受け、承認されればメインブランチにマージされます。 -### Commit structure +### コミット構成 -Separate commits should be used for: +コミットを次のように分類する必要があります。 -- API extension (`api: Add XYZ extension`, contains `doc/api-extensions.md` and `internal/version/api.go`) -- Documentation (`doc: Update XYZ` for files in `doc/`) -- API structure (`shared/api: Add XYZ` for changes to `shared/api/`) -- Go client package (`client: Add XYZ` for changes to `client/`) -- CLI (`lxc/: Change XYZ` for changes to `lxc/`) -- Scripts (`scripts: Update bash completion for XYZ` for changes to `scripts/`) -- Incus daemon (`incus/: Add support for XYZ` for changes to `incus/`) -- Tests (`tests: Add test for XYZ` for changes to `tests/`) +- API拡張（`doc/api-extensions.md`と`internal/version/api.go`を含む変更に対して`api: Add XYZ extension`） +- ドキュメント（`doc/`内のファイルに対して`doc: Update XYZ`） +- API構造（`shared/api/`の変更に対して`shared/api: Add XYZ`） +- Goクライアントパッケージ（`client/`の変更に対して`client: Add XYZ`） +- CLI（`cmd/`の変更に対して`cmd/: Change XYZ`） +- スクリプト（`scripts/`の変更に対して`scripts: Update bash completion for XYZ`） +- Incusデーモン（`incus/`の変更に対して`incus/: Add support for XYZ`） +- テスト（`tests/`の変更に対して`tests: Add test for XYZ`） -The same kind of pattern extends to the other tools in the Incus code tree -and depending on complexity, things may be split into even smaller chunks. +同様のパターンがIncusコードツリーのほかのツールにも適用されます。 +そして複雑さによっては、さらに小さな単位に分けられるかもしれません。 -When updating strings in the CLI tool (`lxc/`), you may need a commit to update the templates: +CLIツール（`cmd/`）内の文字列を更新する際は、テンプレートを更新してコミットする必要があります。 make i18n git commit -a -s -m "i18n: Update translation templates" po/ -When updating API (`shared/api`), you may need a commit to update the swagger YAML: +API（`shared/api`）を更新する際は、swagger YAMLも更新してコミットする必要があります。 make update-api git commit -s -m "doc/rest-api: Refresh swagger YAML" doc/rest-api.yaml -This structure makes it easier for contributions to be reviewed and also -greatly simplifies the process of back-porting fixes to stable branches. +このようにすることで、コントリビューションに対するレビューが容易になり、安定ブランチへバックポートするプロセスが大幅に簡素化されます。 -### Developer Certificate of Origin +### 開発者の起源の証明 -To improve tracking of contributions to this project we use the DCO 1.1 -and use a "sign-off" procedure for all changes going into the branch. +このプロジェクトへの貢献の追跡を改善するために、DCO 1.1を使用しており、ブランチに入るすべての変更に対して「サインオフ」手順を使用しています。 -The sign-off is a simple line at the end of the explanation for the -commit which certifies that you wrote it or otherwise have the right -to pass it on as an open-source contribution. +サインオフとは、あなたがそのコミットを書いたことを証明する、そのコミットの説明の最後にある単純な行です。 +この行は、自分が書いたものであることを証明したり、オープンソースとして渡す権利があることを証明したりします。 ``` Developer Certificate of Origin @@ -102,20 +95,20 @@ By making a contribution to this project, I certify that: this project or the open source license(s) involved. ``` -An example of a valid sign-off line is: +有効なサインオフラインの例は以下の通りです。 ``` Signed-off-by: Random J Developer ``` -Use a known identity and a valid e-mail address. -Sorry, no anonymous contributions are allowed. +実名と有効な電子メールアドレスを使用してください。 +残念ながら、ペンネームや匿名での投稿はできません。 -We also require each commit be individually signed-off by their author, -even when part of a larger set. You may find `git commit -s` useful. +また、それぞれのコミットには作者が個別に署名する必要があります。 +大きなセットの一部であってもです。`git commit -s`が役に立つでしょう。 -## More information +## そのほかの情報 -For more information, see [Contributing](https://linuxcontainers.org/incus/doc/main/contributing/) in the documentation. +より詳しい情報は、ドキュメントの[Contributing](doc/contributing.md)をご覧ください。 diff --git a/Makefile b/Makefile index 3603bb12348..00ea74118db 100644 --- a/Makefile +++ b/Makefile @@ -143,7 +143,7 @@ doc: doc-setup doc-incremental .PHONY: doc-incremental doc-incremental: @echo "Build the documentation" - . $(SPHINXENV) ; LOCAL_SPHINX_BUILD=True sphinx-build -c doc/ -b dirhtml doc/ doc/html/ -d doc/.sphinx/.doctrees -w doc/.sphinx/warnings.txt + . $(SPHINXENV) ; sphinx-build -c doc/ -b dirhtml doc/ doc/html/ -d doc/.sphinx/.doctrees -w doc/.sphinx/warnings.txt .PHONY: doc-serve doc-serve: @@ -218,7 +218,7 @@ endif .PHONY: dist dist: doc # Cleanup - rm -Rf $(ARCHIVE).gz + rm -Rf $(ARCHIVE).xz # Create build dir $(eval TMP := $(shell mktemp -d)) @@ -227,6 +227,7 @@ dist: doc # Download dependencies (cd $(TMP)/incus-$(VERSION) ; $(GO) mod vendor) + (cd $(TMP)/incus-$(VERSION)/cmd/lxd-to-incus ; $(GO) mod vendor) # Download the cowsql libraries git clone --depth=1 https://github.com/cowsql/cowsql $(TMP)/incus-$(VERSION)/vendor/cowsql @@ -239,7 +240,7 @@ dist: doc cp -r doc/html $(TMP)/incus-$(VERSION)/doc/html/ # Assemble tarball - tar --exclude-vcs -C $(TMP) -zcf $(ARCHIVE).gz incus-$(VERSION)/ + tar --exclude-vcs -C $(TMP) -Jcf $(ARCHIVE).xz incus-$(VERSION)/ # Cleanup rm -Rf $(TMP) diff --git a/README.md b/README.md index 43f9e16d66b..2016245adf3 100644 --- a/README.md +++ b/README.md @@ -1,93 +1,96 @@ # Incus -Incus is a modern, secure and powerful system container and virtual machine manager. +Incusは次世代のシステムコンテナおよび仮想マシンマネージャーです。 -It provides a unified experience for running and managing full Linux systems inside containers or virtual machines. Incus supports images for a large number of Linux distributions (official Ubuntu images and images provided by the community) and is built around a very powerful, yet pretty simple, REST API. Incus scales from one instance on a single machine to a cluster in a full data center rack, making it suitable for running workloads both for development and in production. +コンテナや仮想マシンの中で動作する完全なLinuxシステムに統一されたユーザーエクスペリエンスを提供します。 +Incusは数多くの Linuxディストリビューションのイメージ（公式のUbuntuイメージとコミュニティにより提供されるイメージ）を提供しており、非常にパワフルでありながら、それでいてシンプルなREST APIを中心に構築されています。 +Incusは単一のマシン上の単一のインスタンスからデータセンターのフルラック内のクラスタまでスケールし、開発とプロダクションの両方のワークロードに適しています。 -Incus allows you to easily set up a system that feels like a small private cloud. You can run any type of workload in an efficient way while keeping your resources optimized. +Incusを使えば小さなプライベートクラウドのように感じられるシステムを簡単にセットアップできます。 +あなたのマシン資源を最適に利用しながら、あらゆるワークロードを効率よく実行できます。 -You should consider using Incus if you want to containerize different environments or run virtual machines, or in general run and manage your infrastructure in a cost-effective way. +さまざまな環境をコンテナ化したい場合や仮想マシンを稼働させたい場合、あるいは一般にあなたのインフラを費用効率よく稼働および管理したい場合にはIncusを使うのを検討するのがお勧めです。 -You can try Incus online at: [`https://linuxcontainers.org/incus/try-it/`](https://linuxcontainers.org/incus/try-it/) +[`https://linuxcontainers.org/incus/try-it/`](https://linuxcontainers.org/incus/try-it/)にてオンラインでIncusを試せます。 -## Fork of Canonical LXD -Incus, which is named after the [Cumulonimbus incus](https://en.wikipedia.org/wiki/Cumulonimbus_incus) or anvil cloud is a community fork of Canonical's LXD. +## Canonical LXDのフォーク +Incusは、[Cumulonimbus incus](https://en.wikipedia.org/wiki/Cumulonimbus_incus)と鉄床雲にちなんで名づけられましたが、CanonicalのLXDのコミュニティによるフォークです。 -This fork was made in response to [Canonical's takeover](https://linuxcontainers.org/lxd/) of the LXD project from the Linux Containers community. +このフォークはLinux ContainersコミュニティからLXDプロジェクトを[Canonicalが奪取](https://linuxcontainers.org/lxd/)したことに対する回答として作られました。 -The main aim of this fork is to provide once again a real community project where everyone's contributions are welcome and no one single commercial entity is in charge of the project. +このフォークの主な目的は、みなさんの貢献が歓迎され、単一の営利団体がプロジェクトを管理することがないような、真のコミュニティプロジェクトを再び提供することです。 -The fork was done at the LXD 5.16 release, making it possible to upgrade from LXD releases up to and including LXD 5.16. -Upgrading from a later LXD release may not work as the two projects are likely to start diverging from this point onwards. +このフォークはLXD 5.16のリリースの時点で行われ、5.16を含むそれ以前のリリースのLXDからのアップグレードを可能にしています。 +この時点以降2つのプロジェクトは分化していく可能性が高いので、それ以降のLXDリリースからのアップグレードはうまく動かないかもしれません。 -Incus will keep monitoring and importing relevant changes from LXD over time though changes and features that are specific to Ubuntu or Canonical's products are unlikely to be carried over. +Incusは今後もLXDの変更を監視し関連性のある変更は取り込む予定ですが、UbuntuやCanonical製品に特化した変更や機能は取り込まれない可能性が高いです。 -## Get started +## 使い始めるには -See [Getting started](https://linuxcontainers.org/incus/docs/main/getting_started/) in the Incus documentation for installation instructions and first steps. +インストール手順と最初のステップはIncusドキュメントの[Getting started](https://linuxcontainers.org/incus/docs/main/getting_started/)（TODO：リンク先確認）を参照してください。 -- Release announcements: [`https://discuss.linuxcontainers.org/c/news/`](https://discuss.linuxcontainers.org/c/news/) -- Release tarballs: [`https://github.com/lxc/incus/releases/`](https://github.com/lxc/incus/releases/) -- Documentation: [`https://linuxcontainers.org/incus/docs/main/`](https://linuxcontainers.org/incus/docs/main/) +- リリースのアナウンス：[`https://discuss.linuxcontainers.org/c/news/`](https://discuss.linuxcontainers.org/c/news/) +- リリースtarballs：[`https://github.com/lxc/incus/releases/`](https://github.com/lxc/incus/releases/) +- ドキュメント： [`https://incus-ja.readthedocs.io/ja/latest/`](https://incus-ja.readthedocs.io/ja/latest/)（原文： [`https://linuxcontainers.org/incus/docs/main/`](https://linuxcontainers.org/incus/docs/main/)） -## Status +## ステータス -Type | Service | Status +タイプ | サービス | ステータス --- | --- | --- -Tests | GitHub | [![Build Status](https://github.com/lxc/incus/actions/workflows/tests.yml/badge.svg?branch=main)](https://github.com/lxc/incus/actions?query=event%3Apush+branch%3Amain) -Go documentation | Godoc | [![GoDoc](https://godoc.org/github.com/lxc/incus/client?status.svg)](https://godoc.org/github.com/lxc/incus/client) -Static analysis | GoReport | [![Go Report Card](https://goreportcard.com/badge/github.com/lxc/incus)](https://goreportcard.com/report/github.com/lxc/incus) +テスト | GitHub | [![Build Status](https://github.com/lxc/incus/actions/workflows/tests.yml/badge.svg?branch=main)](https://github.com/lxc/incus/actions?query=event%3Apush+branch%3Amain) +Goドキュメント | Godoc | [![GoDoc](https://godoc.org/github.com/lxc/incus/client?status.svg)](https://godoc.org/github.com/lxc/incus/client) +静的解析 | GoReport | [![Go Report Card](https://goreportcard.com/badge/github.com/lxc/incus)](https://goreportcard.com/report/github.com/lxc/incus) -## Security +## セキュリティ -Consider the following aspects to ensure that your Incus installation is secure: +Incusのインストールが安全であることを保証するために、以下の点を考慮してください。 -- Keep your operating system up-to-date and install all available security patches. -- Use only supported Incus versions. -- Restrict access to the Incus daemon and the remote API. -- Do not use privileged containers unless required. If you use privileged containers, put appropriate security measures in place. See the [LXC security page](https://linuxcontainers.org/lxc/security/) for more information. -- Configure your network interfaces to be secure. +- OSを最新に保ち、利用可能なすべてのセキュリティパッチをインストールしてください。 +- サポートされているIncusのバージョンのみを使用してください。 +- IncusデーモンとリモートAPIへのアクセスを制限してください。 +- 必要とされない限り、特権コンテナを使わないでください。特権的なコンテナを使う場合は、適切なセキュリティ対策をしてください。詳細は[LXCセキュリティページ](https://linuxcontainers.org/ja/lxc/security/)を参照してください。 +- ネットワークインタフェースを安全に設定してください。 -See [Security](https://github.com/lxc/incus/blob/main/doc/explanation/security.md) for detailed information. +詳しい情報は[Security](https://github.com/lxc-jp/incus-ja/blob/main/doc/explanation/security.md)を参照してください。 -**IMPORTANT:** +**重要：** -Local access to Incus through the Unix socket always grants full access to Incus. -This includes the ability to attach file system paths or devices to any instance as well as tweak the security features on any instance. +UNIXソケットを介したIncusへのローカルアクセスは、常にIncusへのフルアクセスを許可します。 +これは、任意のインスタンス上のセキュリティ機能を変更できる能力に加えて、任意のインスタンスにファイルシステムパスやデバイスをアタッチする能力を含みます。 -Therefore, you should only give such access to users who you'd trust with root access to your system. +したがって、あなたのシステムへのルートアクセスを信頼できるユーザーにのみ、このようなアクセスを与えるべきです。 -## Support and community +## サポートとコミュニティ -The following channels are available for you to interact with the Incus community. +Incusコミュニティと交流するために以下のチャンネルが用意されています。 -### Bug reports +### バグレポート -You can file bug reports and feature requests at: [`https://github.com/lxc/incus/issues/new`](https://github.com/lxc/incus/issues/new) +バグレポートや機能要求は以下の場所で受け付けています。[`https://github.com/lxc/incus/issues/new`](https://github.com/lxc/incus/issues/new) -### Community support +### コミュニティによるサポート -Community support is handling at: [`https://discuss.linuxcontainers.org`](https://discuss.linuxcontainers.org) +コミュニテイによるサポートは[`https://discuss.linuxcontainers.org`](https://discuss.linuxcontainers.org)で取り扱います。 -### Commercial support +### 商用サポート -Commercial support is currently available from [Zabbly](https://zabbly.com) for users of their [Debian or Ubuntu packages](https://github.com/zabbly/incus). +[Debian or Ubuntu packages](https://github.com/zabbly/incus)の利用に関する商用サポートは現在[Zabbly](https://zabbly.com)から利用できます。 -## Documentation +## ドキュメント -The official documentation is available at: [`https://github.com/lxc/incus/tree/main/doc`](https://github.com/lxc/incus/tree/main/doc) +公式ドキュメントは[`https://github.com/lxc-jp/incus-ja/tree/main/doc`](https://github.com/lxc-jp/incus-ja/tree/main/doc)（原文：[`https://github.com/lxc/incus/tree/main/doc`](https://github.com/lxc/incus/tree/main/doc)）にあります。 -## Contributing +## コントリビュート -Fixes and new features are greatly appreciated. Make sure to read our [contributing guidelines](CONTRIBUTING.md) first! +修正や新機能の提供は大歓迎です。まずは、[コントリビュートガイド](CONTRIBUTING.md)をお読みください！ diff --git a/SECURITY.md b/SECURITY.md index fa0e866a3f5..a390c903167 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -1,34 +1,29 @@ -# Security policy +# セキュリティーポリシー -## Supported versions +## サポートされるバージョン -Incus has two types of releases: +Incus には 2 種類のリリースがあります: -- Feature releases -- LTS releases +- 機能リリース +- LTS （長期サポート）リリース -For feature releases, only the latest one is supported, and we usually -don't do point releases. Instead, users are expected to wait until the -next release. +機能リリースは、最新の 1 つのみがサポートされ、通常ポイントリリースは行いません。 +代わりにユーザーは次のリリースを待つことが期待されます。 -For LTS releases, we do periodic bugfix releases that include an -accumulation of bugfixes from the feature releases. Such bugfix releases -do not include new features. +長期リリースは、機能リリースからの積み重なったバグ修正を含む定期的なバグ修正リリースを行います。 +このバグ修正リリースは新機能は含みません。 -## What qualifies as a security issue +## セキュリティー問題として認められるもの -We don't consider privileged containers to be root safe, so any exploit -allowing someone to escape them will not qualify as a security issue. -This doesn't mean that we're not interested in preventing such escapes, -but we simply do not consider such containers to be root safe. +私たちは、特権コンテナがルートセーフであるとは考えていません。したがって、誰かが特権コンテナから脱出できるようなエクスプロイトは、セキュリティー上の問題とはみなされません。 +これは、そのような脱出を防ぐことに興味がないということではなく、単にそのようなコンテナがルートセーフであるとは考えていないということです。 -Unprivileged container escapes are certainly something we'd consider a -security issue, especially if somehow facilitated by Incus. +非特権コンテナのエスケープは確かに私たちがセキュリティー問題と考えるもので、特に Incus によって促進されている場合はそうです。 -## Reporting security issues +## 脆弱性の報告 -Security issues can be reported by e-mail to security@linuxcontainers.org. -Alternatively security issues can also be reported through Github at: https://github.com/lxc/incus/security/advisories/new +セキュリティーの問題は、security@linuxcontainers.org へ e-mail を送ることで報告できます。 +代わりに GitHub で https://github.com/lxc/incus/security/advisories/new に報告することもできます。 diff --git a/client/incus.go b/client/incus.go index 77b7efd45ca..f8b82985350 100644 --- a/client/incus.go +++ b/client/incus.go @@ -197,7 +197,7 @@ func (r *ProtocolIncus) RawWebsocket(path string) (*websocket.Conn, error) { // RawOperation allows direct querying of an Incus API endpoint returning // background operations. func (r *ProtocolIncus) RawOperation(method string, path string, data any, ETag string) (Operation, string, error) { - return r.queryOperation(method, path, data, ETag) + return r.queryOperation(method, path, data, ETag, true) } // Internal functions. @@ -363,12 +363,14 @@ func (r *ProtocolIncus) queryStruct(method string, path string, data any, ETag s } // queryOperation sends a query to the Incus server and then converts the response metadata into an Operation object. -// It sets up an early event listener, performs the query, processes the response, and manages the lifecycle of the event listener. -func (r *ProtocolIncus) queryOperation(method string, path string, data any, ETag string) (Operation, string, error) { - // Attempt to setup an early event listener - listener, err := r.GetEvents() - if err != nil { - listener = nil +// If useEventListener is true it will set up an early event listener and manage its lifecycle. +// If useEventListener is false, it will not set up an event listener and calls to Operation.Wait will use the operations API instead. +// In this case the returned Operation will error if the user calls Operation.AddHandler or Operation.RemoveHandler. +func (r *ProtocolIncus) queryOperation(method string, path string, data any, ETag string, useEventListener bool) (Operation, string, error) { + // Attempt to setup an early event listener if requested. + var listener *EventListener + if useEventListener { + listener, _ = r.GetEvents() } // Send the query @@ -393,10 +395,11 @@ func (r *ProtocolIncus) queryOperation(method string, path string, data any, ETa // Setup an Operation wrapper op := operation{ - Operation: *respOperation, - r: r, - listener: listener, - chActive: make(chan bool), + Operation: *respOperation, + r: r, + listener: listener, + chActive: make(chan bool), + skipListener: !useEventListener, } // Log the data diff --git a/client/incus_certificates.go b/client/incus_certificates.go index f90e3e52641..4a1dc00c0b4 100644 --- a/client/incus_certificates.go +++ b/client/incus_certificates.go @@ -97,7 +97,7 @@ func (r *ProtocolIncus) CreateCertificateToken(certificate api.CertificatesPost) } // Send the request - op, _, err := r.queryOperation("POST", "/certificates", certificate, "") + op, _, err := r.queryOperation("POST", "/certificates", certificate, "", true) if err != nil { return nil, err } diff --git a/client/incus_cluster.go b/client/incus_cluster.go index 03d6f3ebe4b..bda17517315 100644 --- a/client/incus_cluster.go +++ b/client/incus_cluster.go @@ -33,7 +33,7 @@ func (r *ProtocolIncus) UpdateCluster(cluster api.ClusterPut, ETag string) (Oper } } - op, _, err := r.queryOperation("PUT", "/cluster", cluster, "") + op, _, err := r.queryOperation("PUT", "/cluster", cluster, "", true) if err != nil { return nil, err } @@ -150,7 +150,7 @@ func (r *ProtocolIncus) CreateClusterMember(member api.ClusterMembersPost) (Oper return nil, fmt.Errorf("The server is missing the required \"clustering_join_token\" API extension") } - op, _, err := r.queryOperation("POST", "/cluster/members", member, "") + op, _, err := r.queryOperation("POST", "/cluster/members", member, "", true) if err != nil { return nil, err } @@ -195,7 +195,7 @@ func (r *ProtocolIncus) UpdateClusterMemberState(name string, state api.ClusterM return nil, fmt.Errorf("The server is missing the required \"clustering_evacuation\" API extension") } - op, _, err := r.queryOperation("POST", fmt.Sprintf("/cluster/members/%s/state", name), state, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/cluster/members/%s/state", name), state, "", true) if err != nil { return nil, err } diff --git a/client/incus_images.go b/client/incus_images.go index d12747d2e1b..c94bb84b17d 100644 --- a/client/incus_images.go +++ b/client/incus_images.go @@ -394,7 +394,7 @@ func (r *ProtocolIncus) CreateImage(image api.ImagesPost, args *ImageCreateArgs) // Send the JSON based request if args == nil { - op, _, err := r.queryOperation("POST", "/images", image, "") + op, _, err := r.queryOperation("POST", "/images", image, "", true) if err != nil { return nil, err } @@ -917,7 +917,7 @@ func (r *ProtocolIncus) UpdateImage(fingerprint string, image api.ImagePut, ETag // DeleteImage requests that Incus removes an image from the store. func (r *ProtocolIncus) DeleteImage(fingerprint string) (Operation, error) { // Send the request - op, _, err := r.queryOperation("DELETE", fmt.Sprintf("/images/%s", url.PathEscape(fingerprint)), nil, "") + op, _, err := r.queryOperation("DELETE", fmt.Sprintf("/images/%s", url.PathEscape(fingerprint)), nil, "", true) if err != nil { return nil, err } @@ -932,7 +932,7 @@ func (r *ProtocolIncus) RefreshImage(fingerprint string) (Operation, error) { } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("/images/%s/refresh", url.PathEscape(fingerprint)), nil, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/images/%s/refresh", url.PathEscape(fingerprint)), nil, "", true) if err != nil { return nil, err } @@ -943,7 +943,7 @@ func (r *ProtocolIncus) RefreshImage(fingerprint string) (Operation, error) { // CreateImageSecret requests that Incus issues a temporary image secret. func (r *ProtocolIncus) CreateImageSecret(fingerprint string) (Operation, error) { // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("/images/%s/secret", url.PathEscape(fingerprint)), nil, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/images/%s/secret", url.PathEscape(fingerprint)), nil, "", true) if err != nil { return nil, err } @@ -1002,7 +1002,7 @@ func (r *ProtocolIncus) ExportImage(fingerprint string, image api.ImageExportPos } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("/images/%s/export", url.PathEscape(fingerprint)), &image, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/images/%s/export", url.PathEscape(fingerprint)), &image, "", true) if err != nil { return nil, err } diff --git a/client/incus_instances.go b/client/incus_instances.go index 60a903d1334..b29dd298afb 100644 --- a/client/incus_instances.go +++ b/client/incus_instances.go @@ -193,7 +193,7 @@ func (r *ProtocolIncus) UpdateInstances(state api.InstancesPut, ETag string) (Op } // Send the request - op, _, err := r.queryOperation("PUT", fmt.Sprintf("%s?%s", path, v.Encode()), state, ETag) + op, _, err := r.queryOperation("PUT", fmt.Sprintf("%s?%s", path, v.Encode()), state, ETag, true) if err != nil { return nil, err } @@ -209,7 +209,7 @@ func (r *ProtocolIncus) rebuildInstance(instanceName string, instance api.Instan } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/rebuild?project=%s", path, url.PathEscape(instanceName), r.project), instance, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/rebuild", path, url.PathEscape(instanceName)), instance, "", true) if err != nil { return nil, err } @@ -523,7 +523,7 @@ func (r *ProtocolIncus) CreateInstanceFromBackup(args InstanceBackupArgs) (Opera if args.PoolName == "" && args.Name == "" { // Send the request - op, _, err := r.queryOperation("POST", path, args.BackupFile, "") + op, _, err := r.queryOperation("POST", path, args.BackupFile, "", true) if err != nil { return nil, err } @@ -604,7 +604,7 @@ func (r *ProtocolIncus) CreateInstance(instance api.InstancesPost) (Operation, e } // Send the request - op, _, err := r.queryOperation("POST", path, instance, "") + op, _, err := r.queryOperation("POST", path, instance, "", true) if err != nil { return nil, err } @@ -943,7 +943,7 @@ func (r *ProtocolIncus) UpdateInstance(name string, instance api.InstancePut, ET } // Send the request - op, _, err := r.queryOperation("PUT", fmt.Sprintf("%s/%s", path, url.PathEscape(name)), instance, ETag) + op, _, err := r.queryOperation("PUT", fmt.Sprintf("%s/%s", path, url.PathEscape(name)), instance, ETag, true) if err != nil { return nil, err } @@ -964,7 +964,7 @@ func (r *ProtocolIncus) RenameInstance(name string, instance api.InstancePost) ( } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s", path, url.PathEscape(name)), instance, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s", path, url.PathEscape(name)), instance, "", true) if err != nil { return nil, err } @@ -1060,7 +1060,7 @@ func (r *ProtocolIncus) MigrateInstance(name string, instance api.InstancePost) } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s", path, url.PathEscape(name)), instance, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s", path, url.PathEscape(name)), instance, "", true) if err != nil { return nil, err } @@ -1076,7 +1076,7 @@ func (r *ProtocolIncus) DeleteInstance(name string) (Operation, error) { } // Send the request - op, _, err := r.queryOperation("DELETE", fmt.Sprintf("%s/%s", path, url.PathEscape(name)), nil, "") + op, _, err := r.queryOperation("DELETE", fmt.Sprintf("%s/%s", path, url.PathEscape(name)), nil, "", true) if err != nil { return nil, err } @@ -1112,7 +1112,8 @@ func (r *ProtocolIncus) ExecInstance(instanceName string, exec api.InstanceExecP } // Send the request - op, _, err := r.queryOperation("POST", uri, exec, "") + useEventListener := r.CheckExtension("operation_wait") != nil + op, _, err := r.queryOperation("POST", uri, exec, "", useEventListener) if err != nil { return nil, err } @@ -1210,8 +1211,8 @@ func (r *ProtocolIncus) ExecInstance(instanceName string, exec api.InstanceExecP // And attach stdin and stdout to it go func() { - ws.MirrorRead(context.Background(), conn, args.Stdin) - <-ws.MirrorWrite(context.Background(), conn, args.Stdout) + ws.MirrorRead(conn, args.Stdin) + <-ws.MirrorWrite(conn, args.Stdout) _ = conn.Close() if args.DataDone != nil { @@ -1236,7 +1237,7 @@ func (r *ProtocolIncus) ExecInstance(instanceName string, exec api.InstanceExecP } conns = append(conns, conn) - dones[0] = ws.MirrorRead(context.Background(), conn, args.Stdin) + dones[0] = ws.MirrorRead(conn, args.Stdin) } // Handle stdout @@ -1247,7 +1248,7 @@ func (r *ProtocolIncus) ExecInstance(instanceName string, exec api.InstanceExecP } conns = append(conns, conn) - dones[1] = ws.MirrorWrite(context.Background(), conn, args.Stdout) + dones[1] = ws.MirrorWrite(conn, args.Stdout) } // Handle stderr @@ -1258,7 +1259,7 @@ func (r *ProtocolIncus) ExecInstance(instanceName string, exec api.InstanceExecP } conns = append(conns, conn) - dones[2] = ws.MirrorWrite(context.Background(), conn, args.Stderr) + dones[2] = ws.MirrorWrite(conn, args.Stderr) } // Wait for everything to be done @@ -1681,7 +1682,7 @@ func (r *ProtocolIncus) CreateInstanceSnapshot(instanceName string, snapshot api } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/snapshots", path, url.PathEscape(instanceName)), snapshot, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/snapshots", path, url.PathEscape(instanceName)), snapshot, "", true) if err != nil { return nil, err } @@ -1928,7 +1929,7 @@ func (r *ProtocolIncus) RenameInstanceSnapshot(instanceName string, name string, } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/snapshots/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), instance, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/snapshots/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), instance, "", true) if err != nil { return nil, err } @@ -2004,7 +2005,7 @@ func (r *ProtocolIncus) MigrateInstanceSnapshot(instanceName string, name string } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/snapshots/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), instance, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/snapshots/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), instance, "", true) if err != nil { return nil, err } @@ -2020,7 +2021,7 @@ func (r *ProtocolIncus) DeleteInstanceSnapshot(instanceName string, name string) } // Send the request - op, _, err := r.queryOperation("DELETE", fmt.Sprintf("%s/%s/snapshots/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), nil, "") + op, _, err := r.queryOperation("DELETE", fmt.Sprintf("%s/%s/snapshots/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), nil, "", true) if err != nil { return nil, err } @@ -2040,7 +2041,7 @@ func (r *ProtocolIncus) UpdateInstanceSnapshot(instanceName string, name string, } // Send the request - op, _, err := r.queryOperation("PUT", fmt.Sprintf("%s/%s/snapshots/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), instance, ETag) + op, _, err := r.queryOperation("PUT", fmt.Sprintf("%s/%s/snapshots/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), instance, ETag, true) if err != nil { return nil, err } @@ -2082,7 +2083,7 @@ func (r *ProtocolIncus) UpdateInstanceState(name string, state api.InstanceState } // Send the request - op, _, err := r.queryOperation("PUT", fmt.Sprintf("%s/%s/state", path, url.PathEscape(name)), state, ETag) + op, _, err := r.queryOperation("PUT", fmt.Sprintf("%s/%s/state", path, url.PathEscape(name)), state, ETag, true) if err != nil { return nil, err } @@ -2405,7 +2406,8 @@ func (r *ProtocolIncus) ConsoleInstance(instanceName string, console api.Instanc } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/console", path, url.PathEscape(instanceName)), console, "") + useEventListener := r.CheckExtension("operation_wait") != nil + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/console", path, url.PathEscape(instanceName)), console, "", useEventListener) if err != nil { return nil, err } @@ -2461,7 +2463,7 @@ func (r *ProtocolIncus) ConsoleInstance(instanceName string, console api.Instanc // And attach stdin and stdout to it go func() { - _, writeDone := ws.Mirror(context.Background(), conn, args.Terminal) + _, writeDone := ws.Mirror(conn, args.Terminal) <-writeDone _ = conn.Close() }() @@ -2493,7 +2495,7 @@ func (r *ProtocolIncus) ConsoleInstanceDynamic(instanceName string, console api. } // Send the request. - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/console", path, url.PathEscape(instanceName)), console, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/console", path, url.PathEscape(instanceName)), console, "", true) if err != nil { return nil, nil, err } @@ -2548,7 +2550,7 @@ func (r *ProtocolIncus) ConsoleInstanceDynamic(instanceName string, console api. } // Attach reader/writer. - _, writeDone := ws.Mirror(context.Background(), conn, rwc) + _, writeDone := ws.Mirror(conn, rwc) <-writeDone _ = conn.Close() @@ -2699,7 +2701,7 @@ func (r *ProtocolIncus) CreateInstanceBackup(instanceName string, backup api.Ins } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/backups", path, url.PathEscape(instanceName)), backup, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/backups", path, url.PathEscape(instanceName)), backup, "", true) if err != nil { return nil, err } @@ -2719,7 +2721,7 @@ func (r *ProtocolIncus) RenameInstanceBackup(instanceName string, name string, b } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/backups/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), backup, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("%s/%s/backups/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), backup, "", true) if err != nil { return nil, err } @@ -2739,7 +2741,7 @@ func (r *ProtocolIncus) DeleteInstanceBackup(instanceName string, name string) ( } // Send the request - op, _, err := r.queryOperation("DELETE", fmt.Sprintf("%s/%s/backups/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), nil, "") + op, _, err := r.queryOperation("DELETE", fmt.Sprintf("%s/%s/backups/%s", path, url.PathEscape(instanceName), url.PathEscape(name)), nil, "", true) if err != nil { return nil, err } diff --git a/client/incus_operations.go b/client/incus_operations.go index a949ec54038..088b872a495 100644 --- a/client/incus_operations.go +++ b/client/incus_operations.go @@ -89,6 +89,14 @@ func (r *ProtocolIncus) GetOperation(uuid string) (*api.Operation, string, error func (r *ProtocolIncus) GetOperationWait(uuid string, timeout int) (*api.Operation, string, error) { op := api.Operation{} + // Unset the response header timeout so that the request does not time out. + transport, err := r.getUnderlyingHTTPTransport() + if err != nil { + return nil, "", err + } + + transport.ResponseHeaderTimeout = 0 + // Fetch the raw value etag, err := r.queryStruct("GET", fmt.Sprintf("/operations/%s/wait?timeout=%d", url.PathEscape(uuid), timeout), nil, "", &op) if err != nil { diff --git a/client/incus_projects.go b/client/incus_projects.go index a75683dd9bb..86e68146b73 100644 --- a/client/incus_projects.go +++ b/client/incus_projects.go @@ -115,7 +115,7 @@ func (r *ProtocolIncus) RenameProject(name string, project api.ProjectPost) (Ope } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("/projects/%s", url.PathEscape(name)), project, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/projects/%s", url.PathEscape(name)), project, "", true) if err != nil { return nil, err } diff --git a/client/incus_storage_volumes.go b/client/incus_storage_volumes.go index dc12590e6b0..3c959ff2787 100644 --- a/client/incus_storage_volumes.go +++ b/client/incus_storage_volumes.go @@ -231,7 +231,7 @@ func (r *ProtocolIncus) CreateStoragePoolVolumeSnapshot(pool string, volumeType url.PathEscape(pool), url.PathEscape(volumeType), url.PathEscape(volumeName)) - op, _, err := r.queryOperation("POST", path, snapshot, "") + op, _, err := r.queryOperation("POST", path, snapshot, "", true) if err != nil { return nil, err } @@ -308,7 +308,7 @@ func (r *ProtocolIncus) RenameStoragePoolVolumeSnapshot(pool string, volumeType path := fmt.Sprintf("/storage-pools/%s/volumes/%s/%s/snapshots/%s", url.PathEscape(pool), url.PathEscape(volumeType), url.PathEscape(volumeName), url.PathEscape(snapshotName)) // Send the request - op, _, err := r.queryOperation("POST", path, snapshot, "") + op, _, err := r.queryOperation("POST", path, snapshot, "", true) if err != nil { return nil, err } @@ -327,7 +327,7 @@ func (r *ProtocolIncus) DeleteStoragePoolVolumeSnapshot(pool string, volumeType "/storage-pools/%s/volumes/%s/%s/snapshots/%s", url.PathEscape(pool), url.PathEscape(volumeType), url.PathEscape(volumeName), url.PathEscape(snapshotName)) - op, _, err := r.queryOperation("DELETE", path, nil, "") + op, _, err := r.queryOperation("DELETE", path, nil, "", true) if err != nil { return nil, err } @@ -343,7 +343,7 @@ func (r *ProtocolIncus) UpdateStoragePoolVolumeSnapshot(pool string, volumeType // Send the request path := fmt.Sprintf("/storage-pools/%s/volumes/%s/%s/snapshots/%s", url.PathEscape(pool), url.PathEscape(volumeType), url.PathEscape(volumeName), url.PathEscape(snapshotName)) - _, _, err := r.queryOperation("PUT", path, volume, ETag) + _, _, err := r.queryOperation("PUT", path, volume, ETag, true) if err != nil { return err } @@ -386,7 +386,7 @@ func (r *ProtocolIncus) MigrateStoragePoolVolume(pool string, volume api.Storage } // Send the request - op, _, err := r.queryOperation("POST", path, req, "") + op, _, err := r.queryOperation("POST", path, req, "", true) if err != nil { return nil, err } @@ -475,7 +475,7 @@ func (r *ProtocolIncus) tryCreateStoragePoolVolume(pool string, req api.StorageV // Send the request path := fmt.Sprintf("/storage-pools/%s/volumes/%s", url.PathEscape(pool), url.PathEscape(req.Type)) - top, _, err := r.queryOperation("POST", path, req, "") + top, _, err := r.queryOperation("POST", path, req, "", true) if err != nil { errors = append(errors, remoteOperationResult{URL: serverURL, Error: err}) continue @@ -567,7 +567,7 @@ func (r *ProtocolIncus) CopyStoragePoolVolume(pool string, source InstanceServer } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("/storage-pools/%s/volumes/%s", url.PathEscape(pool), url.PathEscape(volume.Type)), req, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/storage-pools/%s/volumes/%s", url.PathEscape(pool), url.PathEscape(volume.Type)), req, "", true) if err != nil { return nil, err } @@ -616,7 +616,7 @@ func (r *ProtocolIncus) CopyStoragePoolVolume(pool string, source InstanceServer path := fmt.Sprintf("/storage-pools/%s/volumes/%s", url.PathEscape(pool), url.PathEscape(volume.Type)) // Send the request - op, _, err := r.queryOperation("POST", path, req, "") + op, _, err := r.queryOperation("POST", path, req, "", true) if err != nil { return nil, err } @@ -668,7 +668,7 @@ func (r *ProtocolIncus) CopyStoragePoolVolume(pool string, source InstanceServer path := fmt.Sprintf("/storage-pools/%s/volumes/%s", url.PathEscape(pool), url.PathEscape(volume.Type)) // Send the request - targetOp, _, err := r.queryOperation("POST", path, req, "") + targetOp, _, err := r.queryOperation("POST", path, req, "", true) if err != nil { return nil, err } @@ -736,7 +736,7 @@ func (r *ProtocolIncus) MoveStoragePoolVolume(pool string, source InstanceServer } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("/storage-pools/%s/volumes/%s/%s", url.PathEscape(sourcePool), url.PathEscape(volume.Type), volume.Name), req, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/storage-pools/%s/volumes/%s/%s", url.PathEscape(sourcePool), url.PathEscape(volume.Type), volume.Name), req, "", true) if err != nil { return nil, err } @@ -866,7 +866,7 @@ func (r *ProtocolIncus) CreateStoragePoolVolumeBackup(pool string, volName strin } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("/storage-pools/%s/volumes/custom/%s/backups", url.PathEscape(pool), url.PathEscape(volName)), backup, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/storage-pools/%s/volumes/custom/%s/backups", url.PathEscape(pool), url.PathEscape(volName)), backup, "", true) if err != nil { return nil, err } @@ -881,7 +881,7 @@ func (r *ProtocolIncus) RenameStoragePoolVolumeBackup(pool string, volName strin } // Send the request - op, _, err := r.queryOperation("POST", fmt.Sprintf("/storage-pools/%s/volumes/custom/%s/backups/%s", url.PathEscape(pool), url.PathEscape(volName), url.PathEscape(name)), backup, "") + op, _, err := r.queryOperation("POST", fmt.Sprintf("/storage-pools/%s/volumes/custom/%s/backups/%s", url.PathEscape(pool), url.PathEscape(volName), url.PathEscape(name)), backup, "", true) if err != nil { return nil, err } @@ -896,7 +896,7 @@ func (r *ProtocolIncus) DeleteStoragePoolVolumeBackup(pool string, volName strin } // Send the request - op, _, err := r.queryOperation("DELETE", fmt.Sprintf("/storage-pools/%s/volumes/custom/%s/backups/%s", url.PathEscape(pool), url.PathEscape(volName), url.PathEscape(name)), nil, "") + op, _, err := r.queryOperation("DELETE", fmt.Sprintf("/storage-pools/%s/volumes/custom/%s/backups/%s", url.PathEscape(pool), url.PathEscape(volName), url.PathEscape(name)), nil, "", true) if err != nil { return nil, err } diff --git a/client/operations.go b/client/operations.go index a71bbd4a073..8046ef5c3da 100644 --- a/client/operations.go +++ b/client/operations.go @@ -6,6 +6,7 @@ import ( "errors" "fmt" "sync" + "time" "github.com/gorilla/websocket" @@ -20,12 +21,17 @@ type operation struct { listener *EventListener handlerReady bool handlerLock sync.Mutex + skipListener bool chActive chan bool } // AddHandler adds a function to be called whenever an event is received. func (op *operation) AddHandler(function func(api.Operation)) (*EventTarget, error) { + if op.skipListener { + return nil, fmt.Errorf("Cannot add handler, client operation does not support event listeners") + } + // Make sure we have a listener setup err := op.setupListener() if err != nil { @@ -77,6 +83,10 @@ func (op *operation) GetWebsocket(secret string) (*websocket.Conn, error) { // RemoveHandler removes a function to be called whenever an event is received. func (op *operation) RemoveHandler(target *EventTarget) error { + if op.skipListener { + return fmt.Errorf("Cannot remove handler, client operation does not support event listeners") + } + // Make sure we're not racing with ourselves op.handlerLock.Lock() defer op.handlerLock.Unlock() @@ -110,6 +120,27 @@ func (op *operation) Wait() error { // WaitContext lets you wait until the operation reaches a final state with context.Context. func (op *operation) WaitContext(ctx context.Context) error { + if op.skipListener { + timeout := -1 + deadline, ok := ctx.Deadline() + if ok { + timeout = int(time.Until(deadline).Seconds()) + } + + opAPI, _, err := op.r.GetOperationWait(op.ID, timeout) + if err != nil { + return err + } + + op.Operation = *opAPI + + if opAPI.Err != "" { + return errors.New(opAPI.Err) + } + + return nil + } + op.handlerLock.Lock() // Check if not done already if op.StatusCode.IsFinal() { @@ -148,6 +179,10 @@ func (op *operation) WaitContext(ctx context.Context) error { // It adds handlers to process events, monitors the listener for completion or errors, // and triggers a manual refresh of the operation's state to prevent race conditions. func (op *operation) setupListener() error { + if op.skipListener { + return fmt.Errorf("Cannot set up event listener, client operation does not support event listeners") + } + // Make sure we're not racing with ourselves op.handlerLock.Lock() defer op.handlerLock.Unlock() diff --git a/cmd/incus-agent/api_1.0.go b/cmd/incus-agent/api_1.0.go index e7c881018ed..effb82b51f6 100644 --- a/cmd/incus-agent/api_1.0.go +++ b/cmd/incus-agent/api_1.0.go @@ -35,6 +35,7 @@ var api10 = []APIEndpoint{ operationsCmd, operationCmd, operationWebsocket, + operationWait, sftpCmd, stateCmd, } @@ -193,8 +194,13 @@ func getClient(CID uint32, port int, serverCertificate string) (*http.Client, er } func startHTTPServer(d *Daemon, debug bool) error { - // Setup the listener on VM's context ID for inbound connections from the host. - l, err := vsock.Listen(ports.HTTPSDefaultPort, nil) + const CIDAny uint32 = 4294967295 // Equivalent to VMADDR_CID_ANY. + + // Setup the listener on wildcard CID for inbound connections from LXD. + // We use the VMADDR_CID_ANY CID so that if the VM's CID changes in the future the listener still works. + // A CID change can occur when restoring a stateful VM that was previously using one CID but is + // subsequently restored using a different one. + l, err := vsock.ListenContextID(CIDAny, ports.HTTPSDefaultPort, nil) if err != nil { return fmt.Errorf("Failed to listen on vsock: %w", err) } diff --git a/cmd/incus-agent/daemon.go b/cmd/incus-agent/daemon.go index 2e160bdcfb8..339fd83a82c 100644 --- a/cmd/incus-agent/daemon.go +++ b/cmd/incus-agent/daemon.go @@ -4,7 +4,6 @@ import ( "sync" "github.com/lxc/incus/internal/server/events" - "github.com/lxc/incus/internal/server/vsock" ) // A Daemon can respond to requests from a shared client. @@ -17,8 +16,6 @@ type Daemon struct { serverPort uint32 serverCertificate string - localCID uint32 - // The channel which is used to indicate that the agent was able to connect to the host. chConnected chan struct{} @@ -31,11 +28,8 @@ type Daemon struct { func newDaemon(debug, verbose bool) *Daemon { hostEvents := events.NewServer(debug, verbose, nil) - cid, _ := vsock.ContextID() - return &Daemon{ events: hostEvents, chConnected: make(chan struct{}), - localCID: cid, } } diff --git a/cmd/incus-agent/exec.go b/cmd/incus-agent/exec.go index 10d658ee903..311e505ce9c 100644 --- a/cmd/incus-agent/exec.go +++ b/cmd/incus-agent/exec.go @@ -285,12 +285,12 @@ func (s *execWs) Do(op *operations.Operation) error { stderr = ttys[execWSStderr] } - attachedChildIsDead := make(chan struct{}) + waitAttachedChildIsDead, markAttachedChildIsDead := context.WithCancel(context.Background()) var wgEOF sync.WaitGroup finisher := func(cmdResult int, cmdErr error) error { - // Close this before closing the control connection so control handler can detect command ending. - close(attachedChildIsDead) + // Cancel this before closing the control connection so control handler can detect command ending. + markAttachedChildIsDead() for _, tty := range ttys { _ = tty.Close() @@ -387,10 +387,8 @@ func (s *execWs) Do(op *operations.Operation) error { mt, r, err := conn.NextReader() if err != nil || mt == websocket.CloseMessage { // Check if command process has finished normally, if so, no need to kill it. - select { - case <-attachedChildIsDead: + if waitAttachedChildIsDead.Err() != nil { return - default: } if mt == websocket.CloseMessage { @@ -412,10 +410,8 @@ func (s *execWs) Do(op *operations.Operation) error { buf, err := io.ReadAll(r) if err != nil { // Check if command process has finished normally, if so, no need to kill it. - select { - case <-attachedChildIsDead: + if waitAttachedChildIsDead.Err() != nil { return - default: } l.Warn("Failed reading control websocket message, killing command", logger.Ctx{"err": err}) @@ -472,7 +468,7 @@ func (s *execWs) Do(op *operations.Operation) error { conn := s.conns[0] s.connsLock.Unlock() - readDone, writeDone := ws.Mirror(context.Background(), conn, ptys[0]) + readDone, writeDone := ws.Mirror(conn, linux.NewExecWrapper(waitAttachedChildIsDead, ptys[0])) <-readDone <-writeDone @@ -490,14 +486,14 @@ func (s *execWs) Do(op *operations.Operation) error { conn := s.conns[i] s.connsLock.Unlock() - <-ws.MirrorWrite(context.Background(), conn, ttys[i]) + <-ws.MirrorWrite(conn, ttys[i]) _ = ttys[i].Close() } else { s.connsLock.Lock() conn := s.conns[i] s.connsLock.Unlock() - <-ws.MirrorRead(context.Background(), conn, ptys[i]) + <-ws.MirrorRead(conn, ptys[i]) _ = ptys[i].Close() wgEOF.Done() } diff --git a/cmd/incus-agent/main_agent.go b/cmd/incus-agent/main_agent.go index eccd6c90689..699fdd4a57c 100644 --- a/cmd/incus-agent/main_agent.go +++ b/cmd/incus-agent/main_agent.go @@ -17,7 +17,6 @@ import ( "github.com/lxc/incus/internal/linux" "github.com/lxc/incus/internal/server/instance/instancetype" - "github.com/lxc/incus/internal/server/vsock" "github.com/lxc/incus/shared/logger" "github.com/lxc/incus/shared/subprocess" "github.com/lxc/incus/shared/util" @@ -136,31 +135,6 @@ func (c *cmdAgent) Run(cmd *cobra.Command, args []string) error { return fmt.Errorf("Failed to start HTTP server: %w", err) } - // Check context ID periodically, and restart the HTTP server if needed. - go func() { - for range time.Tick(30 * time.Second) { - cid, err := vsock.ContextID() - if err != nil { - continue - } - - if d.localCID == cid { - continue - } - - // Restart server - servers["http"].Close() - - err = startHTTPServer(d, c.global.flagLogDebug) - if err != nil { - errChan <- err - } - - // Update context ID. - d.localCID = cid - } - }() - // Check whether we should start the DevIncus server in the early setup. This way, /dev/incus/sock // will be available for any systemd services starting after the agent. if util.PathExists("agent.conf") { diff --git a/cmd/incus-agent/operations.go b/cmd/incus-agent/operations.go index 884f404461d..0384ace8eef 100644 --- a/cmd/incus-agent/operations.go +++ b/cmd/incus-agent/operations.go @@ -1,11 +1,14 @@ package main import ( + "context" "fmt" "log" "net/http" "net/url" + "strconv" "strings" + "time" "github.com/gorilla/mux" @@ -35,6 +38,11 @@ var operationWebsocket = APIEndpoint{ Get: APIEndpointAction{Handler: operationWebsocketGet}, } +var operationWait = APIEndpoint{ + Path: "operations/{id}/wait", + Get: APIEndpointAction{Handler: operationWaitGet}, +} + func operationDelete(d *Daemon, r *http.Request) response.Response { id, err := url.PathUnescape(mux.Vars(r)["id"]) if err != nil { @@ -158,3 +166,45 @@ func operationWebsocketGet(d *Daemon, r *http.Request) response.Response { return operations.OperationWebSocket(r, op) } + +func operationWaitGet(d *Daemon, r *http.Request) response.Response { + id, err := url.PathUnescape(mux.Vars(r)["id"]) + if err != nil { + return response.InternalError(fmt.Errorf("Failed to extract operation ID from URL: %w", err)) + } + + timeoutSecs := -1 + if r.FormValue("timeout") != "" { + timeoutSecs, err = strconv.Atoi(r.FormValue("timeout")) + if err != nil { + return response.InternalError(fmt.Errorf("Failed to extract operation wait timeout from URL: %w", err)) + } + } + + var ctx context.Context + var cancel context.CancelFunc + if timeoutSecs > -1 { + ctx, cancel = context.WithDeadline(r.Context(), time.Now().Add(time.Second*time.Duration(timeoutSecs))) + } else { + ctx, cancel = context.WithCancel(r.Context()) + } + + defer cancel() + + op, err := operations.OperationGetInternal(id) + if err != nil { + return response.NotFound(err) + } + + err = op.Wait(ctx) + if err != nil { + return response.SmartError(err) + } + + _, opAPI, err := op.Render() + if err != nil { + return response.SmartError(err) + } + + return response.SyncResponse(true, opAPI) +} diff --git a/cmd/incus-migrate/transfer.go b/cmd/incus-migrate/transfer.go index dec4b85f945..6b073651280 100644 --- a/cmd/incus-migrate/transfer.go +++ b/cmd/incus-migrate/transfer.go @@ -31,7 +31,7 @@ func rsyncSend(ctx context.Context, conn *websocket.Conn, path string, rsyncArgs defer func() { _ = dataSocket.Close() }() } - readDone, writeDone := ws.Mirror(ctx, conn, dataSocket) + readDone, writeDone := ws.Mirror(conn, dataSocket) <-writeDone _ = dataSocket.Close() diff --git a/cmd/incus-user/server.go b/cmd/incus-user/server.go index 1222db7c01f..d7078e049d5 100644 --- a/cmd/incus-user/server.go +++ b/cmd/incus-user/server.go @@ -4,6 +4,7 @@ import ( "encoding/base64" "fmt" "os" + "path/filepath" "strings" "github.com/lxc/incus/client" @@ -168,7 +169,7 @@ func serverSetupUser(uid uint32) error { revert.Add(func() { _ = os.RemoveAll(userPath) }) // Generate certificate. - err = localtls.FindOrGenCert(internalUtil.VarPath("users", userPath, "client.crt"), internalUtil.VarPath("users", userPath, "client.key"), true, false) + err = localtls.FindOrGenCert(filepath.Join(userPath, "client.crt"), filepath.Join(userPath, "client.key"), true, false) if err != nil { return fmt.Errorf("Failed to generate user certificate: %w", err) } @@ -219,7 +220,7 @@ func serverSetupUser(uid uint32) error { } // Parse the certificate. - x509Cert, err := localtls.ReadCert(internalUtil.VarPath("users", userPath, "client.crt")) + x509Cert, err := localtls.ReadCert(filepath.Join(userPath, "client.crt")) if err != nil { return fmt.Errorf("Unable to read user certificate: %w", err) } diff --git a/cmd/incus/admin_cluster.go b/cmd/incus/admin_cluster.go index 5d57aad59de..6be77db2fb3 100644 --- a/cmd/incus/admin_cluster.go +++ b/cmd/incus/admin_cluster.go @@ -30,12 +30,14 @@ func (c *cmdAdminCluster) Command() *cobra.Command { } func (c *cmdAdminCluster) Run(cmd *cobra.Command, args []string) { + env := getEnviron() path, _ := exec.LookPath("incusd") if path == "" { if util.PathExists("/usr/lib/incus/incusd") { path = "/usr/lib/incus/incusd" } else if util.PathExists("/opt/incus/bin/incusd") { path = "/opt/incus/bin/incusd" + env = append(env, "LD_LIBRARY_PATH=/opt/incus/lib/") } } @@ -47,5 +49,5 @@ You can invoke it through "incusd cluster".`)) os.Exit(1) } - _ = doExec(path, []string{"incusd", "cluster"}, getEnviron()) + _ = doExec(path, append([]string{"incusd", "cluster"}, args...), env) } diff --git a/cmd/incus/delete.go b/cmd/incus/delete.go index 93a93ac6e0a..7aa393e0318 100644 --- a/cmd/incus/delete.go +++ b/cmd/incus/delete.go @@ -116,7 +116,7 @@ func (c *cmdDelete) Run(cmd *cobra.Command, args []string) error { } if ct.Ephemeral { - return nil + continue } } diff --git a/cmd/incus/storage_volume.go b/cmd/incus/storage_volume.go index c97dd8dac16..af37cb28da6 100644 --- a/cmd/incus/storage_volume.go +++ b/cmd/incus/storage_volume.go @@ -1644,8 +1644,9 @@ func (c *cmdStorageVolumeMove) Run(cmd *cobra.Command, args []string) error { return fmt.Errorf(i18n.G("No storage pool for target volume specified")) } - // Rename volume if both remotes and pools of source and target are equal. - if srcRemote == dstRemote && srcVolPool == dstVolPool { + // Rename volume if both remotes and pools of source and target are equal + // and no destination cluster member name is set. + if srcRemote == dstRemote && srcVolPool == dstVolPool && c.storageVolume.flagDestinationTarget == "" { var args []string if srcRemote != "" { diff --git a/cmd/incusd/api_cluster.go b/cmd/incusd/api_cluster.go index 6ce4bbe48a6..6b5306fbf7e 100644 --- a/cmd/incusd/api_cluster.go +++ b/cmd/incusd/api_cluster.go @@ -21,6 +21,7 @@ import ( internalInstance "github.com/lxc/incus/internal/instance" "github.com/lxc/incus/internal/revert" "github.com/lxc/incus/internal/server/acme" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/cluster" clusterConfig "github.com/lxc/incus/internal/server/cluster/config" clusterRequest "github.com/lxc/incus/internal/server/cluster/request" @@ -675,7 +676,7 @@ func clusterPutJoin(d *Daemon, r *http.Request, req api.ClusterPut) response.Res for _, trustedCert := range trustedCerts { if trustedCert.Type == api.CertificateTypeServer { - dbType, err := dbCluster.CertificateAPITypeToDBType(trustedCert.Type) + dbType, err := certificate.FromAPIType(trustedCert.Type) if err != nil { return err } diff --git a/cmd/incusd/api_metrics.go b/cmd/incusd/api_metrics.go index ef852abc5a9..a081d8029d5 100644 --- a/cmd/incusd/api_metrics.go +++ b/cmd/incusd/api_metrics.go @@ -166,9 +166,9 @@ func metricsGet(d *Daemon, r *http.Request) response.Response { lockCtx, lockCtxCancel := context.WithTimeout(r.Context(), cacheDuration) defer lockCtxCancel() - unlock := locking.Lock(lockCtx, "metricsGet") - if unlock == nil { - return response.SmartError(api.StatusErrorf(http.StatusLocked, "Metrics are currently being built by another request")) + unlock, err := locking.Lock(lockCtx, "metricsGet") + if err != nil { + return response.SmartError(api.StatusErrorf(http.StatusLocked, "Metrics are currently being built by another request: %s", err)) } defer unlock() diff --git a/cmd/incusd/certificates.go b/cmd/incusd/certificates.go index a6224c1171b..58b5f1a9792 100644 --- a/cmd/incusd/certificates.go +++ b/cmd/incusd/certificates.go @@ -11,13 +11,13 @@ import ( "net" "net/http" "net/url" - "sync" "time" "github.com/gorilla/mux" "github.com/lxc/incus/client" internalInstance "github.com/lxc/incus/internal/instance" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/cluster" clusterRequest "github.com/lxc/incus/internal/server/cluster/request" "github.com/lxc/incus/internal/server/db" @@ -37,12 +37,6 @@ import ( localtls "github.com/lxc/incus/shared/tls" ) -type certificateCache struct { - Certificates map[dbCluster.CertificateType]map[string]x509.Certificate - Projects map[string][]string - Lock sync.Mutex -} - var certificatesCmd = APIEndpoint{ Path: "certificates", @@ -189,7 +183,7 @@ func updateCertificateCache(d *Daemon) { logger.Debug("Refreshing trusted certificate cache") - newCerts := map[dbCluster.CertificateType]map[string]x509.Certificate{} + newCerts := map[certificate.Type]map[string]x509.Certificate{} newProjects := map[string][]string{} var certs []*api.Certificate @@ -241,7 +235,7 @@ func updateCertificateCache(d *Daemon) { } // Add server certs to list of certificates to store in local database to allow cluster restart. - if dbCert.Type == dbCluster.CertificateTypeServer { + if dbCert.Type == certificate.TypeServer { localCerts = append(localCerts, dbCert) } } @@ -256,17 +250,14 @@ func updateCertificateCache(d *Daemon) { // continue functioning, and hopefully the write will succeed on next update. } - d.clientCerts.Lock.Lock() - d.clientCerts.Certificates = newCerts - d.clientCerts.Projects = newProjects - d.clientCerts.Lock.Unlock() + d.clientCerts.SetCertificatesAndProjects(newCerts, newProjects) } // updateCertificateCacheFromLocal loads trusted server certificates from local database into memory. func updateCertificateCacheFromLocal(d *Daemon) error { logger.Debug("Refreshing local trusted certificate cache") - newCerts := map[dbCluster.CertificateType]map[string]x509.Certificate{} + newCerts := map[certificate.Type]map[string]x509.Certificate{} var dbCerts []dbCluster.Certificate var err error @@ -300,9 +291,7 @@ func updateCertificateCacheFromLocal(d *Daemon) error { newCerts[dbCert.Type][localtls.CertFingerprint(cert)] = *cert } - d.clientCerts.Lock.Lock() - d.clientCerts.Certificates = newCerts - d.clientCerts.Lock.Unlock() + d.clientCerts.SetCertificates(newCerts) return nil } @@ -582,7 +571,7 @@ func certificatesPost(d *Daemon, r *http.Request) response.Response { } } - dbReqType, err := dbCluster.CertificateAPITypeToDBType(req.Type) + dbReqType, err := certificate.FromAPIType(req.Type) if err != nil { return response.BadRequest(err) } @@ -945,7 +934,7 @@ func doCertificateUpdate(d *Daemon, dbInfo api.Certificate, req api.CertificateP s := d.State() if clientType == clusterRequest.ClientTypeNormal { - reqDBType, err := dbCluster.CertificateAPITypeToDBType(req.Type) + reqDBType, err := certificate.FromAPIType(req.Type) if err != nil { return response.BadRequest(err) } diff --git a/cmd/incusd/daemon.go b/cmd/incusd/daemon.go index b0fdd04e3a1..cac8a25e969 100644 --- a/cmd/incusd/daemon.go +++ b/cmd/incusd/daemon.go @@ -33,6 +33,7 @@ import ( "github.com/lxc/incus/internal/server/auth" "github.com/lxc/incus/internal/server/auth/oidc" "github.com/lxc/incus/internal/server/bgp" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/cluster" clusterConfig "github.com/lxc/incus/internal/server/cluster/config" "github.com/lxc/incus/internal/server/daemon" @@ -76,7 +77,7 @@ import ( // A Daemon can respond to requests from a shared client. type Daemon struct { - clientCerts *certificateCache + clientCerts *certificate.Cache os *sys.OS db *db.DB firewall firewall.Firewall @@ -170,7 +171,7 @@ func newDaemon(config *DaemonConfig, os *sys.OS) *Daemon { shutdownCtx, shutdownCancel := context.WithCancel(context.Background()) d := &Daemon{ - clientCerts: &certificateCache{}, + clientCerts: &certificate.Cache{}, config: config, devIncusEvents: devIncusEvents, events: incusEvents, @@ -275,11 +276,8 @@ func (d *Daemon) checkTrustedClient(r *http.Request) error { } // getTrustedCertificates returns trusted certificates key on DB type and fingerprint. -func (d *Daemon) getTrustedCertificates() map[dbCluster.CertificateType]map[string]x509.Certificate { - d.clientCerts.Lock.Lock() - defer d.clientCerts.Lock.Unlock() - - return d.clientCerts.Certificates +func (d *Daemon) getTrustedCertificates() map[certificate.Type]map[string]x509.Certificate { + return d.clientCerts.GetCertificates() } // Authenticate validates an incoming http Request @@ -295,7 +293,7 @@ func (d *Daemon) Authenticate(w http.ResponseWriter, r *http.Request) (bool, str // Allow internal cluster traffic by checking against the trusted certfificates. if r.TLS != nil { for _, i := range r.TLS.PeerCertificates { - trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[dbCluster.CertificateTypeServer], d.endpoints.NetworkCert(), false) + trusted, fingerprint := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], d.endpoints.NetworkCert(), false) if trusted { return true, fingerprint, "cluster", nil } @@ -351,7 +349,7 @@ func (d *Daemon) Authenticate(w http.ResponseWriter, r *http.Request) (bool, str // Validate metrics certificates. if r.URL.Path == "/1.0/metrics" { for _, i := range r.TLS.PeerCertificates { - trusted, username := localUtil.CheckTrustState(*i, trustedCerts[dbCluster.CertificateTypeMetrics], d.endpoints.NetworkCert(), trustCACertificates) + trusted, username := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeMetrics], d.endpoints.NetworkCert(), trustCACertificates) if trusted { return true, username, "tls", nil } @@ -359,7 +357,7 @@ func (d *Daemon) Authenticate(w http.ResponseWriter, r *http.Request) (bool, str } for _, i := range r.TLS.PeerCertificates { - trusted, username := localUtil.CheckTrustState(*i, trustedCerts[dbCluster.CertificateTypeClient], d.endpoints.NetworkCert(), trustCACertificates) + trusted, username := localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeClient], d.endpoints.NetworkCert(), trustCACertificates) if trusted { return true, username, "tls", nil } @@ -494,9 +492,7 @@ func (d *Daemon) createCmd(restAPI *mux.Router, version string, c APIEndpoint) { // Regular TLS clients. if protocol == "tls" { - d.clientCerts.Lock.Lock() - certProjects := d.clientCerts.Projects - d.clientCerts.Lock.Unlock() + certProjects := d.clientCerts.GetProjects() // Check if we have restrictions on the key. if certProjects != nil { @@ -988,7 +984,8 @@ func (d *Daemon) init() error { } // Detect if clustered, but not yet upgraded to per-server client certificates. - if clustered && len(d.clientCerts.Certificates[dbCluster.CertificateTypeServer]) < 1 { + certificates := d.clientCerts.GetCertificates() + if clustered && len(certificates[certificate.TypeServer]) < 1 { // If the cluster has not yet upgraded to per-server client certificates (by running patch // patchClusteringServerCertTrust) then temporarily use the network (cluster) certificate as client // certificate, and cause us to trust it for use as client certificate from the other members. @@ -1184,6 +1181,30 @@ func (d *Daemon) init() error { version.UserAgentFeatures([]string{"cluster"}) } + // Load server name and config before patches run (so they can access them from d.State()). + err = d.db.Cluster.Transaction(d.shutdownCtx, func(ctx context.Context, tx *db.ClusterTx) error { + config, err := clusterConfig.Load(ctx, tx) + if err != nil { + return err + } + + // Get the local node (will be used if clustered). + serverName, err := tx.GetLocalNodeName(ctx) + if err != nil { + return err + } + + d.globalConfigMu.Lock() + d.serverName = serverName + d.globalConfig = config + d.globalConfigMu.Unlock() + + return nil + }) + if err != nil { + return err + } + // Mount the storage pools. logger.Infof("Initializing storage pools") err = storageStartup(d.State(), false) @@ -1216,13 +1237,7 @@ func (d *Daemon) init() error { return err } - // Get daemon configuration. - bgpAddress := d.localConfig.BGPAddress() - bgpRouterID := d.localConfig.BGPRouterID() - bgpASN := int64(0) - - dnsAddress := d.localConfig.DNSAddress() - + // Load server name and config after patches run (in case its been changed). err = d.db.Cluster.Transaction(d.shutdownCtx, func(ctx context.Context, tx *db.ClusterTx) error { config, err := clusterConfig.Load(ctx, tx) if err != nil { @@ -1246,6 +1261,12 @@ func (d *Daemon) init() error { return err } + // Get daemon configuration. + bgpAddress := d.localConfig.BGPAddress() + bgpRouterID := d.localConfig.BGPRouterID() + bgpASN := int64(0) + dnsAddress := d.localConfig.DNSAddress() + // Get specific config keys. d.globalConfigMu.Lock() bgpASN = d.globalConfig.BGPASN() diff --git a/cmd/incusd/daemon_images.go b/cmd/incusd/daemon_images.go index 6ef5f0230ff..ff968d3e725 100644 --- a/cmd/incusd/daemon_images.go +++ b/cmd/incusd/daemon_images.go @@ -50,7 +50,7 @@ type ImageDownloadArgs struct { } // imageOperationLock acquires a lock for operating on an image and returns the unlock function. -func imageOperationLock(fingerprint string) locking.UnlockFunc { +func imageOperationLock(fingerprint string) (locking.UnlockFunc, error) { l := logger.AddContext(logger.Ctx{"fingerprint": fingerprint}) l.Debug("Acquiring lock for image") defer l.Debug("Lock acquired for image") @@ -126,7 +126,11 @@ func ImageDownload(r *http.Request, s *state.State, op *operations.Operation, ar } // Ensure we are the only ones operating on this image. - unlock := imageOperationLock(fp) + unlock, err := imageOperationLock(fp) + if err != nil { + return nil, err + } + defer unlock() // If auto-update is on and we're being given the image by diff --git a/cmd/incusd/images.go b/cmd/incusd/images.go index de35ba21f0c..8749cc06ab3 100644 --- a/cmd/incusd/images.go +++ b/cmd/incusd/images.go @@ -2475,7 +2475,11 @@ func imageDelete(d *Daemon, r *http.Request) response.Response { do := func(op *operations.Operation) error { // Lock this operation to ensure that concurrent image operations don't conflict. // Other operations will wait for this one to finish. - unlock := imageOperationLock(imgInfo.Fingerprint) + unlock, err := imageOperationLock(imgInfo.Fingerprint) + if err != nil { + return err + } + defer unlock() // Check image still exists and another request hasn't removed it since we resolved the image diff --git a/cmd/incusd/instance.go b/cmd/incusd/instance.go index fbec8580e4a..51012b38eb5 100644 --- a/cmd/incusd/instance.go +++ b/cmd/incusd/instance.go @@ -91,7 +91,11 @@ func ensureImageIsLocallyAvailable(s *state.State, r *http.Request, img *api.Ima // time may also arrive at the conclusion that the image doesn't exist on this cluster member and then // think it needs to download the image and store the record in the database as well, which will lead to // duplicate record errors. - unlock := imageOperationLock(img.Fingerprint) + unlock, err := imageOperationLock(img.Fingerprint) + if err != nil { + return err + } + defer unlock() memberAddress, err := s.DB.Cluster.LocateImage(img.Fingerprint) @@ -734,7 +738,7 @@ func getSourceImageFromInstanceSource(ctx context.Context, s *state.State, tx *d } // instanceOperationLock acquires a lock for operating on an instance and returns the unlock function. -func instanceOperationLock(ctx context.Context, projectName string, instanceName string) locking.UnlockFunc { +func instanceOperationLock(ctx context.Context, projectName string, instanceName string) (locking.UnlockFunc, error) { l := logger.AddContext(logger.Ctx{"project": projectName, "instance": instanceName}) l.Debug("Acquiring lock for instance") defer l.Debug("Lock acquired for instance") diff --git a/cmd/incusd/instance_console.go b/cmd/incusd/instance_console.go index b81f286818e..a8e97d6500c 100644 --- a/cmd/incusd/instance_console.go +++ b/cmd/incusd/instance_console.go @@ -2,7 +2,6 @@ package main import ( "bytes" - "context" "encoding/json" "fmt" "io" @@ -174,7 +173,7 @@ func (s *consoleWs) connectVGA(op *operations.Operation, r *http.Request, w http defer l.Debug("Finished mirroring websocket to console") l.Debug("Started mirroring websocket") - readDone, writeDone := ws.Mirror(context.Background(), conn, console) + readDone, writeDone := ws.Mirror(conn, console) <-readDone l.Debug("Finished mirroring console to websocket") @@ -292,7 +291,7 @@ func (s *consoleWs) doConsole(op *operations.Operation) error { defer l.Debug("Finished mirroring websocket to console") l.Debug("Started mirroring websocket") - readDone, writeDone := ws.Mirror(context.Background(), conn, console) + readDone, writeDone := ws.Mirror(conn, console) <-readDone l.Debug("Finished mirroring console to websocket") diff --git a/cmd/incusd/instance_exec.go b/cmd/incusd/instance_exec.go index 9f5e54c01ee..64b0a12d70c 100644 --- a/cmd/incusd/instance_exec.go +++ b/cmd/incusd/instance_exec.go @@ -254,13 +254,13 @@ func (s *execWs) Do(op *operations.Operation) error { stderr = ttys[execWSStderr] } - waitAttachedChildIsDead := cancel.New(context.Background()) + waitAttachedChildIsDead, markAttachedChildIsDead := context.WithCancel(context.Background()) var wgEOF sync.WaitGroup // Define a function to clean up TTYs and sockets when done. finisher := func(cmdResult int, cmdErr error) error { - // Close this before closing the control connection so control handler can detect command ending. - waitAttachedChildIsDead.Cancel() + // Cancel this before closing the control connection so control handler can detect command ending. + markAttachedChildIsDead() for _, tty := range ttys { _ = tty.Close() @@ -417,10 +417,10 @@ func (s *execWs) Do(op *operations.Operation) error { if s.instance.Type() == instancetype.Container { // For containers, we are running the command via the locally managed PTY and so // need to use the same PTY handle for both read and write. - readDone, writeDone = ws.Mirror(context.Background(), conn, ptys[0]) + readDone, writeDone = ws.Mirror(conn, linux.NewExecWrapper(waitAttachedChildIsDead, ptys[0])) } else { - readDone = ws.MirrorRead(context.Background(), conn, ptys[execWSStdout]) - writeDone = ws.MirrorWrite(context.Background(), conn, ttys[execWSStdin]) + readDone = ws.MirrorRead(conn, ptys[execWSStdout]) + writeDone = ws.MirrorWrite(conn, ttys[execWSStdin]) } <-readDone @@ -462,10 +462,10 @@ func (s *execWs) Do(op *operations.Operation) error { } if i == execWSStdin { - <-ws.MirrorWrite(context.Background(), conn, ttys[i]) + <-ws.MirrorWrite(conn, ttys[i]) _ = ttys[i].Close() } else { - <-ws.MirrorRead(context.Background(), conn, ptys[i]) + <-ws.MirrorRead(conn, ptys[i]) _ = ptys[i].Close() wgEOF.Done() } diff --git a/cmd/incusd/instance_patch.go b/cmd/incusd/instance_patch.go index 118ce256ce8..e0535dbc402 100644 --- a/cmd/incusd/instance_patch.go +++ b/cmd/incusd/instance_patch.go @@ -88,7 +88,11 @@ func instancePatch(d *Daemon, r *http.Request) response.Response { return resp } - unlock := instanceOperationLock(s.ShutdownCtx, projectName, name) + unlock, err := instanceOperationLock(s.ShutdownCtx, projectName, name) + if err != nil { + return response.SmartError(err) + } + defer unlock() c, err := instance.LoadByProjectAndName(s, projectName, name) diff --git a/cmd/incusd/instance_put.go b/cmd/incusd/instance_put.go index 0df8c554d01..236d34c761f 100644 --- a/cmd/incusd/instance_put.go +++ b/cmd/incusd/instance_put.go @@ -95,7 +95,11 @@ func instancePut(d *Daemon, r *http.Request) response.Response { revert := revert.New() defer revert.Fail() - unlock := instanceOperationLock(s.ShutdownCtx, projectName, name) + unlock, err := instanceOperationLock(s.ShutdownCtx, projectName, name) + if err != nil { + return response.SmartError(err) + } + revert.Add(func() { unlock() }) diff --git a/cmd/incusd/instance_rebuild.go b/cmd/incusd/instance_rebuild.go index 344eeae9880..15e77718c88 100644 --- a/cmd/incusd/instance_rebuild.go +++ b/cmd/incusd/instance_rebuild.go @@ -70,6 +70,21 @@ func instanceRebuildPost(d *Daemon, r *http.Request) response.Response { return response.BadRequest(fmt.Errorf("Invalid instance name")) } + instanceType, err := urlInstanceTypeDetect(r) + if err != nil { + return response.SmartError(err) + } + + // Handle requests targeted to a container on a different node + resp, err := forwardedResponseIfInstanceIsRemote(s, r, targetProjectName, name, instanceType) + if err != nil { + return response.SmartError(err) + } + + if resp != nil { + return resp + } + // Parse the request req := api.InstanceRebuildPost{} err = json.NewDecoder(r.Body).Decode(&req) diff --git a/cmd/incusd/patches.go b/cmd/incusd/patches.go index a3b0bfe40ed..47b46148292 100644 --- a/cmd/incusd/patches.go +++ b/cmd/incusd/patches.go @@ -12,6 +12,7 @@ import ( "github.com/lxc/incus/internal/revert" "github.com/lxc/incus/internal/server/backup" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/cluster" "github.com/lxc/incus/internal/server/db" dbCluster "github.com/lxc/incus/internal/server/db/cluster" @@ -79,6 +80,7 @@ var patches = []patch{ {name: "zfs_set_content_type_user_property", stage: patchPostDaemonStorage, run: patchZfsSetContentTypeUserProperty}, {name: "snapshots_rename", stage: patchPreDaemonStorage, run: patchSnapshotsRename}, {name: "storage_zfs_unset_invalid_block_settings", stage: patchPostDaemonStorage, run: patchStorageZfsUnsetInvalidBlockSettings}, + {name: "storage_zfs_unset_invalid_block_settings_v2", stage: patchPostDaemonStorage, run: patchStorageZfsUnsetInvalidBlockSettingsV2}, } type patch struct { @@ -228,7 +230,7 @@ func patchClusteringServerCertTrust(name string, d *Daemon) error { trustedServerCerts := make(map[string]*dbCluster.Certificate) for _, c := range dbCerts { - if c.Type == dbCluster.CertificateTypeServer { + if c.Type == certificate.TypeServer { trustedServerCerts[c.Name] = &c } } @@ -954,8 +956,128 @@ func patchStorageZfsUnsetInvalidBlockSettings(_ string, d *Daemon) error { continue } - delete(config, "block.filesystem") - delete(config, "block.mount_options") + update := false + for _, k := range []string{"block.filesystem", "block.mount_options"} { + _, found := config[k] + if found { + delete(config, k) + update = true + } + } + + if !update { + continue + } + + if vol.Type == db.StoragePoolVolumeTypeNameVM { + volType = volTypeVM + } else if vol.Type == db.StoragePoolVolumeTypeNameCustom { + volType = volTypeCustom + } else { + // Should not happen. + continue + } + + err = s.DB.Cluster.UpdateStoragePoolVolume(vol.Project, vol.Name, volType, pool, vol.Description, config) + if err != nil { + return fmt.Errorf("Failed updating volume %q in project %q on pool %q: %w", vol.Name, vol.Project, poolIDNameMap[pool], err) + } + } + } + + return nil +} + +// patchStorageZfsUnsetInvalidBlockSettingsV2 removes invalid block settings from volumes. +// This patch fixes the previous one. +// - Handle non-clusted environments correctly. +// - Always remove block.* settings from VMs. +func patchStorageZfsUnsetInvalidBlockSettingsV2(_ string, d *Daemon) error { + s := d.State() + + // Get all storage pool names. + pools, err := s.DB.Cluster.GetStoragePoolNames() + if err != nil { + // Skip the rest of the patch if no storage pools were found. + if api.StatusErrorCheck(err, http.StatusNotFound) { + return nil + } + + return fmt.Errorf("Failed getting storage pool names: %w", err) + } + + volTypeCustom := db.StoragePoolVolumeTypeCustom + volTypeVM := db.StoragePoolVolumeTypeVM + + poolIDNameMap := make(map[int64]string, 0) + poolVolumes := make(map[int64][]*db.StorageVolume, 0) + + err = s.DB.Cluster.Transaction(s.ShutdownCtx, func(ctx context.Context, tx *db.ClusterTx) error { + for _, pool := range pools { + // Get storage pool ID. + poolID, err := tx.GetStoragePoolID(ctx, pool) + if err != nil { + return fmt.Errorf("Failed getting storage pool ID of pool %q: %w", pool, err) + } + + driverName, err := tx.GetStoragePoolDriver(ctx, poolID) + if err != nil { + return fmt.Errorf("Failed getting storage pool driver of pool %q: %w", pool, err) + } + + if driverName != "zfs" { + continue + } + + // Get the pool's custom storage volumes. + volumes, err := tx.GetStoragePoolVolumes(ctx, poolID, false, db.StorageVolumeFilter{Type: &volTypeCustom}, db.StorageVolumeFilter{Type: &volTypeVM}) + if err != nil { + return fmt.Errorf("Failed getting custom storage volumes of pool %q: %w", pool, err) + } + + if poolVolumes[poolID] == nil { + poolVolumes[poolID] = []*db.StorageVolume{} + } + + poolIDNameMap[poolID] = pool + poolVolumes[poolID] = append(poolVolumes[poolID], volumes...) + } + + return nil + }) + if err != nil { + return err + } + + var volType int + + for pool, volumes := range poolVolumes { + for _, vol := range volumes { + // In a non-clusted environment ServerName will be empty. + if s.ServerName != "" && vol.Location != s.ServerName { + continue + } + + config := vol.Config + + // Only check zfs.block_mode for custom volumes. VMs should never have any block.* settings + // regardless of the zfs.block_mode setting. + if util.IsTrue(config["zfs.block_mode"]) && vol.Type == db.StoragePoolVolumeTypeNameCustom { + continue + } + + update := false + for _, k := range []string{"block.filesystem", "block.mount_options"} { + _, found := config[k] + if found { + delete(config, k) + update = true + } + } + + if !update { + continue + } if vol.Type == db.StoragePoolVolumeTypeNameVM { volType = volTypeVM diff --git a/cmd/lxc-to-incus/transfer.go b/cmd/lxc-to-incus/transfer.go index 3a52fe5e8ac..9f1aeabe990 100644 --- a/cmd/lxc-to-incus/transfer.go +++ b/cmd/lxc-to-incus/transfer.go @@ -1,7 +1,6 @@ package main import ( - "context" "fmt" "io" "net" @@ -29,7 +28,7 @@ func rsyncSend(conn *websocket.Conn, path string, rsyncArgs string) error { defer func() { _ = dataSocket.Close() }() } - readDone, writeDone := ws.Mirror(context.Background(), conn, dataSocket) + readDone, writeDone := ws.Mirror(conn, dataSocket) <-writeDone _ = dataSocket.Close() diff --git a/cmd/lxd-to-incus/db.go b/cmd/lxd-to-incus/db.go index 1d252fa0cd5..ba8c20f8091 100644 --- a/cmd/lxd-to-incus/db.go +++ b/cmd/lxd-to-incus/db.go @@ -9,7 +9,8 @@ import ( "github.com/pierrec/lz4/v4" - "github.com/lxc/incus/shared" + internalIO "github.com/lxc/incus/internal/io" + internalUtil "github.com/lxc/incus/internal/util" ) // Uncompress the raft snapshot files in the given database directory. @@ -18,7 +19,7 @@ import ( func migrateDatabase(dir string) error { global := filepath.Join(dir, "global") - err := shared.DirCopy(global, global+".bak") + err := internalUtil.DirCopy(global, global+".bak") if err != nil { return fmt.Errorf("Failed to backup database directory %q: %w", global, err) } @@ -97,7 +98,7 @@ func lz4Uncompress(zfilename string) error { // use the same mode for the output file mode := zinfo.Mode() - _, uid, gid := shared.GetOwnerMode(zinfo) + _, uid, gid := internalIO.GetOwnerMode(zinfo) filename := zfilename + ".uncompressed" file, err := os.OpenFile(filename, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, mode) diff --git a/cmd/lxd-to-incus/go.mod b/cmd/lxd-to-incus/go.mod index e3bd6efa015..f4fbb1ea42e 100644 --- a/cmd/lxd-to-incus/go.mod +++ b/cmd/lxd-to-incus/go.mod @@ -1,10 +1,12 @@ module github.com/lxc/incus/cmd/lxd-to-incus +replace github.com/lxc/incus => ../../ + go 1.20 require ( - github.com/canonical/lxd v0.0.0-20230925202117-188c290d29fc - github.com/lxc/incus v0.0.0-20230926032748-f97f7f9d68ac + github.com/canonical/lxd v0.0.0-20231016192422-4c7185a4135a + github.com/lxc/incus v0.0.0-20231016135443-d428606e3b35 github.com/pierrec/lz4/v4 v4.1.18 github.com/spf13/cobra v1.7.0 ) @@ -37,11 +39,11 @@ require ( github.com/sirupsen/logrus v1.9.3 // indirect github.com/spf13/pflag v1.0.5 // indirect github.com/zitadel/oidc/v2 v2.11.0 // indirect - golang.org/x/crypto v0.13.0 // indirect - golang.org/x/net v0.15.0 // indirect - golang.org/x/oauth2 v0.12.0 // indirect - golang.org/x/sys v0.12.0 // indirect - golang.org/x/term v0.12.0 // indirect + golang.org/x/crypto v0.14.0 // indirect + golang.org/x/net v0.17.0 // indirect + golang.org/x/oauth2 v0.13.0 // indirect + golang.org/x/sys v0.13.0 // indirect + golang.org/x/term v0.13.0 // indirect golang.org/x/text v0.13.0 // indirect google.golang.org/appengine v1.6.8 // indirect google.golang.org/protobuf v1.31.0 // indirect diff --git a/cmd/lxd-to-incus/go.sum b/cmd/lxd-to-incus/go.sum index 40e04ce72f6..61c1432c712 100644 --- a/cmd/lxd-to-incus/go.sum +++ b/cmd/lxd-to-incus/go.sum @@ -1,13 +1,13 @@ cloud.google.com/go v0.26.0/go.mod h1:aQUYkXzVsufM+DwF1aE+0xfcU+56JwCaLick0ClmMTw= github.com/BurntSushi/toml v0.3.1/go.mod h1:xHWCNGjB5oqiDr8zfno3MHue2Ht5sIBksp03qcyfWMU= -github.com/canonical/lxd v0.0.0-20230925202117-188c290d29fc h1:ICJTcmO7MggyokAjEE0fLlEHtPv7pe1iMafvCloUOUM= -github.com/canonical/lxd v0.0.0-20230925202117-188c290d29fc/go.mod h1:/lJ1suHbUSZn1VgwfWEcjkddHk4JeLTjtBwFPY0Eb7o= +github.com/canonical/lxd v0.0.0-20231016192422-4c7185a4135a h1:2lKokfODFHr5bEPkc5Q+NTZbModzE3XvNlbY+LFEzGw= +github.com/canonical/lxd v0.0.0-20231016192422-4c7185a4135a/go.mod h1:ANEF+tUYPgaNocG30lmqbB5gN4tuG3NsxQ1cCkAjctM= github.com/census-instrumentation/opencensus-proto v0.2.1/go.mod h1:f6KPmirojxKA12rnyqOA5BBL4O983OfeGPqjHWSTneU= github.com/client9/misspell v0.3.4/go.mod h1:qj6jICC3Q7zFZvVWo7KLAzC3yx5G7kyvSDkc90ppPyw= github.com/cpuguy83/go-md2man/v2 v2.0.2/go.mod h1:tgQtvFlXSQOSOSIRvRPT7W67SCa46tRHOmNcaadrF8o= github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= -github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c= github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= +github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM= github.com/envoyproxy/go-control-plane v0.9.1-0.20191026205805-5f8ba28d4473/go.mod h1:YTl/9mNaCwkRvm6d1a2C3ymFceY/DCBVvsKhRF0iEA4= github.com/envoyproxy/protoc-gen-validate v0.1.0/go.mod h1:iSmxcyjqTsJpI2R4NaDN7+kN2VEUnK/pcBlmesArF7c= github.com/flosch/pongo2 v0.0.0-20200913210552-0d938eb266f3 h1:fmFk0Wt3bBxxwZnu48jqMdaOR/IZ4vdtJFuaFV8MpIE= @@ -79,8 +79,6 @@ github.com/kr/pretty v0.2.1 h1:Fmg33tUaq4/8ym9TJN1x7sLJnHVwhP33CNkpYV/7rwI= github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ= github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI= github.com/kr/text v0.2.0 h1:5Nx0Ya0ZqY2ygV366QzturHI13Jq95ApcVaJBhpS+AY= -github.com/lxc/incus v0.0.0-20230926032748-f97f7f9d68ac h1:XOCgvOXwM4skYY9BSo/+UO7lVhqD2WNnc8UbeWDX6Vs= -github.com/lxc/incus v0.0.0-20230926032748-f97f7f9d68ac/go.mod h1:yhHdpW6Uzxn10at7nNMPQRVr7qQA0gS+EVT32mi+9/U= github.com/mattn/go-runewidth v0.0.9/go.mod h1:H031xJmbD/WCDINGzjvQ9THkh0rPKHF+m2gUSrubnMI= github.com/mattn/go-runewidth v0.0.15 h1:UNAjwbU9l54TA3KzvqLGxwWjHmMgBUVhBiTjelZgg3U= github.com/mattn/go-runewidth v0.0.15/go.mod h1:Jdepj2loyihRzMpdS35Xk/zdY8IAYHsh153qUoGf23w= @@ -109,7 +107,7 @@ github.com/robfig/cron/v3 v3.0.1 h1:WdRxkvbJztn8LMz/QEvLN5sBU+xKpSqwwUO1Pjr4qDs= github.com/robfig/cron/v3 v3.0.1/go.mod h1:eQICP3HwyT7UooqI/z+Ov+PtYAWygg1TEWWzGIFLtro= github.com/rogpeppe/fastuuid v1.2.0 h1:Ppwyp6VYCF1nvBTXL3trRso7mXMlRrw9ooo375wvi2s= github.com/rogpeppe/fastuuid v1.2.0/go.mod h1:jVj6XXZzXRy/MSR5jhDC/2q6DgLz+nrA6LYCDYWNEvQ= -github.com/rs/cors v1.10.0 h1:62NOS1h+r8p1mW6FM0FSB0exioXLhd/sh15KpjWBZ+8= +github.com/rs/cors v1.10.1 h1:L0uuZVXIKlI1SShY2nhFfo44TYvDPQ1w4oFkUJNfhyo= github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= github.com/sirupsen/logrus v1.9.3 h1:dueUQJ1C2q9oE3F7wvmSGAaVtTmUizReu6fjN8uqzbQ= github.com/sirupsen/logrus v1.9.3/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ= @@ -127,16 +125,16 @@ github.com/yuin/goldmark v1.1.27/go.mod h1:3hX8gzYuyVAZsxl0MRgGTJEmQBFcNTphYh9de github.com/yuin/goldmark v1.4.13/go.mod h1:6yULJ656Px+3vBD8DxQVa3kxgyrAnzto9xy5taEt/CY= github.com/zitadel/oidc/v2 v2.11.0 h1:Am4/yQr4iiM5bznRgF3FOp+wLdKx2gzSU73uyI9vvBE= github.com/zitadel/oidc/v2 v2.11.0/go.mod h1:enFSVBQI6aE0TEB1ntjXs9r6O6DEosxX4uhEBLBVD8o= -go.opentelemetry.io/otel v1.17.0 h1:MW+phZ6WZ5/uk2nd93ANk/6yJ+dVrvNWUjGhnnFU5jM= -go.opentelemetry.io/otel/metric v1.17.0 h1:iG6LGVz5Gh+IuO0jmgvpTB6YVrCGngi8QGm+pMd8Pdc= -go.opentelemetry.io/otel/trace v1.17.0 h1:/SWhSRHmDPOImIAetP1QAeMnZYiQXrTy4fMMYOdSKWQ= +go.opentelemetry.io/otel v1.19.0 h1:MuS/TNf4/j4IXsZuJegVzI1cwut7Qc00344rgH7p8bs= +go.opentelemetry.io/otel/metric v1.19.0 h1:aTzpGtV0ar9wlV4Sna9sdJyII5jTVJEvKETPiOKwvpE= +go.opentelemetry.io/otel/trace v1.19.0 h1:DFVQmlVbfVeOuBRrwdtaehRrWiL1JoVs9CPIQ1Dzxpg= golang.org/x/crypto v0.0.0-20180723164146-c126467f60eb/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= golang.org/x/crypto v0.0.0-20191011191535-87dc89f01550/go.mod h1:yigFU9vqHzYiE8UmvKecakEJjdnWj3jj499lnFckfCI= golang.org/x/crypto v0.0.0-20210921155107-089bfa567519/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc= golang.org/x/crypto v0.1.0/go.mod h1:RecgLatLF4+eUMCP1PoPZQb+cVrJcOPbHkTkbkB9sbw= -golang.org/x/crypto v0.13.0 h1:mvySKfSWJ+UKUii46M40LOvyWfN0s2U+46/jDd0e6Ck= -golang.org/x/crypto v0.13.0/go.mod h1:y6Z2r+Rw4iayiXXAIxJIDAJ1zMW4yaTpebo8fPOliYc= +golang.org/x/crypto v0.14.0 h1:wBqGXzWJW6m1XrIKlAH0Hs1JJ7+9KBwnIO8v66Q9cHc= +golang.org/x/crypto v0.14.0/go.mod h1:MVFd36DqK4CsrnJYDkBA3VC4m2GkXAM0PvzMCn4JQf4= golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE= golang.org/x/lint v0.0.0-20190227174305-5b3e6a55c961/go.mod h1:wehouNa3lNwaWXcvxsM5YxQ5yQlVC4a0KAMCusXpPoU= @@ -154,11 +152,11 @@ golang.org/x/net v0.0.0-20200505041828-1ed23360d12c/go.mod h1:qpuaurCH72eLCgpAm/ golang.org/x/net v0.0.0-20210226172049-e18ecbb05110/go.mod h1:m0MpNAwzfU5UDzcl9v0D8zg8gWTRqZa9RBIspLL5mdg= golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c= golang.org/x/net v0.1.0/go.mod h1:Cx3nUiGt4eDBEyega/BKRp+/AlGL8hYe7U9odMt2Cco= -golang.org/x/net v0.15.0 h1:ugBLEUaxABaB5AJqW9enI0ACdci2RUd4eP51NTBvuJ8= -golang.org/x/net v0.15.0/go.mod h1:idbUs1IY1+zTqbi8yxTbhexhEEk5ur9LInksu6HrEpk= +golang.org/x/net v0.17.0 h1:pVaXccu2ozPjCXewfr1S7xza/zcXTity9cCdXQYSjIM= +golang.org/x/net v0.17.0/go.mod h1:NxSsAGuq816PNPmqtQdLE42eU2Fs7NoRIZrHJAlaCOE= golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U= -golang.org/x/oauth2 v0.12.0 h1:smVPGxink+n1ZI5pkQa8y6fZT0RW0MgCO5bFpepy4B4= -golang.org/x/oauth2 v0.12.0/go.mod h1:A74bZ3aGXgCY0qaIC9Ahg6Lglin4AMAco8cIv9baba4= +golang.org/x/oauth2 v0.13.0 h1:jDDenyj+WgFtmV3zYVoi8aE2BwtXFLWOA67ZfNWftiY= +golang.org/x/oauth2 v0.13.0/go.mod h1:/JMhi4ZRXAf4HG9LiNmxvk+45+96RUlVThiH8FzNBn0= golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.0.0-20190423024810-112230192c58/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= @@ -175,13 +173,13 @@ golang.org/x/sys v0.0.0-20220520151302-bc2c85ada10a/go.mod h1:oPkhp1MJrh7nUepCBc golang.org/x/sys v0.0.0-20220715151400-c0bba94af5f8/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.0.0-20220722155257-8c9f86f7a55f/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.1.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= -golang.org/x/sys v0.12.0 h1:CM0HF96J0hcLAwsHPJZjfdNzs0gftsLfgKt57wWHJ0o= -golang.org/x/sys v0.12.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +golang.org/x/sys v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE= +golang.org/x/sys v0.13.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo= golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8= golang.org/x/term v0.1.0/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8= -golang.org/x/term v0.12.0 h1:/ZfYdc3zq+q02Rv9vGqTeSItdzZTSNDmfTi0mBAuidU= -golang.org/x/term v0.12.0/go.mod h1:owVbMEjm3cBLCHdkQu9b1opXd4ETQWc3BhuQGKgXgvU= +golang.org/x/term v0.13.0 h1:bb+I9cTfFazGW51MZqBVmZy7+JEJMouUHTUSKVQLBek= +golang.org/x/term v0.13.0/go.mod h1:LTmsnFJwVN6bCy1rVCoS+qHT1HhALEFxKncY3WNNh4U= golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= golang.org/x/text v0.3.3/go.mod h1:5Zoc/QRtKVWzQhOtBMvqHzDpF6irO9z98xDceosuGiQ= golang.org/x/text v0.3.7/go.mod h1:u+2+/6zg+i71rQMx5EYifcz6MCKuco9NR6JIITiCfzQ= diff --git a/cmd/lxd-to-incus/main.go b/cmd/lxd-to-incus/main.go index 848b9a5887e..8e035570d1b 100644 --- a/cmd/lxd-to-incus/main.go +++ b/cmd/lxd-to-incus/main.go @@ -1,6 +1,7 @@ package main import ( + "bufio" "fmt" "os" "path/filepath" @@ -9,7 +10,7 @@ import ( lxdAPI "github.com/canonical/lxd/shared/api" "github.com/spf13/cobra" - "github.com/lxc/incus/internal/cmd" + cli "github.com/lxc/incus/internal/cmd" "github.com/lxc/incus/internal/version" incusAPI "github.com/lxc/incus/shared/api" "github.com/lxc/incus/shared/subprocess" @@ -19,15 +20,17 @@ var minLXDVersion = &version.DottedVersion{4, 0, 0} var maxLXDVersion = &version.DottedVersion{5, 18, 0} type cmdGlobal struct { + asker cli.Asker + flagHelp bool flagVersion bool } func main() { // Setup command line parser. - daemonCmd := cmdMigrate{} + migrateCmd := cmdMigrate{} - app := daemonCmd.Command() + app := migrateCmd.Command() app.Use = "lxd-to-incus" app.Short = "LXD to Incus migration tool" app.Long = `Description: @@ -39,7 +42,8 @@ func main() { app.CompletionOptions = cobra.CompletionOptions{DisableDefaultCmd: true} // Global flags. - globalCmd := cmdGlobal{} + globalCmd := cmdGlobal{asker: cli.NewAsker(bufio.NewReader(os.Stdin))} + migrateCmd.global = globalCmd app.PersistentFlags().BoolVar(&globalCmd.flagVersion, "version", false, "Print version number") app.PersistentFlags().BoolVarP(&globalCmd.flagHelp, "help", "h", false, "Print help") @@ -55,6 +59,8 @@ func main() { } type cmdMigrate struct { + global cmdGlobal + flagYes bool } @@ -89,6 +95,8 @@ func (c *cmdMigrate) Run(app *cobra.Command, args []string) error { return fmt.Errorf("No source server could be found") } + fmt.Printf("==> Detected: %s\n", source.Name()) + // Iterate through potential targets. fmt.Println("=> Looking for target server") var target Target @@ -456,7 +464,7 @@ At this point, the source server and all its instances will be stopped. Instances will come back online once the migration is complete. `) - ok, err := cmd.AskBool("Proceed with the migration? [default=no]: ", "no") + ok, err := c.global.asker.AskBool("Proceed with the migration? [default=no]: ", "no") if err != nil { return err } @@ -532,6 +540,11 @@ Instances will come back online once the migration is complete. // Cleanup paths. fmt.Println("=> Cleaning up target paths") + for _, dir := range []string{"backups", "images"} { + // Remove any potential symlink (ignore errors for real directories). + _ = os.Remove(filepath.Join(targetPaths.Daemon, dir)) + } + for _, dir := range []string{"devices", "devlxd", "security", "shmounts"} { err = os.RemoveAll(filepath.Join(targetPaths.Daemon, dir)) if err != nil && !os.IsNotExist(err) { @@ -585,7 +598,7 @@ Instances will come back online once the migration is complete. // Confirm uninstall. if !c.flagYes { - ok, err := cmd.AskBool("Uninstall the LXD package? [default=no]: ", "no") + ok, err := c.global.asker.AskBool("Uninstall the LXD package? [default=no]: ", "no") if err != nil { return err } diff --git a/cmd/lxd-to-incus/sources.go b/cmd/lxd-to-incus/sources.go index 15d03eaefcc..b07f9d13ff8 100644 --- a/cmd/lxd-to-incus/sources.go +++ b/cmd/lxd-to-incus/sources.go @@ -11,9 +11,11 @@ type Source interface { Purge() error Connect() (lxd.InstanceServer, error) Paths() (*DaemonPaths, error) + Name() string } var sources = []Source{ &srcSnap{}, &srcDeb{}, + &srcManual{}, } diff --git a/cmd/lxd-to-incus/sources_deb.go b/cmd/lxd-to-incus/sources_deb.go index 10f1df7e72c..f979e614ea6 100644 --- a/cmd/lxd-to-incus/sources_deb.go +++ b/cmd/lxd-to-incus/sources_deb.go @@ -3,25 +3,29 @@ package main import ( "github.com/canonical/lxd/client" - "github.com/lxc/incus/shared" "github.com/lxc/incus/shared/subprocess" + "github.com/lxc/incus/shared/util" ) type srcDeb struct{} func (s *srcDeb) Present() bool { // Validate that the Debian package is installed. - if !shared.PathExists("/var/lib/dpkg/info/lxd.list") { + if !util.PathExists("/var/lib/dpkg/info/lxd.list") { return false } - if !shared.PathExists("/var/lib/lxd") { + if !util.PathExists("/var/lib/lxd") { return false } return true } +func (s *srcDeb) Name() string { + return ".deb package" +} + func (s *srcDeb) Stop() error { _, err := subprocess.RunCommand("systemctl", "stop", "lxd-containers.service", "lxd.service", "lxd.socket") return err diff --git a/cmd/lxd-to-incus/sources_manual.go b/cmd/lxd-to-incus/sources_manual.go new file mode 100644 index 00000000000..69249a6d42d --- /dev/null +++ b/cmd/lxd-to-incus/sources_manual.go @@ -0,0 +1,66 @@ +package main + +import ( + "net/http" + "time" + + "github.com/canonical/lxd/client" + + "github.com/lxc/incus/shared/util" +) + +type srcManual struct{} + +func (s *srcManual) Present() bool { + if !util.PathExists("/var/lib/lxd") { + return false + } + + return true +} + +func (s *srcManual) Name() string { + return "manual installation" +} + +func (s *srcManual) Stop() error { + d, err := s.Connect() + if err != nil { + return err + } + + httpClient, err := d.GetHTTPClient() + if err != nil { + return err + } + + // Request shutdown, this shouldn't return until daemon has stopped so use a large request timeout. + httpTransport := httpClient.Transport.(*http.Transport) + httpTransport.ResponseHeaderTimeout = 3600 * time.Second + _, _, err = d.RawQuery("PUT", "/internal/shutdown", nil, "") + if err != nil { + return err + } + + return nil +} + +func (s *srcManual) Start() error { + return nil +} + +func (s *srcManual) Purge() error { + return nil +} + +func (s *srcManual) Connect() (lxd.InstanceServer, error) { + return lxd.ConnectLXDUnix("/var/lib/lxd/unix.socket", nil) +} + +func (s *srcManual) Paths() (*DaemonPaths, error) { + return &DaemonPaths{ + Daemon: "/var/lib/lxd/", + Logs: "/var/log/lxd/", + Cache: "/var/cache/lxd/", + }, nil +} diff --git a/cmd/lxd-to-incus/sources_snap.go b/cmd/lxd-to-incus/sources_snap.go index 23ad9ebbcfd..560c4b82ecc 100644 --- a/cmd/lxd-to-incus/sources_snap.go +++ b/cmd/lxd-to-incus/sources_snap.go @@ -3,25 +3,29 @@ package main import ( "github.com/canonical/lxd/client" - "github.com/lxc/incus/shared" "github.com/lxc/incus/shared/subprocess" + "github.com/lxc/incus/shared/util" ) type srcSnap struct{} func (s *srcSnap) Present() bool { // Validate that the snap is installed. - if !shared.PathExists("/snap/lxd") { + if !util.PathExists("/snap/lxd") { return false } - if !shared.PathExists("/var/snap/lxd") { + if !util.PathExists("/var/snap/lxd") { return false } return true } +func (s *srcSnap) Name() string { + return "snap package" +} + func (s *srcSnap) Stop() error { _, err := subprocess.RunCommand("snap", "stop", "lxd") return err diff --git a/cmd/lxd-to-incus/targets.go b/cmd/lxd-to-incus/targets.go index fb3455625d9..f2b405e0e4c 100644 --- a/cmd/lxd-to-incus/targets.go +++ b/cmd/lxd-to-incus/targets.go @@ -4,8 +4,8 @@ import ( "time" "github.com/lxc/incus/client" - "github.com/lxc/incus/shared" "github.com/lxc/incus/shared/subprocess" + "github.com/lxc/incus/shared/util" ) type Target interface { @@ -21,11 +21,11 @@ var targets = []Target{&targetSystemd{}} type targetSystemd struct{} func (s *targetSystemd) Present() bool { - if !shared.PathExists("/var/lib/incus/") { + if !util.PathExists("/var/lib/incus/") { return false } - if !shared.PathExists("/lib/systemd/system/incus.service") { + if !util.PathExists("/lib/systemd/system/incus.service") { return false } diff --git a/doc/.readthedocs.yaml b/doc/.readthedocs.yaml index 3f7b82865b4..27a9db4066b 100644 --- a/doc/.readthedocs.yaml +++ b/doc/.readthedocs.yaml @@ -13,7 +13,7 @@ build: python: "3.11" jobs: pre_build: - - go build -o incus.bin ./cmd/incus + - go install -v ./cmd/incus # Build documentation in the docs/ directory with Sphinx diff --git a/doc/.sphinx/.markdownlint/doc-lint.sh b/doc/.sphinx/.markdownlint/doc-lint.sh index 8a12da74953..f7d206f4fd9 100755 --- a/doc/.sphinx/.markdownlint/doc-lint.sh +++ b/doc/.sphinx/.markdownlint/doc-lint.sh @@ -20,8 +20,11 @@ mdl .tmp/doc -sdoc/.sphinx/.markdownlint/style.rb -udoc/.sphinx/.markdownlint/ru ## Postprocessing -filtered_errors="$(grep -vxFf doc/.sphinx/.markdownlint/exceptions.txt .tmp/errors.txt)" -if [ "$(echo "$filtered_errors" | wc -l)" = "2" ]; then +sed -i '/^$/,$d' .tmp/errors.txt + +filtered_errors="$(grep -vxFf doc/.sphinx/.markdownlint/exceptions.txt .tmp/errors.txt)" || true + +if [ -z "$filtered_errors" ]; then echo "Passed!" exit 0 else diff --git a/doc/README.md b/doc/README.md index d6dce9b81e9..2e8d2175443 100644 --- a/doc/README.md +++ b/doc/README.md @@ -1,27 +1,26 @@ -# Incus documentation +# Incusドキュメント -The Incus documentation is available at: +Incus の日本語ドキュメントは、(原文のドキュメントは)で閲覧できます。 -GitHub provides a basic rendering of the documentation as well, but important features like includes and clickable links are missing. Therefore, we recommend reading the [published documentation](https://linuxcontainers.org/incus/docs/main/). +GitHub でもドキュメントの基本的なレンダリングを提供していますが、include やクリッカブルリンクなどの重要な機能が欠落しています。そのため、[公開ドキュメント](https://incus-ja.readthedocs.io/ja/latest/)を読むことをお勧めします。 -## How it works +## どのように動作するか -### Documentation framework +### ドキュメントのフレームワーク -Incus' documentation is built with [Sphinx](https://www.sphinx-doc.org/en/master/index.html). +Incus のドキュメントは[Sphinx](https://www.sphinx-doc.org/en/master/index.html)でビルドされます。 -It is written in [Markdown](https://commonmark.org/) with [MyST](https://myst-parser.readthedocs.io/) extensions. -For syntax help and guidelines, see the [documentation cheat sheet](https://linuxcontainers.org/incus/docs/main/doc-cheat-sheet/) ([source](https://raw.githubusercontent.com/lxc/incus/main/doc/doc-cheat-sheet.md)). +ドキュメントは[Markdown](https://commonmark.org/)と[MyST](https://myst-parser.readthedocs.io/)の拡張で書かれています。 +構文のヘルプやガイドラインについては、[ドキュメントチートシート](https://incus-ja.readthedocs.io/ja/latest/doc-cheat-sheet/) ([ソース](https://raw.githubusercontent.com/lxc-jp/incus-ja/main/doc/doc-cheat-sheet.md))を参照してください。 -For structuring, the documentation uses the [Diátaxis](https://diataxis.fr/) approach. +構成に関しては、このドキュメントでは[Diátaxis](https://diataxis.fr/)アプローチを採用しています。 -### Build the documentation +### ドキュメントのビルド -To build the documentation, run `make doc` from the root directory of the repository. -This command installs the required tools and renders the output to the `doc/html/` directory. -To update the documentation for changed files only (without re-installing the tools), run `make doc-incremental`. +ドキュメントをビルドするには、リポジトリのルートディレクトリーから`make doc`を実行します。このコマンドは必要なツールをインストールして、出力を`doc/html/`ディレクトリーにレンダリングします。 +変更されたファイルのみを対象に（ツールを再インストールすることなく）ドキュメントを更新するには、`make doc-incremental`を実行します。 -Before opening a pull request, make sure that the documentation builds without any warnings (warnings are treated as errors). -To preview the documentation locally, run `make doc-serve` and go to [`http://localhost:8001`](http://localhost:8001) to view the rendered documentation. +Pull Request をオープンする前に、ドキュメントが警告なしでビルドできることを確認してください（警告はエラーとして扱われます）。 +ドキュメントをローカルでプレビューするには、`make doc-serve`を実行し[`http://localhost:8001`](http://localhost:8001)をブラウザで開いてください。 diff --git a/doc/api-extensions.md b/doc/api-extensions.md index 42f125a72ed..e201203b349 100644 --- a/doc/api-extensions.md +++ b/doc/api-extensions.md @@ -1,490 +1,505 @@ -# API extensions +# API 拡張 -The changes below were introduced to the Incus API after the 1.0 API was finalized. +以下の変更は 1.0 API が確定した後、Incus API に追加されました。 -They are all backward compatible and can be detected by client tools by -looking at the `api_extensions` field in `GET /1.0`. +それらの変更はすべて後方互換であり、 `GET /1.0` の `api_extensions` を +見ることでクライアントツールにより検出可能です。 ## `storage_zfs_remove_snapshots` -A `storage.zfs_remove_snapshots` daemon configuration key was introduced. +`storage.zfs_remove_snapshots` というデーモン設定キーが導入されました。 -It's a Boolean that defaults to `false` and that when set to `true` instructs Incus -to remove any needed snapshot when attempting to restore another. +値の型は Boolean でデフォルトは `false` です。 `true` にセットすると、スナップショットを +復元しようとするときに必要なスナップショットをすべて削除するように Incus に +指示します。 -This is needed as ZFS will only let you restore the latest snapshot. +ZFS でスナップショットの復元が出来るのは最新のスナップショットに限られるので、 +この対応が必要になります。 ## `container_host_shutdown_timeout` -A `boot.host_shutdown_timeout` container configuration key was introduced. +`boot.host_shutdown_timeout` というコンテナ設定キーが導入されました。 -It's an integer which indicates how long Incus should wait for the container -to stop before killing it. +値の型は integer でコンテナを停止しようとした後 kill するまでどれだけ +待つかを Incus に指示します。 -Its value is only used on clean Incus daemon shutdown. It defaults to 30s. +この値は Incus デーモンのクリーンなシャットダウンのときにのみ使用されます。 +デフォルトは 30s です。 ## `container_stop_priority` -A `boot.stop.priority` container configuration key was introduced. +`boot.stop.priority` というコンテナ設定キーが導入されました。 -It's an integer which indicates the priority of a container during shutdown. +値の型は integer でシャットダウン時のコンテナの優先度を指示します。 -Containers will shutdown starting with the highest priority level. +コンテナは優先度レベルの高いものからシャットダウンを開始します。 -Containers with the same priority will shutdown in parallel. It defaults to 0. +同じ優先度のコンテナは並列にシャットダウンします。デフォルトは 0 です。 ## `container_syscall_filtering` -A number of new syscalls related container configuration keys were introduced. +コンテナ設定キーに関するいくつかの新しい syscall が導入されました。 * `security.syscalls.blacklist_default` * `security.syscalls.blacklist_compat` * `security.syscalls.blacklist` * `security.syscalls.whitelist` -See [Instance configuration](instance-config) for how to use them. +使い方は [インスタンスの設定](instance-config) を参照してください。 ## `auth_pki` -This indicates support for PKI authentication mode. +これは PKI 認証モードのサポートを指示します。 -In this mode, the client and server both must use certificates issued by the same PKI. +このモードではクライアントとサーバーは同じ PKI によって発行された証明書を使わなければなりません。 -See [Security](security.md) for details. +詳細は [セキュリティ](security.md) を参照してください。 ## `container_last_used_at` -A `last_used_at` field was added to the `GET /1.0/containers/` endpoint. +`GET /1.0/containers/` エンドポイントに `last_used_at` フィールドが追加されました。 -It is a timestamp of the last time the container was started. +これはコンテナが開始した最新の時刻のタイムスタンプです。 -If a container has been created but not started yet, `last_used_at` field -will be `1970-01-01T00:00:00Z` +コンテナが作成されたが開始はされていない場合は `last_used_at` フィールドは +`1970-01-01T00:00:00Z` になります。 ## `etag` -Add support for the ETag header on all relevant endpoints. +関連性のあるすべてのエンドポイントに ETag ヘッダのサポートが追加されました。 -This adds the following HTTP header on answers to GET: +この変更により GET のレスポンスに次の HTTP ヘッダが追加されます。 -* ETag (SHA-256 of user modifiable content) +* ETag（ユーザーが変更可能なコンテンツの SHA-256） -And adds support for the following HTTP header on PUT requests: +また PUT リクエストに次の HTTP ヘッダのサポートが追加されます。 -* If-Match (ETag value retrieved through previous GET) +* If-Match（前回の GET で得られた ETag の値を指定） -This makes it possible to GET a Incus object, modify it and PUT it without -risking to hit a race condition where Incus or another client modified the -object in the meantime. +これにより GET で Incus のオブジェクトを取得して PUT で変更する際に、 +レースコンディションになったり、途中で別のクライアントがオブジェクトを +変更していた（訳注: のを上書きしてしまう）というリスク無しに PUT で +変更できるようになります。 ## `patch` -Add support for the HTTP PATCH method. +HTTP の PATCH メソッドのサポートを追加します。 -PATCH allows for partial update of an object in place of PUT. +PUT の代わりに PATCH を使うとオブジェクトの部分的な変更が出来ます。 ## `usb_devices` -Add support for USB hotplug. +USB ホットプラグのサポートを追加します。 ## `https_allowed_credentials` -To use Incus API with all Web Browsers (via SPAs) you must send credentials -(certificate) with each XHR (in order for this to happen, you should set +Incus API をすべてのウェブブラウザで（SPA 経由で）使用するには、 XHR の度に +認証情報を送る必要があります。それぞれの XHR リクエストで [`withCredentials=true`](https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials) -flag to each XHR Request). +とセットします。 -Some browsers like Firefox and Safari can't accept server response without -`Access-Control-Allow-Credentials: true` header. To ensure that the server will -return a response with that header, set `core.https_allowed_credentials=true`. +Firefox や Safari などいくつかのブラウザは +`Access-Control-Allow-Credentials: true` ヘッダがないレスポンスを受け入れる +ことができません。サーバーがこのヘッダ付きのレスポンスを返すことを保証するには +`core.https_allowed_credentials=true` と設定してください。 ## `image_compression_algorithm` -This adds support for a `compression_algorithm` property when creating an image (`POST /1.0/images`). +この変更はイメージを作成する時（`POST /1.0/images`）に `compression_algorithm` +というプロパティのサポートを追加します。 -Setting this property overrides the server default value (`images.compression_algorithm`). +このプロパティを設定するとサーバーのデフォルト値 (`images.compression_algorithm`) をオーバーライドします。 ## `directory_manipulation` -This allows for creating and listing directories via the Incus API, and exports -the file type via the X-Incus-type header, which can be either `file` or -`directory` right now. +Incus API 経由でディレクトリーを作成したり一覧したりでき、ファイルタイプを X-Incus-type ヘッダに付与するようになります。 +現状はファイルタイプは `file` か `directory` のいずれかです。 ## `container_cpu_time` -This adds support for retrieving CPU time for a running container. +この拡張により実行中のコンテナの CPU 時間を取得できます。 ## `storage_zfs_use_refquota` -Introduces a new server property `storage.zfs_use_refquota` which instructs Incus -to set the `refquota` property instead of `quota` when setting a size limit -on a container. Incus will also then use `usedbydataset` in place of `used` -when being queried about disk utilization. +この拡張により新しいサーバープロパティ `storage.zfs_use_refquota` が追加されます。 +これはコンテナにサイズ制限を設定する際に `quota` の代わりに `refquota` を設定する +ように Incus に指示します。また Incus はディスク使用量を調べる際に `used` の代わりに +`usedbydataset` を使うようになります。 -This effectively controls whether disk usage by snapshots should be -considered as part of the container's disk space usage. +これはスナップショットによるディスク消費をコンテナのディスク利用の一部と +みなすかどうかを実質的に切り替えることになります。 ## `storage_lvm_mount_options` -Adds a new `storage.lvm_mount_options` daemon configuration option -which defaults to `discard` and allows the user to set addition mount -options for the file system used by the LVM LV. +この拡張は `storage.lvm_mount_options` という新しいデーモン設定オプションを +追加します。デフォルト値は `discard` で、このオプションにより LVM LV で使用する +ファイルシステムの追加マウントオプションをユーザーが指定できるようになります。 ## `network` -Network management API for Incus. +Incus のネットワーク管理 API 。 -This includes: +次のものを含みます。 -* Addition of the `managed` property on `/1.0/networks` entries -* All the network configuration options (see [Network configuration](networks.md) for details) -* `POST /1.0/networks` (see [RESTful API](rest-api.md) for details) -* `PUT /1.0/networks/` (see [RESTful API](rest-api.md) for details) -* `PATCH /1.0/networks/` (see [RESTful API](rest-api.md) for details) -* `DELETE /1.0/networks/` (see [RESTful API](rest-api.md) for details) -* `ipv4.address` property on `nic` type devices (when `nictype` is `bridged`) -* `ipv6.address` property on `nic` type devices (when `nictype` is `bridged`) -* `security.mac_filtering` property on `nic` type devices (when `nictype` is `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` -Adds a new `used_by` field to profile entries listing the containers that are using it. +プロファイルを使用しているコンテナをプロファイルエントリーの一覧の `used_by` フィールド +として新たに追加します。 ## `container_push` -When a container is created in push mode, the client serves as a proxy between -the source and target server. This is useful in cases where the target server -is behind a NAT or firewall and cannot directly communicate with the source -server and operate in pull mode. +コンテナが push モードで作成される時、クライアントは作成元と作成先のサーバー間の +プロキシとして機能します。作成先のサーバーが NAT やファイアウォールの後ろにいて +作成元のサーバーと直接通信できず pull モードで作成できないときにこれは便利です。 ## `container_exec_recording` -Introduces a new Boolean `record-output`, parameter to -`/1.0/containers//exec` which when set to `true` and combined with -with `wait-for-websocket` set to `false`, will record stdout and stderr to -disk and make them available through the logs interface. +新しい Boolean 型の `record-output` を導入します。これは `/1.0/containers//exec` +のパラメーターでこれを `true` に設定し `wait-for-websocket` を `false` に設定すると +標準出力と標準エラー出力をディスクに保存し logs インターフェース経由で利用可能にします。 -The URL to the recorded output is included in the operation metadata -once the command is done running. +記録された出力の URL はコマンドが実行完了したら操作のメタデータに含まれます。 -That output will expire similarly to other log files, typically after 48 hours. +出力は他のログファイルと同様に、通常は 48 時間後に期限切れになります。 ## `certificate_update` -Adds the following to the REST API: +REST API に次のものを追加します: -* ETag header on GET of a certificate -* PUT of certificate entries -* PATCH of certificate entries +* 証明書の GET に ETag ヘッダ +* 証明書エントリーの PUT +* 証明書エントリーの PATCH ## `container_exec_signal_handling` -Adds support `/1.0/containers//exec` for forwarding signals sent to the -client to the processes executing in the container. Currently SIGTERM and -SIGHUP are forwarded. Further signals that can be forwarded might be added -later. +クライアントに送られたシグナルをコンテナ内で実行中のプロセスにフォワーディング +するサポートを `/1.0/containers//exec` に追加します。現状では SIGTERM と +SIGHUP がフォワードされます。フォワード出来るシグナルは今後さらに追加される +かもしれません。 ## `gpu_devices` -Enables adding GPUs to a container. +コンテナに GPU を追加できるようにします。 ## `container_image_properties` -Introduces a new `image` configuration key space. Read-only, includes the properties of the parent image. +設定キー空間に新しく `image` を導入します。これは読み取り専用で、親のイメージのプロパティを +含みます。 ## `migration_progress` -Transfer progress is now exported as part of the operation, on both sending and receiving ends. -This shows up as a `fs_progress` attribute in the operation metadata. +転送の進捗が操作の一部として送信側と受信側の両方に公開されます。これは操作のメタデータの +`fs_progress` 属性として現れます。 ## `id_map` -Enables setting the `security.idmap.isolated` and `security.idmap.isolated`, -`security.idmap.size`, and `raw.id_map` fields. +`security.idmap.isolated`、`security.idmap.isolated`、`security.idmap.size`、`raw.id_map` のフィールドを設定できるようにします。 ## `network_firewall_filtering` -Add two new keys, `ipv4.firewall` and `ipv6.firewall` which if set to -`false` will turn off the generation of `iptables` FORWARDING rules. NAT -rules will still be added so long as the matching `ipv4.nat` or -`ipv6.nat` key is set to `true`. +`ipv4.firewall` と `ipv6.firewall` という 2 つのキーを追加します。 +`false` に設置すると `iptables` の FORWARDING ルールの生成をしないように +なります。 NAT ルールは対応する `ipv4.nat` や `ipv6.nat` キーが `true` に +設定されている限り引き続き追加されます。 -Rules necessary for `dnsmasq` to work (DHCP/DNS) will always be applied if -`dnsmasq` is enabled on the bridge. +ブリッジに対して `dnsmasq` が有効な場合、 `dnsmasq` が機能する（DHCP/DNS） +ために必要なルールは常に適用されます。 ## `network_routes` -Introduces `ipv4.routes` and `ipv6.routes` which allow routing additional subnets to a Incus bridge. +`ipv4.routes` と `ipv6.routes` を導入します。これらは Incus ブリッジに +追加のサブネットをルーティングできるようにします。 ## `storage` -Storage management API for Incus. +Incus のストレージ管理 API 。 -This includes: +これは次のものを含みます。 * `GET /1.0/storage-pools` -* `POST /1.0/storage-pools` (see [RESTful API](rest-api.md) for details) +* `POST /1.0/storage-pools`（詳細は [RESTful API](rest-api.md) を参照） -* `GET /1.0/storage-pools/` (see [RESTful API](rest-api.md) for details) -* `POST /1.0/storage-pools/` (see [RESTful API](rest-api.md) for details) -* `PUT /1.0/storage-pools/` (see [RESTful API](rest-api.md) for details) -* `PATCH /1.0/storage-pools/` (see [RESTful API](rest-api.md) for details) -* `DELETE /1.0/storage-pools/` (see [RESTful API](rest-api.md) for details) +* `GET /1.0/storage-pools/`（詳細は [RESTful API](rest-api.md) を参照） +* `POST /1.0/storage-pools/`（詳細は [RESTful API](rest-api.md) を参照） +* `PUT /1.0/storage-pools/`（詳細は [RESTful API](rest-api.md) を参照） +* `PATCH /1.0/storage-pools/`（詳細は [RESTful API](rest-api.md) を参照） +* `DELETE /1.0/storage-pools/`（詳細は [RESTful API](rest-api.md) を参照） -* `GET /1.0/storage-pools//volumes` (see [RESTful API](rest-api.md) for details) +* `GET /1.0/storage-pools//volumes`（詳細は [RESTful API](rest-api.md) を参照） -* `GET /1.0/storage-pools//volumes/` (see [RESTful API](rest-api.md) for details) -* `POST /1.0/storage-pools//volumes/` (see [RESTful API](rest-api.md) for details) +* `GET /1.0/storage-pools//volumes/`（詳細は [RESTful API](rest-api.md) を参照） +* `POST /1.0/storage-pools//volumes/`（詳細は [RESTful API](rest-api.md) を参照） -* `GET /1.0/storage-pools//volumes//` (see [RESTful API](rest-api.md) for details) -* `POST /1.0/storage-pools//volumes//` (see [RESTful API](rest-api.md) for details) -* `PUT /1.0/storage-pools//volumes//` (see [RESTful API](rest-api.md) for details) -* `PATCH /1.0/storage-pools//volumes//` (see [RESTful API](rest-api.md) for details) -* `DELETE /1.0/storage-pools//volumes//` (see [RESTful API](rest-api.md) for details) +* `GET /1.0/storage-pools//volumes//`（詳細は [RESTful API](rest-api.md) を参照） +* `POST /1.0/storage-pools//volumes//`（詳細は [RESTful API](rest-api.md) を参照） +* `PUT /1.0/storage-pools//volumes//`（詳細は [RESTful API](rest-api.md) を参照） +* `PATCH /1.0/storage-pools//volumes//`（詳細は [RESTful API](rest-api.md) を参照） +* `DELETE /1.0/storage-pools//volumes//`（詳細は [RESTful API](rest-api.md) を参照） -* All storage configuration options (see [Storage configuration](storage.md) for details) +* すべてのストレージ設定オプション（詳細は [ストレージの設定](storage.md) を参照） ## `file_delete` -Implements `DELETE` in `/1.0/containers//files` +`/1.0/containers//files` の DELETE メソッドを実装します。 ## `file_append` -Implements the `X-Incus-write` header which can be one of `overwrite` or `append`. +`X-Incus-write` ヘッダを実装しました。値は `overwrite` か `append` のいずれかです。 ## `network_dhcp_expiry` -Introduces `ipv4.dhcp.expiry` and `ipv6.dhcp.expiry` allowing to set the DHCP lease expiry time. +`ipv4.dhcp.expiry` と `ipv6.dhcp.expiry` を導入します。 DHCP のリース期限を設定 +できるようにします。 ## `storage_lvm_vg_rename` -Introduces the ability to rename a volume group by setting `storage.lvm.vg_name`. +`storage.lvm.vg_name` を設定することでボリュームグループをリネームできるようにします。 ## `storage_lvm_thinpool_rename` -Introduces the ability to rename a thin pool name by setting `storage.thinpool_name`. +`storage.thinpool_name` を設定することで thin pool をリネームできるようにします。 ## `network_vlan` -This adds a new `vlan` property to `macvlan` network devices. +`macvlan` ネットワークデバイスに `vlan` プロパティを新たに追加します。 -When set, this will instruct Incus to attach to the specified VLAN. Incus -will look for an existing interface for that VLAN on the host. If one -can't be found it will create one itself and then use that as the -macvlan parent. +これを設定すると、指定した VLAN にアタッチするように Incus に指示します。 +Incus はホスト上でその VLAN を持つ既存のインターフェースを探します。 +もし見つからない場合は Incus がインターフェースを作成して macvlan の親として +使用します。 ## `image_create_aliases` -Adds a new `aliases` field to `POST /1.0/images` allowing for aliases to -be set at image creation/import time. +`POST /1.0/images` に `aliases` フィールドを新たに追加します。イメージの +作成／インポート時にエイリアスを設定できるようになります。 ## `container_stateless_copy` -This introduces a new `live` attribute in `POST /1.0/containers/`. -Setting it to `false` tells Incus not to attempt running state transfer. +`POST /1.0/containers/` に `live` という属性を新たに導入します。 +`false` に設定すると、実行状態を転送しようとしないように Incus に伝えます。 ## `container_only_migration` -Introduces a new Boolean `container_only` attribute. When set to `true` only the -container will be copied or moved. +`container_only` という Boolean 型の属性を導入します。 `true` に設定すると +コンテナだけがコピーや移動されるようになります。 ## `storage_zfs_clone_copy` -Introduces a new Boolean `storage_zfs_clone_copy` property for ZFS storage -pools. When set to `false` copying a container will be done through `zfs send` and -receive. This will make the target container independent of its source -container thus avoiding the need to keep dependent snapshots in the ZFS pool -around. However, this also entails less efficient storage usage for the -affected pool. -The default value for this property is `true`, i.e. space-efficient snapshots -will be used unless explicitly set to `false`. +ZFS ストレージプールに `storage_zfs_clone_copy` という Boolean 型のプロパティを導入します。 +`false` に設定すると、コンテナのコピーは `zfs send` と receive 経由で行われる +ようになります。これにより作成先のコンテナは作成元のコンテナに依存しないように +なり、 ZFS プールに依存するスナップショットを維持する必要がなくなります。 +しかし、これは影響するプールのストレージの使用状況が以前より非効率的になる +という結果を伴います。 +このプロパティのデフォルト値は `true` です。つまり明示的に `false` に設定 +しない限り、空間効率の良いスナップショットが使われます。 ## `unix_device_rename` -Introduces the ability to rename the `unix-block`/`unix-char` device inside container by setting `path`, -and the `source` attribute is added to specify the device on host. -If `source` is set without a `path`, we should assume that `path` will be the same as `source`. -If `path` is set without `source` and `major`/`minor` isn't set, -we should assume that `source` will be the same as `path`. -So at least one of them must be set. +`path` を設定することによりコンテナ内部で `unix-block`/`unix-char` デバイスをリネーム +できるようにし、ホスト上のデバイスを指定する `source` 属性が追加されます。 +`path` を設定せずに `source` を設定すると、 `path` は `source` と同じものとして +扱います。 `source` や `major`/`minor` を設定せずに `path` を設定すると +`source` は `path` と同じものとして扱います。ですので、最低どちらか 1 つは +設定しなければなりません。 ## `storage_rsync_bwlimit` -When `rsync` has to be invoked to transfer storage entities setting `rsync.bwlimit` -places an upper limit on the amount of socket I/O allowed. +ストレージエンティティを転送するために `rsync` が起動される場合に +`rsync.bwlimit` を設定すると使用できるソケット I/O の量に上限を +設定します。 ## `network_vxlan_interface` -This introduces a new `tunnel.NAME.interface` option for networks. +ネットワークに `tunnel.NAME.interface` オプションを新たに導入します。 -This key control what host network interface is used for a VXLAN tunnel. +このキーは VXLAN トンネルにホストのどのネットワークインターフェースを使うかを +制御します。 ## `storage_btrfs_mount_options` -This introduces the `btrfs.mount_options` property for Btrfs storage pools. +Btrfs ストレージプールに `btrfs.mount_options` プロパティを導入します。 -This key controls what mount options will be used for the Btrfs storage pool. +このキーは Btrfs ストレージプールに使われるマウントオプションを制御します。 ## `entity_description` -This adds descriptions to entities like containers, snapshots, networks, storage pools and volumes. +これはエンティティにコンテナ、スナップショット、ストレージプール、ボリュームの +ような説明を追加します。 ## `image_force_refresh` -This allows forcing a refresh for an existing image. +既存のイメージを強制的にリフレッシュできます。 ## `storage_lvm_lv_resizing` -This introduces the ability to resize logical volumes by setting the `size` -property in the containers root disk device. +これはコンテナの root ディスクデバイス内に `size` プロパティを設定することで +論理ボリュームをリサイズできるようにします。 ## `id_map_base` -This introduces a new `security.idmap.base` allowing the user to skip the -map auto-selection process for isolated containers and specify what host -UID/GID to use as the base. +これは `security.idmap.base` を新しく導入します。これにより分離されたコンテナ +に map auto-selection するプロセスをスキップし、ホストのどの UID/GID をベース +として使うかをユーザーが指定できるようにします。 ## `file_symlinks` -This adds support for transferring symlinks through the file API. -X-Incus-type can now be `symlink` with the request content being the target path. +これは file API 経由でシンボリックリンクを転送するサポートを追加します。 +X-Incus-type に `symlink` を指定できるようになり、リクエストの内容はターゲットの +パスを指定します。 ## `container_push_target` -This adds the `target` field to `POST /1.0/containers/` which can be -used to have the source Incus host connect to the target during migration. +`POST /1.0/containers/` に `target` フィールドを新たに追加します。 +これはマイグレーション中に作成元の Incus ホストが作成先に接続するために +利用可能です。 ## `network_vlan_physical` -Allows use of `vlan` property with `physical` network devices. +`physical` ネットワークデバイスで `vlan` プロパティが使用できるようにします。 -When set, this will instruct Incus to attach to the specified VLAN on the `parent` interface. -Incus will look for an existing interface for that `parent` and VLAN on the host. -If one can't be found it will create one itself. -Then, Incus will directly attach this interface to the container. +設定すると、 `parent` インターフェース上で指定された VLAN にアタッチするように +Incus に指示します。 Incus はホスト上でその `parent` と VLAN を既存のインターフェース +で探します。 +見つからない場合は作成します。 +その後コンテナにこのインターフェースを直接アタッチします。 ## `storage_images_delete` -This enabled the storage API to delete storage volumes for images from -a specific storage pool. +これは指定したストレージプールからイメージのストレージボリュームを +ストレージ API で削除できるようにします。 ## `container_edit_metadata` -This adds support for editing a container `metadata.yaml` and related templates -via API, by accessing URLs under `/1.0/containers//metadata`. It can be used -to edit a container before publishing an image from it. +これはコンテナの `metadata.yaml` と関連するテンプレートを +`/1.0/containers//metadata` 配下の URL にアクセスすることにより +API で編集できるようにします。コンテナからイメージを発行する前にコンテナを +編集できるようになります。 ## `container_snapshot_stateful_migration` -This enables migrating stateful container snapshots to new containers. +これは stateful なコンテナのスナップショットを新しいコンテナにマイグレート +できるようにします。 ## `storage_driver_ceph` -This adds a Ceph storage driver. +これは Ceph ストレージドライバーを追加します。 ## `storage_ceph_user_name` -This adds the ability to specify the Ceph user. +これは Ceph ユーザーを指定できるようにします。 ## `instance_types` -This adds the `instance_type` field to the container creation request. -Its value is expanded to Incus resource limits. +これはコンテナの作成リクエストに `instance_type` フィールドを追加します。 +値は Incus のリソース制限に展開されます。 ## `storage_volatile_initial_source` -This records the actual source passed to Incus during storage pool creation. +これはストレージプール作成中に Incus に渡された実際の作成元を記録します。 ## `storage_ceph_force_osd_reuse` -This introduces the `ceph.osd.force_reuse` property for the Ceph storage -driver. When set to `true` Incus will reuse an OSD storage pool that is already in -use by another Incus instance. +これは Ceph ストレージドライバーに `ceph.osd.force_reuse` プロパティを +導入します。 `true` に設定すると Incus は別の Incus インスタンスで既に使用中の +OSD ストレージプールを再利用するようになります。 ## `storage_block_filesystem_btrfs` -This adds support for Btrfs as a storage volume file system, in addition to `ext4` -and `xfs`. +これは `ext4` と `xfs` に加えて Btrfs をストレージボリュームファイルシステムとして +サポートするようになります。 ## `resources` -This adds support for querying a Incus daemon for the system resources it has -available. +これは Incus が利用可能なシステムリソースを Incus デーモンに問い合わせできるようにします。 ## `kernel_limits` -This adds support for setting process limits such as maximum number of open -files for the container via `nofile`. The format is `limits.kernel.[limit name]`. +これは `nofile` でコンテナがオープンできるファイルの最大数といったプロセスの +リミットを設定できるようにします。形式は `limits.kernel.[リミット名]` です。 ## `storage_api_volume_rename` -This adds support for renaming custom storage volumes. +これはカスタムストレージボリュームをリネームできるようにします。 ## `network_sriov` -This adds support for SR-IOV enabled network devices. +これは SR-IOV を有効にしたネットワークデバイスのサポートを追加します。 ## `console` -This adds support to interact with the container console device and console log. +これはコンテナのコンソールデバイスとコンソールログを利用可能にします。 ## `restrict_dev_incus` -A new `security.guestapi` container configuration key was introduced. -The key controls whether the `/dev/incus` interface is made available to the container. -If set to `false`, this effectively prevents the container from interacting with the Incus daemon. +`security.guestapi` コンテナ設定キーを新たに導入します。このキーは `/dev/incus` +インターフェースがコンテナで利用可能になるかを制御します。 +`false` に設定すると、コンテナが Incus デーモンと連携するのを実質無効に +することになります。 ## `migration_pre_copy` -This adds support for optimized memory transfer during live migration. +これはライブマイグレーション中に最適化されたメモリー転送をできるようにします。 ## `infiniband` -This adds support to use InfiniBand network devices. +これは InfiniBand ネットワークデバイスを使用できるようにします。 ## `dev_incus_events` -This adds a WebSocket API to the `/dev/incus` socket. +これは `/dev/incus` ソケットに Websocket API を追加します。 -When connecting to `/1.0/events` over the `/dev/incus` socket, you will now be -getting a stream of events over WebSocket. +`/dev/incus` ソケット上で `/1.0/events` に接続すると、 Websocket 上で +イベントのストリームを受け取れるようになります。 ## `proxy` -This adds a new `proxy` device type to containers, allowing forwarding -of connections between the host and container. +これはコンテナに `proxy` という新しいデバイスタイプを追加します。 +これによりホストとコンテナ間で接続をフォワーディングできるようになります。 ## `network_dhcp_gateway` -Introduces a new `ipv4.dhcp.gateway` network configuration key to set an alternate gateway. +代替のゲートウェイを設定するための `ipv4.dhcp.gateway` ネットワーク設定キーを +新たに追加します。 ## `file_get_symlink` -This makes it possible to retrieve symlinks using the file API. +これは file API を使ってシンボリックリンクを取得できるようにします。 ## `network_leases` -Adds a new `/1.0/networks/NAME/leases` API endpoint to query the lease database on -bridges which run a Incus-managed DHCP server. +`/1.0/networks/NAME/leases` API エンドポイントを追加します。 Incus が管理する +DHCP サーバーが稼働するブリッジ上のリースデータベースに問い合わせできるように +なります。 ## `unix_device_hotplug` -This adds support for the `required` property for Unix devices. +これは Unix デバイスに `required` プロパティのサポートを追加します。 ## `storage_api_local_volume_handling` -This add the ability to copy and move custom storage volumes locally in the -same and between storage pools. +これはカスタムストレージボリュームを同じあるいは異なるストレージプール間で +コピーしたり移動したりできるようにします。 ## `operation_description` -Adds a `description` field to all operations. +すべての操作に `description` フィールドを追加します。 ## `clustering` -Clustering API for Incus. +Incus のクラスタリング API 。 -This includes the following new endpoints (see [RESTful API](rest-api.md) for details): +これは次の新しいエンドポイントを含みます（詳細は [RESTful API](rest-api.md) を参照）: * `GET /1.0/cluster` * `UPDATE /1.0/cluster` @@ -495,44 +510,43 @@ This includes the following new endpoints (see [RESTful API](rest-api.md) for de * `POST /1.0/cluster/members/` * `DELETE /1.0/cluster/members/` -The following existing endpoints have been modified: +次の既存のエンドポイントは以下のように変更されます: -* `POST /1.0/containers` accepts a new `target` query parameter -* `POST /1.0/storage-pools` accepts a new `target` query parameter -* `GET /1.0/storage-pool/` accepts a new `target` query parameter -* `POST /1.0/storage-pool//volumes/` accepts a new `target` query parameter -* `GET /1.0/storage-pool//volumes//` accepts a new `target` query parameter -* `POST /1.0/storage-pool//volumes//` accepts a new `target` query parameter -* `PUT /1.0/storage-pool//volumes//` accepts a new `target` query parameter -* `PATCH /1.0/storage-pool//volumes//` accepts a new `target` query parameter -* `DELETE /1.0/storage-pool//volumes//` accepts a new `target` query parameter -* `POST /1.0/networks` accepts a new `target` query parameter -* `GET /1.0/networks/` accepts a new `target` query parameter +* `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` -This adds a new `lifecycle` message type to the events API. +これはイベント API に `lifecycle` メッセージ種別を新たに追加します。 ## `storage_api_remote_volume_handling` -This adds the ability to copy and move custom storage volumes between remote. +これはリモート間でカスタムストレージボリュームをコピーや移動できるようにします。 ## `nvidia_runtime` -Adds a `nvidia_runtime` configuration option for containers, setting this to -`true` will have the NVIDIA runtime and CUDA libraries passed to the -container. +コンテナに `nvidia_runtime` という設定オプションを追加します。これを `true` に +設定すると NVIDIA ランタイムと CUDA ライブラリーがコンテナに渡されます。 ## `container_mount_propagation` -This adds a new `propagation` option to the disk device type, allowing -the configuration of kernel mount propagation. +これはディスクデバイスタイプに `propagation` オプションを新たに追加します。 +これによりカーネルのマウントプロパゲーションの設定ができるようになります。 ## `container_backup` -Add container backup support. +コンテナのバックアップサポートを追加します。 -This includes the following new endpoints (see [RESTful API](rest-api.md) for details): +これは次のエンドポイントを新たに追加します（詳細は [RESTful API](rest-api.md) を参照）: * `GET /1.0/containers//backups` * `POST /1.0/containers//backups` @@ -543,29 +557,30 @@ This includes the following new endpoints (see [RESTful API](rest-api.md) for de * `GET /1.0/containers//backups//export` -The following existing endpoint has been modified: +次の既存のエンドポイントは以下のように変更されます: -* `POST /1.0/containers` accepts the new source type `backup` +* `POST /1.0/containers` 新たな作成元の種別 `backup` を受け付けるようになります ## `dev_incus_images` -Adds a `security.guestapi.images` configuration option for containers which -controls the availability of a `/1.0/images/FINGERPRINT/export` API over -`/dev/incus`. This can be used by a container running nested Incus to access raw -images from the host. +コンテナに `security.guestapi.images` 設定オプションを追加します。これに +より `/dev/incus` 上で `/1.0/images/FINGERPRINT/export` API が利用可能に +なります。 nested Incus を動かすコンテナがホストから生のイメージを +取得するためにこれは利用できます。 ## `container_local_cross_pool_handling` -This enables copying or moving containers between storage pools on the same Incus -instance. +これは同じ Incus インスタンス上のストレージプール間でコンテナをコピー・移動 +できるようにします。 ## `proxy_unix` -Add support for both Unix sockets and abstract Unix sockets in proxy devices. -They can be used by specifying the address as `unix:/path/to/unix.sock` (normal -socket) or `unix:@/tmp/unix.sock` (abstract socket). +proxy デバイスで Unix ソケットと abstract Unix ソケットの両方のサポートを +追加します。これらは `unix:/path/to/unix.sock`（通常のソケット）あるいは +`unix:@/tmp/unix.sock`（abstract ソケット）のようにアドレスを指定して +利用可能です。 -Supported connections are now: +現状サポートされている接続は次のとおりです: * `TCP <-> TCP` * `UNIX <-> UNIX` @@ -574,9 +589,9 @@ Supported connections are now: ## `proxy_udp` -Add support for UDP in proxy devices. +proxy デバイスで UDP のサポートを追加します。 -Supported connections are now: +現状サポートされている接続は次のとおりです: * `TCP <-> TCP` * `UNIX <-> UNIX` @@ -588,85 +603,90 @@ Supported connections are now: ## `clustering_join` -This makes `GET /1.0/cluster` return information about which storage pools and -networks are required to be created by joining nodes and which node-specific -configuration keys they are required to use when creating them. Likewise the `PUT -/1.0/cluster` endpoint now accepts the same format to pass information about -storage pools and networks to be automatically created before attempting to join -a cluster. +これにより `GET /1.0/cluster` がノードに参加する際にどのようなストレージプールと +ネットワークを作成する必要があるかについての情報を返します。また、それらを作成する +際にどのノード固有の設定キーを使う必要があるかについての情報も返します。 +同様に `PUT /1.0/cluster` エンドポイントも同じ形式でストレージプールとネットワークに +ついての情報を受け付け、クラスタに参加する前にこれらが自動的に作成されるようになります。 ## `proxy_tcp_udp_multi_port_handling` -Adds support for forwarding traffic for multiple ports. Forwarding is allowed -between a range of ports if the port range is equal for source and target -(for example `1.2.3.4 0-1000 -> 5.6.7.8 1000-2000`) and between a range of source -ports and a single target port (for example `1.2.3.4 0-1000 -> 5.6.7.8 1000`). +複数のポートにトラフィックをフォワーディングできるようにします。フォワーディングは +ポートの範囲が転送元と転送先で同じ（たとえば `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` -Adds support for retrieving a network's state. +ネットワークの状態を取得できるようになります。 -This adds the following new endpoint (see [RESTful API](rest-api.md) for details): +これは次のエンドポイントを新たに追加します（詳細は [RESTful API](rest-api.md) を参照）: * `GET /1.0/networks//state` ## `proxy_unix_dac_properties` -This adds support for GID, UID, and mode properties for non-abstract Unix -sockets. +これは抽象的 Unix ソケットではない Unix ソケットに GID、UID、パーミションのプロパティを追加します。 ## `container_protection_delete` -Enables setting the `security.protection.delete` field which prevents containers -from being deleted if set to `true`. Snapshots are not affected by this setting. +`security.protection.delete` フィールドを設定できるようにします。 `true` に設定すると +コンテナが削除されるのを防ぎます。スナップショットはこの設定により影響を受けません。 ## `proxy_priv_drop` -Adds `security.uid` and `security.gid` for the proxy devices, allowing -privilege dropping and effectively changing the UID/GID used for -connections to Unix sockets too. +proxy デバイスに `security.uid` と `security.gid` を追加します。これは root 権限を +落とし（訳注: 非 root 権限で動作させるという意味です）、 Unix ソケットに接続する +際に用いられる UID/GID も変更します。 ## `pprof_http` -This adds a new `core.debug_address` configuration option to start a debugging HTTP server. +これはデバッグ用の HTTP サーバーを起動するために、新たに `core.debug_address` +オプションを追加します。 -That server currently includes a `pprof` API and replaces the old -`cpu-profile`, `memory-profile` and `print-goroutines` debug options. +このサーバーは現在`pprof` API を含んでおり、従来の`cpu-profile`, `memory-profile` +と`print-goroutines`デバッグオプションを置き換えるものです。 ## `proxy_haproxy_protocol` -Adds a `proxy_protocol` key to the proxy device which controls the use of the HAProxy PROXY protocol header. +proxy デバイスに `proxy_protocol` キーを追加します。これは HAProxy PROXY プロトコルヘッダ +の使用を制御します。 ## `network_hwaddr` -Adds a `bridge.hwaddr` key to control the MAC address of the bridge. +ブリッジの MAC アドレスを制御する `bridge.hwaddr` キーを追加します。 ## `proxy_nat` -This adds optimized UDP/TCP proxying. If the configuration allows, proxying -will be done via `iptables` instead of proxy devices. +これは最適化された UDP/TCP プロキシを追加します。設定上可能であれば +プロキシ処理は proxy デバイスの代わりに `iptables` 経由で行われるように +なります。 ## `network_nat_order` -This introduces the `ipv4.nat.order` and `ipv6.nat.order` configuration keys for Incus bridges. -Those keys control whether to put the Incus rules before or after any pre-existing rules in the chain. +Incus ブリッジに `ipv4.nat.order` と `ipv6.nat.order` 設定キーを導入します。 +これらのキーは Incus のルールをチェイン内の既存のルールの前に置くか後に置くかを +制御します。 ## `container_full` -This introduces a new `recursion=2` mode for `GET /1.0/containers` which allows for the retrieval of -all container structs, including the state, snapshots and backup structs. +これは `GET /1.0/containers` に `recursion=2` という新しいモードを導入します。 +これにより状態、スナップショットとバックアップの構造を含むコンテナのすべての構造を +取得できるようになります。 -This effectively allows for [`incus list`](incus_list.md) to get all it needs in one query. +この結果 [`incus list`](incus_list.md) は必要なすべての情報を 1 つのクエリで取得できるように +なります。 ## `backup_compression` -This introduces a new `backups.compression_algorithm` configuration key which -allows configuration of backup compression. +これは新たに `backups.compression_algorithm` 設定キーを導入します。 +これによりバックアップの圧縮の設定が可能になります。 ## `nvidia_runtime_config` -This introduces a few extra configuration keys when using `nvidia.runtime` and the `libnvidia-container` library. -Those keys translate pretty much directly to the matching NVIDIA container environment variables: +これは `nvidia.runtime` と `libnvidia-container` ライブラリーを使用する際に追加の +いくつかの設定キーを導入します。これらのキーは NVIDIA container の対応する +環境変数にほぼそのまま置き換えられます: * `nvidia.driver.capabilities` => `NVIDIA_DRIVER_CAPABILITIES` * `nvidia.require.cuda` => `NVIDIA_REQUIRE_CUDA` @@ -674,10 +694,11 @@ Those keys translate pretty much directly to the matching NVIDIA container envir ## `storage_api_volume_snapshots` -Add support for storage volume snapshots. They work like container snapshots, -only for volumes. +ストレージボリュームスナップショットのサポートを追加します。これらは +コンテナスナップショットのように振る舞いますが、ボリュームに対してのみ +作成できます。 -This adds the following new endpoint (see [RESTful API](rest-api.md) for details): +これにより次の新しいエンドポイントが追加されます（詳細は [RESTful API](rest-api.md) を参照）: * `GET /1.0/storage-pools//volumes///snapshots` * `POST /1.0/storage-pools//volumes///snapshots` @@ -689,527 +710,504 @@ This adds the following new endpoint (see [RESTful API](rest-api.md) for details ## `storage_unmapped` -Introduces a new `security.unmapped` Boolean on storage volumes. +ストレージボリュームに新たに `security.unmapped` という Boolean 設定を導入します。 -Setting it to `true` will flush the current map on the volume and prevent -any further idmap tracking and remapping on the volume. +`true` に設定するとボリューム上の現在のマップをフラッシュし、以降の +idmap のトラッキングとボリューム上のリマッピングを防ぎます。 -This can be used to share data between isolated containers after -attaching it to the container which requires write access. +これは隔離されたコンテナ間でデータを共有するために使用できます。 +この際コンテナを書き込みアクセスを要求するコンテナにアタッチした +後にデータを共有します。 ## `projects` -Add a new project API, supporting creation, update and deletion of projects. +新たに project API を追加します。プロジェクトの作成、更新、削除ができます。 -Projects can hold containers, profiles or images at this point and let -you get a separate view of your Incus resources by switching to it. +現時点では、プロジェクトは、コンテナ、プロファイル、イメージを保持できます。そして、プロジェクトを切り替えることで、独立した Incus リソースのビューを見せられます。 ## `network_vxlan_ttl` -This adds a new `tunnel.NAME.ttl` network configuration option which -makes it possible to raise the TTL on VXLAN tunnels. +新たにネットワークの設定に `tunnel.NAME.ttl` が指定できるようになります。これにより、VXLAN トンネルの TTL を増加させることができます。 ## `container_incremental_copy` -This adds support for incremental container copy. When copying a container -using the `--refresh` flag, only the missing or outdated files will be -copied over. Should the target container not exist yet, a normal copy operation -is performed. +新たにコンテナのインクリメンタルコピーができるようになります。`--refresh` オプションを指定してコンテナをコピーすると、見つからないファイルや、更新されたファイルのみを +コピーします。コンテナが存在しない場合は、通常のコピーを実行します。 ## `usb_optional_vendorid` -As the name implies, the `vendorid` field on USB devices attached to -containers has now been made optional, allowing for all USB devices to -be passed to a container (similar to what's done for GPUs). +名前が暗示しているように、コンテナにアタッチされた USB デバイスの +`vendorid` フィールドが省略可能になります。これによりすべての USB デバイスが +コンテナに渡されます (GPU に対してなされたのと同様)。 ## `snapshot_scheduling` -This adds support for snapshot scheduling. It introduces three new -configuration keys: `snapshots.schedule`, `snapshots.schedule.stopped`, and -`snapshots.pattern`. Snapshots can be created automatically up to every minute. +これはスナップショットのスケジューリングのサポートを追加します。これにより +3 つの新しい設定キーが導入されます。 `snapshots.schedule`、`snapshots.schedule.stopped`、 +そして `snapshots.pattern` です。スナップショットは最短で 1 分間隔で自動的に +作成されます。 ## `snapshots_schedule_aliases` -Snapshot schedule can be configured by a comma-separated list of schedule aliases. -Available aliases are `<@hourly> <@daily> <@midnight> <@weekly> <@monthly> <@annually> <@yearly> <@startup>` for instances, -and `<@hourly> <@daily> <@midnight> <@weekly> <@monthly> <@annually> <@yearly>` for storage volumes. +スナップショットのスケジュールはスケジュールエイリアスのカンマ区切りリストで設定できます。 +インスタンスには `<@hourly> <@daily> <@midnight> <@weekly> <@monthly> <@annually> <@yearly> <@startup>`、 +ストレージボリュームには `<@hourly> <@daily> <@midnight> <@weekly> <@monthly> <@annually> <@yearly>` のエイリアスが利用できます。 ## `container_copy_project` -Introduces a `project` field to the container source JSON object, allowing for -copy/move of containers between projects. +コピー元のコンテナの dict に `project` フィールドを導入します。これにより +プロジェクト間でコンテナをコピーあるいは移動できるようになります。 ## `clustering_server_address` -This adds support for configuring a server network address which differs from -the REST API client network address. When bootstrapping a new cluster, clients -can set the new `cluster.https_address` configuration key to specify the address of -the initial server. When joining a new server, clients can set the -`core.https_address` configuration key of the joining server to the REST API -address the joining server should listen at, and set the `server_address` -key in the `PUT /1.0/cluster` API to the address the joining server should -use for clustering traffic (the value of `server_address` will be -automatically copied to the `cluster.https_address` configuration key of the -joining server). +これはサーバーのネットワークアドレスを REST API のクライアントネットワーク +アドレスと異なる値に設定することのサポートを追加します。クライアントは +新しい `cluster.https_address` 設定キーを初期のサーバーのアドレスを指定するために +に設定できます。新しいサーバーが参加する際、クライアントは参加するサーバーの +`core.https_address` 設定キーを参加するサーバーがリッスンすべきアドレスに設定でき、 +`PUT /1.0/cluster` API の `server_address` キーを参加するサーバーが +クラスタリングトラフィックに使用すべきアドレスに設定できます（`server_address` +の値は自動的に参加するサーバーの `cluster.https_address` 設定キーに +コピーされます）。 ## `clustering_image_replication` -Enable image replication across the nodes in the cluster. -A new `cluster.images_minimal_replica` configuration key was introduced can be used -to specify to the minimal numbers of nodes for image replication. +クラスタ内のノードをまたいだイメージのレプリケーションを可能にします。 +新しい `cluster.images_minimal_replica` 設定キーが導入され、イメージの +レプリケーションに対するノードの最小数を指定するのに使用できます。 ## `container_protection_shift` -Enables setting the `security.protection.shift` option which prevents containers -from having their file system shifted. +`security.protection.shift` の設定を可能にします。これによりコンテナの +ファイルシステム上で UID/GID をシフト (再マッピング) させることを防ぎます。 ## `snapshot_expiry` -This adds support for snapshot expiration. The task is run minutely. The configuration -option `snapshots.expiry` takes an expression in the form of `1M 2H 3d 4w 5m -6y` (1 minute, 2 hours, 3 days, 4 weeks, 5 months, 6 years), however not all -parts have to be used. +これはスナップショットの有効期限のサポートを追加します。タスクは 1 分おきに実行されます。 +`snapshots.expiry` 設定オプションは、`1M 2H 3d 4w 5m 6y` （それぞれ 1 分、2 時間、3 日、4 週間、5 ヶ月、6 年）といった形式を取ります。 +この指定ではすべての部分を使う必要はありません。 -Snapshots which are then created will be given an expiry date based on the -expression. This expiry date, defined by `expires_at`, can be manually edited -using the API or [`incus config edit`](incus_config_edit.md). Snapshots with a valid expiry date will be -removed when the task in run. Expiry can be disabled by setting `expires_at` to -an empty string or `0001-01-01T00:00:00Z` (zero time). This is the default if -`snapshots.expiry` is not set. +作成されるスナップショットには、指定した式に基づいて有効期限が設定されます。 +`expires_at` で定義される有効期限は、API や [`incus config edit`](incus_config_edit.md) コマンドを使って手動で編集できます。 +有効な有効期限が設定されたスナップショットはタスク実行時に削除されます。 +有効期限は `expires_at` に空文字列や `0001-01-01T00:00:00Z`（zero time）を設定することで無効化できます。 +`snapshots.expiry` が設定されていない場合はこれがデフォルトです。 -This adds the following new endpoint (see [RESTful API](rest-api.md) for details): +これは次のような新しいエンドポイントを追加します（詳しくは [RESTful API](rest-api.md) をご覧ください）: * `PUT /1.0/containers//snapshots/` ## `snapshot_expiry_creation` -Adds `expires_at` to container creation, allowing for override of a -snapshot's expiry at creation time. +コンテナ作成に `expires_at` を追加し、作成時にスナップショットの有効期限を上書きできます。 ## `network_leases_location` -Introduces a `Location` field in the leases list. -This is used when querying a cluster to show what node a particular -lease was found on. +ネットワークのリースリストに `Location` フィールドを導入します。 +これは、特定のリースがどのノードに存在するかを問い合わせるときに使います。 ## `resources_cpu_socket` -Add Socket field to CPU resources in case we get out of order socket information. +ソケットの情報が入れ替わる場合に備えて CPU リソースにソケットフィールドを追加します。 ## `resources_gpu` -Add a new GPU struct to the server resources, listing all usable GPUs on the system. +サーバーリソースに新規に GPU 構造を追加し、システム上で利用可能なすべての GPU を一覧表示します。 ## `resources_numa` -Shows the NUMA node for all CPUs and GPUs. +すべての CPU と GPU に対する NUMA ノードを表示します。 ## `kernel_features` -Exposes the state of optional kernel features through the server environment. +サーバーの環境からオプショナルなカーネル機能の使用可否状態を取得します。 ## `id_map_current` -This introduces a new internal `volatile.idmap.current` key which is -used to track the current mapping for the container. +内部的な `volatile.idmap.current` キーを新規に導入します。これはコンテナに +対する現在のマッピングを追跡するのに使われます。 -This effectively gives us: +実質的には以下が利用可能になります: -* `volatile.last_state.idmap` => On-disk idmap -* `volatile.idmap.current` => Current kernel map -* `volatile.idmap.next` => Next on-disk idmap +* `volatile.last_state.idmap` => ディスク上の idmap +* `volatile.idmap.current` => 現在のカーネルマップ +* `volatile.idmap.next` => 次のディスク上の idmap -This is required to implement environments where the on-disk map isn't -changed but the kernel map is (e.g. `shiftfs`). +これはディスク上の map が変更されていないがカーネルマップは変更されている +（例: `shiftfs`）ような環境を実装するために必要です。 ## `event_location` -Expose the location of the generation of API events. +API イベントの世代の場所を公開します。 ## `storage_api_remote_volume_snapshots` -This allows migrating storage volumes including their snapshots. +ストレージボリュームをそれらのスナップショットを含んで移行できます。 ## `network_nat_address` -This introduces the `ipv4.nat.address` and `ipv6.nat.address` configuration keys for Incus bridges. -Those keys control the source address used for outbound traffic from the bridge. +これは Incus ブリッジに `ipv4.nat.address` と `ipv6.nat.address` 設定キーを導入します。 +これらのキーはブリッジからの送信トラフィックに使うソースアドレスを制御します。 ## `container_nic_routes` -This introduces the `ipv4.routes` and `ipv6.routes` properties on `nic` type devices. -This allows adding static routes on host to container's NIC. +これは `nic` タイプのデバイスに `ipv4.routes` と `ipv6.routes` プロパティを導入します。 +ホストからコンテナへの NIC への静的ルートが追加できます。 ## `cluster_internal_copy` -This makes it possible to do a normal `POST /1.0/containers` to copy a -container between cluster nodes with Incus internally detecting whether a -migration is required. +これは通常の `POST /1.0/containers` を実行することでクラスタノード間で +コンテナをコピーすることを可能にします。この際 Incus はマイグレーションが +必要かどうかを内部的に判定します。 ## `seccomp_notify` -If the kernel supports `seccomp`-based syscall interception Incus can be notified -by a container that a registered syscall has been performed. Incus can then -decide to trigger various actions. +カーネルが `seccomp` ベースの syscall インターセプトをサポートする場合に +登録された syscall が実行されたことをコンテナから Incus に通知することが +できます。 Incus はそれを受けて様々なアクションをトリガーするかを決定します。 ## `lxc_features` -This introduces the `lxc_features` section output from the [`incus info`](incus_info.md) command -via the `GET /1.0` route. It outputs the result of checks for key features being present in the -underlying LXC library. +これは `GET /1.0` ルート経由で [`incus info`](incus_info.md) コマンドの出力に `lxc_features` +セクションを導入します。配下の LXC ライブラリーに存在するキー・フィーチャーに +対するチェックの結果を出力します。 ## `container_nic_ipvlan` -This introduces the `ipvlan` `nic` device type. +これは `nic` デバイスに `ipvlan` のタイプを導入します。 ## `network_vlan_sriov` -This introduces VLAN (`vlan`) and MAC filtering (`security.mac_filtering`) support for SR-IOV devices. +これは SR-IOV デバイスに VLAN（`vlan`）と MAC フィルタリング（`security.mac_filtering`）のサポートを導入します。 ## `storage_cephfs` -Add support for CephFS as a storage pool driver. This can only be used -for custom volumes, images and containers should be on Ceph (RBD) -instead. +ストレージプールドライバーとして CephFS のサポートを追加します。これは +カスタムボリュームとしての利用のみが可能になり、イメージとコンテナは +CephFS ではなく Ceph（RBD）上に構築する必要があります。 ## `container_nic_ipfilter` -This introduces container IP filtering (`security.ipv4_filtering` and `security.ipv6_filtering`) support for `bridged` NIC devices. +これは `bridged` の NIC デバイスに対してコンテナの IP フィルタリング +（`security.ipv4_filtering` と `security.ipv6_filtering`）を導入します。 ## `resources_v2` -Rework the resources API at `/1.0/resources`, especially: +`/1.0/resources` のリソース API を見直しました。主な変更は以下の通りです: * CPU - * Fix reporting to track sockets, cores and threads - * Track NUMA node per core - * Track base and turbo frequency per socket - * Track current frequency per core - * Add CPU cache information - * Export the CPU architecture - * Show online/offline status of threads -* Memory - * Add huge-pages tracking - * Track memory consumption per NUMA node too + * ソケット、コア、スレッドのトラッキングのレポートを修正しました + * コア毎の NUMA ノードのトラッキング + * ソケット毎のベースとターボの周波数のトラッキング + * コア毎の現在の周波数のトラッキング + * CPU のキャッシュ情報の追加 + * CPU アーキテクチャをエクスポート + * スレッドのオンライン／オフライン状態を表示 +* メモリー + * HugePages のトラッキングを追加 + * NUMA ノード毎でもメモリー消費を追跡 * GPU - * Split DRM information to separate struct - * Export device names and nodes in DRM struct - * Export device name and node in NVIDIA struct - * Add SR-IOV VF tracking + * DRM 情報を別の構造体に分離 + * DRM 構造体内にデバイスの名前とノードを公開 + * NVIDIA 構造体内にデバイスの名前とノードを公開 + * SR-IOV VF のトラッキングを追加 ## `container_exec_user_group_cwd` -Adds support for specifying `User`, `Group` and `Cwd` during `POST /1.0/containers/NAME/exec`. +`POST /1.0/containers/NAME/exec` の実行時に `User`、`Group` と `Cwd` を指定するサポートを追加します。 ## `container_syscall_intercept` -Adds the `security.syscalls.intercept.*` configuration keys to control -what system calls will be intercepted by Incus and processed with -elevated permissions. +`security.syscalls.intercept.*` 設定キーを追加します。これはどのシステムコールを Incus がインターセプトし昇格された権限で処理するかを制御します。 ## `container_disk_shift` -Adds the `shift` property on `disk` devices which controls the use of the `shiftfs` overlay. +`disk` デバイスに `shift` プロパティを追加します。これは `shiftfs` のオーバーレイの使用を制御します。 ## `storage_shifted` -Introduces a new `security.shifted` Boolean on storage volumes. +ストレージボリュームに新しく `security.shifted` という Boolean の設定を導入します。 -Setting it to `true` will allow multiple isolated containers to attach the -same storage volume while keeping the file system writable from all of -them. +これを `true` に設定すると複数の隔離されたコンテナが、それらすべてがファイルシステムに +書き込み可能にしたまま、同じストレージボリュームにアタッチするのを許可します。 -This makes use of `shiftfs` as an overlay file system. +これは `shiftfs` をオーバーレイファイルシステムとして使用します。 ## `resources_infiniband` -Export InfiniBand character device information (`issm`, `umad`, `uverb`) as part of the resources API. +リソース API の一部として InfiniBand キャラクタデバイス（`issm`、`umad`、`uverb`）の情報を公開します。 ## `daemon_storage` -This introduces two new configuration keys `storage.images_volume` and -`storage.backups_volume` to allow for a storage volume on an existing -pool be used for storing the daemon-wide images and backups artifacts. +これは `storage.images_volume` と `storage.backups_volume` という 2 つの新しい設定項目を導入します。これらは既存のプール上のストレージボリュームがデーモン全体のイメージとバックアップを保管するのに使えるようにします。 ## `instances` -This introduces the concept of instances, of which currently the only type is `container`. +これはインスタンスの概念を導入します。現状ではインスタンスの唯一の種別は `container` です。 ## `image_types` -This introduces support for a new Type field on images, indicating what type of images they are. +これはイメージに新しく Type フィールドのサポートを導入します。 Type フィールドはイメージがどういう種別かを示します。 ## `resources_disk_sata` -Extends the disk resource API struct to include: +ディスクリソース API の構造体を次の項目を含むように拡張します。 -* Proper detection of SATA devices (type) -* Device path -* Drive RPM -* Block size -* Firmware version -* Serial number +* SATA デバイス（種別）の適切な検出 +* デバイスパス +* ドライブの RPM +* ブロックサイズ +* ファームウェアバージョン +* シリアルナンバー ## `clustering_roles` -This adds a new `roles` attribute to cluster entries, exposing a list of -roles that the member serves in the cluster. +これはクラスタのエントリーに `roles` という新しい属性を追加し、クラスタ内のメンバーが提供する role の一覧を公開します。 ## `images_expiry` -This allows for editing of the expiry date on images. +イメージの有効期限を設定できます。 ## `resources_network_firmware` -Adds a `FirmwareVersion` field to network card entries. +ネットワークカードのエントリーに `FirmwareVersion` フィールドを追加します。 ## `backup_compression_algorithm` -This adds support for a `compression_algorithm` property when creating a backup (`POST /1.0/containers//backups`). +バックアップを作成する（`POST /1.0/containers//backups`）際に `compression_algorithm` プロパティのサポートを追加します。 -Setting this property overrides the server default value (`backups.compression_algorithm`). +このプロパティを設定するとデフォルト値（`backups.compression_algorithm`）をオーバーライドすることができます。 ## `ceph_data_pool_name` -This adds support for an optional argument (`ceph.osd.data_pool_name`) when creating -storage pools using Ceph RBD, when this argument is used the pool will store it's -actual data in the pool specified with `data_pool_name` while keeping the metadata -in the pool specified by `pool_name`. +Ceph RBD を使ってストレージプールを作成する際にオプショナルな引数（`ceph.osd.data_pool_name`）のサポートを追加します。 +この引数が指定されると、プールはメタデータは `pool_name` で指定されたプールに保持しつつ実際のデータは `data_pool_name` で指定されたプールに保管するようになります。 ## `container_syscall_intercept_mount` -Adds the `security.syscalls.intercept.mount`, -`security.syscalls.intercept.mount.allowed`, and -`security.syscalls.intercept.mount.shift` configuration keys to control whether -and how the `mount` system call will be intercepted by Incus and processed with -elevated permissions. +`security.syscalls.intercept.mount`、`security.syscalls.intercept.mount.allowed`、`security.syscalls.intercept.mount.shift` 設定キーを追加します。 +これらは `mount` システムコールを Incus にインターセプトさせるかどうか、昇格されたパーミションでどのように処理させるかを制御します。 ## `compression_squashfs` -Adds support for importing/exporting of images/backups using SquashFS file system format. +イメージやバックアップを SquashFS ファイルシステムの形式でインポート／エクスポートするサポートを追加します。 ## `container_raw_mount` -This adds support for passing in raw mount options for disk devices. +ディスクデバイスに raw mount オプションを渡すサポートを追加します。 ## `container_nic_routed` -This introduces the `routed` `nic` device type. +`routed` `nic` デバイスタイプを導入します。 ## `container_syscall_intercept_mount_fuse` -Adds the `security.syscalls.intercept.mount.fuse` key. It can be used to -redirect file-system mounts to their fuse implementation. To this end, set e.g. -`security.syscalls.intercept.mount.fuse=ext4=fuse2fs`. +`security.syscalls.intercept.mount.fuse` キーを追加します。これはファイルシステムのマウントを fuse 実装にリダイレクトするのに使えます。 +このためにはたとえば `security.syscalls.intercept.mount.fuse=ext4=fuse2fs` のように設定します。 ## `container_disk_ceph` -This allows for existing a Ceph RBD or CephFS to be directly connected to a Incus container. +既存の Ceph RBD もしくは CephFS を直接 Incus コンテナに接続できます。 ## `virtual-machines` -Add virtual machine support. +仮想マシンサポートが追加されます。 ## `image_profiles` -Allows a list of profiles to be applied to an image when launching a new container. +新しいコンテナを起動するときに、イメージに適用するプロファイルのリストが指定できます。 ## `clustering_architecture` -This adds a new `architecture` attribute to cluster members which indicates a cluster -member's architecture. +クラスタメンバーに `architecture` 属性を追加します。 +この属性はクラスタメンバーのアーキテクチャを示します。 ## `resources_disk_id` -Add a new `device_id` field in the disk entries on the resources API. +リソース API のディスクのエントリーに `device_id` フィールドを追加します。 ## `storage_lvm_stripes` -This adds the ability to use LVM stripes on normal volumes and thin pool volumes. +通常のボリュームと thin pool ボリューム上で LVM ストライプを使う機能を追加します。 ## `vm_boot_priority` -Adds a `boot.priority` property on NIC and disk devices to control the boot order. +ブートの順序を制御するため NIC とディスクデバイスに `boot.priority` プロパティを追加します。 ## `unix_hotplug_devices` -Adds support for Unix char and block device hotplugging. +Unix のキャラクタデバイスとブロックデバイスのホットプラグのサポートを追加します。 ## `api_filtering` -Adds support for filtering the result of a GET request for instances and images. +インスタンスとイメージに対する GET リクエストの結果をフィルタリングする機能を追加します。 ## `instance_nic_network` -Adds support for the `network` property on a NIC device to allow a NIC to be linked to a managed network. -This allows it to inherit some of the network's settings and allows better validation of IP settings. +NIC デバイスの `network` プロパティのサポートを追加し、管理されたネットワークへ NIC をリンクできるようにします。 +これによりネットワーク設定の一部を引き継ぎ、 IP 設定のより良い検証を行うことができます。 ## `clustering_sizing` -Support specifying a custom values for database voters and standbys. -The new `cluster.max_voters` and `cluster.max_standby` configuration keys were introduced -to specify to the ideal number of database voter and standbys. +データベースの投票者とスタンバイに対してカスタムの値を指定するサポートです。 +`cluster.max_voters` と `cluster.max_standby` という新しい設定キーが導入され、データベースの投票者とスタンバイの理想的な数を指定できます。 ## `firewall_driver` -Adds the `Firewall` property to the `ServerEnvironment` struct indicating the firewall driver being used. +`ServerEnvironment` 構造体にファイアーウォールのドライバーが使用されていることを示す `Firewall` プロパティを追加します。 ## `storage_lvm_vg_force_reuse` -Introduces the ability to create a storage pool from an existing non-empty volume group. -This option should be used with care, as Incus can then not guarantee that volume name conflicts won't occur -with non-Incus created volumes in the same volume group. -This could also potentially lead to Incus deleting a non-Incus volume should name conflicts occur. +既存の空でないボリュームグループからストレージボリュームを作成する機能を追加します。 +このオプションの使用には注意が必要です。 +というのは、同じボリュームグループ内に Incus 以外で作成されたボリュームとボリューム名が衝突しないことを Incus が保証できないからです。 +このことはもし名前の衝突が起きたときは Incus 以外で作成されたボリュームを Incus が削除してしまう可能性があることを意味します。 ## `container_syscall_intercept_hugetlbfs` -When mount syscall interception is enabled and `hugetlbfs` is specified as an -allowed file system type Incus will mount a separate `hugetlbfs` instance for the -container with the UID and GID mount options set to the container's root UID -and GID. This ensures that processes in the container can use huge pages. +mount システムコール・インターセプションが有効にされ `hugetlbfs` が許可されたファイルシステムとして指定された場合、 Incus は別の `hugetlbfs` インスタンスを UID と GID をコンテナの root の UID と GID に設定するマウントオプションを指定してコンテナにマウントします。 +これによりコンテナ内のプロセスが huge page を確実に利用できるようにします。 ## `limits_hugepages` -This allows to limit the number of huge pages a container can use through the -`hugetlb` cgroup. This means the `hugetlb` cgroup needs to be available. Note, that -limiting huge pages is recommended when intercepting the mount syscall for the -`hugetlbfs` file system to avoid allowing the container to exhaust the host's -huge pages resources. +コンテナが使用できる huge page の数を `hugetlb` cgroup を使って制限できるようにします。 +この機能を使用するには `hugetlb` cgroup が利用可能になっている必要があります。 +注意: `hugetlbfs` ファイルシステムの mount システムコールをインターセプトするときは、ホストの huge page のリソースをコンテナが使い切ってしまわないように huge page を制限することを推奨します。 ## `container_nic_routed_gateway` -This introduces the `ipv4.gateway` and `ipv6.gateway` NIC configuration keys that can take a value of either `auto` or -`none`. The default value for the key if unspecified is `auto`. This will cause the current behavior of a default -gateway being added inside the container and the same gateway address being added to the host-side interface. -If the value is set to `none` then no default gateway nor will the address be added to the host-side interface. -This allows multiple routed NIC devices to be added to a container. +この拡張は `ipv4.gateway` と `ipv6.gateway` という NIC の設定キーを追加します。 +指定可能な値は `auto` か `none` のいずれかです。 +値を指定しない場合のデフォルト値は `auto` です。 +`auto` に設定した場合は、デフォルトゲートウェイがコンテナ内部に追加され、ホスト側のインターフェースにも同じゲートウェイアドレスが追加されるという現在の挙動と同じになります。 +`none` に設定すると、デフォルトゲートウェイもアドレスもホスト側のインターフェースには追加されません。 +これにより複数のルートを持つ NIC デバイスをコンテナに追加できます。 ## `projects_restrictions` -This introduces support for the `restricted` configuration key on project, which -can prevent the use of security-sensitive features in a project. +この拡張はプロジェクトに `restricted` という設定キーを追加します。 +これによりプロジェクト内でセキュリティーセンシティブな機能を使うのを防ぐことができます。 ## `custom_volume_snapshot_expiry` -This allows custom volume snapshots to expiry. -Expiry dates can be set individually, or by setting the `snapshots.expiry` configuration key on the parent custom volume which then automatically applies to all created snapshots. +この拡張はカスタムボリュームのスナップショットに有効期限を設定できるようにします。 +有効期限は `snapshots.expiry` 設定キーにより個別に設定することも出来ますし、親のカスタムボリュームに設定してそこから作成されたすべてのスナップショットに自動的にその有効期限を適用することも出来ます。 ## `volume_snapshot_scheduling` -This adds support for custom volume snapshot scheduling. It introduces two new -configuration keys: `snapshots.schedule` and -`snapshots.pattern`. Snapshots can be created automatically up to every minute. +この拡張はカスタムボリュームのスナップショットにスケジュール機能を追加します。 +`snapshots.schedule` と `snapshots.pattern` という 2 つの設定キーが新たに追加されます。 +スナップショットは最短で 1 分毎に作成可能です。 ## `trust_ca_certificates` -This allows for checking client certificates trusted by the provided CA (`server.ca`). -It can be enabled by setting `core.trust_ca_certificates` to `true`. -If enabled, it will perform the check, and bypass the trusted password if `true`. -An exception will be made if the connecting client certificate is in the provided CRL (`ca.crl`). -In this case, it will ask for the password. +この拡張により提供された CA（`server.ca`）によって信頼されたクライアント証明書のチェックが可能になります。 +`core.trust_ca_certificates` を `true` に設定すると有効にできます。 +有効な場合、クライアント証明書のチェックを行い、チェックが OK であれば信頼されたパスワードの要求はスキップします。 +ただし、提供された CRL（`ca.crl`）に接続してきたクライアント証明書が含まれる場合は例外です。 +この場合は、パスワードが求められます。 ## `snapshot_disk_usage` -This adds a new `size` field to the output of `/1.0/instances//snapshots/` which represents the disk usage of the snapshot. +この拡張はスナップショットのディスク使用量を示す `/1.0/instances//snapshots/` の出力に `size` フィールドを新たに追加します。 ## `clustering_edit_roles` -This adds a writable endpoint for cluster members, allowing the editing of their roles. +この拡張はクラスタメンバーに書き込み可能なエンドポイントを追加し、ロールの編集を可能にします。 ## `container_nic_routed_host_address` -This introduces the `ipv4.host_address` and `ipv6.host_address` NIC configuration keys that can be used to control the -host-side `veth` interface's IP addresses. This can be useful when using multiple routed NICs at the same time and -needing a predictable next-hop address to use. +この拡張は NIC の設定キーに `ipv4.host_address` と `ipv6.host_address` を追加し、ホスト側の veth インターフェースの IP アドレスを制御できるようにします。 +これは同時に複数の routed NIC を使用し、予測可能な next-hop のアドレスを使用したい場合に有用です。 -This also alters the behavior of `ipv4.gateway` and `ipv6.gateway` NIC configuration keys. When they are set to `auto` -the container will have its default gateway set to the value of `ipv4.host_address` or `ipv6.host_address` respectively. +さらにこの拡張は `ipv4.gateway` と `ipv6.gateway` の NIC 設定キーの振る舞いを変更します。 +auto に設定するとコンテナはデフォルトゲートウェイをそれぞれ `ipv4.host_address` と `ipv6.host_address` で指定した値にします。 -The default values are: +デフォルト値は次の通りです。 `ipv4.host_address`: `169.254.0.1` -`ipv6.host_address`: `fe80::1` +`ipv6.host_address`: `fe80::1` -This is backward compatible with the previous default behavior. +これは以前のデフォルトの挙動と後方互換性があります。 ## `container_nic_ipvlan_gateway` -This introduces the `ipv4.gateway` and `ipv6.gateway` NIC configuration keys that can take a value of either `auto` or -`none`. The default value for the key if unspecified is `auto`. This will cause the current behavior of a default -gateway being added inside the container and the same gateway address being added to the host-side interface. -If the value is set to `none` then no default gateway nor will the address be added to the host-side interface. -This allows multiple IPVLAN NIC devices to be added to a container. +この拡張は `ipv4.gateway` と `ipv6.gateway` の NIC 設定キーを追加し `auto` か `none` の値を指定できます。 +指定しない場合のデフォルト値は `auto` です。 +この場合は従来同様の挙動になりコンテナ内部に追加されるデフォルトゲートウェイと同じアドレスがホスト側のインターフェースにも追加されます。 +`none` に設定された場合、ホスト側のインターフェースにはデフォルトゲートウェイもアドレスも追加されません。 +これによりコンテナに IPVLAN の NIC デバイスを複数追加することができます。 ## `resources_usb_pci` -This adds USB and PCI devices to the output of `/1.0/resources`. +この拡張は `/1.0/resources` の出力に USB と PC デバイスを追加します。 ## `resources_cpu_threads_numa` -This indicates that the `numa_node` field is now recorded per-thread -rather than per core as some hardware apparently puts threads in -different NUMA domains. +この拡張は `numa_node` フィールドをコアごとではなくスレッドごとに記録するように変更します。 +これは一部のハードウェアでスレッドを異なる NUMA ドメインに入れる場合があるようなのでそれに対応するためのものです。 ## `resources_cpu_core_die` -Exposes the `die_id` information on each core. +それぞれのコアごとに `die_id` 情報を公開します。 ## `api_os` -This introduces two new fields in `/1.0`, `os` and `os_version`. +この拡張は `/1.0` 内に `os` と `os_version` の 2 つのフィールドを追加します。 -Those are taken from the OS-release data on the system. +これらの値はシステム上の OS-release のデータから取得されます。 ## `container_nic_routed_host_table` -This introduces the `ipv4.host_table` and `ipv6.host_table` NIC configuration keys that can be used to add static routes -for the instance's IPs to a custom policy routing table by ID. +この拡張は `ipv4.host_table` と `ipv6.host_table` という NIC の設定キーを導入します。 +これで指定した ID のカスタムポリシーのルーティングテーブルにインスタンスの IP のための静的ルートを追加できます。 ## `container_nic_ipvlan_host_table` -This introduces the `ipv4.host_table` and `ipv6.host_table` NIC configuration keys that can be used to add static routes -for the instance's IPs to a custom policy routing table by ID. +この拡張は `ipv4.host_table` と `ipv6.host_table` という NIC の設定キーを導入します。 +これで指定した ID のカスタムポリシーのルーティングテーブルにインスタンスの IP のための静的ルートを追加できます。 ## `container_nic_ipvlan_mode` -This introduces the `mode` NIC configuration key that can be used to switch the `ipvlan` mode into either `l2` or `l3s`. -If not specified, the default value is `l3s` (which is the old behavior). +この拡張は `mode` という NIC の設定キーを導入します。 +これにより `ipvlan` モードを `l2` か `l3s` のいずれかに切り替えられます。 +指定しない場合、デフォルトは `l3s` （従来の挙動）です。 -In `l2` mode the `ipv4.address` and `ipv6.address` keys will accept addresses in either CIDR or singular formats. -If singular format is used, the default subnet size is taken to be /24 and /64 for IPv4 and IPv6 respectively. +`l2` モードでは `ipv4.address` と `ipv6.address` キーは CIDR か単一アドレスの形式を受け付けます。 +単一アドレスの形式を使う場合、デフォルトのサブネットのサイズは IPv4 では /24 、 IPv6 では /64 となります。 -In `l2` mode the `ipv4.gateway` and `ipv6.gateway` keys accept only a singular IP address. +`l2` モードでは `ipv4.gateway` と `ipv6.gateway` キーは単一の IP アドレスのみを受け付けます。 ## `resources_system` -This adds system information to the output of `/1.0/resources`. +この拡張は `/1.0/resources` の出力にシステム情報を追加します。 ## `images_push_relay` -This adds the push and relay modes to image copy. -It also introduces the following new endpoint: +この拡張はイメージのコピーに push と relay モードを追加します。 +また以下の新しいエンドポイントも追加します: * `POST 1.0/images//export` ## `network_dns_search` -This introduces the `dns.search` configuration option on networks. +この拡張はネットワークに `dns.search` という設定オプションを追加します。 ## `container_nic_routed_limits` -This introduces `limits.ingress`, `limits.egress` and `limits.max` for routed NICs. +この拡張は routed NIC に `limits.ingress`, `limits.egress`, `limits.max` を追加します。 ## `instance_nic_bridged_vlan` -This introduces the `vlan` and `vlan.tagged` settings for `bridged` NICs. +この拡張は `bridged` NIC に `vlan` と `vlan.tagged` の設定を追加します。 -`vlan` specifies the non-tagged VLAN to join, and `vlan.tagged` is a comma-delimited list of tagged VLANs to join. +`vlan` には参加するタグなし VLAN を指定し、 `vlan.tagged` は参加するタグ VLAN のカンマ区切りリストを指定します。 ## `network_state_bond_bridge` -This adds a `bridge` and `bond` section to the `/1.0/networks/NAME/state` API. +この拡張は `/1.0/networks/NAME/state` API に bridge と bond のセクションを追加します。 -Those contain additional state information relevant to those particular types. +これらはそれぞれの特定のタイプに関連する追加の状態の情報を含みます。 Bond: @@ -1232,35 +1230,34 @@ Bridge: ## `resources_cpu_isolated` -Add an `Isolated` property on CPU threads to indicate if the thread is -physically `Online` but is configured not to accept tasks. +この拡張は CPU スレッドに `Isolated` プロパティを追加します。 +これはスレッドが物理的には `Online` ですがタスクを受け付けないように設定しているかを示します。 ## `usedby_consistency` -This extension indicates that `UsedBy` should now be consistent with -suitable `?project=` and `?target=` when appropriate. +この拡張により、可能な時は `UsedBy` が適切な `?project=` と `?target=` に対して一貫性があるようになるはずです。 -The 5 entities that have `UsedBy` are: +`UsedBy` を持つ 5 つのエンティティーは以下の通りです: -* Profiles -* Projects -* Networks -* Storage pools -* Storage volumes +* プロファイル +* プロジェクト +* ネットワーク +* ストレージプール +* ストレージボリューム ## `custom_block_volumes` -This adds support for creating and attaching custom block volumes to instances. -It introduces the new `--type` flag when creating custom storage volumes, and accepts the values `fs` and `block`. +この拡張によりカスタムブロックボリュームを作成しインスタンスにアタッチできるようになります。 +カスタムストレージボリュームの作成時に `--type` フラグが新規追加され、 `fs` と `block` の値を受け付けます。 ## `clustering_failure_domains` -This extension adds a new `failure_domain` field to the `PUT /1.0/cluster/` API, -which can be used to set the failure domain of a node. +この拡張は `PUT /1.0/cluster/` API に `failure_domain` フィールドを追加します。 +これはノードの failure domain を設定するのに使えます。 ## `container_syscall_filtering_allow_deny_syntax` -A number of new syscalls related container configuration keys were updated. +いくつかのシステムコールに関連したコンテナの設定キーが更新されました。 * `security.syscalls.deny_default` * `security.syscalls.deny_compat` @@ -1269,69 +1266,64 @@ A number of new syscalls related container configuration keys were updated. ## `resources_gpu_mdev` -Expose available mediated device profiles and devices in `/1.0/resources`. +`/1.0/resources` の利用可能な媒介デバイス (mediated device) のプロファイルとデバイスを公開します。 ## `console_vga_type` -This extends the `/1.0/console` endpoint to take a `?type=` argument, which can -be set to `console` (default) or `vga` (the new type added by this extension). +この拡張は `/1.0/console` エンドポイントが `?type=` 引数を取るように拡張します。 +これは `console`（デフォルト）か `vga`（この拡張で追加される新しいタイプ）を指定可能です。 -When doing a `POST` to `/1.0//console?type=vga` the data WebSocket -returned by the operation in the metadata field will be a bidirectional proxy -attached to a SPICE Unix socket of the target virtual machine. +`/1.0//console?type=vga` に `POST` する際はメタデータフィールド内の操作の結果ウェブソケットにより返されるデータはターゲットの仮想マシンの SPICE Unix ソケットにアタッチされた双方向のプロキシになります。 ## `projects_limits_disk` -Add `limits.disk` to the available project configuration keys. If set, it limits -the total amount of disk space that instances volumes, custom volumes and images -volumes can use in the project. +利用可能なプロジェクトの設定キーに `limits.disk` を追加します。 +これが設定されるとプロジェクト内でインスタンスボリューム、カスタムボリューム、イメージボリュームが使用できるディスクスペースの合計の量を制限できます。 ## `network_type_macvlan` -Adds support for additional network type `macvlan` and adds `parent` configuration key for this network type to -specify which parent interface should be used for creating NIC device interfaces on top of. +ネットワークタイプ `macvlan` のサポートを追加し、このネットワークタイプに `parent` 設定キーを追加します。 +これは NIC デバイスインターフェースを作る際にどの親インターフェースを使用するべきかを指定します。 -Also adds `network` configuration key support for `macvlan` NICs to allow them to specify the associated network of -the same type that they should use as the basis for the NIC device. +さらに `macvlan` の NIC に `network` 設定キーを追加します。 +これは NIC デバイスの設定の基礎として使う network を指定します。 ## `network_type_sriov` -Adds support for additional network type `sriov` and adds `parent` configuration key for this network type to -specify which parent interface should be used for creating NIC device interfaces on top of. +ネットワークタイプ `sriov` のサポートを追加し、このネットワークタイプに `parent` 設定キーを追加します。 +これは NIC デバイスインターフェースを作る際にどの親インターフェースを使用するべきかを指定します。 -Also adds `network` configuration key support for `sriov` NICs to allow them to specify the associated network of -the same type that they should use as the basis for the NIC device. +さらに `sriov` の NIC に `network` 設定キーを追加します。 +これは NIC デバイスの設定の基礎として使う network を指定します。 ## `container_syscall_intercept_bpf_devices` -This adds support to intercept the `bpf` syscall in containers. Specifically, it allows to manage device cgroup `bpf` programs. +この拡張はコンテナ内で `bpf` のシステムコールをインターセプトする機能を提供します。具体的には device cgroup の `bpf` のプログラムを管理できるようにします。 ## `network_type_ovn` -Adds support for additional network type `ovn` with the ability to specify a `bridge` type network as the `parent`. +ネットワークタイプ `ovn` のサポートを追加し、 `bridge` タイプのネットワークを `parent` として設定できるようにします。 -Introduces a new NIC device type of `ovn` which allows the `network` configuration key to specify which `ovn` -type network they should connect to. +`ovn` という新しい NIC のデバイスタイプを追加します。これにより `network` 設定キーにどの `ovn` のタイプのネットワークに接続すべきかを指定できます。 -Also introduces two new global configuration keys that apply to all `ovn` networks and NIC devices: +さらにすべての `ovn` ネットワークと NIC デバイスに適用される 2 つのグローバルの設定キーを追加します: -* `network.ovn.integration_bridge` - the OVS integration bridge to use. -* `network.ovn.northbound_connection` - the OVN northbound database connection string. +* `network.ovn.integration_bridge` - 使用する OVS 統合ブリッジ +* `network.ovn.northbound_connection` - OVN northbound データベース接続文字列 ## `projects_networks` -Adds the `features.networks` configuration key to projects and the ability for a project to hold networks. +プロジェクトに `features.networks` 設定キーを追加し、プロジェクトがネットワークを保持できるようにします。 ## `projects_networks_restricted_uplinks` -Adds the `restricted.networks.uplinks` project configuration key to indicate (as a comma-delimited list) which networks -the networks created inside the project can use as their uplink network. +プロジェクトに `restricted.networks.uplinks` 設定キーを追加し、プロジェクト内で作られたネットワークがそのアップリンクのネットワークとしてどのネットワークが使えるかを（カンマ区切りリストで）指定します。 ## `custom_volume_backup` -Add custom volume backup support. +カスタムボリュームのバックアップサポートを追加します。 -This includes the following new endpoints (see [RESTful API](rest-api.md) for details): +この拡張は以下の新しい API エンドポイント （詳細は [RESTful API](rest-api.md) を参照）を含みます: * `GET /1.0/storage-pools////backups` * `POST /1.0/storage-pools////backups` @@ -1342,229 +1334,223 @@ This includes the following new endpoints (see [RESTful API](rest-api.md) for de * `GET /1.0/storage-pools////backups//export` -The following existing endpoint has been modified: +以下の既存のエンドポイントが変更されます: -* `POST /1.0/storage-pools///` accepts the new source type `backup` +* `POST /1.0/storage-pools///` が新しいソースタイプとして `backup` を受け付けます ## `backup_override_name` -Adds `Name` field to `InstanceBackupArgs` to allow specifying a different instance name when restoring a backup. +`InstanceBackupArgs` に `Name` フィールドを追加し、バックアップをリストアする際に別のインスタンス名を指定できるようにします。 -Adds `Name` and `PoolName` fields to `StoragePoolVolumeBackupArgs` to allow specifying a different volume name -when restoring a custom volume backup. +`StoragePoolVolumeBackupArgs` に `Name` と `PoolName` フィールドを追加し、カスタムボリュームのバックアップをリストアする際に別のボリューム名を指定できるようにします。 ## `storage_rsync_compression` -Adds `rsync.compression` configuration key to storage pools. This key can be used -to disable compression in `rsync` while migrating storage pools. +ストレージプールに `rsync.compression` 設定キーを追加します。 +このキーはストレージプールをマイグレートする際に `rsync` での圧縮を無効にするために使うことができます。 ## `network_type_physical` -Adds support for additional network type `physical` that can be used as an uplink for `ovn` networks. +新たに `physical` というネットワークタイプのサポートを追加し、 `ovn` ネットワークのアップリンクとして使用できるようにします。 -The interface specified by `parent` on the `physical` network will be connected to the `ovn` network's gateway. +`physical` ネットワークの `parent` で指定するインターフェースは `ovn` ネットワークのゲートウェイに接続されます。 ## `network_ovn_external_subnets` -Adds support for `ovn` networks to use external subnets from uplink networks. +`ovn` ネットワークがアップリンクネットワークの外部のサブネットを使用できるようにします。 -Introduces the `ipv4.routes` and `ipv6.routes` setting on `physical` networks that defines the external routes -allowed to be used in child OVN networks in their `ipv4.routes.external` and `ipv6.routes.external` settings. +`physical` ネットワークに `ipv4.routes` と `ipv6.routes` の設定を追加します。 +これは子供の OVN ネットワークで `ipv4.routes.external` と `ipv6.routes.external` の設定で使用可能な外部のルートを指定します。 -Introduces the `restricted.networks.subnets` project setting that specifies which external subnets are allowed to -be used by OVN networks inside the project (if not set then all routes defined on the uplink network are allowed). +プロジェクトに `restricted.networks.subnets` 設定を追加します。 +これはプロジェクト内の OVN ネットワークで使用可能な外部のサブネットを指定します（未設定の場合はアップリンクネットワークで定義されるすべてのルートが使用可能です）。 ## `network_ovn_nat` -Adds support for `ipv4.nat` and `ipv6.nat` settings on `ovn` networks. +`ovn` ネットワークに `ipv4.nat` と `ipv6.nat` の設定を追加します。 -When creating the network if these settings are unspecified, and an equivalent IP address is being generated for -the subnet, then the appropriate NAT setting will added set to `true`. +これらの設定（訳注: `ipv4.nat` や `ipv6.nat`）を未設定でネットワークを作成する際、（訳注: `ipv4.address` や `ipv6.address` が未設定あるいは `auto` の場合に）対応するアドレス （訳注: `ipv4.nat` であれば `ipv4.address`、`ipv6.nat` であれば `ipv6.address`）がサブネット用に生成される場合は適切な NAT が生成され、`ipv4.nat` や `ipv6.nat` は `true` に設定されます。 -If the setting is missing then the value is taken as `false`. +この設定がない場合は値は `false` として扱われます。 ## `network_ovn_external_routes_remove` -Removes the settings `ipv4.routes.external` and `ipv6.routes.external` from `ovn` networks. +`ovn` ネットワークから `ipv4.routes.external` と `ipv6.routes.external` の設定を削除します。 -The equivalent settings on the `ovn` NIC type can be used instead for this, rather than having to specify them -both at the network and NIC level. +ネットワークと NIC レベルの両方で指定するのではなく、 `ovn` NIC タイプ上で等価な設定を使えます。 ## `tpm_device_type` -This introduces the `tpm` device type. +`tpm` デバイスタイプを導入します。 ## `storage_zfs_clone_copy_rebase` -This introduces `rebase` as a value for `zfs.clone_copy` causing Incus to -track down any `image` dataset in the ancestry line and then perform -send/receive on top of that. +`zfs.clone_copy` に `rebase` という値を導入します。 +この設定で Incus は先祖の系列上の `image` データセットを追跡し、その最上位に対して send/receive を実行します。 ## `gpu_mdev` -This adds support for virtual GPUs. It introduces the `mdev` configuration key for GPU devices which takes -a supported `mdev` type, e.g. `i915-GVTg_V5_4`. +これは仮想 CPU のサポートを追加します。 +GPU デバイスに `mdev` 設定キーを追加し、`i915-GVTg_V5_4` のようなサポートされる `mdev` のタイプを指定します。 ## `resources_pci_iommu` -This adds the `IOMMUGroup` field for PCI entries in the resources API. +これはリソース API の PCI エントリーに `IOMMUGroup` フィールドを追加します。 ## `resources_network_usb` -Adds the `usb_address` field to the network card entries in the resources API. +リソース API のネットワークカードエントリーに `usb_address` フィールドを追加します。 ## `resources_disk_address` -Adds the `usb_address` and `pci_address` fields to the disk entries in the resources API. +リソース API のディスクエントリーに `usb_address` と `pci_address` フィールドを追加します。 ## `network_physical_ovn_ingress_mode` -Adds `ovn.ingress_mode` setting for `physical` networks. +`physical` ネットワークに `ovn.ingress_mode` 設定を追加します。 -Sets the method that OVN NIC external IPs will be advertised on uplink network. +OVN NIC ネットワークの外部 IP アドレスがアップリンクネットワークにどのように広告されるかの方法を設定します。 -Either `l2proxy` (proxy ARP/NDP) or `routed`. +`l2proxy`（proxy ARP/NDP）か `routed` のいずれかを指定します。 ## `network_ovn_dhcp` -Adds `ipv4.dhcp` and `ipv6.dhcp` settings for `ovn` networks. +`ovn` ネットワークに `ipv4.dhcp` と `ipv6.dhcp` の設定を追加します。 -Allows DHCP (and RA for IPv6) to be disabled. Defaults to on. +DHCP（と IPv6 の RA）を無効にできます。デフォルトはオンです。 ## `network_physical_routes_anycast` -Adds `ipv4.routes.anycast` and `ipv6.routes.anycast` Boolean settings for `physical` networks. Defaults to `false`. +`physical` ネットワークに `ipv4.routes.anycast` と `ipv6.routes.anycast` の Boolean の設定を追加します。デフォルトは `false` です。 -Allows OVN networks using physical network as uplink to relax external subnet/route overlap detection when used -with `ovn.ingress_mode=routed`. +`ovn.ingress_mode=routed` と共に使うと physical ネットワークをアップリンクとして使う OVN ネットワークでサブネット／ルートのオーバーラップ検出を緩和できます。 ## `projects_limits_instances` -Adds `limits.instances` to the available project configuration keys. If set, it -limits the total number of instances (VMs and containers) that can be used in the project. +`limits.instances` を利用可能なプロジェクトの設定キーに追加します。 +設定するとプロジェクト内で使われるインスタンス（VM とコンテナ）の合計数を制限します。 ## `network_state_vlan` -This adds a `vlan` section to the `/1.0/networks/NAME/state` API. +これは `/1.0/networks/NAME/state` API に `vlan` セクションを追加します。 -Those contain additional state information relevant to VLAN interfaces: +これらは VLAN インターフェースに関連する追加の状態の情報を含みます。 * `lower_device` * `vid` ## `instance_nic_bridged_port_isolation` -This adds the `security.port_isolation` field for bridged NIC instances. +これは `bridged` NIC に `security.port_isolation` のフィールドを追加します。 ## `instance_bulk_state_change` -Adds the following endpoint for bulk state change (see [RESTful API](rest-api.md) for details): +一括状態変更（詳細は [REST API](rest-api.md) を参照）のために次のエンドポイントを追加します: * `PUT /1.0/instances` ## `network_gvrp` -This adds an optional `gvrp` property to `macvlan` and `physical` networks, -and to `ipvlan`, `macvlan`, `routed` and `physical` NIC devices. +これはオプショナルな `gvrp` プロパティを `macvlan` と `physical` ネットワークに追加し、 +さらに `ipvlan`、`macvlan`、`routed`、`physical` NIC デバイスにも追加します。 -When set, this specifies whether the VLAN should be registered using GARP VLAN -Registration Protocol. Defaults to `false`. +設定された場合は、これは VLAN が GARP VLAN Registration Protocol を使って登録すべきかどうかを指定します。 +デフォルトは `false` です。 ## `instance_pool_move` -This adds a `pool` field to the `POST /1.0/instances/NAME` API, -allowing for easy move of an instance root disk between pools. +これは `POST /1.0/instances/NAME` API に `pool` フィールドを追加し、プール間でインスタンスのルートディスクを簡単に移動できるようにします。 ## `gpu_sriov` -This adds support for SR-IOV enabled GPUs. -It introduces the `sriov` GPU type property. +これは SR-IOV を有効にした GPU のサポートを追加します。 +これにより `sriov` という GPU タイプのプロパティが追加されます。 ## `pci_device_type` -This introduces the `pci` device type. +これは `pci` デバイスタイプを追加します。 ## `storage_volume_state` -Add new `/1.0/storage-pools/POOL/volumes/VOLUME/state` API endpoint to get usage data on a volume. +`/1.0/storage-pools/POOL/volumes/VOLUME/state` API エンドポイントを新規追加しボリュームの使用量を取得できるようにします。 ## `network_acl` -This adds the concept of network ACLs to API under the API endpoint prefix `/1.0/network-acls`. +これは `/1.0/network-acls` の API エンドポイントプリフィクス以下の API にネットワークの ACL のコンセプトを追加します。 ## `migration_stateful` -Add a new `migration.stateful` configuration key. +`migration.stateful` という設定キーを追加します。 ## `disk_state_quota` -This introduces the `size.state` device configuration key on `disk` devices. +これは `disk` デバイスに `size.state` というデバイス設定キーを追加します。 ## `storage_ceph_features` -Adds a new `ceph.rbd.features` configuration key on storage pools to control the RBD features used for new volumes. +ストレージプールに `ceph.rbd.features` 設定キーを追加し、新規ボリュームに使用する RBD の機能を制御します。 ## `projects_compression` -Adds new `backups.compression_algorithm` and `images.compression_algorithm` configuration keys which -allows configuration of backup and image compression per-project. +`backups.compression_algorithm` と `images.compression_algorithm` 設定キーを追加します。 +これらによりプロジェクトごとのバックアップとイメージの圧縮の設定が出来るようになります。 ## `projects_images_remote_cache_expiry` -Add new `images.remote_cache_expiry` configuration key to projects, -allowing for set number of days after which an unused cached remote image will be flushed. +プロジェクトに `images.remote_cache_expiry` 設定キーを追加します。 +これを設定するとキャッシュされたリモートのイメージが指定の日数使われない場合は削除されるようになります。 ## `certificate_project` -Adds a new `restricted` property to certificates in the API as well as -`projects` holding a list of project names that the certificate has -access to. +API 内の証明書に `restricted` と `projects` プロパティを追加します。 +`projects` は証明書がアクセスしたプロジェクト名の一覧を保持します。 ## `network_ovn_acl` -Adds a new `security.acls` property to OVN networks and OVN NICs, allowing Network ACLs to be applied. +OVN ネットワークと OVN NIC に `security.acls` プロパティを追加します。 +これにより ネットワークに ACL をかけられるようになります。 ## `projects_images_auto_update` -Adds new `images.auto_update_cached` and `images.auto_update_interval` configuration keys which -allows configuration of images auto update in projects +`images.auto_update_cached` と `images.auto_update_interval` 設定キーを追加します。 +これらによりプロジェクト内のイメージの自動更新を設定できるようになります。 ## `projects_restricted_cluster_target` -Adds new `restricted.cluster.target` configuration key to project which prevent the user from using --target -to specify what cluster member to place a workload on or the ability to move a workload between members. +プロジェクトに `restricted.cluster.target` 設定キーを追加します。 +これによりどのクラスタメンバーにワークロードを配置するかやメンバー間のワークロードを移動する能力を指定する --target オプションをユーザーに使わせないように出来ます。 ## `images_default_architecture` -Adds new `images.default_architecture` global configuration key and matching per-project key which lets user tell Incus -what architecture to go with when no specific one is specified as part of the image request. +`images.default_architecture` をグローバルの設定キーとプロジェクトごとの設定キーとして追加します。 +これはイメージリクエストの一部として明示的に指定しなかった場合にどのアーキテクチャを使用するかを Incus に指定します。 ## `network_ovn_acl_defaults` -Adds new `security.acls.default.{in,e}gress.action` and `security.acls.default.{in,e}gress.logged` configuration keys for -OVN networks and NICs. This replaces the removed ACL `default.action` and `default.logged` keys. +OVN ネットワークと NIC に `security.acls.default.{in,e}gress.action` と `security.acls.default.{in,e}gress.logged` 設定キーを追加します。 +これは削除された ACL の `default.action` と `default.logged` キーの代わりになるものです。 ## `gpu_mig` -This adds support for NVIDIA MIG. It introduces the `mig` GPU type and associated configuration keys. +これは NVIDIA MIG のサポートを追加します。 +`mig` GPU type と関連する設定キーを追加します。 ## `project_usage` -Adds an API endpoint to get current resource allocations in a project. -Accessible at API `GET /1.0/projects//state`. +プロジェクトに現在のリソース割り当ての情報を取得する API エンドポイントを追加します。 +API の `GET /1.0/projects//state` で利用できます。 ## `network_bridge_acl` -Adds a new `security.acls` configuration key to `bridge` networks, allowing Network ACLs to be applied. +`bridge` ネットワークに `security.acls` 設定キーを追加し、ネットワーク ACL を適用できるようにします。 -Also adds `security.acls.default.{in,e}gress.action` and `security.acls.default.{in,e}gress.logged` configuration keys for -specifying the default behavior for unmatched traffic. +さらにマッチしなかったトラフィックに対するデフォルトの振る舞いを指定する `security.acls.default.{in,e}gress.action` と `security.acls.default.{in,e}gress.logged` 設定キーを追加します。 ## `warnings` -Warning API for Incus. +Incus の警告 API です。 -This includes the following endpoints (see [Restful API](rest-api.md) for details): +この拡張は次のエンドポイントを含みます（詳細は [Restful API](rest-api.md) 参照）: * `GET /1.0/warnings` @@ -1574,270 +1560,258 @@ This includes the following endpoints (see [Restful API](rest-api.md) for detai ## `projects_restricted_backups_and_snapshots` -Adds new `restricted.backups` and `restricted.snapshots` configuration keys to project which -prevents the user from creation of backups and snapshots. +プロジェクトに `restricted.backups` と `restricted.snapshots` 設定キーを追加し、ユーザーがバックアップやスナップショットを作成できないようにします。 ## `clustering_join_token` -Adds `POST /1.0/cluster/members` API endpoint for requesting a join token used when adding new cluster members -without using the trust password. +トラスト・パスワードを使わずに新しいクラスタメンバーを追加する際に使用する参加トークンをリクエストするための `POST /1.0/cluster/members` API エンドポイントを追加します。 ## `clustering_description` -Adds an editable description to the cluster members. +クラスタメンバーに編集可能な説明を追加します。 ## `server_trusted_proxy` -This introduces support for `core.https_trusted_proxy` which has Incus -parse a HAProxy style connection header on such connections and if -present, will rewrite the request's source address to that provided by -the proxy server. +`core.https_trusted_proxy` のサポートを追加します。 この設定は、Incus が HAProxy スタイルの connection ヘッダーをパースし、そのような（HAProxy などのリバースプロキシサーバーが Incus の前面に存在するような）接続の場合でヘッダーが存在する場合は、プロキシサーバーが（ヘッダーで）提供するリクエストの（実際のクライアントの）ソースアドレスへ（Incus が）ソースアドレスを書き換え（て、Incus の管理するクラスタにリクエストを送出し）ます。（Incus のログにもオリジナルのアドレスを記録します） ## `clustering_update_cert` -Adds `PUT /1.0/cluster/certificate` endpoint for updating the cluster -certificate across the whole cluster +クラスタ全体に適用されるクラスタ証明書を更新するための `PUT /1.0/cluster/certificate` エンドポイントを追加します。 ## `storage_api_project` -This adds support for copy/move custom storage volumes between projects. +これはプロジェクト間でカスタムストレージボリュームをコピー／移動できるようにします。 ## `server_instance_driver_operational` -This modifies the `driver` output for the `/1.0` endpoint to only include drivers which are actually supported and -operational on the server (as opposed to being included in Incus but not operational on the server). +これは `/1.0` エンドポイントの `driver` の出力をサーバー上で実際にサポートされ利用可能であるドライバーのみを含めるように修正します（Incus に含まれるがサーバー上では利用不可なドライバーも含めるのとは違って）。 ## `server_supported_storage_drivers` -This adds supported storage driver info to server environment info. +これはサーバーの環境情報にサポートされているストレージドライバーの情報を追加します。 ## `event_lifecycle_requestor_address` -Adds a new address field to `lifecycle` requestor. +lifecycle requestor に address のフィールドを追加します。 ## `resources_gpu_usb` -Add a new `USBAddress` (`usb_address`) field to `ResourcesGPUCard` (GPU entries) in the resources API. +リソース API 内の `ResourcesGPUCard`（GPU エントリ）に `USBAddress`（`usb_address`）を追加します。 ## `clustering_evacuation` -Adds `POST /1.0/cluster/members//state` endpoint for evacuating and restoring cluster members. -It also adds the configuration keys `cluster.evacuate` and `volatile.evacuate.origin` for setting the evacuation method (`auto`, `stop` or `migrate`) and the origin of any migrated instance respectively. +クラスタメンバーを退避と復元するための `POST /1.0/cluster/members//state` エンドポイントを追加します。 +また設定キー `cluster.evacuate` と `volatile.evacuate.origin` も追加します。 +これらはそれぞれ退避の方法（`auto`、`stop`または`migrate`）と移動したインスタンスのオリジンを設定します。 ## `network_ovn_nat_address` -This introduces the `ipv4.nat.address` and `ipv6.nat.address` configuration keys for Incus `ovn` networks. -Those keys control the source address used for outbound traffic from the OVN virtual network. -These keys can only be specified when the OVN network's uplink network has `ovn.ingress_mode=routed`. +これは Incus の `ovn` ネットワークに `ipv4.nat.address` と `ipv6.nat.address` 設定キーを追加します。 +これらのキーで OVN 仮想ネットワークからの外向きトラフィックのソースアドレスを制御します。 +これらのキーは OVN ネットワークのアップリンクネットワークが `ovn.ingress_mode=routed` という設定を持つ場合にのみ指定可能です。 ## `network_bgp` -This introduces support for Incus acting as a BGP router to advertise -routes to `bridge` and `ovn` networks. +これは Incus を BGP ルーターとして振る舞わせルートを `bridge` と `ovn` ネットワークに広告するようにします。 -This comes with the addition to global configuration of: +以下のグローバル設定が追加されます: * `core.bgp_address` * `core.bgp_asn` * `core.bgp_routerid` -The following network configurations keys (`bridge` and `physical`): +以下のネットワーク設定キーが追加されます（`bridge` と `physical`）: * `bgp.peers..address` * `bgp.peers..asn` * `bgp.peers..password` -The `nexthop` configuration keys (`bridge`): +`nexthop` 設定キー（NIC type が `bridged` の場合）: * `bgp.ipv4.nexthop` * `bgp.ipv6.nexthop` -And the following NIC-specific configuration keys (`bridged` NIC type): +そして下記の NIC 特有な設定が追加されます（NIC type が `bridged` の場合）: * `ipv4.routes.external` * `ipv6.routes.external` ## `network_forward` -This introduces the networking address forward functionality. Allowing for `bridge` and `ovn` networks to define -external IP addresses that can be forwarded to internal IP(s) inside their respective networks. +これはネットワークアドレスのフォワード機能を追加します。 +`bridge` と `ovn` ネットワークで外部 IP アドレスを定義して対応するネットワーク内の内部 IP アドレス（複数指定可能）にフォワード出来ます。 ## `custom_volume_refresh` -Adds support for refresh during volume migration. +ボリュームマイグレーションに refresh オプションのサポートを追加します。 ## `network_counters_errors_dropped` -This adds the received and sent errors as well as inbound and outbound dropped packets to the network counters. +これはネットワークカウンターに受信エラー数、送信エラー数とインバウンドとアウトバウンドのドロップしたパケット数を追加します。 ## `metrics` -This adds metrics to Incus. It returns metrics of running instances using the OpenMetrics format. +これは Incus にメトリクスを追加します。実行中のインスタンスのメトリクスを OpenMetrics 形式で返します。 -This includes the following endpoints: +この拡張は次のエンドポイントを含みます: * `GET /1.0/metrics` ## `image_source_project` -Adds a new `project` field to `POST /1.0/images` allowing for the source project -to be set at image copy time. +`POST /1.0/images` に `project` フィールドを追加し、イメージコピー時にコピー元プロジェクトを設定できるようにします。 ## `clustering_config` -Adds new `config` property to cluster members with configurable key/value pairs. +クラスタメンバーに `config` プロパティを追加し、キー・バリュー・ペアを設定可能にします。 ## `network_peer` -This adds network peering to allow traffic to flow between OVN networks without leaving the OVN subsystem. +ネットワークピアリングを追加し、 OVN ネットワーク間のトラフィックが OVN サブシステムの外に出ずに通信できるようにします。 ## `linux_sysctl` -Adds new `linux.sysctl.*` configuration keys allowing users to modify certain kernel parameters -within containers. +`linux.sysctl.*` 設定キーを追加し、ユーザーが一コンテナ内の一部のカーネルパラメーターを変更できるようにします。 ## `network_dns` -Introduces a built-in DNS server and zones API to provide DNS records for Incus instances. +組み込みの DNS サーバーとゾーン API を追加し、 Incus インスタンスに DNS レコードを提供します。 -This introduces the following server configuration key: +以下のサーバー設定キーが追加されます: * `core.dns_address` -The following network configuration key: +以下のネットワーク設定キーが追加されます: * `dns.zone.forward` * `dns.zone.reverse.ipv4` * `dns.zone.reverse.ipv6` -And the following project configuration key: +以下のプロジェクト設定キーが追加されます: * `restricted.networks.zones` -A new REST API is also introduced to manage DNS 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` -Adds new `acceleration` configuration key to OVN NICs which can be used for enabling hardware offloading. -It takes the values `none` or `sriov`. +OVN NIC に `acceleration` 設定キーを追加し、ハードウェアオフロードを有効にするのに使用できます。 +設定値は `none` または `sriov` です。 ## `certificate_self_renewal` -This adds support for renewing a client's own trust certificate. +これはクライアント自身の信頼証明書の更新のサポートを追加します。 ## `instance_project_move` -This adds a `project` field to the `POST /1.0/instances/NAME` API, -allowing for easy move of an instance between projects. +これは `POST /1.0/instances/NAME` API に `project` フィールドを追加し、インスタンスをプロジェクト間で簡単に移動できるようにします。 ## `storage_volume_project_move` -This adds support for moving storage volume between projects. +これはストレージボリュームのプロジェクト間での移動のサポートを追加します。 ## `cloud_init` -This adds a new `cloud-init` configuration key namespace which contains the following keys: +これは以下のキーを含む `project` 設定キー名前空間を追加します: * `cloud-init.vendor-data` * `cloud-init.user-data` * `cloud-init.network-config` - It also adds a new endpoint `/1.0/devices` to `/dev/incus` which shows an instance's devices. +これはまた `devlxd` にインスタンスのデバイスを表示する `/1.0/devices` エンドポイントを追加します。 ## `network_dns_nat` -This introduces `network.nat` as a configuration option on network zones (DNS). +これはネットワークゾーン（DNS）に `network.nat` を設定オプションとして追加します。 -It defaults to the current behavior of generating records for all -instances NICs but if set to `false`, it will instruct Incus to only -generate records for externally reachable addresses. +デフォルトではすべてのインスタンスの NIC のレコードを生成するという現状の挙動になりますが、 +`false` に設定すると外部から到達可能なアドレスのレコードのみを生成するよう Incus に指示します。 ## `database_leader` -Adds new `database-leader` role which is assigned to cluster leader. +クラスタリーダーに設定される `database-leader` ロールを追加します。 ## `instance_all_projects` -This adds support for displaying instances from all projects. +すべてのプロジェクトのインスタンス表示のサポートを追加します。 ## `clustering_groups` -Add support for grouping cluster members. +クラスタメンバーのグループ化のサポートを追加します。 -This introduces the following new endpoints: +これは以下の新しいエンドポイントを追加します: -* `/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） - The following project restriction is added: + 以下のプロジェクトの制限が追加されます: * `restricted.cluster.groups` ## `ceph_rbd_du` -Adds a new `ceph.rbd.du` Boolean on Ceph storage pools which allows -disabling the use of the potentially slow `rbd du` calls. +Ceph ストレージブールに `ceph.rbd.du` という Boolean の設定を追加します。 +実行に時間がかかるかもしれない `rbd du` の呼び出しの使用を無効化できます。 ## `instance_get_full` -This introduces a new `recursion=1` mode for `GET /1.0/instances/{name}` which allows for the retrieval of -all instance structs, including the state, snapshots and backup structs. +これは `GET /1.0/instances/{name}` に `recursion=1` のモードを追加します。 +これは状態、スナップショット、バックアップの構造体を含むすべてのインスタンスの構造体が取得できます。 ## `qemu_metrics` -This adds a new `security.agent.metrics` Boolean which defaults to `true`. -When set to `false`, it doesn't connect to the `incus-agent` for metrics and other state information, but relies on stats from QEMU. +これは `security.agent.metrics` という Boolean 値を追加します。デフォルト値は `true` です。 +`false` に設定するとメトリクスや他の状態の取得のために `incus-agent` に接続することはせず、 QEMU からの統計情報に頼ります。 ## `gpu_mig_uuid` -Adds support for the new MIG UUID format used by NVIDIA `470+` drivers (for example, `MIG-74c6a31a-fde5-5c61-973b-70e12346c202`), -the `MIG-` prefix can be omitted +NVIDIA `470+` ドライバー (例. `MIG-74c6a31a-fde5-5c61-973b-70e12346c202`) で使用される MIG UUID 形式のサポートを追加します。 +`MIG-` の接頭辞は省略できます。 -This extension supersedes old `mig.gi` and `mig.ci` parameters which are kept for compatibility with old drivers and -cannot be set together. +この拡張が古い `mig.gi` と `mig.ci` パラメーターに取って代わります。これらは古いドライバーとの互換性のため残されますが、 +同時には設定できません。 ## `event_project` -Expose the project an API event belongs to. +イベントの API にイベントが属するプロジェクトを公開します。 ## `clustering_evacuation_live` -This adds `live-migrate` as a configuration option to `cluster.evacuate`, which forces live-migration -of instances during cluster evacuation. +`cluster.evacuate` への設定値 `live-migrate` を追加します。 +これはクラスタ退避の際にインスタンスのライブマイグレーションを強制します。 ## `instance_allow_inconsistent_copy` -Adds `allow_inconsistent` field to instance source on `POST /1.0/instances`. If `true`, `rsync` will ignore the -`Partial transfer due to vanished source files` (code 24) error when creating an instance from a copy. +`POST /1.0/instances` のインスタンスソースに `allow_inconsistent` フィールドを追加します。 +`true` の場合、 `rsync` はコピーからインスタンスを生成するときに `Partial transfer due to vanished source files`（code 24）エラーを無視します。 ## `network_state_ovn` -This adds an `ovn` section to the `/1.0/networks/NAME/state` API which contains additional state information relevant to -OVN networks: +これにより、`/1.0/networks/NAME/state` API に `ovn` セクションが追加されます。これには OVN ネットワークに関連する追加の状態情報が含まれます: -* chassis +* chassis（シャーシ） ## `storage_volume_api_filtering` -Adds support for filtering the result of a GET request for storage volumes. +ストレージボリュームの GET リクエストの結果をフィルタリングする機能を追加します。 ## `image_restrictions` -This extension adds on to the image properties to include image restrictions/host requirements. These requirements -help determine the compatibility between an instance and the host system. +この拡張機能は、イメージのプロパティに、イメージの制限やホストの要件を追加します。これらの要件は +インスタンスとホストシステムとの互換性を決定するのに役立ちます。 ## `storage_zfs_export` -Introduces the ability to disable zpool export when unmounting pool by setting `zfs.export`. +`zfs.export` を設定することで、プールのアンマウント時に zpool のエクスポートを無効にする機能を導入しました。 ## `network_dns_records` -This extends the network zones (DNS) API to add the ability to create and manage custom records. +network zones (DNS) API を拡張し、カスタムレコードの作成と管理機能を追加します。 -This adds: +これにより、以下が追加されます: * `GET /1.0/network-zones/ZONE/records` * `POST /1.0/network-zones/ZONE/records` @@ -1848,273 +1822,265 @@ This adds: ## `storage_zfs_reserve_space` -Adds ability to set the `reservation`/`refreservation` ZFS property along with `quota`/`refquota`. +`quota`/`refquota` に加えて、ZFS プロパティの `reservation`/`refreservation` を設定する機能を追加します。 ## `network_acl_log` -Adds a new `GET /1.0/networks-acls/NAME/log` API to retrieve ACL firewall logs. +ACL ファイアウォールのログを取得するための API `GET /1.0/networks-acls/NAME/log` を追加します。 ## `storage_zfs_blocksize` -Introduces a new `zfs.blocksize` property for ZFS storage volumes which allows to set volume block size. +ZFS ストレージボリュームに新しい `zfs.blocksize` プロパティを導入し、ボリュームのブロックサイズを設定できるようになります。 ## `metrics_cpu_seconds` -This is used to detect whether Incus was fixed to output used CPU time in seconds rather than as milliseconds. +Incus が使用する CPU 時間をミリ秒ではなく秒単位で出力するように修正されたかどうかを検出するために使用されます。 ## `instance_snapshot_never` -Adds a `@never` option to `snapshots.schedule` which allows disabling inheritance. +`snapshots.schedule`に`@never`オプションを追加し、継承を無効にすることができます。 ## `certificate_token` -This adds token-based certificate addition to the trust store as a safer alternative to a trust password. +トラストストアに、トラストパスワードに代わる安全な手段として、トークンベースの証明書を追加します。 -It adds the `token` field to `POST /1.0/certificates`. +これは `POST /1.0/certificates` に `token` フィールドを追加します。 ## `instance_nic_routed_neighbor_probe` -This adds the ability to disable the `routed` NIC IP neighbor probing for availability on the parent network. +これは `routed` NIC が親のネットワークが利用可能かを調べるために IP 近傍探索するのを無効化できるようにします。 -Adds the `ipv4.neighbor_probe` and `ipv6.neighbor_probe` NIC settings. Defaulting to `true` if not specified. +`ipv4.neighbor_probe` と `ipv6.neighbor_probe` の NIC 設定を追加します。未指定の場合のデフォルト値は `true` です。 ## `event_hub` -This adds support for `event-hub` cluster member role and the `ServerEventMode` environment field. +これは `event-hub` というクラスタメンバーの役割と `ServerEventMode` 環境フィールドを追加します。 ## `agent_nic_config` -If set to `true`, on VM start-up the `incus-agent` will apply NIC configuration to change the names and MTU of the instance NIC -devices. +これを `true` に設定すると、仮想マシンの起動時に `incus-agent` がインスタンスの NIC デバイスの名前と MTU を変更するための NIC 設定を適用します。 ## `projects_restricted_intercept` -Adds new `restricted.container.intercept` configuration key to allow usually safe system call interception options. +`restricted.container.intercept` という設定キーを追加し通常は安全なシステムコールのインターセプションオプションを可能にします。 ## `metrics_authentication` -Introduces a new `core.metrics_authentication` server configuration option to -allow for the `/1.0/metrics` endpoint to be generally available without -client authentication. +`core.metrics_authentication` というサーバー設定オプションを追加し `/1.0/metrics` のエンドポイントをクライアント認証無しでアクセスすることを可能にします。 ## `images_target_project` -Adds ability to copy image to a project different from the source. +コピー元とは異なるプロジェクトにイメージをコピーできるようにします。 ## `cluster_migration_inconsistent_copy` -Adds `allow_inconsistent` field to `POST /1.0/instances/`. Set to `true` to allow inconsistent copying between cluster -members. +`POST /1.0/instances/` に `allow_inconsistent` フィールドを追加します。 `true` に設定するとクラスタメンバー間で不整合なコピーを許します。 ## `cluster_ovn_chassis` -Introduces a new `ovn-chassis` cluster role which allows for specifying what cluster member should act as an OVN chassis. +`ovn-chassis` というクラスタロールを追加します。これはクラスタメンバーが OVN シャーシとしてどう振る舞うかを指定できるようにします。 ## `container_syscall_intercept_sched_setscheduler` -Adds the `security.syscalls.intercept.sched_setscheduler` to allow advanced process priority management in containers. +`security.syscalls.intercept.sched_setscheduler` を追加し、コンテナ内の高度なプロセス優先度管理を可能にします。 ## `storage_lvm_thinpool_metadata_size` -Introduces the ability to specify the thin pool metadata volume size via `storage.thinpool_metadata_size`. +`storage.thinpool_metadata_size` により thin pool のメタデータボリュームサイズを指定できるようにします。 -If this is not specified then the default is to let LVM pick an appropriate thin pool metadata volume size. +指定しない場合のデフォルトは LVM が適切な thin pool のメタデータボリュームサイズを選択します。 ## `storage_volume_state_total` -This adds `total` field to the `GET /1.0/storage-pools/{name}/volumes/{type}/{volume}/state` API. +これは `GET /1.0/storage-pools/{name}/volumes/{type}/{volume}/state` API に `total` フィールドを追加します。 ## `instance_file_head` -Implements HEAD on `/1.0/instances/NAME/file`. +`/1.0/instances/NAME/file` に HEAD を実装します。 ## `instances_nic_host_name` -This introduces the `instances.nic.host_name` server configuration key that can take a value of either `random` or -`mac`. The default value for the key if unspecified is `random`. If it is set to random then use the random host interface names. -If it's set to `mac`, then generate a name in the form `inc1122334455`. +`instances.nic.host_name` サーバー設定キーを追加します。これは `random` か `mac` を指定できます。 +指定しない場合のデフォルト値は `random` です。 +`random` に設定するとランダムなホストインターフェース名を使用します。 +`mac` に設定すると `lxd1122334455` の形式で名前を生成します。 ## `image_copy_profile` -Adds ability to modify the set of profiles when image is copied. +イメージをコピーする際にプロファイルの組を修正できるようにします。 ## `container_syscall_intercept_sysinfo` -Adds the `security.syscalls.intercept.sysinfo` to allow the `sysinfo` syscall to be populated with cgroup-based resource usage information. +`security.syscalls.intercept.sysinfo` を追加し `sysinfo` システムコールで cgroup ベースのリソース使用状況を追加できるようにします。 ## `clustering_evacuation_mode` -This introduces a `mode` field to the evacuation request which allows -for overriding the evacuation mode traditionally set through -`cluster.evacuate`. +退避リクエストに `mode` フィールドを追加します。 +これにより従来 `cluster.evacuate` で設定されていた退避モードをオーバーライドできます。 ## `resources_pci_vpd` -Adds a new VPD struct to the PCI resource entries. -This struct extracts vendor provided data including the full product name and additional key/value configuration pairs. +PCI リソースエントリに VPS 構造体を追加します。 +この構造体には完全な製品名と追加の設定キーバリューペアを含むベンダー提供のデータが含まれます。 ## `qemu_raw_conf` -Introduces a `raw.qemu.conf` configuration key to override select sections of the generated `qemu.conf`. +生成された qemu.conf の指定したセクションをオーバライドするための `raw.qemu.conf` 設定キーを追加します。 ## `storage_cephfs_fscache` -Add support for `fscache`/`cachefilesd` on CephFS pools through a new `cephfs.fscache` configuration option. +CephFS プール上の `fscache`/`cachefilesd` をサポートするための `cephfs.fscache` 設定オプションを追加します。 ## `network_load_balancer` -This introduces the networking load balancer functionality. Allowing `ovn` networks to define port(s) on external -IP addresses that can be forwarded to one or more internal IP(s) inside their respective networks. +これはネットワークのロードバランサー機能を追加します。 +`ovn` ネットワークで外部 IP アドレス上にポートを定義し、ポートから対応するネットワーク内部の単一または複数の内部 IP にトラフィックをフォワードできます。 ## `vsock_api` -This introduces a bidirectional `vsock` interface which allows the `incus-agent` and the Incus server to communicate better. +これは双方向の `vsock` インターフェースを導入し、 `incus-agent` と Incus サーバーがよりよく連携できるようにします。 ## `instance_ready_state` -This introduces a new `Ready` state for instances which can be set using `/dev/incus`. +インスタンスに新しく `Ready` 状態を追加します。これは `/dev/incus` を使って設定できます。 ## `network_bgp_holdtime` -This introduces a new `bgp.peers..holdtime` configuration key to control the BGP hold time for a particular peer. +特定のピアの BGP ホールドタイムを制御するために `bgp.peers..holdtime` キーを追加します。 ## `storage_volumes_all_projects` -This introduces the ability to list storage volumes from all projects. +すべてのプロジェクトのストレージボリュームを一覧表示できるようにします。 ## `metrics_memory_oom_total` -This introduces a new `incus_memory_OOM_kills_total` metric to the `/1.0/metrics` API. -It reports the number of times the out of memory killer (`OOM`) has been triggered. +`/1.0/metrics` API に `incus_memory_OOM_kills_total` メトリックを追加します。 +メモリーキラー（`OOM`）が発動された回数を報告します。 ## `storage_buckets` -This introduces the storage bucket API. It allows the management of S3 object storage buckets for storage pools. +storage bucket API を追加します。ストレージプールのために S3 オブジェクトストレージのバケットの管理をできるようにします。 ## `storage_buckets_create_credentials` -This updates the storage bucket API to return initial admin credentials at bucket creation time. +これはバケット作成時に管理者の初期クレデンシャルを返すようにストレージバケット API を更新します。 ## `metrics_cpu_effective_total` -This introduces a new `incus_cpu_effective_total` metric to the `/1.0/metrics` API. -It reports the total number of effective CPUs. + +これは `lxd_cpu_effective_total` メトリックを `/1.0/metrics` API に追加します。 +有効な CPU の総数を返します。 ## `projects_networks_restricted_access` -Adds the `restricted.networks.access` project configuration key to indicate (as a comma-delimited list) which networks can be accessed inside the project. -If not specified, all networks are accessible (assuming it is also allowed by the `restricted.devices.nic` setting, described below). +プロジェクト内でアクセスできるネットワークを（カンマ区切りリストで）示す `restricted.networks.access` プロジェクト設定キーを追加します。 +指定しない場合は、すべてのネットワークがアクセスできます（後述の `restricted.devices.nic` 設定でも許可されている場合）。 -This also introduces a change whereby network access is controlled by the project's `restricted.devices.nic` setting: +これはまたプロジェクトの `restricted.devices.nic` 設定で制御されるネットワークアクセスにも変更をもたらします: -* If `restricted.devices.nic` is set to `managed` (the default if not specified), only managed networks are accessible. -* If `restricted.devices.nic` is set to `allow`, all networks are accessible (dependent on the `restricted.networks.access` setting). -* If `restricted.devices.nic` is set to `block`, no networks are accessible. +* `restricted.devices.nic` が `managed` に設定される場合（未設定時のデフォルト）, マネージドネットワークのみがアクセスできます。 +* `restricted.devices.nic` が `allow` に設定される場合、すべてのネットワークがアクセスできます（`restricted.networks.access` 設定に依存）。 +* `restricted.devices.nic` が `block` に設定される場合、どのネットワークにもアクセスできません。 ## `storage_buckets_local` -This introduces the ability to use storage buckets on local storage pools by setting the new `core.storage_buckets_address` global configuration setting. +これは `core.storage_buckets_address` グローバル設定を指定することでローカルストレージプール上のストレージバケットを使用できるようにします。 ## `loki` -This adds support for sending life cycle and logging events to a Loki server. +これはライフサイクルとロギングのイベントを Loki サーバーに送れるようにします。 -It adds the following global configuration keys: +以下のグローバル設定キーを追加します: -* `loki.api.ca_cert`: CA certificate which can be used when sending events to the Loki server -* `loki.api.url`: URL to the Loki server (protocol, name or IP and port) -* `loki.auth.username` and `loki.auth.password`: Used if Loki is behind a reverse proxy with basic authentication enabled -* `loki.labels`: Comma-separated list of values which are to be used as labels for Loki events. -* `loki.loglevel`: Minimum log level for events sent to the Loki server. -* `loki.types`: Types of events which are to be sent to the Loki server (`lifecycle` and/or `logging`). +* `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`）。 ## `acme` -This adds ACME support, which allows [Let's Encrypt](https://letsencrypt.org/) or other ACME services to issue certificates. +ACME サポートを追加します。これにより [Let's Encrypt](https://letsencrypt.org/) や他の ACME サービスを使って証明書を発行できます。 -It adds the following global configuration keys: +以下のグローバルの設定キーを追加します: -* `acme.domain`: The domain for which the certificate should be issued. -* `acme.email`: The email address used for the account of the ACME service. -* `acme.ca_url`: The directory URL of the ACME service, defaults to `https://acme-v02.api.letsencrypt.org/directory`. +* `acme.domain`: 証明書を発行するドメイン。 +* `acme.email`: ACME サービスのアカウントに使用する email アドレス。 +* `acme.ca_url`: ACME サービスのディレクトリー URL、デフォルトは `https://acme-v02.api.letsencrypt.org/directory`。 -It also adds the following endpoint, which is required for the HTTP-01 challenge: +また以下のエンドポイントを追加します。これは HTTP-01 チャレンジで必要です: * `/.well-known/acme-challenge/` ## `internal_metrics` -This adds internal metrics to the list of metrics. -These include: +これはメトリクスのリストに内部メトリクスを追加します。 +以下を含みます。 -* Total running operations -* Total active warnings -* Daemon uptime in seconds -* Go memory stats -* Number of goroutines +* 実行したオペレーションの総数 +* アクティブな警告の総数 +* デーモンの uptime（秒数） +* Go のメモリー統計 +* goroutine の数 ## `cluster_join_token_expiry` -This adds an expiry to cluster join tokens which defaults to 3 hours, but can be changed by setting the `cluster.join_token_expiry` configuration key. +クラスタジョイントークンに有効期限を追加します。デフォルトは 3 時間ですが、`cluster.join_token_expiry` 設定キーで変更できます。 ## `remote_token_expiry` -This adds an expiry to remote add join tokens. -It can be set in the `core.remote_token_expiry` configuration key, and default to no expiry. +リモートの追加ジョイントークンに有効期限を追加します。 +`core.remote_token_expiry` 設定キーで変更できます。デフォルトは無期限です。 ## `storage_volumes_created_at` -This change adds support for storing the creation date and time of storage volumes and their snapshots. +この変更によりストレージボリュームとそのスナップショットの作成日時を保管するようになります。 -This adds the `CreatedAt` field to the `StorageVolume` and `StorageVolumeSnapshot` API types. +これは `StorageVolume` と `StorageVolumeSnapshot` API タイプに `CreatedAt` フィールドを追加します。 ## `cpu_hotplug` -This adds CPU hotplugging for VMs. -Hotplugging is disabled when using CPU pinning, because this would require hotplugging NUMA devices as well, which is not possible. + +これは VM に CPU ホットプラグを追加します。 +CPU ピンニング使用時はホットプラグは無効になります。CPU ピンニングには NUMA デバイスのホットプラグも必要ですが、これはできないためです。 ## `projects_networks_zones` -This adds support for the `features.networks.zones` project feature, which changes which project network zones are -associated with when they are created. Previously network zones were tied to the value of `features.networks`, -meaning they were created in the same project as networks were. +プロジェクトに`features.networks.zones`の機能を追加します。 +これはネットワークゾーンが作成されたときにどのプロジェクトに関連付けされるかを変更します。 +以前はネットワークゾーンは`features.networks`の値に従っており、つまりネットワークと同じプロジェクト内に作られていました。 -Now this has been decoupled from `features.networks` to allow projects that share a network in the default project -(i.e those with `features.networks=false`) to have their own project level DNS zones that give a project oriented -"view" of the addresses on that shared network (which only includes addresses from instances in their project). +この拡張により`features.networks`から切り離され、複数のプロジェクトがデフォルトプロジェクト（たとえば `features.networks=false`と設定）内のネットワークを共有できるようになり、共有されたネットワークに対してプロジェクト指向の（プロジェクト内のインスタンスのアドレスのみを含むような）「ビュー」を提供するプロジェクト固有の DNS ゾーンを持てるようになりました。 -This also introduces a change to the network `dns.zone.forward` setting, which now accepts a comma-separated of -DNS zone names (a maximum of one per project) in order to associate a shared network with multiple zones. +これはまたネットワークの`dns.zone.forward`にも変更を及ぼし、複数のゾーンに共有ネットワークを関連付けるために（プロジェクト毎に最大 1 つの）DNS ゾーン名のカンマ区切りリストを指定できるようになりました。 -No change to the `dns.zone.reverse.*` settings have been made, they still only allow a single DNS zone to be set. -However the resulting zone content that is generated now includes `PTR` records covering addresses from all -projects that are referencing that network via one of their forward zones. +`dns.zone.reverse.*`設定は変更無しで、引き続き単一の DNS ゾーンのみが設定できます。 +しかし結果として生成されるゾーンの内容は、正引きゾーンの 1 つを経由してネットワークを参照するすべてのプロジェクトからのアドレスをカバーするような`PTR`レコードを含むようになりました。 -Existing projects that have `features.networks=true` will have `features.networks.zones=true` set automatically, -but new projects will need to specify this explicitly. +`features.networks=true`の設定を持つ既存のプロジェクトは自動的に`features.networks.zones=true`が設定されますが、新規のプロジェクトは明示的に設定する必要があります。 ## `instance_nic_txqueuelength` -Adds a `txqueuelen` key to control the `txqueuelen` parameter of the NIC device. +NIC デバイスの`txqueuelen`パラメーターを制御する`txqueuelen`キーを追加します。 ## `cluster_member_state` -Adds `GET /1.0/cluster/members//state` API endpoint and associated `ClusterMemberState` API response type. +`GET /1.0/cluster/members//state` API エンドポイントとそれに関連する`ClusterMemberState` API レスポンスタイプを追加します。 ## `instances_placement_scriptlet` -Adds support for a Starlark scriptlet to be provided to Incus to allow customized logic that controls placement of new instances in a cluster. +Starlark スクリプトレットを Incus に提供し、クラスタ内の新規インスタンスの配置を制御するカスタムロジックを使えるようにします。 -The Starlark scriptlet is provided to Incus via the new global configuration option `instances.placement.scriptlet`. +Starlark スクリプトレットは新しいグローバル設定オプション`instances.placement.scriptlet`により Incus に提供されます。 ## `storage_pool_source_wipe` -Adds support for a `source.wipe` Boolean on the storage pool, indicating -that Incus should wipe partition headers off the requested disk rather -than potentially fail due to pre-existing file systems. + +ストレージプールに`source.wipe`ブール値を追加し、Incus は要求されたディスクのパーティションヘッダーを消去する必要があることを示します。これにより、既存のファイルシステムがあることによる潜在的な失敗を回避できるようになります。 ## `zfs_block_mode` -This adds support for using ZFS block {spellexception}`filesystem` volumes allowing the use of different file systems on top of ZFS. +これにより、ZFS ブロック`filesystem`ボリュームを使用して、ZFS の上に異なるファイルシステムを使用することができるようになります。 -This adds the following new configuration options for ZFS storage pools: +これにより、ZFS ストレージプールに以下の新しい設定オプションが追加されます: * `volume.zfs.block_mode` * `volume.block.mount_options` @@ -2122,146 +2088,171 @@ This adds the following new configuration options for ZFS storage pools: ## `instance_generation_id` -Adds support for instance generation ID. The VM or container generation ID will change whenever the instance's place in time moves backwards. As of now, the generation ID is only exposed through to VM type instances. This allows for the VM guest OS to reinitialize any state it needs to avoid duplicating potential state that has already occurred: +インスタンスの generation ID のサポートが追加されます。VM またはコンテナの generation ID は、インスタンスの時間的な世代が後ろに移動するたびに変更されます。現時点では、 generation ID は VM タイプのインスタンスを通じてのみ公開されています。これにより、VM ゲスト OS は、既に発生した可能性のある状態の複製を回避するために必要な状態を再初期化できます: * `volatile.uuid.generation` ## `disk_io_cache` -This introduces a new `io.cache` property to disk devices which can be used to override the VM caching behavior. + +これは、ディスクデバイスに新しい`io.cache`プロパティを導入し、VM のキャッシング動作を上書きするために使用できます。 ## `amd_sev` -Adds support for AMD SEV (Secure Encrypted Virtualization) that can be used to encrypt the memory of a guest VM. -This adds the following new configuration options for SEV encryption: +AMD SEV（Secure Encrypted Virtualization）のサポートを追加します。ゲスト VM のメモリーを暗号化するのに使用できます。 + +これは SEV 暗号化に以下の新しい設定オプションを追加します: -* `security.sev` : (bool) is SEV enabled for this VM -* `security.sev.policy.es` : (bool) is SEV-ES enabled for this VM -* `security.sev.session.dh` : (string) guest owner's `base64`-encoded Diffie-Hellman key -* `security.sev.session.data` : (string) guest owner's `base64`-encoded session blob +* `security.sev` :（bool）この VM で SEV を有効化するか +* `security.sev.policy.es` :（bool）この VM で SEV-ES を有効化するか +* `security.sev.session.dh` :（string）ゲストオーナーの`base64`エンコードされた Diffie-Hellman キー +* `security.sev.session.data` :（string）ゲストオーナーの`base64`エンコードされた session blob ## `storage_pool_loop_resize` -This allows growing loop file backed storage pools by changing the `size` setting of the pool. + +これはループファイルをバックエンドとするストレージプールを、プールの`size`設定を変更することでサイズを拡大できるようにします。 ## `migration_vm_live` -This adds support for performing VM QEMU to QEMU live migration for both shared storage (clustered Ceph) and -non-shared storage pools. -This also adds the `CRIUType_VM_QEMU` value of `3` for the migration `CRIUType` `protobuf` field. +これは VM で QEMU から QEMU へのライブマイグレーションを（Ceph を含む）共有されたストレージと共有されないストレージプールの両方で実行するサポートを追加します。 + +これはさらにマイグレーションの `CRIUType` `protobuf` フィールドに `3` という `CRIUType_VM_QEMU` の値を追加します。 ## `ovn_nic_nesting` -This adds support for nesting an `ovn` NIC inside another `ovn` NIC on the same instance. -This allows for an OVN logical switch port to be tunneled inside another OVN NIC using VLAN tagging. -This feature is configured by specifying the parent NIC name using the `nested` property and the VLAN ID to use for tunneling with the `vlan` property. +これは同じインスタンスの `ovn` NIC を別の `ovn` NIC 内にネストするサポートを追加します。 +これは OVN ロジカルスイッチポートを VLAN タグを使用する別の OVN NIC の内側にトンネルできるようにします。 + +この機能は`nested`プロパティを使って親の NIC 名を指定し、`vlan`プロパティでトンネルに使用する VLAN ID を指定することで設定できます。 ## `oidc` -This adds support for OpenID Connect (OIDC) authentication. +OpenID Connect（OIDC）認証のサポートを追加します。 -This adds the following new configuration keys: +これは以下の設定キーを追加します: * `oidc.issuer` * `oidc.client.id` * `oidc.audience` ## `network_ovn_l3only` -This adds the ability to set an `ovn` network into "layer 3 only" mode. -This mode can be enabled at IPv4 or IPv6 level using `ipv4.l3only` and `ipv6.l3only` configuration options respectively. -With this mode enabled the following changes are made to the network: +これは `ovn` ネットワークを "layer 3 only" モードに設定する能力を追加します。 +このモードは `ipv4.l3only` と `ipv6.l3only` 設定オプションを使うことで IPv4 または IPv6 のレベルで有効化できます。 + +このモードを有効にすると、ネットワークは以下のように変更されます: -* The virtual router's internal port address will be configured with a single host netmask (e.g. /32 for IPv4 or /128 for IPv6). -* Static routes for active instance NIC addresses will be added to the virtual router. -* A discard route for the entire internal subnet will be added to the virtual router to prevent packets destined for inactive addresses from escaping to the uplink network. -* The DHCPv4 server will be configured to indicate that a netmask of 255.255.255.255 be used for instance configuration. +* 仮想ルータの内部ポートアドレスが単一ホストのネットマスクで設定されます（例：IPv4 では /32 あるいは IPv6 では /128）。 +* アクティブなインスタンスの NIC アドレスへの静的ルートが仮想ルータに追加されます。 +* アクティブでないアドレス向けのパケットがアップリンクのネットワークからエスケープされるのを防ぐために、内部のサブネット全体への破棄ルートが仮想ルータに追加されます。 +* 255.255.255.255 のネットマスクがインスタンス設定で使用されるように DHCPv4 サーバーが設定されます。 ## `ovn_nic_acceleration_vdpa` -This updates the `ovn_nic_acceleration` API extension. The `acceleration` configuration key for OVN NICs can now takes the value `vdpa` to support Virtual Data Path Acceleration (VDPA). +これは `ovn_nic_acceleration` API 拡張をアップデートします。OVN NIC の`acceleration`設定キーが Virtual Data Path Acceleration（VDPA）をサポートするための `vdpa` という値を受け付けられるようになります。 ## `cluster_healing` -This adds cluster healing which automatically evacuates offline cluster members. -This adds the following new configuration key: +これにより、オフラインのクラスタメンバーを自動的に退避させるクラスタヒーリングが追加されます。 + +次の新しい設定キーが追加されます: * `cluster.healing_threshold` -The configuration key takes an integer, and can be disabled by setting it to 0 (default). If set, the value represents the threshold after which an offline cluster member is to be evacuated. In case the value is lower than `cluster.offline_threshold`, that value will be used instead. +この設定キーは整数を取り、0（デフォルト）に設定することで無効化できます。設定された場合、その値はオフラインのクラスタメンバーが退避させられる閾値を表します。もし値が`cluster.offline_threshold`よりも低い場合、その値が代わりに使用されます。 -When the offline cluster member is evacuated, only remote-backed instances will be migrated. Local instances will be ignored as there is no way of migrating them once the cluster member is offline. +オフラインのクラスタメンバーが退避させられると、リモートバックアップされたインスタンスのみが移行されます。ローカルインスタンスは、クラスタメンバーがオフラインになった際にそれらを移行する方法がないため、無視されます。 ## `instances_state_total` -This extension adds a new `total` field to `InstanceStateDisk` and `InstanceStateMemory`, both part of the instance's state API. + +この拡張は、インスタンスの状態 API の一部である`InstanceStateDisk`と`InstanceStateMemory`に新しい`total`フィールドを追加します。 ## `auth_user` -Add current user details to the main API endpoint. -This introduces: +メイン API エンドポイントに現在のユーザーの詳細情報を追加します。 + +以下の項目を追加します: * `auth_user_name` * `auth_user_method` ## `security_csm` -Introduce a new `security.csm` configuration key to control the use of -`CSM` (Compatibility Support Module) to allow legacy operating systems to -be run in Incus VMs. + +`CSM`（Compatibility Support Module）の使用を制御する`security.csm`設定キーを追加し、レガシーなオペレーティングシステムを Incus VM 内で稼働できるようにします。 ## `instances_rebuild` -This extension adds the ability to rebuild an instance with the same origin image, alternate image or as empty. A new `POST /1.0/instances//rebuild?project=` API endpoint has been added as well as a new CLI command [`incus rebuild`](incus_rebuild.md). + +この拡張はインスタンスを同じイメージ、別のイメージ、あるいは空のイメージで再構築できるようにします。 +`POST /1.0/instances//rebuild?project=` API エンドポイントと[`incus rebuild`](incus_rebuild.md) CLI コマンドを新しく追加します。 ## `numa_cpu_placement` -This adds the possibility to place a set of CPUs in a desired set of NUMA nodes. -This adds the following new configuration key: +これは CPU の組を指定の NUMA ノードの組内に配置できるようにします。 + +以下の設定キーを追加します: -* `limits.cpu.nodes` : (string) comma-separated list of NUMA node IDs or NUMA node ID ranges to place the CPUs (chosen with a dynamic value of `limits.cpu`) in. +* `limits.cpu.nodes` :（string）（`limits.cpu`の動的な値により選ばれた）CPU を配置する NUMA ノード ID または NUMA ノード ID の範囲のカンマ区切りリスト。 ## `custom_volume_iso` -This adds the possibility to import ISO images as custom storage volumes. -This adds the `--type` flag to [`incus storage volume import`](incus_storage_volume_import.md). +これは ISO イメージをカスタムストレージボリュームとしてインポートできるようにします。 + +[`incus storage volume import`](incus_storage_volume_import.md)に`--type`フラグを追加します。 ## `network_allocations` -This adds the possibility to list a Incus deployment's network allocations. -Through the [`incus network list-allocations`](incus_network_list-allocations.md) command and the `--project | --all-projects` flags, -you can list all the used IP addresses, hardware addresses (for instances), resource URIs and whether it uses NAT for -each `instance`, `network`, `network forward` and `network load-balancer`. +これは Incus インストール環境のネットワーク割り当てを一覧表示できるようにします。 + +[`incus network list-allocations`](incus_network_list-allocations.md)コマンドと`--project | --all-projects`フラグを使って、使用中の IP アドレス、（インスタンスの）ハードウェアドレス、リソース URI、NAT を使用しているかどうかを各`instance`、`network`、`network forward`、`network load-balancer`について一覧表示できます。 ## `zfs_delegate` -This implements a new `zfs.delegate` volume Boolean for volumes on a ZFS storage driver. -When enabled and a suitable system is in use (requires ZFS 2.2 or higher), the ZFS dataset will be delegated to the container, allowing for its use through the `zfs` command line tool. + +これは ZFS ストレージドライバーのボリュームに `zfs.delegate` という Boolean 設定を追加します。 +有効にすると対応したシステム（ZFS 2.2 以上が必要）が使用されている場合に、ZFS dataset はコンテナに移譲され、`zfs` コマンドラインツールを使って使用できます。 ## `storage_api_remote_volume_snapshot_copy` -This allows copying storage volume snapshots to and from remotes. +これはストレージボリュームスナップショットをリモートとローカル間でコピーできるようにします。 ## `operations_get_query_all_projects` -This introduces support for the `all-projects` query parameter for the GET API calls to both `/1.0/operations` and `/1.0/operations?recursion=1`. -This parameter allows bypassing the project name filter. +これは `/1.0/operations` と `/1.0/operations?recursion=1` の両方の GET API 呼び出しに `all-projects` クエリパラメーターを追加します。 +このパラメーターはプロジェクト名のフィルターをバイパスできるようにします。 ## `metadata_configuration` -Adds the `GET /1.0/metadata/configuration` API endpoint to retrieve the generated metadata configuration in a JSON format. The JSON structure adopts the structure ```"configs" > `ENTITY` > `ENTITY_SECTION` > "keys" > [, , ...]```. -Check the list of {doc}`configuration options ` to see which configuration options are included. + +`GET /1.0/metadata/configuration` API エンドポイントを追加し、生成されたメタデータ設定を JSON 形式で取得できるようにします。 +JSON の構造は ```"configs" > `ENTITY` > `ENTITY_SECTION` > "keys" > [, , ...]``` という形式です。 +どの設定オプションが含まれるかは {doc}`configuration options ` の一覧を参照してください。 ## `syslog_socket` -This introduces a syslog socket that can receive syslog formatted log messages. These can be viewed in the events API and `incus monitor`, and can be forwarded to Loki. To enable this feature, set `core.syslog_socket` to `true`. +syslog 形式のログメッセージを受信できる syslog ソケットを追加します。 +これはイベント API と `incus monitor` で参照でき、Loki にフォワードできます。 +この機能を有効にするには `core.syslog_socket` を `true` に設定してください。 ## `event_lifecycle_name_and_project` -This adds the fields `Name` and `Project` to `lifecycle` events. +これは `lifecycle` イベントに `Name` と `Project` フィールドを追加します。 ## `instances_nic_limits_priority` -This introduces a new per-NIC `limits.priority` option that works with both cgroup1 and cgroup2 unlike the deprecated `limits.network.priority` instance setting, which only worked with cgroup1. +これは NIC 単位に `limits.priority` というオプションを追加します。 +これは deprecated になった（cgroup1 のみで使える）`limits.network.priority` インスタンス設定と異なり、cgroup1 と cgroup2 の両方で使えます。 ## `disk_initial_volume_configuration` -This API extension provides the capability to set initial volume configurations for instance root devices. -Initial volume configurations are prefixed with `initial.` and can be specified either through profiles or directly -during instance initialization using the `--device` flag. +この API 拡張はインスタンスのルートデバイスに初期ボリューム設定を指定できるよいうにします。 +初期ボリューム設定は `initial.` という接頭辞がつけられ、インスタンス初期化時に `--device` フラグを使ってプロファイル経由または直接指定できます。 + +これらの設定はインスタンスの作成時にのみ適用され、その後の修正時には既存のデバイスに影響しないことに注意してください。 + +## `operation_wait` + +この API 拡張はサーバーに `/1.0/operations/{id}/wait` エンドポイントが存在することを示します。 +これはクライアントに `/1.0/events` エンドポイント経由でイベントの完了を待つ代わりにこのエンドポイントを使えることを示します。 +`/1.0/events` endpoint. + +## `image_restriction_privileged` -Note that these configuration are applied only at the time of instance creation and subsequent modifications have -no effect on existing devices. +この拡張は `requirements.privileged` というイメージの制限を追加します。 +`false` に設定すると特権コンテナでイメージが使用できなくなります。 diff --git a/doc/api.md b/doc/api.md index 392747cb78d..f84ce67c592 100644 --- a/doc/api.md +++ b/doc/api.md @@ -3,10 +3,10 @@ ```{toctree} :maxdepth: 1 -Main API documentation -rest-api-spec -Main API extensions -Instance API documentation -Events API documentation -Metrics API documentation +メイン API ドキュメント +メイン API 仕様 +メイン API 拡張 +Instance API ドキュメント +Events API ドキュメント +Metrics API ドキュメント ``` diff --git a/doc/architectures.md b/doc/architectures.md index cfce470b686..3fecb16f9e4 100644 --- a/doc/architectures.md +++ b/doc/architectures.md @@ -1,31 +1,31 @@ (architectures)= -# Architectures +# アーキテクチャ -Incus can run on just about any architecture that is supported by the Linux kernel and by Go. +Incus は Linux カーネルと Go でサポートされるあらゆるアーキテクチャ上で稼働できます。 -Some entities in Incus are tied to an architecture, for example, the instances, instance snapshots and images. +Incus の一部のエンティティ、たとえば、インスタンス、インスタンススナップショット、イメージはアーキテクチャに依存します。 -The following table lists all supported architectures including their unique identifier and the name used to refer to them. -The architecture names are typically aligned with the Linux kernel architecture names. +下記のテーブルはサポートされるすべてのアーキテクチャを識別子と参照するための名前をリストアップします。 +アーキテクチャ名は通常は Linux のカーネルアーキテクチャ名と揃えてあります。 -ID | Name | Notes | Personalities -:--- | :--- | :---- | :------------ -1 | `i686` | 32bit Intel x86 | -2 | `x86_64` | 64bit Intel x86 | `x86` -3 | `armv7l` | 32bit ARMv7 little-endian | -4 | `aarch64` | 64bit ARMv8 little-endian | `armv7` (optional) -5 | `ppc` | 32bit PowerPC big-endian | -6 | `ppc64` | 64bit PowerPC big-endian | `powerpc` -7 | `ppc64le` | 64bit PowerPC little-endian | -8 | `s390x` | 64bit ESA/390 big-endian | -9 | `mips` | 32bit MIPS | -10 | `mips64` | 64bit MIPS | `mips` -11 | `riscv32` | 32bit RISC-V little-endian | -12 | `riscv64` | 64bit RISC-V little-endian | +ID | 名前 | 注釈 | パーソナリティ +:--- | :--- | :---- | :------------ +1 | `i686` | 32bit Intel x86 | +2 | `x86_64` | 64bit Intel x86 | `x86` +3 | `armv7l` | 32bit ARMv7 リトルエンディアン | +4 | `aarch64` | 64bit ARMv8 リトルエンディアン | `armv7` (省略可能) +5 | `ppc` | 32bit PowerPC ビッグエンディアン | +6 | `ppc64` | 64bit PowerPC ビッグエンディアン | `powerpc` +7 | `ppc64le` | 64bit PowerPC リトルエンディアン | +8 | `s390x` | 64bit ESA/390 ビッグエンディアン | +9 | `mips` | 32bit MIPS | +10 | `mips64` | 64bit MIPS | `mips` +11 | `riscv32` | 32bit RISC-V リトルエンディアン | +12 | `riscv64` | 64bit RISC-V リトルエンディアン | ```{note} -Incus cares only about the kernel architecture, not the particular userspace flavor as determined by the toolchain. +Incus はカーネルアーキテクチャのみに影響し、ツールチェインで決定される特定のユーザースペースのフレーバーには影響しません。 -That means that Incus considers ARMv7 hard-float to be the same as ARMv7 soft-float and refers to both as `armv7`. -If useful to the user, the exact userspace ABI may be set as an image and container property, allowing easy query. +これは Incus は ARMv7 hard-float を ARMv7 soft-float と同じとして扱い、両方を`armv7`として参照することを意味します。 +もしユーザーにとって有用であれば、正確なユーザースペースのABIがイメージとコンテナプロパティとして設定でき、簡単に問い合わせできます。 ``` diff --git a/doc/authentication.md b/doc/authentication.md index 2be075c7b50..38eead5b9ae 100644 --- a/doc/authentication.md +++ b/doc/authentication.md @@ -1,157 +1,155 @@ (authentication)= -# Remote API authentication +# リモートAPI認証 -Remote communications with the Incus daemon happen using JSON over HTTPS. +Incus デーモンとのリモート通信は、HTTPS 上の JSON を使って行われます。 -To be able to access the remote API, clients must authenticate with the Incus server. -The following authentication methods are supported: +リモート API にアクセスするためには、クライアントは Incus サーバーとの間で認証を行う必要があります。 +以下の認証方法がサポートされています: - {ref}`authentication-tls-certs` - {ref}`authentication-openid` (authentication-tls-certs)= -## TLS client certificates +## TLSクライアント証明書 -When using {abbr}`TLS (Transport Layer Security)` client certificates for authentication, both the client and the server will generate a key pair the first time they're launched. -The server will use that key pair for all HTTPS connections to the Incus socket. -The client will use its certificate as a client certificate for any client-server communication. +認証に{abbr}`TLS (Transport Layer Security)`クライアント証明書を使用する場合、クライアントとサーバーの両方が最初に起動したときにキーペアを生成します。 +サーバーはそのキーペアを Incus ソケットへのすべての HTTPS 接続に使用します。 +クライアントは、その証明書をクライアント証明書として、あらゆるクライアント・サーバー間の通信に使用します。 -To cause certificates to be regenerated, simply remove the old ones. -On the next connection, a new certificate is generated. +証明書を再生成させるには、単に古いものを削除します。 +次の接続時には、新しい証明書が生成されます。 -### Communication protocol +### 通信プロトコル -The supported protocol must be TLS 1.3 or better. +サポートしているプロトコルは TLS 1.3 以上である必要があります。 -It's possible to force Incus to accept TLS 1.2 by setting the `Incus_INSECURE_TLS` environment variable on both client and server. -However this isn't a supported setup and should only ever be used when forced to use an outdated corporate proxy. +`INCUS_INSECURE_TLS`環境変数をクライアントとサーバーの両方で設定することにより Incus が TLS 1.2 を受け入れるようにすることはできます。 +しかし、これはサポートされる構成ではなく、時代遅れな企業プロキシを使うために強制される場合にのみ使用すべきです。 -All communications must use perfect forward secrecy, and ciphers must be limited to strong elliptic curve ones (such as ECDHE-RSA or ECDHE-ECDSA). +すべての通信には完全な前方秘匿を使用し、暗号は強力な楕円曲線（ECDHE-RSA や ECDHE-ECDSA など）に限定してください。 -Any generated key should be at least 4096 bit RSA, preferably 384 bit ECDSA. -When using signatures, only SHA-2 signatures should be trusted. +生成される鍵は最低でも 4096 ビットの RSA、できれば 384 ビットの ECDSA が望ましいです。 +署名を使用する場合は、SHA-2 署名のみを信頼すべきです。 -Since we control both client and server, there is no reason to support -any backward compatibility to broken protocol or ciphers. +我々はクライアントとサーバーの両方を管理しているので、壊れたプロトコルや暗号の下位互換をサポートする理由はありません。 (authentication-trusted-clients)= -### Trusted TLS clients +### 信頼できるTLSクライアント -You can obtain the list of TLS certificates trusted by a Incus server with [`incus config trust list`](incus_config_trust_list.md). +Incus サーバーが信頼する TLS 証明書のリストは、 [`incus config trust list`](incus_config_trust_list.md) で取得できます。 -Trusted clients can be added in either of the following ways: +信頼できるクライアントは以下のいずれかの方法で追加できます: - {ref}`authentication-add-certs` - {ref}`authentication-token` -The workflow to authenticate with the server is similar to that of SSH, where an initial connection to an unknown server triggers a prompt: +サーバーとの認証を行うワークフローは、SSH の場合と同様で、未知のサーバーへの初回接続時にプロンプトが表示されます: -1. When the user adds a server with [`incus remote add`](incus_remote_add.md), the server is contacted over HTTPS, its certificate is downloaded and the fingerprint is shown to the user. -1. The user is asked to confirm that this is indeed the server's fingerprint, which they can manually check by connecting to the server or by asking someone with access to the server to run the info command and compare the fingerprints. -1. The server attempts to authenticate the client: +1. ユーザーが [`incus remote add`](incus_remote_add.md) でサーバーを追加すると、HTTPS でサーバーに接続され、その証明書がダウンロードされ、フィンガープリントがユーザーに表示されます。 +1. ユーザーは、これが本当にサーバーのフィンガープリントであることを確認するよう求められます。これは、サーバーに接続して手動で確認するか、サーバーにアクセスできる人に info コマンドを実行してフィンガープリントを比較してもらうことで確認できます。 +1. サーバーはクライアントの認証を試みます: - - If the client certificate is in the server's trust store, the connection is granted. - - If the client certificate is not in the server's trust store, the server prompts the user for a token or the trust password. - If the provided token or trust password matches, the client certificate is added to the server's trust store and the connection is granted. - Otherwise, the connection is rejected. + - クライアント証明書がサーバーのトラストストアにある場合は、接続が許可されます。 + - クライアント証明書がサーバーのトラストストアにない場合、サーバーはユーザーにトークンの入力を求めます。 + 提供されたトークンが一致した場合、クライアント証明書はサーバーのトラストストアに追加され、接続が許可されます。 + そうでない場合は、接続が拒否されます。 -To revoke trust to a client, remove its certificate from the server with [`incus config trust remove `](incus_config_trust_remove.md). +クライアントへの信頼を取り消すには、[`incus config trust remove `](incus_config_trust_remove.md) でそのクライアント証明書をサーバーから削除します。 -It's possible to restrict a TLS client to one or multiple projects. -In this case, the client will also be prevented from performing global configuration changes or altering the configuration (limits, restrictions) of the projects it's allowed access to. +TLS クライアントを 1 つまたは複数のプロジェクトに制限できます。 +この場合、クライアントは、グローバルな構成変更の実行や、アクセスを許可されたプロジェクトの構成（制限、制約）の変更もできなくなります。 -To restrict access, use [`incus config trust edit `](incus_config_trust_edit.md). -Set the `restricted` key to `true` and specify a list of projects to restrict the client to. -If the list of projects is empty, the client will not be allowed access to any of them. +アクセスを制限するには、[`incus config trust edit `](incus_config_trust_edit.md) を使用します。 +`restricted`キーを`true`に設定し、クライアントのアクセスを制限するプロジェクトのリストを指定します。 +プロジェクトのリストが空の場合、クライアントはどのプロジェクトへのアクセスも許可されません。 (authentication-add-certs)= -#### Adding trusted certificates to the server +#### 信頼できる証明書をサーバーに追加する -The preferred way to add trusted clients is to directly add their certificates to the trust store on the server. -To do so, copy the client certificate to the server and register it using [`incus config trust add `](incus_config_trust_add.md). +信頼できるクライアントを追加するには、そのクライアント証明書をサーバーのトラストストアに直接追加するのが望ましい方法です。 +これを行うには、クライアント証明書をサーバーにコピーし、[`incus config trust add `](incus_config_trust_add.md) で登録します。 (authentication-token)= -#### Adding client certificates using tokens +#### トークンを使ったクライアント証明書の追加 -You can also add new clients by using tokens. This is a safer way than using the trust password, because tokens expire after a configurable time ({config:option}`server-core:core.remote_token_expiry`) or once they've been used. +トークンを使って新しいクライアントを追加することもできます。 +トークンは調整可能な時間（{config:option}`server-core:core.remote_token_expiry`）を過ぎるか一度使用すると無効になります。 -To use this method, generate a token for each client by calling [`incus config trust add`](incus_config_trust_add.md), which will prompt for the client name. -The clients can then add their certificates to the server's trust store by providing the generated token when prompted for the trust password. +この方法を使用するには、クライアント名の入力を促す [`incus config trust add`](incus_config_trust_add.md) を呼び出して、各クライアント用のトークンを生成します。 +その後、クライアントは、生成されたトークンをプロンプトが表示されたときに入力することで、自分の証明書をサーバーのトラストストアに追加することができます。 + +クライアント側から新しい信頼関係を確立できるようにするには、サーバーにトラストパスワード({config:option}`server-core:core.remote_token_expiry`)を設定する必要があります。クライアントは、プロンプト時にトラストパスワードを入力することで、自分の証明書をサーバーのトラストストアに追加することができます。 ```{note} -If your Incus server is behind NAT, you must specify its external public address when adding it as a remote for a client: +Incus サーバーが NAT の後ろ側にいる場合、クライアント用のリモートを追加する際には外部のパブリックアドレスを指定する必要があります: incus remote add -When you are prompted for the admin password, specify the generated token. - -When generating the token on the server, Incus includes a list of IP addresses that the client can use to access the server. -However, if the server is behind NAT, these addresses might be local addresses that the client cannot connect to. -In this case, you must specify the external address manually. +サーバーでトークンを生成する際、 Incus はクライアントがサーバーにアクセスするために使える IP アドレスのリストを含めます。 +しかし、サーバーが NAT の後ろ側にいる場合、これらのアドレスはクライアントが接続できないローカルアドレスの場合があります。 +その場合、手動で外部アドレスを指定する必要があります。 ``` -Alternatively, the clients can provide the token directly when adding the remote: [`incus remote add `](incus_remote_add.md). +あるいは、クライアントはリモートの追加時にトークンを直接提供することもできます: [`incus remote add `](incus_remote_add.md). -### Using a PKI system +### PKI システムの使用 -In a {abbr}`PKI (Public key infrastructure)` setup, a system administrator manages a central PKI that issues client certificates for all the Incus clients and server certificates for all the Incus daemons. +{abbr}`PKI (Public key infrastructure)`の設定では、システム管理者が中央の PKI を管理し、すべての Incus クライアント用のクライアント証明書とすべての Incus デーモン用のサーバー証明書を発行します。 -To enable PKI mode, complete the following steps: +PKI モードを有効にするには、以下の手順を実行します: -1. Add the {abbr}`CA (Certificate authority)` certificate to all machines: +1. すべてのマシンに{abbr}`CA（Certificate authority、認証局）`の証明書を追加します: - - Place the `client.ca` file in the clients' configuration directories (`~/.config/incus`). - - Place the `server.ca` file in the server's configuration directory (`/var/lib/incus`). -1. Place the certificates issued by the CA on the clients and the server, replacing the automatically generated ones. -1. Restart the server. + - `client.ca`ファイルをクライアントの設定ディレクトリー（`~/.config/incus`）に置く。 + - `server.ca`ファイルをサーバーの設定ディレクトリー（`/var/lib/incus`）に置く。 +1. CA から発行された証明書をクライアントとサーバーに配置し、自動生成された証明書を置き換える。 +1. サーバーを再起動します。 -In that mode, any connection to a Incus daemon will be done using the -pre-seeded CA certificate. +このモードでは、Incus デーモンへの接続はすべて、事前に発行された CA 証明書を使って行われます。 -If the server certificate isn't signed by the CA, the connection will simply go through the normal authentication mechanism. -If the server certificate is valid and signed by the CA, then the connection continues without prompting the user for the certificate. +もしサーバー証明書が CA によって署名されていなければ、接続は単に通常の認証メカニズムを通過します。 +サーバー証明書が有効で CA によって署名されていれば、ユーザーに証明書を求めるプロンプトを出さずに接続を続行します。 -Note that the generated certificates are not automatically trusted. You must still add them to the server in one of the ways described in {ref}`authentication-trusted-clients`. +生成された証明書は自動的には信頼されないことに注意してください。そのため、{ref}`authentication-trusted-clients`で説明している方法のいずれかで、サーバーに追加する必要があります。 (authentication-openid)= -## OpenID Connect authentication +## OpenID Connect認証 -Incus supports using [OpenID Connect](https://openid.net/connect/) to authenticate users through an {abbr}`OIDC (OpenID Connect)` Identity Provider. +Incus は[OpenID Connect](https://openid.net/connect/)を使用して、{abbr}`OIDC (OpenID Connect)` アイデンティティプロバイダーを通じてユーザーを認証することをサポートしています。 ```{note} -OpenID Connect authentication is currently under development. -Starting with Incus 5.13, authentication through OpenID Connect is supported, but there is no user role handling in place so far. -Any user that authenticates through the configured OIDC Identity Provider gets full access to Incus. +OpenID Connect を通じた認証がサポートされていますが、まだユーザーロールの取り扱いはありません。 +設定された OIDC アイデンティティプロバイダーを通じて認証するすべてのユーザーは、Incus へのフルアクセスを得ます。 ``` -To configure Incus to use OIDC authentication, set the [`oidc.*`](server-options-oidc) server configuration options. -Your OIDC provider must be configured to enable the [Device Authorization Grant](https://oauth.net/2/device-flow/) type. +Incus を OIDC 認証を使用するように設定するには、[`oidc.*`](server-options-oidc)サーバー設定オプションを設定します。 +あなたの OIDC プロバイダーは[Device Authorization Grant](https://oauth.net/2/device-flow/)タイプを有効にするように設定する必要があります。 -To add a remote pointing to a Incus server configured with OIDC authentication, run [`incus remote add `](incus_remote_add.md). -You are then prompted to authenticate through your web browser, where you must confirm the device code that Incus uses. -The Incus client then retrieves and stores the access and refresh tokens and provides those to Incus for all interactions. +OIDC 認証で設定された Incus サーバーを指すリモートを追加するには、[`incus remote add `](incus_remote_add.md) を実行します。 +その後、ウェブブラウザで認証を求められ、Incus が使用するデバイスコードを確認する必要があります。 +Incus クライアントはその後、アクセストークンとリフレッシュトークンを取得し保存し、それらを Incus とのすべてのやりとりに使用します。 (authentication-server-certificate)= -## TLS server certificate +## TLS サーバー証明書 -Incus supports issuing server certificates using {abbr}`ACME (Automatic Certificate Management Environment)` services, for example, [Let's Encrypt](https://letsencrypt.org/). +Incus は {abbr}`ACME (Automatic Certificate Management Environment)` サービス（たとえば、[Let's Encrypt](https://letsencrypt.org/)）を使ったサーバー証明書の発行をサポートします。 -To enable this feature, set the following server configuration: +この機能を有効にするには、以下のサーバー設定をしてください: -- {config:option}`server-acme:acme.domain`: The domain for which the certificate should be issued. -- {config:option}`server-acme:acme.email`: The email address used for the account of the ACME service. -- {config:option}`server-acme:acme.agree_tos`: Must be set to `true` to agree to the ACME service's terms of service. -- {config:option}`server-acme:acme.ca_url`: The directory URL of the ACME service. By default, Incus uses "Let's Encrypt". +- {config:option}`server-acme:acme.domain`: 証明書を発行するドメイン。 +- {config:option}`server-acme:acme.email`: ACME サービスのアカウントに使用する email アドレス。 +- {config:option}`server-acme:acme.agree_tos`: ACME サービスの利用規約に同意するためには `true` に設定する必要あり。 +- {config:option}`server-acme:acme.ca_url`: ACME サービスのディレクトリー URL。デフォルトでは Incus は "Let's Encrypt" を使用。 -For this feature to work, Incus must be reachable from port 80. -This can be achieved by using a reverse proxy such as [HAProxy](http://www.haproxy.org/). +この機能を利用するには、 Incus は 80 番ポートを開放する必要があります。 +これは [HAProxy](http://www.haproxy.org/) のようなリバースプロキシを使用することで実現できます。 -Here's a minimal HAProxy configuration that uses `incus.example.net` as the domain. -After the certificate has been issued, Incus will be reachable from `https://incus.example.net/`. +以下は `incus.example.net` をドメインとして使用する HAProxy の最小限の設定です。 +証明書が発行された後、 Incus は`https://incus.example.net/` でアクセスできます。 ``` # Global configuration @@ -227,24 +225,24 @@ backend incus-nodes server incus-node03 1.2.3.6:8443 check ``` -## Failure scenarios +## 失敗のシナリオ -In the following scenarios, authentication is expected to fail. +以下のシナリオでは認証は失敗します。 -### Server certificate changed +### サーバー証明書が変更された場合 -The server certificate might change in the following cases: +サーバー証明書は以下の場合に変更されるかも知れません: -- The server was fully reinstalled and therefore got a new certificate. -- The connection is being intercepted ({abbr}`MITM (Machine in the middle)`). +- サーバーが完全に再インストールされたため新しい証明書に変わった。 +- 接続がインターセプトされた（{abbr}`MITM (Machine in the middle)`）。 -In such cases, the client will refuse to connect to the server because the certificate fingerprint does not match the fingerprint in the configuration for this remote. +このような場合、このリモートの設定内のフィンガープリントと証明書のフィンガープリントが一致しないため、クライアントはサーバーへの接続を拒否します。 -It is then up to the user to contact the server administrator to check if the certificate did in fact change. -If it did, the certificate can be replaced by the new one, or the remote can be removed altogether and re-added. +この場合サーバー管理者に連絡して証明書が実際に変更されたのかを確認するのはユーザー次第です。 +実際に変更されたのであれば、証明書を新しいものに置き換えるか、リモートを削除して追加し直すことができます。 -### Server trust relationship revoked +### サーバーとの信頼関係が取り消された場合 -The server trust relationship is revoked for a client if another trusted client or the local server administrator removes the trust entry for the client on the server. +別の信頼されたクライアントまたはローカルのサーバー管理者がサーバー上で対象のクライアントの信頼エントリを削除した場合、そのクライアントに対するサーバーの信頼関係は取り消されます。 -In this case, the server still uses the same certificate, but all API calls return a 403 code with an error indicating that the client isn't trusted. +この場合、サーバーは引き続き同じ証明書を使用していますが、すべての API 呼び出しは対象のクライアントが信頼されていないことを示す 403 のステータスコードを返します。 diff --git a/doc/backup.md b/doc/backup.md index 9dc349d388f..ac7ab869ef1 100644 --- a/doc/backup.md +++ b/doc/backup.md @@ -1,107 +1,108 @@ (backups)= -# How to back up a Incus server +# Incusサーバーをバックアップする -In a production setup, you should always back up the contents of your Incus server. +本番環境では、常に Incus サーバーのデータをバックアップすべきです。 -The Incus server contains a variety of different entities, and when choosing your backup strategy, you must decide which of these entities you want to back up and how frequently you want to save them. +Incus サーバーはさまざまなエンティティを含んでおり、バックアップ戦略を選択する際には、これらのエンティティのうちどれをバックアップの対象にするかとどれぐらいの頻度で保存するかを決定する必要があります。 -## What to back up +## 何をバックアップするか -The various contents of your Incus server are located on your file system and, in addition, recorded in the {ref}`Incus database `. -Therefore, only backing up the database or only backing up the files on disk does not give you a full functional backup. +Incus サーバーのさまざまなコンテンツはファイルシステム上に配置されるものと、それに加えて、{ref}`Incus database `に記録されるものがあります。 +ですので、データベースをバックアップするだけあるいはディスク上のファイルをバックアップするだけでは完全に機能するバックアップにはなりません。 -Your Incus server contains the following entities: +Incus サーバーは以下のエンティティを含んでいます: -- Instances (database records and file systems) -- Images (database records, image files, and file systems) -- Networks (database records and state files) -- Profiles (database records) -- Storage volumes (database records and file systems) +- インスタンス (データベースのレコードとファイルシステム) +- イメージ (データベースのレコード、イメージファイル、そしてファイルシステム) +- ネットワーク (データベースのレコードと状態ファイル) +- プロファイル (データベースのレコード) +- ストレージボリューム (データベースのレコードとファイルシステム) -Consider which of these you need to back up. -For example, if you don't use custom images, you don't need to back up your images since they are available on the image server. -If you use only the `default` profile, or only the standard `incusbr0` network bridge, you might not need to worry about backing them up, because they can easily be re-created. +これらのうちどれをバックアップする必要があるかを検討してください。 +たとえば、カスタムイメージを使用していなければ、イメージはイメージサーバーに存在するのでバックアップは不要です。 +`default`プロファイルしか使用していなかったり、標準の`incusbr0`ネットワークブリッジしか使用していない場合、それらは簡単に再生成できますので、バックアップする必要はないかもしれません。 -## Full backup +## フルバックアップ -To create a full backup of all contents of your Incus server, back up the `/var/lib/incus` directory. +Incus サーバーのすべてのコンテンツをフルバックアップするには、`/var/lib/incus`ディレクトリーをバックアップしてください。 -This directory contains your local storage, the Incus database, and your configuration. -It does not contain separate storage devices, however. -That means that whether the directory also contains the data of your instances depends on the storage drivers that you use. +このディレクトリーはローカルストーレジ、Incus データベース、あなたの設定を含みます。 +ただし、分離されたストレージデバイスは含みません。 +つまりディレクトリーがあなたのインスタンスのデータも含むかはお使いのストレージドライバーによります。 ```{important} -If your Incus server uses any external storage (for example, LVM volume groups, ZFS zpools, or any other resource that isn't directly self-contained to Incus), you must back this up separately. +Incusサーバが外部ストレージ（たとえば、LVMボリュームグループ、ZFS zpool、あるいは何か他のIncus自身に直接含まれないような外部リソース）を使っている場合、それらは別途バックアップが必要です。 -See {ref}`howto-storage-backup-volume` for instructions. +手順については{ref}`howto-storage-backup-volume`を参照してください。 ``` -To back up your data, create a tarball of `/var/lib/incus`. -If your system uses `/etc/subuid` and `/etc/subgid` file, you should also back up these files. -Restoring them avoids needless shifting of instance file systems. +データをバックアップするには、`/var/lib/incus`の tarball を作成してください。 +あなたのシステムが`/etc/subuid`と`/etc/subgid`ファイルをお使いの場合、これらのファイルもバックアップしてください。 +これらをリストアするとインスタンスのファイルシステムで不要なシフトを防げます。 -To restore your data, complete the following steps: +データをリストアするには、以下の手順を実行してください: -1. Stop Incus on your server (for example, with `sudo systemctl stop incus.service incus.socket`). -1. Delete the directory (`/var/lib/incus/`). -1. Restore the directory from the backup. -1. Delete and restore any external storage devices. -1. Restore the `/etc/subuid` and `/etc/subgid` files if present. -1. Restart Incus (for example, with `sudo systemctl start incus.socket incus.service` or by restarting your machine). +1. サーバー上の Incus を停止します（たとえば、`sudo systemctl stop incus.service incus.socket`で）。 +1. ディレクトリー（`/var/lib/incus/`）を削除します。 +1. バックアップからディレクトリーをリストアします。 +1. 外部のストレージデバイスを削除しリストアします。 +1. `/etc/subuid`と`/etc/subgid`ファイルがある場合はリストアします。 +1. Incus を再起動します（たとえば、`sudo systemctl start incus.socket incus.service`またはマシンを再起動して）。 -## Partial backup +## 部分的なバックアップ -If you decide to only back up specific entities, you have different options for how to do this. -You should consider doing some of these partial backups even if you are doing full backups in addition. -It can be easier and safer to, for example, restore a single instance or reconfigure a profile than to restore the full Incus server. +特定のエンティティをバックアップするだけに決めた場合、実行にはいくつかの異なる選択肢があります。 +フルバックアップをしている場合であっても、追加でこれらの部分的なバックアップを検討するのが良いです。 +たとえば、完全な Incus サーバーをリストアするよりも単一のインスタンスをリストアしたりプロファイルを再設定するほうが簡単で安全です。 -### Back up instances and volumes +### インスタンスとボリュームのバックアップ -Instances and storage volumes are backed up in a very similar way (because when backing up an instance, you basically back up its instance volume, see {ref}`storage-volume-types`). +インスタンスとストレージボリュームは非常に似た方法でバックアップされます（というのはインスタンスをバックアップする際は、基本的にはそのインスタンスボリュームをバックアップするからです。{ref}`storage-volume-types`参照）。 -See {ref}`instances-backup` and {ref}`howto-storage-backup-volume` for detailed information. -The following sections give a brief summary of the options you have for backing up instances and volumes. +詳細な情報は{ref}`instances-backup`と{ref}`howto-storage-backup-volume`を参照してください。 +以下のセクションでインスタンスとボリュームをバックアップする際の選択肢の簡単な要約を示します。 -#### Secondary backup Incus server +#### Incusサーバーのセカンダリバックアップ -Incus supports copying and moving instances and storage volumes between two hosts. -See {ref}`move-instances` and {ref}`howto-storage-move-volume` for instructions. +Incus は 2 つのホスト間でインスタンスとストレージボリュームのコピーと移動を +サポートしています。 +手順は{ref}`move-instances`と{ref}`howto-storage-move-volume`を参照してください。 -So if you have a spare server, you can regularly copy your instances and storage volumes to that secondary server to back them up. -If needed, you can either switch over to the secondary server or copy your instances or storage volumes back from it. +ですので予備のサーバーがあれば、インスタンスとストレージボリュームをバックアップとして定期的にそのセカンダリサーバーにコピーできます。 +必要な場合、セカンダリサーバーに切り替えたり、インスタンスやストレージボリュームをセカンダリサーバーからコピーできます。 -If you use the secondary server as a pure storage server, it doesn't need to be as powerful as your main Incus server. +セカンダリサーバーを純粋にストレージサーバーとして使う場合、メインの Incus サーバーほど強力である必要はありません。 -#### Export tarballs +#### tarballのエクスポート -You can use the `export` command to export instances and volumes to a backup tarball. -By default, those tarballs include all snapshots. +`export`コマンドを使ってインスタンスとボリュームをバックアップの tarball にエクスポートできます。 +デフォルトでは、これらの tarball はすべてのスナップショットを含みます。 -You can use an optimized export option, which is usually quicker and results in a smaller size of the tarball. -However, you must then use the same storage driver when restoring the backup tarball. +最適化された export オプションを使用でき、すると通常はより短時間でエクスポートでき tarball のサイズも小さくなります。 +しかし、バックアップの tarball をリストアする際は同じストレージドライバーを使う必要があります。 -See {ref}`instances-backup-export` and {ref}`storage-backup-export` for instructions. +手順は{ref}`instances-backup-export`と{ref}`storage-backup-export`を参照してください。 -#### Snapshots +#### スナップショット -Snapshots save the state of an instance or volume at a specific point in time. -However, they are stored in the same storage pool and are therefore likely to be lost if the original data is deleted or lost. -This means that while snapshots are very quick and easy to create and restore, they don't constitute a secure backup. +スナップショットはインスタンスやボリュームの特定の日時での状態を保存します。 +しかし、それらは同じストレージプール内に保管されますので、オリジナルのデータが削除されたり失われたりした場合はスナップショットも失われる可能性が高いです。 +つまりスナップショットは非常に高速で手軽に作成とリストアができますが、安全なバックアップを構成するものではありません。 -See {ref}`instances-snapshots` and {ref}`storage-backup-snapshots` for more information. +詳細な情報は{ref}`instances-snapshots`と{ref}`storage-backup-snapshots`を参照してください。 (backup-database)= -### Back up the database +### データベースのバックアップ -While there is no trivial method to restore the contents of the {ref}`Incus database `, it can still be very convenient to keep a backup of its content. -Such a backup can make it much easier to re-create, for example, networks or profiles if the need arises. +{ref}`Incus database `の内容をリストアする自明な方法はありませんが、それでもその内容のバックアップをとっておくと非常に便利です。 +たとえば、ネットワークやプロファイルを再生成する必要がでたときに、バックアップがあれば非常に容易になります。 -Use the following command to dump the content of the local database to a file: +ローカルデータベースの内容をダンプするには以下のコマンドを使用します: incus admin sql local .dump > -Use the following command to dump the content of the global database to a file: +グローバルデータベースの内容をダンプするには以下のコマンドを使用します: incus admin sql global .dump > -You should include these two commands in your regular Incus backup. +定期的な Incus のバックアップにこれら 2 つのコマンドを含めておくと良いでしょう。 diff --git a/doc/client.md b/doc/client.md index f4be154e49a..6ecd052b722 100644 --- a/doc/client.md +++ b/doc/client.md @@ -1,10 +1,10 @@ (incus-client)= -# Incus client +# Incus クライアント ```{toctree} :maxdepth: 1 -Add remote servers -Add command aliases +リモートサーバーの追加 +コマンドエイリアスを追加 /reference/manpages ``` diff --git a/doc/cloud-init.md b/doc/cloud-init.md index 5561ac06268..c30dacaee7e 100644 --- a/doc/cloud-init.md +++ b/doc/cloud-init.md @@ -3,79 +3,78 @@ relatedlinks: https://cloudinit.readthedocs.org/ --- (cloud-init)= -# How to use `cloud-init` +# `cloud-init`を使用するには -[`cloud-init`](https://cloud-init.io/) is a tool for automatically initializing and customizing an instance of a Linux distribution. +[`cloud-init`](https://cloud-init.io/)は Linux ディストリビューションのインスタンスの自動的な初期化とカスタマイズのためのツールです。 -By adding `cloud-init` configuration to your instance, you can instruct `cloud-init` to execute specific actions at the first start of an instance. -Possible actions include, for example: +インスタンスに`cloud-init`設定を追加することで、インスタンスの最初の起動時に`cloud-init`に特定のアクションを実行させることができます。 +可能なアクションには、たとえば以下のようなものがあります: -* Updating and installing packages -* Applying certain configurations -* Adding users -* Enabling services -* Running commands or scripts -* Automatically growing the file system of a VM to the size of the disk +* パッケージの更新とインストール +* 特定の設定の適用 +* ユーザーの追加 +* サービスの有効化 +* コマンドやスクリプトの実行 +* 仮想マシンのファイルシステムをディスクのサイズに自動的に拡張する -See the {ref}`cloud-init:index` for detailed information. +詳細な情報は{ref}`cloud-init:index`を参照してください。 ```{note} -The `cloud-init` actions are run only once on the first start of the instance. -Rebooting the instance does not re-trigger the actions. +`cloud-init`アクションはインスタンスの最初の起動時に一度だけ実行されます。 +インスタンスの再起動ではアクションは再実行されません。 ``` -## `cloud-init` support in images +## イメージ内の`cloud-init`サポート -To use `cloud-init`, you must base your instance on an image that has `cloud-init` installed: +`cloud-init`を使用するには、`cloud-init`がインストールされたイメージをベースにインスタンスを作る必要があります: -* All images from the `ubuntu` and `ubuntu-daily` {ref}`image servers ` have `cloud-init` support. -* Images from the [`images` remote](https://images.linuxcontainers.org/) have `cloud-init`-enabled variants, which are usually bigger in size than the default variant. - The cloud variants use the `/cloud` suffix, for example, `images:ubuntu/22.04/cloud`. +* `ubuntu`および`ubuntu-daily` {ref}`イメージサーバー `からのすべてのイメージは`cloud-init`をサポートしています。 +* [`images`リモート](https://images.linuxcontainers.org/)からのイメージには`cloud-init`が有効化されたバリアントがあり、通常デフォルトバリアントよりもサイズが大きくなります。 + クラウドバリアントは`/cloud`接尾辞を使用します。たとえば、`images:ubuntu/22.04/cloud`。 -## Configuration options +## 設定オプション -Incus supports two different sets of configuration options for configuring `cloud-init`: `cloud-init.*` and `user.*`. -Which of these sets you must use depends on the `cloud-init` support in the image that you use. -As a rule of thumb, newer images support the `cloud-init.*` configuration options, while older images support `user.*`. -However, there might be exceptions to that rule. +Incus は、`cloud-init`の設定に対して`cloud-init.*`と`user.*`の 2 つの異なる設定オプションセットをサポートしています。 +どちらのセットを使用する必要があるかは、使用するイメージの`cloud-init`サポートによって異なります。 +一般的には、新しいイメージは`cloud-init.*`設定オプションをサポートし、古いイメージは`user.*`をサポートしていますが、例外も存在する可能性があります。 -The following configuration options are supported: +以下の設定オプションがサポートされています。 -* `cloud-init.vendor-data` or `user.vendor-data` (see {ref}`cloud-init:vendordata`) -* `cloud-init.user-data` or `user.user-data` (see {ref}`cloud-init:user_data_formats`) -* `cloud-init.network-config` or `user.network-config` (see {ref}`cloud-init:network_config`) +* `cloud-init.vendor-data`または`user.vendor-data` （{ref}`cloud-init:vendordata`を参照） +* `cloud-init.user-data`または`user.user-data` （{ref}`cloud-init:user_data_formats`を参照） +* `cloud-init.network-config`または`user.network-config` （{ref}`cloud-init:network_config`を参照） -For more information about the configuration options, see the [`cloud-init` instance options](instance-options-cloud-init), and the documentation for the {ref}`LXD data source ` in the `cloud-init` documentation. +設定オプションの詳細については、[`cloud-init`インスタンスオプション](instance-options-cloud-init)と、`cloud-init`ドキュメント内の{ref}`LXD データソース `を参照してください。 -### Vendor data and user data +### ベンダーデータとユーザーデータ -Both `vendor-data` and `user-data` are used to provide {ref}`cloud configuration data ` to `cloud-init`. +`vendor-data`と`user-data`の両方が、`cloud-init`に{ref}`クラウド構成データ `を提供するために使用されます。 -The main idea is that `vendor-data` is used for the general default configuration, while `user-data` is used for instance-specific configuration. -This means that you should specify `vendor-data` in a profile and `user-data` in the instance configuration. -Incus does not enforce this method, but allows using both `vendor-data` and `user-data` in profiles and in the instance configuration. +主な考え方は、`vendor-data`は一般的なデフォルト構成に使用され、`user-data`はインスタンス固有の構成に使用されることです。 +これは、プロファイルで`vendor-data`を指定し、インスタンス構成で`user-data`を指定する必要があることを意味します。 +Incus はこの方法を強制しませんが、プロファイルとインスタンス構成の両方で`vendor-data`と`user-data`を使用することができます。 -If both `vendor-data` and `user-data` are supplied for an instance, `cloud-init` merges the two configurations. -However, if you use the same keys in both configurations, merging might not be possible. -In this case, configure how `cloud-init` should merge the provided data. -See {ref}`cloud-init:merging_user_data` for instructions. +インスタンスに対して`vendor-data`と`user-data`の両方が提供される場合、`cloud-init`は 2 つの構成をマージします。 +しかし、両方の設定で同じキーを使った場合、マージは不可能になるかもしれません。 +この場合、指定されたデータをどのようにマージするべきかを`clout-init`に指定してください。 +{ref}`cloud-init:merging_user_data`を参照して手順を確認してください。 -## How to configure `cloud-init` +## `cloud-init`の設定方法 -To configure `cloud-init` for an instance, add the corresponding configuration options to a {ref}`profile ` that the instance uses or directly to the {ref}`instance configuration `. +インスタンスの`cloud-init`を設定するには、対応する設定オプションをインスタンスが使用する{ref}`プロファイル `または{ref}`インスタンス構成 `に直接追加します。 -When configuring `cloud-init` directly for an instance, keep in mind that `cloud-init` runs only on the first start of the instance. -That means that you must configure `cloud-init` before you start the instance. -To do so, create the instance with [`incus init`](incus_create.md) instead of [`incus launch`](incus_launch.md), and then start it after completing the configuration. +インスタンスに直接`cloud-init`を設定する場合、`cloud-init`はインスタンスの最初の起動時にのみ実行されることに注意してください。 +つまり、インスタンスを起動する前に`cloud-init`を設定する必要があります。 +これを行うには、`lxc launch`の代わりに`lxc init`でインスタンスを作成し、設定が完了した後に起動します。 -### YAML format for `cloud-init` configuration +### `cloud-init`設定のYAMLフォーマット -The `cloud-init` options require YAML's [literal style format](https://yaml.org/spec/1.2.2/#812-literal-style). -You use a pipe symbol (`|`) to indicate that all indented text after the pipe should be passed to `cloud-init` as a single string, with new lines and indentation preserved. +`cloud-init`のオプションでは、YAML の[literalスタイルフォーマット](https://yaml.org/spec/1.2.2/#812-literal-style)が必要です。 +パイプ記号（`|`）を使用して、パイプの後にインデントされたテキスト全体を、改行とインデントを保持したまま`cloud-init`に単一の文字列として渡すことを示します。 -The `vendor-data` and `user-data` options usually start with `#cloud-config`. +`vendor-data`および`user-data`のオプションは通常、`#cloud-config`で始まります。 -For example: +例: ```yaml config: @@ -88,21 +87,21 @@ config: ``` ```{tip} -See {doc}`cloud-init:howto/debug_user_data` for information on how to check whether the syntax is correct. +構文が正しいかどうかを確認する方法については、{doc}`cloud-init:howto/debug_user_data`を参照してください。 ``` -## How to check the `cloud-init` status +## `cloud-init`のステータスを確認する方法 -`cloud-init` runs automatically on the first start of an instance. -Depending on the configured actions, it might take a while until it finishes. +`cloud-init`はインスタンスの最初の起動時に自動的に実行されます。 +設定されたアクションによっては、完了するまでに時間がかかる場合があります。 -To check the `cloud-init` status, log on to the instance and enter the following command: +`cloud-init`のステータスを確認するには、インスタンスにログインして以下のコマンドを入力します。 cloud-init status -If the result is `status: running`, `cloud-init` is still working. If the result is `status: done`, it has finished. +結果が`status: running`の場合、`cloud-init`はまだ実行中です。結果が`status: done`の場合、完了しています。 -Alternatively, use the `--wait` flag to be notified only when `cloud-init` is finished: +また、`--wait`フラグを使用して、`cloud-init`が完了したときにのみ通知を受け取ることができます: ```{terminal} :input: cloud-init status --wait @@ -113,27 +112,27 @@ Alternatively, use the `--wait` flag to be notified only when `cloud-init` is fi status: done ``` -## How to specify user or vendor data +## ユーザーデータやベンダーデータを指定する方法 -The `user-data` and `vendor-data` configuration can be used to, for example, upgrade or install packages, add users, or run commands. +`user-data`と`vendor-data`の設定は、たとえば、パッケージのアップグレードやインストール、ユーザーの追加、コマンドの実行などに使用することができます。 -The provided values must have a first line that indicates what type of {ref}`user data format ` is being passed to `cloud-init`. -For activities like upgrading packages or setting up a user, `#cloud-config` is the data format to use. +提供される値は、最初の行で`cloud-init`に渡される{ref}`ユーザーデータ形式 `のタイプを示す必要があります。 +パッケージのアップグレードやユーザーの設定などのアクティビティには、`#cloud-config`が使用するデータ形式です。 -The configuration data is stored in the following files in the instance's root file system: +構成データは、インスタンスのルートファイルシステム内の以下のファイルに保存されます: * `/var/lib/cloud/instance/cloud-config.txt` * `/var/lib/cloud/instance/user-data.txt` -### Examples +### 例 -See the following sections for the user data (or vendor data) configuration for different example use cases. +以下のセクションでは、さまざまな例のユースケースに対するユーザーデータ（またはベンダーデータ）の設定を参照してください。 -You can find more advanced {ref}`examples ` in the `cloud-init` documentation. +より高度な{ref}`例 `は、`cloud-init`ドキュメントで見つけることができます。 -#### Upgrade packages +#### パッケージのアップグレード -To trigger a package upgrade from the repositories for the instance right after the instance is created, use the `package_upgrade` key: +インスタンスが作成された直後に、インスタンスのリポジトリからパッケージをアップグレードするためには、`package_upgrade`キーを使用します: ```yaml config: @@ -142,9 +141,9 @@ config: package_upgrade: true ``` -#### Install packages +#### パッケージのインストール -To install specific packages when the instance is set up, use the `packages` key and specify the package names as a list: +インスタンスのセットアップ時に特定のパッケージをインストールするには、`packages`キーを使用し、パッケージ名をリストとして指定します: ```yaml config: @@ -155,9 +154,9 @@ config: - openssh-server ``` -#### Set the time zone +#### タイムゾーンの設定 -To set the time zone for the instance on instance creation, use the `timezone` key: +インスタンス作成時にインスタンスのタイムゾーンを設定するには、`timezone`キーを使用します: ```yaml config: @@ -166,9 +165,9 @@ config: timezone: Europe/Rome ``` -#### Run commands +#### コマンドの実行 -To run a command (such as writing a marker file), use the `runcmd` key and specify the commands as a list: +コマンド（マーカーファイルの書き込みなど）を実行するには、`runcmd`キーを使用し、コマンドをリストとして指定します: ```yaml config: @@ -178,10 +177,10 @@ config: - [touch, /run/cloud.init.ran] ``` -#### Add a user account +#### ユーザーアカウントの追加 -To add a user account, use the `user` key. -See the {ref}`cloud-init:reference/examples:including users and groups` example in the `cloud-init` documentation for details about default users and which keys are supported. +ユーザーアカウントを追加するには、`user`キーを使用します。 +デフォルトユーザーやサポートされているキーに関する詳細は、`cloud-init`ドキュメント内の{ref}`cloud-init:reference/examples:including users and groups`の例を参照してください。 ```yaml config: @@ -191,22 +190,22 @@ config: - name: documentation_example ``` -## How to specify network configuration data +## ネットワーク構成データを指定する方法 -By default, `cloud-init` configures a DHCP client on an instance's `eth0` interface. -You can define your own network configuration using the `network-config` option to override the default configuration (this is due to how the template is structured). +デフォルトでは、`cloud-init`はインスタンスの`eth0`インターフェースに DHCP クライアントを設定します。 +デフォルトの構成を上書きするために、`network-config`オプションを使用して独自のネットワーク構成を定義することができます（これはテンプレートの構造によるものです）。 -`cloud-init` then renders the relevant network configuration on the system using either `ifupdown` or `netplan`, depending on the Ubuntu release. +その後、`cloud-init`は Ubuntu リリースに応じて`ifupdown`か`netplan`を使用して、システム上の関連するネットワーク構成をレンダリングします。 -The configuration data is stored in the following files in the instance's root file system: +構成データは、インスタンスのルートファイルシステム内の以下のファイルに保存されます: * `/var/lib/cloud/seed/nocloud-net/network-config` -* `/etc/network/interfaces.d/50-cloud-init.cfg` (if using `ifupdown`) -* `/etc/netplan/50-cloud-init.yaml` (if using `netplan`) +* `/etc/network/interfaces.d/50-cloud-init.cfg` （`ifupdown`を使用している場合） +* `/etc/netplan/50-cloud-init.yaml` （`netplan`を使用している場合） -### Example +### 例 -To configure a specific network interface with a static IPv4 address and also use a custom name server, use the following configuration: +特定のネットワークインターフェースに静的な IPv4 アドレスを設定し、カスタム名前サーバーを使用するための次の設定を使用します: ```yaml config: diff --git a/doc/clustering.md b/doc/clustering.md index e74e9199249..3091a0fdf63 100644 --- a/doc/clustering.md +++ b/doc/clustering.md @@ -1,16 +1,16 @@ (clustering)= -# Clustering +# クラスタリング ```{toctree} :titlesonly: explanation/clustering.md -Form a cluster -Manage a cluster -Recover a cluster -Manage instances -Configure storage -Configure networks -Set up cluster groups +クラスタの形成 +クラスタの管理 +クラスタの復旧 +インスタンスの管理 +ストレージの設定 +ネットワークの設定 +クラスタグループのセットアップ reference/cluster_member_config ``` diff --git a/doc/conf.py b/doc/conf.py index f3bada8d5cc..6196d68b049 100644 --- a/doc/conf.py +++ b/doc/conf.py @@ -22,18 +22,14 @@ os.symlink('../../deps/swagger-ui/dist/swagger-ui.css', '.sphinx/_static/swagger-ui/swagger-ui.css') ### MAN PAGES ### -# Find path to incus client (different for local builds and on RTD) -if ("LOCAL_SPHINX_BUILD" in os.environ and - os.environ["LOCAL_SPHINX_BUILD"] == "True"): - path = str(subprocess.check_output(['go', 'env', 'GOPATH'], encoding="utf-8").strip()) - incus = os.path.join(path, 'bin', 'incus') - if os.path.isfile(incus): - print("Using " + incus + " to generate man pages.") - else: - print("Cannot find incus in " + incus) - exit(2) +# Find the path to the incus binary +path = str(subprocess.check_output(['go', 'env', 'GOPATH'], encoding="utf-8").strip()) +incus = os.path.join(path, 'bin', 'incus') +if os.path.isfile(incus): + print("Using " + incus + " to generate man pages.") else: - incus = "../incus.bin" + print("Cannot find incus in " + incus) + exit(2) # Generate man pages content os.makedirs('.sphinx/deps/manpages', exist_ok=True) @@ -212,5 +208,4 @@ # Setup redirects (https://documatt.gitlab.io/sphinx-reredirects/usage.html) redirects = { "howto/instances_snapshots/index": "../instances_backup/", - "reference/network_external/index": "../networks/", } diff --git a/doc/container-environment.md b/doc/container-environment.md index 4b556af66cf..0ec4251113c 100644 --- a/doc/container-environment.md +++ b/doc/container-environment.md @@ -1,25 +1,25 @@ (container-runtime-environment)= -# Container runtime environment +# コンテナ実行環境 -Incus attempts to present a consistent environment to all containers it runs. +Incus は実行するすべてのコンテナに一貫性のある環境を提供しようとします。 -The exact environment will differ slightly based on kernel features and user configuration, but otherwise, it is identical for all containers. +正確な環境はカーネルの機能やユーザーの設定によって若干異なりますが、それ以外はすべてのコンテナに対して同一です。 -## File system +## ファイルシステム -Incus assumes that any image it uses to create a new container comes with at least the following root-level directories: +Incus は使用するどのイメージから生成する新規のコンテナは少なくとも以下のルートレベルのディレクトリーが存在することを前提とします: -- `/dev` (empty) -- `/proc` (empty) -- `/sbin/init` (executable) -- `/sys` (empty) + - `/dev` (空のディレクトリー) + - `/proc` (空のディレクトリー) + - `/sbin/init` (実行ファイル) + - `/sys` (空のディレクトリー) -## Devices +## デバイス -Incus containers have a minimal and ephemeral `/dev` based on a `tmpfs` file system. -Since this is a `tmpfs` and not a `devtmpfs` file system, device nodes appear only if manually created. +Incus のコンテナは`tmpfs`ファイルシステムをベースとする最低限で一時的な`/dev`を持ちます。 +これは`tmpfs`であって`devtmpfs`ファイルシステムではないので、デバイスノードは手動で作成されたときのみ現れます。 -The following standard set of device nodes is set up automatically: +デバイスノードの標準セットでは以下のデバイスが自動的にセットアップされます: - `/dev/console` - `/dev/fd` @@ -35,32 +35,32 @@ The following standard set of device nodes is set up automatically: - `/dev/urandom` - `/dev/zero` -In addition to the standard set of devices, the following devices are also set up for convenience: +標準セットのデバイスに加えて、以下のデバイスも利便性のためにセットアップされます: - `/dev/fuse` - `/dev/net/tun` - `/dev/mqueue` -### Network +### ネットワーク -Incus containers may have any number of network devices attached to them. -The naming for those (unless overridden by the user) is `ethX`, where `X` is an incrementing number. +Incus コンテナはネットワークデバイスをいくつでもアタッチできます。 +これらの名前はユーザーにオーバーライドされない限りは`ethX`で`X`は連番です。 -### Container-to-host communication +## コンテナからホストへのコミュニケーション -Incus sets up a socket at `/dev/incus/sock` that the root user in the container can use to communicate with Incus on the host. +Incus は`/dev/incus/sock`にソケットをセットアップし、コンテナ内の root ユーザーはこれを使ってホストの Incus とコミュニケーションできます。 -See {doc}`dev-incus` for the API documentation. +API ドキュメントは{doc}`dev-incus`を参照してください。 -## Mounts +## マウント -The following mounts are set up by default: +以下のマウントがデフォルトでセットアップされます。 -- `/proc` ({spellexception}`proc`) -- `/sys` (`sysfs`) -- `/sys/fs/cgroup/*` (`cgroupfs`) (only on kernels that lack cgroup namespace support) + - `/proc` (`proc`) + - `/sys` (`sysfs`) + - `/sys/fs/cgroup/*` (`cgroupfs`)（cgroup namespace サポートを欠くカーネルの場合のみ） -If they are present on the host, the following paths will also automatically be mounted: +以下のパスがホスト上に存在する場合は自動的にマウントされます: - `/proc/sys/fs/binfmt_misc` - `/sys/firmware/efi/efivars` @@ -69,28 +69,28 @@ If they are present on the host, the following paths will also automatically be - `/sys/kernel/debug` - `/sys/kernel/security` -The reason for passing all of those paths is that legacy init systems require them to be mounted, or be mountable, inside the container. +これらのパスを引き渡す理由は、これらがマウントされているか、コンテナ内でマウント可能であることが必要とされているレガシーな init システムのためです。 -The majority of those paths will not be writable (or even readable) from inside an unprivileged container. -In privileged containers, they will be blocked by the AppArmor policy. +これらのパスほとんどは非特権コンテナ内からは書き込み可能ではなく（あるいは読み取り可能ですらなく）、特権コンテナ内では AppArmor ポリシーによってブロックされます。 ### LXCFS -If LXCFS is present on the host, it is automatically set up for the container. +ホストに LXCFS がある場合は、コンテナ用に自動的にセットアップされます。 -This normally results in a number of `/proc` files being overridden through bind-mounts. -On older kernels, a virtual version of `/sys/fs/cgroup` might also be set up by LXCFS. +これは通常いくつかの`/proc`ファイルになり、それらは bind mount を通してオーバーライドされます。 +古いカーネルでは`/sys/fs/cgroup`の仮想バージョンも LXCFS によりセットアップされるかもしれません。 ## PID1 -Incus spawns whatever is located at `/sbin/init` as the initial process of the container (PID 1). -This binary should act as a proper init system, including handling re-parented processes. +Incus は何であれ`/sbin/init`に置かれているものをコンテナの初期プロセス（PID 1）として起動します。 +このバイナリは親が変更されたプロセス（訳注: ゾンビプロセスなど）の処理を含めて適切な init システムとして振る舞う必要があります。 -Incus' communication with PID1 in the container is limited to two signals: +Incus がコンテナの PID1 とコミュニケーションするのは以下の 2 つのシグナルだけです。 -- `SIGINT` to trigger a reboot of the container -- `SIGPWR` (or alternatively `SIGRTMIN`+3) to trigger a clean shutdown of the container + - `SIGINT` コンテナのリブートをトリガーする + - `SIGPWR` （あるいは `SIGRTMIN`+3）コンテナのクリーンなシャットダウンをトリガーする -The initial environment of PID1 is blank except for `container=lxc`, which can be used by the init system to detect the runtime. +PID1 の初期環境は`container=lxc`以外は空です。 +init システムは`container=lxc`をランタイムの検出(訳注: lxc で動いていることを知る)に使用できます。 -All file descriptors above the default three are closed prior to PID1 being spawned. +デフォルトの 3 個（訳注: stdin, stdout, stderr）より上のすべてのファイルディスクリプターは PID1 が起動される前に閉じられます。 diff --git a/doc/contributing.md b/doc/contributing.md index 77038a8a648..e9352cd9913 100644 --- a/doc/contributing.md +++ b/doc/contributing.md @@ -1,107 +1,102 @@ -# How to contribute to Incus +# Incusにコントリビュートするには % Include content from [../CONTRIBUTING.md](../CONTRIBUTING.md) ```{include} ../CONTRIBUTING.md + :start-after: :end-before: ``` -## Contribute to the code +## 開発を始める -Follow the steps below to set up your development environment to get started working on new features for Incus. +開発環境をセットアップし、Incus の新機能に取り組みを開始するには以下の手順に従ってください。 -### Install Incus from source +### 依存ライブラリのビルド -To build the dependencies, follow the instructions in {ref}`installing_from_source`. +依存ライブラリをビルドするには{ref}`installing_from_source`の手順に従ってください。 -### Add your fork as a remote +### あなたのforkのremoteを追加 -After setting up your build environment, add your GitHub fork as a remote: +依存ライブラリをビルドし終わったら、GitHub の fork を remote として追加できます。 git remote add myfork git@github.com:/incus.git git remote update -Then switch to it: +次にこちらに切り替えます。 git checkout myfork/main -### Build Incus +### Incusのビルド -Finally, you should be able to run `make` inside the repository and build your fork of the project. +最後にリポジトリ内で`make`を実行すればこのプロジェクトのあなたの fork をビルドできます。 -At this point, you most likely want to create a new branch for your changes on your fork: +この時点で、あなたが最も行いたいであろうことはあなたの fork 上にあなたの変更のための新しいブランチを作ることです。 ```bash git checkout -b [name_of_your_new_branch] git push myfork [name_of_your_new_branch] ``` -### Important notes for new Incus contributors +### Incusの新しいコントリビュータのための重要な注意事項 -- Persistent data is stored in the `Incus_DIR` directory, which is generated by `incus admin init`. - The `Incus_DIR` defaults to `/var/lib/incus`. -- As you develop, you may want to change the `Incus_DIR` for your fork of Incus so as to avoid version conflicts. -- Binaries compiled from your source will be generated in the `$(go env GOPATH)/bin` directory by default. - - You will need to explicitly invoke these binaries (not the global `incusd` you may have installed) when testing your changes. - - You may choose to create an alias in your `~/.bashrc` to call these binaries with the appropriate flags more conveniently. -- If you have a `systemd` service configured to run the Incus daemon from a previous installation of Incus, you may want to disable it to avoid version conflicts. +- 永続データは`INCUS_DIR`ディレクトリーに保管されます。これは`incus admin init`で作成されます。 + `INCUS_DIR`のデフォルトは`/var/lib/incus`です。 +- 開発中はバージョン衝突を避けるため、Incus のあなたの fork 用に`INCUS_DIR`の値を変更すると良いでしょう。 +- あなたのソースからコンパイルされる実行ファイルはデフォルトでは`$(go env GOPATH)/bin`に生成されます。 + - あなたの変更をテストするときはこれらの実行ファイル（インストール済みかもしれないグローバルの`incus admin`ではなく）を明示的に起動する必要があります。 + - これらの実行ファイルを適切なオプションを指定してもっと便利に呼び出せるよう`~/.bashrc`にエイリアスを作るという選択も良いでしょう。 +- 既存のインストール済み Incus のデーモンを実行するための`systemd`サービスが設定されている場合はバージョン衝突を避けるためにサービスを無効にすると良いでしょう。 -## Contribute to the documentation +## ドキュメントへのコントリビュート -We want Incus to be as easy and straight-forward to use as possible. -Therefore, we aim to provide documentation that contains the information that users need to work with Incus, that covers all common use cases, and that answers typical questions. +私たちは Incus をできるだけ簡単に使えるようにしたいと考えています。 +ですので、Incus を使用するユーザーが必要とする（よくある使い方すべてをカバーし、典型的な質問に答えるような）情報を含んだドキュメントを提供を目指しています。 -You can contribute to the documentation in various different ways. -We appreciate your contributions! +いろいろな方法でドキュメントにコントリビュートできます。 +あなたのコントリビュートを感謝します！ -Typical ways to contribute are: +コントリビュートする典型的な方法は以下のとおりです。 -- Add or update documentation for new features or feature improvements that you contribute to the code. - We'll review the documentation update and merge it together with your code. -- Add or update documentation that clarifies any doubts you had when working with the product. - Such contributions can be done through a pull request or through a post in the [Tutorials](https://discuss.linuxcontainers.org/c/tutorials/16) section on the forum. - New tutorials will be considered for inclusion in the docs (through a link or by including the actual content). -- To request a fix to the documentation, open a documentation issue on [GitHub](https://github.com/lxc/incus/issues). - We'll evaluate the issue and update the documentation accordingly. -- Post a question or a suggestion on the [forum](https://discuss.linuxcontainers.org). - We'll monitor the posts and, if needed, update the documentation accordingly. -- Ask questions or provide suggestions in the `#lxc` channel on [IRC](https://web.libera.chat/#lxc). - Given the dynamic nature of IRC, we cannot guarantee answers or reactions to IRC posts, but we monitor the channel and try to improve our documentation based on the received feedback. +- コードにあなたがコントリビュートする新機能や機能改善についてのドキュメントを追加あるいは更新します。私たちはドキュメントの更新をレビューし、あなたのコードとともにマージします。 +- Incus を使っているときに感じた疑問点を明確にするようなドキュメントを追加あるいは更新します。それらの修正は Pull Request またはフォーラムの[Tutorials](https://discuss.linuxcontainers.org/c/tutorials/16)セクションへの投稿で送ってください。新しいチュートリアルはドキュメントへ含める（リンク経由で参照あるいは実際のコンテンツをインクルード）ことを検討します。 +- ドキュメントの修正を依頼するために、[GitHub](https://github.com/canonical/incus/issues)でドキュメントに関するイシューを作成します。 +- 質問や提案を[フォーラム](https://discuss.linuxcontainers.org)に投稿してください。 + 私たちはイシューを評価し、適切にドキュメントを更新します。 +- [IRC](https://web.libera.chat/#lxc)の`#lxc`チャンネルで質問したり提案してください。IRC の動的な性質のため、IRC の投稿に回答や反応することを保証はできませんが、チャンネルを注視して受け取ったフィードバックにもとづいてドキュメントを改善するつもりです。 % Include content from [README.md](README.md) ```{include} README.md :start-after: ``` -When you open a pull request, a preview of the documentation output is built automatically. +Pull Request をオープンすると、ドキュメントのプレビュー出力が自動的にビルドされます。 -### Automatic documentation checks +### ドキュメントの自動チェック -GitHub runs automatic checks on the documentation to verify the spelling, the validity of links, correct formatting of the Markdown files, and the use of inclusive language. +GitHub はドキュメントのスペル、リンク先が正しいか、Markdown ファイルのフォーマットが正しいか、差別用語を使用していないか、を自動的にチェックします。 -You can (and should!) run these tests locally as well with the following commands: +ローカルでも以下のコマンドでこれらのチェックができます（してください！）。 -- Check the spelling: `make doc-spellcheck` -- Check the validity of links: `make doc-linkcheck` -- Check the Markdown formatting: `make doc-lint` -- Check for inclusive language: `make doc-woke` +- スペルをチェックする：`make doc-spellcheck` +- リンクの有効性をチェックする：`make doc-linkcheck` +- Markdown のフォーマットをチェックする：`make doc-lint` +- 差別用語を使っていないかをチェックする：`make doc-woke` -### Document configuration options +### ドキュメントの設定オプション ```{note} -We are currently in the process of moving the documentation of configuration options to code comments. -At the moment, not all configuration options follow this approach. +現在ドキュメントの設定オプションをコード内のコメントに移行中です。 +現時点では、一部の設定オプションはこのアプローチに沿っていません。 ``` -The documentation of configuration options is extracted from comments in the Go code. -Look for comments that start with `gendoc:generate` in the code. +ドキュメントの設定オプションは Go コード内のコメントから抽出されます。 +コード内の`gendoc:generate`で始まるコメントを参照してください。 -When you add or change a configuration option, make sure to include the required documentation comment for it. +設定オプションを追加または変更する際は、それに必要なドキュメントのコメントを含めるようにしてください。 -Then run `make generate-config` to re-generate the `doc/config_options.txt` file. -The updated file should be checked in. +次に`make generate-config`を実行して`doc/config_options.txt`ファイルを再生成してください。更新されたファイルはチェックインしてください。 -The documentation includes sections from the `doc/config_options.txt` to display a group of configuration options. -For example, to include the core server options: +ドキュメントでは、設定オプションのグループを表示するために、`doc/config_options.txt`の一部をインクルードしています。 +たとえば、コアのサーバーオプションをインクルードするには以下のようにします。 ```` % Include content from [config_options.txt](config_options.txt) @@ -111,6 +106,6 @@ For example, to include the core server options: ``` ```` -If you add a configuration option to an existing group, you don't need to do any updates to the documentation files. -The new option will automatically be picked up. -You only need to add an include to a documentation file if you are defining a new group. +既存のグループに設定を追加した場合は、ドキュメントファイルを更新する必要はありません。 +新しいオプションは自動的に取り込まれます。 +新しいグループを追加した場合のみ、ドキュメントファイルにインクルードを追加する必要があります。 diff --git a/doc/daemon-behavior.md b/doc/daemon-behavior.md index 7234e58c6c3..98a4c345544 100644 --- a/doc/daemon-behavior.md +++ b/doc/daemon-behavior.md @@ -1,39 +1,33 @@ (daemon-behavior)= -# Daemon behavior +# デーモンの動作 -This specification covers some of the Incus daemon's behavior. +この仕様書は Incus デーモンの振る舞いの一部を取り扱います。 -## Startup +## 起動 -On every start, Incus checks that its directory structure exists. If it -doesn't, it creates the required directories, generates a key pair and -initializes the database. +起動する度に Incus はディレクトリー構造が存在することをチェックします。 +もし存在しない場合は、必要なディレクトリーを作成し、キーペアを生成し、データベースを初期化します。 -Once the daemon is ready for work, Incus scans the instances table -for any instance for which the stored power state differs from the -current one. If an instance's power state was recorded as running and the -instance isn't running, Incus starts it. +ひとたびデーモンが動作の準備が出来ると、 Incus はデータベース内のインスタンスのテーブルから対象のテーブルを検索し、電源状態が実際の状態と異なっていないかを確認します。 +もしインスタンスの電源状態が稼働中と記録されているのにインスタンスが稼働していない場合は Incus はそのインスタンスを開始します。 -## Signal handling +## シグナル処理 ### `SIGINT`, `SIGQUIT`, `SIGTERM` -For those signals, Incus assumes that it's being temporarily stopped and -will be restarted at a later time to continue handling the instances. +これらのシグナルについては Incus は一時的に停止し、後に再開してインスタンスの処理を継続することを想定しています。 -The instances will keep running and Incus will close all connections and -exit cleanly. +インスタンスは稼働し続けて Incus はすべての接続を閉じ、クリーンな状態で終了するでしょう。 ### `SIGPWR` -Indicates to Incus that the host is going down. +Incus にホストがシャットダウンしようとしていることを伝えます。 -Incus will attempt a clean shutdown of all the instances. After 30 seconds, it -kills any remaining instance. +Incus はすべてのインスタンスをクリーンにシャットダウンしようと試みます。 +30 秒後、Incus は残りのインスタンスを kill します。 -The instance `power_state` in the instances table is kept as it was so -that Incus can restore the instances as they were after the host is done rebooting. +ホストがリブート完了後に Incus がインスタンスを元の状態に戻せるように、データベース内のインスタンスのテーブルの`power_state`カラムにインスタンスの元の電源状態を記録しておきます。 ### `SIGUSR1` -Write a memory profile dump to the file specified with `--memprofile`. +メモリープロファイルを`--memprofile`で指定したファイルにダンプします。 diff --git a/doc/database.md b/doc/database.md index 607f24004e1..7230366cedd 100644 --- a/doc/database.md +++ b/doc/database.md @@ -1,28 +1,29 @@ (database)= -# About the Incus database +# Incus データベースについて -Incus uses a distributed database to store the server configuration and state, which allows for quicker queries than if the configuration was stored inside each instance's directory (as it is done by LXC, for example). +サーバーの設定と状態を保管するために Incus は分散データーベースを使用します。 +これにより（たとえば、LXC でそうされているように）設定が各インスタンスのディレクトリー内に保管される場合より高速に問い合わせができます。 -To understand the advantages, consider a query against the configuration of all instances, like "what instances are using `br0`?". -To answer that question without a database, you would have to iterate through every single instance, load and parse its configuration, and then check which network devices are defined in there. -With a database, you can run a simple query on the database to retrieve this information. +利点を理解するため、すべてへのインスタンスに「どのインスタンスが`br0`を使用しているか？」のような問い合わせをすることを考えてみましょう。 +データベースが無ければ、この問いに答えるためには、設定を読み込んで解釈し、どのネットワークデバイスが設定上に定義されているかの確認を、ひとつひとつのインスタンスに対して行う必要があります。 +データベースがあれば、この情報を得るためにデータベースにシンプルな問い合わせを実行できます。 ## Cowsql -In a Incus cluster, all members of the cluster must share the same database state. -Therefore, Incus uses [Cowsql](https://github.com/cowsql/cowsql), a distributed version of SQLite. -Cowsql provides replication, fault-tolerance, and automatic failover without the need of external database processes. +Incus クラスタ内では、クラスタのすべてのメンバーが同じデータベースの状態を共有する必要があります。 +このため、Incus は SQLIte の分散版である[Cowsql](https://github.com/cowsql/cowsql)を使用しています。 +Cowsql はレプリケーション、冗長性、外部のデータベースプロセスを必要としない自動フェールオーバーの機能を提供します。 -When using Incus as a single machine and not as a cluster, the Cowsql database effectively behaves like a regular SQLite database. +Incus をクラスタではなく単一マシンとして使用する場合は、Cowsql のデータベースは実質的には通常の SQLite データベースのように振る舞います。 -## File location +## ファイルの保管場所 -The database files are stored in the `database` sub-directory of your Incus data directory (`/var/lib/incus/database/`). +データベースは Incus のデータディレクトリー（`/var/lib/incus/database/`）の`database`サブディレクトリーに保管されます。 -Upgrading Incus to a newer version might require updating the database schema. -In this case, Incus automatically stores a backup of the database and then runs the update. -See {ref}`installing-upgrade` for more information. +Incus を新しいバージョンにアップグレードする際はデータベーススキーマの更新が必要かもしれません。 +この場合、Incus は自動的にデータベースのバックアップをしてから更新を実行します。 +詳細は{ref}`installing-upgrade`を参照してください。 -## Backup +## バックアップ -See {ref}`backup-database` for instructions on how to back up the contents of the Incus database. +Incus データベースの内容をどのようにバックアップするかについての手順は{ref}`backup-database`を参照してください。 diff --git a/doc/debugging.md b/doc/debugging.md index 6907ffe5e2f..f7e268d295b 100644 --- a/doc/debugging.md +++ b/doc/debugging.md @@ -1,125 +1,103 @@ -# How to debug Incus +# Incusをデバッグするには -For information on debugging instance issues, see {ref}`instances-troubleshoot`. +インスタンスの問題をデバッグする際の情報については、{ref}`instances-troubleshoot`を参照してください。 -## Debugging `incus` and `incusd` +## `incus` と `incusd` のデバッグ -Here are different ways to help troubleshooting `incus` and `incusd` code. +`incus` と `incusd` のコードをトラブルシューティングするのに役立ついくつかの異なる方法を説明します。 ### `incus --debug` -Adding `--debug` flag to any client command will give extra information -about internals. If there is no useful info, it can be added with the -logging call: +クライアントのどのコマンドにも `--debug` フラグを追加することで内部についての追加情報を出力することができます。 +もし有用な情報がない場合はログ出力の呼び出しで追加することができます: logger.Debugf("Hello: %s", "Debug") ### `incus monitor` -This command will monitor messages as they appear on remote server. +このコマンドはメッセージがリモートのサーバーに現れるのをモニターします。 -## REST API through local socket +## ローカルソケット経由でのREST API -On server side the most easy way is to communicate with Incus through -local socket. This command accesses `GET /1.0` and formats JSON into -human readable form using [jq](https://stedolan.github.io/jq/tutorial/) -utility: +サーバーサイドで Incus とやりとりするのに最も簡単な方法はローカルソケットを経由することです。 +以下のコマンドは`GET /1.0`にアクセスし、[jq](https://stedolan.github.io/jq/tutorial/)ユーティリティを使って +JSON を人間が読みやすいように整形します: ```bash curl --unix-socket /var/lib/incus/unix.socket incus/1.0 | jq . ``` -See the [RESTful API](rest-api.md) for available API. +利用可能な API については[RESTful API](rest-api.md)をご参照ください。 -## REST API through HTTPS +## HTTPS経由でのREST API -{ref}`HTTPS connection to Incus ` requires valid -client certificate that is generated on first [`incus remote add`](incus_remote_add.md). This -certificate should be passed to connection tools for authentication -and encryption. +[Incus への HTTPS 接続](security.md)には、有効なクライアント証明書が必要で、最初の [`incus remote add`](incus_remote_add.md) で生成されます。 +この証明書は、認証と暗号化のための接続ツールに渡す必要があります。 -If desired, `openssl` can be used to examine the certificate (`~/.config/incus/client.crt`): +必要に応じて、`openssl`を使って証明書（`~/.config/incus/client.crt`）を調べることができます: ```bash openssl x509 -text -noout -in client.crt ``` -Among the lines you should see: +表示される行の中に以下のようなものがあるはずです: Certificate purposes: SSL client : Yes -### With command line tools +### コマンドラインツールを使う ```bash wget --no-check-certificate --certificate=$HOME/.config/incus/client.crt --private-key=$HOME/.config/incus/client.key -qO - https://127.0.0.1:8443/1.0 ``` -### With browser +### ブラウザを使う -Some browser plugins provide convenient interface to create, modify -and replay web requests. To authenticate against Incus server, convert -`incus` client certificate into importable format and import it into -browser. +いくつかのブラウザ拡張はウェブのリクエストを作成、修正、リプレイするための便利なインターフェースを提供しています。 +Incus サーバーに対して認証するには`incus`のクライアント証明書をインポート可能な形式に変換しブラウザにインポートしてください。 -For example this produces `client.pfx` in Windows-compatible format: +たとえば Windows で利用可能な形式の`client.pfx`を生成するには以下のようにします: ```bash openssl pkcs12 -clcerts -inkey client.key -in client.crt -export -out client.pfx ``` -After that, opening [`https://127.0.0.1:8443/1.0`](https://127.0.0.1:8443/1.0) should work as expected. +上記のコマンドを実行し、（訳注：変換後の証明書をインポートしてから）ブラウザで[`https://127.0.0.1:8443/1.0`](https://127.0.0.1:8443/1.0)を開けば期待通り動くはずです。 -## Debug the Incus database +## Incusデータベースをデバッグ -The files of the global {ref}`database ` are stored under the `./database/global` -sub-directory of your Incus data directory (`/var/lib/incus/database/global`). +グローバル{ref}`データベース `のファイルは Incus のデータディレクトリー（`/var/lib/incus/database/global`）の`./database/global`サブディレクトリーの下に格納されます。 -Since each member of the cluster also needs to keep some data which is specific -to that member, Incus also uses a plain SQLite database (the "local" database), -which you can find in `./database/local.db`. +クラスタの各メンバーもそのメンバー固有の何らかのデータを保持する必要があるため、Incus は通常の SQLite のデータベース(「ローカル」データベース)も使用します。 +これは`./database/local.db`に置かれます。 -Backups of the global database directory and of the local database file are made -before upgrades, and are tagged with the `.bak` suffix. You can use those if -you need to revert the state as it was before the upgrade. +アップグレードの前にはグローバルデータベースのディレクトリーとローカルデータベースのファイルのバックアップが作成され、 `.bak` のサフィックス付きでタグ付けされます。 +アップグレード前の状態に戻す必要がある場合は、このバックアップを使うことができます。 -### Dumping the database content or schema +### データベースのデータとスキーマをダンプする -If you want to get a SQL text dump of the content or the schema of the databases, -use the `incus admin sql [.dump|.schema]` command, which produces the -equivalent output of the `.dump` or `.schema` directives of the `sqlite3` -command line tool. +データベースのデータまたはスキーマの SQL テキスト形式でのダンプを取得したい場合は、`incus admin sql [.dump|.schema]` コマンドを使ってください。 +これにより`sqlite3`コマンドラインツールの`.dump`または`.schema`ディレクティブと同じ出力を生成できます。 -### Running custom queries from the console +### コンソールからカスタムクエリを実行する -If you need to perform SQL queries (e.g. `SELECT`, `INSERT`, `UPDATE`) -against the local or global database, you can use the `incus admin sql` command (run -`incus admin sql --help` for details). +ローカルまたはグローバルデータベースに SQL クエリ（例 `SELECT`, `INSERT`, `UPDATE`）を実行する必要がある場合、`incus admin sql`コマンドを使うことができます（詳細は`incus admin sql --help`を実行してください）。 -You should only need to do that in order to recover from broken updates or bugs. -Please consult the Incus team first (creating a [GitHub -issue](https://github.com/lxc/incus/issues/new) or -[forum](https://discuss.linuxcontainers.org) post). +ただ、これが必要になるのは壊れたアップデートかバグからリカバーするときだけでしょう。 +その場合、まず Incus チームに相談してみてください（[GitHubのイシュー](https://github.com/lxc/incus/issues/new)を作成するか[フォーラム](https://discuss.linuxcontainers.org/)に投稿）。 -### Running custom queries at Incus daemon startup +### Incusデーモン起動時にカスタムクエリを実行する -In case the Incus daemon fails to start after an upgrade because of SQL data -migration bugs or similar problems, it's possible to recover the situation by -creating `.sql` files containing queries that repair the broken update. +SQL のデータマイグレーションのバグあるいは関連する問題のためにアップグレード後に Incus デーモンが起動に失敗する場合、壊れたアップデートを修復するクエリを含んだ`.sql`ファイルを作成することで、その状況からリカバーできる可能性があります。 -To perform repairs against the local database, write a -`./database/patch.local.sql` file containing the relevant queries, and -similarly a `./database/patch.global.sql` for global database repairs. +ローカルデータベースに対して修復を実行するには、修復に必要なクエリを含む`./database/patch.local.sql`というファイルを作成してください。 +同様にグローバルデータベースの修復には`./database/patch.global.sql`というファイルを作成してください。 -Those files will be loaded very early in the daemon startup sequence and deleted -if the queries were successful (if they fail, no state will change as they are -run in a SQL transaction). +これらのファイルはデーモンの起動シーケンスの非常に早い段階で読み込まれ、クエリが成功したときは削除されます（クエリは SQL トランザクション内で実行されるので、クエリが失敗したときにデータベースの状態が変更されることはありません）。 -As above, please consult the Incus team first. +上記のとおり、まず Incus チームに相談してみてください。 -### Syncing the cluster database to disk +### クラスタデータベースをディスクに同期 -If you want to flush the content of the cluster database to disk, use the `incus -admin sql global .sync` command, that will write a plain SQLite database file into -`./database/global/db.bin`, which you can then inspect with the `sqlite3` -command line tool. +クラスタデータベースの内容をディスクにフラッシュしたいなら、`incus admin sql global .sync`コマンドを使ってください。これは通常の SQLite 形式のデータベースのファイルを`./database/global/db.bin`に書き込みます。 +その後`sqlite3`コマンドラインツールを使って中身を見ることができます。 diff --git a/doc/dev-incus.md b/doc/dev-incus.md index 2fd49c59657..01f4bde1a14 100644 --- a/doc/dev-incus.md +++ b/doc/dev-incus.md @@ -1,50 +1,48 @@ (dev-incus)= -# Communication between instance and host +# インスタンス〜ホスト間の通信 -Communication between the hosted workload (instance) and its host while -not strictly needed is a pretty useful feature. +ホストされているワークロード（インスタンス）とそのホストのコミュニケーションは +厳密には必要とされているわけではないですが、とても便利な機能です。 -In Incus, this feature is implemented through a `/dev/incus/sock` node which is -created and set up for all Incus instances. +Incus ではこの機能は `/dev/incus/sock` というノードを通して実装されており、 +このノードはすべての Incus のインスタンスに対して作成、セットアップされます。 -This file is a Unix socket which processes inside the instance can -connect to. It's multi-threaded so multiple clients can be connected at the -same time. +このファイルはインスタンス内部のプロセスが接続できる Unix ソケットです。 +マルチスレッドで動いているので複数のクライアントが同時に接続できます。 ```{note} -{config:option}`instance-security:security.guestapi` must be set to `true` (which is the default) for an instance to allow access to the socket. +インスタンスのソケットへのアクセスを許可するには {config:option}`instance-security:security.guestapi` を `true`（これがデフォルトです）に設定する必要があります。 ``` -## Implementation details +## 実装詳細 -Incus on the host binds `/var/lib/incus/guestapi/sock` and starts listening for new -connections on it. +ホストでは Incus は `/var/lib/incus/guestapi/sock` をバインドして新しいコネクションの +リッスンを開始します。 -This socket is then exposed into every single instance started by -Incus at `/dev/incus/sock`. +このソケットは、Incus が開始させたすべてのインスタンス内の `/dev/incus/sock` に +公開されます。 -The single socket is required so we can exceed 4096 instances, otherwise, -Incus would have to bind a different socket for every instance, quickly -reaching the FD limit. +4096 を超えるインスタンスを扱うのに単一のソケットが必要です。そうでなければ、 +Incus は各々のインスタンスに異なるソケットをバインドする必要があり、 +ファイルディスクリプター数の上限にすぐ到達してしまいます。 -## Authentication +## 認証 -Queries on `/dev/incus/sock` will only return information related to the -requesting instance. To figure out where a request comes from, Incus will -extract the initial socket's user credentials and compare that to the list of -instances it manages. +`/dev/incus/sock` への問い合わせは依頼するインスタンスに関連した情報のみを +返します。リクエストがどこから来たかを知るために、 Incus は初期のソケットの +ユーザークレデンシャルを取り出し、 Incus が管理しているインスタンスのリストと比較します。 -## Protocol +## プロトコル -The protocol on `/dev/incus/sock` is plain-text HTTP with JSON messaging, so very -similar to the local version of the Incus protocol. +`/dev/incus/sock` のプロトコルは JSON メッセージを用いたプレーンテキストの +HTTP であり、 Incus プロトコルのローカル版に非常に似ています。 -Unlike the main Incus API, there is no background operation and no -authentication support in the `/dev/incus/sock` API. +メインの Incus API とは異なり、 `/dev/incus/sock` API にはバックグラウンド処理と +認証サポートはありません。 ## REST-API -### API structure +### API の構造 * `/` * `/1.0` @@ -55,16 +53,16 @@ authentication support in the `/dev/incus/sock` API. * `/1.0/images/{fingerprint}/export` * `/1.0/meta-data` -### API details +### API の詳細 #### `/` ##### GET -* Description: List of supported APIs -* Return: list of supported API endpoint URLs (by default `['/1.0']`) +* 説明: サポートされている API のリスト +* 出力: サポートされている API エンドポイント URL のリスト（デフォルトでは ['/1.0']`） -Return value: +戻り値: ```json [ @@ -76,10 +74,10 @@ Return value: ##### GET -* Description: Information about the 1.0 API -* Return: JSON object +* 説明: 1.0 API についての情報 +* 出力: dict 形式のオブジェクト -Return value: +戻り値: ```json { @@ -92,10 +90,10 @@ Return value: #### PATCH -* Description: Update instance state (valid states are `Ready` and `Started`) -* Return: none +* 説明: インスタンスの状態を更新する（有効な状態は `Ready` と `Started`） +* 戻り値: 無し - Input: + 入力: ```json { @@ -107,17 +105,17 @@ Return value: ##### GET -* Description: List of configuration keys -* Return: list of configuration keys URL +* 説明: 設定キーの一覧 +* 出力: 設定キー URL のリスト -Note that the configuration key names match those in the instance -configuration, however not all configuration namespaces will be exported to -`/dev/incus/sock`. -Currently only the `cloud-init.*` and `user.*` keys are accessible to the instance. +設定キーの名前はインスタンスの設定の名前と一致するようにしています。 +しかし、設定の namespace のすべてが `/dev/incus/sock` にエクスポート +されているわけではありません。 +現在は `cloud-init.*` と `user.*` キーのみがインスタンスにアクセス可能となっています。 -At this time, there also aren't any instance-writable namespace. +現時点ではインスタンスが書き込み可能な名前空間はありません。 -Return value: +戻り値: ```json [ @@ -129,10 +127,10 @@ Return value: ##### GET -* Description: Value of that key -* Return: Plain-text value +* 説明: そのキーの値 +* 出力: プレーンテキストの値 -Return value: +戻り値: blah @@ -140,10 +138,10 @@ Return value: ##### GET -* Description: Map of instance devices -* Return: JSON object +* 説明: インスタンスのデバイスのマップ +* 出力: dict -Return value: +戻り値: ```json { @@ -164,19 +162,19 @@ Return value: ##### GET -* Description: WebSocket upgrade -* Return: none (never ending flow of events) +* 説明: この API ではプロトコルが WebSocket にアップグレードされます。 +* 出力: 無し（イベントのフローが終わることがなくずっと続く） -Supported arguments are: +サポートされる引数は以下の通りです: -* type: comma-separated list of notifications to subscribe to (defaults to all) +* type: 購読する通知の種別のカンマ区切りリスト（デフォルトは all） -The notification types are: +通知の種別には以下のものがあります: -* `config` (changes to any of the `user.*` configuration keys) -* `device` (any device addition, change or removal) +* `config`（あらゆる `user.*` 設定キーの変更） +* `device`（あらゆるデバイスの追加、変更、削除） -This never returns. Each notification is sent as a separate JSON object: +この API は決して終了しません。それぞれの通知は別々の JSON の dict として送られます: ```json { @@ -209,22 +207,22 @@ This never returns. Each notification is sent as a separate JSON object: ##### GET -* Description: Download a public/cached image from the host -* Return: raw image or error -* Access: Requires `security.guestapi.images` set to `true` +* 説明: 公開されたあるいはキャッシュされたイメージをホストからダウンロードする +* 出力: 生のイメージあるいはエラー +* アクセス権: `security.devlxd.images` を `true` に設定する必要があります -Return value: +戻り値: - See /1.0/images//export in the daemon API. + LXD デーモン API の /1.0/images//export を参照してください。 #### `/1.0/meta-data` ##### GET -* Description: Container meta-data compatible with cloud-init -* Return: cloud-init meta-data +* 説明: cloud-init と互換性のあるコンテナのメタデータ +* 出力: cloud-init のメタデータ -Return value: +戻り値: #cloud-config instance-id: af6a01c7-f847-4688-a2a4-37fddd744625 diff --git a/doc/environment.md b/doc/environment.md index a6c0a36d5f2..db5504a071f 100644 --- a/doc/environment.md +++ b/doc/environment.md @@ -1,40 +1,39 @@ -# Environment variables +# 環境変数 -The Incus client and daemon respect some environment variables to adapt to -the user's environment and to turn some advanced features on and off. +以下の環境変数を設定することで、Incus のクライアントとデーモンをユーザーの環境に適合させることができ、いくつかの高度な機能を有効または無効にすることができます。 -## Common +## クライアントとサーバー共通の環境変数 -Name | Description -:--- | :---- -`INCUS_DIR` | The Incus data directory -`INCUS_INSECURE_TLS` | If set to true, allows all default Go ciphers both for client <-> server communication and server <-> image servers (server <-> server and clustering are not affected) -`PATH` | List of paths to look into when resolving binaries -`http_proxy` | Proxy server URL for HTTP -`https_proxy` | Proxy server URL for HTTPS -`no_proxy` | List of domains, IP addresses or CIDR ranges that don't require the use of a proxy +名前 | 説明 +:--- | :---- +`INCUS_DIR` | Incusのデータディレクトリー +`INCUS_INSECURE_TLS` | trueに設定するとクライアント<->サーバー通信とサーバー<->イメージサーバーの両方（サーバー<->サーバーとクラスタは影響を受けない）ですべてのデフォルトのGoのcipherを許可する +`PATH` | 実行ファイルの検索対象のパスのリスト +`http_proxy` | HTTP用のプロキシサーバーのURL +`https_proxy` | HTTPS用のプロキシサーバーのURL +`no_proxy` | プロキシが不要なドメイン、IPアドレスあるいはCIDRレンジのリスト -## Client environment variable +## クライアントの環境変数 -Name | Description -:--- | :---- -`EDITOR` | What text editor to use -`VISUAL` | What text editor to use (if `EDITOR` isn't set) -`INCUS_CONF` | Path to the client configuration directory -`INCUS_GLOBAL_CONF` | Path to the global client configuration directory -`INCUS_REMOTE` | Name of the remote to use (overrides configured default remote) -`INCUS_PROJECT` | Name of the project to use (overrides configured default project) +名前 | 説明 +:--- | :---- +`EDITOR` | 使用するテキストエディタ +`VISUAL` | （`EDITOR` が設定されてないときに）使用するテキストエディタ +`INCUS_CONF` | LXC設定ディレクトリーのパス +`INCUS_GLOBAL_CONF` | LXCグローバル設定ディレクトリーのパス +`INCUS_REMOTE` | 使用するリモートの名前（設定されたデフォルトのリモートよりも優先されます） +`INCUS_PROJECT` | 使用するプロジェクトの名前（設定されたデフォルトのプロジェクトよりも優先されます） -## Server environment variable +## サーバーの環境変数 -Name | Description +名前 | 説明 :--- | :---- -`INCUS_CLUSTER_UPDATE` | Script to call on a cluster update -`INCUS_DEVMONITOR_DIR` | Path to be monitored by the device monitor. This is primarily for testing -`INCUS_EXEC_PATH` | Full path to the Incus binary (used when forking subcommands) -`INCUS_IDMAPPED_MOUNTS_DISABLE` | Disable idmapped mounts support (useful when testing traditional UID shifting) -`INCUS_LXC_TEMPLATE_CONFIG` | Path to the LXC template configuration directory -`INCUS_OVMF_PATH` | Path to an OVMF build including `OVMF_CODE.fd` and `OVMF_VARS.ms.fd` -`INCUS_SECURITY_APPARMOR` | If set to `false`, forces AppArmor off -`INCUS_SHIFTFS_DISABLE` | Disable `shiftfs` support (useful when testing traditional UID shifting) -`INCUS_UI` | Path to the web UI to serve through the web server +`INCUS_CLUSTER_UPDATE` | クラスタアップデートの際に呼ぶスクリプト +`INCUS_DEVMONITOR_DIR` | デバイスモニターでモニターするパス。主にテスト用。 +`INCUS_EXEC_PATH` | （サブコマンド実行時に使用される）Incus実行ファイルのフルパス +`INCUS_IDMAPPED_MOUNTS_DISABLE` | idmapを使ったマウントを無効にする（従来のUIDシフトを試す際に有用です） +`INCUS_LXC_TEMPLATE_CONFIG` | LXCテンプレート設定ディレクトリー +`INCUS_OVMF_PATH` | `OVMF_CODE.fd`と`OVMF_VARS.ms.fd`を含むOVMFビルドへのパス +`INCUS_SECURITY_APPARMOR` | `false`に設定するとAppArmorを無効にします +`INCUS_SHIFTFS_DISABLE` | `shiftfs`のサポートを無効にする（従来のUIDシフトを試す際に有用です） +`INCUS_UI` | ウェブサーバーを配信する web UI のパス diff --git a/doc/events.md b/doc/events.md index 2f243309068..53a26016614 100644 --- a/doc/events.md +++ b/doc/events.md @@ -1,21 +1,20 @@ -# Events +# イベント -## Introduction +## イントロダクション -Events are messages about actions that have occurred over Incus. Using the API endpoint `/1.0/events` directly or via -[`incus monitor`](incus_monitor.md) will connect to a WebSocket through which logs and life-cycle messages will be streamed. +イベントとは Incus 上で発生したアクションに関するメッセージです。 `/1.0/events` の API エンドポイントを直接使うか [`incus monitor`](incus_monitor.md) コマンドを使うことでウェブソケットに接続しログとライフサイクルメッセージがストリーム出力されます。 -## Event types +## イベント種別 -Incus Currently supports three event types. +Incus は現在 3 つのイベント種別をサポートします。 -- `logging`: Shows all logging messages regardless of the server logging level. -- `operation`: Shows all ongoing operations from creation to completion (including updates to their state and progress metadata). -- `lifecycle`: Shows an audit trail for specific actions occurring over Incus. +- `logging`: サーバーのログレベルに関係なくすべてのログメッセージを表示します。 +- `operation`: 作成から完了までの（状態と進捗メタデータの更新を含む）すべての実行中のオペレーションを表示します。 +- `lifecycle`: Incus 上で発生する特定のアクションの監査証跡を表示します。 -## Event structure +## イベント構造 -### Example +### 例 ```yaml location: cluster_name @@ -29,148 +28,148 @@ timestamp: "2021-03-14T00:00:00Z" type: lifecycle ``` -- `location`: The cluster member name (if clustered). -- `timestamp`: Time that the event occurred in RFC3339 format. -- `type`: The type of event this is (one of `logging`, `operation`, or `lifecycle`). -- `metadata`: Information about the specific event type. - -### Logging event structure - -- `message`: The log message. -- `level`: The log-level of the log. -- `context`: Additional information included in the event. - -### Operation event structure - -- `id`: The UUID of the operation. -- `class`: The type of operation (`task`, `token`, or `websocket`). -- `description`: A description of the operation. -- `created_at`: The operation's creation date. -- `updated_at`: The operation's date of last change. -- `status`: The current state of the operation. -- `status_code`: The operation status code. -- `resources`: Resources affected by this operation. -- `metadata`: Operation specific metadata. -- `may_cancel`: Whether the operation may be canceled. -- `err`: Error message of the operation. -- `location`: The cluster member name (if clustered). - -### Life-cycle event structure - -- `action`: The life-cycle action that occurred. -- `requestor`: Information about who is making the request (if applicable). -- `source`: Path to what is being acted upon. -- `context`: Additional information included in the event. - -## Supported life-cycle events - -| Name | Description | Additional Information | -| :------------------------------------- | :-------------------------------------------------------------------- | :--------------------------------------------------------------------------------------------------- | -| `certificate-created` | A new certificate has been added to the server trust store. | | -| `certificate-deleted` | The certificate has been deleted from the trust store. | | -| `certificate-updated` | The certificate's configuration has been updated. | | -| `cluster-certificate-updated` | The certificate for the whole cluster has changed. | | -| `cluster-disabled` | Clustering has been disabled for this machine. | | -| `cluster-enabled` | Clustering has been enabled for this machine. | | -| `cluster-group-created` | A new cluster group has been created. | | -| `cluster-group-deleted` | A cluster group has been deleted. | | -| `cluster-group-renamed` | A cluster group has been renamed. | | -| `cluster-group-updated` | A cluster group has been updated. | | -| `cluster-member-added` | A new machine has joined the cluster. | | -| `cluster-member-removed` | The cluster member has been removed from the cluster. | | -| `cluster-member-renamed` | The cluster member has been renamed. | `old_name`: the previous name. | -| `cluster-member-updated` | The cluster member's configuration been edited. | | -| `cluster-token-created` | A join token for adding a cluster member has been created. | | -| `config-updated` | The server configuration has changed. | | -| `image-alias-created` | An alias has been created for an existing image. | `target`: the original instance. | -| `image-alias-deleted` | An alias has been deleted for an existing image. | `target`: the original instance. | -| `image-alias-renamed` | The alias for an existing image has been renamed. | `old_name`: the previous name. | -| `image-alias-updated` | The configuration for an image alias has changed. | `target`: the original instance. | -| `image-created` | A new image has been added to the image store. | `type`: `container` or `vm`. | -| `image-deleted` | The image has been deleted from the image store. | | -| `image-refreshed` | The local image copy has updated to the current source image version. | | -| `image-retrieved` | The raw image file has been downloaded from the server. | `target`: destination server. | -| `image-secret-created` | A one-time key to fetch this image has been created. | | -| `image-updated` | The image's configuration has changed. | | -| `instance-backup-created` | A backup of the instance has been created. | | -| `instance-backup-deleted` | The instance backup has been deleted. | | -| `instance-backup-renamed` | The instance backup has been renamed. | `old_name`: the previous name. | -| `instance-backup-retrieved` | The raw instance backup file has been downloaded. | | -| `instance-console` | Connected to the console of the instance. | `type`: `console` or `vga`. | -| `instance-console-reset` | The console buffer has been reset. | | -| `instance-console-retrieved` | The console log has been downloaded. | | -| `instance-created` | A new instance has been created. | | -| `instance-deleted` | The instance has been deleted. | | -| `instance-exec` | A command has been executed on the instance. | `command`: the command to be executed. | -| `instance-file-deleted` | A file on the instance has been deleted. | `file`: path to the file. | -| `instance-file-pushed` | The file has been pushed to the instance. | `file-source`: local file path. `file-destination`: destination file path. `info`: file information. | -| `instance-file-retrieved` | The file has been downloaded from the instance. | `file-source`: instance file path. `file-destination`: destination file path. | -| `instance-log-deleted` | The instance's specified log file has been deleted. | | -| `instance-log-retrieved` | The instance's specified log file has been downloaded. | | -| `instance-metadata-retrieved` | The instance's image metadata has been downloaded. | | -| `instance-metadata-template-created` | A new image template file for the instance has been created. | `path`: relative file path. | -| `instance-metadata-template-deleted` | The image template file for the instance has been deleted. | `path`: relative file path. | -| `instance-metadata-template-retrieved` | The image template file for the instance has been downloaded. | `path`: relative file path. | -| `instance-metadata-updated` | The instance's image metadata has changed. | | -| `instance-paused` | The instance has been put in a paused state. | | -| `instance-ready` | The instance is ready. | | -| `instance-renamed` | The instance has been renamed. | `old_name`: the previous name. | -| `instance-restarted` | The instance has restarted. | | -| `instance-restored` | The instance has been restored from a snapshot. | `snapshot`: name of the snapshot being restored. | -| `instance-resumed` | The instance has resumed after being paused. | | -| `instance-shutdown` | The instance has shut down. | | -| `instance-snapshot-created` | A snapshot of the instance has been created. | | -| `instance-snapshot-deleted` | The instance snapshot has been deleted. | | -| `instance-snapshot-renamed` | The instance snapshot has been renamed. | `old_name`: the previous name. | -| `instance-snapshot-updated` | The instance snapshot's configuration has changed. | | -| `instance-started` | The instance has started. | | -| `instance-stopped` | The instance has stopped. | | -| `instance-updated` | The instance's configuration has changed. | | -| `network-acl-created` | A new network ACL has been created. | | -| `network-acl-deleted` | The network ACL has been deleted. | | -| `network-acl-renamed` | The network ACL has been renamed. | `old_name`: the previous name. | -| `network-acl-updated` | The network ACL configuration has changed. | | -| `network-created` | A network device has been created. | | -| `network-deleted` | The network device has been deleted. | | -| `network-forward-created` | A new network forward has been created. | | -| `network-forward-deleted` | The network forward has been deleted. | | -| `network-forward-updated` | The network forward has been updated. | | -| `network-peer-created` | A new network peer has been created. | | -| `network-peer-deleted` | The network peer has been deleted. | | -| `network-peer-updated` | The network peer has been updated. | | -| `network-renamed` | The network device has been renamed. | `old_name`: the previous name. | -| `network-updated` | The network device's configuration has changed. | | -| `network-zone-created` | A new network zone has been created. | | -| `network-zone-deleted` | The network zone has been deleted. | | -| `network-zone-record-created` | A new network zone record has been created. | | -| `network-zone-record-deleted` | The network zone record has been deleted. | | -| `network-zone-record-updated` | The network zone record has been updated. | | -| `network-zone-updated` | The network zone has been updated. | | -| `operation-cancelled` | The operation has been canceled. | | -| `profile-created` | A new profile has been created. | | -| `profile-deleted` | The profile has been deleted. | | -| `profile-renamed` | The profile has been renamed . | `old_name`: the previous name. | -| `profile-updated` | The profile's configuration has changed. | | -| `project-created` | A new project has been created. | | -| `project-deleted` | The project has been deleted. | | -| `project-renamed` | The project has been renamed. | `old_name`: the previous name. | -| `project-updated` | The project's configuration has changed. | | -| `storage-pool-created` | A new storage pool has been created. | `target`: cluster member name. | -| `storage-pool-deleted` | The storage pool has been deleted. | | -| `storage-pool-updated` | The storage pool's configuration has changed. | `target`: cluster member name. | -| `storage-volume-backup-created` | A new backup for the storage volume has been created. | `type`: `container`, `virtual-machine`, `image`, or `custom`. | -| `storage-volume-backup-deleted` | The storage volume's backup has been deleted. | | -| `storage-volume-backup-renamed` | The storage volume's backup has been renamed. | `old_name`: the previous name. | -| `storage-volume-backup-retrieved` | The storage volume's backup has been downloaded. | | -| `storage-volume-created` | A new storage volume has been created. | `type`: `container`, `virtual-machine`, `image`, or `custom`. | -| `storage-volume-deleted` | The storage volume has been deleted. | | -| `storage-volume-renamed` | The storage volume has been renamed. | `old_name`: the previous name. | -| `storage-volume-restored` | The storage volume has been restored from a snapshot. | `snapshot`: name of the snapshot being restored. | -| `storage-volume-snapshot-created` | A new storage volume snapshot has been created. | `type`: `container`, `virtual-machine`, `image`, or `custom`. | -| `storage-volume-snapshot-deleted` | The storage volume's snapshot has been deleted. | | -| `storage-volume-snapshot-renamed` | The storage volume's snapshot has been renamed. | `old_name`: the previous name. | -| `storage-volume-snapshot-updated` | The configuration for the storage volume's snapshot has changed. | | -| `storage-volume-updated` | The storage volume's configuration has changed. | | -| `warning-acknowledged` | The warning's status has been set to "acknowledged". | | -| `warning-deleted` | The warning has been deleted. | | -| `warning-reset` | The warning's status has been set to "new". | | +- `location`: クラスタメンバー名（クラスタの場合）。 +- `timestamp`: RFC3339 形式のイベント発生時刻。 +- `type`: イベント種別（`logging`、`operation`、`lifecycle` のいずれか）。 +- `metadata`: 特定のイベント種別に関する情報。 + +### logging イベントの構造 + +- `message`: ログメッセージ。 +- `level`: ログのログレベル。 +- `context`: イベントに含まれる追加情報。 + +### operation イベントの構造 + +- `id`: オペレーションの UUID +- `class`: オペレーション種別（`task`、`token`、`websocket` のいずれか）。 +- `description`: オペレーションの説明。 +- `created_at`: オペレーションの作成日時。 +- `updated_at`: オペレーションの更新日時。 +- `status`: オペレーションの現在の状態。 +- `status_code`: オペレーションのステータスコード。 +- `resources`: このオペレーションで影響を受けるリソース。 +- `metadata`: オペレーション特有のメタデータ。 +- `may_cancel`: オペレーションがキャンセル可能か。 +- `err`: オペレーションのエラーメッセージ。 +- `location`: クラスタメンバー名（クラスタの場合）。 + +### ライフサイクルイベントの構造 + +- `action`: 発生したライフサイクルアクション。 +- `requestor`: 誰がリクエストを作成したかの情報（該当するものがあれば）。 +- `source`: アクションの対象のパス。 +- `context`: イベントに含まれる追加情報。 + +## サポートされるライフサイクルイベント + +| 名前 | 説明 | 追加情報 +| :------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------ | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `certificate-created` | サーバーのトラスト・ストアに新しい証明書が追加された。 | | +| `certificate-deleted` | トラスト・ストアから証明書が削除された。 | | +| `certificate-updated` | 証明書の設定が更新された。 | | +| `cluster-certificate-updated` | クラスタ全体の証明書が変更された。 | | +| `cluster-disabled` | このマシンに対してクラスタリングが無効化された。 | | +| `cluster-enabled` | このマシンに対してクラスタリングが有効化された。 | | +| `cluster-group-created` | 新しいクラスタグループが作成された。 | | +| `cluster-group-deleted` | クラスタグループが削除された。 | | +| `cluster-group-renamed` | クラスタグループがリネームされた。 | | +| `cluster-group-updated` | クラスタグループが更新された。 | | +| `cluster-member-added` | 新しいマシンがクラスタに参加した。 | | +| `cluster-member-removed` | クラスタからクラスタメンバーが削除された。 | | +| `cluster-member-renamed` | クラスタメンバーがリネームされた。 | `old_name`: 以前の名前。 | +| `cluster-member-updated` | クラスタメンバーの設定が変更された。 | | +| `cluster-token-created` | クラスタメンバー追加のための参加トークンが作成された。 | | +| `config-updated` | サーバーの設定が変更された。 | | +| `image-alias-created` | 既存イメージのエイリアスが作成された。 | `target`: オリジナルのインスタンス。 | +| `image-alias-deleted` | 既存イメージのエイリアスが削除された。 | `target`: オリジナルのインスタンス。 | +| `image-alias-renamed` | 既存イメージのエイリアスがリネームされた。 | `old_name`: 以前の名前。 | +| `image-alias-updated` | イメージ・エイリアスの設定が変更された。 | `target`: オリジナルのインスタンス。 | +| `image-created` | イメージ・ストアに新しいイメージが追加された。 | `type`: `container` か `vm`。 | +| `image-deleted` | イメージ・ストアからイメージが削除された。 | | +| `image-refreshed` | ローカルのイメージコピーが現在のソースイメージのバージョンに更新された。 | | +| `image-retrieved` | raw イメージファイルがサーバーからダウンロードされた。 | `target`: ダウンロード先のサーバー。 | +| `image-secret-created` | イメージ取得用のワンタイム・キーが作成された。 | | +| `image-updated` | イメージの設定が変更された。 | | +| `instance-backup-created` | インスタンスのバックアップが作成された。 | | +| `instance-backup-deleted` | インスタンスのバックアップが削除された。 | | +| `instance-backup-renamed` | インスタンスのバックアップがリネームされた。 | `old_name`: 以前の名前。 | +| `instance-backup-retrieved` | raw インスタンス・バックアップ・ファイルがダウンロードされた。 | | +| `instance-console` | インスタンスのコンソールに接続された。 | `type`: `console` か `vga`。 | +| `instance-console-reset` | コンソール・バッファーがリセットされた。 | | +| `instance-console-retrieved` | コンソール・ログがダウンロードされた。 | | +| `instance-created` | 新しいインスタンスが作成された。 | | +| `instance-deleted` | インスタンスが削除された。 | | +| `instance-exec` | インスタンス上でコマンドが実行された。 | `command`: 実行されたコマンド。 | +| `instance-file-deleted` | インスタンス上のファイルが削除された。 | `file`: ファイルのパス。 | +| `instance-file-pushed` | インスタンスにファイルがアップロードされた。 | `file-source`: ローカルのファイルパス。 `file-destination`: コピー先のファイルパス。 `info`: ファイルの情報。 | +| `instance-file-retrieved` | インスタンスからファイルがダウンロードされた。 | `file-source`: インスタンスのファイルパス。 `file-destination`: コピー先のファイルパス。 | +| `instance-log-deleted` | インスタンスの指定のログファイルが削除された。 | | +| `instance-log-retrieved` | インスタンスの指定のログファイルがダウンロードされた。 | | +| `instance-metadata-retrieved` | インスタンスのイメージメタデータがダウンロードされた。 | | +| `instance-metadata-template-created` | インスタンスの新しいイメージテンプレートファイルが作成された。 | `path`: ファイルの相対パス。 | +| `instance-metadata-template-deleted` | インスタンスのイメージテンプレートファイルが削除された。 | `path`: ファイルの相対パス。 | +| `instance-metadata-template-retrieved` | インスタンスのイメージテンプレートファイルがダウンロードされた。 | `path`: ファイルの相対パス。 | +| `instance-metadata-updated` | インスタンスのイメージメタデータが変更された。 | | +| `instance-paused` | インスタンスが休止状態にされた。 | | +| `instance-ready` | インスタンスが準備完了になった。 | | +| `instance-renamed` | インスタンスがリネームされた。 | `old_name`: 以前の名前。 | +| `instance-restarted` | インスタンスが再起動された。 | | +| `instance-restored` | インスタンスがスナップショットから復元された。 | `snapshot`: 復元されたスナップショット名。 | +| `instance-resumed` | インスタンスが休止状態から復帰された。 | | +| `instance-shutdown` | インスタンスがシャットダウンされた。 | | +| `instance-snapshot-created` | インスタンスのスナップショットが作成された。 | | +| `instance-snapshot-deleted` | インスタンスのスナップショットが削除された。 | | +| `instance-snapshot-renamed` | インスタンスのスナップショットがリネームされた。 | `old_name`: 以前の名前。 | +| `instance-snapshot-updated` | インスタンス・スナップショットの設定が変更された。 | | +| `instance-started` | インスタンスが起動された。 | | +| `instance-stopped` | インスタンスが停止された。 | | +| `instance-updated` | インスタンスの設定が変更された。 | | +| `network-acl-created` | 新しいネットワーク ACL が作成された。 | | +| `network-acl-deleted` | ネットワーク ACL が削除された。 | | +| `network-acl-renamed` | ネットワーク ACL がリネームされた。 | `old_name`: 以前の名前。 | +| `network-acl-updated` | ネットワーク ACL の設定が変更された。 | | +| `network-created` | ネットワークデバイスが作成された。 | | +| `network-deleted` | ネットワークデバイスが削除された。 | | +| `network-forward-created` | ネットワークフォワードが作成された。 | | +| `network-forward-deleted` | ネットワークフォワードが削除された。 | | +| `network-forward-updated` | ネットワークフォワードが更新された。 | | +| `network-peer-created` | ネットワークピアが作成された。 | | +| `network-peer-deleted` | ネットワークピアが削除された。 | | +| `network-peer-updated` | ネットワークピアがリネームされた。 | | +| `network-renamed` | ネットワークデバイスがリネームされた。 | `old_name`: 以前の名前。 | +| `network-updated` | ネットワークデバイスの設定が変更された。 | | +| `network-zone-created` | ネットワークゾーンが作成された。 | | +| `network-zone-deleted` | ネットワークゾーンが削除された。 | | +| `network-zone-record-created` | ネットワークゾーンレコードが作成された。 | | +| `network-zone-record-deleted` | ネットワークゾーンレコードが削除された。 | | +| `network-zone-record-updated` | ネットワークゾーンレコードが更新された。 | | +| `network-zone-updated` | ネットワークゾーンが更新された。 | | +| `operation-cancelled` | オペレーションがキャンセルされた。 | | +| `profile-created` | 新しいプロファイルが作成された。 | | +| `profile-deleted` | プロファイルが削除された。 | | +| `profile-renamed` | プロファイルがリネームされた。 | `old_name`: 以前の名前。 | +| `profile-updated` | プロファイルの設定が変更された。 | | +| `project-created` | 新しいプロジェクトが作成された。 | | +| `project-deleted` | プロジェクトが削除された。 | | +| `project-renamed` | プロジェクトがリネームされた。 | `old_name`: 以前の名前。 | +| `project-updated` | プロジェクトの設定が変更された。 | | +| `storage-pool-created` | 新しいストレージプールが作成された。 | `target`: クラスタメンバー名。 | +| `storage-pool-deleted` | ストレージプールが削除された。 | | +| `storage-pool-updated` | ストレージプールの設定が変更された。 | `target`: クラスタメンバー名。 | +| `storage-volume-backup-created` | ストレージボリュームの新しいバックアップが作成された。 | `type`: `container`、`virtual-machine`、`image`、`custom` のいずれか。 | +| `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-deleted` | ストレージボリュームが削除された。 | | +| `storage-volume-renamed` | ストレージボリュームがリネームされた。 | `old_name`: 以前の名前。 | +| `storage-volume-restored` | ストレージボリュームがスナップショットから復元された。 | `snapshot`: 復元されたスナップショット名。 | +| `storage-volume-snapshot-created` | 新しいストレージボリュームスナップショットが作成された。 | `type`: `container`、`virtual-machine`、`image`、`custom` のいずれか。 | +| `storage-volume-snapshot-deleted` | ストレージボリュームのスナップショットが削除された。 | | +| `storage-volume-snapshot-renamed` | ストレージボリュームのスナップショットがリネームされた。 | `old_name`: 以前の名前。 | +| `storage-volume-snapshot-updated` | ストレージボリュームのスナップショットの設定が変更された。 | | +| `storage-volume-updated` | ストレージボリュームの設定が変更された。 | | +| `warning-acknowledged` | 警告の状態が "acknowledged" （確認済み）に設定された。 | | +| `warning-deleted` | 警告が削除された。 | | +| `warning-reset` | 警告の状態が "new" （新規）に設定された。 | | diff --git a/doc/explanation/clustering.md b/doc/explanation/clustering.md index 0974b98d9dd..3d2a4bf58f5 100644 --- a/doc/explanation/clustering.md +++ b/doc/explanation/clustering.md @@ -1,213 +1,212 @@ (exp-clustering)= -# About clustering +# クラスタリングについて -To spread the total workload over several servers, Incus can be run in clustering mode. -In this scenario, any number of Incus servers share the same distributed database that holds the configuration for the cluster members and their instances. -The Incus cluster can be managed uniformly using the [`incus`](incus.md) client or the REST API. - -This feature was introduced as part of the [`clustering`](../api-extensions.md#clustering) API extension and is available since Incus 3.0. +全体のワークロードを複数のサーバーに分散するため、 Incus はクラスタリングモードで動かせます。 +このシナリオでは、クラスタメンバーとそのインスタンスの設定を保持する同じ分散データベースを任意の台数の Incus サーバーで共有します。 +Incus クラスタは [`incus`](incus.md) クライアントまたは REST API を使って管理できます。 ```{tip} -If you want to quickly set up a basic Incus cluster, check out [MicroCloud](https://microcloud.is). +ベーシックな Incus クラスタを素早くセットアップしたい場合、[MicroCloud](https://microcloud.is)をチェックしてみてください。 ``` (clustering-members)= -## Cluster members +## クラスタメンバー -A Incus cluster consists of one bootstrap server and at least two further cluster members. -It stores its state in a [distributed database](../database.md), which is a [Cowsql](https://github.com/cowsql/cowsql/) database replicated using the Raft algorithm. +Incus クラスタは 1 台のブートストラップサーバーと少なくともさらに 2 台のクラスタメンバーから構成されます。 +クラスタは状態を [分散データベース](../database.md) に保管します。これは Raft アルゴリズムを使用して複製される[Cowsql](https://github.com/cowsql/cowsql/) データベースです。 -While you could create a cluster with only two members, it is strongly recommended that the number of cluster members be at least three. -With this setup, the cluster can survive the loss of at least one member and still be able to establish quorum for its distributed state. +2 台のメンバーだけでもクラスタを作成することは出来なくはないですが、少なくとも 3 台のクラスタメンバーを強く推奨します。 +このセットアップでは、クラスタは少なくとも 1 台のメンバーの消失に耐えることができ、分散状態の過半数を確立できます。 -When you create the cluster, the Cowsql database runs on only the bootstrap server until a third member joins the cluster. -Then both the second and the third server receive a replica of the database. +クラスタを作成する際、 Cowsql データベースは 3 番目のメンバーがクラスタにジョインするまではブートストラップサーバー上でのみ稼働します。 +そして 2 番目と 3 番目のサーバーはデータベースの複製を受信します。 -See {ref}`cluster-form` for more information. +詳細は {ref}`cluster-form` を参照してください。 (clustering-member-roles)= -### Member roles +### メンバーロール -In a cluster with three members, all members replicate the distributed database that stores the state of the cluster. -If the cluster has more members, only some of them replicate the database. -The remaining members have access to the database, but don't replicate it. +3 台のメンバーのクラスタでは、すべてのメンバーがクラスタの状態を保管する分散データベースを複製します。 +クラスタのメンバーがさらに増えると、一部のメンバーだけがデータベースを複製します。 +残りのメンバーはデータベースへアクセスしますが、複製はしません。 -At each time, there is an elected cluster leader that monitors the health of the other members. +任意の時点で、選出されたリーダーが 1 つ存在し、他のメンバーの健康状態をモニターします。 -Each member that replicates the database has either the role of a *voter* or of a *stand-by*. -If the cluster leader goes offline, one of the voters is elected as the new leader. -If a voter member goes offline, a stand-by member is automatically promoted to voter. -The database (and hence the cluster) remains available as long as a majority of voters is online. +データベースを複製する各メンバーは *voter* か *stand-by* のロールを持ちます。 +クラスタリーダーがオフラインになると voter の 1 つが新しいリーダーに選出されます。 +voter のメンバーがオフラインになると stand-by メンバーが自動的に voter に昇格します。 +データベース (そしてクラスタ) は voter の過半数がオンラインである限り利用可能です。 -The following roles can be assigned to Incus cluster members. -Automatic roles are assigned by Incus itself and cannot be modified by the user. +以下のロールが Incus クラスタメンバーに割り当て可能です。 +自動のロールは Incus 自身によって割り当てられユーザーによる変更は出来ません。 -| Role | Automatic | Description | +| ロール | 自動 | 説明 | | :--- | :-------- | :---------- | -| `database` | yes | Voting member of the distributed database | -| `database-leader` | yes | Current leader of the distributed database | -| `database-standby` | yes | Stand-by (non-voting) member of the distributed database | -| `event-hub` | no | Exchange point (hub) for the internal Incus events (requires at least two) | -| `ovn-chassis` | no | Uplink gateway candidate for OVN networks | +| `database` | yes | 分散データベースの voter メンバー | +| `database-leader` | yes | 分散データベースの現在のリーダー | +| `database-standby` | yes | 分散データベースの stand-by（voter ではない）メンバー | +| `event-hub` | no | 内部 Incus イベントへの交換ポイント（hub）（最低 2 つは必要）| +| `ovn-chassis` | no | OVN ネットワークのアップリンクゲートウェイの候補 | + -The default number of voter members ({config:option}`server-cluster:cluster.max_voters`) is three. -The default number of stand-by members ({config:option}`server-cluster:cluster.max_standby`) is two. -With this configuration, your cluster will remain operational as long as you switch off at most one voting member at a time. +voter メンバーのデフォルトの数（{config:option}`server-cluster:cluster.max_voters`）は 3 です。 +stand-by メンバーのデフォルトの数（{config:option}`server-cluster:cluster.max_standby`）は 2 です。 +この設定では、クラスタを稼働したまま一度に最大で 1 つの voter メンバーの電源を切ることができます。 -See {ref}`cluster-manage` for more information. +詳細は {ref}`cluster-manage` を参照してください。 (clustering-offline-members)= -#### Offline members and fault tolerance +#### オフラインメンバーと障害耐性 -If a cluster member is down for more than the configured offline threshold, its status is marked as offline. -In this case, no operations are possible on this member, and neither are operations that require a state change across all members. +クラスタメンバーがダウンして設定されたオフラインの閾値を超えると、ステータスはオフラインと記録されます。 +この場合、このメンバーに対する操作はできなくなり、すべてのメンバーの状態変更を必要とする操作もできなくなります。 -As soon as the offline member comes back online, operations are available again. +オフラインのメンバーがオンラインに戻るとすぐに操作が再びできるようになります。 -If the member that goes offline is the leader itself, the other members will elect a new leader. +オフラインになったメンバーがリーダーそのものだった場合、他のメンバーは新しいリーダーを選出します。 -If you can't or don't want to bring the server back online, you can [delete it from the cluster](cluster-manage-delete-members). +サーバーを再びオンラインに復旧できないあるいはしたくない場合、[クラスタからメンバーを削除](cluster-manage-delete-members) できます。 -You can tweak the amount of seconds after which a non-responding member is considered offline by setting the {config:option}`server-cluster:cluster.offline_threshold` configuration. -The default value is 20 seconds. -The minimum value is 10 seconds. +応答しないメンバーをオフラインと判断する秒数は[`cluster.offline_threshold`](server-options-cluster)設定で調整できます。 +デフォルト値は 20 秒です。 +最小値は 10 秒です。 -To automatically {ref}`evacuate ` instances from an offline member, set the {config:option}`server-cluster:cluster.healing_threshold` configuration to a non-zero value. +オフラインのメンバーからインスタンスを自動的に{ref}`退避 `するには、{config:option}`server-cluster:cluster.offline_threshold`設定をゼロでない値に設定してください。 -See {ref}`cluster-recover` for more information. +詳細は{ref}`cluster-recover`を参照してください。 #### Failure domains -You can use failure domains to indicate which cluster members should be given preference when assigning roles to a cluster member that has gone offline. -For example, if a cluster member that currently has the database role gets shut down, Incus tries to assign its database role to another cluster member in the same failure domain, if one is available. +オフラインになったメンバーにロールを割り当てる際に、どのクラスタメンバーを優先するかを指示するために failure domain を使用できます。 +たとえば、現在データベースロールを持つクラスタメンバーがシャットダウンした場合、 Incus はデータベースロールを同じ failure domain 内の別のクラスタメンバーがあればそれに割り当てようとします。 -To update the failure domain of a cluster member, use the [`incus cluster edit `](incus_cluster_edit.md) command and change the `failure_domain` property from `default` to another string. +クラスタメンバーの failure domain を更新するには、[`incus cluster edit `](incus_cluster_edit.md) コマンドを使って `failure_domain` プロパティを `default` から他の文字列に変更します。 (clustering-member-config)= -### Member configuration +### メンバー設定 -Incus cluster members are generally assumed to be identical systems. -This means that all Incus servers joining a cluster must have an identical configuration to the bootstrap server, in terms of storage pools and networks. +Incus クラスタメンバーは一般的に同一のシステムと想定されています。 +それはクラスタにジョインするすべての Incus サーバーはブートストラップサーバーとストレージプールとネットワークについて同一の設定を持つ必要があるということです。 -To accommodate things like slightly different disk ordering or network interface naming, there is an exception for some configuration options related to storage and networks, which are member-specific. +少し異なるディスクの順序やネットワークインターフェースの名前付けのようなことに対応するため、ストレージとネットワークに関連してメンバー固有のいくつかの設定が例外的に用意されています。 -When such settings are present in a cluster, any server that is being added must provide a value for them. -Most often, this is done through the interactive `incus admin init` command, which asks the user for the value for a number of configuration keys related to storage or networks. +クラスタ内にそのような設定が存在する場合、追加するサーバーにはそれらの設定に対する値を提供する必要があります。 +たいていの場合、これはインタラクティブな `incus admin init` コマンドで実行され、ユーザーにストレージやネットワークに関連する設定の値の入力を求めます。 -Those settings typically include: +通常これらの設定には以下のものが含まれます: -- The source device and size for a storage pool -- The name for a ZFS zpool, LVM thin pool or LVM volume group -- External interfaces and BGP next-hop for a bridged network -- The name of the parent network device for managed `physical` or `macvlan` networks +- ストレージプールのソースデバイスとサイズ +- ZFS プール、 LVM thin pool、または LVM ボリュームグループの名前 +- ブリッジネットワークの外部インターフェースと BGP の next-hop +- 管理された `physical` または `macvlan` ネットワークの親のネットワークデバイス名 -See {ref}`cluster-config-storage` and {ref}`cluster-config-networks` for more information. +詳細は {ref}`cluster-config-storage` と {ref}`cluster-config-networks` を参照してください。 -If you want to look up the questions ahead of time (which can be useful for scripting), query the `/1.0/cluster` API endpoint. -This can be done through `incus query /1.0/cluster` or through other API clients. +事前に質問を調べたい（スクリプトでの自動化に有用）場合、 `/1.0/cluster` API エンドポイントをクエリしてください。 +これは `incus query /1.0/cluster` あるいは他の API クライアントを使って実行できます。 -## Images +## イメージ -By default, Incus replicates images on as many cluster members as there are database members. -This typically means up to three copies within the cluster. +デフォルトでは、 Incus はデータベースメンバーと同じ数のクラスタメンバーにイメージを複製します。 +通常これはクラスタ内で最大 3 つのコピーを持つことを意味します。 -You can increase that number to improve fault tolerance and the likelihood of the image being locally available. -To do so, set the {config:option}`server-cluster:cluster.images_minimal_replica` configuration. -The special value of `-1` can be used to have the image copied to all cluster members. +障害耐性とイメージがローカルで利用できる確率を改善するためこの数を増やすことができます。 +そのためには、{config:option}`server-cluster:cluster.images_minimal_replica` 設定を変更してください。 +すべてのクラスタメンバーにイメージをコピーするには`-1`という特別な値を使用できます。 (cluster-groups)= -## Cluster groups +## クラスタグループ -In a Incus cluster, you can add members to cluster groups. -You can use these cluster groups to launch instances on a cluster member that belongs to a subset of all available members. -For example, you could create a cluster group for all members that have a GPU and then launch all instances that require a GPU on this cluster group. +Incus のクラスタではクラスタグループにメンバーを追加できます。 +これらのクラスタグループは、すべての利用可能なメンバーのサブセットに属するクラスタメンバー上で、インスタンスを起動するのに使用できます。 +たとえば、GPU を持つすべてのメンバーからなるクラスタメンバーを作って、GPU が必要なすべてのインスタンスをこのクラスタグループ上で起動できます。 -By default, all cluster members belong to the `default` group. +デフォルトでは、すべてのクラスタメンバーは `default` グループに属します。 -See {ref}`howto-cluster-groups` and {ref}`cluster-target-instance` for more information. +詳細は {ref}`howto-cluster-groups` と {ref}`cluster-target-instance` を参照してください。 (clustering-instance-placement)= -## Automatic placement of instances +## インスタンスの自動配置 -In a cluster setup, each instance lives on one of the cluster members. -When you launch an instance, you can target it to a specific cluster member, to a cluster group or have Incus automatically assign it to a cluster member. +クラスタのセットアップでは各インスタンスはクラスタメンバーの 1 つの上で稼働します。 +インスタンスを起動する際、特定のクラスタメンバー、クラスタグループをターゲットにするか、あるいは Incus に自動的にどれかのクラスタメンバーに割り当てさせることもできます。 -By default, the automatic assignment picks the cluster member that has the lowest number of instances. -If several members have the same amount of instances, one of the members is chosen at random. +デフォルトでは、自動的な割り当てはインスタンス数が一番少ないクラスタメンバーを選択します。 +複数のメンバーが同じインスタンス数の場合は、それらの 1 つがランダムで選ばれます。 -However, you can control this behavior with the {config:option}`cluster-cluster:scheduler.instance` configuration option: +しかし、この挙動を {config:option}`cluster-cluster:scheduler.instance` 設定で制御することもできます: -- If `scheduler.instance` is set to `all` for a cluster member, this cluster member is selected for an instance if: +- クラスタメンバーの `scheduler.instance` が `all` に設定されると、以下の条件でこのクラスタメンバーが選ばれます: - - The instance is created without `--target` and the cluster member has the lowest number of instances. - - The instance is targeted to live on this cluster member. - - The instance is targeted to live on a member of a cluster group that the cluster member is a part of, and the cluster member has the lowest number of instances compared to the other members of the cluster group. + - インスタンスが `--target` を指定せずに作成され、かつクラスタメンバーのインスタンス数が最小である。 + - インスタンスがこのクラスタメンバー上で稼働するようにターゲットされた。 + - インスタンスがこのクラスタメンバーが所属するクラスタグループのメンバー上で稼働するようにターゲットされ、かつクラスタメンバーがそのクラスタグループの他のメンバーと比べてインスタンス数が最小である。 -- If `scheduler.instance` is set to `manual` for a cluster member, this cluster member is selected for an instance if: +- クラスタメンバーの `scheduler.instance` が `manual` に設定されると、以下の条件でこのクラスタメンバーが選ばれる: - - The instance is targeted to live on this cluster member. + - インスタンスがこのクラスタメンバー上で稼働するようにターゲットされた。 -- If `scheduler.instance` is set to `group` for a cluster member, this cluster member is selected for an instance if: +- クラスタメンバーの `scheduler.instance` が `group` に設定されると、以下の条件でこのクラスタメンバーが選ばれる: - - The instance is targeted to live on this cluster member. - - The instance is targeted to live on a member of a cluster group that the cluster member is a part of, and the cluster member has the lowest number of instances compared to the other members of the cluster group. + - インスタンスがこのクラスタメンバー上で稼働するようにターゲットされた。 + - インスタンスがこのクラスタメンバーが所属するクラスタグループのメンバー上で稼働するようにターゲットされ、かつクラスタメンバーがそのクラスタグループの他のメンバーと比べてインスタンス数が最小である。 (clustering-instance-placement-scriptlet)= -### Instance placement scriptlet +### インスタンス配置スクリプトレット -Incus supports using custom logic to control automatic instance placement by using an embedded script (scriptlet). -This method provides more flexibility than the built-in instance placement functionality. +Incus では埋め込まれたスクリプト(スクリプトレット)を使って自動的なインスタンス配置を制御するカスタムロジックを使用できます。 +この方法は、組み込みのインスタンス配置機能よりも柔軟性が高いです。 -The instance placement scriptlet must be written in the [Starlark language](https://github.com/bazelbuild/starlark) (which is a subset of Python). -The scriptlet is invoked each time Incus needs to know where to place an instance. -The scriptlet receives information about the instance that is being placed and the candidate cluster members that could host the instance. -It is also possible for the scriptlet to request information about each candidate cluster member's state and the hardware resources available. +インスタンス配置スクリプトレットは[Starlark言語](https://github.com/bazelbuild/starlark) (Python のサブセット)で記述する必要があります。 +スクリプトレットは、Incus がインスタンスをどこに配置するかを知る必要があるたびに呼び出されます。 +スクリプトレットは、配置されるインスタンスに関する情報と、インスタンスをホストできる候補のクラスタメンバーに関する情報を受け取ります。 +スクリプトレットからクラスタメンバー候補の状態と利用可能なハードウェアリソースについての情報を要求することもできます。 -An instance placement scriptlet must implement the `instance_placement` function with the following signature: +インスタンス配置スクリプトレットは`instance_placement`関数を以下のシグネチャで実装する必要があります: `instance_placement(request, candidate_members)`: -- `request` is an object that contains an expanded representation of [`scriptlet.InstancePlacement`](https://pkg.go.dev/github.com/lxc/incus/shared/api/scriptlet/#InstancePlacement). This request includes `project` and `reason` fields. The `reason` can be `new`, `evacuation` or `relocation`. -- `candidate_members` is a `list` of cluster member objects representing [`api.ClusterMember`](https://pkg.go.dev/github.com/lxc/incus/shared/api#ClusterMember) entries. +- `request`は、[`scriptlet.InstancePlacement`](https://pkg.go.dev/github.com/lxc/incus/shared/api/scriptlet/#InstancePlacement) の展開された表現を含むオブジェクトである。このリクエストには、`project`および`reason`フィールドが含まれています。`reason`は、`new`、`evacuation`、または`relocation`のいずれかである。 +- `candidate_members`は、[`api.ClusterMember`](https://pkg.go.dev/github.com/lxc/incus/shared/api#ClusterMember) エントリを表すクラスタメンバーオブジェクトの`list`である。 -For example: +たとえば: ```python def instance_placement(request, candidate_members): - # Example of logging info, this will appear in Incus' log. + # 情報ログ出力の例。これは Incus のログに出力されます。 log_info("instance placement started: ", request) - # Example of applying logic based on the instance request. + # インスタンスのリクエストに基づいてロジックを適用する例。 if request.name == "foo": - # Example of logging an error, this will appear in Incus' log. + # エラーログ出力の例。これは Incus のログに出力されます。 log_error("Invalid name supplied: ", request.name) - fail("Invalid name") # Exit with an error to reject instance placement. + fail("Invalid name") # エラーで終了してインスタンス配置を拒否します。 - # Place the instance on the first candidate server provided. + # 提供された第1候補のサーバーにインスタンスを配置する。 set_target(candidate_members[0].server_name) - return # Return empty to allow instance placement to proceed. + return # インスタンス配置を進めるために空を返す。 ``` -The scriptlet must be applied to Incus by storing it in the `instances.placement.scriptlet` global configuration setting. +スクリプトレットは Incus に適用するためには`instances.placement.scriptlet`グローバル設定に設定する必要があります。 -For example, if the scriptlet is saved inside a file called `instance_placement.star`, then it can be applied to Incus with the following command: +たとえばスクリプトレットが`instance_placement.star`というファイルに保存されている場合、Incus には以下のように適用できます: cat instance_placement.star | incus config set instances.placement.scriptlet=- -To see the current scriptlet applied to Incus, use the `incus config get instances.placement.scriptlet` command. +Incus に現在適用されているスクリプトレットを見るには`lxc config get instances.placement.scriptlet`コマンドを使用してください。 -The following functions are available to the scriptlet (in addition to those provided by Starlark): +スクリプトレットでは（Starlark で提供される関数に加えて）以下の関数が利用できます: -- `log_info(*messages)`: Add a log entry to Incus' log at `info` level. `messages` is one or more message arguments. -- `log_warn(*messages)`: Add a log entry to Incus' log at `warn` level. `messages` is one or more message arguments. -- `log_error(*messages)`: Add a log entry to Incus' log at `error` level. `messages` is one or more message arguments. -- `set_cluster_member_target(member_name)`: Set the cluster member where the instance should be created. `member_name` is the name of the cluster member the instance should be created on. If this function is not called, then Incus will use its built-in instance placement logic. -- `get_cluster_member_state(member_name)`: Get the cluster member's state. Returns an object with the cluster member's state in the form of [`api.ClusterMemberState`](https://pkg.go.dev/github.com/lxc/incus/shared/api#ClusterMemberState). `member_name` is the name of the cluster member to get the state for. -- `get_cluster_member_resources(member_name)`: Get information about resources on the cluster member. Returns an object with the resource information in the form of [`api.Resources`](https://pkg.go.dev/github.com/lxc/incus/shared/api#Resources). `member_name` is the name of the cluster member to get the resource information for. -- `get_instance_resources()`: Get information about the resources the instance will require. Returns an object with the resource information in the form of [`scriptlet.InstanceResources`](https://pkg.go.dev/github.com/lxc/incus/shared/api/scriptlet/#InstanceResources). +- `log_info(*messages)`: `info`レベルで Incus のログにログエントリを追加する。`messages`は 1 つ以上のメッセージの引数。 +- `log_warn(*messages)`: `warn`レベルで Incus のログにログエントリを追加する。`messages`は 1 つ以上のメッセージの引数。 +- `log_error(*messages)`: `error`レベルで Incus のログにログエントリを追加する。`messages`は 1 つ以上のメッセージの引数。 +- `set_cluster_member_target(member_name)`: インスタンスが作成されるべきクラスタメンバーを設定する。`member_name`はインスタンスが作成されるべきクラスタメンバーの名前。この関数が呼ばれなければ、Incus は組み込みのインスタンス配置ロジックを使用する。 +- `get_cluster_member_state(member_name)`: クラスタメンバーの状態を取得する。[`api.ClusterMemberState`](https://pkg.go.dev/github.com/lxc/incus/shared/api#ClusterMemberState)の形式でクラスタメンバーの状態を含むオブジェクトを返す。`member_name`は状態を取得する対象のクラスタメンバーの名前。 +- `get_cluster_member_resources(member_name)`: クラスタメンバーのリソースについての情報を取得する。[`api.Resources`](https://pkg.go.dev/github.com/lxc/incus/shared/api#Resources)の形式でリソースについての情報を含むオブジェクトを返す。`member_name`はリソース情報を取得する対象のクラスタメンバーの名前。 +- `get_instance_resources()`: インスタンスが必要とするリソースについての情報を取得する。[`scriptlet.InstanceResources`](https://pkg.go.dev/github.com/lxc/incus/shared/api/scriptlet/#InstanceResources)の形式でリソース情報を含むオブジェクトを返す。 ```{note} -Field names in the object types are equivalent to the JSON field names in the associated Go types. +オブジェクト内のフィールド名は対応する Go の型の JSON フィールド名と同じです。 ``` diff --git a/doc/explanation/containers_and_vms.md b/doc/explanation/containers_and_vms.md index 60f657c562a..ee973ccf706 100644 --- a/doc/explanation/containers_and_vms.md +++ b/doc/explanation/containers_and_vms.md @@ -1,24 +1,24 @@ (containers-and-vms)= -# About containers and VMs +# コンテナと仮想マシンについて -Incus provides support for two different types of {ref}`instances `: *system containers* and *virtual machines*. +Incus は*システムコンテナ*と*仮想マシン*という 2 つの異なるタイプの{ref}`インスタンス `をサポートしています。 -When running a system container, Incus simulates a virtual version of a full operating system. To do this, it uses the functionality provided by the kernel running on the host system. +システムコンテナを動かす際は、Incus は完全なバージョンの OS をシミュレートします。このために、ホストシステム上で稼働しているカーネルが提供する機能を使用します。 -When running a virtual machine, Incus uses the hardware of the host system, but the kernel is provided by the virtual machine. Therefore, virtual machines can be used to run, for example, a different operating system. +仮想マシンを動かす際は、Incus はホストシステムのハードウェアを使用しますが、カーネルは仮想マシンにより提供されます。ですので、仮想マシンはたとえば別の OS を動かすこともできます。 -## Application containers vs. system containers +## アプリケーションコンテナとシステムコンテナ -Application containers (as provided by, for example, Docker) package a single process or application. System containers, on the other hand, simulate a full operating system and let you run multiple processes at the same time. +（たとえば Docker で提供される）アプリケーションコンテナは単一のプロセスあるいはアプリケーションをパッケージするものです。一方、システムコンテナは完全な OS をシミュレートし、同時に複数のプロセスを稼働させます。 -Therefore, application containers are suitable to provide separate components, while system containers provide a full solution of libraries, applications, databases and so on. In addition, you can use system containers to create different user spaces and isolate all processes belonging to each user space, which is not what application containers are intended for. +ですので、アプリケーションは分離したコンポーネントを提供するのに適しているのに対して、システムコンテナはライブラリ、アプリケーション、データベースなど、あらゆるソリューションを提供します。さらに、異なるユーザー空間を作成し、それぞれのユーザー空間に属するすべてのプロセスを隔離するためにシステムコンテナを使うこともできます。これらの用途はアプリケーションコンテナ向きではありません。 -![Application and system containers](/images/application-vs-system-containers.svg "Application and system containers") +![アプリケーションとシステムコンテナ](/images/application-vs-system-containers.svg "アプリケーションとシステムコンテナ") -## Virtual machines vs. system containers +## 仮想マシンとシステムコンテナ -Virtual machines emulate a physical machine, using the hardware of the host system from a full and completely isolated operating system. System containers, on the other hand, use the OS kernel of the host system instead of creating their own environment. If you run several system containers, they all share the same kernel, which makes them faster and more light-weight than virtual machines. +仮想マシンは完全で隔離された OS を使いホストシステムのハードウェアを使用して物理マシンをエミュレートします。一方、システムコンテナは自分自身のカーネルを作成せずホストシステムのカーネルを使用します。複数のシステムコンテナを稼働させる場合、それらすべては同じカーネルを共有しますので、仮想マシンより高速で軽量になります。 -With Incus, you can create both system containers and virtual machines. You should use a system container to leverage the smaller size and increased performance if all functionality you require is compatible with the kernel of your host operating system. If you need functionality that is not supported by the OS kernel of your host system or you want to run a completely different OS, use a virtual machine. +Incus ではシステムコンテナと仮想マシンの両方を作成できます。必要な機能のすべてがホストの OS カーネルと互換性がある場合は、システムコンテナを使うとより小さいサイズで高パフォーマンスを得られます。ホストシステムの OS カーネルでサポートされない機能が必要かあるいは完全に異なる OS を使いたい場合は仮想マシンを使ってください。 -![Virtual machines and system containers](/images/virtual-machines-vs-system-containers.svg "Virtual machines and system containers") +![仮想マシンとシステムコンテナ](/images/virtual-machines-vs-system-containers.svg "仮想マシンとシステムコンテナ") diff --git a/doc/explanation/instance_config.md b/doc/explanation/instance_config.md index 860a6506f07..8f797e116e0 100644 --- a/doc/explanation/instance_config.md +++ b/doc/explanation/instance_config.md @@ -1,37 +1,37 @@ (instance-config)= -# Instance configuration +# インスタンスの設定 -The instance configuration consists of different categories: +インスタンス設定は以下の異なるカテゴリから構成されます: -Instance properties -: Instance properties are specified when the instance is created. - They include, for example, the instance name and architecture. - Some of the properties are read-only and cannot be changed after creation, while others can be updated by {ref}`setting their property value ` or {ref}`editing the full instance configuration `. +インスタンスプロパティ +: インスタンスプロパティはインスタンスが作成されるときに指定されます。 + これには、たとえば、インスタンス名やアーキテクチャが含まれます。 + いくつかのプロパティは読み取り専用で作成後は変更できませんが、他のプロパティは{ref}`プロパティの値を設定する ` または {ref}`インスタンス設定全体を編集する ` で更新できます。 - In the YAML configuration, properties are on the top level. + YAML 設定内では、プロパティはトップレベルにあります。 - See {ref}`instance-properties` for a reference of available instance properties. + 利用可能なインスタンスプロパティのレファレンスは {ref}`instance-properties` を参照してください。 -Instance options -: Instance options are configuration options that are related directly to the instance. - They include, for example, startup options, security settings, hardware limits, kernel modules, snapshots and user keys. - These options can be specified as key/value pairs during instance creation (through the `--config key=value` flag). - After creation, they can be configured with the [`incus config set`](incus_config_set.md) and [`incus config unset`](incus_config_unset.md) commands. +インスタンスオプション +: インスタンスオプションはインスタンスに直接関連する設定オプションです。 + これには、たとえば、起動時のオプション、セキュリティー設定、ハードウェアのリミット、カーネルモジュール、スナップショット、そしてユーザーの鍵を含みます。 + これらのオプションはインスタンスの作成時に (`--config key=value` フラグを使って) キー/バリューペアで指定できます。 + 作成後は [`incus config set`](incus_config_set.md) や [`incus config unset`](incus_config_unset.md) コマンドで変更できます。 - In the YAML configuration, options are located under the `config` entry. + YAML 設定内では、オプションは `config` エントリの下に配置されます。 - See {ref}`instance-options` for a reference of available instance options, and {ref}`instances-configure-options` for instructions on how to configure the options. + 利用可能なインスタンスオプションのレファレンスは {ref}`instance-options`、オプションをどのように設定するかの手順は {ref}`instances-configure-options` を参照してください。 -Instance devices -: Instance devices are attached to an instance. - They include, for example, network interfaces, mount points, USB and GPU devices. - Devices are usually added after an instance is created with the [`incus config device add`](incus_config_device_add.md) command, but they can also be added to a profile or a YAML configuration file that is used to create an instance. +インスタンスデバイス +: インスタンスデバイスはインスタンスにアタッチされます。 + これらは、たとえば、ネットワークインターフェース、マウントポイント、USB そして GPU デバイスが含まれます。 + 通常、デバイスはインスタンスを作成した後に [`incus config device add`](incus_config_device_add.md) コマンドで追加しますが、プロファイルやインスタンスを作成するのに使用する YAML 設定ファイルに追加することもできます。 - Each type of device has its own specific set of options, referred to as *instance device options*. + 各デバイスタイプには固有のオプションのセットがあり、*インスタンスデバイスオプション*として参照されます。 - In the YAML configuration, devices are located under the `devices` entry. + YAML 設定内では、デバイスは `devices` エントリの下に配置されます。 - See {ref}`devices` for a reference of available devices and the corresponding instance device options, and {ref}`instances-configure-devices` for instructions on how to add and configure instance devices. + 利用可能なデバイスと対応するインスタンスデバイスオプションのレファレンスについては {ref}`devices`、インスタンスデバイスをどのように追加し設定するかの手順は {ref}`instances-configure-devices` を参照してください。 ```{toctree} :maxdepth: 1 diff --git a/doc/explanation/instances.md b/doc/explanation/instances.md index 51a8a430394..93d4b930644 100644 --- a/doc/explanation/instances.md +++ b/doc/explanation/instances.md @@ -1,24 +1,24 @@ (expl-instances)= -# About instances +# インスタンスについて -Incus supports the following types of instances: +Incus は以下のインスタンスタイプをサポートします: -Containers -: Containers are the default type for instances. - They are currently the most complete implementation of Incus instances and support more features than virtual machines. +コンテナ +: コンテナはデフォルトのインスタンスタイプです。 + コンテナは現状 Incus インスタンスの最も完全な実装であり、仮想マシンよりも多くの機能をサポートしています。 - Containers are implemented through the use of `liblxc` (LXC). + コンテナは `liblxc`（LXC）を使って実装されています。 -Virtual machines -: {abbr}`Virtual machines (VMs)` are natively supported since version 4.0 of Incus. - Thanks to a built-in agent, they can be used almost like containers. +仮想マシン +: {abbr}`Virtual machines (VMs)` は Incus バージョン 4.0 以降ネイティブにサポートされています。 + ビルトインのエージェントのおかげで、ほぼコンテナと同様に使えます。 - Incus uses `qemu` to provide the VM functionality. + Incus は仮想マシンの機能を提供するために `qemu` を使用しています。 ```{note} - Currently, virtual machines support fewer features than containers, but the plan is to support the same set of features for both instance types in the future. + 現状、仮想マシンはコンテナよりサポートする機能が少ないですが、将来には両方のインスタンスタイプで同じ機能セットをサポートする計画です。 - To see which features are available for virtual machines, check the condition column in the {ref}`instance-options` documentation. + 仮想マシンでどの機能が利用可能かを見るには、{ref}`instance-options` ドキュメントの条件のカラムを確認してください。 ``` -See {ref}`containers-and-vms` for more information about the different instance types. +インスタンスタイプのより詳細な情報は{ref}`containers-and-vms`を参照してください。 diff --git a/doc/explanation/networks.md b/doc/explanation/networks.md index f14639a84e9..2177871782b 100644 --- a/doc/explanation/networks.md +++ b/doc/explanation/networks.md @@ -1,54 +1,55 @@ (networks)= -# About networking +# ネットワークについて -There are different ways to connect your instances to the Internet. The easiest method is to have Incus create a network bridge during initialization and use this bridge for all instances, but Incus supports many different and advanced setups for networking. +あなたのインスタンスをインターネットに接続するにはいろいろな方法があります。 +最も簡単な方法は Incus の初期化時にネットワークブリッジを作ってすべてのインスタンスでこのブリッジを使うことですが、 Incus はネットワークに関するさまざまな高度な設定をサポートします。 -## Network devices +## ネットワークデバイス -To grant direct network access to an instance, you must assign it at least one network device, also called {abbr}`NIC (Network Interface Controller)`. -You can configure the network device in one of the following ways: +インスタンスへの直接のネットワークアクセスを許可するには、 {abbr}`NIC (Network Interface Controller)` とも呼ばれるネットワークデバイスを最低 1 つ割り当てる必要があります +ネットワークデバイスは以下のどれかの方法で設定できます: -- Use the default network bridge that you set up during the Incus initialization. - Check the default profile to see the default configuration: +- Incus の初期化中にセットアップしたデフォルトのネットワークブリッジを使用する。 + デフォルトの設定を表示するにはデフォルトのプロファイルを確認します: incus profile show default - This method is used if you do not specify a network device for your instance. -- Use an existing network interface by adding it as a network device to your instance. - This network interface is outside of Incus control. - Therefore, you must specify all information that Incus needs to use the network interface. + この方法はインスタンスのネットワークを指定しない場合に使用します。 +- 既存のネットワークインターフェースをインスタンスにネットワークデバイスとして追加して使用する。 + このネットワークインターフェースは Incus の制御外です。 + そのため、ネットワークインターフェースを使用するために必要なすべての情報を Incus に指定する必要があります。 - Use a command similar to the following: + 以下のようなコマンドを使用します: incus config device add nic nictype= ... - See [Type: `nic`](devices-nic) for a list of available NIC types and their configuration properties. + 指定可能な NIC タイプの一覧とそれらの設定プロパティについては [タイプ: `nic`](devices-nic) を参照してください。 - For example, you could add a pre-existing Linux bridge (`br0`) with the following command: + たとえば、既存の Linux ブリッジ (`br0`) を追加するには以下のコマンドを使えます: incus config device add eth0 nic nictype=bridged parent=br0 -- {doc}`Create a managed network ` and add it as a network device to your instance. - With this method, Incus has all required information about the configured network, and you can directly attach it to your instance as a device: +- {doc}`マネージドネットワークを作成 ` し、それをインスタンスにネットワークデバイスとして追加する。 + この方法では Incus は設定されるネットワークについてのすべての必要な情報を持っていますので、デバイスとしてインスタンスに直接アタッチできます: incus network attach - See {ref}`network-attach` for more information. + 詳細は{ref}`network-attach`を参照してください。 (managed-networks)= -## Managed networks +## マネージドネットワーク -Managed networks in Incus are created and configured with the `incus network [create|edit|set]` command. +Incus でマネージドネットワークは `incus network [create|edit|set]` コマンドで作成と設定をします。 -Depending on the network type, Incus either fully controls the network or just manages an external network interface. +ネットワークタイプによって、 Incus はネットワークを完全に制御するか、単に外部のネットワークインターフェースを管理するかのどちらかになります。 -Note that not all {ref}`NIC types ` are supported as network types. -Incus can only set up some of the types as managed networks. +すべての {ref}`NIC タイプ ` がネットワークタイプとしてサポートされているわけではないことに注意してください。 +Incus はいくつかのタイプのみマネージドネットワークとしてセットアップできます。 -### Fully controlled networks +### 完全に制御されるネットワーク -Fully controlled networks create network interfaces and provide most functionality, including, for example, the ability to do IP management. +完全に制御されるネットワークではネットワークインターフェースを作成し、たとえば IP を管理する機能を含むほとんどの機能を提供します。 -Incus supports the following network types: +Incus は以下のネットワークタイプをサポートします: {ref}`network-bridge` : % Include content from [../reference/network_bridge.md](../reference/network_bridge.md) @@ -57,11 +58,11 @@ Incus supports the following network types: :end-before: ``` - In Incus context, the `bridge` network type creates an L2 bridge that connects the instances that use it together into a single network L2 segment. - This makes it possible to pass traffic between the instances. - The bridge can also provide local DHCP and DNS. + Incus の文脈では、 `bridge` ネットワークタイプは、ブリッジを共用するインスタンスを同一の L2 ネットワークセグメントに接続するような L2 ブリッジを作成します。 + これによりインスタンス間のトラフィックを通すことができます。 + ブリッジはさらにローカルの DHCP と DNS を提供することもできます。 - This is the default network type. + これがデフォルトのネットワークタイプです。 {ref}`network-ovn` : % Include content from [../reference/network_ovn.md](../reference/network_ovn.md) @@ -70,17 +71,17 @@ Incus supports the following network types: :end-before: ``` - In Incus context, the `ovn` network type creates a logical network. - To set it up, you must install and configure the OVN tools. - In addition, you must create an uplink network that provides the network connection for OVN. - As the uplink network, you should use one of the external network types or a managed Incus bridge. + Incus の文脈では、 `ovn` ネットワークタイプは論理ネットワークを作成します。 + セットアップするには OVN ツールをインストールし設定する必要があります。 + さらに、OVN にネットワーク接続を提供するアップリンクのネットワークを作成する必要があります。 + アップリンクのネットワークとして、外部ネットワークタイプの 1 つかマネージドな Incus ブリッジを使う必要があります。 ```{tip} - Unlike the other network types, you can create and manage an OVN network inside a {ref}`project `. - This means that you can create your own OVN network as a non-admin user, even in a restricted project. + 他のネットワークタイプと違って、 OVN ネットワークは {ref}`プロジェクト ` 内に作成・管理できます。 + これは、制限されたプロジェクトであっても、非管理者ユーザとして自身の OVN ネットワークを作成できることを意味します。 ``` -### External networks +### 外部ネットワーク % Include content from [../reference/network_external.md](../reference/network_external.md) ```{include} ../reference/network_external.md @@ -95,7 +96,7 @@ Incus supports the following network types: :end-before: ``` - In Incus context, the `macvlan` network type provides a preset configuration to use when connecting instances to a parent macvlan interface. + Incus の文脈では、 `macvlan` ネットワークタイプは親の macvlan インターフェースへインスタンスを接続する際に使用するプリセット設定を提供します。 {ref}`network-sriov` : % Include content from [../reference/network_sriov.md](../reference/network_sriov.md) @@ -104,7 +105,7 @@ Incus supports the following network types: :end-before: ``` - In Incus context, the `sriov` network type provides a preset configuration to use when connecting instances to a parent SR-IOV interface. + Incus の文脈では、 `sriov` ネットワークタイプは親の SR-IOV インターフェースへインスタンスを接続する際に使用するプリセット設定を提供します。 {ref}`network-physical` : % Include content from [../reference/network_physical.md](../reference/network_physical.md) @@ -113,24 +114,24 @@ Incus supports the following network types: :end-before: ``` - It provides a preset configuration to use when connecting OVN networks to a parent interface. + OVN ネットワークを親インターフェースに接続する際のプリセット設定を提供します。 -## Recommendations +## お勧めの設定 -In general, if you can use a managed network, you should do so because networks are easy to configure and you can reuse the same network for several instances without repeating the configuration. +一般に、マネージドネットワークは設定が容易で設定を繰り返すこと無く複数のインスタンスで同じネットワークを再利用できるので、マネージドネットワークが使用できる場合はこれを使用すべきです。 -Which network type to choose depends on your specific use case. -If you choose a fully controlled network, it provides more functionality than using a network device. +どのネットワークタイプを使用すべきかはあなたの固有の使い方によります。 +完全に制御されたネットワークを選ぶと、ネットワークデバイスを使用するのに比べてより多くの機能を提供します。 -As a general recommendation: +一般的なお勧めとしては: -- If you are running Incus on a single system or in a public cloud, use a {ref}`network-bridge`. -- If you are running Incus in your own private cloud, use an {ref}`network-ovn`. +- Incus を単一のシステム上かパブリッククラウドで動かしている場合は、 {ref}`network-bridge` を使用してください。 +- あなた自身のプライベートクラウドで Incus を動かしている場合は、 {ref}`network-ovn` を使用してください。 ```{note} - OVN requires a shared L2 uplink network for proper operation. - Therefore, using OVN is usually not possible if you run Incus in a public cloud. + OVN は適切な運用には共有された L2 のアップリンクネットワークが必要です。 + このため、パブリッククラウドで Incus を動かしている場合は通常 OVN は使用できません。 ``` -- To connect an instance NIC to a managed network, use the `network` property rather than the `parent` property, if possible. - This way, the NIC can inherit the settings from the network and you don't need to specify the `nictype`. +- インスタンス NIC をマネージドネットワークに接続するためには、可能であれば `parent` プロパティより `network` プロパティを使用してください。 + こうすることで、 NIC はネットワークの設定を引き継ぎ、 `nictype` を指定する必要がなくなります。 diff --git a/doc/explanation/performance_tuning.md b/doc/explanation/performance_tuning.md index 5cb81730d67..c43ad4c669d 100644 --- a/doc/explanation/performance_tuning.md +++ b/doc/explanation/performance_tuning.md @@ -1,19 +1,19 @@ (performance-tuning)= -# About performance tuning +# パフォーマンスチューニングについて -When you are ready to move your Incus setup to production, you should take some time to optimize the performance of your system. -There are different aspects that impact performance. -The following steps help you to determine the choices and settings that you should tune to improve your Incus setup. +お使いの Incus 環境を本番稼働に移行する準備が出来たら、システムのパフォーマンスを最適化するためにいくらか時間を取るほうが良いです。 +パフォーマンスに影響を与えるいくつかの視点があります。 +お使いの Incus 環境を改善するためにチューニングするべき選択肢と設定を決定するのに以下の手順が役立ちます。 -## Run benchmarks +## ベンチマークを実行する -Incus provides a benchmarking tool to evaluate the performance of your system. -You can use the tool to initialize or launch a number of containers and measure the time it takes for the system to create the containers. -By running the tool repeatedly with different Incus configurations, system settings or even hardware setups, you can compare the performance and evaluate which is the ideal configuration. +Incus はシステムのパフォーマンスを評価するためにベンチマークツールを提供しています。 +このツールを使って複数のコンテナを初期化・起動し、システムがコンテナを作成するのに必要な時間を計測できます。 +異なる Incus の設定、システム設定、さらにはハードウェア構成に対して繰り返しツールを実行することで、パフォーマンスを比較し、どの設定が理想的か評価できます。 -See {ref}`benchmark-performance` for instructions on running the tool. +ツールを実行する手順については {ref}`benchmark-performance` を参照してください。 -## Monitor instance metrics +## インスタンスのメトリクスをモニターする % Include content from [../metrics.md](../metrics.md) ```{include} ../metrics.md @@ -21,28 +21,28 @@ See {ref}`benchmark-performance` for instructions on running the tool. :end-before: ``` -You should regularly monitor the metrics to evaluate the resources that your instances use. -The numbers help you to determine if there are any spikes or bottlenecks, or if usage patterns change and require updates to your configuration. +あなたのインスタンスが使用しているリソースを見積もるために定期的にメトリクスをモニターするほうが良いです。 +スパイクやボトルネックがある場合や、使用量のパターンが変化したり、設定を見直す必要がある場合に、これらの数値が役立ちます。 -See {ref}`metrics` for more information about metrics collection. +メトリクス収集についての詳細な情報は {ref}`metrics` を参照してください。 -## Tune server settings +## サーバー設定をチューニングする -The default kernel settings for most Linux distributions are not optimized for running a large number of containers or virtual machines. -Therefore, you should check and modify the relevant server settings to avoid hitting limits caused by the default settings. +ほとんどの Linux ディストリビューションのデフォルトのカーネル設定は大量のコンテナや仮想マシンを稼働させるのに最適化されていません。 +ですので、デフォルトの設定で引き起こされる制限にひっかかるのを避けるため、関連する設定を確認、変更するほうが良いです。 -Typical errors that you might see when you encounter those limits are: +これらの制限にひっかかかった場合の典型的なエラーは以下のようなものです: * `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!` -See {ref}`server-settings` for a list of relevant server settings and suggested values. +関連するサーバー設定と提案される値の一覧は {ref}`server-settings` を参照してください。 -## Tune the network bandwidth +## ネットワーク帯域幅をチューニングする -If you have a lot of local activity between instances or between the Incus host and the instances, or if you have a fast internet connection, you should consider increasing the network bandwidth of your Incus setup. -You can do this by increasing the transmit and receive queue lengths. +インスタンス間あるいは Incus ホストとインスタンス間で大量のローカルなアクティビティがある場合、あるいは高速なインターネット接続をお持ちの場合、 Incus のセットアップのネットワーク帯域幅を増やすことを検討すると良いです。 +これは送信と受信のキューの長さを拡張することで実現できます。 -See {ref}`network-increase-bandwidth` for instructions. +手順については {ref}`network-increase-bandwidth` を参照してください。 diff --git a/doc/explanation/projects.md b/doc/explanation/projects.md index d7f85226a91..cd46249934e 100644 --- a/doc/explanation/projects.md +++ b/doc/explanation/projects.md @@ -1,73 +1,73 @@ (exp-projects)= -# About projects +# プロジェクトについて -You can use projects to keep your Incus server clean by grouping related instances together. -In addition to isolated instances, each project can also have specific images, profiles, networks, and storage. +Incus サーバーを整理して、関連するインスタンスをまとめるためにプロジェクトを使用できます。 +隔離されたインスタンスに加えて、各プロジェクトは特定のイメージ、プロファイル、ネットワーク、およびストレージを持つことができます。 -For example, projects can be useful in the following scenarios: +たとえば、プロジェクトは以下のシナリオで役立ちます: -- You run a huge number of instances for different purposes, for example, for different customer projects. - You want to keep these instances separate to make it easier to locate and maintain them, and you might want to reuse the same instance names in each customer project for consistency reasons. - Each instance in a customer project should use the same base configuration (for example, networks and storage), but the configuration might differ between customer projects. +- 異なる目的のために非常に多くのインスタンスを実行している場合、たとえば、異なる顧客プロジェクトのために。 + これらのインスタンスを別々にして、それらを見つけやすく管理しやすくすることを望みます。また、整合性のために各顧客プロジェクトで同じインスタンス名を再利用することができます。 + 顧客プロジェクト内の各インスタンスは、同じ基本構成（たとえば、ネットワークやストレージ）を使用する必要がありますが、顧客プロジェクト間で構成が異なる場合があります。 - In this case, you can create a Incus project for each customer project (thus each group of instances) and use different profiles, networks, and storage for each Incus project. -- Your Incus server is shared between multiple users. - Each user runs their own instances, and might want to configure their own profiles. - You want to keep the user instances confined, so that each user can interact only with their own instances and cannot see the instances created by other users. - In addition, you want to be able to limit resources for each user and make sure that the instances of different users cannot interfere with one another. + この場合、各顧客プロジェクト（つまり、各インスタンスのグループ）ごとに Incus プロジェクトを作成し、各 Incus プロジェクトで異なるプロファイル、ネットワーク、およびストレージを使用できます。 +- Incus サーバーが複数のユーザー間で共有されている場合。 + 各ユーザーは自分のインスタンスを実行し、自分のプロファイルを設定するかもしれません。 + ユーザーインスタンスを制限し、各ユーザーが自分のインスタンスのみとやり取りでき、他のユーザーが作成したインスタンスを見ることができないようにしたいです。 + さらに、各ユーザーのリソースを制限し、異なるユーザーのインスタンスが互いに干渉しないようにしたいです。 - In this case, you can set up a multi-user environment with confined projects. + この場合、制限されたプロジェクトを持つマルチユーザー環境を設定できます。 -Incus comes with a `default` project. -See {ref}`projects-create` for instructions on how to add projects. +Incus には`default`プロジェクトが付属しています。 +プロジェクトを追加する方法については、{ref}`projects-create`を参照してください。 (projects-isolation)= -## Isolation of projects +## プロジェクトの隔離 -Projects always encapsulate the instances they contain, which means that instances cannot be shared between projects and instance names can be duplicated in several projects. -When you are in a specific project, you can see only the instances that belong to this project. +プロジェクトは常にそれらが含むインスタンスをカプセル化します。これは、インスタンスがプロジェクト間で共有されず、インスタンス名が複数のプロジェクトで重複して使用できることを意味します。 +特定のプロジェクト内にいる場合、そのプロジェクトに属するインスタンスのみが表示されます。 -Other entities (images, profiles, networks, and storage) can be either isolated in the project or inherited from the `default` project. -To configure which entities are isolated, you enable or disable the respective *feature* in the project. -If a feature is enabled, the corresponding entity is isolated in the project; if the feature is disabled, it is inherited from the `default` project. +他のエンティティ（イメージ、プロファイル、ネットワーク、およびストレージ）は、プロジェクト内で隔離されるか、`default`プロジェクトから継承されます。 +どのエンティティが隔離されているかを設定するには、プロジェクト内で対応する*機能*を有効または無効にします。 +機能が有効になっている場合、対応するエンティティはプロジェクト内で隔離されます。機能が無効になっている場合、`default`プロジェクトから継承されます。 -For example, if you enable {config:option}`project-features:features.networks` for a project, the project uses a separate set of networks and not the networks defined in the `default` project. If you disable {config:option}`project-features:features.images`, the project has access to the images defined in the `default` project, and any images you add while you're using the project are also added to the `default` project. +たとえば、プロジェクトで{config:option}`project-features:features.networks`を有効にすると、プロジェクトは別のネットワークのセットを使用し、`default`プロジェクトで定義されたネットワークは使用しません。{config:option}`project-features:features.images`を無効にすると、プロジェクトは`default`プロジェクトで定義されたイメージにアクセスでき、プロジェクトを使用している間に追加したイメージも`default`プロジェクトに追加されます。 -See the list of available {ref}`project-features` for information about which features are enabled or disabled when you create a project. +プロジェクトを作成するときに有効または無効になっている機能についての情報は、利用可能な{ref}`project-features`のリストを参照してください。 ```{note} -You must select the features that you want to enable before starting to use a new project. -When a project contains instances, the features are locked. -To edit them, you must remove all instances first. +新しいプロジェクトを使用する前に、有効にしたい機能を選択する必要があります。 +プロジェクトにインスタンスが含まれている場合、機能はロックされます。 +それらを編集するには、まずすべてのインスタンスを削除する必要があります。 -New features that are added in an upgrade are disabled for existing projects. +アップグレードで追加された新しい機能は、既存のプロジェクトでは無効になっています。 ``` (projects-confined)= -## Confined projects in a multi-user environment +## マルチユーザー環境での制限されたプロジェクト -If your Incus server is used by multiple users (for example, in a lab environment), you can use projects to confine the activities of each user. -This method isolates the instances and other entities (depending on the feature configuration), as described in {ref}`projects-isolation`. -It also confines users to their own user space and prevents them from gaining access to other users' instances or data. -Any changes that affect the Incus server and its configuration, for example, adding or removing storage, are not permitted. +Incus サーバーが複数のユーザーによって使用される場合（たとえば、ラボ環境で）、プロジェクトを使用して各ユーザーの活動を制限できます。 +この方法は、{ref}`projects-isolation`で説明されているように、インスタンスや他のエンティティ（機能設定に依存）を隔離します。 +また、ユーザーを自分のユーザースペースに制限し、他のユーザーのインスタンスやデータにアクセスできないようにします。 +Incus サーバーやその設定に影響を与える変更、たとえばストレージの追加や削除は許可されません。 -In addition, this method allows users to work with Incus without being a member of the `incus-admin` group (see {ref}`security-daemon-access`). -Members of the `incus-admin` group have full access to Incus, including permission to attach file system paths and tweak the security features of an instance, which makes it possible to gain root access to the host system. -Using confined projects limits what users can do in Incus, but it also prevents users from gaining root access. +さらに、この方法では、`incus-admin`グループのメンバーでなくても Incus を使用できます（{ref}`security-daemon-access`を参照）。 +`incus-admin`グループのメンバーは、Incus への完全なアクセス権を持っており、ファイルシステムのパスをアタッチしたり、インスタンスのセキュリティー機能を調整したりすることができます。これにより、ホストシステムへのルートアクセスが可能になります。 +制限されたプロジェクトを使用することで、ユーザーが Incus でできることを制限しますが、同時にユーザーが root アクセスを得ることも防ぎます。 -### Authentication methods for projects +### プロジェクトの認証方法 -There are different ways of authentication that you can use to confine projects to specific users: +特定のユーザーにプロジェクトを制限するために使用できるさまざまな認証方法があります。 -Client certificates -: You can restrict the {ref}`authentication-tls-certs` to allow access to specific projects only. - The projects must exist before you can restrict access to them. - A client that connects using a restricted certificate can see only the project or projects that the client has been granted access to. +クライアント証明書 +: {ref}`authentication-tls-certs`を制限して、特定のプロジェクトのみへのアクセスを許可することができます。 + アクセスを制限する前に、プロジェクトが存在している必要があります。 + 制限された証明書を使用して接続するクライアントは、クライアントがアクセスが許可されているプロジェクトのみを見ることができます。 -Multi-user Incus daemon -: A multi-user Incus daemon allows dynamic project creation on a per-user basis. - This is usually used for users that are a member of the `incus` group but aren't in the more privileged `incus-admin` group. +マルチユーザーIncus デーモン +: マルチユーザーの Incus デーモンはユーザーごとに動的なプロジェクトの作成を可能にします。 + これは通常`incus`グループに所属していますが、より権限の強い`incus-admin`グループには所属していないユーザーに使用されます。 - When a user that is a member of this group starts using Incus, Incus automatically creates a confined project for this user. + このグループのメンバーであるユーザーが Incus を使用し始めると、Incus は自動的にこのユーザーに制限されたプロジェクトを作成します。 -See {ref}`projects-confine` for instructions on how to enable and configure the different authentication methods. +さまざまな認証方法を有効にし、設定する方法については、{ref}`projects-confine`を参照してください。 diff --git a/doc/explanation/security.md b/doc/explanation/security.md index ff286a32e6d..93588237c4d 100644 --- a/doc/explanation/security.md +++ b/doc/explanation/security.md @@ -1,5 +1,5 @@ (exp-security)= -# About security +# セキュリティーについて % Include content from [../../README.md](../../README.md) ```{include} ../../README.md @@ -7,13 +7,13 @@ :end-before: ``` -See the following sections for detailed information. +詳細な情報は以下のセクションを参照してください。 -If you discover a security issue, see the [Incus security policy](https://github.com/lxc/incus/blob/main/SECURITY.md) for information on how to report the issue. +セキュリティー上の問題を発見した場合、その問題の報告方法については [Incus のセキュリティーポリシー](https://github.com/lxc-jp/incus-ja/blob/main/SECURITY.md)（原文: [Incus security policy](https://github.com/lxc/incus/blob/main/SECURITY.md)）を参照してください。 -## Supported versions +## サポートされているバージョン -Never use unsupported Incus versions in a production environment. +サポートされていないバージョンの Incus は実運用環境では絶対に使用しないでください。 % Include content from [../../SECURITY.md](../../SECURITY.md) ```{include} ../../SECURITY.md @@ -22,18 +22,18 @@ Never use unsupported Incus versions in a production environment. ``` (security-daemon-access)= -## Access to the Incus daemon +## Incus デーモンへのアクセス -Incus is a daemon that can be accessed locally over a Unix socket or, if configured, remotely over a {abbr}`TLS (Transport Layer Security)` socket. -Anyone with access to the socket can fully control Incus, which includes the ability to attach host devices and file systems or to tweak the security features for all instances. +Incus は Unix ソケットを介してローカルにアクセスできるデーモンで、設定されていれば{abbr}`TLS(Transport Layer Security)`ソケットを介してリモートにアクセスすることもできます。 +ソケットにアクセスできる人は、ホストデバイスやファイルシステムをアタッチしたり、すべてのインスタンスのセキュリティー機能をいじったりするなど、Incus を完全に制御することができます。 -Therefore, make sure to restrict the access to the daemon to trusted users. +したがって、デーモンへのアクセスを信頼できるユーザーに制限するようにしてください。 -### Local access to the Incus daemon +### Incus デーモンへのローカルアクセス -The Incus daemon runs as root and provides a Unix socket for local communication. -Access control for Incus is based on group membership. -The root user and all members of the `incus-admin` group can interact with the local daemon. +Incus デーモンは root で動作し、ローカル通信用の Unix ソケットを提供します。 +Incus のアクセス制御は、グループメンバーシップに基づいて行われます。 +root ユーザーと `incus-admin` グループのすべてのメンバーがローカルデーモンと対話できます。 ````{important} % Include content from [../../README.md](../../README.md) @@ -44,105 +44,105 @@ The root user and all members of the `incus-admin` group can interact with the l ```` (security_remote_access)= -### Access to the remote API +### リモート API へのアクセス -By default, access to the daemon is only possible locally. -By setting the `core.https_address` configuration option, you can expose the same API over the network on a {abbr}`TLS (Transport Layer Security)` socket. -See {ref}`server-expose` for instructions. -Remote clients can then connect to Incus and access any image that is marked for public use. +デフォルトでは、デーモンへのアクセスはローカルでのみ可能です。 +`core.https_address`という設定オプションを設定することで、同じ API を{abbr}`TLS (Transport Layer Security)`ソケットでネットワーク上に公開することができます。 +手順は {ref}`server-expose` を参照してください。 +リモートクライアントは、Incus に接続して、公開用にマークされたイメージにアクセスできます。 -There are several ways to authenticate remote clients as trusted clients to allow them to access the API. -See {ref}`authentication` for details. +リモートクライアントが API にアクセスできるように、信頼できるクライアントとして認証する方法がいくつかあります。 +詳細は{ref}`authentication`を参照してください。 -In a production setup, you should set `core.https_address` to the single address where the server should be available (rather than any address on the host). -In addition, you should set firewall rules to allow access to the Incus port only from authorized hosts/subnets. +本番環境では、`core.https_address`に、（ホスト上の任意のアドレスではなく）サーバーが利用可能な単一のアドレスを設定する必要があります。 +さらに、許可されたホスト/サブネットからのみ Incus ポートへのアクセスを許可するファイアウォールルールを設定する必要があります。 (container-security)= -## Container security +## コンテナのセキュリティー -Incus containers can use a wide range of features for security. +Incus コンテナはセキュリティーのために幅広い機能を使うことができます。 -By default, containers are *unprivileged*, meaning that they operate inside a user namespace, restricting the abilities of users in the container to that of regular users on the host with limited privileges on the devices that the container owns. +デフォルトでは、コンテナは *非特権*（*unprivileged*）であり、ユーザーNamespace 内で動作することを意味し、コンテナ内のユーザーの能力を、コンテナが所有するデバイスに対する制限された権限を持つホスト上の通常のユーザーに制限します。 -If data sharing between containers isn't needed, you can enable {config:option}`instance-security:security.idmap.isolated`, which will use non-overlapping UID/GID maps for each container, preventing potential {abbr}`DoS (Denial of Service)` attacks on other containers. +コンテナ間のデータ共有が必要ない場合は、{config:option}`instance-security:security.idmap.isolated`を有効にすることで、各コンテナに対して重複しない UID/GID マップを使用し、他のコンテナに対する潜在的な{abbr}`DoS (Denial of Service、サービス拒否)`攻撃を防ぐことができます。 -Incus can also run *privileged* containers. -Note, however, that those aren't root safe, and a user with root access in such a container will be able to DoS the host as well as find ways to escape confinement. +Incus はまた、*特権*（*privileged*）コンテナを実行することができます。 +しかし、これは（訳注:コンテナ内だけで）安全に root 権限を使えるわけではなく、そのようなコンテナの中でルートアクセスを持つユーザーは、閉じ込められた状態から逃れる方法を見つけるだけでなく、ホストを DoS することができてしまう点に注意してください。 -More details on container security and the kernel features we use can be found on the -[LXC security page](https://linuxcontainers.org/lxc/security/). +コンテナのセキュリティーと私たちが使っているカーネルの機能についてのより詳細な情報は +[LXCセキュリティページ](https://linuxcontainers.org/ja/lxc/security/)にあります。 -### Container name leakage +### コンテナ名の漏洩 -The default server configuration makes it easy to list all cgroups on a system and, by extension, all running containers. +デフォルトの設定ではシステム上のすべての cgroup と、さらに転じて、すべての実行中のコンテナを一覧表示することが簡単にできてしまいます。 -You can prevent this name leakage by blocking access to `/sys/kernel/slab` and `/proc/sched_debug` before you start any containers. -To do so, run the following commands: +コンテナを開始する前に `/sys/kernel/slab` と `/proc/sched_debug` へのアクセスをブロックすることでコンテナ名の漏洩を防げます。 +このためには以下のコマンドを実行してください: chmod 400 /proc/sched_debug chmod 700 /sys/kernel/slab/ -## Network security +## ネットワークセキュリティー -Make sure to configure your network interfaces to be secure. -Which aspects you should consider depends on the networking mode you decide to use. +ネットワークインターフェースは必ず安全に設定してください。 +どのような点を考慮すべきかは、使用するネットワークモードによって異なります。 -### Bridged NIC security +### ブリッジ型NICのセキュリティー -The default networking mode in Incus is to provide a "managed" private network bridge that each instance connects to. -In this mode, there is an interface on the host called `incusbr0` that acts as the bridge for the instances. +Incus のデフォルトのネットワークモードは、各インスタンスが接続する「管理された」プライベートネットワークのブリッジを提供することです。 +このモードでは、ホスト上に`incusbr0`というインターフェースがあり、それがインスタンスのブリッジとして機能します。 -The host runs an instance of `dnsmasq` for each managed bridge, which is responsible for allocating IP addresses and providing both authoritative and recursive DNS services. +ホストは、管理されたブリッジごとに`dnsmasq`のインスタンスを実行し、IP アドレスの割り当てと、権威 DNS および再帰 DNS サービスの提供を担当します。 -Instances using DHCPv4 will be allocated an IPv4 address, and a DNS record will be created for their instance name. -This prevents instances from being able to spoof DNS records by providing false host name information in the DHCP request. +DHCPv4 を使用しているインスタンスには、IPv4 アドレスが割り当てられ、インスタンス名の DNS レコードが作成されます。 +これにより、インスタンスが DHCP リクエストに偽のホスト名情報を提供して、DNS レコードを偽装することができなくなります。 -The `dnsmasq` service also provides IPv6 router advertisement capabilities. -This means that instances will auto-configure their own IPv6 address using SLAAC, so no allocation is made by `dnsmasq`. -However, instances that are also using DHCPv4 will also get an AAAA DNS record created for the equivalent SLAAC IPv6 address. -This assumes that the instances are not using any IPv6 privacy extensions when generating IPv6 addresses. +`dnsmasq`サービスは、IPv6 のルータ広告機能も提供します。 +つまり、インスタンスは SLAAC を使って自分の IPv6 アドレスを自動設定するので、`dnsmasq`による割り当ては行われません。 +しかし、DHCPv4 を使用しているインスタンスは、SLAAC IPv6 アドレスに相当する AAAA の DNS レコードも取得します。 +これは、インスタンスが IPv6 アドレスを生成する際に、IPv6 プライバシー拡張を使用していないことを前提としています。 -In this default configuration, whilst DNS names cannot not be spoofed, the instance is connected to an Ethernet bridge and can transmit any layer 2 traffic that it wishes, which means an instance that is not trusted can effectively do MAC or IP spoofing on the bridge. +このデフォルト構成では、DNS 名を偽装することはできませんが、インスタンスはイーサネットブリッジに接続されており、希望するレイヤー2 トラフィックを送信することができます。これは、信頼されていないインスタンスがブリッジ上で MAC または IP の偽装を効果的に行うことができることを意味します。 -In the default configuration, it is also possible for instances connected to the bridge to modify the Incus host's IPv6 routing table by sending (potentially malicious) IPv6 router advertisements to the bridge. -This is because the `incusbr0` interface is created with `/proc/sys/net/ipv6/conf/incusbr0/accept_ra` set to `2`, meaning that the Incus host will accept router advertisements even though `forwarding` is enabled (see [`/proc/sys/net/ipv4/*` Variables](https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt) for more information). +デフォルトの設定では、ブリッジに接続されたインスタンスがブリッジに（潜在的に悪意のある）IPv6 ルータ広告を送信することで、Incus ホストの IPv6 ルーティングテーブルを修正することも可能です。 +これは、`incusbr0`インターフェースが`/proc/sys/net/ipv6/conf/incusbr0/accept_ra`を`2`に設定して作成されているためで、`forwarding`が有効であるにもかかわらず、Incus ホストがルーター広告を受け入れることを意味しています（詳細は[`/proc/sys/net/ipv4/*` Variables](https://www.kernel.org/doc/Documentation/networking/ip-sysctl.txt)を参照してください）。 -However, Incus offers several bridged {abbr}`NIC (Network interface controller)` security features that can be used to control the type of traffic that an instance is allowed to send onto the network. -These NIC settings should be added to the profile that the instance is using, or they can be added to individual instances, as shown below. +しかし、Incus はいくつかのブリッジ型{abbr}`NIC(Network interface controller)`セキュリティー機能を提供しており、インスタンスがネットワーク上に送信することを許可されるトラフィックの種類を制御するために使用することができます。 +これらの NIC 設定は、インスタンスが使用しているプロファイルに追加する必要がありますが、以下のように個々のインスタンスに追加することもできます。 -The following security features are available for bridged NICs: +ブリッジ型 NIC には、以下のようなセキュリティー機能があります: -Key | Type | Default | Required | Description -:-- | :-- | :-- | :-- | :-- -`security.mac_filtering` | bool | `false` | no | Prevent the instance from spoofing another instance's MAC address -`security.ipv4_filtering`| bool | `false` | no | Prevent the instance from spoofing another instance's IPv4 address (enables `mac_filtering`) -`security.ipv6_filtering`| bool | `false` | no | Prevent the instance from spoofing another instance's IPv6 address (enables `mac_filtering`) +キー | タイプ | デフォルト | 必須 | 説明 +:-- | :-- | :-- | :-- | :-- +`security.mac_filtering` | bool | `false` | no | インスタンスが他のインスタンスの MAC アドレスを詐称することを防ぐ。 +`security.ipv4_filtering` | bool | `false` | no | インスタンスが他のインスタンスの IPv4 アドレスになりすますことを防ぎます(`mac_filtering` を有効にします)。 +`security.ipv6_filtering` | bool | `false` | no | インスタンスが他のインスタンスの IPv6 アドレスになりすますことを防ぎます(`mac_filtering` を有効にします)。 -One can override the default bridged NIC settings from the profile on a per-instance basis using: +プロファイルで設定されたデフォルトのブリッジ型 NIC の設定は、インスタンスごとに以下の方法で上書きすることができます: ``` incus config device override security.mac_filtering=true ``` -Used together, these features can prevent an instance connected to a bridge from spoofing MAC and IP addresses. -These options are implemented using either `xtables` (`iptables`, `ip6tables` and `ebtables`) or `nftables`, depending on what is available on the host. +これらの機能を併用することで、ブリッジに接続されているインスタンスが MAC アドレスや IP アドレスを詐称することを防ぐことができます。 +これらのオプションは、ホスト上で利用可能なものに応じて、`xtables`（`iptables`、`ip6tables`、`ebtables`）または`nftables`を使用して実装されます。 -It's worth noting that those options effectively prevent nested containers from using the parent network with a different MAC address (i.e using bridged or `macvlan` NICs). +これらのオプションは、ネストされたコンテナが異なる MAC アドレスを持つ親ネットワークを使用すること（ブリッジされた NIC や`macvlan` NIC を使用すること）を効果的に防止することができるのは注目に値します。 -The IP filtering features block ARP and NDP advertisements that contain a spoofed IP, as well as blocking any packets that contain a spoofed source address. +IP フィルタリング機能は、スプーフィングされた IP を含む ARP および NDP アドバタイジングをブロックし、スプーフィングされたソースアドレスを含むすべてのパケットをブロックします。 -If `security.ipv4_filtering` or `security.ipv6_filtering` is enabled and the instance cannot be allocated an IP address (because `ipvX.address=none` or there is no DHCP service enabled on the bridge), then all IP traffic for that protocol is blocked from the instance. +`security.ipv4_filtering`または`security.ipv6_filtering`が有効で、（`ipvX.address=none`またはブリッジで DHCP サービスが有効になっていないため）インスタンスに IP アドレスが割り当てられない場合、そのプロトコルのすべての IP トラフィックがインスタンスからブロックされます。 -When `security.ipv6_filtering` is enabled, IPv6 router advertisements are blocked from the instance. +`security.ipv6_filtering` が有効な場合、IPv6 のルータ広告がインスタンスからブロックされます。 -When `security.ipv4_filtering` or `security.ipv6_filtering` is enabled, any Ethernet frames that are not ARP, IPv4 or IPv6 are dropped. -This prevents stacked VLAN Q-in-Q (802.1ad) frames from bypassing the IP filtering. +`security.ipv4_filtering`または`security.ipv6_filtering`が有効な場合、ARP、IPv4 または IPv6 ではないイーサネットフレームはすべてドロップされます。 +これにより、スタックされた VLAN `Q-in-Q`（802.1ad）フレームが IP フィルタリングをバイパスすることを防ぎます。 -### Routed NIC security +### ルート化されたNICのセキュリティー -An alternative networking mode is available called "routed". -It provides a virtual Ethernet device pair between container and host. -In this networking mode, the Incus host functions as a router, and static routes are added to the host directing traffic for the container's IPs towards the container's `veth` interface. +"routed" と呼ばれる別のネットワークモードがあります。 +このモードでは、コンテナとホストの間に仮想イーサネットデバイペアを提供します。 +このネットワークモードでは、Incus ホストがルータとして機能し、コンテナの IP 宛のトラフィックをコンテナの`veth`インターフェースに誘導するスタティックルートがホストに追加されます。 -By default, the `veth` interface created on the host has its `accept_ra` setting disabled to prevent router advertisements from the container modifying the IPv6 routing table on the Incus host. -In addition to that, the `rp_filter` on the host is set to `1` to prevent source address spoofing for IPs that the host does not know the container has. +デフォルトでは、コンテナからのルータ広告が Incus ホスト上の IPv6 ルーティングテーブルを変更するのを防ぐために、ホスト上に作成された`veth`インターフェースは、その`accept_ra`設定が無効になっています。 +それに加えて、コンテナが持っていることをホストが知らない IP に対するソースアドレスの偽装を防ぐために、ホスト上の`rp_filter`が`1`に設定されています。 diff --git a/doc/explanation/storage.md b/doc/explanation/storage.md index a089f0cd4f8..5f4eab80a84 100644 --- a/doc/explanation/storage.md +++ b/doc/explanation/storage.md @@ -1,22 +1,22 @@ (exp-storage)= -# About storage pools, volumes and buckets +# ストレージプール、ボリューム、バケットについて -Incus stores its data in storage pools, divided into storage volumes of different content types (like images or instances). -You could think of a storage pool as the disk that is used to store data, while storage volumes are different partitions on this disk that are used for specific purposes. +Incus はデータを（イメージやインスタンスのように）コンテントタイプに応じて別のストレージボリュームに分けてストレージプールに保管します。 +ストレージプールはデータを保管するためのディスクであり、ストレージボリュームは特定の目的に使用されるディスク上の別々のパーティションであると考えることも出来るでしょう。 -In addition to storage volumes, there are storage buckets, which use the [Amazon {abbr}`S3 (Simple Storage Service)`](https://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html) protocol. -Like storage volumes, storage buckets are part of a storage pool. +ストレージボリュームに加えて、ストレージバケットというものもあります。これは [Amazon {abbr}`S3 (Simple Storage Service)`](https://docs.aws.amazon.com/AmazonS3/latest/API/Welcome.html) プロトコルを使用します。 +ストレージボリュームと同様に、ストレージバケットはストレージプールの一部です。 (storage-pools)= -## Storage pools +## ストレージプール -During initialization, Incus prompts you to create a first storage pool. -If required, you can create additional storage pools later (see {ref}`storage-create-pool`). +初期化時に、 Incus は最初のストレージプールを作成するためのプロンプトを表示します。 +必要であれば、後からストレージプールを追加できます（{ref}`storage-create-pool` 参照）。 -Each storage pool uses a storage driver. -The following storage drivers are supported: +それぞれのストレージプールはストレージドライバーを使用します。 +次のストレージドライバーが利用できます。 -- [Directory - `dir`](storage-dir) +- [ディレクトリ - `dir`](storage-dir) - [Btrfs - `btrfs`](storage-btrfs) - [LVM - `lvm`](storage-lvm) - [ZFS - `zfs`](storage-zfs) @@ -24,68 +24,68 @@ The following storage drivers are supported: - [CephFS - `cephfs`](storage-cephfs) - [Ceph Object - `cephobject`](storage-cephobject) -See the following how-to guides for additional information: +さらなる情報については以下の how-to ガイドを参照してください: - {ref}`howto-storage-pools` - {ref}`howto-storage-create-instance` (storage-location)= -### Data storage location +### データストレージのロケーション -Where the Incus data is stored depends on the configuration and the selected storage driver. -Depending on the storage driver that is used, Incus can either share the file system with its host or keep its data separate. +Incus のデータをどこに保管するかは設定と選択したストレージドライバーによって異なります。 +使用されるストレージドライバーによって、 Incus はファイルシステムをホストと共有することもできますし、データを別にしておくこともできます。 -Storage location | Directory | Btrfs | LVM | ZFS | Ceph (all) | -:--- | :-: | :-: | :-: | :-: | :-: | -Shared with the host | ✓ | ✓ | - | ✓ | - | -Dedicated disk/partition | - | ✓ | ✓ | ✓ | - | -Loop disk | - | ✓ | ✓ | ✓ | - | -Remote storage | - | - | - | - | ✓ | +ストレージロケーション | Directory | Btrfs | LVM | ZFS | Ceph (すべて) | +:--- | :-: | :-: | :-: | :-: | :-: | +ホストと共有 | ✓ | ✓ | - | ✓ | - | +専用のディスク/パーティション | - | ✓ | ✓ | ✓ | - | +ループディスク | - | ✓ | ✓ | ✓ | - | +リモートストレージ | - | - | - | - | ✓ | -#### Shared with the host +#### ホストと共有 -Sharing the file system with the host is usually the most space-efficient way to run Incus. -In most cases, it is also the easiest to manage. +ファイルシステムをホストと共有するのは Incus を実行する上で通常もっとも空間効率が良い方法です。 +ほとんどの場合、もっとも管理が楽な方法でもあります。 -This option is supported for the `dir` driver, the `btrfs` driver (if the host is Btrfs and you point Incus to a dedicated sub-volume) and the `zfs` driver (if the host is ZFS and you point Incus to a dedicated dataset on your zpool). +この選択肢は `dir` ドライバー、 `btrfs` ドライバー（ホストが Btrfs で Incus に専用のサブボリュームを使用する場合）、 `zfs` ドライバー（ホストが ZFS で zpool 上で Incus に専用のデータセットを使用する場合）でサポートされます。 -#### Dedicated disk or partition +#### 専用のディスクかパーティションか -Having Incus use an empty partition on your main disk or a full dedicated disk keeps its storage completely independent from the host. +メインのディスク上で Incus に空のパーティションを使用するか、ホストから完全に独立したストレージを保管する完全な専用のディスクを使用します。 -This option is supported for the `btrfs` driver, the `lvm` driver and the `zfs` driver. +この選択肢は `btrfs` ドライバー、 `lvm` ドライバー、 `zfs` ドライバーでサポートされます。 -#### Loop disk +#### ループディスク -Incus can create a loop file on your main drive and have the selected storage driver use that. -This method is functionally similar to using a disk or partition, but it uses a large file on your main drive instead. -This means that every write must go through the storage driver and your main drive's file system, which leads to decreased performance. +Incus ではメインドライブ上にループファイルを作成して選択したストレージドライバーでそれを使用できます。 +この方法はディスクやパーティションを使用する方法と機能的には似ていますが、大きな 1 つのファイルをメインドライブとして使用する点が異なります。 +これはそれぞれの書き込みがストレージドライバーとメインドライブのファイルシステムを通過することを意味し、パフォーマンスは低くなります。 -The loop files reside in `/var/lib/incus/disks/`. +ループファイルは `/var/lib/incus/disks/` に作られます。 -Loop files usually cannot be shrunk. -They will grow up to the configured limit, but deleting instances or images will not cause the file to shrink. -You can increase their size though; see {ref}`storage-resize-pool`. +ループファイルは通常縮小できません。 +最大で指定した限界まで拡大しますが、インスタンスやイメージを削除してもファイルが縮小することはありません。 +しかしサイズを増やすことはできます。 {ref}`storage-resize-pool` を参照してください。 -#### Remote storage +#### リモートストレージ -The `ceph`, `cephfs` and `cephobject` drivers store the data in a completely independent Ceph storage cluster that must be set up separately. +`ceph`, `cephfs`, `cephobject` ドライバーはデータを完全に独立な Ceph ストレージクラスタに保管します。これは別途セットアップが必要です。 (storage-default-pool)= -### Default storage pool +### デフォルトストレージプール -There is no concept of a default storage pool in Incus. +Incus にはデフォルトストレージプールという概念はありません。 -When you create a storage volume, you must specify the storage pool to use. +ストレージボリュームを作成する時は、使用するストレージプールを指定する必要があります。 -When Incus automatically creates a storage volume during instance creation, it uses the storage pool that is configured for the instance. -This configuration can be set in either of the following ways: +インスタンスの作成時に Incus が自動的にストレージボリュームを作成する際は、インスタンスに設定されたストレージプールを使用します。 +この設定は以下のいずれかの方法でできます。 -- Directly on an instance: [`incus launch --storage `](incus_launch.md) -- Through a profile: [`incus profile device add root disk path=/ pool=`](incus_profile_device_add.md) and [`incus launch --profile `](incus_launch.md) -- Through the default profile +- 直接インスタンスに指定: [`incus launch --storage `](incus_launch.md) +- プロファイル経由: [`incus profile device add root disk path=/ pool=`](incus_profile_device_add.md) と [`incus launch --profile `](incus_launch.md) +- デフォルトプロファイル経由 -In a profile, the storage pool to use is defined by the pool for the root disk device: +プロファイルでは使用するストレージプールはルートディスクデバイスのプールで定義されます: ```yaml root: @@ -94,87 +94,87 @@ In a profile, the storage pool to use is defined by the pool for the root disk d pool: default ``` -In the default profile, this pool is set to the storage pool that was created during initialization. +デフォルトプロファイルではこのプールは (訳注: Incus の) 初期化時に作られたストレージプールに設定されています。 (storage-volumes)= -## Storage volumes +## ストレージボリューム -When you create an instance, Incus automatically creates the required storage volumes for it. -You can create additional storage volumes. +インスタンスを作成する際、 Incus は必要なストレージボリュームを自動的に作成します。 +追加のストレージボリュームを作成することもできます。 -See the following how-to guides for additional information: +さらなる情報については以下の how-to ガイドを参照してください: - {ref}`howto-storage-volumes` - {ref}`howto-storage-move-volume` - {ref}`howto-storage-backup-volume` (storage-volume-types)= -### Storage volume types +### ストレージボリュームタイプ -Storage volumes can be of the following types: +ストレージボリュームは以下の種別があります: `container`/`virtual-machine` -: Incus automatically creates one of these storage volumes when you launch an instance. - It is used as the root disk for the instance, and it is destroyed when the instance is deleted. +: Incus はインスタンスを起動する際にこのどちらかのストレージボリュームを自動的に作成します。 + それはインスタンスのルートディスクとして使用され、インスタンスが削除される際に破棄されます。 - This storage volume is created in the storage pool that is specified in the profile used when launching the instance (or the default profile, if no profile is specified). - The storage pool can be explicitly specified by providing the `--storage` flag to the launch command. + このストレージボリュームはインスタンス起動時に使用されたプロファイル（あるいはプロファイルが指定されない場合はデフォルトプロファイル）に指定されたストレージプール内に作成されます。 + 起動のコマンドに `--storage` フラグを渡してストレージプールを明示的に指定することもできます。 `image` -: Incus automatically creates one of these storage volumes when it unpacks an image to launch one or more instances from it. - You can delete it after the instance has been created. - If you do not delete it manually, it is deleted automatically ten days after it was last used to launch an instance. +: Incus はイメージから 1 つあるいは複数のインスタンスを起動するためにイメージを解凍する際にこれらのストレージボリュームを自動的に作成します。 + インスタンスが作成された後は削除できます。 + 手動で削除しない場合、インスタンス起動の 10 日後に自動的に削除されます。 - The image storage volume is created in the same storage pool as the instance storage volume, and only for storage pools that use a {ref}`storage driver ` that supports optimized image storage. + イメージのストレージボリュームはインスタンスのストレージボリュームと同じストレージプール内に作成されます。それは最適化されたイメージのストレージをサポートする {ref}`ストレージドライバー ` を使用するストレージプールだけです。 `custom` -: You can add one or more custom storage volumes to hold data that you want to store separately from your instances. - Custom storage volumes can be shared between instances, and they are retained until you delete them. +: インスタンスから分離して保管したいデータを保持する 1 つあるいは複数のカスタムストレージボリュームを追加できます。 + カスタムストレージボリュームはインスタンス間で共有でき、インスタンスが削除されても残ります。 - You can also use custom storage volumes to hold your backups or images. + バックアップやイメージを保管するためにカスタムストレージボリュームを使用することもできます。 - You must specify the storage pool for the custom volume when you create it. + カスタムボリュームの作成時は使用するストレージプールを指定する必要があります。 (storage-content-types)= -### Content types +### コンテントタイプ -Each storage volume uses one of the following content types: +それぞれのストレージボリュームは以下のコンテントタイプのどれかを使用します: `filesystem` -: This content type is used for containers and container images. - It is the default content type for custom storage volumes. +: このコンテントタイプはコンテナとコンテナイメージに使用されます。 + これはカスタムストレージボリュームのデフォルトのコンテントタイプです。 - Custom storage volumes of content type `filesystem` can be attached to both containers and virtual machines, and they can be shared between instances. + コンテントタイプが `filesystem` のカスタムストレージボリュームはコンテナと仮想マシンの両方にアタッチでき、インスタンス間で共有できます。 `block` -: This content type is used for virtual machines and virtual machine images. - You can create a custom storage volume of type `block` by using the `--type=block` flag. +: このコンテントタイプは仮想マシンと仮想マシンイメージで使用されます。 + コンテントタイプ `block` のカスタムストレージボリュームは `--type=block` フラグを使って作成できます。 - Custom storage volumes of content type `block` can only be attached to virtual machines. - They should not be shared between instances, because simultaneous access can lead to data corruption. + コンテントタイプが `block` のカスタムストレージボリュームは仮想マシンのみにアタッチできます。 + これらはインスタンス間では共有すべきではありません。同時アクセスはデータ破壊を引き起こすからです。 `iso` -: This content type is used for custom ISO volumes. - A custom storage volume of type `iso` can only be created by importing an ISO file using [`incus import`](incus_import.md). +: このコンテントタイプはカスタム ISO ボリュームで使用されます。 + コンテントタイプ `iso` のカスタムストレージボリュームは [`incus import`](incus_import.md) コマンドを使って ISO ファイルをインポートすることでのみ作成できます。 - Custom storage volumes of content type `iso` can only be attached to virtual machines. - They can be attached to multiple machines simultaneously as they are always read-only. + コンテントタイプ `iso` のカスタムストレージボリュームは仮想マシンにのみアタッチできます。 + これらは読み取り専用なので同時に複数の仮想マシンにアタッチできます。 (storage-buckets)= -## Storage buckets +## ストレージバケット -Storage buckets provide object storage functionality via the S3 protocol. +ストレージバケットは S3 プロトコルを使用してオブジェクトストレージの機能を提供します。 -They can be used in a way that is similar to custom storage volumes. -However, unlike storage volumes, storage buckets are not attached to an instance. -Instead, applications can access a storage bucket directly using its URL. +これはカスタムストレージボリュームと同様の方法で使用されます。 +しかし、ストレージボリュームとは異なり、ストレージバケットはインスタンスに紐付けされません。 +代わりに、アプリケーションはストレージバケットにその URL を使って直接アクセスできます。 -Each storage bucket is assigned one or more access keys, which the applications must use to access it. +それぞれのストレージバケットには 1 つまたは複数のアクセスキーが割り当てられ、アプリケーションはアクセスの際にこれを使う必要があります。 -Storage buckets can be located on local storage (with `dir`, `btrfs`, `lvm` or `zfs` pools) or on remote storage (with `cephobject` pools). +ストレージバケットはローカルのストレージ（`dir`, `btrfs`, `lvm` あるいは `zfs` プールの場合）あるいはリモートストレージ（`cephobject` プールの場合）上に配置できます。 -To enable storage buckets for local storage pool drivers and allow applications to access the buckets via the S3 protocol, you must configure the {config:option}`server-core:core.storage_buckets_address` server setting. +ローカルストレージドライバーでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには、{config:option}`server-core:core.storage_buckets_address` サーバー設定を調整する必要があります。 -See the following how-to guide for additional information: +さらなる情報については以下の how-to ガイドを参照してください: - {ref}`howto-storage-buckets` diff --git a/doc/external_resources.md b/doc/external_resources.md index a12612821c3..1b444c06d25 100644 --- a/doc/external_resources.md +++ b/doc/external_resources.md @@ -1,8 +1,8 @@ -# External resources +# 外部リソース ```{toctree} :maxdepth: 1 -Project repository -Image server +プロジェクトレポジトリ +イメージサーバー ``` diff --git a/doc/faq.md b/doc/faq.md index 32942b51408..269e23dfd84 100644 --- a/doc/faq.md +++ b/doc/faq.md @@ -1,111 +1,111 @@ -# Frequently asked questions +# よく聞かれる質問（FAQ） -The following sections give answers to frequently asked questions. -They explain how to resolve common issues and point you to more detailed information. +以下のセクションは、よくある質問への回答を提供します。 +それらは一般的な問題の解決方法を説明し、より詳細な情報へと導きます。 -## Why do my instances not have network access? +## なぜ私のインスタンスはネットワークアクセスがないのですか？ -Most likely, your firewall blocks network access for your instances. -See {ref}`network-bridge-firewall` for more information about the problem and how to fix it. +最も可能性が高いのは、あなたのファイアウォールがインスタンスのネットワークアクセスをブロックしているためです。 +問題とその修正方法についての詳細は {ref}`network-bridge-firewall` をご覧ください。 -Another frequent reason for connectivity issues is running Incus and Docker on the same host. -See {ref}`network-incus-docker` for instructions on how to fix such issues. +接続問題の別の一般的な原因は、Incus と Docker を同じホスト上で実行していることです。 +このような問題を修正する方法については {ref}`network-incus-docker` を参照してください。 -## How to enable the Incus server for remote access? +## Incus サーバーをリモートアクセス可能にするにはどうすればよいですか？ -By default, the Incus server is not accessible from the network, because it only listens on a local Unix socket. +デフォルトでは、 Incus サーバーはネットワークからアクセスできません。なぜなら、それはローカルの Unix ソケットでしかリッスンしていないからです。 -You can enable it for remote access by following the instructions in {ref}`server-expose`. +リモートアクセスを可能にするためには、 {ref}`server-expose` の指示に従ってください。 -## When I do a `incus remote add`, it asks for a token? +## `incus remote add`を行うと、トークンを求められるのはなぜですか？ -To be able to access the remote API, clients must authenticate with the Incus server. +リモート API にアクセスするためには、クライアントは Incus サーバーに対して認証を行わなければなりません。 -See {ref}`server-authenticate` for instructions on how to authenticate using a trust token. +トラストトークンを使用して認証する方法については {ref}`server-authenticate` を参照してください。 -## Why should I not run privileged containers? +## なぜ特権コンテナを実行すべきではないのですか？ -A privileged container can do things that affect the entire host - for example, it can use things in `/sys` to reset the network card, which will reset it for the entire host, causing network blips. -See {ref}`container-security` for more information. +特権コンテナは、ホスト全体に影響を与えることができます - たとえば、`/sys`内のものを使ってネットワークカードをリセットすると、ホスト全体のそれがリセットされ、ネットワークが一時的に断線します。 +詳細は {ref}`container-security` をご覧ください。 -Almost everything can be run in an unprivileged container, or - in cases of things that require unusual privileges, like wanting to mount NFS file systems inside the container - you might need to use bind mounts. +ほとんどのものは非特権コンテナで実行できます。また、NFS ファイルシステムをコンテナ内にマウントしたいなど、通常とは異なる特権を必要とするものの場合、バインドマウントを使用する必要があるかもしれません。 -## Can I bind-mount my home directory in a container? +## ホームディレクトリーをコンテナにバインドマウントすることはできますか？ -Yes, you can do this by using a {ref}`disk device `: +はい、それは{ref}`ディスクデバイス `を使用することで可能です: incus config device add container-name home disk source=/home/${USER} path=/home/ubuntu -For unprivileged containers, you need to make sure that the user in the container has working read/write permissions. -Otherwise, all files will show up as the overflow UID/GID (`65536:65536`) and access to anything that's not world-readable will fail. -Use either of the following methods to grant the required permissions: +非特権コンテナの場合、コンテナ内のユーザーが適切な読み書き権限を持っていることを確認する必要があります。 +そうでないと、すべてのファイルはオーバーフローUID/GID（`65536:65536`）として表示され、ワールドリーダブルでないものへのアクセスは失敗します。 +必要な権限を付与するために以下の方法のいずれかを使用してください: -- Pass `shift=true` to the [`incus config device add`](incus_config_device_add.md) call. This depends on the kernel and file system supporting either idmapped mounts or shiftfs (see [`incus info`](incus_info.md)). -- Add a `raw.idmap` entry (see [Idmaps for user namespace](userns-idmap.md)). -- Place recursive POSIX ACLs on your home directory. +- [`incus config device add`](incus_config_device_add.md)の実行時に`shift=true`を指定します。これはカーネルとファイルシステムが idmapped マウントあるいは shiftfs をサポートしているかに依存します（ [`incus info`](incus_info.md)参照）。 +- `raw.idmap`エントリを追加します（[User Namespace の Idmap](userns-idmap.md)参照）。 +- ホームディレクトリーに再帰的な POSIX ACL を配置します。 -Privileged containers do not have this issue because all UID/GID in the container are the same as outside. -But that's also the cause of most of the security issues with such privileged containers. +特権コンテナはこの問題を持っていません、なぜならコンテナ内のすべての UID/GID は外部と同じだからです。 +しかし、それが特権コンテナのセキュリティー問題のほとんどの原因でもあります。 -## How can I run Docker inside a Incus container? +## Incus コンテナの内部で Docker を実行するには？ -To run Docker inside a Incus container, set the {config:option}`instance-security:security.nesting` property of the container to `true`: +Incus コンテナの内部で Docker を実行するには、コンテナの {config:option}`instance-security:security.nesting` プロパティを `true` にセットします: incus config set security.nesting true -Note that Incus containers cannot load kernel modules, so depending on your Docker configuration, you might need to have extra kernel modules loaded by the host. -You can do so by setting a comma-separated list of kernel modules that your container needs: +Incus コンテナはカーネルモジュールをロードできないため、 Docker の設定によっては、ホストで追加のカーネルモジュールをロードする必要があるかもしれません。 +コンテナが必要とするカーネルモジュールのカンマ区切りのリストを設定することでこれを行うことができます: incus config set linux.kernel_modules -In addition, creating a `/.dockerenv` file in your container can help Docker ignore some errors it's getting due to running in a nested environment. +さらに、コンテナ内に`/.dockerenv`ファイルを作成すると、Docker がネストした環境で実行されているために発生するいくつかのエラーを無視するのに役立ちます。 -## Where does the Incus client (`incus`) store its configuration? +## Incus クライアント（`incus`）は設定をどこに保存しますか？ -The [`incus`](incus.md) command stores its configuration under `~/.config/incus`. +[`incus`](incus.md) コマンドはその設定を `~/.config/incus` に保存します。 -Various configuration files are stored in that directory, for example: +様々な設定ファイルがそのディレクトリーに保存されます。たとえば: -- `client.crt`: client certificate (generated on demand) -- `client.key`: client key (generated on demand) -- `config.yml`: configuration file (info about `remotes`, `aliases`, etc.) -- `servercerts/`: directory with server certificates belonging to `remotes` +- `client.crt`：クライアント証明書（要求に応じて生成されます） +- `client.key`：クライアントキー（要求に応じて生成されます） +- `config.yml`：設定ファイル（`remotes`、`aliases`などの情報） +- `servercerts/`：`remotes`に関連するサーバー証明書が保存されているディレクトリー -## Why can I not ping my Incus instance from another host? +## なぜ他のホストから Incus インスタンスに ping を送ることができないのですか？ -Many switches do not allow MAC address changes, and will either drop traffic with an incorrect MAC or disable the port totally. -If you can ping a Incus instance from the host, but are not able to ping it from a different host, this could be the cause. +多くのスイッチは MAC アドレスの変更を許可せず、不正な MAC を持つトラフィックをドロップするか、ポートを完全に無効にします。 +ホストから Incus インスタンスには ping を送ることができますが、異なるホストから ping を送ることができない場合、これが原因かもしれません。 -The way to diagnose this problem is to run a `tcpdump` on the uplink and you will see either ``ARP Who has `xx.xx.xx.xx` tell `yy.yy.yy.yy` ``, with you sending responses but them not getting acknowledged, or ICMP packets going in and out successfully, but never being received by the other host. +この問題を診断する方法は、アップリンク上で`tcpdump`を実行することで、``ARP Who has `xx.xx.xx.xx` tell `yy.yy.yy.yy` ``が表示され、レスポンスを送信しているにもかかわらず確認されていない、または ICMP パケットが成功裏に送受信されているにもかかわらず、他のホストには受け取られていないことを確認することです。 (faq-monitor)= -## How can I monitor what Incus is doing? +## Incusが何をしているかモニターするには？ -To see detailed information about what Incus is doing and what processes it is running, use the [`incus monitor`](incus_monitor.md) command. +Incus が何をしているかとどんなプロセスが稼働しているかについての詳細な情報を見るには、[`incus monitor`](incus_monitor.md)コマンドを使います。 -For example, to show a human-readable output of all types of messages, enter the following command: +たとえば、すべてのタイプのメッセージの出力を人間が見やすい形式で表示するには、以下のコマンドを使用します: incus monitor --pretty -See [`incus monitor --help`](incus_monitor.md) for all options, and {doc}`debugging` for more information. +すべてのオプションについては [`incus monitor --help`](incus_monitor.md) を、より詳しい情報は {doc}`debugging` を参照してください。 -## Why does Incus stall when creating an instance? +## インスタンス作成時に Incus が止まってしまうのはなぜですか？ -Check if your storage pool is out of space (by running [`incus storage info `](incus_storage_info.md)). -In that case, Incus cannot finish unpacking the image, and the instance that you're trying to create shows up as stopped. +ストレージプールの空きが無くなってないか（`incus storage info `を実行して）確認してください。 +空きが無い場合、 Incus はイメージの展開ができず、作成しようとしているインスタンスは止まったままに見えます。 -To get more insight into what is happening, run [`incus monitor`](incus_monitor.md) (see {ref}`faq-monitor`), and check `sudo dmesg` for any I/O errors. +何が起きているかをより詳しく調べるには [`incus monitor`](incus_monitor.md) を実行し（{ref}`faq-monitor`参照）、`sudo dmesg`で何か I/O エラーが起きていないか確認してください。 -## Why does starting containers suddenly fail? +## コンテナの起動が突然失敗するようになったのはなぜ？ -If starting containers suddenly fails with a cgroup-related error message (`Failed to mount "/sys/fs/cgroup"`), this might be due to running a VPN client on the host. +コンテナの起動が cgroup 関連のエラーメッセージ（`Failed to mount "/sys/fs/cgroup"`）で失敗する場合、ホスト上で VPN クライアントが稼働しているためかもしれません。 -This is a known issue for both [Mullvad VPN](https://github.com/mullvad/mullvadvpn-app/issues/3651) and [Private Internet Access VPN](https://github.com/pia-foss/desktop/issues/50), but might occur for other VPN clients as well. -The problem is that the VPN client mounts the `net_cls` cgroup1 over cgroup2 (which Incus uses). +これは [Mullvad VPN](https://github.com/mullvad/mullvadvpn-app/issues/3651) と [Private Internet Access VPN](https://github.com/pia-foss/desktop/issues/50) の両方で知られた問題ですが、他の VPN クライアントでも起きるかもしれません。 +問題は VPN クライアントが（Incus が使用する）cgroiup2 上に `net_cls` cgroup1 をマウントすることです。 -The easiest fix for this problem is to stop the VPN client and unmount the `net_cls` cgroup1 with the following command: +この問題の一番簡単な修正方法は VPN クライアントを停止し、以下のコマンドで `net_cls` cgroup1 をアンマウントすることです: umount /sys/fs/cgroup/net_cls -If you need to keep the VPN client running, mount the `net_cls` cgroup1 in another location and reconfigure your VPN client accordingly. -See [this Discourse post](https://discuss.linuxcontainers.org/t/help-help-help-cgroup2-related-issue-on-ubuntu-jammy-with-mullvad-and-privateinternetaccess-vpn/14705/18) for instructions for Mullvad VPN. +VPN クライアントを稼働したままにする必要がある場合、 `net_cls` cgroup1 を他の場所にマウントし、 VPN クライアントを適宜再設定してください。 +Mullvad VPN 用の手順は [この Discourse の投稿](https://discuss.linuxcontainers.org/t/help-help-help-cgroup2-related-issue-on-ubuntu-jammy-with-mullvad-and-privateinternetaccess-vpn/14705/18) を参照してください。 diff --git a/doc/general.md b/doc/general.md index 63c721089e8..5216075c925 100644 --- a/doc/general.md +++ b/doc/general.md @@ -1,18 +1,18 @@ -# General +# 概要 -See the following sections for information on how to get started with Incus: +どのように Incus を使い始めるかについての情報は以下のセクションを参照してください。 ```{toctree} :maxdepth: 1 -Containers and VMs -Install Incus -Initialize Incus -Get support -Frequently asked -Contribute to Incus +コンテナと仮想マシン +Incusのインストール +Incusの初期化 +サポートを受ける +よく聞かれる質問 +Incusへのコントリビュート ``` -You can find a series of demos and tutorials on YouTube: +YouTube に一連のデモとチュートリアルがあります。 diff --git a/doc/howto/benchmark_performance.md b/doc/howto/benchmark_performance.md index 976b62f395d..65fc3d80303 100644 --- a/doc/howto/benchmark_performance.md +++ b/doc/howto/benchmark_performance.md @@ -1,96 +1,96 @@ (benchmark-performance)= -# How to benchmark performance +# パフォーマンスをベンチマークするには -The performance of your Incus server or cluster depends on a lot of different factors, ranging from the hardware, the server configuration, the selected storage driver and the network bandwidth to the overall usage patterns. +Incus サーバーあるいはクラスタのパフォーマンスは、ハードウェア、サーバー設定、選択されたストレージドライバー、ネットワーク帯域幅から全体的な利用パターンに至るまでの多数の異なる因子によって変わります。 -To find the optimal configuration, you should run benchmark tests to evaluate different setups. +最適な設定を見つけるには、異なるセットアップを評価するためベンチマークテストを実行するほうが良いです。 -Incus provides a benchmarking tool for this purpose. -This tool allows you to initialize or launch a number of containers and measure the time it takes for the system to create the containers. -If you run this tool repeatedly with different configurations, you can compare the performance and evaluate which is the ideal configuration. +Incus ではこの目的のためベンチマークツールを提供しています。 +このツールを使って複数のコンテナを初期化・起動し、システムがコンテナを作成するのに必要な時間を計測できます。 +異なる Incus の設定、システム設定、さらにはハードウェア構成に対して繰り返しツールを実行することで、パフォーマンスを比較し、どの設定が理想的か評価できます。 -## Get the tool +## ツールを取得する -If the `incus-benchmark` tool isn't provided with your installation, you can build it from source. -Make sure that you have `go` (version 1.20 or later) installed and install the tool with the following command: +あなたのインストールに`incus-benchmark`が存在しない場合は、ソースからビルドできます。 +`go`（バージョン 1.20 以降）がインストールされていることを確認の上、以下のコマンドでツールをインストールしてください: go install github.com/lxc/incus/incus-benchmark@latest -## Run the tool +## ツールを実行する -Run `incus-benchmark [action]` to measure the performance of your Incus setup. +あなたの Incus 環境のパフォーマンスを計測するには`incus-benchmark [action]`を実行してください。 -The benchmarking tool uses the current Incus configuration. -If you want to use a different project, specify it with `--project`. +ベンチマークは現在の Incus 設定を使用します。 +別のプロジェクトを使用したい場合は、`--project`で指定してください。 -For all actions, you can specify the number of parallel threads to use (default is to use a dynamic batch size). -You can also choose to append the results to a CSV report file and label them in a certain way. +すべてのアクションについて、使用する並列スレッド数 (デフォルトはダイナミックなバッチサイズを使用) を指定できます。 +また結果を CSV のレポートファイルに追加し、一定の方法でラベル付けすることもできます。 -See `incus-benchmark help` for all available actions and flags. +利用可能なアクションとフラグについては`incus-benchmark help`を参照してください。 -### Select an image +### イメージを選択する -Before you run the benchmark, select what kind of image you want to use. +ベンチマークを実行する前に、使用したいイメージの種別を選んでください。 -Local image -: If you want to measure the time it takes to create a container and ignore the time it takes to download the image, you should copy the image to your local image store before you run the benchmarking tool. +ローカルイメージ +: コンテナの作成にかかる時間を計測し、イメージをダウンロードするのにかかる時間を無視したい場合は、ベンチマークツールを実行する前にイメージをローカルのイメージストアにコピーするのが良いです。 - To do so, run a command similar to the following and specify the fingerprint (for example, `2d21da400963`) of the image when you run `incus-benchmark`: + そうするには、以下のようなコマンドを実行し、`lxd.benchmark`の実行時にはイメージのフィンガープリント（たとえば`2d21da400963`）を指定します: incus image copy images:ubuntu/22.04 local: - You can also assign an alias to the image and specify that alias (for example, `ubuntu`) when you run `incus-benchmark`: + またイメージにエイリアスを割り当てて、`incus-benchmark`の実行時にエイリアス (たとえば`ubuntu`) を指定することもできます: incus image copy images:ubuntu/22.04 local: --alias ubuntu -Remote image -: If you want to include the download time in the overall result, specify a remote image (for example, `images:ubuntu/22.04`). - The default image that `incus-benchmark` uses is the latest Ubuntu image (`images:ubuntu`), so if you want to use this image, you can leave out the image name when running the tool. +リモートイメージ +: 全体の結果にダウンロード時間も含めたい場合は、リモートイメージ (たとえば`images:ubuntu/22.04`) を指定します。 +`incus-benchmark`が使用するデフォルトのイメージは最新の Ubuntu イメージ (`images:ubuntu`) ですので、このイメージを使用したい場合は、ツール実行時にイメージ名を省略できます。 -### Create and launch containers +### コンテナを作成、起動する -Run the following command to create a number of containers: +指定した数のコンテナを作成するには以下のコマンドを実行します: incus-benchmark init --count -Add `--privileged` to the command to create privileged containers. +特権コンテナを作成するにはコマンドに`--privileged`を追加します。 -For example: +例: ```{list-table} :header-rows: 1 -* - Command - - Description +* - コマンド + - 説明 * - `incus-benchmark init --count 10 --privileged` - - Create ten privileged containers that use the latest Ubuntu image. + - 最新の Ubuntu イメージを使用して 10 個の特権コンテナを作成する。 * - `incus-benchmark init --count 20 --parallel 4 images:alpine/edge` - - Create 20 containers that use the Alpine Edge image, using four parallel threads. + - Alpine Edge イメージを使用する 20 個のコンテナを 4 つのパラレルスレッドを使用して作成する。 * - `incus-benchmark init 2d21da400963` - - Create one container that uses the local image with the fingerprint `2d21da400963`. + - フィンガープリントが`2d21da400963`のローカルイメージを使用して 1 個のコンテナを作成する。 * - `incus-benchmark init --count 10 ubuntu` - - Create ten containers that use the image with the alias `ubuntu`. + - `ubuntu`のエイリアスを設定されたイメージを使用して 10 個のコンテナを作成する。 ``` -If you use the `init` action, the benchmarking containers are created but not started. -To start the containers that you created, run the following command: +`init`アクションを使用するとコンテナを作成するが起動はせずにベンチマークを実行します。 +作成したコンテナを起動するには、以下のコマンドを実行します: incus-benchmark start -Alternatively, use the `launch` action to both create and start the containers: +あるいは`launch`アクションを使用してコンテナを作成し起動します: incus-benchmark launch --count 10 -For this action, you can add the `--freeze` flag to freeze each container right after it starts. -Freezing a container pauses its processes, so this flag allows you to measure the pure launch times without interference of the processes that run in each container after startup. +このアクションでは、`--freeze`フラグを追加するとコンテナの起動直後に凍結できます。 +コンテナを凍結するとプロセスは一時停止しますので、このフラグは各コンテナ内でプロセスが起動後に干渉するのを回避して純粋な起動時間を計測できます。 -### Delete containers +### コンテナを削除する -To delete the benchmarking containers that you created, run the following command: +作成したベンチマーク用のコンテナを削除するには、以下のコマンドを実行します: incus-benchmark delete ```{note} -You must delete all existing benchmarking containers before you can run a new benchmark. +新しいベンチマークを実行する前には既存のベンチマーク用コンテナを全て削除する必要があります。 ``` diff --git a/doc/howto/cluster_config_networks.md b/doc/howto/cluster_config_networks.md index 319c21f0869..19380e08300 100644 --- a/doc/howto/cluster_config_networks.md +++ b/doc/howto/cluster_config_networks.md @@ -1,54 +1,54 @@ (cluster-config-networks)= -# How to configure networks for a cluster +# クラスタのネットワークを設定するには -All members of a cluster must have identical networks defined. -The only configuration keys that may differ between networks on different members are [`bridge.external_interfaces`](network-bridge-options), [`parent`](network-external), [`bgp.ipv4.nexthop`](network-bridge-options) and [`bgp.ipv6.nexthop`](network-bridge-options). -See {ref}`clustering-member-config` for more information. +クラスタのすべてのメンバーは同一のネットワーク設定を持つ必要があります。 +メンバーごとに異なってもよい設定は [`bridge.external_interfaces`](network-bridge-options)、[`parent`](network-external)、[`bgp.ipv4.nexthop`](network-bridge-options) と [`bgp.ipv6.nexthop`](network-bridge-options) だけです。 +詳細は {ref}`clustering-member-config` を参照してください。 -Creating additional networks is a two-step process: +追加のネットワークを作成する際は以下の 2 ステップで行います: -1. Define and configure the new network across all cluster members. - For example, for a cluster that has three members: +1. すべてのクラスタメンバー上で新しいネットワークを定義し設定します。 + たとえば、3 つのメンバーを持つクラスタでは以下のようにします: incus network create --target server1 my-network incus network create --target server2 my-network incus network create --target server3 my-network ```{note} - You can pass only the member-specific configuration keys `bridge.external_interfaces`, `parent`, `bgp.ipv4.nexthop` and `bgp.ipv6.nexthop`. - Passing other configuration keys results in an error. + メンバー固有の設定キーは `bridge.external_interfaces`、`parent`、`bgp.ipv4.nexthop` と `bgp.ipv6.nexthop` だけを渡せます。 + 他の設定キーを渡すとエラーになります。 ``` - These commands define the network, but they don't create it. - If you run [`incus network list`](incus_network_list.md), you can see that the network is marked as "pending". -1. Run the following command to instantiate the network on all cluster members: + これらのコマンドはネットワークを定義しますが作成はしません。 + [`incus network list`](incus_network_list.md) を実行するとこのネットワークは "pending" と表示されます。 +1. すべてのクラスタメンバーでネットワークを実在化させるには以下のコマンドを実行します: incus network create my-network ```{note} - You can add configuration keys that are not member-specific to this command. + このコマンドにメンバー固有ではない設定キーを追加できます。 ``` - If you missed a cluster member when defining the network, or if a cluster member is down, you get an error. + ネットワークを定義した際のクラスタメンバーがいない、あるいはクラスタメンバーがダウンしている場合はエラーになります。 -Also see {ref}`network-create-cluster`. +{ref}`network-create-cluster` も参照してください。 (cluster-https-address)= -## Separate REST API and clustering networks +## 個別の REST API とクラスタネットワーク -You can configure different networks for the REST API endpoint of your clients and for internal traffic between the members of your cluster. -This separation can be useful, for example, to use a virtual address for your REST API, with DNS round robin. +クライアントの REST API エンドポイント用とクラスタメンバー間の内部トラフィック用で別のネットワークを設定できます。 +たとえば、DNS ラウンドロビンで REST API に仮想アドレスを使う場合にこの分離は役立ちます。 -To do so, you must specify different addresses for {config:option}`server-cluster:cluster.https_address` (the address for internal cluster traffic) and {config:option}`server-core:core.https_address` (the address for the REST API): +そうするためには、{config:option}`server-cluster:cluster.https_address`（クラスタ内部トラフィック用のアドレス）と {config:option}`server-core:core.https_address`（REST API のアドレス）に異なるアドレスを指定する必要があります: -1. Create your cluster as usual, and make sure to use the address that you want to use for internal cluster traffic as the cluster address. - This address is set as the `cluster.https_address` configuration. -1. After joining your members, set the `core.https_address` configuration to the address for the REST API. - For example: +1. 通常通りクラスタを作成し、クラスタ内部トラフィックに使うクラスタのアドレスを忘れずに使用する。 + このアドレスは `cluster.https_address` で設定します。 +1. メンバーがジョインした後、 REST API のアドレスを `core.https_address` で設定する。 + たとえば: incus config set core.https_address 0.0.0.0:8443 ```{note} - `core.https_address` is specific to the cluster member, so you can use different addresses on different members. - You can also use a wildcard address to make the member listen on multiple interfaces. + `core.https_address` はクラスタメンバーに固有ですので、異なるメンバーに異なるアドレスを設定できます。 + メンバーに複数のインターフェースでリッスンするようにワイルドカードアドレスを使用することもできます。 ``` diff --git a/doc/howto/cluster_config_storage.md b/doc/howto/cluster_config_storage.md index 7461426b294..4904486ef9e 100644 --- a/doc/howto/cluster_config_storage.md +++ b/doc/howto/cluster_config_storage.md @@ -1,69 +1,69 @@ (cluster-config-storage)= -# How to configure storage for a cluster +# クラスタのストレージを設定するには -All members of a cluster must have identical storage pools. -The only configuration keys that may differ between pools on different members are [`source`](storage-drivers), [`size`](storage-drivers), [`zfs.pool_name`](storage-zfs-pool-config), [`lvm.thinpool_name`](storage-lvm-pool-config) and [`lvm.vg_name`](storage-lvm-pool-config). -See {ref}`clustering-member-config` for more information. +クラスタのすべてのメンバーは同一のストレージプール設定を持つ必要があります。 +メンバーごとに異なる設定が可能なのは [`source`](storage-drivers)、[`size`](storage-drivers)、[`zfs.pool_name`](storage-zfs-pool-config)、[`lvm.thinpool_name`](storage-lvm-pool-config) と [`lvm.vg_name`](storage-lvm-pool-config) だけです。 +詳細は {ref}`clustering-member-config` を参照してください。 -Incus creates a default `local` storage pool for each cluster member during initialization. +Incus は初期化時にデフォルトの `local` ストレージプールを各クラスタメンバーに作成します。 -Creating additional storage pools is a two-step process: +追加のストレージプールを作成するのは以下の 2 ステップで行います: -1. Define and configure the new storage pool across all cluster members. - For example, for a cluster that has three members: +1. すべてのクラスタメンバーで新しいストレージプールを定義し設定します。 + たとえば、 3 つのメンバーを持つクラスタでは以下のようにします: incus storage create --target server1 data zfs source=/dev/vdb1 incus storage create --target server2 data zfs source=/dev/vdc1 incus storage create --target server3 data zfs source=/dev/vdb1 size=10GiB ```{note} - You can pass only the member-specific configuration keys `source`, `size`, `zfs.pool_name`, `lvm.thinpool_name` and `lvm.vg_name`. - Passing other configuration keys results in an error. + メンバー固有の設定キーは `source`、`size`、`zfs.pool_name`、`lvm.thinpool_name` と `lvm.vg_name` だけを渡せます。 + 他の設定キーを渡すとエラーになります。 ``` - These commands define the storage pool, but they don't create it. - If you run [`incus storage list`](incus_storage_list.md), you can see that the pool is marked as "pending". -1. Run the following command to instantiate the storage pool on all cluster members: + これらのコマンドはストレージプールを定義しますが作成はしません。 + [`incus storage list`](incus_storage_list.md) を実行するとこのストレージプールは "pending" と表示されます。 +1. すべてのクラスタメンバーでストレージプールを実在化させるには以下のコマンドを実行します: incus storage create data zfs ```{note} - You can add configuration keys that are not member-specific to this command. + このコマンドにメンバー固有ではない設定キーを追加できます。 ``` - If you missed a cluster member when defining the storage pool, or if a cluster member is down, you get an error. + ストレージプールを定義した際のクラスタメンバーがいない、あるいはクラスタメンバーがダウンしている場合はエラーになります。 -Also see {ref}`storage-pools-cluster`. +{ref}`storage-pools-cluster` も参照してください。 -## View member-specific pool configuration +## メンバー固有のプール設定を参照する -Running [`incus storage show `](incus_storage_show.md) shows the cluster-wide configuration of the storage pool. +ストレージプールのクラスタ全体の設定を表示するには [`incus storage show `](incus_storage_show.md) を実行します。 -To view the member-specific configuration, use the `--target` flag. -For example: +メンバー固有の設定を参照するには `--target` フラグを使用してください。 +たとえば: incus storage show data --target server2 -## Create storage volumes +## ストレージボリュームを作成する -For most storage drivers (all except for Ceph-based storage drivers), storage volumes are not replicated across the cluster and exist only on the member for which they were created. -Run [`incus storage volume list `](incus_storage_volume_list.md) to see on which member a certain volume is located. +ほとんどのストレージドライバー（Ceph ベースのストレージドライバーを除いて）、ストレージボリュームはクラスタ内で複製されず、ストレージを作成したメンバー上にのみ存在します。 +特定のボリュームがどのメンバー上にあるのかを見るには [`incus storage volume list `](incus_storage_volume_list.md) を実行してください。 -When creating a storage volume, use the `--target` flag to create a storage volume on a specific cluster member. -Without the flag, the volume is created on the cluster member on which you run the command. -For example, to create a volume on the current cluster member `server1`: +ストレージボリュームを作成する際に `--target` フラグを使用すると特定のクラスタメンバー上にストレージボリュームを作成できます。 +フラグを指定しない場合、ボリュームはコマンドを実行したクラスタメンバー上に作成されます。 +たとえば、 `server1` というクラスタメンバー上でボリュームを作成するには以下のようにします: incus storage volume create local vol1 -To create a volume with the same name on another cluster member: +他のクラスタメンバー上で同じ名前のボリュームを作成するには以下のようにします: incus storage volume create local vol1 --target server2 -Different volumes can have the same name as long as they live on different cluster members. -Typical examples for this are image volumes. +別のボリュームも別のクラスタメンバー上にある限り同じ名前を持つことができます。 +典型的な例はイメージボリュームです。 -You can manage storage volumes in a cluster in the same way as you do in non-clustered deployments, except that you must pass the `--target` flag to your commands if more than one cluster member has a volume with the given name. -For example, to show information about the storage volumes: +クラスタ内のストレージボリュームは、指定した名前のボリュームを複数のクラスタメンバーが持つ場合は `--target` フラグを指定する必要があるという点を除けば、クラスタではない Incus 環境と同じように管理できます。 +たとえば、ストレージボリュームの情報を表示するには以下のようにします: incus storage volume show local vol1 --target server1 incus storage volume show local vol1 --target server2 diff --git a/doc/howto/cluster_form.md b/doc/howto/cluster_form.md index 758c075dae6..70d9d4984f3 100644 --- a/doc/howto/cluster_form.md +++ b/doc/howto/cluster_form.md @@ -1,41 +1,41 @@ (cluster-form)= -# How to form a cluster +# クラスタを形成するには -When forming a Incus cluster, you start with a bootstrap server. -This bootstrap server can be an existing Incus server or a newly installed one. +Incus クラスタを形成するときはブートストラップサーバーから始めます。 +このブートストラップサーバーは既存の Incus サーバーでもよいですし新しくインストールしたものでもよいです。 -After initializing the bootstrap server, you can join additional servers to the cluster. -See {ref}`clustering-members` for more information. +ブートストラップサーバーを初期化した後、クラスタに追加のサーバーをジョインできます。 +詳細は {ref}`clustering-members` を参照してください。 -You can form the Incus cluster interactively by providing configuration information during the initialization process or by using preseed files that contain the full configuration. +Incus クラスタを形成するために初期化プロセス中に設定をインタラクティブに指定することもできますし、完全な設定を含むプリシードファイルを使うこともできます。 -To quickly and automatically set up a basic Incus cluster, you can use MicroCloud. -Note, however, that this project is still in an early phase. +素早く自動的にベーシックな Incus クラスタをセットアップするには MicroCloud が使えます。 +ただし、このプロジェクトはまだ初期段階なことに注意してください。 -## Configure the cluster interactively +## クラスタをインタラクティブに設定する -To form your cluster, you must first run `incus admin init` on the bootstrap server. After that, run it on the other servers that you want to join to the cluster. +クラスタを形成するには、まずブートストラップサーバー上で `incus admin init` を実行する必要があります。その後クラスタにジョインさせたい他のサーバー上でもそのコマンドを実行します。 -When forming a cluster interactively, you answer the questions that `incus admin init` prompts you with to configure the cluster. +クラスタをインタラクティブに形成する際、クラスタを設定するために `incus admin init` のプロンプトの質問に回答します。 -### Initialize the bootstrap server +### ブートストラップサーバーを初期化する -To initialize the bootstrap server, run `incus admin init` and answer the questions according to your desired configuration. +ブートストラップサーバーを初期化するには、 `incus admin init` を実行して希望の設定に応じて質問に回答します。 -You can accept the default values for most questions, but make sure to answer the following questions accordingly: +ほとんどの質問はデフォルト値を受け入れることができますが、以下の質問には適切に答えるようにしてください: - `Would you like to use Incus clustering?` - Select **yes**. + **yes** を選択。 - `What IP address or DNS name should be used to reach this server?` - Make sure to use an IP or DNS address that other servers can reach. + 他のサーバーがアクセスできる IP または DNS のアドレスを確実に使用してください。 - `Are you joining an existing cluster?` - Select **no**. + **no** を選択。
-Expand to see a full example for incus admin init on the bootstrap server +ブートストラップ上での incus admin init の完全な例を見るには展開してください ```{terminal} :input: incus admin init @@ -44,7 +44,6 @@ Would you like to use Incus clustering? (yes/no) [default=no]: yes What IP address or DNS name should be used to reach this server? [default=192.0.2.101]: Are you joining an existing cluster? (yes/no) [default=no]: no What member name should be used to identify this server in the cluster? [default=server1]: -Setup password authentication on the cluster? (yes/no) [default=no]: no Do you want to configure a new local storage pool? (yes/no) [default=yes]: Name of the storage backend to use (btrfs, dir, lvm, zfs) [default=zfs]: Create a new ZFS pool? (yes/no) [default=yes]: @@ -58,69 +57,69 @@ Would you like a YAML "incus admin init" preseed to be printed? (yes/no) [defaul
-After the initialization process finishes, your first cluster member should be up and available on your network. -You can check this with [`incus cluster list`](incus_cluster_list.md). +初期化プロセスが終了したら、最初のクラスタメンバーが起動してネットワーク上で利用可能になるはずです。 +これは [`incus cluster list`](incus_cluster_list.md) で確認できます。 -### Join additional servers +### 追加のサーバーをジョインさせる -You can now join further servers to the cluster. +これでクラスタに追加のサーバーをジョインできるようになりました。 ```{note} -The servers that you add should be newly installed Incus servers. -If you are using existing servers, make sure to clear their contents before joining them, because any existing data on them will be lost. +追加するサーバーは新規にインストールした Incus サーバーにするほうがよいです。 +既存のサーバーを使う場合、既存のデータは消失するので、ジョインする前にデータを確実にクリアしてください。 ``` -To join a server to the cluster, run `incus admin init` on the cluster. -Joining an existing cluster requires root privileges, so make sure to run the command as root or with `sudo`. +クラスタにサーバーをジョインさせるには、クラスタ上で `incus admin init` を実行します。 +既存のクラスタにジョインするには root 権限が必要ですので、コマンドを root で実行するか `sudo` をつけて実行するのを忘れないでください。 -Basically, the initialization process consists of the following steps: +基本的に、初期化プロセスは以下のステップからなります: -1. Request to join an existing cluster. +1. 既存のクラスタにジョインをリクエストする。 - Answer the first questions that `incus admin init` asks accordingly: + `incus admin init` の最初の質問に適切に回答します: - `Would you like to use Incus clustering?` - Select **yes**. + **yes** を選択。 - `What IP address or DNS name should be used to reach this server?` - Make sure to use an IP or DNS address that other servers can reach. + 他のサーバーがアクセスできる IP または DNS のアドレスを確実に使用してください。 - `Are you joining an existing cluster?` - Select **yes**. + **yes** を選択。 -1. Authenticate with the cluster. +1. クラスタで認証する。 - There are two alternative methods, depending on which authentication method you choose when configuring the bootstrap server. + ブートスラップサーバーを設定する際に選んだ認証方法に応じて 2 つの方法があります。 `````{tabs} - ````{group-tab} Authentication tokens (recommended) - If you configured your cluster to use {ref}`authentication tokens `, you must generate a join token for each new member. - To do so, run the following command on an existing cluster member (for example, the bootstrap server): + ````{group-tab} 認証トークン + {ref}`認証トークン ` を使うようにクラスタを設定した場合、新メンバーごとにジョイントークンを生成する必要があります。 + そのためには、既存のクラスタメンバー（たとえば、ブートストラップサーバー）で以下のコマンドを実行します: incus cluster add - This command returns a single-use join token that is valid for a configurable time (see {config:option}`server-cluster:cluster.join_token_expiry`). - Enter this token when `incus admin init` prompts you for the join token. + このコマンドは設定（{config:option}`server-cluster:cluster.join_token_expiry`参照）時に有効な一回限りのジョイントークンを返します。 + `incus admin init` のプロンプトでジョイントークンを求められたときにこのトークンを入力してください。 - The join token contains the addresses of the existing online members, as well as a single-use secret and the fingerprint of the cluster certificate. - This reduces the amount of questions that you must answer during `incus admin init`, because the join token can be used to answer these questions automatically. + ジョイントークンは既存のオンラインメンバーのアドレス、一回限りのシークレットとクラスタ証明書のフィンガープリントを含みます。 + ジョイントークンがこれらの質問に自動で回答できるので、 `incus admin init` 中に回答が必要な質問の量を減らすことができます。 ```` ````` -1. Confirm that all local data for the server is lost when joining a cluster. -1. Configure server-specific settings (see {ref}`clustering-member-config` for more information). +1. クラスタにジョインする際サーバーのすべてのローカルデータが消失することを確認します。 +1. サーバー固有の設定を行います（詳細は {ref}`clustering-member-config` を参照）。 - You can accept the default values or specify custom values for each server. + デフォルト値を受け入れることもできますし、各サーバーにカスタム値を指定することもできます。
-Expand to see full examples for incus admin init on additional servers +追加のサーバー上で incus admin init を実行する完全な例を見るには展開してください `````{tabs} -````{group-tab} Authentication tokens (recommended) +````{group-tab} 認証トークン ```{terminal} :input: sudo incus admin init @@ -137,55 +136,32 @@ Choose "zfs.pool_name" property for storage pool "local": Would you like a YAML "incus admin init" preseed to be printed? (yes/no) [default=no]: ``` -```` -````{group-tab} Trust password - -```{terminal} -:input: sudo incus admin init - -Would you like to use Incus clustering? (yes/no) [default=no]: yes -What IP address or DNS name should be used to reach this server? [default=192.0.2.102]: -Are you joining an existing cluster? (yes/no) [default=no]: yes -Do you have a join token? (yes/no/[token]) [default=no]: no -What member name should be used to identify this server in the cluster? [default=server2]: -IP address or FQDN of an existing cluster member (may include port): 192.0.2.101:8443 -Cluster fingerprint: 2915dafdf5c159681a9086f732644fb70680533b0fb9005b8c6e9bca51533113 -You can validate this fingerprint by running "incus info" locally on an existing cluster member. -Is this the correct fingerprint? (yes/no/[fingerprint]) [default=no]: yes -Cluster trust password: -All existing data is lost when joining a cluster, continue? (yes/no) [default=no] yes -Choose "size" property for storage pool "local": -Choose "source" property for storage pool "local": -Choose "zfs.pool_name" property for storage pool "local": -Would you like a YAML "incus admin init" preseed to be printed? (yes/no) [default=no]: -``` - ```` `````
-After the initialization process finishes, your server is added as a new cluster member. -You can check this with [`incus cluster list`](incus_cluster_list.md). +初期化プロセスが終わった後、サーバーが新しいクラスタメンバーとして追加されます。 +これは [`incus cluster list`](incus_cluster_list.md) で確認できます。 -## Configure the cluster through preseed files +## クラスタをプリシードファイルで設定する -To form your cluster, you must first run `incus admin init` on the bootstrap server. -After that, run it on the other servers that you want to join to the cluster. +クラスタを形成するには、まずブートストラップサーバー上で `incus admin init` を実行します。 +その後、クラスタにジョインさせたい他のサーバーでもこのコマンドを実行します。 -Instead of answering the `incus admin init` questions interactively, you can provide the required information through preseed files. -You can feed a file to `incus admin init` with the following command: +`incus admin init` の質問にインタラクティブに回答する代わりに、プリシードファイルを使って必要な情報を提供できます。 +以下のコマンドを使って `incus admin init` にファイルをフィードできます: cat | incus admin init --preseed -You need a different preseed file for every server. +サーバーごとに異なるプリシードファイルが必要です。 -### Initialize the bootstrap server +### ブートストラップサーバーを初期化する `````{tabs} -````{group-tab} Authentication tokens (recommended) -To enable clustering, the preseed file for the bootstrap server must contain the following fields: +````{group-tab} 認証トークン +クラスタリングを有効にするには、ブートストラップサーバー用のプリシードファイルは以下のフィールドを含む必要があります: ```yaml config: @@ -195,7 +171,7 @@ cluster: enabled: true ``` -Here is an example preseed file for the bootstrap server: +ブートストラップサーバー用のプリシードファイルの例を以下に示します: ```yaml config: @@ -230,14 +206,14 @@ cluster: ````` -### Join additional servers +### 追加のサーバーをジョインさせる -The preseed files for new cluster members require only a `cluster` section with data and configuration values that are specific to the joining server. +新しいクラスタメンバー用のプリシードファイルは参加するサーバーに固有のデータと設定値を含む `cluster` セクションのみが必要です。 `````{tabs} -````{group-tab} Authentication tokens (recommended) -The preseed file for additional servers must include the following fields: +````{group-tab} 認証トークン +追加のサーバーのプリシードファイルは以下の項目を含む必要があります: ```yaml cluster: @@ -246,7 +222,7 @@ cluster: cluster_token: ``` -Here is an example preseed file for a new cluster member: +新しいクラスタメンバー用のプリシードファイルの例を以下に示します: ```yaml cluster: diff --git a/doc/howto/cluster_groups.md b/doc/howto/cluster_groups.md index d92013391f9..83aff005b2a 100644 --- a/doc/howto/cluster_groups.md +++ b/doc/howto/cluster_groups.md @@ -1,42 +1,42 @@ (howto-cluster-groups)= -# How to set up cluster groups +# クラスタグループをセットアップするには -Cluster members can be assigned to {ref}`cluster-groups`. -By default, all cluster members belong to the `default` group. +ラスタメンバーは {ref}`cluster-groups` にアサインできます。 +デフォルトでは、すべてのクラスタメンバーは `default` グループに属しています。 -To create a cluster group, use the [`incus cluster group create`](incus_cluster_group_create.md) command. -For example: +クラスタグループを作成するには、[`incus cluster group create`](incus_cluster_group_create.md) コマンドを使用します。 +たとえば: incus cluster group create gpu -To assign a cluster member to one or more groups, use the [`incus cluster group assign`](incus_cluster_group_assign.md) command. -This command removes the specified cluster member from all the cluster groups it currently is a member of and then adds it to the specified group or groups. +クラスタメンバーを 1 つまたは複数のグループに割り当てるには、[`incus cluster group assign`](incus_cluster_group_assign.md) コマンドを使用します。 +このコマンドは、指定したクラスタメンバーを現在所属しているすべてのクラスタグループから削除し、その後、指定したグループまたはグループに追加します。 -For example, to assign `server1` to only the `gpu` group, use the following command: +たとえば、`server1`を`gpu`グループのみに割り当てるには、次のコマンドを使用します: incus cluster group assign server1 gpu -To assign `server1` to the `gpu` group and also keep it in the `default` group, use the following command: +`server1`を`gpu`グループに割り当てるとともに、`default`グループにも保持させるためには、以下のコマンドを使用します: incus cluster group assign server1 default,gpu -To add a cluster member to a specific group without removing it from other groups, use the [`incus cluster group add`](incus_cluster_group_add.md) command. +他のグループからメンバーを削除せずに特定のグループにクラスタメンバーを追加するには [`incus cluster group add`](incus_cluster_group_add.md) コマンドを使います。 -For example, to add `server1` to the `gpu` group and also keep it in the `default` group, use the following command: +たとえば、`server1` を `default` グループに残したまま `gpu` に追加するには、以下のコマンドを使います: incus cluster group add server1 gpu -## Launch an instance on a cluster group member +## クラスタグループメンバー上でインスタンスを起動する -With cluster groups, you can target an instance to run on one of the members of the cluster group, instead of targeting it to run on a specific member. +クラスタグループがある場合、インスタンスを特定のメンバー上で動かすようにターゲットする代わりに、クラスタグループのいずれかのメンバー上で動かすようにターゲットできます。 ```{note} -{config:option}`cluster-cluster:scheduler.instance` must be set to either `all` (the default) or `group` to allow instances to be targeted to a cluster group. +クラスタグループにインスタンスをターゲットできるようにするには {config:option}`cluster-cluster:scheduler.instance` は `all`（デフォルト）または `group` に設定する必要があります。 -See {ref}`clustering-instance-placement` for more information. +詳細は{ref}`clustering-instance-placement`を参照してください。 ``` -To launch an instance on a member of a cluster group, follow the instructions in {ref}`cluster-target-instance`, but use the group name prefixed with `@` for the `--target` flag. -For example: +クラスタグループのメンバー上でインスタンスを起動するには、{ref}`cluster-target-instance` の指示に従ってください。ただし `--target` フラグではグループ名の前に `@` をつけて指定してください。 +たとえば: incus launch images:ubuntu/22.04 c1 --target=@gpu diff --git a/doc/howto/cluster_manage.md b/doc/howto/cluster_manage.md index 215b36b2ecf..82c0b1eae06 100644 --- a/doc/howto/cluster_manage.md +++ b/doc/howto/cluster_manage.md @@ -1,7 +1,7 @@ (cluster-manage)= -# How to manage a cluster +# クラスタを管理するには -After your cluster is formed, use [`incus cluster list`](incus_cluster_list.md) to see a list of its members and their status: +クラスタを形成した後、メンバーの一覧と状態を見るには [`incus cluster list`](incus_cluster_list.md) を使用します: ```{terminal} :input: incus cluster list @@ -19,120 +19,120 @@ After your cluster is formed, use [`incus cluster list`](incus_cluster_list.md) +---------+----------------------------+------------------+--------------+----------------+-------------+--------+-------------------+ ``` -To see more detailed information about an individual cluster member, run the following command: +ここのクラスタメンバーについてより詳細な情報を見るには、以下のコマンドを実行します: incus cluster show -To see state and usage information for a cluster member, run the following command: +クラスタメンバーの状態と使用状況を見るには、以下のコマンドを実行します: incus cluster info -## Configure your cluster +## クラスタを設定するには -To configure your cluster, use [`incus config`](incus_config.md). -For example: +クラスタを設定するには、[`incus config`](incus_config.md) を使用します。 +たとえば: incus config set cluster.max_voters 5 -Keep in mind that some {ref}`server configuration options ` are global and others are local. -You can configure the global options on any cluster member, and the changes are propagated to the other cluster members through the distributed database. -The local options are set only on the server where you configure them (or alternatively on the server that you target with `--target`). +いくつかの {ref}`サーバー設定 ` はグローバルで他はローカルであることに注意してください。 +グローバル設定はどのクラスタメンバー上でも実行でき、変更は分散データベースを通して他のクラスタメンバーにも伝搬されます。 +ローカル設定は設定したサーバー上でのみ（あるいは `--target` で指定したサーバー上でのみ）変更されます。 -In addition to the server configuration, there are a few cluster configurations that are specific to each cluster member. -See {ref}`cluster-member-config` for all available configurations. +サーバー設定に加えて、各クラスタメンバーに固有ないくつかのクラスタ設定があります。 +利用可能な設定のすべてについては {ref}`cluster-member-config` を参照してください。 -To set these configuration options, use [`incus cluster set`](incus_cluster_set.md) or [`incus cluster edit`](incus_cluster_edit.md). -For example: +これらの設定を変更するには、[`incus cluster set`](incus_cluster_set.md) か [`incus cluster edit`](incus_cluster_edit.md) を使用します。 +たとえば: incus cluster set server1 scheduler.instance manual -### Assign member roles +### メンバーロールを割り当てる -To add or remove a {ref}`member role ` for a cluster member, use the [`incus cluster role`](incus_cluster_role.md) command. -For example: +クラスタメンバーに {ref}`メンバーロール ` を追加または削除するには [`incus cluster role`](incus_cluster_role.md) コマンドを使用します。 +たとえば: incus cluster role add server1 event-hub ```{note} -You can add or remove only those roles that are not assigned automatically by Incus. +Incus で自動で割り当てられないロールのみが追加または削除できます。 ``` -### Edit the cluster member configuration +### クラスタメンバー設定を編集する -To edit all properties of a cluster member, including the member-specific configuration, the member roles, the failure domain and the cluster groups, use the [`incus cluster edit`](incus_cluster_edit.md) command. +メンバー固有設定、メンバーロール、failure domain とクラスタグループを含むクラスタメンバーのプロパティを編集するには [`incus cluster edit`](incus_cluster_edit.md) コマンドを使用します。 (cluster-evacuate)= -## Evacuate and restore cluster members +## クラスタメンバーの退避と復元 -There are scenarios where you might need to empty a given cluster member of all its instances (for example, for routine maintenance like applying system updates that require a reboot, or to perform hardware changes). +既存のクラスタメンバーのすべてのインスタンスを空にしたい（たとえば再起動が必要なシステムのアップデートを適用するような日常のメンテナンスやハードウェアの変更を行う場合など）ようなケースがあります。 -To do so, use the [`incus cluster evacuate`](incus_cluster_evacuate.md) command. -This command migrates all instances on the given server, moving them to other cluster members. -The evacuated cluster member is then transitioned to an "evacuated" state, which prevents the creation of any instances on it. +このためには [`incus cluster evacuate`](incus_cluster_evacuate.md) コマンドを使用します。 +このコマンドは指定したサーバー上のすべてのインスタンスを他のクラスタメンバーに移動します。 +退避したクラスタメンバーは "evacuated" 状態になり、このメンバー上でインスタンスの作成はできなくなります。 -You can control how each instance is moved through the {config:option}`instance-miscellaneous:cluster.evacuate` instance configuration key. -Instances are shut down cleanly, respecting the `boot.host_shutdown_timeout` configuration key. +各インスタンスがどのように移動するかは {config:option}`instance-miscellaneous:cluster.evacuate` インスタンス設定で制御できます。 +インスタンスは `boot.host_shutdown_timeout` 設定にしたがってクリーンにシャットダウンされます。 -When the evacuated server is available again, use the [`incus cluster restore`](incus_cluster_restore.md) command to move the server back into a normal running state. -This command also moves the evacuated instances back from the servers that were temporarily holding them. +退避したサーバーが再び利用可能になったときに、サーバーを通常の稼働状態に戻すには [`incus cluster restore`](incus_cluster_restore.md) コマンドを使用します。 +このコマンドは退避したインスタンスを一時的に保持していたサーバーから戻します。 (cluster-automatic-evacuation)= -### Automatic evacuation +### 自動での退避 -If you set the {config:option}`server-cluster:cluster.healing_threshold` configuration to a non-zero value, instances are automatically evacuated if a cluster member goes offline. +{config:option}`server-cluster:cluster.healing_threshold` 設定をゼロでない値に設定すると、クラスタメンバーがオフラインになったら、インスタンスは自動的に退避されます。 -When the evacuated server is available again, you must manually restore it. +退避されたサーバーが再び利用可能になったら、手動で復元する必要があります。 (cluster-manage-delete-members)= -## Delete cluster members +## クラスタメンバーを削除する -To cleanly delete a member from the cluster, use the following command: +クラスタからメンバーをクリーンに削除するには以下のコマンドを使用します: incus cluster remove -You can only cleanly delete members that are online and that don't have any instances located on them. +オンラインでインスタンスが 1 つも存在しないメンバーだけがクリーンに削除できます。 -### Deal with offline cluster members +### オフラインのクラスタメンバーの強制削除 -If a cluster member goes permanently offline, you can force-remove it from the cluster. -Make sure to do so as soon as you discover that you cannot recover the member. -If you keep an offline member in your cluster, you might encounter issues when upgrading your cluster to a newer version. +クラスタメンバーが恒久的にオフラインになった場合、クラスタメンバーをクラスタから強制削除できます。 +メンバーを復旧できないと気づいたらすぐに削除するようにしてください。 +クラスタにオフラインのメンバーを残しておくと、クラスタを新しいバージョンにアップグレードする際に問題が起きるかもしれません。 -To force-remove a cluster member, enter the following command on one of the cluster members that is still online: +クラスタメンバーを強制削除するには、引き続きオンラインになっているクラスタメンバーの 1 つで以下のコマンドを入力します: incus cluster remove --force ```{caution} -Force-removing a cluster member will leave the member's database in an inconsistent state (for example, the storage pool on the member will not be removed). -As a result, it will not be possible to re-initialize Incus later, and the server must be fully reinstalled. +クラスタメンバーを強制削除するとメンバーのデータベースが不整合な状態（例えば、メンバー上のストレージプールが削除されないなど）のままになります。 +結果として、後で Incus を再び初期化できなくなり、サーバーを完全に再インストールするしかなくなります。 ``` -## Upgrade cluster members +## クラスタメンバーをアップグレードする -To upgrade a cluster, you must upgrade all of its members. -All members must be upgraded to the same version of Incus. +クラスタをアップグレードするには、すべてのメンバーをアップグレードする必要があります。 +すべてのメンバーを同じ Incus のバージョンにアップグレードしなければなりません。 ```{caution} -Do not attempt to upgrade your cluster if any of its members are offline. -Offline members cannot be upgraded, and your cluster will end up in a blocked state. +オフラインのメンバーがいる場合はクラスタをアップグレードしないでください。 +オフラインのメンバーはアップグレードできず、クラスタがブロックした状態になってしまいます。 ``` -To upgrade a single member, simply upgrade the Incus package on the host and restart the Incus daemon. -If the new version of the daemon has database schema or API changes, the upgraded member might transition into a "blocked" state. -In this case, the member does not serve any Incus API requests (which means that `incus` commands don't work on that member anymore), but any running instances will continue to run. +単一のメンバーをアップグレードするには、単にそのホスト上で Incus パッケージをアップグレードして Incus デーモンを再起動します。 +新しいバージョンのデーモンがデータベーススキーマまたは API に変更がある場合、アップグレードされたメンバーは "blocked" 状態に遷移するかも知れません。 +この場合、メンバーは Incus API リクエストに応答しなくなります（これはこのメンバー上では `incus` コマンドがもはや使用できなくなることを意味します）が、稼働中のインスタンスは引き続き稼働します。 -This happens if there are other cluster members that have not been upgraded and are therefore running an older version. -Run [`incus cluster list`](incus_cluster_list.md) on a cluster member that is not blocked to see if any members are blocked. +これはアップグレードされておらず古いバージョンを稼働している他のクラスタメンバーがある場合に発生します。 +ブロックされているメンバーがあるかを確認するには、ブロックされていないクラスタメンバー上で [`incus cluster list`](incus_cluster_list.md) を実行します。 -As you proceed upgrading the rest of the cluster members, they will all transition to the "blocked" state. -When you upgrade the last member, the blocked members will notice that all servers are now up-to-date, and the blocked members become operational again. +残りのクラスタメンバーのアップグレードを進めると、それらすべてのメンバーが "blocked" 状態になります。 +最後のメンバーをアップグレードすると、ブロックされたメンバーはすべてのサーバーが最新になったことを検知し、ブロックされたメンバーが再び使用可能になります。 -## Update the cluster certificate +## クラスタ証明書をアップグレードする -In a Incus cluster, the API on all servers responds with the same shared certificate, which is usually a standard self-signed certificate with an expiry set to ten years. +Incus クラスタ内ですべてのサーバー上の API は同じ共有された証明書で応答します。これは通常有効期限が 10 年に設定されたごく普通の自己署名証明書です。 -The certificate is stored at `/var/lib/incus/cluster.crt` and is the same on all cluster members. +証明書は `/var/lib/incus/cluster.crt` に保管され、すべてのクラスタメンバー上で同じです。 -You can replace the standard certificate with another one, for example, a valid certificate obtained through ACME services (see {ref}`authentication-server-certificate` for more information). -To do so, use the [`incus cluster update-certificate`](incus_cluster_update-certificate.md) command. -This command replaces the certificate on all servers in your cluster. +この自己署名証明書を別の証明書、たとえば、 ACME サービス経由で得られた有効な証明書（詳細は {ref}`authentication-server-certificate` を参照）に置き換えることができます。 +そのためには [`incus cluster update-certificate`](incus_cluster_update-certificate.md) コマンドを使用します。 +このコマンドはクラスタ内のすべてのサーバーの証明書を置き換えます。 diff --git a/doc/howto/cluster_manage_instance.md b/doc/howto/cluster_manage_instance.md index 3ae6b1df93e..356006b9ad4 100644 --- a/doc/howto/cluster_manage_instance.md +++ b/doc/howto/cluster_manage_instance.md @@ -1,44 +1,44 @@ (cluster-manage-instance)= -# How to manage instances in a cluster +# クラスタ内のインスタンスを管理するには -In a cluster setup, each instance lives on one of the cluster members. -You can operate each instance from any cluster member, so you do not need to log on to the cluster member on which the instance is located. +クラスタのセットアップでは、各インスタンスはどれかのクラスタメンバー上で稼働します。 +どのクラスタメンバーからでも各インスタンスを操作できるので、インスタンスが配置されているクラスタメンバーにログオンする必要はありません。 (cluster-target-instance)= -## Launch an instance on a specific cluster member +## 特定のクラスタメンバー上でインスタンスを起動する -When you launch an instance, you can target it to run on a specific cluster member. -You can do this from any cluster member. +インスタンスを起動する際、特定のクラスタメンバー上で稼働するようにターゲットできます。 +これはどのクラスタメンバーからでも実行できます。 -For example, to launch an instance named `c1` on the cluster member `server2`, use the following command: +たとえば、`c1` という名前のインスタンスを `server2` クラスタメンバー上で起動するには、以下のコマンドを使用します: incus launch images:ubuntu/22.04 c1 --target server2 -You can launch instances on specific cluster members or on specific {ref}`cluster groups `. +インスタンスを特定のクラスタメンバーあるいは特定の {ref}`クラスタグループ ` 上で実行できます。 -If you do not specify a target, the instance is assigned to a cluster member automatically. -See {ref}`clustering-instance-placement` for more information. +ターゲットを指定しなかった場合、インスタンスはクラスタメンバーに自動的に割り当てられます。 +詳細は{ref}`clustering-instance-placement`を参照してください。 -## Check where an instance is located +## インスタンスの配置を確認する -To check on which member an instance is located, list all instances in the cluster: +インスタンスがどのメンバーに配置されているかを確認するには、クラスタ内のすべてのインスタンス一覧を表示します: incus list -The location column indicates the member on which each instance is running. +location カラムに各インスタンスが稼働しているメンバーが表示されます。 -## Move an instance +## インスタンスを移動する -You can move an existing instance to another cluster member. -For example, to move the instance `c1` to the cluster member `server1`, use the following commands: +既存のインスタンスを他のクラスタメンバーに移動できます。 +たとえば、 `c1` インスタンスを `server1` クラスタメンバーに移動するには以下のコマンドを使用します: incus stop c1 incus move c1 --target server1 incus start c1 -See {ref}`move-instances` for more information. +詳細は {ref}`move-instances` を参照してください。 -To move an instance to a member of a cluster group, use the group name prefixed with `@` for the `--target` flag. -For example: +インスタンスをクラスターグループのメンバーに移動するには、`--target` フラグで `@` で始まるグループ名を使用してください。 +たとえば: incus move c1 --target @group1 diff --git a/doc/howto/cluster_recover.md b/doc/howto/cluster_recover.md index 520a4125090..57218d46cee 100644 --- a/doc/howto/cluster_recover.md +++ b/doc/howto/cluster_recover.md @@ -1,116 +1,116 @@ (cluster-recover)= -# How to recover a cluster +# クラスタを復旧するには -It might happen that one or several members of your cluster go offline or become unreachable. -In that case, no operations are possible on this member, and neither are operations that require a state change across all members. -See {ref}`clustering-offline-members` and {ref}`cluster-automatic-evacuation` for more information. +クラスタの 1 つまたは複数のメンバーがオフラインまたは到達不能になるかもしれません。 +この場合、このメンバー上での操作とすべてのメンバーにまたがる状態変更が必要な操作は不可能になります。 +詳細は{ref}`clustering-offline-members`と{ref}`cluster-automatic-evacuation`を参照してください。 -If you can bring the offline cluster members back or delete them from the cluster, operation resumes as normal. -If this is not possible, there are a few ways to recover the cluster, depending on the scenario that caused the failure. -See the following sections for details. +オフラインのクラスタメンバーを復旧させるかクラスタから削除すると、通常どおり操作が可能となります。 +これができない場合、故障の原因となったケースに応じて、クラスタを復旧させるいくつかの方法があります。 +詳細は以下のセクションを参照してください。 ```{note} -Run `incus admin cluster --help` for an overview of all available commands. +全ての利用可能なコマンドの概要を見るには `incus admin cluster --help` を実行してください。 ``` -## Recover from quorum loss +## 過半数割れからの復旧 -Every Incus cluster has a specific number of members (configured through {config:option}`server-cluster:cluster.max_voters`) that serve as voting members of the distributed database. -If you permanently lose a majority of these cluster members (for example, you have a three-member cluster and you lose two members), the cluster loses quorum and becomes unavailable. -However, if at least one database member survives, it is possible to recover the cluster. +各 Incus クラスタは（{config:option}`server-cluster:cluster.max_voters` で設定した）特定のメンバー数を持ち、これが分散データベースの voter メンバーの数を決定します。 +クラスタメンバーの過半数を恒久的に失った場合（たとえば、 3 つのメンバーのクラスタで 2 つのメンバーを消失した場合）、クラスタは過半数を失い利用不可能となります。 +しかし、最低 1 つのデータベースメンバーが生き残っていれば、クラスタを復旧できます。 -To do so, complete the following steps: +このためには、以下のステップを実行してください。 -1. Log on to any surviving member of your cluster and run the following command: +1. クラスタ内の生き残っているどれかのメンバーにログオンし以下のコマンドを実行します: sudo incus admin cluster list-database - This command shows which cluster members have one of the database roles. -1. Pick one of the listed database members that is still online as the new leader. - Log on to the machine (if it differs from the one you are already logged on to). -1. Make sure that the Incus daemon is not running on the machine. + このコマンドはデータベースロールの 1 つを持つクラスタメンバーを表示します。 +1. 一覧表示されたデータベースメンバーの 1 つを新しいリーダーとして選択します。 + そのマシンにログオンします（すでにログオンしたマシンと異なる場合）。 +1. そのマシンで Incus デーモンが実行中でないことを確認します。 sudo systemctl stop incus.service incus.socket -1. Log on to all other cluster members that are still online and stop the Incus daemon. -1. On the server that you picked as the new leader, run the following command: +1. まだオンラインである他のすべてのクラスタメンバーにログオンし Incus デーモンを停止します。 +1. 新しいリーダーとして選択したサーバーで以下のコマンドを実行します: sudo incus admin cluster recover-from-quorum-loss -1. Start the Incus daemon again on all machines, starting with the new leader. +1. すべてのマシンで再び Incus デーモンを開始し、新しいリーダーを始動させます。 sudo systemctl start incus.socket incus.service -The database should now be back online. -No information has been deleted from the database. -All information about the cluster members that you have lost is still there, including the metadata about their instances. -This can help you with further recovery steps if you need to re-create the lost instances. +これでデータベースはオンラインに戻るはずです。 +データベースから情報が削除されることはありません。 +失ったクラスタメンバーについての情報は、そのメンバーのインスタンスについてのメタデータも含めて、すべて残っています。 +失ったインスタンスを再び作成する必要がある場合に、この情報がさらに復旧を進める上で役に立ちます。 -To permanently delete the cluster members that you have lost, force-remove them. -See {ref}`cluster-manage-delete-members`. +失ったクラスタメンバーを恒久的に削除するには、強制削除します。 +{ref}`cluster-manage-delete-members` を参照してください。 -## Recover cluster members with changed addresses +## アドレス変更からクラスタメンバーを復旧する -If some members of your cluster are no longer reachable, or if the cluster itself is unreachable due to a change in IP address or listening port number, you can reconfigure the cluster. +クラスタのいくつかのメンバーがもう到達不能な場合、あるいはクラスタ自体が IP アドレスまたはリッスニングポート番号の変更のために到達不能な場合、クラスタを再設定できます。 -To do so, edit the cluster configuration on each member of the cluster and change the IP addresses or listening port numbers as required. -You cannot remove any members during this process. -The cluster configuration must contain the description of the full cluster, so you must do the changes for all cluster members on all cluster members. +そうするためには、クラスタの各メンバーでクラスタ設定を編集し、IP アドレスとリッスニンググポート番号を必要に応じて変更します。 +この操作中はメンバーは削除できません。 +クラスタ設定は完全なクラスタの記述を含む必要がありますので、すべてのクラスタメンバー上ですべてのクラスタメンバーを変更する必要があります。 -You can edit the {ref}`clustering-member-roles` of the different members, but with the following limitations: +異なるメンバーの {ref}`clustering-member-roles` を編集できますが、以下の制限があります: -- A cluster member that does not have a `database*` role cannot become a voter, because it might lack a global database. -- At least two members must remain voters (except in the case of a two-member cluster, where one voter suffices), or there will be no quorum. +- `database*` ロールを持たないクラスタメンバーは、グローバルデータベースがないため、 voter になれません。 +- 少なくとも 2 つのメンバー（2 つのメンバーからなるクラスタの場合を除く、この場合は 1 つで十分）が voter にとどまる必要があります。そうでなければ過半数が成り立ちません。 -Log on to each cluster member and complete the following steps: +各クラスタメンバーにログオンして以下のステップを実行します: -1. Stop the Incus daemon. +1. Incus デーモンを停止します。 sudo systemctl stop incus.service incus.socket -1. Run the following command: +1. 以下のコマンドを実行します: sudo incus admin cluster edit -1. Edit the YAML representation of the information that this cluster member has about the rest of the cluster: +1. クラスタメンバーがクラスタの他のメンバーについて持っている情報の YAML 表現を編集します: ```yaml # Latest cowsql segment ID: 1234 members: - - id: 1 # Internal ID of the member (Read-only) - name: server1 # Name of the cluster member (Read-only) - address: 192.0.2.10:8443 # Last known address of the member (Writeable) - role: voter # Last known role of the member (Writeable) - - id: 2 # Internal ID of the member (Read-only) - name: server2 # Name of the cluster member (Read-only) - address: 192.0.2.11:8443 # Last known address of the member (Writeable) - role: stand-by # Last known role of the member (Writeable) - - id: 3 # Internal ID of the member (Read-only) - name: server3 # Name of the cluster member (Read-only) - address: 192.0.2.12:8443 # Last known address of the member (Writeable) - role: spare # Last known role of the member (Writeable) + - id: 1 # メンバーの内部 ID（読み取り専用） + name: server1 # クラスタメンバー名（読み取り専用） + address: 192.0.2.10:8443 # メンバーの最終の既知のアドレス（変更可能） + role: voter # メンバーの最終の既知のロール（変更可能） + - id: 2 # メンバーの内部 ID（読み取り専用） + name: server2 # クラスタメンバー名（読み取り専用） + address: 192.0.2.11:8443 # メンバーの最終の既知のアドレス（変更可能） + role: stand-by # メンバーの最終の既知のロール（変更可能） + - id: 3 # メンバーの内部 ID（読み取り専用） + name: server3 # クラスタメンバー名（読み取り専用） + address: 192.0.2.12:8443 # メンバーの最終の既知のアドレス（変更可能） + role: spare # メンバーの最終の既知のロール（変更可能） ``` - You can edit the addresses and the roles. + アドレスとロールを編集できます。 -After doing the changes on all cluster members, start the Incus daemon on all members again. +すべてのクラスタメンバー上でこの変更をした後、すべてのメンバーで Incus デーモンを再び開始します。 sudo systemctl start incus.socket incus.service -The cluster should now be fully available again with all members reporting in. -No information has been deleted from the database. -All information about the cluster members and their instances is still there. +クラスタはすべてのメンバーが入った状態で再び完全に利用可能になるはずです。 +データベースから情報が削除されることはありません。 +クラスタメンバーとそれらのインスタンスについての情報はすべて残っています。 -## Manually alter Raft membership +## Raft のメンバーシップを手動で変更する -In some situations, you might need to manually alter the Raft membership configuration of the cluster because of some unexpected behavior. +場合によっては、なんらかの予期せぬ挙動のために Raft のメンバーシップ設定を手動で変更する必要があるかもしれません。 -For example, if you have a cluster member that was removed uncleanly, it might not show up in [`incus cluster list`](incus_cluster_list.md) but still be part of the Raft configuration. -To see the Raft configuration, run the following command: +たとえば、クラスタメンバーをクリーンでない状態で削除した場合、 [`incus cluster list`](incus_cluster_list.md) では表示されないが Raft 設定の一部として残るという状態になるかも知れません。 +Raft の設定を見るには以下のコマンドを使用します: incus admin sql local "SELECT * FROM raft_nodes" -In that case, run the following command to remove the leftover node: +この場合、残ったノードを削除するには以下のコマンドを使用します: incus admin cluster remove-raft-node
diff --git a/doc/howto/disaster_recovery.md b/doc/howto/disaster_recovery.md index 9724ed63437..3c48c4c21f8 100644 --- a/doc/howto/disaster_recovery.md +++ b/doc/howto/disaster_recovery.md @@ -1,40 +1,40 @@ (disaster-recovery)= -# How to recover instances in case of disaster +# 災害時にインスタンスを復旧するには -Incus provides a tool for disaster recovery in case the {ref}`Incus database ` is corrupted or otherwise lost. +Incus は{ref}`Incus データベース `が壊れたり失われたりといったディザスタリカバリのためのツールを提供しています。 -The tool scans the storage pools for instances and imports the instances that it finds back into the database. -You need to re-create the required entities that are missing (usually profiles, projects, and networks). +ツールはインスタンスのストレージプールをスキャンし、見つけたインスタンスをデータベースにインポートします。 +失われた必要なエンティティ（通常はプロファイル、プロジェクトとネットワーク）をあなたが再作成する必要があります。 ```{important} -This tool should be used for disaster recovery only. -Do not rely on this tool as an alternative to proper backups; you will lose data like profiles, network definitions, or server configuration. +このツールはディザスタリカバリのみに使うべきです。 +適切なバックアップの代替手段としてこのツールに依存しないでください。プロファイル、ネットワークの定義、サーバ設定のようなデータは失われてしまうからです。 -The tool must be run interactively and cannot be used in automated scripts. +ツールはインタラクティブに実行する必要があり、自動化したスクリプト内では使用できません。 ``` -## Recovery process +## リカバリプロセス -When you run the tool, it scans all storage pools that still exist in the database, looking for missing volumes that can be recovered. -You can also specify the details of any unknown storage pools (those that exist on disk but do not exist in the database), and the tool attempts to scan those too. +ツールを実行すると、データベースにまだ残っているすべてのストレージプールをスキャンし、復旧できる失われたボリュームを探します。 +（ディスク上に存在するがデータベース内には存在しない）未知のストレージプールの詳細を指定することもでき、するとツールはそれらもスキャンを試みます。 -After mounting the specified storage pools (if not already mounted), the tool scans them for unknown volumes that look like they are associated with Incus. -Incus maintains a `backup.yaml` file in each instance's storage volume, which contains all necessary information to recover a given instance (including instance configuration, attached devices, storage volume, and pool configuration). -This data can be used to rebuild the instance, storage volume, and storage pool database records. -Before recovering an instance, the tool performs some consistency checks to compare what is in the `backup.yaml` file with what is actually on disk (such as matching snapshots). -If all checks out, the database records are re-created. +（まだマウントされていなければ）指定されたストレージプールをマウントした後、ツールは Incus に関連付けられていたと思われる未知のボリュームのストレージボリュームをスキャンします。 +Incus は各インスタンスのストレージボリュームに`backup.yaml`を保管していて、そこにインスタンスを復旧するために必要なすべての（インスタンス設定、アタッチしたデバイス、ストレージボリューム、プール設定も含めた）情報を保管しています。 +このデータはインスタンス、ストレージボリューム、そしてストレージプールのデータベースレコードをリビルドするのに使用できます。 +インスタンスを復旧する前に、ツールは`backup.yaml` ファイルの内容と（対応するスナップショットなど）ディスク上に実際に存在するものとを比較してある程度の整合性チェックを行います。 +問題なければデータベースのレコードが再生成されます。 -If the storage pool database record also needs to be created, the tool uses the information from an instance's `backup.yaml` file as the basis of its configuration, rather than what the user provided during the discovery phase. -However, if this information is not available, the tool falls back to restoring the pool's database record with what was provided by the user. +ストレージプールのデータベースレコードも作成が必要な場合、ディスカバリーフェーズにユーザーが入力した情報よりも、インスタンスの `backup.yaml` ファイルを設定のベースとして優先して使用します。 +ただし、それが無い場合はユーザーが入力した情報をもとにプールのデータベースレコードを復元するようにフォールバックします。 -The tool asks you to re-create missing entities like networks. -However, the tool does not know how the instance was configured. -That means that if some configuration was specified through the `default` profile, you must also re-add the required configuration to the profile. -For example, if the `incusbr0` bridge is used in an instance and you are prompted to re-create it, you must add it back to the `default` profile so that the recovered instance uses it. +ツールはネットワークなど失われたエンティティを再生成するためにあなたに質問します。 +しかし、ツールはどのようにインスタンスが設定されていたかを知りません。 +これはつまり一部の設定が`default`プロファイル経由で指定されていた場合、プロファイルに必要な設定をあなたが再度追加する必要があることを意味します。 +たとえば、インスタンスで`incusbr0`ブリッジが使われていてそれを再生成するようプロンプトが出た場合、復旧されるインスタンスがそれを使うようにあなたはそれを`default`プロファイルに追加し直す必要があります。 -## Example +## 例 -This is how a recovery process could look: +リカバリプロセスの例を示します: ```{terminal} :input: incus admin recover diff --git a/doc/howto/images_copy.md b/doc/howto/images_copy.md index 465511099ac..534107e1b32 100644 --- a/doc/howto/images_copy.md +++ b/doc/howto/images_copy.md @@ -1,88 +1,88 @@ (images-copy)= -# How to copy and import images +# イメージをコピーやインポートするには -To add images to an image store, you can either copy them from another server or import them from files (either local files or files on a web server). +イメージをイメージストアに追加するには、他のサーバーからコピーすることもできますし、ファイル（ローカルのファイルまたはウェブサーバー上のファイル）からインポートすることもできます。 -## Copy an image from a remote +## リモートからイメージをコピーする -To copy an image from one server to another, enter the following command: +あるサーバーから別のサーバーにイメージをコピーするには、以下のコマンドを入力します: incus image copy [:] : ```{note} -To copy the image to your local image store, specify `local:` as the target remote. +イメージをローカルのイメージストアにコピーするには、コピー先のリモートに `local:` と指定します。 ``` -See [`incus image copy --help`](incus_image_copy.md) for a list of all available flags. -The most relevant ones are: +すべての利用可能なフラグの一覧は [`incus image copy --help`](incus_image_copy.md) を参照してください。 +最も重要なものは以下のとおりです: `--alias` -: Assign an alias to the copy of the image. +: イメージのコピーにエイリアスを割り当てる。 `--copy-aliases` -: Copy the aliases that the source image has. +: コピー元のイメージが持つエイリアスをコピーする。 `--auto-update` -: Keep the copy up-to-date with the original image. +: 元のイメージが更新されたらコピーも更新する。 `--vm` -: When copying from an alias, copy the image that can be used to create virtual machines. +: エイリアスからコピーする際、仮想マシンを作成するのに使えるイメージをコピーする。 -## Import an image from files +## ファイルからイメージをインポートする -If you have image files that use the required {ref}`image-format`, you can import them into your image store. +要求される {ref}`image-format` を使用するイメージファイルを持っていれば、イメージストアにインポートできます。 -There are several ways of obtaining such image files: +そのようなイメージファイルを取得する方法はいくつかあります: -- Exporting an existing image (see {ref}`images-manage-export`) -- Building your own image using `distrobuilder` (see {ref}`images-create-build`) -- Downloading image files from a {ref}`remote image server ` (note that it is usually easier to {ref}`use the remote image ` directly instead of downloading it to a file and importing it) +- 既存のイメージをエクスポートする（{ref}`images-manage-export`参照） +- `distrobuilder`でイメージを生成する（{ref}`images-create-build`参照） +- {ref}`remote image server `からイメージファイルをダウンロードする（イメージをファイルにダウンロードしてインポートするより、{ref}`リモートのイメージを使用する `ほうが通常は簡単なことに注意してください） -### Import from the local file system +### ローカルファイルシステムからインポートする -To import an image from the local file system, use the [`incus image import`](incus_image_import.md) command. -This command supports both {ref}`unified images ` (compressed file or directory) and {ref}`split images ` (two files). +ローカルファイルシステムからイメージをインポートするには、[`incus image import`](incus_image_import.md) コマンドを使用します。 +このコマンドは{ref}`統合イメージ `（圧縮されたファイルまたはディレクトリー）と{ref}`分離イメージ `（2 つのファイル）の両方をサポートします。 -To import a unified image from one file or directory, enter the following command: +1 つのファイルまたはディレクトリーから統合イメージをインポートするには、以下のコマンドを入力します: incus image import [:] -To import a split image, enter the following command: +分離イメージをインポートするには、以下のコマンドを入力します: incus image import [:] -In both cases, you can assign an alias with the `--alias` flag. -See [`incus image import --help`](incus_image_import.md) for all available flags. +どちらの場合も、`--alias`フラグでエイリアスを割り当てられます。 +利用可能なすべてのフラグは [`incus image import --help`](incus_image_import.md) を参照してください。 -### Import from a file on a remote web server +### リモートウェブサーバーからファイルをインポートする -You can import image files from a remote web server by URL. -This method is an alternative to running a Incus server for the sole purpose of distributing an image to users. -It only requires a basic web server with support for custom headers (see {ref}`images-copy-http-headers`). +URL を指定してリモートウェブサーバーからイメージファイルをインポートできます。 +この方法はイメージをユーザーに配布するためだけに Incus サーバーを稼働させる代わりに使用できます。 +必要なのはカスタムヘッダ（{ref}`images-copy-http-headers`参照）をサポートする基本的なウェブサーバーだけです。 -The image files must be provided as unified images (see {ref}`image-format-unified`). +イメージファイルは統合イメージ（{ref}`image-format-unified`参照）として提供される必要があります。 -To import an image file from a remote web server, enter the following command: +リモートウェブサーバーからイメージをインポートするには、以下のコマンドを入力します: incus image import -You can assign an alias to the local image with the `--alias` flag. +`--alias`フラグでローカルのイメージにエイリアスを割り当てられます。 (images-copy-http-headers)= -#### Custom HTTP headers +#### カスタムHTTPヘッダ -Incus requires the following custom HTTP headers to be set by the web server: +Incus では以下のカスタム HTTP ヘッダをウェブサーバーで設定する必要があります: `Incus-Image-Hash` -: The SHA256 of the image that is being downloaded. +: ダウンロードされるイメージの SHA256 ハッシュ値。 `Incus-Image-URL` -: The URL from which to download the image. +: イメージをダウンロードする URL。 -Incus sets the following headers when querying the server: +Incus はサーバーに問い合わせる際に以下のヘッダを設定します: `Incus-Server-Architectures` -: A comma-separated list of architectures that the client supports. +: クライアントがサポートするアーキテクチャのカンマ区切りリスト。 `Incus-Server-Version` -: The version of Incus in use. +: 使用している Incus のバージョン。 diff --git a/doc/howto/images_create.md b/doc/howto/images_create.md index 9a2d0a31a1a..466aecd2286 100644 --- a/doc/howto/images_create.md +++ b/doc/howto/images_create.md @@ -1,41 +1,40 @@ (images-create)= -# How to create images +# イメージを作成するには -If you want to create and share your own images, you can do this either based on an existing instance or snapshot or by building your own image from scratch. +独自のイメージを作成し共有したい場合、既存のインスタンスやスナップショットをベースにすることもできますし、一から独自のイメージを作ることもできます。 (images-create-publish)= -## Publish an image from an instance or snapshot +## インスタンスやスナップショットからイメージを発行する -If you want to be able to use an instance or an instance snapshot as the base for new instances, you should create and publish an image from it. +インスタンスやインスタンススナップショットを新しいインスタンスのベースとして使いたい場合、それらからイメージを作成し発行するのが良いです。 -To publish an image from an instance, make sure that the instance is stopped. -Then enter the following command: +インスタンスからイメージを発行するには、インスタンスが停止されていることを確認してください。 +次に以下のコマンドを入力します: incus publish [:] -To publish an image from a snapshot, enter the following command: +スナップショットからイメージを発行するには、以下のコマンドを入力します: incus publish / [:] -In both cases, you can specify an alias for the new image with the `--alias` flag, set an expiration date with `--expire` and make the image publicly available with `--public`. -If an image with the same name already exists, add the `--reuse` flag to overwrite it. -See [`incus publish --help`](incus_publish.md) for a full list of available flags. +どちらの場合も`--alias`フラグで新しいイメージにエイリアスを設定し、`--expire`で有効期限を設定し、`--public`でイメージを公開状態にすることができます。 +同じ名前のイメージがすでに存在する場合は、`--reuse`フラグを追加して上書きします。 +利用可能なすべてのフラグ一覧は [`incus publish --help`](incus_publish.md) を参照してください。 -The publishing process can take quite a while because it generates a tarball from the instance or snapshot and then compresses it. -As this can be particularly I/O and CPU intensive, publish operations are serialized by Incus. +発行のプロセスはインスタンスやスナップショットから tarball を生成した後圧縮するため、かなりの時間がかかるかもしれません。特に I/O と CPU の負荷が高いため、発行の操作は Incus で直列化（訳注：1 つずつ順に実行）されます。 -### Prepare the instance for publishing +### 発行用にインスタンスを準備する -Before you publish an image from an instance, clean up all data that should not be included in the image. -Usually, this includes the following data: +インスタンスからイメージを発行する前に、イメージに含めるべきでないすべてのデータをクリーンアップしてください。 +通常、これは以下のデータを含みます: -- Instance metadata (use [`incus config metadata`](incus_config_metadata.md) to edit) -- File templates (use [`incus config template`](incus_config_template.md) to edit) -- Instance-specific data inside the instance itself (for example, host SSH keys and `dbus/systemd machine-id`) +- インスタンスメタデータ（編集には [`incus config metadata`](incus_config_metadata.md) を使ってください） +- ファイルテンプレート（編集には [`incus config template`](incus_config_template.md) を使ってください） +- インスタンス自身の内部のインスタンスに特有なデータ（たとえば、ホストの SSH 鍵と`dbus/systemd machine-id`） (images-create-build)= -## Build an image +## イメージをビルドする -For building your own images, you can use [`distrobuilder`](https://github.com/lxc/distrobuilder). +独自イメージをビルドするには、[`distrobuilder`](https://github.com/lxc/distrobuilder)が使用できます。 -See the [`distrobuilder` documentation](https://linuxcontainers.org/distrobuilder/docs/latest/) for instructions for installing and using the tool. +インストール手順とツールの使い方は[`distrobuilder`のドキュメント](https://distrobuilder.readthedocs.io/en/latest/)を参照してください。 diff --git a/doc/howto/images_manage.md b/doc/howto/images_manage.md index 83436baf05c..c71fd155f38 100644 --- a/doc/howto/images_manage.md +++ b/doc/howto/images_manage.md @@ -1,110 +1,110 @@ (images-manage)= -# How to manage images +# イメージを管理するには -When working with images, you can inspect various information about the available images, view and edit their properties and configure aliases to refer to specific images. -You can also export an image to a file, which can be useful to {ref}`copy or import it ` on another machine. +イメージを扱う際は、利用可能なイメージについての情報を調べたりプロパティを表示・編集したり、特定のイメージを参照するエイリアスを設定したりできます。 +またイメージをファイルにエクスポートすることもできます。これは他のマシンに{ref}`イメージをコピーしたりインポート `するのに便利です。 -## List available images +## 利用可能なイメージを一覧表示する -To list all images on a server, enter the following command: +サーバー上のすべてのイメージを一覧表示するには、以下のコマンドを入力します: incus image list [:] -If you do not specify a remote, the {ref}`default remote ` is used. +リモートを指定しない場合は、{ref}`デフォルトリモート `が使用されます。 (images-manage-filter)= -### Filter available images +### 利用可能なイメージをフィルタする -To filter the results that are displayed, specify a part of the alias or fingerprint after the command. -For example, to show all Ubuntu 22.04 images, enter the following command: +表示される結果をフィルタするには、コマンドの後にエイリアスかフィンガープリントの一部を指定します。 +たとえば、すべての Ubuntu 22.04 のイメージを表示するには、以下のコマンドを入力します: incus image list images: 22.04 -You can specify several filters as well. -For example, to show all Arm 64-bit Ubuntu 22.04 images, enter the following command: +複数のフィルタも指定可能です。 +たとえば、すべての Arm 64-bit の Ubuntu 22.04 のイメージを表示するには、以下のコマンドを入力します: incus image list images: 22.04 arm64 -To filter for properties other than alias or fingerprint, specify the filter in `=` format. -For example: +エイリアスとフィンガープリント以外のプロパティをフィルタするには、`=`形式でフィルタを指定します。 +たとえば: incus image list images: 22.04 architecture=x86_64 -## View image information +## イメージの情報を表示する -To view information about an image, enter the following command: +イメージの情報を表示するには、以下のコマンドを入力します: incus image info -As the image ID, you can specify either the image's alias or its fingerprint. -For a remote image, remember to include the remote server (for example, `images:ubuntu/22.04`). +イメージの ID としては、イメージのエイリアスかフィンガープリントを指定できます。 +リモートのイメージでは、リモートサーバーを忘れずに含めてください（たとえば、`images:ubuntu/22.04`）。 -To display only the image properties, enter the following command: +イメージのプロパティだけを表示するには、以下のコマンドを入力します: incus image show -You can also display a specific image property (located under the `properties` key) with the following command: +また、イメージの（`properties`キー配下にある）特定のプロパティは以下のコマンドで表示できます: incus image get-property -For example, to show the release name of the official Ubuntu 22.04 image, enter the following command: +たとえば、公式の Ubuntu 22.04 イメージのリリース名を表示するには、以下のコマンドを入力します: incus image get-property images:ubuntu/22.04 release (images-manage-edit)= -## Edit image properties +## イメージのプロパティを編集する -To set a specific image property that is located under the `properties` key, enter the following command: +`properties` キー配下にあるイメージの特定のプロパティを設定するには、以下のコマンドを入力します: incus image set-property ```{note} -These properties can be used to convey information about the image. -They do not configure Incus' behavior in any way. +これらのプロパティはイメージについての情報を伝えるために使用できます。 +これらはいかなる方法によっても Incus の挙動を変更はしません。 ``` -To edit the full image properties, including the top-level properties, enter the following command: +トップレベルのプロパティを含むイメージのプロパティ全体を編集するには、以下のコマンドを入力します: incus image edit -## Configure image aliases +## イメージのエイリアスを設定する -Configuring an alias for an image can be useful to make it easier to refer to an image, since remembering an alias is usually easier than remembering a fingerprint. -Most importantly, however, you can change an alias to point to a different image, which allows creating an alias that always provides a current image (for example, the latest version of a release). +イメージのエイリアスを設定すると、イメージを参照するのがより容易になり便利かもしれません。というのはエイリアスを覚えるほうがフィンガープリントを覚えるより通常容易だからです。 +しかし、もっとも重要なのは、エイリアスは別のイメージを指すように変更できるので、常に最新のイメージ（たとえば最新のリリースバージョン）を提供するエイリアスを作れることです。 -You can see some of the existing aliases in the image list. -To see the full list, enter the following command: +イメージ一覧の中に既存のエイリアスの例を見ることができます。 +完全なリストを見るには、以下のコマンドを入力します: incus image alias list -You can directly assign an alias to an image when you {ref}`copy or import ` or {ref}`publish ` it. -Alternatively, enter the following command: +イメージを{ref}`コピーやインポート `または{ref}`発行 `する際には、直接イメージにエイリアスを割り当てることができます。 +代わりに、以下のコマンドを入力してエイリアスを作成することもできます: incus image alias create -You can also delete an alias: +エイリアスは削除することもできます: incus image alias delete -To rename an alias, enter the following command: +エイリアスをリネームするには、以下のコマンドを入力します: incus image alias rename -If you want to keep the alias name, but point the alias to a different image (for example, a newer version), you must delete the existing alias and then create a new one. +エイリアスの名前を維持したまま、別の（たとえば、より新しいバージョンの）イメージにエイリアスを向けたい場合は、既存のエイリアスを削除して新しいエイリアスを作成する必要があります。 (images-manage-export)= -## Export an image to a file +## イメージをファイルにエクスポートする -Images are located in the image store of your local server or a remote Incus server. -You can export them to a file though. -This method can be useful to back up image files or to transfer them to an air-gapped environment. +イメージはローカルサーバーかリモートの Incus サーバーのイメージストアに保管されます。 +ですが、イメージをファイルにエクスポートすることができます。 +この方法はイメージファイルをバックアップしたり、エアギャップされた（訳注：セキュリティーを高めるために外部ネットワークから遮断された）環境にイメージを持っていくのに便利です。 -To export a container image to a file, enter the following command: +コンテナイメージをファイルにエクスポートするには、以下のコマンドを入力します: incus image export [:] [] -To export a virtual machine image to a file, add the `--vm` flag: +仮想マシンイメージをファイルにエクスポートするには、`--vm`フラグを追加します: incus image export [:] [] --vm -See {ref}`image-format` for a description of the file structure used for the image. +イメージに使用されるファイル構造の説明については{ref}`image-format`を参照してください。 diff --git a/doc/howto/images_profiles.md b/doc/howto/images_profiles.md index 57ab3e26cd7..449556c6bf9 100644 --- a/doc/howto/images_profiles.md +++ b/doc/howto/images_profiles.md @@ -1,22 +1,22 @@ (images-profiles)= -# How to associate profiles with an image +# イメージにプロファイルを関連付けるには -You can associate one or more profiles with a specific image. -Instances that are created from the image will then automatically use the associated profiles in the order they were specified. +特定のイメージに 1 つ以上のプロファイルを関連付けできます。 +イメージから作成されたインスタンスは関連付けられたプロファイルが指定された順に自動的に適用されます。 -To associate a list of profiles with an image, use the [`incus image edit`](incus_image_edit.md) command and edit the `profiles:` section: +イメージにプロファイルのリストを関連付けるには、 [`incus image edit`](incus_image_edit.md) コマンドを使って`profiles:`セクションを編集します: ```yaml profiles: - default ``` -Most provided images come with a profile list that includes only the `default` profile. -To prevent any profile (including the `default` profile) from being associated with an image, pass an empty list. +提供されているほとんどのイメージは`default`プロファイルだけを含むプロファイルリストが設定されています。 +（`default`プロファイルを含む）すべてのプロファイルがイメージに関連付けられないようにするには、空のリストを渡します。 ```{note} -Passing an empty list is different than passing `nil`. -If you pass `nil` as the profile list, only the `default` profile is associated with the image. +空のリストを渡すのは`nil`を渡すのとは異なります。 +プロファイルリストに`nil`を渡すとイメージに`default`プロファイルだけが関連付けられます。 ``` -You can override the associated profiles for an image when creating an instance by adding the `--profile` or the `--no-profiles` flag to the launch or init command. +launch または init コマンドに`--profile`または`--no-profiles`フラグを追加することで、イメージに関連付けられたプロファイルをインスタンス作成時にオーバーライドできます。 diff --git a/doc/howto/images_remote.md b/doc/howto/images_remote.md index 5633d16e6dc..f2e02ee19ee 100644 --- a/doc/howto/images_remote.md +++ b/doc/howto/images_remote.md @@ -1,77 +1,77 @@ (images-remote)= -# How to use remote images +# リモートイメージを使用するには -The [`incus`](incus.md) CLI command is pre-configured with several remote image servers. -See {ref}`remote-image-servers` for an overview. +[`incus`](incus.md) CLI コマンドはいくつかのリモートイメージサーバーを初期設定されています。 +概要は{ref}`remote-image-servers`を参照してください。 -## List configured remotes +## 設定されたリモートを一覧表示する -To see all configured remote servers, enter the following command: +設定されたすべてのリモートサーバーを見るには、以下のコマンドを入力します: incus remote list -Remote servers that use the [simple streams format](https://git.launchpad.net/simplestreams/tree/) are pure image servers. -Servers that use the `incus` format are Incus servers, which either serve solely as image servers or might provide some images in addition to serving as regular Incus servers. -See {ref}`remote-image-server-types` for more information. +[simple streams形式](https://git.launchpad.net/simplestreams/tree/)を使用するリモートサーバーは純粋なイメージサーバーです。 +`incus`形式を使用するサーバーは Incus サーバーであり、イメージサーバーだけとして稼働しているか、通常の Incus サーバーとして稼働するのに加えて追加のイメージを提供しているかのどちらかです。 +詳細は{ref}`remote-image-server-types`を参照してください。 -## List available images on a remote +## リモート上の利用可能なイメージを一覧表示する -To list all remote images on a server, enter the following command: +サーバー上のすべてのリモートイメージを一覧表示するには、以下のコマンドを入力します: incus image list : -You can filter the results. -See {ref}`images-manage-filter` for instructions. +結果をフィルタできます。 +手順は{ref}`images-manage-filter`を参照してください。 -## Add a remote server +## リモートサーバーを追加する -How to add a remote depends on the protocol that the server uses. +どのようにリモートを追加するかはサーバーが使用しているプロトコルに依存します。 -### Add a simple streams server +### simple streamsサーバーを追加する -To add a simple streams server as a remote, enter the following command: +simple streams サーバーをリモートとして追加するには、以下のコマンドを入力します: incus remote add --protocol=simplestreams -The URL must use HTTPS. +URL は HTTPS でなければなりません。 -### Add a remote Incus server +### リモートのIncusサーバーを追加する -To add a Incus server as a remote, enter the following command: +Incus サーバーをリモートして追加するには、以下のコマンドを入力します: incus remote add [flags] -Some authentication methods require specific flags (for example, use [`incus remote add --auth-type=oidc`](incus_remote_add.md) for OIDC authentication). -See {ref}`server-authenticate` and {ref}`authentication` for more information. +認証方法によっては固有のフラグが必要です（たとえば、OIDC 認証では[`incus remote add --auth-type=oidc`](incus_remote_add.md)を使います）。 +詳細は{ref}`server-authenticate`と{ref}`authentication`を参照してください。 -For example, enter the following command to add a remote through an IP address: +たとえば、IP アドレスを指定してリモートを追加するには以下のコマンドを入力します: incus remote add my-remote 192.0.2.10 -You are prompted to confirm the remote server fingerprint and then asked for the password or token, depending on the authentication method used by the remote. +リモートサーバーのフィンガープリントを確認するプロンプトが表示され、トークンの入力を求められます。 -## Reference an image +## イメージを参照する -To reference an image, specify its remote and its alias or fingerprint, separated with a colon. -For example: +イメージを参照するには、リモートとイメージのエイリアスまたはフィンガープリントをコロンで区切って指定します。 +例: images:ubuntu/22.04 images:ubuntu/22.04 local:ed7509d7e83f (images-remote-default)= -## Select a default remote +## デフォルトのリモートを選択する -If you specify an image name without the name of the remote, the default image server is used. +リモート名前を指定せずにイメージ名だけ指定すると、デフォルトのイメージサーバーが使用されます。 -To see which server is configured as the default image server, enter the following command: +どのサーバーがデフォルトのイメージサーバーと設定されているか表示するには、以下のコマンドを入力します: incus remote get-default -To select a different remote as the default image server, enter the following command: +別のリモートをデフォルトのイメージサーバーに選択するには、以下のコマンドを入力します: incus remote switch diff --git a/doc/howto/import_machines_to_instances.md b/doc/howto/import_machines_to_instances.md index 602aefd6848..13c2efd14cc 100644 --- a/doc/howto/import_machines_to_instances.md +++ b/doc/howto/import_machines_to_instances.md @@ -1,101 +1,102 @@ (import-machines-to-instances)= -# How to import physical or virtual machines to Incus instances +# 物理または仮想マシンを Incus インスタンスにインポートするには -Incus provides a tool (`incus-migrate`) to create a Incus instance based on an existing disk or image. -You can run the tool on any Linux machine. -It connects to a Incus server and creates a blank instance, which you can configure during or after the migration. -The tool then copies the data from the disk or image that you provide to the instance. +Incus は既存のディスクやイメージに基づく Incus インスタンスを作成するツール（`incus-migrate`）を提供しています。 + +このツールは Linux マシン上で実行できます。 +まず Incus サーバーに接続して空のインスタンスを作成します。このインスタンスはマイグレーション中またはマイグレーション後に設定を変更できます。 +次にこのツールはあなたが用意したディスクまたはイメージからインスタンスにデータをコピーします。 ```{note} -If you want to configure your new instance during the migration process, set up the entities that you want your instance to use before starting the migration process. +マイグレーションプロセスの最中に新しいインスタンスを設定したい場合は、マイグレーションプロセスを開始する前にあなたのインスタンスで使用したいエンティティをセットアップしてください。 -By default, the new instance will use the entities specified in the `default` profile. -You can specify a different profile (or a profile list) to customize the configuration. -See {ref}`profiles` for more information. -You can also override {ref}`instance-options`, the {ref}`storage pool ` to be used and the size for the {ref}`storage volume `, and the {ref}`network ` to be used. +デフォルトでは、新しいインスタンスは `default` プロファイルで指定されたエンティティを使用します。 +設定をカスタマイズするために異なるプロファイル（あるいはプロファイルのリスト）を設定できます。 +詳細は {ref}`profiles` を参照してください。 +また、使用される {ref}`instance-options`、{ref}`storage pool `、{ref}`ストレージボリューム `のサイズ、{ref}`network ` をオーバーライドできます。 -Alternatively, you can update the instance configuration after the migration is complete. +あるいは、マイグレーションの完了後にインスタンス設定を変更することもできます。 ``` -The tool can create both containers and virtual machines: +このツールはコンテナと仮想マシンの両方を作成できます: -* When creating a container, you must provide a disk or partition that contains the root file system for the container. - For example, this could be the `/` root disk of the machine or container where you are running the tool. -* When creating a virtual machine, you must provide a bootable disk, partition or image. - This means that just providing a file system is not sufficient, and you cannot create a virtual machine from a container that you are running. - It is also not possible to create a virtual machine from the physical machine that you are using to do the migration, because the migration tool would be using the disk that it is copying. - Instead, you could provide a bootable image, or a bootable partition or disk that is currently not in use. +* コンテナを作成する際は、コンテナのルートファイルシステムを含むディスクまたはパーティションを用意する必要があります。 + たとえば、これはあなたがツールを実行しているマシンまたはコンテナの `/` ルートディスクかもしれません。 +* 仮想マシンを作成する際は、起動可能なディスク、パーティション、またはイメージを用意する必要があります。 + これは単にファイルシステムを用意するだけでは不十分であり、実行中のコンテナから仮想マシンを作成することはできないことを意味します。 + また使用中の物理マシンから仮想マシンを作成することもできません。これはマイグレーションツールがコピーしようとするディスクを使用するからです。 + 代わりに、起動可能なディスク、起動可能なパーティション、または現在使用中でないディスクを用意してください。 ````{tip} - If you want to convert a Windows VM from a foreign hypervisor (not from QEMU/KVM with Q35/`virtio-scsi`), - you must install the `virtio-win` drivers to your Windows. Otherwise, your VM won't boot. + （Q35/`virtio-scsi` ありの QEMU/KVM 以外の）外部のハイパーバイザーから Windows VM を変換したい場合、 Windows に `virtio-win` ドライバーをインストールする必要があります。さもないと VM は起動しません。 +
- Expand to see how to integrate the required drivers to your Windows VM - Install the required tools on the host: + Windows VM にどのようにひすようなドライバーを統合するかを見るには展開 + ホスト上で必要なツールをインストール: - 1. Install `virt-v2v` version >= 2.3.4 (this is the minimal version that supports the `--block-driver` option). - 1. Install the `virtio-win` package, or download the [`virtio-win.iso`](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso) image and put it into the `/usr/share/virtio-win` folder. - 1. You might also need to install [`rhsrvany`](https://github.com/rwmjones/rhsrvany). + 1. `virt-v2v` バージョン 2.3.4 以上（これが `--block-driver` オプションに対応する最小バージョン）をインストール。 + 1. `virtio-win` パッケージをインストール、あるいは [`virtio-win.iso`](https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/stable-virtio/virtio-win.iso) イメージをダウンロードして `/usr/share/virtio-win` フォルダーに配置。 + 1. さらに [`rhsrvany`](https://github.com/rwmjones/rhsrvany) にインストールする必要がある場合もある。 - Now you can use `virt-v2v` to convert images from a foreign hypervisor to `raw` images for Incus and include the required drivers: + これで `virt-v2v` を使って外部のハイパーバイザーのイメージを Incus の `raw` イメージに変換して必要なドライバーを含められます: ``` - # Example 1. Convert a vmdk disk image to a raw image suitable for incus-migrate + # 例 1。vmdk ディスクイメージを incus-migrate に適した raw イメージに変換する sudo virt-v2v --block-driver virtio-scsi -o local -of raw -os ./os -i vmx ./test-vm.vmx - # Example 2. Convert a QEMU/KVM qcow2 image and integrate virtio-scsi driver + # 例 2。QEMU/KVM qcow2 イメージを変換し virtio-scsi ドライバーを統合する sudo virt-v2v --block-driver virtio-scsi -o local -of raw -os ./os -if qcow2 -i disk test-vm-disk.qcow2 ``` - You can find the resulting image in the `os` directory and use it with `incus-migrate` on the next steps. + 結果のイメージは `os` ディレクトリー内に生成され、次のステップで `incus-migrate` で使えます。
```` -Complete the following steps to migrate an existing machine to a Incus instance: +既存のマシンを Incus インスタンスにマイグレートするには以下の手順を実行してください: -1. Download the `bin.linux.incus-migrate` tool from the **Assets** section of the latest [Incus release](https://github.com/lxc/incus/releases). -1. Place the tool on the machine that you want to use to create the instance. - Make it executable (usually by running `chmod u+x bin.linux.incus-migrate`). -1. Make sure that the machine has `rsync` installed. - If it is missing, install it (for example, with `sudo apt install rsync`). -1. Run the tool: +1. 最新の [Incus release](https://github.com/lxc/incus/releases) の **Assets** セクションから `bin.linux.incus-migrate` ツールをダウンロードしてください。 +1. ツールをインスタンスを作成したいマシン上に配置して + （通常 `chmod u+x bin.linux.incus-migrate` を実行して）実行可能にしてください。 +1. マシンに `rsync` がインストールされているか確認してください。 + インストールされていない場合は（たとえば、`sudo apt install rsync` で）インストールしてください。 +1. ツールを実行します: sudo ./bin.linux.incus-migrate - The tool then asks you to provide the information required for the migration. + ツールはマイグレーションに必要な情報を入力するようプロンプトを出します。 ```{tip} - As an alternative to running the tool interactively, you can provide the configuration as parameters to the command. - See `./bin.linux.incus-migrate --help` for more information. + ツールをインタラクティブに実行する代わりの方法として、設定をパラメータでコマンドに指定することもできます。 + 詳細は `./bin.linux.incus-migrate --help` を参照してください。 ``` - 1. Specify the Incus server URL, either as an IP address or as a DNS name. + 1. Incus サーバーの URL を、 IP アドレスまたは DNS 名で指定してください。 ```{note} - The Incus server must be {ref}`exposed to the network `. - If you want to import to a local Incus server, you must still expose it to the network. - You can then specify `127.0.0.1` as the IP address to access the local server. + Incus サーバーは {ref}`ネットワークに公開 ` する必要があります。 + ローカルの Incus サーバーにインポートしたい場合も、それをネットワークに公開する必要があります。 + その後、ローカルサーバーにアクセスするには IP アドレスとして `127.0.0.1` を指定できます。 ``` - 1. Check and confirm the certificate fingerprint. - 1. Choose a method for authentication (see {ref}`authentication`). + 1. 証明書のフィンガープリントを確認してください。 + 1. 認証の方法を選択してください（{ref}`authentication` 参照）。 - For example, if you choose using a certificate token, log on to the Incus server and create a token for the machine on which you are running the migration tool with [`incus config trust add`](incus_config_trust_add.md). - Then use the generated token to authenticate the tool. - 1. Choose whether to create a container or a virtual machine. - See {ref}`containers-and-vms`. - 1. Specify a name for the instance that you are creating. - 1. Provide the path to a root file system (for containers) or a bootable disk, partition or image file (for virtual machines). - 1. For containers, optionally add additional file system mounts. - 1. For virtual machines, specify whether secure boot is supported. - 1. Optionally, configure the new instance. - You can do so by specifying {ref}`profiles `, directly setting {ref}`configuration options ` or changing {ref}`storage ` or {ref}`network ` settings. + たとえば、証明書トークンを選ぶ場合、 Incus サーバーにログオンしてマイグレーションツールを実行中のマシン用のトークンを [`incus config trust add`](incus_config_trust_add.md) で作成してください。 + 次に生成されたトークンを、ツールを認証するのに使用してください。 + 1. コンテナと仮想マシンのどちらを作成するか選択してください。 + {ref}`containers-and-vms` を参照してください。 + 1. 作成するインスタンスの名前を指定してください。 + 1. ルートファイルシステム（コンテナの場合）、起動可能なディスク、パーティションまたはイメージファイル（仮想マシンの場合）のパスを指定します。 + 1. コンテナの場合、必要に応じてファイルシステムのマウントを追加します。 + 1. 仮想マシンの場合、セキュアブートがサポートされているかを指定します。 + 1. 任意で、新しいインスタンスを設定します。 + {ref}`プロファイル `を指定するか、{ref}`設定オプション `や{ref}`ストレージ `を変更したり{ref}`ネットワーク `を設定する設定オプションを直接指定できます。 - Alternatively, you can configure the new instance after the migration. - 1. When you are done with the configuration, start the migration process. + あるいは、マイグレーション後に新しいインスタンスを設定することもできます。 + 1. マイグレーションの設定が完了したら、マイグレーションプロセスを開始します。
- Expand to see an example output for importing to a container + コンテナにインポートする出力例を見るには展開 ```{terminal} :input: sudo ./bin.linux.incus-migrate @@ -199,7 +200,7 @@ Complete the following steps to migrate an existing machine to a Incus instance:
- Expand to see an example output for importing to a VM + 仮想マシンにインポートする出力例を見るには展開 ```{terminal} :input: sudo ./bin.linux.incus-migrate @@ -307,5 +308,5 @@ Complete the following steps to migrate an existing machine to a Incus instance: ```
-1. When the migration is complete, check the new instance and update its configuration to the new environment. - Typically, you must update at least the storage configuration (`/etc/fstab`) and the network configuration. +1. マイグレーションが完了したら、新しいインスタンスをチェックし、設定を新しい環境にあわせて更新してください。 + 通常は、少なくともストレージ設定（`/etc/fstab`）とネットワーク設定を更新する必要があります。 diff --git a/doc/howto/incus_alias.md b/doc/howto/incus_alias.md index dd0ecca2da4..273627bc230 100644 --- a/doc/howto/incus_alias.md +++ b/doc/howto/incus_alias.md @@ -1,14 +1,14 @@ (incus-alias)= -# How to add command aliases +# コマンドエイリアスを追加するには -The Incus command-line client supports adding aliases for commands that you use frequently. -You can use aliases as shortcuts for longer commands, or to automatically add flags to existing commands. +Incus コマンドラインクライアントでは良く使うコマンドのエイリアスを追加できます。 +長いコマンドのショートカットとして、あるいは既存のコマンドに自動的にフラグを追加するために、エイリアスを使用できます。 -To manage command aliases, you use the [`incus alias`](incus_alias.md) command. +コマンドエイリアスを管理するには、[`incus alias`](incus_alias.md)コマンドを使用します。 -For example, to always ask for confirmation when deleting an instance, create an alias for `incus delete` that always runs `incus delete -i`: +たとえば、インスタンスを削除する際に必ず確認を求めるようにするには`incus delete`に常に`incus delete -i`を実行するようにエイリアスを作成します: - incus alias add delete "delete -i" + lxc alias add delete "delete -i" -To see all configured aliases, run [`incus alias list`](incus_alias_list.md). -Run [`incus alias --help`](incus_alias.md) to see all available subcommands. +登録されたすべてののエイリアスを表示するには[`incus alias list`](incus_alias_list.md)を実行します。 +すべての利用可能なサブコマンドを表示するには[`incus alias --help`](incus_alias.md)を実行してください。 diff --git a/doc/howto/initialize.md b/doc/howto/initialize.md index b4dfb248ec3..8ee1a277bf8 100644 --- a/doc/howto/initialize.md +++ b/doc/howto/initialize.md @@ -1,84 +1,84 @@ (initialize)= -# How to initialize Incus +# Incusを初期化するには -Before you can create a Incus instance, you must configure and initialize Incus. +Incus のインスタンスを作成する前に、Incus の設定と初期化をする必要があります。 -## Interactive configuration +## 対話式の設定 -Run the following command to start the interactive configuration process: +対話式の設定プロセスを開始するには以下のコマンドを実行します。 incus admin init ```{note} -For simple configurations, you can run this command as a normal user. -However, some more advanced operations during the initialization process (for example, joining an existing cluster) require root privileges. -In this case, run the command with `sudo` or as root. +シンプルな設定では、このコマンドは通常ユーザで実行できます。 +しかし、初期化プロセス中により高度な操作（例えば、既存のクラスタに参加するなど）を行う際はroot権限が必要な場合があります。 +この場合は、コマンドを`sudo`付きで実行するかrootユーザで実行してください。 ``` -The tool asks a series of questions to determine the required configuration. -The questions are dynamically adapted to the answers that you give. -They cover the following areas: +このツールは必要な設定を決定するために一連の質問をします。 +質問はあなたが入力した回答に応じて動的に調整されます。 +質問は以下の領域をカバーします。 -Clustering (see {ref}`exp-clustering` and {ref}`cluster-form`) -: A cluster combines several Incus servers. - The cluster members share the same distributed database and can be managed uniformly using the Incus client ([`incus`](incus.md)) or the REST API. +クラスタリング({ref}`exp-clustering`と{ref}`cluster-form`参照) +: クラスタは複数の Incus サーバーを結合します。 + クラスタメンバーは同じ分散データベースを共有し、Incus クライアント(`incus`)や REST APIT を使って統一的に管理できます。 - The default answer is `no`, which means clustering is not enabled. - If you answer `yes`, you can either connect to an existing cluster or create one. + デフォルトの回答は`no`で、クラスタリングは有効化されません。 + `yes`と回答すると、既存のクラスタに接続するか、クラスタを新規作成できます。 -Networking (see {ref}`networks` and {ref}`Network devices `) -: Provides network access for the instances. +ネットワーク（{ref}`networks`と{ref}`ネットワークデバイス `参照） +: インスタンスにネットワークへのアクセスを提供します。 - You can let Incus create a new bridge (recommended) or use an existing network bridge or interface. + Incus に新しいブリッジを作成させる（推奨）こともできますし、既存のネットワークブリッジやインターフェースを使うこともできます。 - You can create additional bridges and assign them to instances later. + 後から追加のブリッジを作成して、インスタンスに割り当てることもできます。 -Storage pools (see {ref}`exp-storage` and {ref}`storage-drivers`) -: Instances (and other data) are stored in storage pools. +ストレージプール（{ref}`exp-storage`と{ref}`storage-drivers`参照） +: インスタンス（とほかのデータ）はストレージプール内に保管されます。 - For testing purposes, you can create a loop-backed storage pool. - For production use, however, you should use an empty partition (or full disk) instead of loop-backed storage (because loop-backed pools are slower and their size can't be reduced). + お試し用にはループバックベースのストレージプールを作ることもできます。 + しかし、本番環境での利用には、ループバックベースのストレージではなく空のパーティション（または完全なディスク）を使うほうが良いです（ループバックベースのストレージのほうが遅くサイズを縮小できないため）。 - The recommended backends are `zfs` and `btrfs`. + お勧めのバックエンドは`zfs`と`btrfs`です。 - You can create additional storage pools later. + 後から追加のストレージブールを作成できます。 -Remote access (see {ref}`security_remote_access` and {ref}`authentication`) -: Allows remote access to the server over the network. +リモートアクセス（{ref}`security_remote_access`と{ref}`authentication`参照） +: ネットワーク越しにサーバーへリモートアクセスできるようにします。 - The default answer is `no`, which means remote access is not allowed. - If you answer `yes`, you can connect to the server over the network. + デフォルトの回答は`no`で、リモートアクセスは有効化されません。 + `yes`と回答すると、ネットワーク越しにサーバーへ接続できます。 - You can choose to add client certificates to the server (manually or through tokens, the recommended way) or set a trust password. + サーバーにクライアント証明書を追加する(手動にてあるいはトークンを使用して)ことを選択できます。 -Automatic image update (see {ref}`about-images`) -: You can download images from image servers. - In this case, images can be updated automatically. +イメージの自動更新（{ref}`about-images`参照） +: イメージサーバーからイメージをダウンロードできます。 + この場合、イメージを自動的に更新できます。 - The default answer is `yes`, which means that Incus will update the downloaded images regularly. + デフォルトの回答は`yes`で、Incus はダウンロードされたイメージを定期的に更新します。 -YAML `incus admin init` preseed (see {ref}`initialize-preseed`) -: If you answer `yes`, the command displays a summary of your chosen configuration options in the terminal. +YAML `incus admin init` プリシード（{ref}`initialize-preseed`参照） +: `yes`と回答すると、このコマンドはあなたが選択した設定オプションのサマリをターミナルに表示します。 -### Minimal setup +### 最小構成のセットアップ -To create a minimal setup with default options, you can skip the configuration steps by adding the `--minimal` flag to the `incus admin init` command: +デフォルトのオプションで最小構成のセットアップを作成する場合は、`incus admin init`コマンドに`--minimal`フラグを追加することで、設定の行程をスキップできます。 incus admin init --minimal ```{note} -The minimal setup provides a basic configuration, but the configuration is not optimized for speed or functionality. -Especially the [`dir` storage driver](storage-dir), which is used by default, is slower than other drivers and doesn't provide fast snapshots, fast copy/launch, quotas and optimized backups. +最小構成のセットアップは基本的な設定は提供しますが、設定は速度や機能に最適化されません。 +特に、デフォルトで使用される[`dir`ストレージドライバ](storage-dir)は他のドライバより遅く、高速なスナップショット、インスタンスのコピーや起動、クォータや最適化されたバックアップを提供しません。 -If you want to use an optimized setup, go through the interactive configuration process instead. +最適化された環境を使いたい場合は、代わりに対話式の設定プロセスを行ってください。 ``` (initialize-preseed)= -## Non-interactive configuration +## 非対話式の設定 -The `incus admin init` command supports a `--preseed` command line flag that makes it possible to fully configure the Incus daemon settings, storage pools, network devices and profiles, in a non-interactive way through a preseed YAML file. +`incus admin init`コマンドは`--preseed`コマンドラインオプションをサポートし、Incus デーモンの設定、ストレージプール、ネットワークデバイス、プロファイルを YAML プリシードファイルを使って非対話的に設定できます。 -For example, starting from a brand new Incus installation, you could configure Incus with the following command: +たとえば、完全に新しく Incus をインストールした状態から始める場合、以下のコマンドで Incus を設定できます。 ```bash cat </ -For example, to edit the `/etc/hosts` file in the instance, enter the following command: +たとえば、インスタンス内の `/etc/hosts` ファイルを編集するには、以下のコマンドを入力します: incus file edit my-container/etc/hosts ```{note} -The file must already exist on the instance. -You cannot use the `edit` command to create a file on the instance. +ファイルはインスタンス上に既に存在している必要があります。 +インスタンス上にファイルを作成するのに `edit` コマンドは使えません。 ``` -## Delete files from the instance +## インスタンスからファイルを削除する -To delete a file from your instance, enter the following command: +インスタンスからファイルを削除するには、以下のコマンドを入力します: incus file delete / -## Pull files from the instance to the local machine +## インスタンスからローカルマシンにファイルをプルする -To pull a file from your instance to your local machine, enter the following command: +インスタンスからローカルマシンにファイルをプルするには、以下のコマンドを入力します: incus file pull / -For example, to pull the `/etc/hosts` file to the current directory, enter the following command: +たとえば `/etc/hosts` ファイルをカレントディレクトリーにプルするには、以下のコマンドを入力します: incus file pull my-instance/etc/hosts . -Instead of pulling the instance file into a file on the local system, you can also pull it to stdout and pipe it to stdin of another command. -This can be useful, for example, to check a log file: +インスタンスのファイルをローカルマシンにプルする代わりに、標準出力にプルして別のコマンドの標準入力にパイプすることもできます。 +これは、たとえば、ログファイルをチェックするのに便利です: incus file pull my-instance/var/log/syslog - | less -To pull a directory with all contents, enter the following command: +ディレクトリーのすべての中身をプルするには、以下のコマンドを入力します: incus file pull -r / -## Push files from the local machine to the instance +## ローカルマシンからインスタンスにファイルをプッシュする -To push a file from your local machine to your instance, enter the following command: +ローカルマシンからインスタンスにファイルをプッシュするには、以下のコマンドを入力します: incus file push / -To push a directory with all contents, enter the following command: +ディレクトリーのすべての中身をプッシュするには、以下のコマンドを入力します: incus file push -r / -## Mount a file system from the instance +## インスタンスのファイルシステムをマウントする -You can mount an instance file system into a local path on your client. +インスタンスのファイルシステムをクライアントのローカルパスにマウントできます。 -To do so, make sure that you have `sshfs` installed. +そうするためには、`sshfs` がインストールされていることを確認してください。 incus file mount / -You can then access the files from your local machine. +これでローカルマシンからファイルにアクセスできます。 -### Set up an SSH SFTP listener +### SSH SFTP リスナーをセットアップする -Alternatively, you can set up an SSH SFTP listener. -This method allows you to connect with any SFTP client and with a dedicated user name. +別の方法として、SSH SFTP リスナーをセットアップすることもできます。 +この方法では任意の SFTP クライアントで専用のユーザー名で接続できます。 -To do so, first set up the listener by entering the following command: +そうするには、まず以下のコマンドを入力してリスナーをセットアップします: incus file mount [--listen
:] -For example, to set up the listener on a random port on the local machine (for example, `127.0.0.1:45467`): +たとえば、ローカルマシン上のランダムなポート（たとえば、`127.0.0.1:45467`）にリスナーをセットアップするには以下のようにします: incus file mount my-instance -If you want to access your instance files from outside your local network, you can pass a specific address and port: +ローカルネットワークの外側からインスタンスのファイルにアクセスしたい場合、特定のアドレスとポートを渡せます: incus file mount my-instance --listen 192.0.2.50:2222 ```{caution} -Be careful when doing this, because it exposes your instance remotely. +あなたのインスタンスをリモートに公開することになるので、これを実行する際には注意してください。 ``` -To set up the listener on a specific address and a random port: +特定のアドレスとランダムなポートでリスナーをセットアップするには以下のようにします: incus file mount my-instance --listen 192.0.2.50:0 -The command prints out the assigned port and a user name and password for the connection. +コマンドは割り当てられたポートと接続に使用するユーザー名とパスワードを出力します。 ```{tip} -You can specify a user name by passing the `--auth-user` flag. +`--auth-user` フラグを渡すとユーザ名を指定できます。 ``` -Use this information to access the file system. -For example, if you want to use `sshfs` to connect, enter the following command: +この情報を使ってファイルシステムにアクセスします。 +たとえば `sshfs` で接続するには、以下のコマンドを入力します: sshfs @
: -p -For example: +たとえば以下のようにします: sshfs xFn8ai8c@127.0.0.1:/home my-instance-files -p 35147 -You can then access the file system of your instance at the specified location on the local machine. +これでインスタンスのファイルシステムをローカルマシン上の指定の場所でアクセスできます。 diff --git a/doc/howto/instances_backup.md b/doc/howto/instances_backup.md index 79717516f16..0e82830cdeb 100644 --- a/doc/howto/instances_backup.md +++ b/doc/howto/instances_backup.md @@ -5,9 +5,9 @@ myst: --- (instances-backup)= -# How to back up instances +# インスタンスをバックアップするには -There are different ways of backing up your instances: +インスタンスをバックアップするにはいくつかの方法があります: - {ref}`instances-snapshots` - {ref}`instances-backup-export` @@ -20,18 +20,18 @@ There are different ways of backing up your instances: ``` ```{note} -Custom storage volumes might be attached to an instance, but they are not part of the instance. -Therefore, the content of a custom storage volume is not stored when you back up your instance. -You must back up the data of your storage volume separately. -See {ref}`howto-storage-backup-volume` for instructions. +カスタムストレージボリュームがインスタンスにアタッチされているかもしれませんが、それらはインスタンスの一部ではありません。 +ですので、インスタンスをバックアップする際カスタムストレージボリュームは保存されません。 +ストレージボリュームのデータは別途バックアップする必要があります。 +手順は {ref}`howto-storage-backup-volume` を参照してください。 ``` (instances-snapshots)= -## Use snapshots for instance backup +## インスタンスのバックアップにスナップショットを使用する -You can save your instance at a point in time by creating an instance snapshot, which makes it easy to restore the instance to a previous state. +特定の日時のインスタンスをスナップショットを作成することで保存できます。スナップショットを使えばインスタンスを以前の状態に簡単に復元できます。 -Instance snapshots are stored in the same storage pool as the instance volume itself. +インスタンススナップショットはインスタンスのボリューム自身と同じストレージプールに保存されます。 % Include content from [storage_backup_volume.md](storage_backup_volume.md) ```{include} storage_backup_volume.md @@ -39,9 +39,9 @@ Instance snapshots are stored in the same storage pool as the instance volume it :end-before: ``` -### Create a snapshot +### スナップショットを作成する -Use the following command to create a snapshot of an instance: +インスタンスのスナップショットを作成するには以下のコマンドを使います: incus snapshot create [] @@ -51,77 +51,77 @@ Use the following command to create a snapshot of an instance: :end-before: ``` -For virtual machines, you can add the `--stateful` flag to capture not only the data included in the instance volume but also the running state of the instance. -Note that this feature is not fully supported for containers because of CRIU limitations. +仮想マシンでは、 `--stateful` フラグを指定するとインスタンスボリュームに含まれるデータだけでなく、インスタンスの稼働状態も含めることができます。 +CRIU の制限のためコンテナではこの機能は完全にはサポートされていないことに注意してください。 -### View, edit or delete snapshots +### スナップショットを表示、編集、削除する -Use the following command to display the snapshots for an instance: +インスタンスのスナップショットを表示するには以下のコマンドを使います: incus info -You can view or modify snapshots in a similar way to instances, by referring to the snapshot with `/`. +スナップショットを `/` で参照することで、インスタンスの場合と同様にスナップショットを表示または変更できます。 -To show configuration information about a snapshot, use the following command: +スナップショットの設定を表示するには、以下のコマンドを使います: incus config show / -To change the expiry date of a snapshot, use the following command: +スナップショットの有効期限を変更するには、以下のコマンドを使います: incus config edit / ```{note} -In general, snapshots cannot be edited, because they preserve the state of the instance. -The only exception is the expiry date. -Other changes to the configuration are silently ignored. +一般に、スナップショットはインスタンスの状態を保存しているため、編集できません。 +唯一の例外が有効期限です。 +他の設定の変更は黙って無視されます。 ``` -To delete a snapshot, use the following command: +スナップショットを削除するには、以下のコマンドを使います: incus delete / -### Schedule instance snapshots +### インスタンスのスナップショット作成をスケジュールする -You can configure an instance to automatically create snapshots at specific times (at most once every minute). -To do so, set the {config:option}`instance-snapshots:snapshots.schedule` instance option. +指定した時刻（最大で 1 分ごと）に自動的にスナップショットを作成するようにインスタンスを設定できます。 +そのためには、 {config:option}`instance-snapshots:snapshots.schedule` インスタンスオプションを設定してください。 -For example, to configure daily snapshots, use the following command: +たとえば、日次のスナップショットを設定するには、以下のコマンドを使います: incus config set snapshots.schedule @daily -To configure taking a snapshot every day at 6 am, use the following command: +毎日 AM 6 時にスナップショットを作成するよう設定するには、以下のコマンドを使います: incus config set snapshots.schedule "0 6 * * *" -When scheduling regular snapshots, consider setting an automatic expiry ({config:option}`instance-snapshots:snapshots.expiry`) and a naming pattern for snapshots ({config:option}`instance-snapshots:snapshots.pattern`). -You should also configure whether you want to take snapshots of instances that are not running ({config:option}`instance-snapshots:snapshots.schedule.stopped`). +定期的にスナップショットをスケジュールする際、自動破棄（{config:option}`instance-snapshots:snapshots.expiry`）とスナップショットの命名規則（{config:option}`instance-snapshots:snapshots.pattern`）の設定も検討してください。 +また、稼働していないインスタンスのスナップショットを作成するかどうかの設定（{config:option}`instance-snapshots:snapshots.schedule.stopped`）もすると良いでしょう。 -### Restore an instance snapshot +### インスタンスのスナップショットをリストアする -You can restore an instance to any of its snapshots. +インスタンスを任意のスナップショットの状態に復元できます。 -To do so, use the following command: +そのためには、以下のコマンドを使います: incus snapshot restore -If the snapshot is stateful (which means that it contains information about the running state of the instance), you can add the `--stateful` flag to restore the state. +スナップショットがステートフル（インスタンスの稼働状態の情報を含むことを意味します）の場合、状態をリストアするために `--stateful` を追加できます。 (instances-backup-export)= -## Use export files for instance backup +## インスタンスのバックアップにエクスポートファイルを使用する -You can export the full content of your instance to a standalone file that can be stored at any location. -For highest reliability, store the backup file on a different file system to ensure that it does not get lost or corrupted. +インスタンスの完全な内容をスタンドアロンのファイルにエクスポートし、任意の場所に保存できます。 +信頼度を最大化するため、失われたり壊れたりしないように、バックアップファイルは別のファイルシステムに保存してください。 -### Export an instance +### インスタンスをエクスポートする -Use the following command to export an instance to a compressed file (for example, `/path/to/my-instance.tgz`): +以下のコマンドを使ってインスタンスを圧縮ファイル（たとえば、`/path/to/my-instance.tgz`）にエクスポートします: incus export [] -If you do not specify a file path, the export file is saved as `.` in the working directory (for example, `my-container.tar.gz`). +ファイルパスを指定しない場合、エクスポートファイルは作業ディレクトリーに `.` （たとえば、`my-container.tar.gz`）という名前で保存されます。 ```{warning} -If the output file (`.` or the specified file path) already exists, the command overwrites the existing file without warning. +出力ファイル（`.` または指定した名前）がすでに存在する場合、コマンドは警告なしで既存のファイルを上書きします。 ``` % Include content from [storage_backup_volume.md](storage_backup_volume.md) @@ -131,23 +131,23 @@ If the output file (`.` or the specified file path) al ``` `--instance-only` -: By default, the export file contains all snapshots of the instance. - Add this flag to export the instance without its snapshots. +: デフォルトでは、エクスポートファイルはインスタンスのすべてのスナップショットを含みます。 + このフラグを追加すると、スナップショットを除いたインスタンスのみをエクスポートします。 -### Restore an instance from an export file +### エクスポートファイルからインスタンスをリストアする -You can import an export file (for example, `/path/to/my-backup.tgz`) as a new instance. -To do so, use the following command: +エクスポートファイル（たとえば、 `/path/to/my-backup.tgz`）を新しいインスタンスとしてインポートできます。 +そのためには、以下のコマンドを使用します: incus import [] -If you do not specify an instance name, the original name of the exported instance is used for the new instance. -If an instance with that name already (or still) exists in the specified storage pool, the command returns an error. -In that case, either delete the existing instance before importing the backup or specify a different instance name for the import. +インスタンス名を指定しない場合、新しいインスタンスの名前はエクスポートされたインスタンスの元の名前になります。 +その名前のインスタンスが指定したストレージブールにすでに（あるいはまだ）存在する場合、コマンドはエラーを返します。 +その場合、バックアップをインポートする前に既存のインスタンスを削除するか、あるいはインポートの際に別のインスタンス名を指定してください。 (instances-backup-copy)= -## Copy an instance to a backup server +## インスタンスをバックアップサーバーにコピーする -You can copy an instance to a secondary backup server to back it up. +インスタンスをバックアップするためにセカンダリバックアップサーバーにコピーできます。 -See {ref}`move-instances` for instructions. +手順は {ref}`move-instances` を参照してください。 diff --git a/doc/howto/instances_configure.md b/doc/howto/instances_configure.md index 3321c43d799..f26e052ae98 100644 --- a/doc/howto/instances_configure.md +++ b/doc/howto/instances_configure.md @@ -1,265 +1,199 @@ (instances-configure)= -# How to configure instances +# インスタンスを設定するには -You can configure instances by setting {ref}`instance-properties`, {ref}`instance-options`, or by adding and configuring {ref}`devices`. +{ref}`instance-properties` か {ref}`instance-options` を設定するか {ref}`devices` を追加し設定することでインスタンスを設定できます。 -See the following sections for instructions. +設定方法は以下の項を参照してください。 ```{note} -To store and reuse different instance configurations, use {ref}`profiles `. +異なるインスタンス設定を保管し再利用するには、{ref}`プロファイル ` を使用してください。 ``` (instances-configure-options)= -## Configure instance options +## インスタンスオプションを設定する -You can specify instance options when you {ref}`create an instance `. -Alternatively, you can update the instance options after the instance is created. +{ref}`インスタンスを作成する ` 際にインスタンスオプションを指定できます。 +あるいは、インスタンス作成後にインスタンスオプションを変更できます。 ````{tabs} ```{group-tab} CLI -Use the [`incus config set`](incus_config_set.md) command to update instance options. -Specify the instance name and the key and value of the instance option: +[`incus config set`](incus_config_set.md) コマンドを使ってインスタンスオプションを変更できます。 +インスタンス名とインスタンスオプションのキーとバリューを指定します: incus config set = = ... ``` ```{group-tab} API -Send a PATCH request to the instance to update instance options. -Specify the instance name and the key and value of the instance option: +インスタンスに PATCH リクエストを送るとインスタンスオプションを変更します。 +インスタンス名とインスタンスオプションのキーとバリューを指定します: incus query --request PATCH /1.0/instances/ --data '{"config": {"":"","":""}}' -See [`PATCH /1.0/instances/{name}`](swagger:/instances/instance_patch) for more information. -``` - -```{group-tab} UI -To update instance options, go to the {guilabel}`Configuration` tab of the instance detail page and click {guilabel}`Edit instance`. - -Find the configuration option that you want to update and change its value. -Click {guilabel}`Save changes` to save the updated configuration. - -To configure instance options that are not displayed in the UI, follow the instructions in {ref}`instances-configure-edit`. +詳細は [`PATCH /1.0/instances/{name}`](swagger:/instances/instance_patch) を参照してください。 ``` ```` -See {ref}`instance-options` for a list of available options and information about which options are available for which instance type. +利用可能なオプションの一覧とどのオプションがどのインスタンスタイプで利用可能かの情報は {ref}`instance-options` を参照してください。 -For example, change the memory limit for your container: +たとえば、コンテナのメモリーリミットを変更するには: ````{tabs} ```{group-tab} CLI -To set the memory limit to 8 GiB, enter the following command: +メモリーリミットを 8 GiB に設定するには、以下のコマンドを入力します: incus config set my-container limits.memory=8GiB ``` ```{group-tab} API -To set the memory limit to 8 GiB, send the following request: +メモリーリミットを 8 GiB に設定するには、以下のリクエストを送ります: incus query --request PATCH /1.0/instances/my-container --data '{"config": {"limits.memory":"8GiB"}}' ``` - -```{group-tab} UI -To set the memory limit to 8 GiB, go to the {guilabel}`Configuration` tab of the instance detail page and select {guilabel}`Advanced > Resource limits`. -Then click {guilabel}`Edit instance`. - -Select {guilabel}`Override` for the **Memory limit** and enter 8 GiB as the absolute value. - -![Setting the memory limit for an instance to 8 GiB](/images/UI/limits_memory_example.png) -``` ```` ```{note} -Some of the instance options are updated immediately while the instance is running. -Others are updated only when the instance is restarted. +一部のインスタンスオプションはインスタンスが稼働中に即座に更新されます。 +他のインスタンスオプションはインスタンスの再起動後に更新されます。 -See the "Live update" information in the {ref}`instance-options` reference for information about which options are applied immediately while the instance is running. +どのオプションがインスタンス稼働中に即座に反映されるかの情報は {ref}`instance-options` の "ライブアップデート" 列を参照してください。 ``` (instances-configure-properties)= -## Configure instance properties +## インスタンスプロパティを設定する ````{tabs} ```{group-tab} CLI -To update instance properties after the instance is created, use the [`incus config set`](incus_config_set.md) command with the `--property` flag. -Specify the instance name and the key and value of the instance property: +インスタンス作成後にインスタンスプロパティを変更するには、 `--property` フラグを指定して [`incus config set`](incus_config_set.md) コマンドを使います。 +インスタンス名とインスタンスプロパティのキーとバリューを指定します: incus config set = = ... --property -Using the same flag, you can also unset a property just like you would unset a configuration option: +同じフラグを使って、設定オプションを解除するのと全く同じようにインスタンスプロパティも設定解除できます: incus config unset --property -You can also retrieve a specific property value with: +指定したプロパティの値を取得もできます: incus config get --property ``` ```{group-tab} API -To update instance properties through the API, use the same mechanism as for configuring instance options. -The only difference is that properties are on the root level of the configuration, while options are under the `config` field. +API でインスタンスプロパティを変更するには、インスタンスオプションの変更と同じ仕組みを使います。 +唯一の違いはプロパティは設定の root レベルにありますが、オプションは `config` フィールドは以下にあることです。 -Therefore, to set an instance property, send a PATCH request to the instance: +ですので、インスタンスプロパティを設定するには、インスタンスに PATCH リクエストを送ります: incus query --request PATCH /1.0/instances/ --data '{"":"","":"property_value>"}}' -To unset an instance property, send a PUT request that contains the full instance configuration that you want except for the property that you want to unset. +インスタンスプロパティを設定解除するには、設定解除したいプロパティを除いた完全なインスタンス設定を含む PUT リクエストをくります。 -See [`PATCH /1.0/instances/{name}`](swagger:/instances/instance_patch) and [`PUT /1.0/instances/{name}`](swagger:/instances/instance_put) for more information. -``` - -```{group-tab} UI -The Incus UI does not distinguish between instance options and instance properties. -Therefore, you can configure instance properties in the same way as you {ref}`configure instance options `. +詳細は [`PATCH /1.0/instances/{name}`](swagger:/instances/instance_patch) と [`PUT /1.0/instances/{name}`](swagger:/instances/instance_put) を参照してください。 ``` ```` (instances-configure-devices)= -## Configure devices +## デバイスを設定する -Generally, devices can be added or removed for a container while it is running. -VMs support hotplugging for some device types, but not all. +一般的に、デバイスはコンテナの稼働中に追加または削除できます。 +仮想マシンはいくつかのデバイスタイプではホットプラグをサポートしますが、すべてではありません。 -See {ref}`devices` for a list of available device types and their options. +利用可能なデバイスタイプとそのオプションについては {ref}`devices` を参照してください。 ```{note} -Every device entry is identified by a name unique to the instance. +各デバイスのエントリはインスタンスごとにユニークな名前により識別します。 -Devices from profiles are applied to the instance in the order in which the profiles are assigned to the instance. -Devices defined directly in the instance configuration are applied last. -At each stage, if a device with the same name already exists from an earlier stage, the whole device entry is overridden by the latest definition. +プロファイルに定義されたデバイスは、プロファイルがインスタンスに割り当てられる順番でインスタンスに適用されます。 +インスタンス設定内に直接定義されたデバイスは最後に適用されます。 +各ステージで、より以前のステージに同じ名前のデバイスがある場合は、デバイスエントリ全体が最後の定義により上書きされます。 -Device names are limited to a maximum of 64 characters. +デバイス名は最大64文字です。 ``` `````{tabs} ````{group-tab} CLI -To add and configure an instance device for your instance, use the [`incus config device add`](incus_config_device_add.md) command. +インスタンスにデバイスを追加して設定するには、 [`incus config device add`](incus_config_device_add.md) コマンドを使います。 -Specify the instance name, a device name, the device type and maybe device options (depending on the {ref}`device type `): +インスタンス名、デバイス名、デバイスタイプと ({ref}`デバイスタイプ ` ごとに) 必要に応じてデバイスオプションを指定します: incus config device add = = ... -For example, to add the storage at `/share/c1` on the host system to your instance at path `/opt`, enter the following command: +例えば、ホストシステムの `/share/c1` 上のストレージをインスタンスのパス `/opt` に追加するには、以下のコマンドを入力します: incus config device add my-container disk-storage-device disk source=/share/c1 path=/opt -To configure instance device options for a device that you have added earlier, use the [`incus config device set`](incus_config_device_set.md) command: +以前追加したデバイスのインスタンスデバイスオプションを設定するには、 [`incus config device set`](incus_config_device_set.md) コマンドを使います: incus config device set = = ... ```{note} -You can also specify device options by using the `--device` flag when {ref}`creating an instance `. -This is useful if you want to override device options for a device that is provided through a {ref}`profile `. +デバイスオプションは {ref}`インスタンスの作成 ` 時に `--device` フラグを使って指定することもできます。 +これは {ref}`プロファイル ` を通して提供されるデバイスのデバイスオプションを上書きしたい場合に有用です。 ``` -To remove a device, use the [`incus config device remove`](incus_config_device_remove.md) command. -See [`incus config device --help`](incus_config_device.md) for a full list of available commands. +デバイスを除去するには、[`incus config device remove`](incus_config_device_remove.md) コマンドを使います。 +利用可能なコマンドの完全なリストは [`incus config device --help`](incus_config_device.md) を参照してください。 + ```` ````{group-tab} API -To add and configure an instance device for your instance, use the same mechanism of patching the instance configuration. -The device configuration is located under the `devices` field of the configuration. +インスタンスにデバイスを追加して設定するには、インスタンス設定を変更するのと同じ仕組みを使います。 +デバイス設定は設定の `devices` フィールドの下に配置されています。 -Specify the instance name, a device name, the device type and maybe device options (depending on the {ref}`device type `): +インスタンス名、デバイス名、デバイスタイプと ({ref}`デバイスタイプ ` ごとに) 必要に応じてデバイスオプションを指定します: incus query --request PATCH /1.0/instances/ --data '{"devices": {"": {"type":"","":"","":"device_option_value>"}}}' -For example, to add the storage at `/share/c1` on the host system to your instance at path `/opt`, enter the following command: +例えば、ホストシステムの `/share/c1` 上のストレージをインスタンスのパス `/opt` に追加するには、以下のコマンドを入力します: incus query --request PATCH /1.0/instances/my-container --data '{"devices": {"disk-storage-device": {"type":"disk","source":"/share/c1","path":"/opt"}}}' -See [`PATCH /1.0/instances/{name}`](swagger:/instances/instance_patch) for more information. +詳細は [`PATCH /1.0/instances/{name}`](swagger:/instances/instance_patch) を参照してください。 ```` - -````{group-tab} UI -The UI currently has limited support for devices. - -To attach a device to your instance, you must first create it. -Then you can update your instance configuration (in the same way as you {ref}`configure instance options `) to attach the device to the instance. - -```{note} -Some of the devices that are displayed in the instance configuration are inherited from a {ref}`profile ` or defined through a {ref}`project `. -These devices cannot be edited for an instance. -``` - -To add and configure devices that are not currently supported in the UI, follow the instructions in {ref}`instances-configure-edit`. -```` - ````` -## Display instance configuration +## インスタンス設定を表示する ````{tabs} ```{group-tab} CLI -To display the current configuration of your instance, including writable instance properties, instance options, devices and device options, enter the following command: +書き込み可能なインスタンスプロパティ、インスタンスオプション、デバイスとデバイスオプションを含むインスタンスの現在の設定を表示するには、以下のコマンドを入力します: incus config show --expanded ``` ```{group-tab} API -To retrieve the current configuration of your instance, including writable instance properties, instance options, devices and device options, send a GET request to the instance: +書き込み可能なインスタンスプロパティ、インスタンスオプション、デバイスとデバイスオプションを含むインスタンスの現在の設定を取得するには、インスタンスに GET リクエストを送ります: incus query /1.0/instances/ -See [`GET /1.0/instances/{name}`](swagger:/instances/instance_get) for more information. -``` - -```{group-tab} UI -To view the current configuration of your instance, go to {guilabel}`Instances`, select your instance, and then switch to the {guilabel}`Configuration` tab. - -To see the full configuration including instance properties, instance options, devices and device options (also the ones that aren't yet supported by the UI), select {guilabel}`YAML configuration`. -This view shows the full YAML of the instance configuration. +詳細は [`GET /1.0/instances/{name}`](swagger:/instances/instance_get) を参照してください。 ``` ```` (instances-configure-edit)= -## Edit the full instance configuration +## インスタンス設定全体を編集する `````{tabs} ````{group-tab} CLI -To edit the full instance configuration, including writable instance properties, instance options, devices and device options, enter the following command: +書き込み可能なインスタンスプロパティ、インスタンスオプション、デバイスとデバイスオプションを含むインスタンス設定全体を編集するには、以下のコマンドを入力します: incus config edit ```{note} -For convenience, the [`incus config edit`](incus_config_edit.md) command displays the full configuration including read-only instance properties. -However, you cannot edit those properties. -Any changes are ignored. +利便性のため、 [`incus config edit`](incus_config_edit.md) コマンドは読み取り専用のインスタンスプロパティを含む設定全体を表示します。 +しかし、これらのプロパティは変更できません。 +変更しても無視されます。 ``` ```` ````{group-tab} API -To update the full instance configuration, including writable instance properties, instance options, devices and device options, send a PUT request to the instance: +書き込み可能なインスタンスプロパティ、インスタンスオプション、デバイスとデバイスオプションを含むインスタンス設定全体を編集するには、インスタンスに PUT リクエストを送ります: incus query --request PUT /1.0/instances/ --data '' -See [`PUT /1.0/instances/{name}`](swagger:/instances/instance_put) for more information. - -```{note} -If you include changes to any read-only instance properties in the configuration you provide, they are ignored. -``` -```` - -````{group-tab} UI -Instead of using the UI forms to configure your instance, you can choose to edit the YAML configuration of the instance. -You must use this method if you need to update any configurations that are not available in the UI. - -```{important} -When doing updates, do not navigate away from the YAML configuration without saving your changes. -If you do, your updates are lost. -``` - -To edit the YAML configuration of your instance, go to the instance detail page, switch to the {guilabel}`Configuration` tab and select {guilabel}`YAML configuration`. -Then click {guilabel}`Edit instance`. - -Edit the YAML configuration as required. -Then click {guilabel}`Save changes` to save the updated configuration. +詳細は [`PUT /1.0/instances/{name}`](swagger:/instances/instance_put) を参照してください。 ```{note} -For convenience, the YAML contains the full configuration including read-only instance properties. -However, you cannot edit those properties. -Any changes are ignored. +提供する設定内に読み取り専用のインスタンスプロパティの変更を含めた場合、それらは無視されます。 ``` ```` ````` diff --git a/doc/howto/instances_console.md b/doc/howto/instances_console.md index c00d664c922..4c50fa98f74 100644 --- a/doc/howto/instances_console.md +++ b/doc/howto/instances_console.md @@ -1,31 +1,31 @@ (instances-console)= -# How to access the console +# コンソールにアクセスするには -Use the [`incus console`](incus_console.md) command to attach to instance consoles. -The console is available at boot time already, so you can use it to see boot messages and, if necessary, debug startup issues of a container or VM. +インスタンスのコンソールにアタッチするには [`incus console`](incus_console.md) コマンドを使います。 +コンソールは起動時に既に利用可能になり、必要なら、ブートメッセージを見て、コンテナや仮想マシンの起動時の問題をデバッグするのに使えます。 -To get an interactive console, enter the following command: +インタラクティブなコンソールに接続するには、以下のコマンドを入力します: incus console -To show log output, pass the `--show-log` flag: +ログ出力を見るには `--show-log` フラグを渡します: incus console --show-log -You can also immediately attach to the console when you start your instance: +インスタンスが起動したらすぐにコンソールにアタッチできます: incus start --console incus start --console=vga -## Access the graphical console (for virtual machines) +## グラフィカルなコンソールにアタッチする（仮想マシンの場合） -On virtual machines, log on to the console to get graphical output. -Using the console you can, for example, install an operating system using a graphical interface or run a desktop environment. +仮想マシンでは、コンソールにログオンしてグラフィカルな出力を見ることができます。 +コンソールを使えば、たとえば、グラフィカルなインターフェースを使ってオペレーティングシステムをインストールしたりデスクトップ環境を実行できます。 -An additional advantage is that the console is available even if the `incus-agent` process is not running. -This means that you can access the VM through the console before the `incus-agent` starts up, and also if the `incus-agent` is not available at all. +さらなる利点は `incus-agent` プロセスが実行していなくても、コンソールは利用可能です。 +これは `incus-agent` が起動する前や `incus-agent` が全く利用可能でない場合にもコンソール経由で仮想マシンにアクセスできることを意味します。 -To start the VGA console with graphical output for your VM, you must install a SPICE client (for example, `virt-viewer` or `spice-gtk-client`). -Then enter the following command: +仮想マシンにグラフィカルなアウトプットを持つ VGA コンソールを開始するには、 SPICE クライアント (たとえば、`virt-viewer` または `spice-gtk-client`) をインストールする必要があります。 +次に以下のコマンドを入力します: incus console --type vga diff --git a/doc/howto/instances_create.md b/doc/howto/instances_create.md index 6cdf1a23086..8b12a5cbe99 100644 --- a/doc/howto/instances_create.md +++ b/doc/howto/instances_create.md @@ -1,131 +1,132 @@ (instances-create)= -# How to create instances +# インスタンスを作成するには -To create an instance, you can use either the [`incus init`](incus_create.md) or the [`incus launch`](incus_launch.md) command. -The [`incus init`](incus_create.md) command only creates the instance, while the [`incus launch`](incus_launch.md) command creates and starts it. +インスタンスを作成するには、[`incus init`](incus_create.md)か[`incus launch`](incus_launch.md)をコマンドを使用できます。 +[`incus init`](incus_create.md)はインスタンスを作成するだけですが、[`incus launch`](incus_launch.md)は作成して起動します。 -## Usage +## 使い方 -Enter the following command to create a container: +コンテナを作成するには以下のコマンドを入力します: incus launch|init : [flags] -Image -: Images contain a basic operating system (for example, a Linux distribution) and some Incus-related information. - Images for various operating systems are available on the built-in remote image servers. - See {ref}`images` for more information. +イメージ +: イメージは必要最小限のオペレーティングシステム（たとえば、Linux ディストリビューション）と Incus 関連の情報を含みます。 + さまざまなオペレーティングシステムのイメージがビルトインのリモートイメージサーバーで利用できます。 + 詳細は {ref}`images` を参照してください。 - Unless the image is available locally, you must specify the name of the image server and the name of the image (for example, `images:ubuntu/22.04` for the official 22.04 Ubuntu image). + イメージがローカルにない場合、イメージサーバーとイメージの名前を指定（たとえば、公式の 22.04 Ubuntu イメージなら `images:ubuntu/22.04`）する必要があります。 -Instance name -: Instance names must be unique within a Incus deployment (also within a cluster). - See {ref}`instance-properties` for additional requirements. +インスタンス名 +: インスタンス名は Incus の運用環境（そしてクラスタ内）でユニークである必要があります。 + 追加の要件については {ref}`instance-properties` を参照してください。 -Flags -: See [`incus launch --help`](incus_launch.md) or [`incus init --help`](incus_create.md) for a full list of flags. - The most common flags are: +フラグ +: フラグの完全なリストについては [`incus launch --help`](incus_launch.md) か [`incus init --help`](incus_create.md) を参照してください。 + よく使うフラグは以下のとおりです。 - - `--config` to specify a configuration option for the new instance - - `--device` to override {ref}`device options ` for a device provided through a profile - - `--profile` to specify a {ref}`profile ` to use for the new instance - - `--network` or `--storage` to make the new instance use a specific network or storage pool - - `--target` to create the instance on a specific cluster member - - `--vm` to create a virtual machine instead of a container + - `--config` は新しいインスタンスの設定オプションを指定します + - `--device` はプロファイルを通して提供されるデバイスの {ref}`デバイスオプション ` を上書きします + - `--profile` は新しいインスタンスに使用する {ref}`プロファイル ` を指定します + - `--network` や `--storage` は新しいインスタンスに指定のネットワークやストレージプールを使用させます + - `--target` は指定のクラスタメンバー上にインスタンスを作成します + - `--vm` はコンテナではなく仮想マシンを作成します -## Pass a configuration file +## 設定ファイルを渡す -Instead of specifying the instance configuration as flags, you can pass it to the command as a YAML file. +インスタンス設定をフラグとして指定する代わりに、YAML ファイルでコマンドに渡すことができます。 -For example, to launch a container with the configuration from `config.yaml`, enter the following command: +たとえば、`config.yaml` の設定でコンテナを起動するには、以下のコマンドを入力します: + + lxc launch images:ubuntu/22.04 ubuntu-config < config.yaml incus launch images:ubuntu/22.04 ubuntu-config < config.yaml ```{tip} -Check the contents of an existing instance configuration ([`incus config show --expanded`](incus_config_show.md)) to see the required syntax of the YAML file. +YAML ファイルの必要な文法を見るには既存のインスタンス設定の中身を確認（[`incus config show --expanded`](incus_config_show.md)）してください。 ``` -## Examples +## 例 -The following examples use [`incus launch`](incus_launch.md), but you can use [`incus init`](incus_create.md) in the same way. +以下の例では [`incus launch`](incus_launch.md) を使用しますが、同じように [`incus init`](incus_create.md) も使用できます。 -### Launch a container +### コンテナを起動する -To launch a container with an Ubuntu 22.04 image from the `images` server using the instance name `ubuntu-container`, enter the following command: +`images` サーバーの Ubuntu 22.04 のイメージで `ubuntu-container` というインスタンス名でコンテナを起動するには、以下のコマンドを入力します: incus launch images:ubuntu/22.04 ubuntu-container -### Launch a virtual machine +### 仮想マシンを起動する -To launch a virtual machine with an Ubuntu 22.04 image from the `images` server using the instance name `ubuntu-vm`, enter the following command: +`images` サーバーの Ubuntu 22.04 のイメージで `ubuntu-vm` というインスタンス名で仮想マシンを起動するには、以下のコマンドを入力します: incus launch images:ubuntu/22.04 ubuntu-vm --vm -Or with a bigger disk: +より大きいディスクサイズで起動する場合は: incus launch images:ubuntu/22.04 ubuntu-vm-big --vm --device root,size=30GiB -### Launch a container with specific configuration options +### コンテナを指定の設定で起動する -To launch a container and limit its resources to one vCPU and 192 MiB of RAM, enter the following command: +コンテナを起動しリソースを 1 つの vCPU と 192MiB の RAM に限定するには、以下のコマンドを入力します: incus launch images:ubuntu/22.04 ubuntu-limited --config limits.cpu=1 --config limits.memory=192MiB -### Launch a VM on a specific cluster member +### 指定のクラスタメンバー上で仮想マシンを起動する -To launch a virtual machine on the cluster member `server2`, enter the following command: +クラスタメンバー `server2` 上で仮想マシンを起動するには、以下のコマンドを入力します: incus launch images:ubuntu/22.04 ubuntu-container --vm --target server2 -### Launch a container with a specific instance type +### 指定のインスタンスタイプでコンテナを起動する -Incus supports simple instance types for clouds. -Those are represented as a string that can be passed at instance creation time. +Incus ではクラウドのシンプルなインスタンスタイプが使えます。これは、インスタンスの作成時に指定できる文字列で表されます。 -The syntax allows the three following forms: +以下の 3 つの指定方法があります: - `` - `:` - `c-m` -For example, the following three instance types are equivalent: +たとえば、次の 3 つのインスタンスタイプは同じです: - `t2.micro` - `aws:t2.micro` - `c1-m1` -To launch a container with this instance type, enter the following command: +コマンドラインでは、インスタンスタイプは次のように指定します: incus launch images:ubuntu/22.04 my-instance --type t2.micro -The list of supported clouds and instance types can be found at [`https://github.com/dustinkirkland/instance-type`](https://github.com/dustinkirkland/instance-type). +使えるクラウドとインスタンスタイプのリストは [`https://github.com/dustinkirkland/instance-type`](https://github.com/dustinkirkland/instance-type) で確認できます。 -### Launch a VM that boots from an ISO +### ISOからブートする仮想マシンを起動する -To launch a VM that boots from an ISO, you must first create a VM. -Let's assume that we want to create a VM and install it from the ISO image. -In this scenario, use the following command to create an empty VM: +ISO からブートする仮想マシンを起動するには、まず仮想マシンを作成する必要があります。 +ISO イメージから仮想マシンを作成しインストールしたいとしましょう。 +このシナリオでは、まず以下のコマンドで空の仮想マシンを作成します: incus init iso-vm --empty --vm -The second step is to import an ISO image that can later be attached to the VM as a storage volume: +次のステップは ISO イメージをインポートし、後で仮想マシンにストレージボリュームとしてアタッチできるようにします: incus storage volume import iso-volume --type=iso -Lastly, you need to attach the custom ISO volume to the VM using the following command: +最後に、以下のコマンドでカスタム ISO ボリュームを仮想マシンにアタッチする必要があります: incus config device add iso-vm iso-volume disk pool=default source=iso-volume boot.priority=10 -The `boot.priority` configuration key ensures that the VM will boot from the ISO first. -Start the VM and connect to the console as there might be a menu you need to interact with: +`boot.priority` 設定キーは仮想マシンの起動順が確実に ISO が最初になるようにします。 +仮想マシンを起動し、コンソールに接続してメニューを操作できるようにします: incus start iso-vm --console -Once you're done in the serial console, you need to disconnect from the console using `ctrl+a-q`, and connect to the VGA console using the following command: +シリアルコンソールでの操作が完了したら、`ctrl+a-q` を使ってコンソールから切断する必要があります。そして以下のコマンドで VGA コンソールに接続します: incus console iso-vm --type=vga -You should now see the installer. After the installation is done, you need to detach the custom ISO volume: +これでインストーラが見えるようになります。インストールが終わったら、カスタム ISO ボリュームを切り離す必要があります: incus storage volume detach default iso-volume iso-vm -Now the VM can be rebooted, and it will boot from disk. +これで仮想マシンはリブートでき、リブートするとディスクから起動します。 diff --git a/doc/howto/instances_manage.md b/doc/howto/instances_manage.md index dd63b8c1834..7e9cef94986 100644 --- a/doc/howto/instances_manage.md +++ b/doc/howto/instances_manage.md @@ -1,149 +1,125 @@ (instances-manage)= -# How to manage instances +# インスタンスを管理するには -When listing the existing instances, you can see their type, status, and location (if applicable). -You can filter the instances and display only the ones that you are interested in. +既存のインスタンスを一覧表示する際、インスタンスタイプ、状態、場所（場所を持つ場合）を表示できます。 +またインスタンスをフィルターして興味があるインスタンスだけを表示できます。 ````{tabs} ```{group-tab} CLI -Enter the following command to list all instances: +全てのインスタンスを一覧表示するには以下のコマンドを入力します: incus list -You can filter the instances that are displayed, for example, by type, status or the cluster member where the instance is located: +表示するインスタンスをフィルターできます。例えば、インスタンスタイプ、状態、またはインスタンスが配置されているクラスタメンバーでフィルターできます: incus list type=container incus list status=running incus list location=server1 -You can also filter by name. -To list several instances, use a regular expression for the name. -For example: +インスタンス名でフィルターもできます。 +複数のインスタンスを一覧表示するには、名前の正規表現を使います。 +例えば以下のようにします: incus list ubuntu.* -Enter [`incus list --help`](incus_list.md) to see all filter options. +全てのフィルターオプションを見るには [`incus list --help`](incus_list.md) と入力します。 ``` ```{group-tab} API -Query the `/1.0/instances` endpoint to list all instances. -You can use {ref}`rest-api-recursion` to display more information about the instances: +すべてのインスタンスを一覧表示するには `/1.0/instances` エンドポイントに問い合わせます。 +インスタンスのより詳細な情報を表示するには {ref}`rest-api-recursion` を使えます: incus query /1.0/instances?recursion=2 -You can {ref}`filter ` the instances that are displayed, by name, type, status or the cluster member where the instance is located: +表示するインスタンスを名前、インスタンスタイプ、状態またはインスタンスが配置されているクラスタメンバで {ref}`フィルタ ` できます: incus query /1.0/instances?filter=name+eq+ubuntu incus query /1.0/instances?filter=type+eq+container incus query /1.0/instances?filter=status+eq+running incus query /1.0/instances?filter=location+eq+server1 -To list several instances, use a regular expression for the name. -For example: +複数のインスタンスを一覧表示するには、名前の正規表現を使います。 +たとえば: incus query /1.0/instances?filter=name+eq+ubuntu.* -See [`GET /1.0/instances`](swagger:/instances/instances_get) for more information. -``` - -```{group-tab} UI -Go to {guilabel}`Instances` to see a list of all instances. - -You can filter the instances that are displayed by status, instance type, or the profile they use by selecting the corresponding filter. - -In addition, you can search for instances by entering a search text. -The text you enter is matched against the name, the description, and the name of the base image. +詳細は [`GET /1.0/instances`](swagger:/instances/instances_get) を参照してください。 ``` ```` -## Show information about an instance +## インスタンスの詳細情報を表示する ````{tabs} ```{group-tab} CLI -Enter the following command to show detailed information about an instance: +インスタンスの詳細情報を表示するには以下のコマンドを入力します: incus info -Add `--show-log` to the command to show the latest log lines for the instance: +インスタンスの最新のログを表示するにはコマンドに `--show-log` を追加します: incus info --show-log ``` ```{group-tab} API -Query the following endpoint to show detailed information about an instance: +インスタンスの詳細情報を表示するには以下のエンドポイントに問い合わせます: incus query /1.0/instances/ -See [`GET /1.0/instances/{name}`](swagger:/instances/instance_get) for more information. -``` - -```{group-tab} UI -Clicking an instance line in the overview will show a summary of the instance information right next to the instance list. - -Click the instance name to go to the instance detail page, which contains detailed information about the instance. +詳細は [`GET /1.0/instances/{name}`](swagger:/instances/instance_get) を参照してください。 ``` ```` -## Start an instance +## インスタンスを起動する ````{tabs} ```{group-tab} CLI -Enter the following command to start an instance: +インスタンスを起動するには以下のコマンドを入力します: incus start -You will get an error if the instance does not exist or if it is running already. +インスタンスが存在しないか既に稼働中の場合はエラーになります。 -To immediately attach to the console when starting, pass the `--console` flag. -For example: +起動する際にコンソールにすぐにアタッチするには `--console` フラグを渡します。 +例えば以下のようにします: incus start --console -See {ref}`instances-console` for more information. +詳細は {ref}`instances-console` を参照してください。 ``` ```{group-tab} API -To start an instance, send a PUT request to change the instance state: +インスタンスを起動するには、PUT リクエストを送ってインスタンス状態を変更してください: incus query --request PUT /1.0/instances//state --data '{"action":"start"}' -The return value of this query contains an operation ID, which you can use to query the status of the operation: +API 呼び出しの戻り値には操作 ID が含まれます。これを使って操作の状態を問い合わせできます: incus query /1.0/operations/ -Use the following query to monitor the state of the instance: +インスタンスの状態をモニターするには以下のクエリを使います: incus query /1.0/instances//state -See [`GET /1.0/instances/{name}/state`](swagger:/instances/instance_state_get) and [`PUT /1.0/instances/{name}/state`](swagger:/instances/instance_state_put)for more information. +詳細は [`GET /1.0/instances/{name}/state`](swagger:/instances/instance_state_get) と [`PUT /1.0/instances/{name}/state`](swagger:/instances/instance_state_put) を参照してください。 ``` - -```{group-tab} UI -To start an instance, go to the instance list or the respective instance and click the {guilabel}`Start` button (▷). - -You can also start several instances at the same time by selecting them in the instance list and clicking the {guilabel}`Start` button at the top. - -On the instance detail page, select the {guilabel}`Console` tab to see the boot log with information about the instance starting up. -Once it is running, you can select the {guilabel}`Terminal` tab to access the instance. -``` ```` (instances-manage-stop)= -## Stop an instance +## インスタンスを停止する `````{tabs} ````{group-tab} CLI -Enter the following command to stop an instance: +インスタンスを停止するには以下のコマンドを入力します: incus stop -You will get an error if the instance does not exist or if it is not running. +インスタンスが存在しないか稼働中ではない場合はエラーになります。 ```` ````{group-tab} API -To stop an instance, send a PUT request to change the instance state: +インスタンスを停止するには、PUT リクエストを送ってインスタンス状態を変更します: incus query --request PUT /1.0/instances//state --data '{"action":"stop"}' @@ -153,108 +129,74 @@ To stop an instance, send a PUT request to change the instance state: :end-before: ``` ```` - -````{group-tab} UI -To stop an instance, go to the instance list or the respective instance and click the {guilabel}`Stop` button (□). -You are then prompted to confirm. - - -```{tip} -To skip the confirmation prompt, hold the {kbd}`Shift` key while clicking. -``` - - -You can choose to force-stop the instance. -If stopping the instance takes a long time or the instance is not responding to the stop request, click the spinning stop button to go back to the confirmation prompt, where you can select to force-stop the instance. - -You can also stop several instances at the same time by selecting them in the instance list and clicking the {guilabel}`Stop` button at the top. -```` - ````` -## Delete an instance +## インスタンスを削除する -If you don't need an instance anymore, you can remove it. -The instance must be stopped before you can delete it. +インスタンスがもう不要な場合、削除できます。 +削除する前にインスタンスを停止する必要があります。 `````{tabs} ```{group-tab} CLI -Enter the following command to delete an instance: +インスタンスを削除するには以下のコマンドを入力します: incus delete ``` ```{group-tab} API -To delete an instance, send a DELETE request to the instance: +インスタンスを削除するには、インスタンスに DELETE リクエストを送ります: incus query --request DELETE /1.0/instances/ -See [`DELETE /1.0/instances/{name}`](swagger:/instances/instance_delete) for more information. +詳細は [`DELETE /1.0/instances/{name}`](swagger:/instances/instance_delete) を参照してください。 ``` - -````{group-tab} UI -To delete an instance, go to its instance detail page and click {guilabel}`Delete instance`. -You are then prompted to confirm. - -% Include content from above -```{include} ./instances_manage.md - :start-after: - :end-before: -``` - -You can also delete several instances at the same time by selecting them in the instance list and clicking the {guilabel}`Delete` button at the top. -```` ````` ```{caution} -This command permanently deletes the instance and all its snapshots. +このコマンドはインスタンスとそのスナップショットを永久的に削除します。 ``` -### Prevent accidental deletion of instances +### 間違ってインスタンスを削除するのを防ぐ -There are different ways to prevent accidental deletion of instances: +間違ってインスタンスを削除するのを防ぐにはいくつかの異なる方法があります: -- To protect a specific instance from being deleted, set {config:option}`instance-security:security.protection.delete` to `true` for the instance. - See {ref}`instances-configure` for instructions. -- In the CLI client, you can create an alias to be prompted for approval every time you use the [`incus delete`](incus_delete.md) command: +- 特定のインスタンスが削除されることを防ぐためには、そのインスタンスの {config:option}`instance-security:security.protection.delete` を `true` に設定します。 + 手順は {ref}`instances-configure` を参照してください。 +- CLI クライアントでは、[`incus delete`](incus_delete.md) コマンドを使うたびに確認のプロンプトを表示するようなエイリアスを作成します: incus alias add delete "delete -i" -## Rebuild an instance +## インスタンスを再構築する -If you want to wipe and re-initialize the root disk of your instance but keep the instance configuration, you can rebuild the instance. +インスタンスの root ディスクを一掃して再初期化したいがインスタンスの設定は維持したい場合、インスタンスを再構築できます。 -Rebuilding is only possible for instances that do not have any snapshots. +再構築はスナップショットが 1 つも存在しないインスタンスでのみ可能です。 -Stop your instance before rebuilding it. +再構築の前にインスタンスを停止します。 ````{tabs} ```{group-tab} CLI -Enter the following command to rebuild the instance with a different image: +別のイメージでインスタンスを再構築するには以下のコマンドを入力します: incus rebuild -Enter the following command to rebuild the instance with an empty root disk: +空のルートディスクでインスタンスを再構築するには以下のコマンドを入力します: incus rebuild --empty -For more information about the `rebuild` command, see [`incus rebuild --help`](incus_rebuild.md). +`rebuild` コマンドについての詳細は、 [`incus rebuild --help`](incus_rebuild.md) を参照してください。 ``` ```{group-tab} API -To rebuild the instance with a different image, send a POST request to the instance's `rebuild` endpoint. -For example: +インスタンスを別のイメージで再構築するには、インスタンスの `rebuild` エンドポイントに POST リクエストを送ります。 +たとえば: incus query --request POST /1.0/instances//rebuild --data '{"source": {"alias":"","server":"", protocol:"simplestreams"}}' -To rebuild the instance with an empty root disk, specify the source type as `none`: +空のルートディスクでインスタンスを再構築するには、 source の type を `none` にします: incus query --request POST /1.0/instances//rebuild --data '{"source": {"type":"none"}}' -See [`POST /1.0/instances/{name}/rebuild`](swagger:/instances/instance_rebuild_post) for more information. -``` - -```{group-tab} UI -Rebuilding an instance is not yet supported in the UI. +詳細は [`POST /1.0/instances/{name}/rebuild`](swagger:/instances/instance_rebuild_post) を参照してください。 ``` ```` diff --git a/doc/howto/instances_routed_nic_vm.md b/doc/howto/instances_routed_nic_vm.md index 3c94d070a77..c774ba6f456 100644 --- a/doc/howto/instances_routed_nic_vm.md +++ b/doc/howto/instances_routed_nic_vm.md @@ -1,21 +1,21 @@ (instances-routed-nic-vm)= -# How to add a routed NIC device to a virtual machine +# 仮想マシンに routed NIC を追加するには -When adding a {ref}`routed NIC device ` to an instance, you must configure the instance to use the link-local gateway IPs as default routes. -For containers, this is configured for you automatically. -For virtual machines, the gateways must be configured manually or via a mechanism like `cloud-init`. +インスタンスに {ref}`routed NIC デバイス ` を追加する際、link-local ゲートウェイ IP をデフォルトルートとして使用するようにインスタンスを設定する必要があります。 +コンテナでは、これは自動的に設定されます。 +仮想マシンでは、ゲートウェイは手動あるいは `cloud-init` のような仕組みで設定する必要があります。 -To configure the gateways with `cloud-init`, firstly initialize an instance: +`cloud-init` でゲートウェイを設定するには、まずインスタンスを初期化します: incus init images:ubuntu/22.04 jammy --vm -Then add the routed NIC device: +次に routed NIC デバイスを追加します: incus config device add jammy eth0 nic nictype=routed parent=my-parent-network ipv4.address=192.0.2.2 ipv6.address=2001:db8::2 -In this command, `my-parent-network` is your parent network, and the IPv4 and IPv6 addresses are within the subnet of the parent. +このコマンドでは、`my-parent-network` が親ネットワークで、IPv4 と IPv6 アドレスは親のサブネット内です。 -Next we will add some `netplan` configuration to the instance using the `cloud-init.network-config` configuration key: +次に `cloud-init.network-config` 設定キーを使ってインスタンスに `netplan` 設定を追加します: cat <` (`169.254.0.1` and `fe80::1`) that are required. -For each of these routes we set `on-link` to `true`, which specifies that the route is directly connected to the interface. -We also add the addresses that we configured in our routed NIC device. -For more information on `netplan`, see [their documentation](https://netplan.readthedocs.io/en/latest/). +この `netplan` 設定は必要な {ref}`スタティックな link-local next-hop アドレス `（`169.254.0.1` と `fe80::1`）を追加します。 +これらのルートはそれぞれ `on-link` を `true` に設定します。するとルートがインターフェースに直接接続されるよう指定されます。 +また routed NIC デバイス内でのアドレスも追加します。 +`netplan` の詳細は [ドキュメント](https://netplan.readthedocs.io/en/latest/) を参照してください。 ```{note} -This `netplan` configuration does not include a name server. -To enable DNS within the instance, you must set a valid DNS IP address. -If there is a `incusbr0` network on the host, the name server can be set to that IP instead. +この `netplan` 設定はネームサーバーを含んでいません。 +インスタンス内で DNS を使うには、有効な DNS の IP アドレスを設定する必要があります。 +ホストに `incusbr0` ネットワークがあれば、ネームサーバーは代わりにその IP を指定できます。 ``` -You can then start your instance with: +これでネットワークを開始できます: incus start jammy ```{note} -Before you start your instance, make sure that you have {ref}`configured the parent network ` to enable proxy ARP/NDP. +インスタンスを輝度する前に、 proxy ARP/NDP を有効にするように {ref}`親のネットワークを設定した ` ことを確認してください。 ``` diff --git a/doc/howto/instances_troubleshoot.md b/doc/howto/instances_troubleshoot.md index fdbf651cbbf..2e0ad31a673 100644 --- a/doc/howto/instances_troubleshoot.md +++ b/doc/howto/instances_troubleshoot.md @@ -1,32 +1,32 @@ (instances-troubleshoot)= -# How to troubleshoot failing instances +# インスタンスの起動に失敗する問題のトラブルシューティング方法 -If your instance fails to start and ends up in an error state, this usually indicates a bigger issue related to either the image that you used to create the instance or the server configuration. +インスタンスの起動に失敗し、エラー状態になる場合、これは通常、インスタンスの作成に使用したイメージまたはサーバー設定に関連する大きな問題を示しています。 -To troubleshoot the problem, complete the following steps: +問題のトラブルシューティングを行うには、以下の手順を完了してください: -1. Save the relevant log files and debug information: +1. 関連するログファイルとデバッグ情報を保存します: - Instance log - : Enter the following command to display the instance log: + インスタンスログ + : インスタンスログを表示するには、次のコマンドを入力します: incus info --show-log - Console log - : Enter the following command to display the console log: + コンソールログ + : コンソールログを表示するには、次のコマンドを入力します: incus console --show-log -1. Reboot the machine that runs your Incus server. -1. Try starting your instance again. - If the error occurs again, compare the logs to check if it is the same error. +1. Incus サーバーを実行しているマシンを再起動します. +1. インスタンスをもう一度起動してみてください。 + エラーが再発した場合は、ログを比較して同じエラーかどうか確認します。 - If it is, and if you cannot figure out the source of the error from the log information, open a question in the [forum](https://discuss.linuxcontainers.org). - Make sure to include the log files you collected. + 同じエラーであり、ログ情報からエラーの原因を特定できない場合は、[フォーラム](https://discuss.linuxcontainers.org)で質問を投稿してください。 + 収集したログファイルを含めるようにしてください。 -## Troubleshooting example +## トラブルシューティングの例 -In this example, let's investigate a RHEL 7 system in which `systemd` cannot start. +この例では、systemd が起動できない RHEL 7 システムを調査しましょう。 ```{terminal} :input: incus console --show-log systemd @@ -40,19 +40,19 @@ Failed to mount proc at /proc: Operation not permitted [!!!!!!] Failed to mount API filesystems, freezing. ``` -The errors here say that `/sys` and `/proc` cannot be mounted - which is correct in an unprivileged container. -However, Incus mounts these file systems automatically if it can. +ここでのエラーは、 /sys と /proc がマウントできないと言っています - これは、非特権コンテナでは正しいです。 +しかし、Incus は可能であればこれらのファイルシステムを自動的にマウントします。 -The {doc}`container requirements <../container-environment>` specify that every container must come with an empty `/dev`, `/proc` and `/sys` directory, and that `/sbin/init` must exist. -If those directories don't exist, Incus cannot mount them, and `systemd` will then try to do so. -As this is an unprivileged container, `systemd` does not have the ability to do this, and it then freezes. +{doc}`コンテナの要件 <../container-environment>`では、すべてのコンテナには空の `/dev`、`/proc`、`/sys` ディレクトリーが必要であり、`/sbin/init` が存在していなければなりません。 +これらのディレクトリーが存在しない場合、Incus はそれらをマウントできず、`systemd`がその後それを試みます。 +これは非特権コンテナなので、`systemd`はこれを行う能力がなく、コンテナはフリーズします。 -So you can see the environment before anything is changed, and you can explicitly change the init system in a container using the `raw.lxc` configuration parameter. -This is equivalent to setting `init=/bin/bash` on the Linux kernel command line. +したがって、何も変更される前の環境を確認でき、`raw.lxc` 設定パラメーターを使用してコンテナ内の`init`システムを明示的に変更できます。 +これは、Linux カーネルのコマンドラインで `init=/bin/bash` を設定するのと同等です。 incus config set systemd raw.lxc 'lxc.init.cmd = /bin/bash' -Here is what it looks like: +これがどのように見えるかを示します: ```{terminal} :input: incus config set systemd raw.lxc 'lxc.init.cmd = /bin/bash' @@ -65,7 +65,7 @@ Console log: [root@systemd /]# ``` -Now that the container has started, you can check it and see that things are not running as well as expected: +これでコンテナが起動したので、確認して期待通りにうまく動作していないことがわかります: ```{terminal} :input: incus exec systemd bash @@ -79,5 +79,5 @@ sys [root@systemd /]# exit ``` -Because Incus tries to auto-heal, it created some of the directories when it was starting up. -Shutting down and restarting the container fixes the problem, but the original cause is still there - the template does not contain the required files. +Incus は自動的に回復しようとするため、起動時にいくつかのディレクトリーが作成されました。 +コンテナをシャットダウンして再起動すると問題が解決しますが、元の原因はまだ残っています - テンプレートには必要なファイルが含まれていません。 diff --git a/doc/howto/migrate_from_lxc.md b/doc/howto/migrate_from_lxc.md index 1511801bad6..7bf3dbdd127 100644 --- a/doc/howto/migrate_from_lxc.md +++ b/doc/howto/migrate_from_lxc.md @@ -1,70 +1,70 @@ (migrate-from-lxc)= -# How to migrate containers from LXC to Incus +# LXC から Incus にコンテナをマイグレートするには -Incus provides a tool (`lxc-to-incus`) that you can use to import LXC containers into your Incus server. -The LXC containers must exist on the same machine as the Incus server. +Incus は LXC のコンテナを Incus サーバーにインポートするためのツール（`lxc-to-incus`）を提供しています。 +LXC コンテナは Incus サーバーと同じマシン上に存在する必要があります。 -The tool analyzes the LXC containers and migrates both their data and their configuration into new Incus containers. +このツールは LXC コンテナを分析し、データと設定の両方を新しい Incus コンテナにマイグレートします。 ```{note} -Alternatively, you can use the `incus-migrate` tool within a LXC container to migrate it to Incus (see {ref}`import-machines-to-instances`). -However, this tool does not migrate any of the LXC container configuration. +あるいは LXC コンテナ内で `incus-migrate` ツールを使用して Incus にマイグレートすることもできます（{ref}`import-machines-to-instances` 参照）。 +しかし、このツールは LXC コンテナの設定は一切マイグレートしません。 ``` -## Get the tool +## ツールを取得する -If the tool isn't provided alongside your Incus installation, you can build it yourself. -Make sure that you have `go` (version 1.18 or later) installed and get the tool with the following command: +あなたの Incus がインストールされた環境でツールが提供されていない場合、自分でビルドできます。 +`go` （バージョン 1.18 以降）がインストールされていることを確認して以下のコマンドでツールを取得してください: go install github.com/lxc/incus/cmd/lxc-to-incus@latest -## Prepare your LXC containers +## LXC コンテナを用意する -You can migrate one container at a time or all of your LXC containers at the same time. +一度に 1 つのコンテナをマイグレートすることもできますし、同時にあなたのすべての LXC コンテナをマイグレートすることもできます。 ```{note} -Migrated containers use the same name as the original containers. -You cannot migrate containers with a name that already exists as an instance name in Incus. +マイグレートされたコンテナは元のコンテナと同じ名前を使用します。 +Incus にインスタンス名としてすでに存在する名前を持つコンテナをマイグレートすることはできません。 -Therefore, rename any LXC containers that might cause name conflicts before you start the migration process. +このため、マイグレーションプロセスを開始する前に名前の衝突を引き起こす可能性のある LXC コンテナはリネームしてください。 ``` -Before you start the migration process, stop the LXC containers that you want to migrate. +マイグレーションプロセスを開始する前に、マイグレートしたいコンテナを停止してください。 -## Start the migration process +## マイグレーションプロセスを開始する -Run `sudo lxc-to-incus [flags]` to migrate the containers. +コンテナをマイグレートするには `sudo lxd.lxc-to-incus [flags]` と実行してください。 -For example, to migrate all containers: +たとえば、すべてのコンテナをマイグレートするには: sudo lxc-to-incus --all -To migrate only the `lxc1` container: +`lxc1` コンテナだけをマイグレートするには: sudo lxc-to-incus --containers lxc1 -To migrate two containers (`lxc1` and `lxc2`) and use the `my-storage` storage pool in Incus: +2 つのコンテナ（`lxc1` と `lxc2`）をマイグレートし Incus 内の `my-storage` ストレージプールを使用するには: sudo lxc-to-incus --containers lxc1,lxc2 --storage my-storage -To test the migration of all containers without actually running it: +実際に実行せずにすべてのコンテナのマイグレートをテストするには: sudo lxc-to-incus --all --dry-run -To migrate all containers but limit the `rsync` bandwidth to 5000 KB/s: +すべてのコンテナをマイグレートするが、`rsync` の帯域幅を 5000 KB/s に限定するには: sudo lxc-to-incus --all --rsync-args --bwlimit=5000 -Run `sudo lxc-to-incus --help` to check all available flags. +すべての利用可能なフラグを確認するには `sudo lxd.lxc-to-incus --help` と実行してください。 ```{note} -If you get an error that the `linux64` architecture isn't supported, either update the tool to the latest version or change the architecture in the LXC container configuration from `linux64` to either `amd64` or `x86_64`. +`linux64` アーキテクチャがサポートされない（`linux64` architecture isn't supported）というエラーが出る場合、ツールを最新版にアップデートするか LXC コンテナ内のアーキテクチャを `linux64` から `amd64` か `x86_64` に変更してください。 ``` -## Check the configuration +## 設定を確認する -The tool analyzes the LXC configuration and the configuration of the container (or containers) and migrates as much of the configuration as possible. -You will see output similar to the following: +このツールは LXC の設定と（1 つまたは複数の）コンテナの設定を分析し、可能な限りの範囲で設定をマイグレートします。 +以下のような実行結果が出力されます: ```{terminal} :input: sudo lxc-to-incus --containers lxc1 @@ -90,4 +90,4 @@ Transferring container: lxc1: ... Container 'lxc1' successfully created ``` -After the migration process is complete, you can check and, if necessary, update the configuration in Incus before you start the migrated Incus container. +マイグレーションプロセスが完了したら、設定を確認し、必要に応じて、マイグレートした Incus コンテナを起動する前に Incus 内の設定を更新してください。 diff --git a/doc/howto/move_instances.md b/doc/howto/move_instances.md index 6288b1b50e3..dad7b2c6a80 100644 --- a/doc/howto/move_instances.md +++ b/doc/howto/move_instances.md @@ -1,67 +1,67 @@ (move-instances)= -# How to move existing Incus instances between servers +# サーバー間で既存の Incus インスタンスを移動するには -To move an instance from one Incus server to another, use the [`incus move`](incus_move.md) command: +ある Incus サーバーから別のサーバーへインスタンスを移動するには [`incus move`](incus_move.md) コマンドを使います: incus move [:] :[] ```{note} -When moving a container, you must stop it first. -See {ref}`live-migration-containers` for more information. +コンテナを移動する際にはまず停止する必要があります。 +詳細は {ref}`live-migration-containers` を参照してください。 -When moving a virtual machine, you must either enable {ref}`live-migration-vms` or stop it first. +仮想マシンを移動する際は、{ref}`live-migration-vms` を有効にするか、まず仮想マシンを停止する必要があります。 ``` -Alternatively, you can use the [`incus copy`](incus_copy.md) command if you want to duplicate the instance: +あるいは、インスタンスを複製したい場合は [`incus copy`](incus_copy.md) コマンドを使えます: incus copy [:] :[] -In both cases, you don't need to specify the source remote if it is your default remote, and you can leave out the target instance name if you want to use the same instance name. -If you want to move the instance to a specific cluster member, specify it with the `--target` flag. -In this case, do not specify the source and target remote. +どちらの場合も、移動元のリモートがデフォルトのリモートの場合は省略可能で、移動先でも同じインスタンス名を使用する場合は移動先インスタンス名は省略できます。 +インスタンスを特定のクラスタメンバーに移動したい場合は、`--target` フラグを指定してください。 +この場合、移動元と移動先のリモートは指定を省略してください。 -You can add the `--mode` flag to choose a transfer mode, depending on your network setup: +ネットワークのセットアップに応じて、`--mode` フラグを追加して転送モードを選択できます: -`pull` (default) -: Instruct the target server to connect to the source server and pull the respective instance. +`pull`（デフォルト） +: 移動先のサーバーに、移動元のサーバーへ接続させ該当のインスタンスをプルするように指示します。 `push` -: Instruct the source server to connect to the target server and push the instance. +: 移動元のサーバーに、移動先のサーバーへ接続させインスタンスをプッシュするように指示します。 `relay` -: Instruct the client to connect to both the source and the target server and transfer the data through the client. +: クライアントに移動元と移動先の両方に接続させデータをクライアント経由で転送するよう指示します。 -If you need to adapt the configuration for the instance to run on the target server, you can either specify the new configuration directly (using `--config`, `--device`, `--storage` or `--target-project`) or through profiles (using `--no-profiles` or `--profile`). See [`incus move --help`](incus_move.md) for all available flags. +移動先のサーバー上でインスタンスを動かすように設定を調整する必要がある場合、（`--config`, `--device`, `--storage`, `--target-project` を使用して）設定を直接指定するか、（`--no-profiles` か `--profile` を使って）プロファイルを経由して指定できます。すべての利用可能なフラグについては [`incus move --help`](incus_move.md) を参照してください。 (live-migration)= -## Live migration +## ライブマイグレーション -Live migration means migrating an instance while it is running. -This method is supported for virtual machines. -For containers, there is limited support. +ライブマイグレーションとはインスタンスの稼働中にマイグレートするという意味です。 +仮想マシンではフルにサポートされています。 +コンテナでは限定的にサポートされています。 (live-migration-vms)= -### Live migration for virtual machines +### 仮想マシンのライブマイグレーション -Virtual machines can be moved to another server while they are running, thus without any downtime. +仮想マシンは稼働したまま、つまり一切のダウンタイムなしで、別のサーバーに移動できます。 -To allow for live migration, you must enable support for stateful migration. -To do so, ensure the following configuration: +ライブマイグレーションを可能にするには、ステートフルマイグレーションのサポートを有効にする必要があります。 +そのためには、以下の設定を確認してください。 -* Set {config:option}`instance-migration:migration.stateful` to `true` on the instance. -* Set [`size.state`](devices-disk) of the virtual machine's root disk device to at least the size of the virtual machine's {config:option}`instance-resource-limits:limits.memory` setting. +* インスタンスの {config:option}`instance-migration:migration.stateful` を `true` に設定する。 +* 仮想マシンのルートディスクデバイスの [`size.state`](devices-disk) を少なくとも仮想マシンの {config:option}`instance-resource-limits:limits.memory` 設定のサイズに設定する。 (live-migration-containers)= -### Live migration for containers +### コンテナのライブマイグレーション -For containers, there is limited support for live migration using [{abbr}`CRIU (Checkpoint/Restore in Userspace)`](https://criu.org/). -However, because of extensive kernel dependencies, only very basic containers (non-`systemd` containers without a network device) can be migrated reliably. -In most real-world scenarios, you should stop the container, move it over and then start it again. +コンテナについては [{abbr}`CRIU (Checkpoint/Restore in Userspace)`](https://criu.org/) を使用したライブマイグレーションが限定的にサポートされています。 +しかし、広範囲に及ぶカーネルへの依存のため、非常にベーシックなコンテナ（ネットワークデバイスなしの非 `systemd` コンテナ）のみが安定してマイグレートできます。 +ほとんどの実世界でのシナリオでは、コンテナを停止、移動してその後起動するのが良いです。 -If you want to use live migration for containers, you must first make sure that CRIU is installed on both systems. +コンテナのライブマイグレーションを使用したい場合、マイグレーション元と先の両方のサーバーで CRIU を有効にする必要があります。 -To optimize the memory transfer for a container, set the {config:option}`instance-migration:migration.incremental.memory` property to `true` to make use of the pre-copy features in CRIU. -With this configuration, Incus instructs CRIU to perform a series of memory dumps for the container. -After each dump, Incus sends the memory dump to the specified remote. -In an ideal scenario, each memory dump will decrease the delta to the previous memory dump, thereby increasing the percentage of memory that is already synced. -When the percentage of synced memory is equal to or greater than the threshold specified via {config:option}`instance-migration:migration.incremental.memory.goal`, or the maximum number of allowed iterations specified via {config:option}`instance-migration:migration.incremental.memory.iterations` is reached, Incus instructs CRIU to perform a final memory dump and transfers it. +コンテナのメモリー転送を最適化するには {config:option}`instance-migration:migration.incremental.memory` プロパティを `true` に設定して CRIU の事前コピー機能を使用してください。 +この設定では Incus はコンテナの一連のメモリーダーンプを実行するよう CRIU に指示します。 +それぞれのダンプの後、 Incus はメモリーダーンプを指定されたリモートに送信します。 +理想的なシナリオでは、各メモリーダーンプを前のメモリーダーンプとの差分にまで減らし、それによりすでに同期されたメモリーの割合を増やします。 +同期されたメモリーの割合が {config:option}`instance-migration:migration.incremental.memory.goal` で設定した閾値と等しいか超えた場合、あるいは {config:option}`instance-migration:migration.incremental.memory.iterations` で指定された許容される繰り返し回数の最大値に達した場合、 Incus は CRIU に最終的なメモリーダーンプを実行し、転送するように要求します。 diff --git a/doc/howto/network_acls.md b/doc/howto/network_acls.md index 2fe902bdfad..b8ac3e546d1 100644 --- a/doc/howto/network_acls.md +++ b/doc/howto/network_acls.md @@ -1,218 +1,217 @@ (network-acls)= -# How to configure network ACLs +# ネットワーク ACL を設定するには ```{note} -Network ACLs are available for the {ref}`OVN NIC type `, the {ref}`network-ovn` and the {ref}`network-bridge` (with some exceptions, see {ref}`network-acls-bridge-limitations`). +ネットワーク ACL は {ref}`OVN NIC タイプ `、{ref}`network-ovn` と {ref}`network-bridge`（いくつか制限あり、{ref}`network-acls-bridge-limitations` 参照）で利用できます。 ``` -Network {abbr}`ACLs (Access Control Lists)` define traffic rules that allow controlling network access between different instances connected to the same network, and access to and from other networks. +ネットワーク {abbr}`ACL (Access Control Lists; アクセス制御リスト)` は同じネットワークに接続された異なるインスタンス間のネットワークアクセスや、他のネットワークとのアクセスを制御するトラフィクルールを定義します。 -Network ACLs can be assigned directly to the {abbr}`NIC (Network Interface Controller)` of an instance or to a network. -When assigned to a network, the ACL applies to all NICs connected to the network. +ネットワーク ACL は インスタンスの {abbr}`NIC (Network Interface Controller; ネットワークインタフェースコントローラ)` やネットワークに直接適用できます。 +ネットワークに適用するときは、ネットワークに接続されたすべての NIC に ACL が適用されます。 -The instance NICs that have a particular ACL applied (either explicitly or implicitly through a network) make up a logical group, which can be referenced from other rules as a source or destination. -See {ref}`network-acls-groups` for more information. +特定の ACL を(明示的にあるいはネットワークから暗黙的に)適用したインスタンス NIC は論理的なグループを形成し、他のルールから送信元あるいは送信先として参照できます。 +より詳細な情報は {ref}`network-acls-groups` を参照してください。 -## Create an ACL +## ACL を作成する -Use the following command to create an ACL: +ACL を作成するには以下のコマンドを使用します: ```bash incus network acl create [configuration_options...] ``` -This command creates an ACL without rules. -As a next step, {ref}`add rules ` to the ACL. +このコマンドはルール無しの ACL を作成します。 +次のステップとして ACL に {ref}`ルールを追加します `。 -Valid network ACL names must adhere to the following rules: +有効なネットワーク ACL の名前は以下のルールに従う必要があります。 -- Names must be between 1 and 63 characters long. -- Names must be made up exclusively of letters, numbers and dashes from the ASCII table. -- Names must not start with a digit or a dash. -- Names must not end with a dash. +- 名前は 1 文字から 63 文字の間である。 +- 名前は ASCII の文字、数字、ハイフンからのみなる。 +- 名前は数字やハイフンから始まらない。 +- 名前はハイフンで終わらない。 -### ACL properties +### ACL のプロパティ -ACLs have the following properties: +ACL のプロパティには次のものがあります: -Property | Type | Required | Description -:-- | :-- | :-- | :-- -`name` | string | yes | Unique name of the network ACL in the project -`description` | string | no | Description of the network ACL -`ingress` | rule list | no | Ingress traffic rules -`egress` | rule list | no | Egress traffic rules -`config` | string set | no | Configuration options as key/value pairs (only `user.*` custom keys supported) +プロパティ | 型 | 必須 | 説明 +:-- | :-- | :-- | :-- +`name` | string | yes | プロジェクト内でユニークなネットワーク ACL の名前 +`description` | string | no | ネットワーク ACL の説明 +`ingress` | rule list | no | 内向きのトラフィックルールのリスト +`egress` | rule list | no | 外向きのトラフィックルールのリスト +`config` | string set | no | キー・バリューペア形式での設定オプション（`user.*` カスタムキーのみサポート） (network-acls-rules)= -## Add or remove rules +## ルールの追加と削除 -Each ACL contains two lists of rules: +それぞれの ACL はルールの 2 つのリストを含みます。 -- *Ingress* rules apply to inbound traffic going towards the NIC. -- *Egress* rules apply to outbound traffic leaving the NIC. +- *イングレス (ingress)* ルールは NIC に向かう内向きのトラフィックに適用されます。 +- *エグレス (egress)* ルールは NIC から出ていく外向きのトラフィックに適用されます。 -To add a rule to an ACL, use the following command, where `` can be either `ingress` or `egress`: +ACL にルールを追加するには、以下のコマンドを使います。 `` には `ingress` か `egress` のどちらかを指定します: ```bash incus network acl rule add [properties...] ``` -This command adds a rule to the list for the specified direction. +このコマンドは指定した方向（direction）に対応するリストにルールを追加します。 -You cannot edit a rule (except if you {ref}`edit the full ACL `), but you can delete rules with the following command: +（{ref}`ACL 全体を編集する ` 場合を除き）ルールを編集することはできませんが、以下のコマンドでルールを削除はできます: ```bash incus network acl rule remove [properties...] ``` -You must either specify all properties needed to uniquely identify a rule or add `--force` to the command to delete all matching rules. +ユニークにルールを特定するのに必要なすべてのプロパティを指定するか、またはマッチしたすべてのルールを削除するためコマンドに `--force` を追加する必要があります。 -### Rule ordering and priorities +### ルールの順番と優先度 -Rules are provided as lists. -However, the order of the rules in the list is not important and does not affect -filtering. +ルールはリストとして提供されます。 +しかしリスト内のルールの順番は重要ではなくフィルタリングには影響しません。 -Incus automatically orders the rules based on the `action` property as follows: +Incus は以下のように `action` プロパティに基づいてルールの順番を自動的に決めます: - `drop` - `reject` - `allow` -- Automatic default action for any unmatched traffic (defaults to `reject`, see {ref}`network-acls-defaults`). +- 上記のすべてにマッチしなかったトラフィックに対する自動のデフォルトアクション（￥デフォルトでは `reject`、{ref}`network-acls-defaults` 参照）。 -This means that when you apply multiple ACLs to a NIC, there is no need to specify a combined rule ordering. -If one of the rules in the ACLs matches, the action for that rule is taken and no other rules are considered. +これは NIC に複数の ACL を適用する際、組み合わせたルールの順番を指定する必要がないことを意味します。 +ACL 内のあるルールがマッチすれば、そのルールが採用され、他のルールは考慮されません。 -### Rule properties +### ルールのプロパティ -ACL rules have the following properties: +ACL ルールには次のプロパティがあります: -Property | Type | Required | Description -:-- | :-- | :-- | :-- -`action` | string | yes | Action to take for matching traffic (`allow`, `reject` or `drop`) -`state` | string | yes | State of the rule (`enabled`, `disabled` or `logged`), defaulting to `enabled` if not specified -`description` | string | no | Description of the rule -`source` | string | no | Comma-separated list of CIDR or IP ranges, source subject name selectors (for ingress rules), or empty for any -`destination` | string | no | Comma-separated list of CIDR or IP ranges, destination subject name selectors (for egress rules), or empty for any -`protocol` | string | no | Protocol to match (`icmp4`, `icmp6`, `tcp`, `udp`) or empty for any -`source_port` | string | no | If protocol is `udp` or `tcp`, then a comma-separated list of ports or port ranges (start-end inclusive), or empty for any -`destination_port`| string | no | If protocol is `udp` or `tcp`, then a comma-separated list of ports or port ranges (start-end inclusive), or empty for any -`icmp_type` | string | no | If protocol is `icmp4` or `icmp6`, then ICMP type number, or empty for any -`icmp_code` | string | no | If protocol is `icmp4` or `icmp6`, then ICMP code number, or empty for any + +プロパティ | 型 | 必須 | 説明 +:-- | :-- | :-- | :-- +`action` | string | yes | マッチしたトラフィックに適用するアクション（`allow`, `reject` または `drop`） +`state` | string | yes | ルールの状態（`enabled`, `disabled` または `logged`）、未設定の場合のデフォルト値は `enabled` +`description` | string | no | ルールの説明 +`source` | string | no | CIDR か IP の範囲、送信元の ACL の名前、あるいは（ingress ルールに対しての） ソースサブジェクト名セレクターのカンマ区切りリスト、または any の場合は空を指定 +`destination` | string | no | CIDR か IP の範囲、送信先の ACL の名前、あるいは（egress ルールに対しての） デスティネーションサブジェクト名セレクターのカンマ区切りリスト、または any の場合は空を指定 +`protocol` | string | no | マッチ対象のプロトコル（`icmp4`, `icmp6`, `tcp`, `udp`）、または any の場合は空を指定 +`source_port` | string | no | protocol が `udp` か `tcp` の場合はポートかポートの範囲（開始-終了で両端含む）のカンマ区切りリスト、または any の場合は空を指定 +`destination_port` | string | no | protocol が `udp` か `tcp` の場合はポートかポートの範囲（開始-終了で両端含む）のカンマ区切りリスト、または any の場合は空を指定 +`icmp_type` | string | no | protocol が `icmp4` か `icmp6` の場合は ICMP の Type 番号、または any の場合は空を指定 +`icmp_code` | string | no | protocol が `icmp4` か `icmp6` の場合は ICMP の Code 番号、または any の場合は空を指定 (network-acls-selectors)= -### Use selectors in rules +### ルール内でセレクタを使う ```{note} -This feature is supported only for the {ref}`OVN NIC type ` and the {ref}`network-ovn`. +この機能は {ref}`OVN NIC タイプ ` と {ref}`network-ovn` でのみサポートされます。 ``` -The `source` field (for ingress rules) and the `destination` field (for egress rules) support using selectors instead of CIDR or IP ranges. +（ingress ルールの）`source` フィールドと （egress ルールの）`destination` フィールドは CIDR や IP の範囲の代わりにセレクタの使用をサポートします。 -With this method, you can use ACL groups or network selectors to define rules for groups of instances without needing to maintain IP lists or create additional subnets. +この機能を使えば、 IP のリストを管理したり追加のサブネットを作ることなしに、 ACL グループかネットワークセレクタを使ってインスタンスのグループに対するルールを定義できます。 (network-acls-groups)= -#### ACL groups +#### ACL グループ -Instance NICs that are assigned a particular ACL (either explicitly or implicitly through a network) make up a logical port group. +（明示的にあるいはネットワーク経由で暗黙的に）特定の ACL を適用されたインスタンス NIC は論理的なポートグループを形成します。 -Such ACL groups are called *subject name selectors*, and they can be referenced with the name of the ACL in other ACL groups. +そのような ACL グループは *サブジェクト名セレクタ* と呼ばれ、他の ACL グループ内で ACL 名を用いて参照できます。 -For example, if you have an ACL with the name `foo`, you can specify the group of instance NICs that are assigned this ACL as source with `source=foo`. +たとえば `foo` という名前の ACL がある場合、この ACL が適用されたインスタンス NIC のグループを `source=foo` で参照できます。 -#### Network selectors +#### ネットワークセレクタ -You can use *network subject selectors* to define rules based on the network that the traffic is coming from or going to. +*ネットワークサブジェクトセレクタ* を用いて、ネットワーク上の外向きと内向きのトラフィックにルールを定義できます。 -There are two special network subject selectors called `@internal` and `@external`. -They represent network local and external traffic, respectively. -For example: +`@internal` と `@external` という 2 つの特別なネットワークサブジェクトセレクタがあります。 +これらはそれぞれネットワークのローカルと外向きのトラフィックを示します。 +たとえば: ```bash source=@internal ``` -If your network supports [network peers](network_ovn_peers.md), you can reference traffic to or from the peer connection by using a network subject selector in the format `@/`. -For example: +ネットワークが [ネットワークピア](network_ovn_peers.md) をサポートする場合、ピア接続間のトラフィックを +`@/` という形式のネットワークサブジェクトセレクタで参照できます。 +たとえば: ```bash source=@ovn1/mypeer ``` -When using a network subject selector, the network that has the ACL applied to it must have the specified peer connection. -Otherwise, the ACL cannot be applied to it. +ネットワークサブジェクトセレクターを使用する際は、 ACL 適用先のネットワークは指定されたピア接続を持っていなければなりません。 +持っていない場合 ACL は適用できません。 -### Log traffic +### トラフィックのログ -Generally, ACL rules are meant to control the network traffic between instances and networks. -However, you can also use them to log specific network traffic, which can be useful for monitoring, or to test rules before actually enabling them. +一般的には ACL はインスタンスとネットワーク間のネットワークトラフィックを制御するためのものです。 +しかし、特定のネットワークトラフィックをログ出力するためにルールを使うこともできます。 +これはモニタリングや、ルールを実際に有効にする前にテストするのに役立ちます。 -To add a rule for logging, create it with the `state=logged` property. -You can then display the log output for all logging rules in the ACL with the following command: +ログのためにルールを追加するには `state=logged` プロパティ付きでルールを作成してください。 +ACL 内のすべてのログのルールに対するログ出力は以下のコマンドで表示できます: ```bash incus network acl show-log ``` (network-acls-edit)= -## Edit an ACL +## ACL を編集する -Use the following command to edit an ACL: +ACL を編集するには以下のコマンドを使用します: ```bash incus network acl edit ``` -This command opens the ACL in YAML format for editing. -You can edit both the ACL configuration and the rules. +このコマンドは ACL を編集用に YAML 形式でオープンします。 +ACL 設定とルールの両方を編集できます。 -## Assign an ACL +## ACL の適用 -After configuring an ACL, you must assign it to a network or an instance NIC. +ACL の設定が終わったらネットワークかインスタンス NIC に適用する必要があります。 -To do so, add it to the `security.acls` list of the network or NIC configuration. -For networks, use the following command: +そのためにはネットワークか NIC の設定の `security.acls` リストに ACL を追加してください。 +ネットワークの場合は、以下のコマンドを使います: ```bash incus network set security.acls="" ``` -For instance NICs, use the following command: +インスタンス NIC の場合は、以下のコマンドを使います: ```bash incus config device set security.acls="" ``` (network-acls-defaults)= -## Configure default actions +## デフォルトアクションの設定 -When one or more ACLs are applied to a NIC (either explicitly or implicitly through a network), a default reject rule is added to the NIC. -This rule rejects all traffic that doesn't match any of the rules in the applied ACLs. +1 つ以上の ACL が NIC に（明示的にあるいはネットワーク経由で暗黙的に）適用されると、 NIC にデフォルトの reject ルールが追加されます。 +このルールは適用された ACL 内のどのルールにもマッチしないすべてのトラフィックを拒否（reject）します。 -You can change this behavior with the network and NIC level `security.acls.default.ingress.action` and `security.acls.default.egress.action` settings. -The NIC level settings override the network level settings. +この挙動はネットワークと NIC レベルの `security.acls.default.ingress.action` と `security.acls.default.egress.action` 設定で変更できます。 +NIC レベルの設定はネットワークレベルの設定を上書きします。 -For example, to set the default action for inbound traffic to `allow` for all instances connected to a network, use the following command: +たとえば、ネットワークに接続されたすべてのインスタンスの内向きのトラフィックを許可（`allow`）するには以下のコマンドを使用します: ```bash incus network set security.acls.default.ingress.action=allow ``` -To configure the same default action for an instance NIC, use the following command: +インスタンス NIC に同じデフォルトアクションを設定するには以下のコマンドを使用します: ```bash incus config device set security.acls.default.ingress.action=allow ``` (network-acls-bridge-limitations)= -## Bridge limitations +## ブリッジの制限 -When using network ACLs with a bridge network, be aware of the following limitations: +ブリッジネットワークにネットワーク ACL を使用する場合は以下の制限に気を付けてください。 -- Unlike OVN ACLs, bridge ACLs are applied only on the boundary between the bridge and the Incus host. - This means they can only be used to apply network policies for traffic going to or from external networks. - They cannot be used for to create {spellexception}`intra-bridge` firewalls, thus firewalls that control traffic between instances connected to the same bridge. -- {ref}`ACL groups and network selectors ` are not supported. -- When using the `iptables` firewall driver, you cannot use IP range subjects (for example, `192.0.2.1-192.0.2.10`). -- Baseline network service rules are added before ACL rules (in their respective INPUT/OUTPUT chains), because we cannot differentiate between INPUT/OUTPUT and FORWARD traffic once we have jumped into the ACL chain. - Because of this, ACL rules cannot be used to block baseline service rules. +- OVN ACL とは違い、ブリッジ ACL はブリッジと Incus ホストの間の境界のみに適用されます。これは外部へと外部からのトラフィックにネットワークポリシーを適用するために使うことしかできないことを意味します。ブリッジ間のファイアウォール、つまり同じブリッジに接続されたインスタンス間のトラフィックを制御するファイアウォールには使えません。 +- {ref}`ACL グループとネットワークセレクタ ` はサポートされません。 +- `iptables` ファイアウォールドライバーを使う際は、 IP レンジサブジェクト（例：`192.0.2.1-192.0.2.10`）は使用できません。 +- ベースラインのネットワークサービスルールが（対応する INPUT/OUTPUT チェイン内の） ACL ルールの前に適用されます。これは一旦 ACL チェインに入ってしまうと INPUT/OUTPUT と FORWARD トラフィックを区別できないからです。このため ACL ルールはベースラインのサービスルールをブロックするのには使えません。 diff --git a/doc/howto/network_bgp.md b/doc/howto/network_bgp.md index e0dd5ad871f..63a212db47f 100644 --- a/doc/howto/network_bgp.md +++ b/doc/howto/network_bgp.md @@ -1,46 +1,45 @@ (network-bgp)= -# How to configure Incus as a BGP server - +# Incus を BGP サーバーとして設定するには ```{note} -The BGP server feature is available for the {ref}`network-bridge` and the {ref}`network-physical`. +BGP サーバー機能は　{ref}`network-bridge` と {ref}`network-physical` で利用できます。 ``` -{abbr}`BGP (Border Gateway Protocol)` is a protocol that allows exchanging routing information between autonomous systems. +{abbr}`BGP (Border Gateway Protocol)` は自律システム間でルーティング情報を交換できるプロトコルです。 -If you want to directly route external addresses to specific Incus servers or instances, you can configure Incus as a BGP server. -Incus will then act as a BGP peer and advertise relevant routes and next hops to external routers, for example, your network router. -It automatically establishes sessions with upstream BGP routers and announces the addresses and subnets that it's using. +外部アドレスを特定の Incus サーバーやインスタンスに直接ルーティングしたい場合は、 Incus を BGP サーバーとして設定できます。 +すると Incus は BGP ピアとして振る舞い、関連するルートとネクストホップを外部のルータ、たとえば、あなたのネットワークルータに広告します。 +アップストリームの BGP ルータとセッションを自動的に確立し、使用中のアドレスとサブネットを広告します。 -The BGP server feature can be used to allow a Incus server or cluster to directly use internal/external address space by getting the specific subnets or addresses routed to the correct host. -This way, traffic can be forwarded to the target instance. +BGP サーバー機能は Incus サーバーやクラスタが正しいホストへルーティングされる特定のサブネットやアドレスを取得することで内部／外部アドレス空間を直接使用できるようにします。 +こうすることで、トラフィックを対象のインスタンスにフォワードできます。 -For bridge networks, the following addresses and networks are being advertised: +ブリッジネットワークについては、以下のアドレスとネットワークが広告されます: -- Network `ipv4.address` or `ipv6.address` subnets (if the matching `nat` property isn't set to `true`) -- Network `ipv4.nat.address` or `ipv6.nat.address` subnets (if the matching `nat` property is set to `true`) -- Network forward addresses -- Addresses or subnets specified in `ipv4.routes.external` or `ipv6.routes.external` on an instance NIC that is connected to the bridge network +- `ipv4.address` または `ipv6.address` サブネットのネットワーク（対応する `nat` プロパティが `true` に設定されていない場合） +- `ipv4.nat.address` または `ipv6.nat.address` サブネットのネットワーク（対応する `nat` プロパティが `true` に設定されていない場合） +- ネットワークフォワードアドレス +- ブリッジネットワークに接続されているインスタンス NIC 上の `ipv4.routes.external` または `ipv6.routes.external` で指定されているアドレスまたはサブネット -Make sure to add your subnets to the respective configuration options. -Otherwise, they won't be advertised. +サブネットを対応する設定オプションに確実に追加してください。 +さもなければ、広告されません。 -For physical networks, no addresses are advertised directly at the level of the physical network. -Instead, the networks, forwards and routes of all downstream networks (the networks that specify the physical network as their uplink network through the `network` option) are advertised in the same way as for bridge networks. +物理ネットワークについては、物理ネットワークのレベルに直接広告されるアドレスはありません。 +代わりに、すべてのダウンストリームネットワーク（`network` オプションで物理ネットワークをアップリンクネットワークとして指定するネットワーク）のネットワーク、フォワードとルートがブリッジネットワークに対するのと同じように広告されます。 ```{note} -At this time, it is not possible to announce only some specific routes/addresses to particular peers. -If you need this, filter prefixes on the upstream routers. +現時点では、特定のピアに一部の特定のルート／アドレスのみを広告することはできません。 +これが必要な場合はアップストリームルータでプリフィクスをフィルタしてください。 ``` -## Configure the BGP server +## BGP サーバーを設定する -To configure Incus as a BGP server, set the following server configuration options on all cluster members: +Incus を BGP サーバーとして設定するには、以下のサーバー設定オプションをすべてのクラスタメンバーで設定してください: -- {config:option}`server-core:core.bgp_address` - the IP address for the BGP server -- {config:option}`server-core:core.bgp_asn` - the {abbr}`ASN (Autonomous System Number)` for the local server -- {config:option}`server-core:core.bgp_routerid` - the unique identifier for the BGP server +- {config:option}`server-core:core.bgp_address` - BGP サーバーの IP アドレス +- {config:option}`server-core:core.bgp_asn` - ローカルサーバーの {abbr}`ASN (Autonomous System Number)` +- {config:option}`server-core:core.bgp_routerid` - BGP サーバーのユニークな識別子 -For example, set the following values: +たとえば、以下のような値を設定します: ```bash incus config set core.bgp_address=192.0.2.50:179 @@ -48,26 +47,26 @@ incus config set core.bgp_asn=65536 incus config set core.bgp_routerid=192.0.2.50 ``` -Once these configuration options are set, Incus starts listening for BGP sessions. +これらの設定オプションが一旦設定されると、 Incus は BGP セッションのリッスンを始めます。 -### Configure next-hop (`bridge` only) +### ネクストホップを設定する（`bridge` のみ） -For bridge networks, you can override the next-hop configuration. -By default, the next-hop is set to the address used for the BGP session. +ブリッジネットワークについては、ネクストホップ設定をオーバーライドできます。 +デフォルトでは、ネクストホップは BGP セッションに使用されるアドレスに設定されます。 -To configure a different address, set `bgp.ipv4.nexthop` or `bgp.ipv6.nexthop`. +別のアドレスに設定するには、 `bgp.ipv4.nexthop` または `bgp.ipv6.nexthop` を設定してください。 -### Configure BGP peers for OVN networks +### OVN ネットワークに BGP ピアを設定する -If you run an OVN network with an uplink network (`physical` or `bridge`), the uplink network is the one that holds the list of allowed subnets and the BGP configuration. -Therefore, you must configure BGP peers on the uplink network that contain the information that is required to connect to the BGP server. +OVN ネットワークをアップリンクネットワーク（`physical` または `bridge`）と使用する場合、アップリンクネットワークは許可されるサブネット一覧と BGP 設定を持つネットワークです。 +このため、 BGP サーバーに接続するのに必要な情報を含むアップリンクネットワーク上に BGP ピアを設定する必要があります。 -Set the following configuration options on the uplink network: +アップリンクネットワークに対して以下の設定オプションを設定してください: -- `bgp.peers..address` - the peer address to be used by the downstream networks -- `bgp.peers..asn` - the {abbr}`ASN (Autonomous System Number)` for the local server -- `bgp.peers..password` - an optional password for the peer session -- `bgp.peers..holdtime` - an optional hold time for the peer session (in seconds) +- `bgp.peers..address` - ダウンストリームネットワークで使用されるピアアドレス +- `bgp.peers..asn` - ローカルサーバーの {abbr}`ASN (Autonomous System Number)` +- `bgp.peers..password` - ピアセッションに対するオプショナルなパスワード +- `bgp.peers..holdtime` - ピアセッションに対する省略可能なホールドタイム (秒で指定) -Once the uplink network is configured, downstream OVN networks will get their external subnets and addresses announced over BGP. -The next-hop is set to the address of the OVN router on the uplink network. +アップリンクネットワークが一旦設定されると、ダウンストリームの OVN ネットワークは BGP で広告される外部のサブネットとアドレスを取得します。 +ネクストホップはアップリンクネットワークの OVN ルータのアドレスに設定されます。 diff --git a/doc/howto/network_bridge_firewalld.md b/doc/howto/network_bridge_firewalld.md index 71f5b12d76d..7dff4d77f47 100644 --- a/doc/howto/network_bridge_firewalld.md +++ b/doc/howto/network_bridge_firewalld.md @@ -1,58 +1,59 @@ (network-bridge-firewall)= -# How to configure your firewall +# ファイアウォールを設定するには -Linux firewalls are based on `netfilter`. -Incus uses the same subsystem, which can lead to connectivity issues. +Linux のファイアウォールは `netfilter` をベースにしています。 +Incus は同じサブシステムを使用しているため、接続に問題を引き起こすことがありえます。 -If you run a firewall on your system, you might need to configure it to allow network traffic between the managed Incus bridge and the host. -Otherwise, some network functionality (DHCP, DNS and external network access) might not work as expected. +ファイアウォールを動かしている場合、 Incus が管理しているブリッジとホストの間のネットワークトラフィックを許可するように設定する必要があるかもしれません。 +そうしないと、一部のネットワークの機能（DHCP、DNS と外部ネットワークへのアクセス）が期待通り動かないかもしれません。 -You might also see conflicts between the rules defined by your firewall (or another application) and the firewall rules that Incus adds. -For example, your firewall might erase Incus rules if it is started after the Incus daemon, which might interrupt network connectivity to the instance. +ファイアウォール（あるいは他のアプリケーション）に設定されたルールと Incus が追加するファイアウォールのルールが衝突するケースがあります。 +たとえば、ファイアウォールが Incus デーモンより後に起動した場合ファイアウォールが Incus のルールを削除するかもしれず、そうするとインスタンスへのネットワーク接続を妨げるかもしれません。 -## `xtables` vs. `nftables` +## `xtables` 対 `nftables` -There are different userspace commands to add rules to `netfilter`: `xtables` (`iptables` for IPv4 and `ip6tables` for IPv6) and `nftables`. +`netfilter` にルールを追加するには `xtables`（IPv4 には `iptables` と IPv6 には `ip6tables`）と `nftables` という異なるユーザースペースのコマンドがあります。 -`xtables` provides an ordered list of rules, which might cause issues if multiple systems add and remove entries from the list. -`nftables` adds the ability to separate rules into namespaces, which helps to separate rules from different applications. -However, if a packet is blocked in one namespace, it is not possible for another namespace to allow it. -Therefore, rules in one namespace can still affect rules in another namespace, and firewall applications can still impact Incus network functionality. +`xtables` は順序ありのルールのリストを提供しますが、そのため複数のシステムがルールの追加や削除を行うと問題が起きるかもしれません。 +`nftables` は分離されたルールを別々の Namespace に追加することができますので、異なるアプリケーションからのルールを分離するのに役立ちます。 +しかし、パケットが 1 つの Namespace でブロックされる場合、他の Namespace がそれを許可することはできません。 +そのため、 1 つの Namespace が他の Namespace のルールへ影響することは依然としてあり、ファイアウォールのアプリケーションが Incus のネットワーク機能に影響することがありえます。 -If your system supports and uses `nftables`, Incus detects this and switches to `nftables` mode. -In this mode, Incus adds its rules into the `nftables`, using its own `nftables` namespace. +システムで `nftables` を利用可能な場合、 Incus はそれを検知して `nftables` モードにスイッチします。 +このモードでは Incus は自身の `nftables` の Namespace を用いてルールを `nftables` に追加します。 -## Use Incus' firewall +## Incus のファイアウォールを使用する -By default, managed Incus bridges add firewall rules to ensure full functionality. -If you do not run another firewall on your system, you can let Incus manage its firewall rules. +デフォルトでは Incus が管理するブリッジはフル機能を使えるようにするためファイアウォールにルールを追加します。 +システムで他のファイアウォールを使用していない場合は Incus にファイアウォールのルールを管理させることができます。 -To enable or disable this behavior, use the `ipv4.firewall` or `ipv6.firewall` {ref}`configuration options `. +これを有効または無効にするには `ipv4.firewall` または `ipv6.firewall` {ref}`設定オプション ` を使用してください。 -## Use another firewall +## 別のファイアウォールを使用する -Firewall rules added by other applications might interfere with the firewall rules that Incus adds. -Therefore, if you use another firewall, you should disable Incus' firewall rules. -You must also configure your firewall to allow network traffic between the instances and the Incus bridge, so that the Incus instances can access the DHCP and DNS server that Incus runs on the host. +別のアプリケーションが追加するファイアウォールのルールは Incus が追加するファイアウォールルールと干渉するかもしれません。 +このため、別のファイアウォールを使用する場合は Incus のファイアウォールルールを無効にするべきです。 +また Incus のインスタンスがホスト上で Incus が動かしている DHCP と DNS サーバーにアクセスできるようにするため、 +インスタンスと Incus ブリッジ間のネットワークトラフィックを許可するように設定しなければなりません。 -See the following sections for instructions on how to disable Incus' firewall rules and how to properly configure `firewalld` and UFW, respectively. +Incus のファイアウォールルールをどのように無効化し、 `firewalld` と UFW をどのように適切に設定するかは以下を参照してください。 -### Disable Incus' firewall rules +### Incus のファイアウォールルールを無効化する -Run the following commands to prevent Incus from setting firewall rules for a specific network bridge (for example, `incusbr0`): +指定のネットワークブリッジ（たとえば、`incusbr0`）に Incus がファイアウォールルールを設定しないようにするためには以下のコマンドを実行してください: incus network set ipv6.firewall false incus network set ipv4.firewall false -### `firewalld`: Add the bridge to the trusted zone +### `firewalld` で信頼されたゾーンにブリッジを追加する -To allow traffic to and from the Incus bridge in `firewalld`, add the bridge interface to the `trusted` zone. -To do this permanently (so that it persists after a reboot), run the following commands: +`firewalld` で Incus ブリッジへとブリッジからのトラフィックを許可するには、ブリッジインターフェースを `trusted` ゾーンに追加してください。 +（再起動後も設定が残るように）永続的にこれを行うには以下のコマンドを実行してください: sudo firewall-cmd --zone=trusted --change-interface= --permanent sudo firewall-cmd --reload -For example: +たとえば: sudo firewall-cmd --zone=trusted --change-interface=incusbr0 --permanent sudo firewall-cmd --reload @@ -60,24 +61,24 @@ For example: ```{warning} -The commands given above show a simple example configuration. -Depending on your use case, you might need more advanced rules and the example configuration might inadvertently introduce a security risk. +上に示したコマンドはシンプルな例です。 +あなたの使い方に応じて、より高度なルールが必要な場合があり、その場合上の例をそのまま実行するとうっかりセキュリティリスクを引き起こす可能性があります。 ``` -### UFW: Add rules for the bridge +### UFW でブリッジにルールを追加する -If UFW has a rule to drop all unrecognized traffic, it blocks the traffic to and from the Incus bridge. -In this case, you must add rules to allow traffic to and from the bridge, as well as allowing traffic forwarded to it. +UFW で認識不能なトラフィックをすべてドロップするルールを入れていると、 Incus ブリッジへとブリッジからのトラフィックをブロックしてしまいます。 +この場合ブリッジへとブリッジからのトラフィックを許可し、さらにブリッジへフォワードされるトラフィックを許可するルールを追加する必要があります。 -To do so, run the following commands: +そのためには次のコマンドを実行します: sudo ufw allow in on sudo ufw route allow in on sudo ufw route allow out on -For example: +たとえば: sudo ufw allow in on incusbr0 sudo ufw route allow in on incusbr0 @@ -90,57 +91,57 @@ For example: ``` (network-incus-docker)= -## Prevent connectivity issues with Incus and Docker +## Incus と Docker の接続の問題を回避する -Running Incus and Docker on the same host can cause connectivity issues. -A common reason for these issues is that Docker sets the global FORWARD policy to `drop`, which prevents Incus from forwarding traffic and thus causes the instances to lose network connectivity. -See [Docker on a router](https://docs.docker.com/network/iptables/#docker-on-a-router) for detailed information. +同じホストで Incus と Docker を動かすと接続の問題を引き起こします。 +この問題のよくある理由は Docker はグローバルの FOWARD のポリシーを `drop` に設定するので、それが Incus がトラフィックをフォワードすることを妨げインスタンスのネットワーク接続を失わせるということです。 +詳細は [Docker on a router](https://docs.docker.com/network/iptables/#docker-on-a-router) を参照してください。 -There are different ways of working around this problem: +この問題を回避するためのさまざまな方法があります: -Uninstall Docker -: The easiest way to prevent such issues is to uninstall Docker from the system that runs Incus and restart the system. - You can run Docker inside a Incus container or virtual machine instead. +Docker をアンインストールする +: このような問題を防ぐ最も簡単な方法は、Incus を実行しているシステムから Docker をアンインストールしてシステムを再起動することです。 + 代わりに、Incus のコンテナや仮想マシンの中で Docker を実行できます。 -Enable IPv4 forwarding -: If uninstalling Docker is not an option, enabling IPv4 forwarding before the Docker service starts will prevent Docker from modifying the global FORWARD policy. - Incus bridge networks enable this setting normally. - However, if Incus starts after Docker, then Docker will already have modified the global FORWARD policy. +IPv4 の転送を有効にする +: Docker をアンインストールすることができない場合、Docker サービスが開始する前に IPv4 転送を有効にすることで、Docker がグローバル FORWARD ポリシーを変更するのを防ぐことができます。 + Incus ブリッジネットワークは通常、この設定を有効にします。 + しかし、Incus が Docker の後に起動すると、Docker は既にグローバル FORWARD ポリシーを変更している可能性があります。 ```{warning} - Enabling IPv4 forwarding can cause your Docker container ports to be reachable from any machine on your local network. - Depending on your environment, this might be undesirable. - See [local network container access issue](https://github.com/moby/moby/issues/14041) for more information. + IPv4の転送を有効にすると、Dockerのコンテナポートがローカルネットワーク上の任意のマシンからアクセス可能になる可能性があります。 + 環境によりますが、これは望ましくない場合があります。 + 詳細については、[ローカルネットワークのコンテナアクセス問題](https://github.com/moby/moby/issues/14041)を参照してください。 ``` - To enable IPv4 forwarding before Docker starts, ensure that the following `sysctl` setting is enabled: + Docker が開始する前に IPv4 転送を有効にするためには、次の`sysctl`設定が有効になっていることを確認します: net.ipv4.conf.all.forwarding=1 ```{important} - You must make this setting persistent across host reboots. + この設定はホストの再起動時にも保持されるようにする必要があります。 - One way of doing this is to add a file to the `/etc/sysctl.d/` directory using the following commands: + これを行う一つの方法は、次のコマンドを使用して`/etc/sysctl.d/`ディレクトリにファイルを追加することです: echo "net.ipv4.conf.all.forwarding=1" > /etc/sysctl.d/99-forwarding.conf systemctl restart systemd-sysctl ``` -Allow egress network traffic flows -: If you do not want the Docker container ports to be potentially reachable from any machine on your local network, you can apply a more complex solution provided by Docker. +外向きネットワークトラフィックフローを許可する +: Docker のコンテナポートがローカルネットワーク上の任意のマシンからアクセス可能になる可能性を避けたい場合、Docker が提供するより複雑なソリューションを適用できます。 - Use the following commands to explicitly allow egress network traffic flows from your Incus managed bridge interface: + 次のコマンドを使用して、Incus 管理ブリッジインターフェースからの外向きネットワークトラフィックフローを明示的に許可します: iptables -I DOCKER-USER -i -j ACCEPT iptables -I DOCKER-USER -o -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT - For example, if your Incus managed bridge is called `incusbr0`, you can allow egress traffic to flow using the following commands: + たとえば、Incus の管理ブリッジが`incusbr0`と呼ばれている場合、次のコマンドを使用して外向きトラフィックのフローを許可できます: iptables -I DOCKER-USER -i incusbr0 -j ACCEPT iptables -I DOCKER-USER -o incusbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT ```{important} - You must make these firewall rules persistent across host reboots. - How to do this depends on your Linux distribution. + これらのファイアウォールルールは、ホストの再起動時にも保持されるようにする必要があります。 + これを行う方法は Linux ディストリビューションによります。 ``` diff --git a/doc/howto/network_bridge_resolved.md b/doc/howto/network_bridge_resolved.md index f2ca6ae209f..9aa101f8f5c 100644 --- a/doc/howto/network_bridge_resolved.md +++ b/doc/howto/network_bridge_resolved.md @@ -1,72 +1,72 @@ (network-bridge-resolved)= -# How to integrate with `systemd-resolved` +# `systemd-resolved` と統合するには -If the system that runs Incus uses `systemd-resolved` to perform DNS lookups, you should notify `resolved` of the domains that Incus can resolve. -To do so, add the DNS servers and domains provided by a Incus network bridge to the `resolved` configuration. +Incus を実行するシステムが DNS ルックアップの実行に `systemd-resolved` を使用する場合、 `resolved` に Incus が名前解決できるドメインを通知するべきです。 +そうするには、 Incus ネットワークブリッジにより提供される DNS サーバーとドメインを `resolved` の設定に追加してください。 ```{note} -The `dns.mode` option (see {ref}`network-bridge-options`) must be set to `managed` or `dynamic` if you want to use this feature. +この機能を使いたい場合、 `dns.mode` オプション ({ref}`network-bridge-options` 参照) を `managed` か `dynamic` に設定する必要があります。 -Depending on the configured `dns.domain`, you might need to disable DNSSEC in `resolved` to allow for DNS resolution. -This can be done through the `DNSSEC` option in `resolved.conf`. +`dns.domain` の設定によっては、 DNS 名前解決を許可するため `resolved` の DNSSEC を無効化する必要があるかもしれません。 +これは `resolved.conf` 内の `DNSSEC` オプションにより実現できます。 ``` (network-bridge-resolved-configure)= -## Configure resolved +## resolved を設定する -To add a network bridge to the `resolved` configuration, specify the DNS addresses and domains for the respective bridge. +ネットワークブリッジを `resolved` 設定に追加するには、対応するブリッジの DNS アドレスとドメインを指定します。 -DNS address -: You can use the IPv4 address, the IPv6 address or both. - The address must be specified without the subnet netmask. +DNS アドレス +: IPv4 アドレス、 IPv6 アドレス、あるいは両方を使用できます。 + アドレスはサブネットのネットマスク無しで指定する必要があります。 - To retrieve the IPv4 address for the bridge, use the following command: + ブリッジの IPv4 アドレスを取得するには以下のコマンドを使用します: incus network get ipv4.address - To retrieve the IPv6 address for the bridge, use the following command: + ブリッジの IPv6 アドレスを取得するには以下のコマンドを使用します: incus network get ipv6.address -DNS domain -: To retrieve the DNS domain name for the bridge, use the following command: +DNS ドメイン +: ブリッジの DNS ドメイン名を取得するには以下のコマンドを使用します: incus network get dns.domain - If this option is not set, the default domain name is `incus`. + このオプションが設定されていない場合、デフォルトのドメイン名は `incus` です。 -Use the following commands to configure `resolved`: +`resolved` を設定するには以下のコマンドを使用します: resolvectl dns resolvectl domain ~ ```{note} -When configuring `resolved` with the DNS domain name, you should prefix the name with `~`. -The `~` tells `resolved` to use the respective name server to look up only this domain. +`resolved`でDNSドメインを指定する場合、ドメイン名に `~` の接頭辞をつけてください。 +`~` により `resolved` がこのドメインをルックアップするためだけに対応するネームサーバーを使うようになります。 -Depending on which shell you use, you might need to include the DNS domain in quotes to prevent the `~` from being expanded. +ご利用のシェルによっては `~` が展開されるのを防ぐために DNS ドメインを引用符で囲む必要があるかもしれません。 ``` -For example: +たとえば: resolvectl dns incusbr0 192.0.2.10 resolvectl domain incusbr0 '~incus' ```{note} -Alternatively, you can use the `systemd-resolve` command. -This command has been deprecated in newer releases of `systemd`, but it is still provided for backwards compatibility. +別の方法として、 `systemd-resolve` コマンドを使用することもできます。 +このコマンドは `systemd` の新しいリリースでは廃止予定となっていますが、後方互換性のため引き続き提供されています。 systemd-resolve --interface --set-domain ~ --set-dns ``` -The `resolved` configuration persists as long as the bridge exists. -You must repeat the commands after each reboot and after Incus is restarted, or make it persistent as described below. +`resolved` の設定はブリッジが存在する限り残ります。 +リブートのたびに Incus が再起動した後に上記のコマンドを実行するか、下記のように設定を永続的にする必要があります。 -## Make the `resolved` configuration persistent +## `resolved` の設定を永続的にする -You can automate the `systemd-resolved` DNS configuration, so that it is applied on system start and takes effect when Incus creates the network interface. +システムの起動時に適用され Incus がネットワークインターフェースを作成したときに有効になるように `systemd-resolved` の DNS 設定を自動化できます。 -To do so, create a `systemd` unit file named `/etc/systemd/system/incus-dns-.service` with the following content: +そうするには、 `/etc/systemd/system/lxd-dns-.service` という名前の `systemd` ユニットファイルを以下の内容で作成してください: ``` [Unit] @@ -85,19 +85,19 @@ RemainAfterExit=yes WantedBy=sys-subsystem-net-devices-.device ``` -Replace `` in the file name and content with the name of your bridge (for example, `incusbr0`). -Also replace `` and `` as described in {ref}`network-bridge-resolved-configure`. +ファイル名と内容で `` をブリッジの名前（たとえば `incusbr0`）に置き換えてください。 +さらに `` と `` を {ref}`network-bridge-resolved-configure` に書かれているように置き換えてください。 -Then enable and start the service with the following commands: +次に以下のコマンドでサービスの自動起動を有効にし起動します: sudo systemctl daemon-reload sudo systemctl enable --now incus-dns- -If the respective bridge already exists (because Incus is already running), you can use the following command to check that the new service has started: +（Incus が既に実行中のため）対応するブリッジが既に存在する場合、以下のコマンドでサービスが起動したかを確認できます: sudo systemctl status incus-dns-.service -You should see output similar to the following: +以下のような出力になるはずです: ```{terminal} :input: sudo systemctl status incus-dns-incusbr0.service @@ -110,7 +110,7 @@ You should see output similar to the following: Main PID: 9434 (code=exited, status=0/SUCCESS) ``` -To check that `resolved` has applied the settings, use `resolvectl status `: +`resolved` に設定が反映されたか確認するには、 `resolvectl status ` を実行します: ```{terminal} :input: resolvectl status incusbr0 diff --git a/doc/howto/network_configure.md b/doc/howto/network_configure.md index 1c29c06a57b..b004f59c9ed 100644 --- a/doc/howto/network_configure.md +++ b/doc/howto/network_configure.md @@ -1,23 +1,23 @@ (network-configure)= -# How to configure a network +# ネットワークを設定する -To configure an existing network, use either the [`incus network set`](incus_network_set.md) and [`incus network unset`](incus_network_unset.md) commands (to configure single settings) or the `incus network edit` command (to edit the full configuration). -To configure settings for specific cluster members, add the `--target` flag. +既存のネットワークを設定するには、 `incus network set` と `incus network unset` コマンド（単一の設定項目を設定する場合）または `incus network edit` コマンド（設定全体を編集する場合）のどちらかを使います。 +特定のクラスタメンバーの設定を変更するには、 `--target` フラグを追加してください。 -For example, the following command configures a DNS server for a physical network: +たとえば、以下のコマンドは物理ネットワークの DNS サーバーを設定します: ```bash incus network set UPLINK dns.nameservers=8.8.8.8 ``` -The available configuration options differ depending on the network type. -See {ref}`network-types` for links to the configuration options for each network type. +利用可能な設定オプションはネットワークタイプによって異なります。 +各ネットワークタイプの設定オプションへのリンクは {ref}`network-types` を参照してください。 -There are separate commands to configure advanced networking features. -See the following documentation: +高度なネットワーク機能を設定するためには別のコマンドがあります。 +以下のドキュメントを参照してください: - {doc}`/howto/network_acls` - {doc}`/howto/network_forwards` - {doc}`/howto/network_load_balancers` - {doc}`/howto/network_zones` -- {doc}`/howto/network_ovn_peers` (OVN only) +- {doc}`/howto/network_ovn_peers`（OVN のみ） diff --git a/doc/howto/network_create.md b/doc/howto/network_create.md index a39e3a19e4d..33d2faa3bce 100644 --- a/doc/howto/network_create.md +++ b/doc/howto/network_create.md @@ -1,19 +1,19 @@ -# How to create and configure a network +# ネットワークを作成するには -To create a managed network, use the [`incus network`](incus_network.md) command and its subcommands. -Append `--help` to any command to see more information about its usage and available flags. +マネージドネットワークを作成し設定するには、[`incus network`](incus_network.md) コマンドとそのサブコマンドを使用します。 +どのコマンドでも `--help` を追加すると使用方法と利用可能なフラグについてより詳細な情報を表示できます。 (network-types)= -## Network types +## ネットワークタイプ -The following network types are available: +以下のネットワークタイプが利用できます: ```{list-table} :header-rows: 1 -* - Network type - - Documentation - - Configuration options +* - ネットワークタイプ + - ドキュメント + - 設定オプション * - `bridge` - {ref}`network-bridge` - {ref}`network-bridge-options` @@ -32,29 +32,29 @@ The following network types are available: ``` -## Create a network +## ネットワークを作成する -Use the following command to create a network: +ネットワークを作成するには以下のコマンドを実行します: ```bash incus network create --type= [configuration_options...] ``` -See {ref}`network-types` for a list of available network types and links to their configuration options. +利用可能なネットワークタイプ一覧と設定オプションへのリンクは {ref}`network-types` を参照してください。 -If you do not specify a `--type` argument, the default type of `bridge` is used. +`--type` 引数を指定しない場合、デフォルトのタイプ `bridge` が使用されます。 (network-create-cluster)= -### Create a network in a cluster +### クラスタ内にネットワークを作成する -If you are running a Incus cluster and want to create a network, you must create the network for each cluster member separately. -The reason for this is that the network configuration, for example, the name of the parent network interface, might be different between cluster members. +Incus クラスタを実行していてネットワークを作成したい場合、各クラスタメンバーに別々にネットワークを作成する必要があります。 +この理由はネットワーク設定は、たとえば親ネットワークインターフェースの名前のように、クラスタメンバー間で異なるかもしれないからです。 -Therefore, you must first create a pending network on each member with the `--target=` flag and the appropriate configuration for the member. -Make sure to use the same network name for all members. -Then create the network without specifying the `--target` flag to actually set it up. +このため、まず `--target=` フラグとメンバー用の適切な設定を指定して保留中のネットワークを作成する必要があります。 +すべてのメンバーで同じネットワーク名を使うようにしてください。 +次に実際にセットアップするために `--target` フラグなしでネットワークを作成してください。 -For example, the following series of commands sets up a physical network with the name `UPLINK` on three cluster members: +たとえば、以下の一連のコマンドで 3 つのクラスタメンバー上に `UPLINK` という名前の物理ネットワークをセットアップします: ```{terminal} :input: incus network create UPLINK --type=physical parent=br0 --target=vm01 @@ -68,54 +68,31 @@ Network UPLINK pending on member vm03 Network UPLINK created ``` -Also see {ref}`cluster-config-networks`. +{ref}`cluster-config-networks`も参照してください。 (network-attach)= -## Attach a network to an instance +## インスタンスにネットワークをアタッチする -After creating a managed network, you can attach it to an instance as a {ref}`NIC device `. +マネージドネットワークを作成後、それをインスタンスに{ref}`NIC デバイス `としてアタッチできます。 -To do so, use the following command: +そのためには、以下のコマンドを使います: incus network attach [] [] -The device name and the interface name are optional, but we recommend specifying at least the device name. -If not specified, Incus uses the network name as the device name, which might be confusing and cause problems. -For example, Incus images perform IP auto-configuration on the `eth0` interface, which does not work if the interface is called differently. +デバイス名とインターフェース名は省略可能ですが、少なくともデバイス名は指定することをお勧めします。 +指定しない場合、Incus はネットワーク名をデバイス名として使用しますが、紛らわしく問題を起こすかもしれません。 +たとえば、Incus イメージは`eth0`インターフェースに IP 自動設定を行いますが、インターフェースの名前が違うと機能しません。 -For example, to attach the network `my-network` to the instance `my-instance` as `eth0` device, enter the following command: +たとえば、`my-network`というネットワークを`my-instance`というインタンスに`eth0`デバイスとしてアタッチするには、以下のコマンドを入力します: incus network attach my-network my-instance eth0 -### Attach the network as a device +### NICデバイスを追加する -The [`incus network attach`](incus_network_attach.md) command is a shortcut for adding a NIC device to an instance. -Alternatively, you can add a NIC device based on the network configuration in the usual way: +[`incus network attach`](incus_network_attach.md) コマンドはインスタンスに NIC デバイスを追加するショートカットです。 +別の方法として、通常通りネットワーク設定で NIC デバイスを追加できます: incus config device add nic network= -When using this way, you can add further configuration to the command to override the default settings for the network if needed. -See {ref}`NIC device ` for all available device options. - -## Configure a network - -To configure an existing network, use either the `incus network set` and `incus network unset` commands (to configure single settings) or the `incus network edit` command (to edit the full configuration). -To configure settings for specific cluster members, add the `--target` flag. - -For example, the following command configures a DNS server for a physical network: - -```bash -incus network set UPLINK dns.nameservers=8.8.8.8 -``` - -The available configuration options differ depending on the network type. -See {ref}`network-types` for links to the configuration options for each network type. - -There are separate commands to configure advanced networking features. -See the following documentation: - -- {doc}`/howto/network_acls` -- {doc}`/howto/network_forwards` -- {doc}`/howto/network_load_balancers` -- {doc}`/howto/network_zones` -- {doc}`/howto/network_ovn_peers` (OVN only) +この方法を使う場合、必要に応じてネットワークのデフォルト設定をオーバーライドするように追加の設定をコマンドに追加できます。 +すべての利用可能なデバイスオプションについては{ref}`NIC デバイス `を参照してください。 diff --git a/doc/howto/network_forwards.md b/doc/howto/network_forwards.md index 9fb9cbaa616..cab442a1dc7 100644 --- a/doc/howto/network_forwards.md +++ b/doc/howto/network_forwards.md @@ -1,104 +1,102 @@ (network-forwards)= -# How to configure network forwards +# ネットワークフォワードを設定するには ```{note} -Network forwards are available for the {ref}`network-ovn` and the {ref}`network-bridge`. +ネットワークフォワードは {ref}`network-ovn` と {ref}`network-bridge` で利用できます。 ``` -Network forwards allow an external IP address (or specific ports on it) to be forwarded to an internal IP address (or specific ports on it) in the network that the forward belongs to. +ネットワークフォワードは外部 IP アドレス（あるいは外部 IP アドレスの特定のポート）をフォワード設定が属するネットワーク内の内部 IP アドレス（あるいは内部 IP アドレスの特定のポート）にフォワードする機能です。 -This feature can be useful if you have limited external IP addresses and want to share a single external address between multiple instances. -There are two different ways how you can use network forwards in this case: +この機能は外部 IP アドレスが限定されていて 1 つの外部アドレスを複数のインスタンスで共有したい場合に有用です。 +この場合にネットワークフォワードを 2 つの異なる方法で利用できます。 -- Forward all traffic from the external address to the internal address of one instance. - This method makes it easy to move the traffic destined for the external address to another instance by simply reconfiguring the network forward. -- Forward traffic from different port numbers of the external address to different instances (and optionally different ports on those instances). - This method allows to "share" your external IP address and expose more than one instance at a time. +- 外部アドレスからのすべてのトラフィックを 1 つのインスタンスの内部アドレスにフォワードします。この方法はネットワークフォワードを単に再設定することで外部アドレスに向けられたトラフィックを別のインスタンスに簡単に移動できます。 +- 外部アドレスの異なるポートからのトラフィックを異なるインスタンスにフォワードします（さらにこれらのインスタンスの異なるポートにフォワードもできます）。この方法は外部 IP アドレスを「共有」し、複数のインスタンスを一度に公開できます。 -## Create a network forward +## ネットワークフォワードを作成する -Use the following command to create a network forward: +ネットワークフォワードを作成するには以下のコマンドを使用します: ```bash incus network forward create [configuration_options...] ``` -Each forward is assigned to a network. -It requires a single external listen address (see {ref}`network-forwards-listen-addresses` for more information about which addresses can be forwarded, depending on the network that you are using). +それぞれのフォワードはネットワークに割り当てられます。 +フォワードには単一の外部リッスンアドレスが必要です（使用しているネットワークに応じてどのアドレスがフォワードできるかについて詳細は {ref}`network-forwards-listen-addresses` を参照してください）。 -You can specify an optional default target address by adding the `target_address=` configuration option. -If you do, any traffic that does not match a port specification is forwarded to this address. -Note that this target address must be within the same subnet as the network that the forward is associated to. +さらに `target_address=` 設定オプションを追加することでデフォルトのターゲットアドレスを追加することもできます。 +こうするとポート指定にマッチしないトラフィックはすべてこのアドレスにフォワードします。 +このターゲットアドレスはフォワードが関連付けられるネットワークと同じサブネット内でなければならないことに注意してください。 -### Forward properties +### フォワードのプロパティ -Network forwards have the following properties: +ネットワークフォワードのプロパティには以下のものがあります: -Property | Type | Required | Description -:-- | :-- | :-- | :-- -`listen_address` | string | yes | IP address to listen on -`description` | string | no | Description of the network forward -`config` | string set | no | Configuration options as key/value pairs (only `target_address` and `user.*` custom keys supported) -`ports` | port list | no | List of {ref}`port specifications ` +プロパティ | 型 | 必須 | 説明 +:-- | :-- | :-- | :-- +`listen_address` | string | yes | リッスンする IP アドレス +`description` | string | no | ネットワークフォワードの説明 +`config` | string set | no | キー/バリューペア形式の設定オプション（`target_address` と `user.*` カスタムキーのみサポート） +`ports` | port list | no | {ref}`ポート指定 ` のリスト (network-forwards-listen-addresses)= -### Requirements for listen addresses +### リッスンアドレスの要件 -The requirements for valid listen addresses vary depending on which network type the forward is associated to. +有効なリッスンアドレスの要件はフォワードがどのネットワークタイプに割り当てられるかに応じて異なります。 -Bridge network -: - Any non-conflicting listen address is allowed. - - The listen address must not overlap with a subnet that is in use with another network. +ブリッジネットワーク +: - 任意の衝突しないリッスンアドレスが使用できます。 + - リッスンアドレスは他のネットワークで使用中のサブネットとオーバーラップはできません。 -OVN network -: - Allowed listen addresses must be defined in the uplink network's `ipv{n}.routes` settings or the project's {config:option}`project-restricted:restricted.networks.subnets` setting (if set). - - The listen address must not overlap with a subnet that is in use with another network. +OVN ネットワーク +: - 利用可能なリッスンアドレスはアップリンクネットワークの `ipv{n}.routes` 設定か（設定されている場合は）プロジェクトの `restricted.networks.subnets` 設定で定義されていなければなりません。 + - リッスンアドレスは他のネットワークで使用中のサブネットとオーバーラップはできません。 (network-forwards-port-specifications)= -## Configure ports +## ポートを設定する -You can add port specifications to the network forward to forward traffic from specific ports on the listen address to specific ports on the target address. -This target address must be different from the default target address. -It must be within the same subnet as the network that the forward is associated to. +リッスンアドレスの特定のポートからターゲットアドレスの特定のポートにトラフィックをフォワードするためにネットワークフォワードにポート指定を追加できます。 +このターゲットアドレスはデフォルトターゲットアドレスとは異なるものである必要があります。 +またフォワードを割り当てるネットワークと同じサブネットである必要があります。 -Use the following command to add a port specification: +ポート指定を追加するには以下のコマンドを使用します: ```bash incus network forward port add [] ``` -You can specify a single listen port or a set of ports. -If you want to forward the traffic to different ports, you have two options: +単一のポートか一組のポートを指定できます。 +異なるポートにトラフィックをフォワードしたい場合、 2 つの選択肢があります。 -- Specify a single target port to forward traffic from all listen ports to this target port. -- Specify a set of target ports with the same number of ports as the listen ports to forward traffic from the first listen port to the first target port, the second listen port to the second target port, and so on. +- 単一のターゲットポートを指定し、すべてのリッスンポートからのトラフィックをこのターゲットポートにフォワードします。 +- リッスンポートと同じ数の一組のターゲットポートを指定し、最初のリッスンポートを最初のターゲットポートに、 2 番目のリッスンポートを 2 番目のターゲットポートに、以下同様というようにフォワードします。 -### Port properties +### ポートのプロパティ -Network forward ports have the following properties: +ネットワークフォワードポートのプロパティには以下のものがあります: -Property | Type | Required | Description -:-- | :-- | :-- | :-- -`protocol` | string | yes | Protocol for the port(s) (`tcp` or `udp`) -`listen_port` | string | yes | Listen port(s) (e.g. `80,90-100`) -`target_address` | string | yes | IP address to forward to -`target_port` | string | no | Target port(s) (e.g. `70,80-90` or `90`), same as `listen_port` if empty -`description` | string | no | Description of port(s) +プロパティ | 型 | 必須 | 説明 +:-- | :-- | :-- | :-- +`protocol` | string | yes | ポートのプロトコル（`tcp` または `udp`） +`listen_port` | string | yes | リッスンするポート（例 `80,90-100`） +`target_address` | string | yes | フォワード先の IP アドレス +`target_port` | string | no | ターゲットのポート（例 `70,80-90` または `90`）、 空の場合は `listen_port` と同じ +`description` | string | no | ポートの説明 -## Edit a network forward +## ネットワークフォワードを編集する -Use the following command to edit a network forward: +ネットワークフォワードを編集するには以下のコマンドを使用します: ```bash incus network forward edit ``` -This command opens the network forward in YAML format for editing. -You can edit both the general configuration and the port specifications. +このコマンドはネットワークフォワードを編集用に YAML 形式でオープンします。 +全般の設定とポート指定の両方を編集できます。 -## Delete a network forward +## ネットワークフォワードを削除する -Use the following command to delete a network forward: +ネットワークフォワードを削除するには以下のコマンドを使用します: ```bash incus network forward delete diff --git a/doc/howto/network_increase_bandwidth.md b/doc/howto/network_increase_bandwidth.md index 8e5681a84c3..2348b89b6ea 100644 --- a/doc/howto/network_increase_bandwidth.md +++ b/doc/howto/network_increase_bandwidth.md @@ -1,48 +1,48 @@ (network-increase-bandwidth)= -# How to increase the network bandwidth +# ネットワーク帯域幅を拡大するには -You can increase the network bandwidth of your Incus setup by configuring the transmit queue length (`txqueuelen`). -This change makes sense in the following scenarios: +あなたの Incus 環境のネットワーク帯域幅を送信キューの長さ（`txqueuelen`）を調整することで拡大できます。 +以下のようなシナリオでは適しているでしょう。 -- You have a NIC with 1 GbE or higher on a Incus host with a lot of local activity (instance-instance connections or host-instance connections). -- You have an internet connection with 1 GbE or higher on your Incus host. +- 大量のローカルアクティビティ（インスタンス間接続あるいはホストあるいはインスタンス間の接続）がある Incus ホスト上に 1 GbE あるいはそれ以上の NIC 1 GbE あるいはそれ以上の NIC がある場合。 +- Incus ホストで 1 GbE あるいはそれ以上のインターネット接続がある場合。 -The more instances you use, the more you can benefit from this tweak. +使用するインスタンス数が多いほど、この設定変更の利益があります。 ```{note} -The following instructions use a `txqueuelen` value of 10000, which is commonly used with 10GbE NICs, and a `net.core.netdev_max_backlog` value of 182757. -Depending on your network, you might need to use different values. +以下の手順では `txqueuelen` の値として 10000（10GbE NIC でよく使用されます）を、`net.core.netdev_max_backlog` の値として 182757 を使用しています。 +ネットワークによっては、異なる値を使用する必要があるかもしれません。 -In general, you should use small `txqueuelen` values with slow devices with a high latency, and high `txqueuelen` values with devices with a low latency. -For the `net.core.netdev_max_backlog` value, a good guideline is to use the minimum value of the `net.ipv4.tcp_mem` configuration. +一般的に、低速なデバイスでレイテンシが高い場合は小さい `txqueuelen` の値を、レイテンシが低いデバイスでは大きな `txqueuelen` の値を使用するのが良いです。 +`net.core.netdev_max_backlog` の値について、良い指標は `net.ipv4.tcp_mem` 設定の最小値を使用することです。 ``` -## Increase the network bandwidth on the Incus host +## Incus ホスト上のネットワーク帯域幅を拡大する -Complete the following steps to increase the network bandwidth on the Incus host: +Incus ホスト上のネットワーク帯域幅を拡大するには以下の手順を実行してください: -1. Increase the transmit queue length (`txqueuelen`) of both the real NIC and the Incus NIC (for example, `incusbr0`). - You can do this temporarily for testing with the following command: +1. 実 NIC と Incus NIC（たとえば、`incusbr0`）の両方で送信キューの長さ（`txqueuelen`）を拡大します。 + テストのために一時的にこれを行うには以下のコマンドが使用できます: ifconfig txqueuelen 10000 - To make the change permanent, add the following command to your interface configuration in `/etc/network/interfaces`: + 変更を永続的にするには `/etc/network/interfaces` 内のインターフェース設定に以下のコマンドを追加します: up ip link set eth0 txqueuelen 10000 -1. Increase the receive queue length (`net.core.netdev_max_backlog`). - You can do this temporarily for testing with the following command: +1. 受信キューの長さ（`net.core.netdev_max_backlog`）を拡大します。 + テストのために一時的にこれを行うには以下のコマンドが使用できます: echo 182757 > /proc/sys/net/core/netdev_max_backlog - To make the change permanent, add the following configuration to `/etc/sysctl.conf`: + 変更を永続的にするには `/etc/sysctl.conf` に以下の設定を追加します: net.core.netdev_max_backlog = 182757 -## Increase the transmit queue length on the instances +## インスタンス上の送信キューの長さを拡大する -You must also change the `txqueuelen` value for all Ethernet interfaces in your instances. -To do this, use one of the following methods: +インスタンス上のすべての Ethernet インターフェースの `txqueulen` の値も変更する必要があります。 +このためには、以下の方法のいずれかを使います: -- Apply the same changes as described above for the Incus host. -- Set the `queue.tx.length` device option on the instance profile or configuration. +- 上述の Incus ホストへの変更と同じ変更を適用する。 +- インスタンスのプロファイルあるいは設定で `queue.tx.length` デバイスオプションを設定する。 diff --git a/doc/howto/network_ipam.md b/doc/howto/network_ipam.md index a6597c0c540..ee926fdcac9 100644 --- a/doc/howto/network_ipam.md +++ b/doc/howto/network_ipam.md @@ -1,36 +1,37 @@ (network-ipam)= -# How to display IPAM information of a Incus deployment +# Incus 環境の IPAM 情報を表示するには -{abbr}`IPAM (IP Address Management)` is a method used to plan, track, and manage the information associated with a computer network's IP address space. In essence, it's a way of organizing, monitoring, and manipulating the IP space in a network. +{abbr}`IPAM (IP Address Management)` はコンピューターネットワークの IP アドレス空間に関連付ける情報を計画、追跡、管理するために使用される方法です。本質的には、ネットワーク内の IP 空間を管理、監視、操作する方法です。 -Checking the IPAM information for your Incus setup can help you debug networking issues. You can see which IP addresses are used for instances, network interfaces, forwards, and load balancers and use this information to track down where traffic is lost. +あなたの Incus 環境の IPAM 情報をチェックすることはネットワークの問題をデバッグするのに役立つかもしれません。インスタンス、ネットワークインターフェース、フォワード、ロードバランサーでどんな IP アドレスが使用されているかを確認し、この情報をどこでトラフィックが失われているかを突き止めるのに使用できます。 -To display IPAM information, enter the following command: +IPAM 情報を表示するには、以下のコマンドを入力します: ```bash incus network list-allocations ``` -By default, this command shows the IPAM information for the `default` project. You can select a different project with the `--project` flag, or specify `--all-projects` to display the information for all projects. +デフォルトでは、このコマンドは `default` プロジェクトの IPAM 情報を表示します。 +`--project` フラグを指定して他のプロジェクトを選択したり、 `--all-projects` を指定してすべてのプロジェクトの情報を表示できます。 -The resulting output will look something like this: +出力は以下のようになります: ``` -+----------------------+-----------------+----------+------+-------------------+ -| USED BY | ADDRESS | TYPE | NAT | HARDWARE ADDRESS | -+----------------------+-----------------+----------+------+-------------------+ ++------------------------+-----------------+----------+------+-------------------+ +| USED BY | ADDRESS | TYPE | NAT | HARDWARE ADDRESS | ++------------------------+-----------------+----------+------+-------------------+ | /1.0/networks/incusbr0 | 192.0.2.0/24 | network | true | | -+----------------------+-----------------+----------+------+-------------------+ ++------------------------+-----------------+----------+------+-------------------+ | /1.0/networks/incusbr0 | 2001:db8::/32 | network | true | | -+----------------------+-----------------+----------+------+-------------------+ -| /1.0/instances/u1 | 2001:db8::1/128 | instance | true | 00:16:3e:04:f0:95 | -+----------------------+-----------------+----------+------+-------------------+ -| /1.0/instances/u1 | 192.0.2.2/32 | instance | true | 00:16:3e:04:f0:95 | -+----------------------+-----------------+----------+------+-------------------+ ++------------------------+-----------------+----------+------+-------------------+ +| /1.0/instances/u1 | 2001:db8::1/128 | instance | true | 00:16:3e:04:f0:95 | ++------------------------+-----------------+----------+------+-------------------+ +| /1.0/instances/u1 | 192.0.2.2/32 | instance | true | 00:16:3e:04:f0:95 | ++------------------------+-----------------+----------+------+-------------------+ ... ``` -Each listed entry lists the IP address (in CIDR notation) of one of the following Incus entities: `network`, `network-forward`, `network-load-balancer`, and `instance`. -An entry contains an IP address using the CIDR notation. -It also contains a Incus resource URI, the type of the entity, whether it is in NAT mode, and the hardware address (only for the `instance` entity). +一覧の各エントリは次の Incus のエンティティの（CIDR 表記の） IP アドレスを表示します: `network`、`network-forward`、`network-load-balancer`、`instance`。 +エントリは CIDR 表記の IP アドレスを含みます。 +またエントリは Incus リソース URI、エンティティのタイプ、NAT モードかどうか、ハードウェアアドレス（`instance`エンティティのみ）も含みます。 diff --git a/doc/howto/network_load_balancers.md b/doc/howto/network_load_balancers.md index 7abd076c522..cbdc27759a0 100644 --- a/doc/howto/network_load_balancers.md +++ b/doc/howto/network_load_balancers.md @@ -1,121 +1,121 @@ (network-load-balancers)= -# How to configure network load balancers +# ネットワークロードバランサーを設定するには ```{note} -Network load balancers are currently available for the {ref}`network-ovn`. +ネットワークロードバランサーは現状では {ref}`network-ovn` でのみ利用できます。 ``` -Network load balancers are similar to forwards in that they allow specific ports on an external IP address to be forwarded to specific ports on internal IP addresses in the network that the load balancer belongs to. The difference between load balancers and forwards is that load balancers can be used to share ingress traffic between multiple internal backend addresses. +ネットワークロードバランサーは、外部 IP アドレス上の特定のポートを、ロードバランサーが属するネットワークの内部 IP アドレス上の特定のポートにフォワードできるという点で、ネットワークフォワードに似ています。ネットワークロードバランサーとネットワークフォワードの違いは、ロードバランサーは内向きのトラフィックを複数の内部のバックエンドアドレスで共有するのに使えることです。 -This feature can be useful if you have limited external IP addresses or want to share a single external address and ports over multiple instances. +この機能は外部 IP アドレスの数に限りがあったり、複数のインスタンスで単一の外部アドレスとそのアドレス上のポートを共有したい場合に有用です。 -A load balancer is made up of: +ロードバランサーは以下の要素で構成されます: -- A single external listen IP address. -- One or more named backends consisting of an internal IP and optional port ranges. -- One or more listen port ranges that are configured to forward to one or more named backends. +- 単一の外部リッスン IP アドレス。 +- 内部 IP アドレスとオプショナルなポートレンジからなる単一あるいは複数の名前付きバックエンド。 +- 単一または複数の名前付きバックエンドにフォワードされるように設定された単一または複数のリッスンポートレンジ。 -## Create a network load balancer +## ネットワークロードバランサーを作成する -Use the following command to create a network load balancer: +ネットワークロードバランサーを作成するには以下のコマンドを使用します: ```bash incus network load-balancer create [configuration_options...] ``` -Each load balancer is assigned to a network. -It requires a single external listen address (see {ref}`network-load-balancers-listen-addresses` for more information about which addresses can be load-balanced). +それぞれのロードバランサーはネットワークに割り当てられます。 +ロードバランサーには単一の外部リッスンアドレスが必要です（どのアドレスがロードバランス可能かについてのさらなる情報は {ref}`network-load-balancers-listen-addresses` 参照）。 -### Load balancer properties +### ロードバランサーのプロパティ -Network load balancers have the following properties: +ネットワークロードバランサーは以下のプロパティを持ちます。 -Property | Type | Required | Description -:-- | :-- | :-- | :-- -`listen_address` | string | yes | IP address to listen on -`description` | string | no | Description of the network load balancer -`config` | string set | no | Configuration options as key/value pairs (only `user.*` custom keys supported) -`backends` | backend list | no | List of {ref}`backend specifications ` -`ports` | port list | no | List of {ref}`port specifications ` +プロパティ | 型 | 必須 | 説明 +:-- | :-- | :-- | :-- +`listen_address` | string | yes | リッスンする IP アドレス +`description` | string | no | ネットワークロードバランサーの説明 +`config` | string set | no | キー/バリュー形式の設定オプション（`user.*` カスタムキーのみがサポートされます） +`backends` | backend list | no | {ref}`バックエンド仕様 ` のリスト +`ports` | port list | no | {ref}`ポート仕様 ` のリスト (network-load-balancers-listen-addresses)= -### Requirements for listen addresses +### リッスンアドレスの要件 -The following requirements must be met for valid listen addresses: +有効なリッスンアドレスは以下の要件を満たす必要があります: -- Allowed listen addresses must be defined in the uplink network's `ipv{n}.routes` settings or the project's {config:option}`project-restricted:restricted.networks.subnets` setting (if set). -- The listen address must not overlap with a subnet that is in use with another network or entity in that network. +- 許可されるリッスンアドレスはアップリンクのネットワークの `ipv{n}.routes` 設定またはプロジェクトの {config:option}`project-restricted:restricted.networks.subnets` 設定（設定されている場合）に定義されている必要があります。 +- リッスンアドレスは他のネットワークやネットワーク内のエンティティで使用されているサブネットと重なってはいけません。 (network-load-balancers-backend-specifications)= -## Configure backends +## バックエンドを設定する -You can add backend specifications to the network load balancer to define target addresses (and optionally ports). -The backend target address must be within the same subnet as the network that the load balancer is associated to. +ターゲットのアドレス（と省略可能なポート）をネットワークロードバランサーに定義するためにバックエンド仕様を追加できます。 +バックエンドのターゲットアドレスはロードバランサーが関連付けられているネットワークと同じサブネット内である必要があります。 -Use the following command to add a backend specification: +バックエンド仕様を追加するには以下のコマンドを使用します: ```bash incus network load-balancer backend add [] ``` -The target ports are optional. -If not specified, the load balancer will use the listen ports for the backend for the backend target ports. +ターゲットポートは省略可能です。 +省略した場合、ロードバランサーはバックエンドのリッスンポートをバックエンドのターゲットポートとして使用します。 -If you want to forward the traffic to different ports, you have two options: +トラフィックを別のポートにフォワードしたい場合、2 つの選択肢があります。 -- Specify a single target port to forward traffic from all listen ports to this target port. -- Specify a set of target ports with the same number of ports as the listen ports to forward traffic from the first listen port to the first target port, the second listen port to the second target port, and so on. +- 単一のターゲットポートを指定し、すべてのリッスンポートへのトラフィックをこのターゲットポートにフォワードする。 +- 一組のターゲットポートをリッスンポートと同じ数のポートで指定し、リッスンポートの最初のポートをターゲットポートの最初のポート、リッスンポートの 2 番目のポートをターゲットポートの 2 番目のポート、というようにトラフィックをフォワードする。 -### Backend properties +### バックエンドのプロパティ -Network load balancer backends have the following properties: +ネットワークロードバランサーのバックエンドは以下のプロパティを持ちます。 -Property | Type | Required | Description -:-- | :-- | :-- | :-- -`name` | string | yes | Name of the backend -`target_address` | string | yes | IP address to forward to -`target_port` | string | no | Target port(s) (e.g. `70,80-90` or `90`), same as the {ref}`port `'s `listen_port` if empty -`description` | string | no | Description of backend +プロパティ | 型 | 必須 | 説明 +:-- | :-- | :-- | :-- +`name` | string | yes | バックエンドの名前 +`target_address` | string | yes | フォワード先の IP アドレス +`target_port` | string | no | ターゲットポート（例 `70,80-90` や `90`）、空の場合 {ref}`ポート ` の `listen_port` と同じ +`description` | string | no | バックエンドの説明 (network-load-balancers-port-specifications)= -## Configure ports +## ポートを設定する -You can add port specifications to the network load balancer to forward traffic from specific ports on the listen address to specific ports on one or more target backends. +ネットワークロードバランサーにポート指定を追加し、リッスンアドレスの特定のポートから、単一または複数のバックエンド上の特定のポートにトラフィックを転送できます。 -Use the following command to add a port specification: +ポート仕様を追加するには以下のコマンドを使用します: ```bash incus network load-balancer port add [,...] ``` -You can specify a single listen port or a set of ports. -The backend(s) specified must have target port(s) settings compatible with the port's listen port(s) setting. +単一のリッスンポートまたは一組のポートを指定できます。 +指定されたバックエンドはポートのリッスンポート設定と互換性があるターゲットポート設定を持たなければなりません。 -### Port properties +### ポートのプロパティ -Network load balancer ports have the following properties: +ネットワークロードバランサーのポートは以下のプロパティを持ちます。 -Property | Type | Required | Description -:-- | :-- | :-- | :-- -`protocol` | string | yes | Protocol for the port(s) (`tcp` or `udp`) -`listen_port` | string | yes | Listen port(s) (e.g. `80,90-100`) -`target_backend` | backend list | yes | Backend name(s) to forward to -`description` | string | no | Description of port(s) +プロパティ | 型 | 必須 | 説明 +:-- | :-- | :-- | :-- +`protocol` | string | yes | ポートのプロトコル（`tcp` または `udp`） +`listen_port` | string | yes | リッスンポート（例 `80,90-100`） +`target_backend` | backend list | yes | フォワード先のバックエンドの名前 +`description` | string | no | ポートの説明 -## Edit a network load balancer +## ネットワークロードバランサーを編集する -Use the following command to edit a network load balancer: +ネットワークロードバランサーを編集するには以下のコマンドを使用します: ```bash incus network load-balancer edit ``` -This command opens the network load balancer in YAML format for editing. -You can edit both the general configuration, backend and the port specifications. +このコマンドは YAML 形式のネットワークロードバランサーの設定を編集用に開きます。 +一般の設定、バックエンド、ポート仕様を編集できます。 -## Delete a network load balancer +## ネットワークロードバランサーを削除する -Use the following command to delete a network load balancer: +ネットワークロードバランサーを削除するには以下のコマンドを使用します: ```bash incus network load-balancer delete diff --git a/doc/howto/network_ovn_peers.md b/doc/howto/network_ovn_peers.md index b76fec3a928..f53c1e7859c 100644 --- a/doc/howto/network_ovn_peers.md +++ b/doc/howto/network_ovn_peers.md @@ -1,60 +1,60 @@ (network-ovn-peers)= -# How to create peer routing relationships +# ピアルーティング関係を作成するには -By default, traffic between two OVN networks goes through the uplink network. -This path is inefficient, however, because packets must leave the OVN subsystem and transit through the host's networking stack (and, potentially, an external network) and back into the OVN subsystem of the target network. -Depending on how the host's networking is configured, this might limit the available bandwidth (if the OVN overlay network is on a higher bandwidth network than the host's external network). +デフォルトでは、 2 つの OVN ネットワーク間のトラフィックはアップリンクのネットワークを経由します。 +しかし、パケットが OVN サブシステムから出てホストのネットワークスタック（そして、場合によっては外部ネットワーク）を通過し対象ネットサークの OVN サブシステムに戻る必要があるため、この経路は非効率です。 +ホストのネットワークの構成によっては、利用できる帯域幅が制限される場合があります（ホストの外部ネットワークより OVN のオーバーレイネットワークが広帯域幅のネットワークにある場合）。 -Therefore, Incus allows creating peer routing relationships between two OVN networks. -Using this method, traffic between the two networks can go directly from one OVN network to the other and thus stays within the OVN subsystem, rather than transiting through the uplink network. +このため、 Incus では 2 つの OVN ネットワーク間でルーティング関係を作成できます。 +この方法を使うと 2 つのネットワーク間での通信がアップリンクのネットワーク経由ではなく OVN サブシステム内で完結できます。 -## Create a routing relationship between networks +## ネットワーク間にルーティング関係を作成する -To add a peer routing relationship between two networks, you must create a network peering for both networks. -The relationship must be mutual. -If you set it up on only one network, the routing relationship will be in pending state, but not active. +2 つのネットワーク間にルーティング関係を作成するには、両方のネットワークにネットワークピアを作成する必要があります。 +関係は双方向でなくてはなりません。 +1 のネットワークだけセットアップした場合、ルーティング関係はペンディング状態になり、アクディブにはなりません。 -When creating the peer routing relationship, specify a peering name that identifies the relationship for the respective network. -The name can be chosen freely, and you can use it later to edit or delete the relationship. +ピアのルーティング関係を作成する際は、対象のネットワークとの関係を特定するピアの名前を指定します。 +名前は自由に選ぶことができ、後で関係を編集または削除する際に使用します。 -Use the following commands to create a peer routing relationship between networks in the same project: +同じプロジェクト内のネットワーク間でピアのルーティング関係を作成するには次のコマンドを使います: incus network peer create [configuration_options] incus network peer create [configuration_options] -You can also create peer routing relationships between OVN networks in different projects: +別のプロジェクトの OVN ネットワーク間でピアのルーティング関係を作成することもできます: incus network peer create [configuration_options] --project= incus network peer create [configuration_options] --project= ```{important} -If the project or the network name is incorrect, the command will not return any error indicating that the respective project/network does not exist, and the routing relationship will remain in pending state. -This behavior prevents users in a different project from discovering whether a project and network exists. +プロジェクトまたはネットワークの名前が間違っている場合、コマンドは対応するプロジェクトやネットワークが存在しないというエラーは出さず、ルーティング関係はペンディング状態のままになります。 +これは他のプロジェクトのユーザがプロジェクトやネットワークが存在するか調べられないようにするための（訳注: セキュリティ上の）仕様です。 ``` -### Peering properties +### アのプロパティ -Peer routing relationships have the following properties: +ピアのルーティング関係には以下のプロパティがあります。 -Property | Type | Required | Description +プロパティ | 型 | 必須 | 説明 :-- | :-- | :-- | :-- -`name` | string | yes | Name of the network peering on the local network -`description` | string | no | Description of the network peering -`config` | string set | no | Configuration options as key/value pairs (only `user.*` custom keys supported) -`target_project` | string | yes | Which project the target network exists in (required at create time) -`target_network` | string | yes | Which network to create a peering with (required at create time) -`status` | string | -- | Status indicating if pending or created (mutual peering exists with the target network) +`name` | string | yes | ローカルネットワーク上のネットワークピアの名前 +`description` | string | no | ネットワークピアの説明 +`config` | string set | no | 設定のキーバリューペアー（`user.*` のカスタムキーのみサポート） +`target_project` | string | yes | 対象のネットワークがどのプロジェクト内に存在するか（作成時に必須） +`target_network` | string | yes | どのネットワークとピアを作成するか（作成時に必須） +`status` | string | -- | 作成中か作成完了（対象のネットワークと相互にピアリングした状態）かを示すステータス -## List routing relationships +## ルーティング関係の一覧を表示する -To list all network peerings for a network, use the following command: +ネットワークのネットワークピアすべての一覧を表示するには、次のコマンドを実行します: incus network peer list -## Edit a routing relationship +## ルーティング関係を編集する -Use the following command to edit a network peering: +ネットワークピアを編集するには次のコマンドを実行します: incus network peer edit -This command opens the network peering in YAML format for editing. +このコマンドは YAML 形式のネットワークピアを編集モードで開きます。 diff --git a/doc/howto/network_ovn_setup.md b/doc/howto/network_ovn_setup.md index b65d36819f5..47ca92d8987 100644 --- a/doc/howto/network_ovn_setup.md +++ b/doc/howto/network_ovn_setup.md @@ -1,35 +1,35 @@ (network-ovn-setup)= -# How to set up OVN with Incus +# Incus で OVN をセットアップするには -See the following sections for how to set up a basic OVN network, either as a standalone network or to host a small Incus cluster. +スタンドアロンのネットワークとしてまたは小さな Incus クラスタとして基本的な OVN ネットワークをセットアップするには以下の項を参照してください。 -## Set up a standalone OVN network +## スタンドアロンの OVN ネットワークをセットアップする -Complete the following steps to create a standalone OVN network that is connected to a managed Incus parent bridge network (for example, `incusbr0`) for outbound connectivity. +外向きの接続のために Incus が管理する親のブリッジネットワーク（たとえば、 `incusbr0`）に接続するスタンドアロンの OVN ネットワークを作成するには以下の手順を実行してください。 -1. Install the OVN tools on the local server: +1. ローカルサーバーに OVN ツールをインストールします: sudo apt install ovn-host ovn-central -1. Configure the OVN integration bridge: +1. OVN の統合ブリッジを設定します: sudo ovs-vsctl set open_vswitch . \ external_ids:ovn-remote=unix:/var/run/ovn/ovnsb_db.sock \ external_ids:ovn-encap-type=geneve \ external_ids:ovn-encap-ip=127.0.0.1 -1. Create an OVN network: +1. OVN ネットワークを作成します: incus network set ipv4.dhcp.ranges= ipv4.ovn.ranges= incus network create ovntest --type=ovn network= -1. Create an instance that uses the `ovntest` network: +1. `ovntest` ネットワークを使用するインスタンスを作成します: incus init images:ubuntu/22.04 c1 incus config device override c1 eth0 network=ovntest incus start c1 -1. Run [`incus list`](incus_list.md) to show the instance information: +1. [`incus list`](incus_list.md) を実行してインスタンスの情報を表示します: ```{terminal} :input: incus list @@ -42,38 +42,38 @@ Complete the following steps to create a standalone OVN network that is connecte +------+---------+---------------------+----------------------------------------------+-----------+-----------+ ``` -## Set up a Incus cluster on OVN +## OVN 上に Incus クラスタをセットアップする -Complete the following steps to set up a Incus cluster that uses an OVN network. +OVN ネットワークを使用する Incus クラスタをセットアップするには以下の手順を実行してください。 -Just like Incus, the distributed database for OVN must be run on a cluster that consists of an odd number of members. -The following instructions use the minimum of three servers, which run both the distributed database for OVN and the OVN controller. -In addition, you can add any number of servers to the Incus cluster that run only the OVN controller. +Incus と同様に、 OVN の分散データベースは奇数のメンバーで構成されるクラスタ上で動かす必要があります。 +以下の手順は最小構成の 3 台のサーバーを使います。 3 台のサーバーでは OVN の分散データベースと OVN コントローラーの両方を動かします。 +さらに Incus クラスタに OVN コントローラーのみを動かすサーバーを任意の台数追加できます。 -1. Complete the following steps on the three machines that you want to run the distributed database for OVN: +1. OVN の分散データベースを動かしたい 3 台のマシンで次の手順を実行してください: - 1. Install the OVN tools: + 1. OVN ツールをインストールします: sudo apt install ovn-central ovn-host - 1. Mark the OVN services as enabled to ensure that they are started when the machine boots: + 1. マシンの起動時に OVN サービスが起動されるように自動起動を有効にします: systemctl enable ovn-central systemctl enable ovn-host - 1. Stop OVN for now: + 1. OVN を停止します: systemctl stop ovn-central - 1. Note down the IP address of the machine: + 1. マシンの IP アドレスをメモします: ip -4 a - 1. Open `/etc/default/ovn-central` for editing. + 1. `/etc/default/ovn-central` を編集します。 - 1. Paste in one of the following configurations (replace ``, `` and `` with the IP addresses of the respective machines, and `` with the IP address of the machine that you are on). + 1. 以下の設定をペーストします（``, `` and `` をそれぞれのマシンの IP アドレスに、 `` をあなたがいるマシンの IP アドレスに置き換えてください）。 - - For the first machine: + - 最初のマシン: ``` OVN_CTL_OPTS=" \ @@ -87,7 +87,7 @@ In addition, you can add any number of servers to the Incus cluster that run onl --ovn-northd-sb-db=tcp::6642,tcp::6642,tcp::6642" ``` - - For the second and third machine: + - 2 番目と 3 番目のマシン: ``` OVN_CTL_OPTS=" \ @@ -103,26 +103,26 @@ In addition, you can add any number of servers to the Incus cluster that run onl --ovn-northd-sb-db=tcp::6642,tcp::6642,tcp::6642" ``` - 1. Start OVN: + 1. OVN を起動します: systemctl start ovn-central -1. On the remaining machines, install only `ovn-host` and make sure it is enabled: +1. 残りのマシンでは `ovn-host` のみインストールし、自動起動を有効にしてください: sudo apt install ovn-host systemctl enable ovn-host -1. On all machines, configure Open vSwitch (replace the variables as described above): +1. すべてのマシンで Open vSwitch（変数は上記の通りに置き換えてください）を設定します: sudo ovs-vsctl set open_vswitch . \ external_ids:ovn-remote=tcp::6642,tcp::6642,tcp::6642 \ external_ids:ovn-encap-type=geneve \ external_ids:ovn-encap-ip= -1. Create a Incus cluster by running `incus admin init` on all machines. - On the first machine, create the cluster. - Then join the other machines with tokens by running [`incus cluster add `](incus_cluster_add.md) on the first machine and specifying the token when initializing Incus on the other machine. -1. On the first machine, create and configure the uplink network: +1. すべてのマシンで `incus admin init` を実行して Incus クラスタを作成してください。 + 最初のマシンでクラスタを作成します。 + 次に最初のマシンで [`incus cluster add `](incus_cluster_add.md) を実行してトークンを出力し、他のマシンで Incus を初期化する際にトークンを指定して他のマシンをクラスタに参加させます。 +1. 最初のマシンでアップリンクネットワークを作成し設定します: incus network create UPLINK --type=physical parent= --target= incus network create UPLINK --type=physical parent= --target= @@ -135,34 +135,34 @@ In addition, you can add any number of servers to the Incus cluster that run onl ipv6.gateway= \ dns.nameservers= - To determine the required values: + 必要な値を決定します。 - Uplink interface - : A high availability OVN cluster requires a shared layer 2 network, so that the active OVN chassis can move between cluster members (which effectively allows the OVN router's external IP to be reachable from a different host). + アップリンクネットワーク + : アクティブな OVN シャーシがクラスタメンバー間で移動できるようにするため、ハイアベイラビリティな OVN クラスタには共有されたレイヤー 2 ネットワークが必須です（これにより OVN のルータの外部 IP が実質的に別のホストから到達可能にできます）。 - Therefore, you must specify either an unmanaged bridge interface or an unused physical interface as the parent for the physical network that is used for OVN uplink. - The instructions assume that you are using a manually created unmanaged bridge. - See [How to configure network bridges](https://netplan.readthedocs.io/en/stable/examples/#how-to-configure-network-bridges) for instructions on how to set up this bridge. + そのため管理されていないブリッジインターフェースまたは使用されていない物理インターフェースを OVN アップリンクで使用される物理ネットワークの親として指定する必要があります。 + 以下の手順は手動で作成した管理されていないブリッジを使用する想定です。 + このブリッジをセットアップする手順は [ネットワークブリッジの設定](https://netplan.readthedocs.io/en/stable/examples/#how-to-configure-network-bridges) を参照してください。 - Gateway - : Run `ip -4 route show default` and `ip -6 route show default`. + ゲートウェイ + : `ip -4 route show default` と `ip -6 route show default` を実行してください。 - Name server - : Run `resolvectl`. + ネームサーバー + : `resolvectl` を実行してください。 - IP ranges - : Use suitable IP ranges based on the assigned IPs. + IP の範囲 + : 割り当てられた IP を元に適切な IP の範囲を使用してください。 -1. Still on the first machine, configure Incus to be able to communicate with the OVN DB cluster. - To do so, find the value for `ovn-northd-nb-db` in `/etc/default/ovn-central` and provide it to Incus with the following command: +1. 引き続き最初のマシンで Incus を OVN DB クラスタと通信できるように設定します。 + そのためには、 `/etc/default/ovn-central` 内の `ovn-northd-nb-db` の値を確認し、以下のコマンドで Incus に指定します: incus config set network.ovn.northbound_connection -1. Finally, create the actual OVN network (on the first machine): +1. 最後に（最初のマシンで）実際の OVN ネットワークを作成します: incus network create my-ovn --type=ovn -1. To test the OVN network, create some instances and check the network connectivity: +1. OVN ネットワークをテストするには、インスタンスを作成してネットワークが接続できるか確認します: incus launch images:ubuntu/22.04 c1 --network my-ovn incus launch images:ubuntu/22.04 c2 --network my-ovn @@ -174,37 +174,37 @@ In addition, you can add any number of servers to the Incus cluster that run onl ping ping6 -n www.example.com -## Send OVN logs to Incus +## OVN ログを Incus に送信 -Complete the following steps to have the OVN controller send its logs to Incus. +OVN コントローラーのログを Incus に送るようにするには以下の手順を実行してください。 -1. Enable the syslog socket: +1. syslog ソケットを有効にします: incus config set core.syslog_socket=true -1. Open `/etc/default/ovn-host` for editing. +1. `/etc/default/ovn-host` を編集用に開きます: -1. Paste the following configuration: +1. 以下の設定をペーストします: OVN_CTL_OPTS=" \ --ovn-controller-log='-vsyslog:info --syslog-method=unix:/var/lib/incus/syslog.socket'" -1. Restart the OVN controller: +1. OVN コントローラーを再起動します: systemctl restart ovn-controller.service -You can now use [`incus monitor`](incus_monitor.md) to see logged network ACL traffic from the OVN controller: +これで [`incus monitor`](incus_monitor.md) を使って OVN コントローラーからのネットワーク ACL トラフィックのログを見られます: incus monitor --type=network-acls -You can also send the logs to Loki. -To do so, add the `network-acl` value to the {config:option}`server-loki:loki.types` configuration key, for example: +また Loki にログを送ることもできます。 +そのためには、たとえば、{config:option}`server-loki:loki.types`設定キーに`network-acl`の値を追加してください: incus config set loki.types=network-acl ```{tip} -You can include logs for OVN `northd`, OVN north-bound `ovsdb-server`, and OVN south-bound `ovsdb-server` as well. -To do so, edit `/etc/default/ovn-central`: +OVN `northd`、OVN north-bound `ovsdb-server`、OVN south-bound `ovsdb-server`のログもインクルードできます。 +そのためには、`/etc/default/ovn-central`を編集します: OVN_CTL_OPTS=" \ --ovn-northd-log='-vsyslog:info --syslog-method=unix:/var/lib/incus/syslog.socket' \ diff --git a/doc/howto/network_zones.md b/doc/howto/network_zones.md index 8dbbdecfe30..4bd11064f5f 100644 --- a/doc/howto/network_zones.md +++ b/doc/howto/network_zones.md @@ -1,65 +1,59 @@ (network-zones)= -# How to configure network zones +# ネットワークゾーンを設定するには ```{note} -Network zones are available for the {ref}`network-ovn` and the {ref}`network-bridge`. +ネットワークゾーンは {ref}`network-ovn` と {ref}`network-bridge` で利用できます。 ``` -Network zones can be used to serve DNS records for Incus networks. +ネットワークゾーンは Incus のネットワークの DNS レコードを保持するのに使用します。 -You can use network zones to automatically maintain valid forward and reverse records for all your instances. -This can be useful if you are operating a Incus cluster with multiple instances across many networks. +ネットワークゾーンを使うとすべてのインスタンスの有効な正引きと逆引きのレコードを自動的に維持できます。 +多くのネットワークにまたがる複数のインスタンスからなる Incus クラスタを運用する際に有用です。 -Having DNS records for each instance makes it easier to access network services running on an instance. -It is also important when hosting, for example, an outbound SMTP service. -Without correct forward and reverse DNS entries for the instance, sent mail might be flagged as potential spam. +各インスタンスに DNS レコードを持つとインスタンス上のネットワークサービスにアクセスするのがより簡単になります。 +またたとえば外部への SMTP サービスをホストする際にも重要です。 +インスタンスに正しい正引きと逆引きの DNS エントリがないと、送信されたメールが潜在的なスパムと判定されてしまうかもしれません。 -Each network can be associated to different zones: +各ネットワークは異なるゾーンに関連します。 -- Forward DNS records - multiple comma-separated zones (no more than one per project) -- IPv4 reverse DNS records - single zone -- IPv6 reverse DNS records - single zone +- 正引き DNS レコード - カンマ区切りの複数のゾーン（プロジェクトごとに最大 1 つ） +- IPv4 逆引き DNS レコード - 単一のゾーン +- IPv6 逆引き DNS レコード - 単一のゾーン -Incus will then automatically manage forward and reverse records for all instances, network gateways and downstream network ports and serve those zones for zone transfer to the operator’s production DNS servers. +Incus はすべてのインスタンス、ネットワークゲートウェイ、ダウンストリーム（下流）のネットワークポートのすべてに対して正引きと逆引きのレコードを自動で管理し、オペレータのプロダクションの DNS サーバーへのゾーン転送のためのこれらのゾーンを提供します。 -## Project views +## プロジェクトビュー -Projects have a {config:option}`project-features:features.networks.zones` feature, which is disabled by default. -This controls which project new networks zones are created in. -When this feature is enabled new zones are created in the project, otherwise they are created in the default project. +プロジェクトには `features.networks.zones` 機能があります。デフォルトでは無効です。 +これは新しいネットワークゾーンがどのプロジェクト内に作成されるかを制御します。 +この機能を有効にすると新しいゾーンはプロジェクト内に作成されますが、無効の場合はデフォルトプロジェクト内に作成されます。 -This allows projects that share a network in the default project (i.e those with `features.networks=false`) to have their own project level DNS zones that give a project oriented -"view" of the addresses on that shared network (which only includes addresses from instances in their project). +これにより、複数のプロジェクトがデフォルトプロジェクト（すなわち`features.networks=false`と設定されたプロジェクト）内のネットワークを共有できるようになり、共有されたネットワークに対してプロジェクト指向の（プロジェクト内のインスタンスのアドレスのみを含むような）「ビュー」を提供するプロジェクト固有の DNS ゾーンを持てるようになります。 -## Generated records +## 生成されるレコード -### Forward records +### 正引きレコード -If you configure a zone with forward DNS records for `incus.example.net` for your network, it generates records that resolve the following DNS names: +たとえば、あなたのネットワークで `incus.example.net` の正引き DNS レコードのゾーンを設定した場合、 +以下の DNS 名を解決するレコードを生成します: -- For all instances in the network: `.incus.example.net` -- For the network gateway: `.gw.incus.example.net` -- For downstream network ports (for network zones set on an uplink network with a downstream OVN network): `-.uplink.incus.example.net` -- Manual records added to the zone. +- ネットワーク内のすべてのインスタンスに対して: `.incus.example.net` +- ネットワークゲートウェイに対して: `.gw.incus.example.net` +- ダウンストリームネットワークポートに対して（ダウンストリーム OVN ネットワークを持つアップリンクのネットワーク上に設定されれうネットワークゾーンに対して）: `-.uplink.incus.example.net` +- ゾーンに手動で追加されたレコード。 -You can check the records that are generated with your zone setup with the `dig` command. +ゾーン設定に対して生成されたレコードは `dig` コマンドで確認できます。 +これは {config:option}`server-core:core.dns_address` が`:`に設定されていることを前提としています（その設定オプションを設定すると、バックエンドはすぐにそのアドレスでサービスを開始します）。 -This assumes that {config:option}`server-core:core.dns_address` was set to `:`. (Setting that configuration -option causes the backend to immediately start serving on that address.) +特定のゾーンに対して`dig`リクエストが許可されるようにするためには、そのゾーンの`peers.NAME.address`設定オプションを設定する必要があります。`NAME`はランダムなもので構いません。値は、`dig`が呼び出される IP アドレスと一致しなければなりません。同じランダムな`NAME`の`peers.NAME.key`は未設定のままにしておく必要があります。 -In order for the `dig` request to be allowed for a given zone, you must set the -`peers.NAME.address` configuration option for that zone. `NAME` can be anything random. The value must match the -IP address where your `dig` is calling from. You must leave `peers.NAME.key` for that same random `NAME` unset. - -For example: `incus network zone set incus.example.net peers.whatever.address=192.0.2.1`. +例: `lxc network zone set incus.example.net peers.whatever.address=192.0.2.1` ```{note} -It is not enough for the address to be of the same machine that `dig` is calling from; it needs to -match as a string with what the DNS server in `incus` thinks is the exact remote address. `dig` binds to -`0.0.0.0`, therefore the address you need is most likely the same that you provided to `core.dns_address`. +`dig`が呼び出し元の同じマシンのアドレスであるだけでは十分ではありません。それは、`incus`内のDNSサーバーが正確なリモートアドレスと考えるものと文字列で一致する必要があります。`dig`は`0.0.0.0`にバインドするため、必要なアドレスはおそらく、あなたが`core.dns_address`に提供したものと同じです。 ``` -For example, running `dig @ -p axfr incus.example.net` might give the following output: +たとえば、`dig @ -p axfr incus.example.net`と実行すると以下のような出力がでるかもしれません: ```{terminal} :input: dig @192.0.2.200 -p 1053 axfr incus.example.net @@ -76,11 +70,11 @@ manualtest.incus.example.net. 300 IN A 8.8.8.8 incus.example.net. 3600 IN SOA incus.example.net. ns1.incus.example.net. 1669736788 120 60 86400 30 ``` -### Reverse records +### 逆引きレコード -If you configure a zone for IPv4 reverse DNS records for `2.0.192.in-addr.arpa` for a network using `192.0.2.0/24`, it generates reverse `PTR` DNS records for addresses from all projects that are referencing that network via one of their forward zones. +`192.0.2.0/24` を使用するネットワークに `2.0.192.in-addr.arpa` の IPv4 逆引き DNS レコードのゾーンを設定すると、正引きゾーンの 1 つを経由してネットワークを参照するすべてのプロジェクトからのアドレスの逆引き `PTR` DNS レコードを生成します。 -For example, running `dig @ -p axfr 2.0.192.in-addr.arpa` might give the following output: +たとえば `dig @ -p axfr 2.0.192.in-addr.arpa` を実行すると以下のような出力が得られるかもしれません: ```{terminal} :input: dig @192.0.2.200 -p 1053 axfr 2.0.192.in-addr.arpa @@ -94,32 +88,32 @@ For example, running `dig @ -p axfr 2.0.192.in- ``` (network-dns-server)= -## Enable the built-in DNS server +## 組み込みの DNS サーバーを有効にする -To make use of network zones, you must enable the built-in DNS server. +ネットワークゾーンを使用するには、組み込みの DNS サーバーを有効にする必要があります。 -To do so, set the {config:option}`server-core:core.dns_address` configuration option to a local address on the Incus server. -To avoid conflicts with an existing DNS we suggest not using the port 53. -This is the address on which the DNS server will listen. -Note that in a Incus cluster, the address may be different on each cluster member. +そのためには、 Incus サーバーのローカルアドレスに {config:option}`server-core:core.dns_address` 設定オプションを設定してください。 +既存の DNS との衝突を避けるためポート 53 を使用しないことをお勧めします。 +これは DNS サーバーがリッスンするアドレスです。 +Incus クラスタの場合、アドレスは各クラスタメンバーによって異なるかもしれないことに注意してください。 ```{note} -The built-in DNS server supports only zone transfers through AXFR. -It cannot be directly queried for DNS records. -Therefore, the built-in DNS server must be used in combination with an external DNS server (`bind9`, `nsd`, ...), which will transfer the entire zone from Incus, refresh it upon expiry and provide authoritative answers to DNS requests. +組み込みの DNS サーバーは AXFR 経由でのゾーン転送のみをサポートしており、DNS レコードへの直接の問い合わせはできません。 +つまりこの機能は外部の DNS サーバー（`bind9`、`nsd`、…）の使用を前提としています。 +外部の DNS サーバーが Incus からの全体のゾーンを転送し、有効期限を過ぎたら更新し、DNS 問い合わせに対する管理権限を持つ応答（authoritative answers）を提供します。 -Authentication for zone transfers is configured on a per-zone basis, with peers defined in the zone configuration and a combination of IP address matching and TSIG-key based authentication. +ゾーン転送の認証はゾーン毎に設定され、各ゾーンでピアごとに IP アドレスと TSIG キーを設定して、TSIG キーベースの認証を行います。 ``` -## Create and configure a network zone +## ネットワークゾーンの作成と設定 -Use the following command to create a network zone: +ネットワークゾーンの作成には以下のコマンドを使用します: ```bash incus network zone create [configuration_options...] ``` -The following examples show how to configure a zone for forward DNS records, one for IPv4 reverse DNS records and one for IPv6 reverse DNS records, respectively: +以下の例は正引き DNS レコードのゾーン、IPv4 逆引き DNS レコードのゾーン、IPv6 逆引き DNS レコードのゾーンを作成する方法を示しています: ```bash incus network zone create incus.example.net @@ -128,106 +122,105 @@ incus network zone create 1.0.0.0.1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa ``` ```{note} -Zones must be globally unique, even across projects. -If you get a creation error, it might be due to the zone already existing in another project. +ゾーン名は複数のプロジェクトをまたいでグローバルにユニークでなければなりません。 +そのため、別のプロジェクト内の既存のゾーンのせいでゾーンの作成がエラーになることがありえます。 ``` -You can either specify the configuration options when you create the network or configure them afterwards with the following command: +ネットワークを作成するときに設定オプションを指定できますし、後から以下のコマンドで設定もできます: ```bash incus network zone set = ``` -Use the following command to edit a network zone in YAML format: +YAML 形式でネットワークゾーンを編集するには以下のコマンドを使用します: ```bash incus network zone edit ``` -### Configuration options +### 設定オプション -The following configuration options are available for network zones: +ネットワークゾーンで利用可能な設定オプションは下記のとおりです。 -Key | Type | Required | Default | Description -:-- | :-- | :-- | - | :-- -`peers.NAME.address`| string | no | - | IP address of a DNS server -`peers.NAME.key` | string | no | - | TSIG key for the server -`dns.nameservers` | string set | no | - | Comma-separated list of DNS server FQDNs (for NS records) -`network.nat` | bool | no | `true` | Whether to generate records for NAT-ed subnets -`user.*` | * | no | - | User-provided free-form key/value pairs +キー | 型 | 必須 | デフォルト値 | 説明 +:-- | :-- | :-- | - | :-- +`peers.NAME.address` | string | no | - | DNS サーバーの IP アドレス +`peers.NAME.key` | string | no | - | サーバーの TSIG キー +`dns.nameservers` | string set | no | - | （NS レコード用の）DNS サーバーの FQDN のカンマ区切りリスト +`network.nat` | bool | no | `true` | NAT されたサブネットのレコードを生成するかどうか +`user.*` | * | no | - | ユーザー提供の自由形式のキー・バリューペア ```{note} -When generating the TSIG key using `tsig-keygen`, the key name must follow the format `_.`. -For example, if your zone name is `incus.example.net` and the peer name is `bind9`, then the key name must be `incus.example.net_bind9.`. -If this format is not followed, zone transfer might fail. + +`tsig-keygen`を使用してTSIGキーを生成するとき、キー名は`_.`というフォーマットに従わなければなりません。たとえば、ゾーン名が`incus.example.net`でピア名が`bind9`の場合、キー名は`incus.example.net_bind9.`でなければなりません。この形式に従わない場合、ゾーン転送が失敗する可能性があります。 ``` -## Add a network zone to a network +## ネットワークにネットワークゾーンを追加する -To add a zone to a network, set the corresponding configuration option in the network configuration: +ネットワークにゾーンを追加するにはネットワーク設定内に対応する設定オプションを設定します: -- For forward DNS records: `dns.zone.forward` -- For IPv4 reverse DNS records: `dns.zone.reverse.ipv4` -- For IPv6 reverse DNS records: `dns.zone.reverse.ipv6` +- 正引き DNS レコードには: `dns.zone.forward` +- IPv4 逆引き DNS レコードには: `dns.zone.reverse.ipv4` +- IPv6 逆引き DNS レコードには: `dns.zone.reverse.ipv6` -For example: +たとえば: ```bash incus network set dns.zone.forward="incus.example.net" ``` -Zones belong to projects and are tied to the `networks` features of projects. -You can restrict projects to specific domains and sub-domains through the {config:option}`project-restricted:restricted.networks.zones` project configuration key. +ゾーンはプロジェクトに属し、プロジェクトの `networks` 機能に紐づきます。 +プロジェクトの {config:option}`project-restricted:restricted.networks.zones` 設定キーを使ってプロジェクトを指定のドメインとサブドメインに制限できます。 -## Add custom records +## カスタムレコードを追加する -A network zone automatically generates forward and reverse records for all instances, network gateways and downstream network ports. -If required, you can manually add custom records to a zone. +ネットワークゾーンは、すべてのインスタンス、ネットワークゲートウェイ、ダウンストリームネットワークポートに対して +正引きと逆引きレコードを自動的に生成します。 -To do so, use the [`incus network zone record`](incus_network_zone_record.md) command. +そのためには [`incus network zone record`](incus_network_zone_record.md) コマンドを使用します。 -### Create a record +### レコードを作成する -Use the following command to create a record: +レコードを作成するには以下のコマンドを使用します: ```bash incus network zone record create ``` -This command creates an empty record without entries and adds it to a network zone. +このコマンドはエントリ無しの空のレコードを作成しネットワークゾーンに追加します。 -#### Record properties +#### レコードのプロパティ -Records have the following properties: +レコードは以下のプロパティを持ちます。 -Property | Type | Required | Description -:-- | :-- | :-- | :-- -`name` | string | yes | Unique name of the record -`description` | string | no | Description of the record -`entries` | entry list | no | A list of DNS entries -`config` | string set | no | Configuration options as key/value pairs (only `user.*` custom keys supported) +プロパティ | 型 | 必須 | 説明 +:-- | :-- | :-- | :-- +`name` | string | yes | レコードのユニークな名前 +`description` | string | no | レコードの説明 +`entries` | entry list | no | DNS エントリのリスト +`config` | string set | no | キー／バリュー形式の設定オプション（`user.*` カスタムキーのみサポート） -### Add or remove entries +### エントリを追加または削除する -To add an entry to the record, use the following command: +レコードにエントリを追加するには以下のコマンドを使います: ```bash incus network zone record entry add [--ttl ] ``` -This command adds a DNS entry with the specified type and value to the record. +このコマンドはレコードに指定した型と値を持つ DNS エントリを追加します。 -For example, to create a dual-stack web server, add a record with two entries similar to the following: +たとえば、デュアルスタックのウェブサーバーを作成するには以下のような 2 つのエントリを持つレコードを追加します: ```bash incus network zone record entry add A 1.2.3.4 incus network zone record entry add AAAA 1234::1234 ``` -You can use the `--ttl` flag to set a custom time-to-live (in seconds) for the entry. -Otherwise, the default of 300 seconds is used. +エントリにカスタムの time-to-live（秒で指定）を設定するには `--ttl` フラグが使えます。 +指定しない場合、デフォルトの 300 秒になります。 -You cannot edit an entry (except if you edit the full record with [`incus network zone record edit`](incus_network_zone_record_edit.md)), but you can delete entries with the following command: +（[`incus network zone record edit`](incus_network_zone_record_edit.md) でレコード全体を編集するのを除いて）エントリを編集は出来ませんが、以下のコマンドでエントリを削除できます: ```bash incus network zone record entry remove diff --git a/doc/howto/projects_confine.md b/doc/howto/projects_confine.md index 82411c833d1..5e690bfa6eb 100644 --- a/doc/howto/projects_confine.md +++ b/doc/howto/projects_confine.md @@ -1,59 +1,58 @@ (projects-confine)= -# How to confine projects to specific users +# 特定のユーザーにプロジェクトを制限するには -You can use projects to confine the activities of different users or clients. -See {ref}`projects-confined` for more information. +プロジェクトを使用して、異なるユーザーまたはクライアントの活動を制限できます。 +詳細については、{ref}`projects-confined`を参照してください。 -How to confine a project to a specific user depends on the authentication method you choose. +特定のユーザーにプロジェクトを制限する方法は、選択した認証方法によって異なります。 -## Confine projects to specific TLS clients +## 特定のTLSクライアントにプロジェクトを制限する -You can confine access to specific projects by restricting the TLS client certificate that is used to connect to the Incus server. -See {ref}`authentication-tls-certs` for detailed information. +Incus サーバーへの接続に使用される TLS クライアント証明書を制限することで、特定のプロジェクトへのアクセスを制限できます。 +詳細については、{ref}`authentication-tls-certs`を参照してください。 -To confine the access from the time the client certificate is added, you must either use token authentication or add the client certificate to the server directly. -If you use password authentication, you can restrict the client certificate only after it has been added. +クライアント証明書が追加された時点からアクセスを制限するには、トークン認証を使用するか、クライアント証明書をサーバーに直接追加する必要があります。 -Use the following command to add a restricted client certificate: +制限されたクライアント証明書を追加するには、次のコマンドを使用します: ````{tabs} -```{group-tab} Token authentication +```{group-tab} トークン認証 incus config trust add --projects --restricted ``` -```{group-tab} Add client certificate +```{group-tab} クライアント証明書を追加 incus config trust add --projects --restricted ``` ```` -The client can then add the server as a remote in the usual way ([`incus remote add `](incus_remote_add.md) or [`incus remote add `](incus_remote_add.md)) and can only access the project or projects that have been specified. +クライアントは、通常の方法でサーバーをリモートに追加できます（[`incus remote add `](incus_remote_add.md) または [`incus remote add `](incus_remote_add.md)）。そして、指定されたプロジェクトのみにアクセスできます。 -To confine access for an existing certificate (either because the access restrictions change or because the certificate was added with a trust password), use the following command: +既存の証明書のアクセスを制限するには、次のコマンドを使用します: incus config trust edit -Make sure that `restricted` is set to `true` and specify the projects that the certificate should give access to under `projects`. +`restricted`が`true`に設定されていることを確認し、`projects`の下に証明書がアクセスを許可するプロジェクトを指定してください。 ```{note} -You can specify the `--project` flag when adding a remote. -This configuration pre-selects the specified project. -However, it does not confine the client to this project. +リモートを追加するときに`--project`フラグを指定できます。 +この設定では、指定されたプロジェクトが事前に選択されます。 +ただし、これによってクライアントがこのプロジェクトに制限されるわけではありません。 ``` -## Confine projects to specific Incus users +## 特定のIncusユーザーにプロジェクトを制限する -Incus can be configured to dynamically create projects for all users in a specific user group. -This is usually achieved by having some users be a member of the `incus` group but not the `incus-admin` group. +Incus は特定のユーザーグループ内のすべてのユーザーのために動的にプロジェクトを作成するように設定できます。 +これは通常`incus`グループのメンバーだが`incus-admin`グループのメンバーではないユーザーを作ることで実現されます。 -Make sure that all user accounts that you want to be able to use Incus are a member of this group. +Incus を使うユーザーアカウントはすべてこのグループのメンバーであるようにしてください。 -Once a member of the group issues a Incus command, Incus creates a confined project for this user and switches to this project. -If Incus has not been {ref}`initialized ` at this point, it is automatically initialized (with the default settings). +グループのメンバーが Incus コマンドを発行すると、Incus はこのユーザーのために制限されたプロジェクトを作成し、このプロジェクトに切り替えます。 +この時点で Incus が{ref}`初期化 `されていない場合、自動的に初期化されます（デフォルト設定で）。 -If you want to customize the project settings, for example, to impose limits or restrictions, you can do so after the project has been created. -To modify the project configuration, you must have full access to Incus, which means you must be part of the `incus-admin` group and not only the group that you configured as the Incus user group. +プロジェクトの設定をカスタマイズしたい場合（たとえば、制限や制約を課すために）、プロジェクトが作成された後で行うことができます。 +プロジェクト設定を変更するには、Incus への完全なアクセスが必要です。つまり、設定した Incus ユーザーグループの一員であるだけでなく、 `incus-admin`グループの一員である必要があります。 diff --git a/doc/howto/projects_create.md b/doc/howto/projects_create.md index 9397960cb85..efca71c90ca 100644 --- a/doc/howto/projects_create.md +++ b/doc/howto/projects_create.md @@ -1,49 +1,56 @@ (projects-create)= -# How to create and configure projects +# プロジェクトを作成し設定するには -You can configure projects at creation time or later. -However, note that it is not possible to modify the features that are enabled for a project when the project contains instances. +プロジェクトは作成時または後で設定することができます。 +ただし、プロジェクトにインスタンスが含まれている場合、有効になっている機能を変更することはできません。 -## Create a project +## プロジェクトを作成する -To create a project, use the [`incus project create`](incus_project_create.md) command. +プロジェクトを作成するには、[`incus project create`](incus_project_create.md) コマンドを使用します。 -You can specify configuration options by using the `--config` flag. -See {ref}`ref-projects` for the available configuration options. +`--config`フラグを使用して設定オプションを指定できます。 +利用可能な設定オプションについては、{ref}`ref-projects`を参照してください。 -For example, to create a project called `my-project` that isolates instances, but allows access to the default project's images and profiles, enter the following command: +たとえば、インスタンスを分離し、デフォルトプロジェクトのイメージとプロファイルにアクセスを許可する`my-project`というプロジェクトを作成するには、次のコマンドを入力します: incus project create my-project --config features.images=false --config features.profiles=false -To create a project called `my-restricted-project` that blocks access to security-sensitive features (for example, container nesting) but allows backups, enter the following command: +セキュリティーに関する機能（たとえば、コンテナのネスト）へのアクセスをブロックし、バックアップを許可する`my-restricted-project`というプロジェクトを作成するには、次のコマンドを入力します: incus project create my-restricted-project --config restricted=true --config restricted.backups=allow -(projects-configure)= -## Configure a project +```{tip} +設定オプションを指定せずにプロジェクトを作成する場合、{config:option}`project-features:features.profiles`は`true`に設定されます。これはプロジェクト内でプロファイルは隔離されることを意味します。 -To configure a project, you can either set a specific configuration option or edit the full project. +その結果、新しいプロジェクトは`default`プロジェクトの`default`プロファイルへのアクセスは持たず、そのため（ルートディスクのような）インスタンス作成に必要な設定が不足します。 +これを修正するためには、[`incus profile device add`](incus_profile_device_add.md)コマンドを使用してプロジェクトの`default`プロファイルにルートディスクデバイスを追加してください。 +``` -Some configuration options can only be set for projects that do not contain any instances. +(projects-configure)= +## プロジェクトの設定 +プロジェクトを設定するには、特定の設定オプションを設定するか、プロジェクト全体を編集できます。 -### Set specific configuration options +いくつかの設定オプションは、インスタンスが含まれていないプロジェクトに対してのみ設定できます。 -To set a specific configuration option, use the [`incus project set`](incus_project_set.md) command. +### 特定の設定オプションを設定する -For example, to limit the number of containers that can be created in `my-project` to five, enter the following command: +特定の設定オプションを設定するには、[`incus project set`](incus_project_set.md) コマンドを使用します。 + +たとえば、`my-project`で作成できるコンテナの数を 5 つに制限するには、次のコマンドを入力します: incus project set my-project limits.containers=5 -To unset a specific configuration option, use the [`incus project unset`](incus_project_unset.md) command. +特定の設定オプションを解除するには、[`incus project unset`](incus_project_unset.md) コマンドを使用します。 ```{note} -If you unset a configuration option, it is set to its default value. -This default value might differ from the initial value that is set when the project is created. +設定オプションを解除すると、デフォルト値に設定されます。 +このデフォルト値は、プロジェクトが作成されたときに設定される初期値と異なる場合があります。 ``` -### Edit the project +### プロジェクトを編集する + +プロジェクトの設定全体を編集するには、[`incus project edit`](incus_project_edit.md) コマンドを使用します。 -To edit the full project configuration, use the [`incus project edit`](incus_project_edit.md) command. -For example: +たとえば: incus project edit my-project diff --git a/doc/howto/projects_work.md b/doc/howto/projects_work.md index 6cb4bb835bf..b5321ae53af 100644 --- a/doc/howto/projects_work.md +++ b/doc/howto/projects_work.md @@ -1,21 +1,21 @@ (projects-work)= -# How to work with different projects +# 異なるプロジェクトで作業するには -If you have more projects than just the `default` profile, you must make sure to use or address the correct project when working with Incus. +`default`プロジェクト以外にもプロジェクトがある場合、Incus で作業する際に正しいプロジェクトを使用するか、対象となるプロジェクトを確認する必要があります。 ```{note} -If you have projects that are {ref}`confined to specific users `, only users with full access to Incus can see all projects. +{ref}`特定のユーザーに制限されたプロジェクト `がある場合、すべてのプロジェクトを表示できるのは、LXDへのフルアクセス権を持つユーザーのみです。 -Users without full access can only see information for the projects to which they have access. +フルアクセス権を持たないユーザーは、アクセス権があるプロジェクトの情報のみを表示できます。 ``` -## List projects +## プロジェクトの一覧表示 -To list all projects (that you have permission to see), enter the following command: +すべてのプロジェクト（閲覧許可があるもの）を一覧表示するには、次のコマンドを入力します: incus project list -By default, the output is presented as a list: +デフォルトでは、出力はリスト形式で表示されます: ```{terminal} :input: incus project list @@ -30,52 +30,53 @@ By default, the output is presented as a list: +----------------------+--------+----------+-----------------+-----------------+----------+---------------+---------------------+---------+ ``` -You can request a different output format by adding the `--format` flag. -See [`incus project list --help`](incus_project_list.md) for more information. +異なる出力形式を要求するには、`--format`フラグを追加します。 +詳細については、[`incus project list --help`](incus_project_list.md) を参照してください。 -## Switch projects +## プロジェクトの切り替え -By default, all commands that you issue in Incus affect the project that you are currently using. -To see which project you are in, use the [`incus project list`](incus_project_list.md) command. +デフォルトでは、Incus で実行するすべてのコマンドは、現在使用しているプロジェクトに影響します。 +どのプロジェクトを使用しているかを確認するには、[`incus project list`](incus_project_list.md) コマンドを使用します。 -To switch to a different project, enter the following command: +別のプロジェクトに切り替えるには、次のコマンドを入力します: incus project switch -## Target a project +## プロジェクトをターゲットにする -Instead of switching to a different project, you can target a specific project when running a command. -Many Incus commands support the `--project` flag to run an action in a different project. +別のプロジェクトに切り替える代わりに、コマンドを実行する際に特定のプロジェクトをターゲットにすることができます。 +多くの Incus コマンドは、`--project`フラグをサポートしており、異なるプロジェクトでアクションを実行できます。 ```{note} -You can target only projects that you have permission for. +許可があるプロジェクトだけをターゲットにすることができます。 ``` -The following sections give some typical examples where you would typically target a project instead of switching to it. +以下のセクションでは、プロジェクトを切り替える代わりにターゲットにする典型的な例をいくつか紹介します。 -### List instances in a project +### 特定のプロジェクト内のインスタンスをリストする -To list the instances in a specific project, add the `--project` flag to the [`incus list`](incus_list.md) command. -For example: +特定のプロジェクト内のインスタンスをリストするには、[`incus list`](incus_list.md) コマンドに`--project`フラグを追加します。 + +たとえば: incus list --project my-project -### Move an instance to another project +### インスタンスを別のプロジェクトに移動する -To move an instance from one project to another, enter the following command: +インスタンスを 1 つのプロジェクトから別のプロジェクトに移動するには、次のコマンドを入力します: incus move --project --target-project -You can keep the same instance name if no instance with that name exists in the target project. +ターゲットプロジェクトにその名前のインスタンスが存在しない場合、同じインスタンス名を維持できます。 -For example, to move the instance `my-instance` from the `default` project to `my-project` and keep the instance name, enter the following command: +たとえば、インスタンス`my-instance`を`default`プロジェクトから`my-project`に移動し、インスタンス名を維持するには、次のコマンドを入力します: incus move my-instance my-instance --project default --target-project my-project -### Copy a profile to another project +### プロファイルを別のプロジェクトにコピーする -If you create a project with the default settings, profiles are isolated in the project ([`features.profiles`](project-features) is set to `true`). -Therefore, the project does not have access to the default profile (which is part of the `default` project), and you will see an error similar to the following when trying to create an instance: +デフォルトの設定でプロジェクトを作成すると、プロファイルはプロジェクト内で隔離されます（[`features.profiles`](project-features) が `true` に設定されています）。 +そのため、プロジェクトはデフォルトのプロファイル（`default`プロジェクトの一部）にアクセスできず、インスタンスを作成しようとすると次のようなエラーが表示されます: ```{terminal} :input: incus launch images:ubuntu/22.04 my-instance @@ -84,7 +85,7 @@ Creating my-instance Error: Failed instance creation: Failed creating instance record: Failed initialising instance: Failed getting root disk: No root device could be found ``` -To fix this, you can copy the contents of the `default` project's default profile into the current project's default profile. -To do so, enter the following command: +これを修正するには、`default`プロジェクトのデフォルトプロファイルの内容を現在のプロジェクトのデフォルトプロファイルにコピーします。 +そのためには、次のコマンドを入力してください: incus profile show default --project default | incus profile edit default diff --git a/doc/howto/server_configure.md b/doc/howto/server_configure.md index c5ceda99952..952caee6ac2 100644 --- a/doc/howto/server_configure.md +++ b/doc/howto/server_configure.md @@ -1,38 +1,38 @@ (server-configure)= -# How to configure the Incus server +# Incusサーバーを設定するには -See {ref}`server` for all configuration options that are available for the Incus server. +Incus サーバーで利用可能なすべて設定オプションについては{ref}`server`を参照してください。 -If the Incus server is part of a cluster, some of the options apply to the cluster, while others apply only to the local server, thus the cluster member. -In the {ref}`server` option tables, options that apply to the cluster are marked with a `global` scope, while options that apply to the local server are marked with a `local` scope. +Incus サーバーがクラスタの一部の場合、一部のオプションはクラスタに適用され、また別のオプションはローカルサーバー、つまりクラスタメンバーにのみ適用されます。 +{ref}`server`オプションの表で、クラスタに適用されるオプションは`global`スコープと表記され、ローカルサーバーのみに適用されるオプションは`local`スコープと表記されます。 -## Configure server options +## サーバーオプションを設定する -You can configure a server option with the following command: +以下のコマンドでサーバーオプションを設定できます: incus config set -For example, to allow remote access to the Incus server on port 8443, enter the following command: +たとえば、ポート 8443 で Incus サーバーにリモートからのアクセスを許可するには、以下のコマンドを入力します: incus config set core.https_address :8443 -In a cluster setup, to configure a server option for a cluster member only, add the `--target` flag. -For example, to configure where to store image tarballs on a specific cluster member, enter a command similar to the following: +クラスタ構成では、クラスタメンバーだけにサーバー設定を行うには`--target`フラグを追加してください。 +たとえば、特定のクラスタメンバーでイメージの tarball を保管する場所を設定するには、以下のようなコマンドを入力してください: incus config set storage.images_volume my-pool/my-volume --target member02 -## Display the server configuration +## サーバー設定を表示する -To display the current server configuration, enter the following command: +現在のサーバー設定を表示するには、以下のコマンドを入力します: incus config show -In a cluster setup, to show the local configuration for a specific cluster member, add the `--target` flag. +クラスタ構成では、クラスタメンバーだけにサーバー設定を行うには`--target`フラグを追加してください。 -## Edit the full server configuration +## サーバー設定全体を編集する -To edit the full server configuration as a YAML file, enter the following command: +サーバー設定全体を YAML ファイルとして編集するには、以下のコマンドを入力します: incus config edit -In a cluster setup, to edit the local configuration for a specific cluster member, add the `--target` flag. +クラスタ構成では、クラスタメンバーだけにサーバー設定を行うには`--target`フラグを追加してください。 diff --git a/doc/howto/server_expose.md b/doc/howto/server_expose.md index 3586f459dac..9908a44ba83 100644 --- a/doc/howto/server_expose.md +++ b/doc/howto/server_expose.md @@ -1,17 +1,16 @@ (server-expose)= -# How to expose Incus to the network +# Incusをネットワークに公開するには -By default, Incus can be used only by local users through a Unix socket and is not accessible over the network. +デフォルトでは、Incus は Unix ソケットを介してローカルユーザーからのみ使用でき、ネットワーク経由でアクセスすることはできません。 -To expose Incus to the network, you must configure it to listen to addresses other than the local Unix socket. -To do so, set the {config:option}`server-core:core.https_address` server configuration option. +Incus をネットワークに公開するには、ローカル Unix ソケット以外のアドレスをリッスンするように設定する必要があります。これを行うには、{config:option}`server-core:core.https_address` サーバー設定オプションを設定します。 -For example, to allow access to the Incus server on port `8443`, enter the following command: +たとえば、Incus サーバーをポート`8443`でアクセスできるようにするには、以下のコマンドを入力します: incus config set core.https_address :8443 -To allow access through a specific IP address, use `ip addr` to find an available address and then set it. -For example: +特定の IP アドレスからのアクセスを許可するには、`ip addr`を使用して利用可能なアドレスを見つけ、それを設定します。 +たとえば: ```{terminal} :input: ip addr @@ -39,24 +38,24 @@ For example: :input: incus config set core.https_address 10.68.216.12 ``` -All remote clients can then connect to Incus and access any image that is marked for public use. +すべてのリモートクライアントは Incus に接続して公開利用とマークされた任意のイメージにアクセスできます。 (server-authenticate)= -## Authenticate with the Incus server +## Incusサーバーでの認証 -To be able to access the remote API, clients must authenticate with the Incus server. -There are several authentication methods; see {ref}`authentication` for detailed information. +リモート API にアクセスできるようにするには、クライアントは Incus サーバーに認証しなければなりません。 +いくつかの認証方法があります。詳細は{ref}`authentication`を参照してください。 -The recommended method is to add the client's TLS certificate to the server's trust store through a trust token. -To authenticate a client using a trust token, complete the following steps: +お勧めの方法はクライアントの TLS 証明書をトラストトークンを使ってサーバーのトラストストアに追加することです。 +トラストトークンを使ってクライアントを認証するには、以下の手順を実行します: -1. On the server, enter the following command: +1. サーバーで、以下のコマンドを入力します: incus config trust add - Enter the name of the client that you want to add. - The command generates and prints a token that can be used to add the client certificate. -1. On the client, add the server with the following command: + 追加したいクライアントの名前を入力します。 + クライアント証明書を追加するのに使用できるトークンをコマンドが生成し表示します。 +1. クライアントで、以下のコマンドでサーバーを追加します: incus remote add @@ -66,4 +65,4 @@ To authenticate a client using a trust token, complete the following steps: :end-before: ``` -See {ref}`authentication` for detailed information and other authentication methods. +詳細や他の認証方法については{ref}`authentication`を参照してください。 diff --git a/doc/howto/storage_backup_volume.md b/doc/howto/storage_backup_volume.md index 964c3fb8f06..01a19e91fdd 100644 --- a/doc/howto/storage_backup_volume.md +++ b/doc/howto/storage_backup_volume.md @@ -5,150 +5,150 @@ myst: --- (howto-storage-backup-volume)= -# How to back up custom storage volumes +# カスタムストレージボリュームをバックアップするには -There are different ways of backing up your custom storage volumes: +カスタムストレージボリュームをバックアップするにはいくつかの方法があります: - {ref}`storage-backup-snapshots` - {ref}`storage-backup-export` - {ref}`storage-copy-volume` -Which method to choose depends both on your use case and on the storage driver you use. +どの方法を選ぶかはあなたのユースケースとお使いのストレージドライバーによって異なります。 -In general, snapshots are quick and space efficient (depending on the storage driver), but they are stored in the same storage pool as the {{type}} and therefore not too reliable. -Export files can be stored on different disks and are therefore more reliable. -They can also be used to restore the {{type}} into a different storage pool. -If you have a separate, network-connected Incus server available, regularly copying {{type}}s to this other server gives high reliability as well, and this method can also be used to back up snapshots of the {{type}}. +一般に、スナップショットは高速で（ストレージドライバーによりますが）空間効率が良いですが、{{type}}と同じストレージプールに保存されますので信頼性はあまり高くありません。 +エクスポートファイルは別のディスク上に保存できますのでより信頼性が高いです。 +これらは別のストレージプールに{{type}}をリストアするのに使用できます。 +ネットワークで接続された別の Incus サーバーがある場合、定期的に{{type}}をこの別のサーバーにコピーするのも高い信頼性が得られます。そしてこの方法は{{type}}のスナップショットをバックアップするためにも使えます。 ```{note} -Custom storage volumes might be attached to an instance, but they are not part of the instance. -Therefore, the content of a custom storage volume is not stored when you {ref}`back up your instance `. -You must back up the data of your storage volume separately. +カスタムストレージボリュームがインスタンスにアタッチされているかもしれませんが、それらはインスタンスの一部ではありません。 +ですので、{ref}`インスタンスをバックアップ `する際カスタムストレージボリュームは保存されません。 +ストレージボリュームのデータは別途バックアップする必要があります。 ``` (storage-backup-snapshots)= -## Use snapshots for volume backup +## ボリュームのバックアップのスナップショットを使用する -A snapshot saves the state of the storage volume at a specific time, which makes it easy to restore the volume to a previous state. -It is stored in the same storage pool as the volume itself. +特定の日時のストレージボリュームをスナップショットを作成することで保存できます。スナップショットを使えばストレージボリュームを以前の状態に簡単に復元できます。 +スナップショットはボリューム自身と同じストレージプールに保存されます。 -Most storage drivers support optimized snapshot creation (see {ref}`storage-drivers-features`). -For these drivers, creating snapshots is both quick and space-efficient. -For the `dir` driver, snapshot functionality is available but not very efficient. -For the `lvm` driver, snapshot creation is quick, but restoring snapshots is efficient only when using thin-pool mode. +ほとんどのストレージドライバーはスナップショットの最適化された作成をサポートします（{ref}`storage-drivers-features`参照）。 +これらのドライバーではスナップショットの作成は高速で空間効率も良いです。 +`dir` ドライバーでは、スナップショットの機能は利用できますが、あまり効率がよくありません。 +`lvm` ドライバーでは、スナップショットの作成は高速ですが、スナップショットのリストアが効率的なのは thin-pool モードを使っているときだけです。 -### Create a snapshot of a custom storage volume +### カスタムストレージボリュームのスナップショットを作成する -Use the following command to create a snapshot for a custom storage volume: +カスタムストレージボリュームのスナップショットを作成するには以下のコマンド使用します: incus storage volume snapshot [] -Add the `--reuse` flag in combination with a snapshot name to replace an existing snapshot. +既存のスナップショットを置き換えるには、スナップショット名とともに `--reuse` フラグを追加します。 -By default, snapshots are kept forever, unless the `snapshots.expiry` configuration option is set. -To retain a specific snapshot even if a general expiry time is set, use the `--no-expiry` flag. +デフォルトでは、 `snapshots.expiry` 設定オプションが設定されていない限り、スナップショットは永遠に保存されます。 +全般的な期限が設定されていてもスナップショットを維持するには、 `--no-expiry` フラグを使用してください。 (storage-edit-snapshots)= -### View, edit or delete snapshots +### スナップショットを表示、編集、削除する -Use the following command to display the snapshots for a storage volume: +ストレージボリュームのスナップショットを表示するには以下のコマンドを使います: incus storage volume info -You can view or modify snapshots in a similar way to custom storage volumes, by referring to the snapshot with `/`. +スナップショットを `/` で参照することで、ストレージボリュームの場合と同様にスナップショットを表示または変更できます。 -To show information about a snapshot, use the following command: +スナップショットの情報を表示するには、以下のコマンドを使います: incus storage volume show / -To edit a snapshot (for example, to add a description or change the expiry date), use the following command: +スナップショットを編集（たとえば、説明を追加したり有効期限を編集）には以下のコマンドを使います: incus storage volume edit / -To delete a snapshot, use the following command: +スナップショットを削除するには、以下のコマンドを使います: incus storage volume delete / -### Schedule snapshots of a custom storage volume +### カスタムストレージボリュームのスナップショット作成をスケジュールする -You can configure a custom storage volume to automatically create snapshots at specific times. -To do so, set the `snapshots.schedule` configuration option for the storage volume (see {ref}`storage-configure-volume`). +指定した時刻に自動的にスナップショットを作成するようにカスタムストレージボリュームを設定できます。 +そのためには、ストレージボリュームの `snapshots.schedule` 設定オプションを設定してください（{ref}`storage-configure-volume`参照）。 -For example, to configure daily snapshots, use the following command: +たとえば、日次のスナップショットを設定するには、以下のコマンドを使います: incus storage volume set snapshots.schedule @daily -To configure taking a snapshot every day at 6 am, use the following command: +毎日 AM 6 時にスナップショットを作成するよう設定するには、以下のコマンドを使います: incus storage volume set snapshots.schedule "0 6 * * *" -When scheduling regular snapshots, consider setting an automatic expiry (`snapshots.expiry`) and a naming pattern for snapshots (`snapshots.pattern`). -See the {ref}`storage-drivers` documentation for more information about those configuration options. +定期的にスナップショットをスケジュールする際、自動破棄（`snapshots.expiry`）とスナップショットの命名規則（`snapshots.pattern`）の設定も検討してください。 +設定オプションの詳細は{ref}`storage-drivers`のドキュメントを参照してください。 -### Restore a snapshot of a custom storage volume +### カスタムストレージボリュームのスナップショットをリストアする -You can restore a custom storage volume to the state of any of its snapshots. +カスタムストレージボリュームを任意のスナップショットの状態に復元できます。 -To do so, you must first stop all instances that use the storage volume. -Then use the following command: +そのためには、まずストレージボリュームを使用しているすべてのインスタンスを停止する必要があります。 +その後以下のコマンドを入力します: incus storage volume restore -You can also restore a snapshot into a new custom storage volume, either in the same storage pool or in a different one (even a remote storage pool). -To do so, use the following command: +スナップショットを同じまたは別のストレージプール（リモートのストレージプールでも可）内に新しいカスタムストレージボリュームをリストアもできます。 +そのためには、以下のコマンドを入力します: incus storage volume copy // / (storage-backup-export)= -## Use export files for volume backup +## ボリュームのバックアップにエクスポートファイルを使用する -You can export the full content of your custom storage volume to a standalone file that can be stored at any location. -For highest reliability, store the backup file on a different file system to ensure that it does not get lost or corrupted. +カスタムストレージボリュームの完全な内容をスタンドアロンのファイルにエクスポートし、任意の場所に保存できます。 +信頼度を最大化するため、失われたり壊れたりしないように、バックアップファイルは別のファイルシステムに保存してください。 -### Export a custom storage volume +### カスタムストレージボリュームをエクスポートする -Use the following command to export a custom storage volume to a compressed file (for example, `/path/to/my-backup.tgz`): +以下のコマンドを使ってインスタンスを圧縮ファイル（たとえば、`/path/to/my-instance.tgz`）にエクスポートします: incus storage volume export [] -If you do not specify a file path, the export file is saved as `backup.tar.gz` in the working directory. +ファイルパスを指定しない場合、エクスポートファイルは作業ディレクトリーに `backup.tar.gz` という名前で保存されます。 ```{warning} -If the output file already exists, the command overwrites the existing file without warning. +出力ファイルがすでに存在する場合、コマンドは警告なしで既存のファイルを上書きします。 ``` -You can add any of the following flags to the command: +コマンドに以下のフラグを追加できます: `--compression` -: By default, the output file uses `gzip` compression. - You can specify a different compression algorithm (for example, `bzip2`) or turn off compression with `--compression=none`. +: デフォルトでは、出力ファイルは `gzip` 圧縮を使用します。 + 別の圧縮アルゴリズム（たとえば、`bzip2`）を指定したり、`--compression=none` で圧縮しないようにできます。 `--optimized-storage` -: If your storage pool uses the `btrfs` or the `zfs` driver, add the `--optimized-storage` flag to store the data as a driver-specific binary blob instead of an archive of individual files. - In this case, the export file can only be used with pools that use the same storage driver. +: ストレージプールが `btrfs` か `zfs` ドライバーを使用している場合、 `--optimized-storage` フラグを指定すると個別のファイルのアーカイブではなくドライバー固有のバイナリ形式でデータを保存します。 + この場合、エスクポートファイルは同じストレージドライバーを使うプールでのみ使用できます。 - Exporting a volume in optimized mode is usually quicker than exporting the individual files. - Snapshots are exported as differences from the main volume, which decreases their size and makes them easily accessible. + 最適化されたモードでボリュームをエクスポートするほうが個別のファイルをエクスポートするより通常は高速です。 + スナップショットはメインボリュームからの差分としてエクスポートされるため、サイズが小さくなりアクセスが容易になります。 `--volume-only` -: By default, the export file contains all snapshots of the storage volume. - Add this flag to export the volume without its snapshots. +: デフォルトでは、エクスポートファイルはストレージボリュームのすべてのスナップショットを含みます。 + このフラグを追加すると、スナップショットを除いたストレージボリュームのみをエクスポートします。 -### Restore a custom storage volume from an export file +### エクスポートファイルからカスタムストレージボリュームをリストアする -You can import an export file (for example, `/path/to/my-backup.tgz`) as a new custom storage volume. -To do so, use the following command: +エクスポートファイル（たとえば、 `/path/to/my-backup.tgz`）を新しいカスタムストレージボリュームとしてインポートできます。 +そのためには、以下のコマンドを使用します: incus storage volume import [] -If you do not specify a volume name, the original name of the exported storage volume is used for the new volume. -If a volume with that name already (or still) exists in the specified storage pool, the command returns an error. -In that case, either delete the existing volume before importing the backup or specify a different volume name for the import. +ボリューム名を指定しない場合、新しいボリュームの名前はエクスポートされたストレージボリュームの元の名前になります。 +その名前のボリュームが指定したストレージブールにすでに（あるいはまだ）存在する場合、コマンドはエラーを返します。 +その場合、バックアップをインポートする前に既存のボリュームを削除するか、あるいはインポートの際に別のボリューム名を指定してください。 diff --git a/doc/howto/storage_buckets.md b/doc/howto/storage_buckets.md index 7be49508f31..84dcd00bb54 100644 --- a/doc/howto/storage_buckets.md +++ b/doc/howto/storage_buckets.md @@ -1,134 +1,132 @@ (howto-storage-buckets)= -# How to manage storage buckets and keys +# ストレージバケットとキーを管理するには -See the following sections for instructions on how to create, configure, view and resize {ref}`storage-buckets` and how to manage storage bucket keys. +{ref}`storage-buckets` を作成、設定、表示、リサイズするための手順およびストレージバケットキーを管理する方法については以下のセクションを参照してください。 -## Configure the S3 address +## S3アドレスを設定する -If you want to use storage buckets on local storage (thus in a `dir`, `btrfs`, `lvm`, or `zfs` pool), you must configure the S3 address for your Incus server. -This is the address that you can then use to access the buckets through the S3 protocol. +S3 アドレスを設定することにより、ローカルストレージ（`dir`、`btrfs`、`lvm`、または`zfs`プール）上のストレージバケットを使用することが可能になります。これにより、S3 プロトコルを通じてバケットにアクセスできるようになります。 -To configure the S3 address, set the {config:option}`server-core:core.storage_buckets_address` server configuration option. -For example: +S3 アドレスを設定するには、{config:option}`server-core:core.storage_buckets_address` サーバー設定オプションを設定します。たとえば: incus config set core.storage_buckets_address :8555 -## Manage storage buckets +## ストレージバケットを管理する -Storage buckets provide access to object storage exposed using the S3 protocol. +ストレージバケットは S3 プロトコルを使って公開されるオブジェクトストレージを提供します。 -Unlike custom storage volumes, storage buckets are not added to an instance, but applications can instead access them directly via their URL. +カスタムストレージボリュームとは異なり、ストレージバケットはインスタンスに追加されるのではなく、それらの URL を通してアプリケーションから直接アクセスされます。 -See {ref}`storage-buckets` for detailed information. +詳細は {ref}`storage-buckets` を参照してください。 -### Create a storage bucket +### ストレージバケットを作成する -Use the following command to create a storage bucket in a storage pool: +ストレージプール内にストレージバケットを作成するには、以下のコマンドを使用します: incus storage bucket create [configuration_options...] -See the {ref}`storage-drivers` documentation for a list of available storage bucket configuration options for each driver that supports object storage. +それぞれのドライバーで利用可能なストレージバケット設定オプションの一覧については {ref}`storage-drivers` を参照してください。 -To add a storage bucket on a cluster member, add the `--target` flag: +クラスタメンバーにストレージバケットを追加するには `--target` フラグを追加してください: incus storage bucket create --target= [configuration_options...] ```{note} -For most storage drivers, storage buckets are not replicated across the cluster and exist only on the member for which they were created. -This behavior is different for `cephobject` storage pools, where buckets are available from any cluster member. +ほとんどのストレージドライバでは、ストレージバケットはクラスタ間でリプリケートされず、作成されたメンバー上にのみ存在します。 +この挙動は `cephobject` ストレージプールでは異なります。 `cephobject` ではバケットはどのクラスタメンバーからも利用できます。 ``` -### Configure storage bucket settings +### ストレージバケットを設定するには -See the {ref}`storage-drivers` documentation for the available configuration options for each storage driver that supports object storage. +各ストレージドライバーで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 -Use the following command to set configuration options for a storage bucket: +ストレージバケットの設定オプションを設定するには以下のコマンドを使用します: incus storage bucket set -For example, to set the quota size of a bucket, use the following command: +たとえば、バケットにクォータサイズを設定するには、以下のコマンドを使用します: incus storage bucket set my-pool my-bucket size 1MiB -You can also edit the storage bucket configuration by using the following command: +以下のコマンドでストレージバケットの設定を編集することもできます: incus storage bucket edit -Use the following command to delete a storage bucket and its keys: +ストレージバケットとそのキーを削除するには以下のコマンドを使用します: incus storage bucket delete -### View storage buckets +### ストレージバケットを表示するには -You can display a list of all available storage buckets in a storage pool and check their configuration. +ストレージプール内のすべての利用可能なストレージバケットの一覧を表示し設定を確認できます。 -To list all available storage buckets in a storage pool, use the following command: +ストレージプール内のすべての利用可能なストレージバケットを一覧表示するには、以下のコマンドを使用します: incus storage bucket list -To show detailed information about a specific bucket, use the following command: +特定のバケットの詳細情報を表示するには、以下のコマンドを使用します: incus storage bucket show -### Resize a storage bucket +### ストレージバケットをリサイズするには -By default, storage buckets do not have a quota applied. +デフォルトではストレージバケットにはクォータは適用されません。 -To set or change a quota for a storage bucket, set its size configuration: +ストレージバケットクォータを設定するには、サイズを設定します: incus storage bucket set size ```{important} -- Growing a storage bucket usually works (if the storage pool has sufficient storage). -- You cannot shrink a storage bucket below its current used size. +- ストレージバケットの拡大は通常は正常に動作します（ストレージプールが十分なストレージを持つ場合）。 +- ストレージバケットを現在の使用量より縮小することはできません。 ``` -## Manage storage bucket keys +## ストレージバケットキーを管理する -To access a storage bucket, applications must use a set of S3 credentials made up of an *access key* and a *secret key*. -You can create multiple sets of credentials for a specific bucket. +アプリケーションがストレージバケットにアクセスするためには *アクセスキー* と *シークレットキー* からなる S3 クレデンシャルを使う必要があります。 +特定のバケットに対して複数のセットのクレデンシャルを作成できます。 -Each set of credentials is given a key name. -The key name is used only for reference and does not need to be provided to the application that uses the credentials. +それぞれのクレデンシャルのセットにはキー名を設定します。 +キー名は参照のためだけに用いられ、アプリケーションがクレデンシャルを使用する際に提供する必要はありません。 -Each set of credentials has a *role* that specifies what operations they can perform on the bucket. +それぞれのクレデンシャルのセットには *ロール* が設定されます。それはバケットにどの操作を実行できるかを指定します。 -The roles available are: +使用可能なロールは以下のとおりです: -- `admin` - Full access to the bucket -- `read-only` - Read-only access to the bucket (list and get files only) +- `admin` - バケットへのフルアクセス。 +- `read-only` - バケットへの読み取り専用アクセス（一覧とファイルの取得のみ）。 -If the role is not specified when creating a bucket key, the role used is `read-only`. +バケットキー作成時にロールが指定されない場合、使用されるロールは `read-only` になります。 -### Create storage bucket keys +### ストレージバケットキーを作成する -Use the following command to create a set of credentials for a storage bucket: +ストレージバケットにクレデンシャルのセットを作成するには、以下のコマンドを使用します: incus storage bucket key create [configuration_options...] -Use the following command to create a set of credentials for a storage bucket with a specific role: +ストレージバケットに特定のロールを持つクレデンシャルのセットを作成するには、以下のコマンドを使用します: incus storage bucket key create --role=admin [configuration_options...] -These commands will generate and display a random set of credential keys. +これらのコマンドはランダムなクレデンシャルキーのセットを生成し表示します。 -### Edit or delete storage bucket keys +### ストレージバケットキーを編集または削除するには -Use the following command to edit an existing bucket key: +既存のバケットキーを編集するには以下のコマンドを使用します: incus storage bucket key edit -Use the following command to delete an existing bucket key: +既存のバケットキーを削除するには以下のコマンドを使用します: incus storage bucket key delete -### View storage bucket keys +### ストレージバケットのキーを表示するには -Use the following command to see the keys defined for an existing bucket: +既存のバケットに定義されているキーを表示するには以下のコマンドを使用します: incus storage bucket key list -Use the following command to see a specific bucket key: +特定のバケットキーを表示するには以下のコマンドを使用します: incus storage bucket key show diff --git a/doc/howto/storage_create_instance.md b/doc/howto/storage_create_instance.md index 15cf28f9657..f81dc86b887 100644 --- a/doc/howto/storage_create_instance.md +++ b/doc/howto/storage_create_instance.md @@ -1,13 +1,13 @@ (howto-storage-create-instance)= -# How to create an instance in a specific storage pool +# 特定のストレージプール内にインスタンスを作成するには -Instance storage volumes are created in the storage pool that is specified by the instance's root disk device. -This configuration is normally provided by the profile or profiles applied to the instance. -See {ref}`storage-default-pool` for detailed information. +インスタンスストレージボリュームはインスタンスのルートディスクデバイスにより指定されたストレージプール内に作成されます。 +通常この設定はインスタンスに適用されるプロファイルで提供されます。 +詳細な情報は {ref}`storage-default-pool` を参照してください。 -To use a different storage pool when creating or launching an instance, add the `--storage` flag. -This flag overrides the root disk device from the profile. -For example: +インスタンスを作成または起動する際に別のストレージプールを使用するには `--storage` フラグを追加します。 +このフラグはプロファイルからのルートディスクデバイスをオーバーライドします。 +たとえば: incus launch --storage diff --git a/doc/howto/storage_move_volume.md b/doc/howto/storage_move_volume.md index d6cbbb7b671..572b7d9e711 100644 --- a/doc/howto/storage_move_volume.md +++ b/doc/howto/storage_move_volume.md @@ -1,73 +1,73 @@ (howto-storage-move-volume)= -# How to move or copy storage volumes +# ストレージボリュームを移動やコピーするには -You can {ref}`copy ` or {ref}`move ` custom storage volumes from one storage pool to another, or copy or rename them within the same storage pool. +カスタムストレージボリュームはあるストレージプールから別のストレージプールに {ref}`コピー ` や {ref}`移動 ` したり、同じストレージプール内でコピーやリネームできます。 -To move instance storage volumes from one storage pool to another, {ref}`move the corresponding instance ` to another pool. +インスタンスストレージボリュームをあるストレージプールから別のストレージプールに移動するには、別のストレージプールに {ref}`対応するインスタンスを移動 ` します。 -When copying or moving a volume between storage pools that use different drivers, the volume is automatically converted. +別のドライバーを使用するストレージプール間でボリュームをコピーまたは移動する際はボリュームは自動的に変換されます。 (storage-copy-volume)= -## Copy custom storage volumes +## カスタムストレージボリュームをコピーする -Use the following command to copy a custom storage volume: +カスタムストレージボリュームをコピーするには以下のコマンドを使用します: incus storage volume copy / / -Add the `--volume-only` flag to copy only the volume and skip any snapshots that the volume might have. -If the volume already exists in the target location, use the `--refresh` flag to update the copy. +ボリュームに存在するかもしれないスナップショットをスキップしてボリュームだけをコピーするには `--volume-only` フラグを追加してください。 +コピー先のロケーションにボリュームが既に存在する場合は、コピーを更新するために `--refresh` フラグを使ってください。 -Specify the same pool as the source and target pool to copy the volume within the same storage pool. -You must specify different volume names for source and target in this case. +同じストレージプール内でボリュームをコピーするにはコピー元とコピー先に同じプールを指定します。 +この場合コピー元とコピー先で別のボリューム名を指定する必要があります。 -When copying from one storage pool to another, you can either use the same name for both volumes or rename the new volume. +ボリュームをあるストレージプールから別のストレージプールにコピーする場合は、同じボリューム名を使うことも新しいボリューム名にリネームすることもできます。 (storage-move-volume)= -## Move or rename custom storage volumes +## カスタムストレージボリュームを移動またはリネームする -Before you can move or rename a custom storage volume, all instances that use it must be {ref}`stopped `. +カスタムストレージボリュームを移動またはリネームする前に、それを利用しているすべてのインスタンスを {ref}`停止 ` する必要があります。 -Use the following command to move or rename a storage volume: +ストレージボリュームを移動またはリネームするには以下のコマンドを使用します: incus storage volume move / / -Specify the same pool as the source and target pool to rename the volume while keeping it in the same storage pool. -You must specify different volume names for source and target in this case. +変更前のプールと変更後のプールに同じプールを指定すると、同じストレージプールに置いたままボリューム名を変更できます。 +この場合変更前と変更後で別のボリューム名を指定する必要があります。 -When moving from one storage pool to another, you can either use the same name for both volumes or rename the new volume. +ボリュームをあるストレージプールから別のストレージプールに移動する場合は、同じボリューム名を使うことも新しいボリューム名にリネームすることもできます。 -## Copy or move between cluster members +## クラスタメンバー間でコピーまたは移動する -For most storage drivers (except for `ceph` and `ceph-fs`), storage volumes exist only on the cluster member for which they were created. +（`ceph` と `ceph-fs` を除く）ほとんどのストレージドライバーではストレージボリュームはそれらが作成されたクラスタメンバー上だけに存在します。 -To copy or move a custom storage volume from one cluster member to another, add the `--target` and `--destination-target` flags to specify the source cluster member and the target cluster member, respectively. +あるクラスタメンバーから別のメンバーにカスタムストレージボリュームをコピーまたは移動するには `--target` と `--destination-target` フラグでそれぞれコピー/移動元のクラスタメンバーとコピー/移動先のクラスタメンバーを指定します。 -## Copy or move between projects +## プロジェクト間でコピーまたは移動する -Add the `--target-project` to copy or move a custom storage volume to a different project. +別のプロジェクトにカスタムストレージボリュームをコピーまたは移動するには `--target-project` を追加してください。 -## Copy or move between Incus servers +## Incus サーバー間でコピーまたは移動する -You can copy or move custom storage volumes between different Incus servers by specifying the remote for each pool: +対象の各プールにリモートを指定することで異なる Incus サーバー間でカスタムストレージボリュームをコピーまたは移動できます: incus storage volume copy :/ :/ incus storage volume move :/ :/ -You can add the `--mode` flag to choose a transfer mode, depending on your network setup: +ネットワークのセットアップに応じて `--mode` フラグを追加して転送モードを選べます。 -`pull` (default) -: Instruct the target server to pull the respective storage volume. +`pull`（デフォルト） +: コピー/移動先のサーバーに指定のストレージボリュームをプルするように指示します。 `push` -: Push the storage volume from the source server to the target server. +: コピー/移動元のサーバーからストレージボリュームをコピー/移動先のサーバーにプッシュします。 `relay` -: Pull the storage volume from the source server to the local client, and then push it to the target server. +: コピー/移動元のサーバーからストレージボリュームをローカルクライアントにプルし、それからコピー/移動先のサーバーにプッシュします。 (storage-move-instance)= -## Move instance storage volumes to another pool +## インスタンスストレージプールを別のプールに移動する -To move an instance storage volume to another storage pool, make sure the instance is stopped. -Then use the following command to move the instance to a different pool: +インスタンスストレージプールを別のプールに移動するにはまずインスタンスが停止されていることを確認してください。 +次に以下のコマンドでインスタンスを別のプールに移動します: incus move --storage diff --git a/doc/howto/storage_pools.md b/doc/howto/storage_pools.md index 20b373ab491..f4e28287314 100644 --- a/doc/howto/storage_pools.md +++ b/doc/howto/storage_pools.md @@ -1,138 +1,138 @@ (howto-storage-pools)= -# How to manage storage pools +# ストレージプールを管理するには -See the following sections for instructions on how to create, configure, view and resize {ref}`storage-pools`. +{ref}`storage-pools` を作成、設定、表示、リサイズするための手順については以下のセクションを参照してください。 (storage-create-pool)= -## Create a storage pool +## ストレージプールを作成する -Incus creates a storage pool during initialization. -You can add more storage pools later, using the same driver or different drivers. +Incus は初期化中にストレージプールを作成します。 +同じドライバーあるいは別のドライバーを使用して、後からさらにストレージプールを追加できます。 -To create a storage pool, use the following command: +ストレージプールを作成するには以下のコマンドを使用します: incus storage create [configuration_options...] -Unless specified otherwise, Incus sets up loop-based storage with a sensible default size (20% of the free disk space, but at least 5 GiB and at most 30 GiB). +別途指定しない場合は、 Incus は実用的なデフォルトのサイズ（空きディスクスペースの 20%、しかし最低 5GiB で最大 30GiB）でループベースのストレージをセットアップします。 -See the {ref}`storage-drivers` documentation for a list of available configuration options for each driver. +それぞれのドライバーで利用可能な設定オプションの一覧は {ref}`storage-drivers` ドキュメントを参照してください。 -### Examples +### 例 -See the following examples for how to create a storage pool using different storage drivers. +それぞれのストレージドライバーでストレージプールを作成する例は以下を参照してください。 `````{tabs} -````{group-tab} Directory +````{group-tab} ディレクトリ -Create a directory pool named `pool1`: +`pool1` という名前のディレクトリプールを作成する: incus storage create pool1 dir -Use the existing directory `/data/incus` for `pool2`: +`/data/incus` という既存のディレクトリを使って `pool2` を作成する: incus storage create pool2 dir source=/data/incus ```` ````{group-tab} Btrfs -Create a loop-backed pool named `pool1`: +`pool1` という名前のループバックプールを作成する: incus storage create pool1 btrfs -Use the existing Btrfs file system at `/some/path` for `pool2`: +`/some/path` にある既存の Btrfs ファイルシステムを使って `pool2` を作成する: incus storage create pool2 btrfs source=/some/path -Create a pool named `pool3` on `/dev/sdX`: +`/dev/sdX` 上に `pool3` という名前のプールを作成する: incus storage create pool3 btrfs source=/dev/sdX ```` ````{group-tab} LVM -Create a loop-backed pool named `pool1` (the LVM volume group will also be called `pool1`): +`pool1` という名前のループバックのプールを作成する（LVM ボリュームグループ名も `pool1` になります）: incus storage create pool1 lvm -Use the existing LVM volume group called `my-pool` for `pool2`: +`my-pool` という既存の LVM ボリュームグループを使って `pool2` を作成する: incus storage create pool2 lvm source=my-pool -Use the existing LVM thin pool called `my-pool` in volume group `my-vg` for `pool3`: +`my-vg` というボリュームグループ内の `my-pool` という既存の LVM thin-pool を使って `pool3` を作成する: incus storage create pool3 lvm source=my-vg lvm.thinpool_name=my-pool -Create a pool named `pool4` on `/dev/sdX` (the LVM volume group will also be called `pool4`): +`/dev/sdX` 上に `pool4` という名前のプールを作成する（LVM ボリュームグループ名も `pool4` になります）: incus storage create pool4 lvm source=/dev/sdX -Create a pool named `pool5` on `/dev/sdX` with the LVM volume group name `my-pool`: +`/dev/sdX` 上に `my-pool` というLVM ボリュームグループ名で `pool5` という名前のプールを作成する: incus storage create pool5 lvm source=/dev/sdX lvm.vg_name=my-pool ```` ````{group-tab} ZFS -Create a loop-backed pool named `pool1` (the ZFS zpool will also be called `pool1`): +`pool1` という名前のループバックプールを作成する（ZFS zpool 名も `pool1` になります）: incus storage create pool1 zfs -Create a loop-backed pool named `pool2` with the ZFS zpool name `my-tank`: +`pool2` という名前のループバックプールを `my-tank` という ZFS zpool 名で作成する: incus storage create pool2 zfs zfs.pool_name=my-tank -Use the existing ZFS zpool `my-tank` for `pool3`: +`my-tank` という既存の ZFS zpool を使用して `pool3` を作成する: incus storage create pool3 zfs source=my-tank -Use the existing ZFS dataset `my-tank/slice` for `pool4`: +`my-tank/slice` という既存の ZFS データセットを使用して `pool4` を作成する: incus storage create pool4 zfs source=my-tank/slice -Use the existing ZFS dataset `my-tank/zvol` for `pool5` and configure it to use ZFS block mode: +`/dev/sdX` 上に `pool5` という名前のプールを作成する（ZFS zpool 名も `pool5` になります）: incus storage create pool5 zfs source=my-tank/zvol volume.zfs.block_mode=yes -Create a pool named `pool6` on `/dev/sdX` (the ZFS zpool will also be called `pool6`): +`/dev/sdX` 上に `pool6` という名前のプールを作成する（ZFS zpool 名も `pool6` になります）: incus storage create pool6 zfs source=/dev/sdX -Create a pool named `pool7` on `/dev/sdX` with the ZFS zpool name `my-tank`: +`/dev/sdX` 上に `my-tank` という ZFS zpool 名で `pool7` という名前のプールを作成する: incus storage create pool7 zfs source=/dev/sdX zfs.pool_name=my-tank ```` ````{group-tab} Ceph RBD -Create an OSD storage pool named `pool1` in the default Ceph cluster (named `ceph`): +デフォルトの Ceph クラスタ（名前は `ceph`）内に `pool1` という名前の OSD ストレージプールを作成する: incus storage create pool1 ceph -Create an OSD storage pool named `pool2` in the Ceph cluster `my-cluster`: +`my-cluster` という Ceph クラスタ内に `pool2` という名前の OSD ストレージプールを作成する: incus storage create pool2 ceph ceph.cluster_name=my-cluster -Create an OSD storage pool named `pool3` with the on-disk name `my-osd` in the default Ceph cluster: +デフォルトの Ceph クラスタ内に `my-osd` という on-disk 名で `pool3` という名前の OSD ストレージプールを作成する: incus storage create pool3 ceph ceph.osd.pool_name=my-osd -Use the existing OSD storage pool `my-already-existing-osd` for `pool4`: +`my-already-existing-osd` という既存の OSD ストレージプールを使って `pool4` を作成する: incus storage create pool4 ceph source=my-already-existing-osd -Use the existing OSD erasure-coded pool `ecpool` and the OSD replicated pool `rpl-pool` for `pool5`: +`ecpool` という既存の OSD erasure-coded ストレージプールと `rpl-pool` という OSD リプリケーテッドプールを使って `pool5` を作成する: incus storage create pool5 ceph source=rpl-pool ceph.osd.data_pool_name=ecpool ```` ````{group-tab} CephFS ```{note} -When using the CephFS driver, you must create a CephFS file system beforehand. -This file system consists of two OSD storage pools, one for the actual data and one for the file metadata. +CephFS ドライバを使用する際は、事前に CephFS ファイルシステムを作成する必要があります。 +このファイルシステムは 2 つの OSD ストレージプールからなります。そのうち 1 つは実際のデータ、もう 1 つはファイルメタデータに使用されます。 ``` -Use the existing CephFS file system `my-filesystem` for `pool1`: +既存の CephFS ファイルシステム `my-filesystem` を使って `pool1` を作成する: incus storage create pool1 cephfs source=my-filesystem -Use the sub-directory `my-directory` from the `my-filesystem` file system for `pool2`: +`my-filesystem` ファイルシステムからサブディレクトリ `my-directory` を使って `pool2` を作成する: incus storage create pool2 cephfs source=my-filesystem/my-directory @@ -140,26 +140,26 @@ Use the sub-directory `my-directory` from the `my-filesystem` file system for `p ````{group-tab} Ceph Object ```{note} -When using the Ceph Object driver, you must have a running Ceph Object Gateway [`radosgw`](https://docs.ceph.com/en/latest/radosgw/) URL available beforehand. +Ceph Object ドライバを使用する場合、事前に稼働中の Ceph Object Gateway [`radosgw`](https://docs.ceph.com/en/latest/radosgw/) の URL を用意しておく必要があります。 ``` -Use the existing Ceph Object Gateway `https://www.example.com/radosgw` to create `pool1`: +既存の Ceph Object Gateway `https://www.example.com/radosgw` を使用して `pool1` を作成する: incus storage create pool1 cephobject cephobject.radosgw.endpoint=https://www.example.com/radosgw ```` ````` (storage-pools-cluster)= -### Create a storage pool in a cluster +### クラスタ内にストレージプールを作成する -If you are running a Incus cluster and want to add a storage pool, you must create the storage pool for each cluster member separately. -The reason for this is that the configuration, for example, the storage location or the size of the pool, might be different between cluster members. +Incus クラスタを稼働していてストレージプールを追加したい場合、それぞれのクラスタメンバー内にストレージを別々に作る必要があります。 +この理由は、設定、たとえばストレージのロケーションやプールのサイズがクラスタメンバー間で異なるかもしれないからです。 -Therefore, you must first create a pending storage pool on each member with the `--target=` flag and the appropriate configuration for the member. -Make sure to use the same storage pool name for all members. -Then create the storage pool without specifying the `--target` flag to actually set it up. +このため、 `--target=` フラグを指定してストレージプールをペンディング状態でまず作成し、メンバーごとに適切な設定を行う必要があります。 +すべてのメンバーで同じストレージプール名を使用しているか確認してください。 +次に `--target` フラグなしでストレージプールを作成し、実際にセットアップします。 -For example, the following series of commands sets up a storage pool with the name `my-pool` at different locations and with different sizes on three cluster members: +たとえば、以下の一連のコマンドは 3 つのクラスタメンバー上で異なるロケーションと異なるサイズで `my-pool` という名前のストレージプールをセットアップします: ```{terminal} :input: incus storage create my-pool zfs source=/dev/sdX size=10GiB --target=vm01 @@ -172,58 +172,58 @@ Storage pool my-pool pending on member vm03 Storage pool my-pool created ``` -Also see {ref}`cluster-config-storage`. +{ref}`cluster-config-storage`も参照してください。 ```{note} -For most storage drivers, the storage pools exist locally on each cluster member. -That means that if you create a storage volume in a storage pool on one member, it will not be available on other cluster members. +ほとんどのストレージドライバでは、ストレージプールは各クラスタメンバー上にローカルに存在します。 +これは 1 つのメンバー上のストレージプール内にストレージボリュームを作成しても、別のクラスタメンバー上では利用可能にはならないことを意味します。 -This behavior is different for Ceph-based storage pools (`ceph`, `cephfs` and `cephobject`) where each storage pool exists in one central location and therefore, all cluster members access the same storage pool with the same storage volumes. +この挙動は Ceph ベースのストレージプール（`ceph`、 `cephfs`、 `cephobject`）では異なります。これらではストレージプールは 1 つの中央のロケーション上に存在し、全てのクラスタメンバーが同じストレージボリュームを持つ同じストレージプールにアクセスします。 ``` -## Configure storage pool settings +## ストレージプールを設定する -See the {ref}`storage-drivers` documentation for the available configuration options for each storage driver. +各ストレージドライバーで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 -General keys for a storage pool (like `source`) are top-level. -Driver-specific keys are namespaced by the driver name. +（`source` のような）ストレージプールの一般的なキーはトップレベルです。 +ドライバー固有のキーはドライバー名で名前空間が分けられています。 -Use the following command to set configuration options for a storage pool: +ストレージプールに設定オプションを設定するには以下のコマンドを使用します: incus storage set -For example, to turn off compression during storage pool migration for a `dir` storage pool, use the following command: +たとえば、 `dir` ストレージプールでストレージプールのマイグレーション中に圧縮をオフにするには以下のコマンドを使用します: incus storage set my-dir-pool rsync.compression false -You can also edit the storage pool configuration by using the following command: +ストレージプールの設定を編集するには以下のコマンドを使用します: incus storage edit -## View storage pools +## ストレージプールを表示する -You can display a list of all available storage pools and check their configuration. +すべての利用可能なストレージプールの一覧を表示し設定を確認できます。 -Use the following command to list all available storage pools: +以下のコマンドですべての利用可能なストレージプールを一覧表示できます: incus storage list -The resulting table contains the storage pool that you created during initialization (usually called `default` or `local`) and any storage pools that you added. +出力結果の表には（訳注: Incus の）初期化時に作成した（通常 `default` や `local` と呼ばれる）ストレージプールとあなたが追加したあらゆるストレージプールが含まれます。 -To show detailed information about a specific pool, use the following command: +特定のプールに関する詳細情報を表示するには、以下のコマンドを使用します: incus storage show -To see usage information for a specific pool, run the following command: +特定のプールに関する使用量を表示するには、以下のコマンドを使用します: incus storage info (storage-resize-pool)= -## Resize a storage pool +## ストレージプールをリサイズする -If you need more storage, you can increase the size of your storage pool by changing the `size` configuration key: +ストレージがもっと必要な場合、`size` 設定キーを変更することでストレージプールのサイズを拡大できます: incus storage set size= -This will only work for loop-backed storage pools that are managed by Incus. -You can only grow the pool (increase its size), not shrink it. +これはループファイルをバックエンドとし Incus で管理されているストレージプールでのみ機能します。 +プールは拡張（サイズを増やす）のみが可能で、縮小はできません。 diff --git a/doc/howto/storage_volumes.md b/doc/howto/storage_volumes.md index 6380db65c14..80efea2101e 100644 --- a/doc/howto/storage_volumes.md +++ b/doc/howto/storage_volumes.md @@ -1,192 +1,192 @@ (howto-storage-volumes)= -# How to manage storage volumes +# ストレージボリュームを管理するには -See the following sections for instructions on how to create, configure, view and resize {ref}`storage-volumes`. +{ref}`storage-volumes` を作成、設定、表示、リサイズするための手順については以下のセクションを参照してください。 -## Create a custom storage volume +## カスタムストレージボリュームを作成する -When you create an instance, Incus automatically creates a storage volume that is used as the root disk for the instance. +インスタンスを作成する際に、 Incus はインスタンスのルートディスクとして使用するストレージボリュームを自動的に作成します。 -You can add custom storage volumes to your instances. -Such custom storage volumes are independent of the instance, which means that they can be backed up separately and are retained until you delete them. -Custom storage volumes with content type `filesystem` can also be shared between different instances. +インスタンスにカスタムストレージボリュームを追加できます。 +このカスタムストレージボリュームはインスタンスから独立しています。これは別にバックアップできたり、カスタムストレージボリュームを削除するまで残っていることを意味します。 +コンテントタイプが `filesystem` のカスタムストレージボリュームは異なるインスタンス間で共有もできます。 -See {ref}`storage-volumes` for detailed information. +詳細な情報は {ref}`storage-volumes` を参照してください。 -### Create the volume +### ボリュームを作成する -Use the following command to create a custom storage volume of type `block` or `filesystem` in a storage pool: +ストレージプール内に `block` または `filesystem` のタイプのカスタムストレージボリュームを作成するには以下のコマンドを使用します: incus storage volume create [configuration_options...] -See the {ref}`storage-drivers` documentation for a list of available storage volume configuration options for each driver. +各ドライバーで利用可能なストレージボリューム設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 -By default, custom storage volumes use the `filesystem` {ref}`content type `. -To create a custom storage volume with the content type `block`, add the `--type` flag: +デフォルトではカスタムストレージボリュームは `filesystem` {ref}`コンテントタイプ ` を使用します。 +`block` コンテントタイプのカスタムストレージボリュームを作成するには `--type` フラグを追加してください: incus storage volume create --type=block [configuration_options...] -To add a custom storage volume on a cluster member, add the `--target` flag: +クラスタメンバー上にカスタムストレージボリュームを追加するには `--target` フラグを追加してください: incus storage volume create --target= [configuration_options...] ```{note} -For most storage drivers, custom storage volumes are not replicated across the cluster and exist only on the member for which they were created. -This behavior is different for Ceph-based storage pools (`ceph` and `cephfs`), where volumes are available from any cluster member. +ほとんどのストレージドライバではカスタムストレージボリュームはクラスタ間で同期されず作成されたメンバー上にのみ存在します。 +この挙動は Ceph ベースのストレージプール（`ceph` と `cephfs`）では異なり、ボリュームはどのクラスタメンバーでも利用可能です。 ``` -To create a custom storage volume of type `iso`, use the `import` command instead of the `create` command: +タイプが `iso` のカスタムストレージボリュームを作るには、 `create` コマンドではなく `import` コマンドを使います: incus storage volume import --type=iso (storage-attach-volume)= -### Attach the volume to an instance +### インスタンスにカスタムストレージボリュームをアタッチする -After creating a custom storage volume, you can add it to one or more instances as a {ref}`disk device `. +カスタムストレージボリュームを作成したら、それを 1 つあるいは複数のインスタンスに {ref}`ディスクデバイス ` として追加できます。 -The following restrictions apply: +以下の制限があります: -- Custom storage volumes of {ref}`content type ` `block` or `iso` cannot be attached to containers, but only to virtual machines. -- To avoid data corruption, storage volumes of {ref}`content type ` `block` should never be attached to more than one virtual machine at a time. -- Storage volumes of {ref}`content type ` `iso` are always read-only, and can therefore be attached to more than one virtual machine at a time without corrupting data. -- File system storage volumes can't be attached to virtual machines while they're running. +- {ref}`コンテントタイプ ` が `block` または `iso` のカスタムストレージボリュームはコンテナにはアタッチできず、仮想マシンのみにアタッチできます。 +- データ破壊を防ぐため、 {ref}`コンテントタイプ ` が `block` のカスタムストレージボリュームは同時に複数の仮想マシンには決してアタッチするべきではありません。 +- {ref}`コンテントタイプ ` が `iso` のカスタムストレージボリュームは読み取り専用であり、データを破壊することなく同時に複数の仮想マシンにアタッチできます。 +- ファイルシステムのストレージボリュームは仮想マシンの稼働中にアタッチはできません。 -For custom storage volumes with the content type `filesystem`, use the following command, where `` is the path for accessing the storage volume inside the instance (for example, `/data`): +コンテントタイプ `filesystem` のカスタムストレージボリュームは以下のコマンドを使用します。ここで `` はインスタンス内でストレージボリュームにアクセスするためのパス（例: `/data`）です: incus storage volume attach -Custom storage volumes with the content type `block` do not take a location: +コンテントタイプ `block` のカスタムストレージボリュームは `` を指定しません: incus storage volume attach -By default, the custom storage volume is added to the instance with the volume name as the {ref}`device ` name. -If you want to use a different device name, you can add it to the command: +デフォルトでは、カスタムストレージボリュームはインスタンスに {ref}`デバイス ` の名前でボリュームが追加されます。 +異なるデバイス名を使用したい場合は、コマンドにデバイス名を追加できます: incus storage volume attach incus storage volume attach -#### Attach the volume as a device +#### ボリュームをデバイスとしてアタッチする -The [`incus storage volume attach`](incus_storage_volume_attach.md) command is a shortcut for adding a disk device to an instance. -Alternatively, you can add a disk device for the storage volume in the usual way: +[`incus storage volume attach`](incus_storage_volume_attach.md) コマンドは、インスタンスにディスクデバイスを追加するためのショートカットです。 +もしくは、通常の方法でストレージボリュームのディスクデバイスを追加することもできます: incus config device add disk pool= source= [path=] -When using this way, you can add further configuration to the command if needed. -See {ref}`disk device ` for all available device options. +この方法を使用すると、必要に応じてコマンドに更なる設定を追加することができます。 +利用可能なすべてのデバイスオプションについては {ref}`ディスクデバイス ` を参照してください。 (storage-configure-IO)= -#### Configure I/O limits +#### I/O 制限値の設定 -When you attach a storage volume to an instance as a {ref}`disk device `, you can configure I/O limits for it. -To do so, set the `limits.read`, `limits.write` or `limits.max` properties to the corresponding limits. -See the {ref}`devices-disk` reference for more information. +ストレージボリュームをインスタンスに {ref}`ディスクデバイス ` としてアタッチする際に、 I/O 制限値を設定できます。 +そのためには `limits.read`, `limits.write`, `limits.max` に対応する制限値を設定します。 +詳細な情報は {ref}`devices-disk` レファレンスを参照してください。 -The limits are applied through the Linux `blkio` cgroup controller, which makes it possible to restrict I/O at the disk level (but nothing finer grained than that). +制限値は Linux の `blkio` cgroup コントローラー経由で適用されます。これによりディスクのレベルで I/O を制限することができます（しかしそれより細かい単位では制限できません）。 ```{note} -Because the limits apply to a whole physical disk rather than a partition or path, the following restrictions apply: +制限値はパーティションやパスではなく物理ディスク全体に適用されるため、以下の制約があります: -- Limits will not apply to file systems that are backed by virtual devices (for example, device mapper). -- If a file system is backed by multiple block devices, each device will get the same limit. -- If two disk devices that are backed by the same disk are attached to the same instance, the limits of the two devices will be averaged. +- 仮想デバイス（例えば device mapper）上に存在するファイルシステムには制限値は適用されません +- ファイルシステムが複数のブロックデバイス上に存在する場合、各デバイスは同じ制限を受けます。 +- 同じディスク上に存在する 2 つのディスクデバイスが同じインスタンスにアタッチされた場合は、 2 つのデバイスの制限値は平均されます ``` -All I/O limits only apply to actual block device access. -Therefore, consider the file system's own overhead when setting limits. -Access to cached data is not affected by the limit. +すべての I/O 制限値は実際のブロックデバイスアクセスにのみ適用されます。 +そのため、制限値を設定する際はファイルシステム自体のオーバーヘッドを考慮してください。 +キャッシュされたデータへのアクセスはこの制限値に影響されません。 (storage-volume-special)= -### Use the volume for backups or images +### バックアップやイメージにボリュームを使用する -Instead of attaching a custom volume to an instance as a disk device, you can also use it as a special kind of volume to store {ref}`backups ` or {ref}`images `. +カスタムボリュームをディスクデバイスとしてインスタンスにアタッチする代わりに、{ref}`バックアップ ` あるいは {ref}`イメージ ` を格納する特別な種類のボリュームとして使うこともできます。 -To do so, you must set the corresponding {ref}`server configuration `: +このためには、対応する{ref}`サーバー設定 `を設定する必要があります: -- To use a custom volume to store the backup tarballs: +- バックアップ tarball を保管するためにカスタムボリュームを使用する: incus config set storage.backups_volume / -- To use a custom volume to store the image tarballs: +- イメージ tarball を保管するためにカスタムボリュームを使用する: incus config set storage.images_volume / (storage-configure-volume)= -## Configure storage volume settings +## ストレージボリュームを設定する -See the {ref}`storage-drivers` documentation for the available configuration options for each storage driver. +各ストレージドライバーで利用可能な設定オプションについては {ref}`storage-drivers` ドキュメントを参照してください。 -Use the following command to set configuration options for a storage volume: +ストレージボリュームの設定オプションを設定するには以下のコマンドを使用します: incus storage volume set [/] -The default {ref}`storage volume type ` is `custom`, so you can leave out the `/` when configuring a custom storage volume. +{ref}`ストレージボリュームタイプ ` のデフォルトは `custom` ですので、カスタムストレージボリュームを設定する際は `/` は省略できます。 -For example, to set the size of your custom storage volume `my-volume` to 1 GiB, use the following command: +たとえば、カスタムストレージボリューム `my-volume` のサイズを 1 GiB に設定するには、以下のコマンドを使います: incus storage volume set my-pool my-volume size=1GiB -To set the snapshot expiry time for your virtual machine `my-vm` to one month, use the following command: +たとえば、仮想マシン `my-vm` のスナップショットの破棄期限を 1 ヶ月に設定するには以下のコマンドを使います: incus storage volume set my-pool virtual-machine/my-vm snapshots.expiry 1M -You can also edit the storage volume configuration by using the following command: +以下のコマンドでストレージボリューム設定を編集することもできます: incus storage volume edit [/] (storage-configure-vol-default)= -### Configure default values for storage volumes +### ストレージボリュームのデフォルト値を変更する -You can define default volume configurations for a storage pool. -To do so, set a storage pool configuration with a `volume` prefix, thus `volume.=`. +ストレージプールのデフォルトのボリューム設定を定義できます。 +そのためには、 `volume` 接頭辞をつけたストレージプール設定`volume.=` をセットします。 -This value is then used for all new storage volumes in the pool, unless it is set explicitly for a volume or an instance. -In general, the defaults set on a storage pool level (before the volume was created) can be overridden through the volume configuration, and the volume configuration can be overridden through the instance configuration (for storage volumes of {ref}`type ` `container` or `virtual-machine`). +新しいストレージボリュームまたはインスタンスに明示的に設定されない限り、この値はプール内のすべての新しいストレージボリュームに使用されます。 +一般的に、ストレージプールのレベルに設定されたデフォルト値は（ボリュームが作成される前であれば）ボリューム設定でオーバーライドでき、ボリューム設定はインスタンス設定（{ref}`タイプ ` が `container` か `virtual-machine` のストレージボリュームについて）でオーバーライドできます。 -For example, to set a default volume size for a storage pool, use the following command: +たとえば、ストレージプールにデフォルトのボリュームサイズを設定するには以下のコマンドを使用します: incus storage set [:] volume.size -## View storage volumes +## ストレージボリュームを表示する -You can display a list of all available storage volumes in a storage pool and check their configuration. +ストレージブール内のすべての利用可能なストレージボリュームを一覧表示しそれらの設定を確認できます。 -To list all available storage volumes in a storage pool, use the following command: +あるストレージプール内のすべての利用可能なストレージボリュームを一覧表示するには以下のコマンドを使用します: incus storage volume list -To display the storage volumes for all projects (not only the default project), add the `--all-projects` flag. +すべてのプロジェクト（デフォルトのプロジェクトだけでなく）ストレージボリュームを表示するには、 `--all-projects` フラグを追加してください。 -The resulting table contains the {ref}`storage volume type ` and the {ref}`content type ` for each storage volume in the pool. +結果の表にはそのプール内の各ストレージボリュームについて {ref}`ストレージボリュームタイプ ` と {ref}`コンテントタイプ ` が含まれます。 ```{note} -Custom storage volumes might use the same name as instance volumes (for example, you might have a container named `c1` with a container storage volume named `c1` and a custom storage volume named `c1`). -Therefore, to distinguish between instance storage volumes and custom storage volumes, all instance storage volumes must be referred to as `/` (for example, `container/c1` or `virtual-machine/vm`) in commands. +カスタムストレージボリュームはインスタンスボリュームと同じ名前を使うこともできます (例えば `c1` という名前のコンテナストレージボリュームと `c1` という名前のカスタムストレージボリュームを持つ `c1` という名前のコンテナを作成することもできます)。 +このため、インスタンスストレージボリュームとカスタムストレージボリュームを区別するには、全てのインタンスストレージボリュームは `/` (例えば `container/c1` または `virtual-machine/vm`) のようにコマンド内で指定する必要があります。 ``` -To show detailed configuration information about a specific volume, use the following command: +特定のカスタムボリュームについて詳細な情報を表示するには以下のコマンドを使用します: incus storage volume show [/] -To show state information about a specific volume, use the following command: +特定のインスタンスボリュームについて詳細な情報を表示するには以下のコマンドを使用します: incus storage volume info [/] -In both commands, the default {ref}`storage volume type ` is `custom`, so you can leave out the `/` when displaying information about a custom storage volume. +どちらのコマンドも、{ref}`ストレージボリュームタイプ ` のデフォルトは `custom` ですので、カスタムストレージボリュームの情報を表示する際は `/` は省略できます。 -## Resize a storage volume +## ストレージボリュームをリサイズする -If you need more storage in a volume, you can increase the size of your storage volume. -In some cases, it is also possible to reduce the size of a storage volume. +ボリュームにもっとストレージが必要な場合、ストレージボリュームのサイズを拡大できます。 +場合によっては、ストレージボリュームのサイズを縮小することもできます。 -To resize a storage volume, set its size configuration: +ストレージボリュームをリサイズするにはサイズ設定を設定します: incus storage volume set size ```{important} -- Growing a storage volume usually works (if the storage pool has sufficient storage). -- Shrinking a storage volume is only possible for storage volumes with content type `filesystem`. - It is not guaranteed to work though, because you cannot shrink storage below its current used size. -- Shrinking a storage volume with content type `block` is not possible. +- ストレージボリュームの拡大は通常は正常に動作します（ストレージプールが十分なストレージを持つ場合）。 +- ストレージボリュームの縮小はコンテントタイプ `filesystem` のストレージボリュームでのみ可能です。 + ただし現在使用しているサイズより小さく縮小はできないので、縮小が保証されているわけではありません。 +- コンテントタイプ `block` のストレージボリュームの縮小は不可能です。 ``` diff --git a/doc/image-handling.md b/doc/image-handling.md index 187a6c10ab5..0f57882f737 100644 --- a/doc/image-handling.md +++ b/doc/image-handling.md @@ -1,60 +1,61 @@ (about-images)= -# About images +# イメージについて -Incus uses an image-based workflow. -Each instance is based on an image, which contains a basic operating system (for example, a Linux distribution) and some Incus-related information. +Incus はイメージをベースとしたワークフローを使用します。 +各インスタンスはイメージをベースとしています。イメージは基礎となるオペレーティングシステム（たとえば、Linux ディストリビューション）と Incus に関連するいくつかの情報を含みます。 -Images are available from remote image stores (see {ref}`remote-image-servers` for an overview), but you can also create your own images, either based on an existing instances or a rootfs image. +イメージはリモートのイメージストア（概要は{ref}`remote-image-servers`参照）から利用可能ですが、既存のインスタンスや rootfs イメージをベースにして、独自のイメージを作成できます。 -You can copy images from remote servers to your local image store, or copy local images to remote servers. -You can also use a local image to create a remote instance. +リモートサーバーからローカルのイメージストアにイメージをコピーしたり、ローカルのイメージをリモートサーバーにコピーできます。 +ローカルのイメージをリモートのインスタンスを作るのに使うこともできます。 -Each image is identified by a fingerprint (SHA256). -To make it easier to manage images, Incus allows defining one or more aliases for each image. +各イメージはフィンガープリント（SHA256）で識別されます。 +イメージを管理しやすくするために、Incus では各イメージに 1 つ以上のエイリアスを定義できます。 -## Caching +## キャッシュ -When you create an instance using a remote image, Incus downloads the image and caches it locally. -It is stored in the local image store with the cached flag set. -The image is kept locally as a private image until either: +リモートのイメージからインスタンスを作成する際、Incus はイメージをダウンロードしローカルにキャッシュします。 +イメージはローカルのイメージストアに cached フラグをセットして保管されます。 +イメージは以下のいずれかが発生するまでは非公開のイメージとしてローカルに保持されます: -- The image has not been used to create a new instance for the number of days set in {config:option}`server-images:images.remote_cache_expiry`. -- The image's expiry date (one of the image properties; see {ref}`images-manage-edit` for information on how to change it) is reached. +- {config:option}`server-images:images.remote_cache_expiry` で指定された日数の間新しいインスタンスを作成するのにイメージが使われなかった。 +- イメージの有効期限（イメージのプロパティの 1 つ。どのように変更するかの情報は{ref}`images-manage-edit`参照）に達した。 -Incus keeps track of the image usage by updating the `last_used_at` image property every time a new instance is spawned from the image. +Incus はイメージから新しいインスタンスが起動される度にイメージの `last_used_at` プロパティを更新することで、イメージの利用状況を記録しています。 -## Auto-update +## 自動更新 -Incus can automatically keep images that come from a remote server up to date. +Incus はリモートサーバーからのイメージを自動的に最新に更新します。 ```{note} -Only images that are requested through an alias can be updated. -If you request an image through a fingerprint, you request an exact image version. +エイリアスを指定して取得したイメージだけが更新されます。 +フィンガープリントを指定してイメージを取得した場合は、その特定のイメージバージョンを要求したことになります。 ``` -Whether auto-update is enabled for an image depends on how the image was downloaded: +自動更新が有効になるかどうかはイメージをどのようにダウンロードしたかに依存します: -- If the image was downloaded and cached when creating an instance, it is automatically updated if {config:option}`server-images:images.auto_update_cached` was set to `true` (the default) at download time. -- If the image was copied from a remote server using the [`incus image copy`](incus_image_copy.md) command, it is automatically updated only if the `--auto-update` flag was specified. +- インスタンス作成時にイメージがダウンロードとキャッシュされた場合は、ダウンロード時に {config:option}`server-images:images.auto_update_cached` が `true` に設定されていれば、自動的に更新されます。 +- イメージがリモートサーバーから [`incus image copy`](incus_image_copy.md) コマンドでコピーされた場合は、`--auto-update`フラグが指定されていた場合のみ自動的に更新されます。 -You can change this behavior for an image by [editing the `auto_update` property](images-manage-edit). +イメージのこの挙動は [`auto_update` プロパティを編集](images-manage-edit) することで変更できます。 -On startup and after every {config:option}`server-images:images.auto_update_interval` (by default, every six hours), the Incus daemon checks for more recent versions of all the images in the store that are marked to be auto-updated and have a recorded source server. +起動時と [`images.auto_update_interval`](server-options-images) の間隔（デフォルトでは 6 時間ごと）を過ぎるたびに、Incus デーモンは自動更新とマークされコピー元のサーバーが記録されたストア内のすべてのイメージについてより新しいバージョンがあるかをチェックします。 -When a new version of an image is found, it is downloaded into the image store. -Then any aliases pointing to the old image are moved to the new one, and the old image is removed from the store. +新しいイメージが見つかったら、イメージ・ストアにダウンロードされます。 +その後古いイメージを指していたエイリアスは新しいイメージを指すように変更され、古いイメージはストアから削除されます。 -To not delay instance creation, Incus does not check if a new version is available when creating an instance from a cached image. -This means that the instance might use an older version of an image for the new instance until the image is updated at the next update interval. +インスタンスの生成が遅くならないようにするため、Incus はキャッシュされたイメージからインスタンスを作成する際に新しいバージョンが利用可能かをチェックしません。 +これはイメージが次の更新期間で更新されるまでの間は、新しく作成するインスタンスにイメージの古いバージョンが使われるかもしれないことを意味します。 -## Special image properties +## 特別なイメージプロパティ -Image properties that begin with the prefix `requirements` (for example, `requirements.XYZ`) are used by Incus to determine the compatibility of the host system and the instance that is created based on the image. -If these are incompatible, Incus does not start the instance. +プレフィックス`requirements`で始まるイメージプロパティ（たとえば、`requirements.XYZ`）は Incus がホストシステムと当該イメージで生成されるインスタンスの互換性を判断するために使用されます。 +これらの互換性がない場合には、Incus はそのインスタンスを起動しません。 -The following requirements are supported: +以下の要件がサポートされています: -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`requirements.secureboot` | string | - | If set to `false`, indicates that the image cannot boot under secure boot. -`requirements.cgroup` | string | - | If set to `v1`, indicates that the image requires the host to run cgroup v1. +キー | タイプ | 既定値 | 説明 +:-- | :--- | :------ | :---------- +`requirements.cgroup` | string | - | `v1` に設定されている場合、ホストで`CGroupV1`が実行されている必要があることを示します。 +`requirements.privileged` | bool | - | `false` に設定すると、イメージが特権コンテナで使えないことを示します。 +`requirements.secureboot` | bool | - | `false` に設定すると、イメージがセキュアブートで起動しないことを示します。 diff --git a/doc/images.md b/doc/images.md index 238c3918bb2..1f4dfe11be5 100644 --- a/doc/images.md +++ b/doc/images.md @@ -5,11 +5,11 @@ :maxdepth: 1 image-handling -Use remote images -Manage images -Copy and import images -Create images -Associate profiles +リモートイメージの使用 +イメージの管理 +イメージのコピーとインポート +イメージの作成 +プロファイルの関連付け reference/remote_image_servers reference/image_format ``` diff --git a/doc/index.md b/doc/index.md index 322c3ff7894..bb0cf851a02 100644 --- a/doc/index.md +++ b/doc/index.md @@ -1,8 +1,6 @@ # Incus -(日本語訳準備中) - -Incus is a modern, secure and powerful system container and virtual machine manager. +Incus は次世代の安全で強力なシステムコンテナおよび仮想マシンマネージャーです。 % Include content from [../README.md](../README.md) ```{include} ../README.md @@ -10,7 +8,7 @@ Incus is a modern, secure and powerful system container and virtual machine mana :end-before: ``` -## Security +## セキュリティー % Include content from [../README.md](../README.md) ```{include} ../README.md @@ -18,7 +16,7 @@ Incus is a modern, secure and powerful system container and virtual machine mana :end-before: ``` -See [Security](security.md) for detailed information. +詳細は[セキュリティ](security.md)をご覧ください。 ````{important} % Include content from [../README.md](../README.md) @@ -28,37 +26,30 @@ See [Security](security.md) for detailed information. ``` ```` -## Project and community +## プロジェクトとコミュニティ -Incus is free software and developed under the [Apache 2 license](https://www.apache.org/licenses/LICENSE-2.0). -It’s an open source project that warmly welcomes community projects, contributions, suggestions, fixes and constructive feedback. +Incus はフリーソフトウェアであり [Apache 2 ライセンス](https://www.apache.org/licenses/LICENSE-2.0) で開発されています。 +これはコミュニティのプロジェクト、コントリビューション、提案、修正、建設的なフィードバックを温かく迎えるオープンソースプロジェクトです。 -- [Code of Conduct](https://github.com/lxc/incus/blob/main/CODE_OF_CONDUCT.md) -- [Contribute to the project](contributing.md) -- [Release announcements](https://discuss.linuxcontainers.org/c/news/13) -- [Release tarballs](https://github.com/lxc/incus/releases/) -- [Get support](support.md) -- [Watch tutorials and announcements on YouTube](https://www.youtube.com/@TheZabbly) -- [Discuss on IRC](https://web.libera.chat/#lxc) (see [Getting started with IRC](https://discuss.linuxcontainers.org/t/getting-started-with-irc/11920) if needed) -- [Ask and answer questions on the forum](https://discuss.linuxcontainers.org) +- [Code of Conduct](https://github.com/lxc-jp/incus-ja/blob/main/CODE_OF_CONDUCT.md) ```{toctree} :hidden: :titlesonly: self -Getting Started -General -Client -Server -Instances -Storage -Networks -Images -Projects -Clustering +使い始めるには +概要 +クライアント +サーバ +インスタンス +ストレージ +ネットワーク +イメージ +プロジェクト +クラスタリング API -Security -Internals -External resources +セキュリティ +内部動作 +外部リソース ``` diff --git a/doc/installing.md b/doc/installing.md index 314ecafe6fc..2dc59d80deb 100644 --- a/doc/installing.md +++ b/doc/installing.md @@ -1,13 +1,13 @@ (installing)= -# How to install Incus +# Incusをインストールするには -The easiest way to install Incus is to {ref}`install one of the available packages `, but you can also {ref}`install Incus from the sources `. +Incus をインストールする最も簡単な方法は{ref}`利用可能なパッケージの1つをインストール `ですが、{ref}`ソースからIncusをインストール `も可能です。 -After installing Incus, make sure you have an `incus-admin` group on your system. -Users in this group can interact with Incus. -See {ref}`installing-manage-access` for instructions. +Incus をインストールしたら、システム上に`incus-admin`グループが存在することを確認してください。 +このグループのユーザーが Incus を操作できます。 +手順は{ref}`installing-manage-access`を参照してください。 -## Choose your release +## リリースを選択する % Include content from [support.md](support.md) ```{include} support.md @@ -15,153 +15,152 @@ See {ref}`installing-manage-access` for instructions. :end-before: ``` -LTS releases are recommended for production environments, because they benefit from regular bugfix and security updates. -However, there are no new features added to an LTS release, nor any kind of behavioral change. +本番環境には LTS を推奨します。通常のバグフィクスとセキュリティーアップデートの恩恵を受けられるからです。 +しかし、長期リリースには新しい機能はやどんな種類の挙動の変更も追加されません。 -To get all the latest features and monthly updates to Incus, use the feature release branch instead. +Incus の最新の機能と毎月の更新を得るには、代わりに機能リリースを使ってください。 (installing-from-package)= -## Install Incus from a package +## Incusをパッケージからインストールする -The Incus daemon only works on Linux. -The client tool ([`incus`](incus.md)) is available on most platforms. +Incus デーモンは Linux でのみ稼働します。 +クライアントツール（[`incus`](incus.md)）はほとんどのプラットフォームで利用できます。 ### Linux -The easiest way to install Incus on Linux is to install the {ref}`installing-zabbly-package`, which is available for both Debian and Ubuntu. +Linux で Incus をインストールする最も簡単な方法は{ref}`installing-zabbly-package`です。これは Debian と Ubuntu で利用できます。 (installing-zabbly-package)= -#### Debian and Ubuntu package from Zabbly -Currently the easiest way to install Incus is to use the Debian or Ubuntu packages provided by [Zabbly](https://zabbly.com). -There are two repositories available, one for the current stable release and one for daily (untested) builds. +#### ZabblyのDebianとUbuntuパッケージをインストールする +現時点では Incus をインストールする最も簡単な方法は[Zabbly](https://zabbly.com)で提供される Debian または Ubuntu のパッケージを使うことです。 +最新の安定版リリースと（テストされていない）デイリービルドの 2 つのリポジトリがあります。 -Installation instructions may be found here: [`https://github.com/zabbly/incus`](https://github.com/zabbly/incus) +インストール手順は[`https://github.com/zabbly/incus`](https://github.com/zabbly/incus)にあります。 -If you prefer a different installation method, see {ref}`installing`. +他のインストール方法については{ref}`installing`を参照してください。 -1. Allow your user to control Incus +1. あなたのユーザーに Incus を制御する許可を与えます。 - Access to Incus in the packages above is controlled through two groups: + 上記のパッケージに含まれる Incus へのアクセスは 2 つのグループで制御されます。 - - `incus` allows basic user access, no configuration and all actions restricted to a per-user project. - - `incus-admin` allows full control over Incus. + - `incus`は基本的なユーザーアクセスを許可します。設定はできずすべてのアクションはユーザーごとのプロジェクトに限定されます。 + - `incus-admin`は Incus の完全なコントロールを許可します。 - To control Incus without having to run all commands as root, you can add yourself to the `incus-admin` group: + すべてのコマンドを root で実行することなく Incus を制御するには、あなた自身を`incus-admin`グループに追加してください。 sudo adduser YOUR-USERNAME incus-admin newgrp incus-admin - The `newgrp` step is needed in any terminal that interacts with Incus until you restart your user session. + `newgrp`の手順はあなたの端末セッションを再起動しないままで Incus を利用する場合に必要です（訳注：端末を起動し直す場合は不要です）。 -1. Initialize Incus with: +1. Incus を初期化します。 incus admin init --minimal - This will create a minimal setup with default options. - If you want to tune the initialization options, see {ref}`initialize` for more information. + この手順はフォルトのオプションで最小セットアップの構成を作成します。 + 初期化オプションをチューニングしたい場合、詳細は{ref}`initialize`を参照してください。 -### Other operating systems +### 他のOS ```{important} -The builds for other operating systems include only the client, not the server. +他のOS用のビルドはクライアントのみを含み、サーバは含みません。 ``` ````{tabs} ```{group-tab} macOS -Incus publishes builds of the Incus client for macOS through [Homebrew](https://brew.sh/). +IncusはmacOSのIncusクライアントのビルドを[Homebrew](https://brew.sh/)で公開しています。 -To install the feature branch of Incus, run: +機能リリースのIncusをインストールするには、以下のようにします。 brew install incus ``` ```{group-tab} Windows -The Incus client on Windows is provided as a [Chocolatey](https://community.chocolatey.org/packages/lxc) package. -To install it: +Windows版のIncusクライアントは[Chocolatey](https://community.chocolatey.org/packages/incus)パッケージとして提供されています。 +インストールするためには以下のようにします。 -1. Install Chocolatey by following the [installation instructions](https://docs.chocolatey.org/en-us/choco/setup). -1. Install the Incus client: +1. [インストール手順](https://docs.chocolatey.org/en-us/choco/setup)に従ってChocolateyをインストールします。 +1. Incusクライアントをインストールします。 choco install incus ``` ```` -You can also find native builds of the Incus client on [GitHub](https://github.com/lxc/incus/actions). -To download a specific build: +[GitHub](https://github.com/lxc/incus/actions)にも Incus クライアントのネイティブビルドがあります。 +特定のビルドをダウンロードするには以下のようにします。 -1. Make sure that you are logged into your GitHub account. -1. Filter for the branch or tag that you are interested in (for example, the latest release tag or `main`). -1. Select the latest build and download the suitable artifact. +1. GitHub アカウントにログインします。 +1. 興味のあるブランチやタグ(たとえば、最新のリリースタグあるいは`main`)でフィルタリングします。 +1. 最新のビルドを選択し、適切なアーティファクトをダウンロードします。 (installing_from_source)= -## Install Incus from source +## Incusをソースからインストールする -Follow these instructions if you want to build and install Incus from the source code. +Incus をソースコードからビルドとインストールしたい場合、以下の手順に従ってください。 -We recommend having the latest versions of `liblxc` (>= 4.0.0 required) -available for Incus development. Additionally, Incus requires Golang 1.18 or -later to work. On Ubuntu, you can get those with: +Incus の開発には`liblxc`の最新バージョン（4.0.0 以上が必要）を使用することをお勧めします。 +さらに Incus が動作するためには Golang 1.18 以上が必要です。 +Ubuntu では次のようにインストールできます。 ```bash 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 ``` -There are a few storage drivers for Incus besides the default `dir` driver. -Installing these tools adds a bit to initramfs and may slow down your -host boot, but are needed if you'd like to use a particular driver: +デフォルトのストレージドライバーである`dir`ドライバーに加えて、Incus ではいくつかのストレージドライバーが使えます。 +これらのツールをインストールすると、initramfs への追加が行われ、ホストのブートが少しだけ遅くなるかもしれませんが、特定のドライバーを使いたい場合には必要です。 ```bash sudo apt install lvm2 thin-provisioning-tools sudo apt install btrfs-progs ``` -To run the test suite, you'll also need: +テストスイートを実行するには、次のパッケージも必要です。 ```bash sudo apt install busybox-static curl gettext jq sqlite3 socat bind9-dnsutils ``` -### From source: Build the latest version +### ソースから最新版をビルドする -These instructions for building from source are suitable for individual developers who want to build the latest version -of Incus, or build a specific release of Incus which may not be offered by their Linux distribution. Source builds for -integration into Linux distributions are not covered here and may be covered in detail in a separate document in the -future. +この方法は Incus の最新版をビルドしたい開発者や Linux ディストリビューションで提供されない Incus の特定のリリースをビルドするためのものです。 +Linux ディストリビューションへ統合するためのソースからのビルドはここでは説明しません。 +それは将来、別のドキュメントで取り扱うかもしれません。 ```bash git clone https://github.com/lxc/incus cd incus ``` -This will download the current development tree of Incus and place you in the source tree. -Then proceed to the instructions below to actually build and install Incus. +これで Incus の現在の開発ツリーをダウンロードしてソースツリー内に移動します。 +その後下記の手順にしたがって実際に Incus をビルド、インストールしてください。 -### From source: Build a release +### ソースからリリース版をビルドする -The Incus release tarballs bundle a complete dependency tree as well as a -local copy of `libraft` and `libcowsql` for Incus' database setup. +Incus のリリース tarball は完全な依存ツリーと`libraft`と Incus データベースのセットアップに使用する`libcowsql`のローカルコピーをバンドルしています。 ```bash tar zxvf incus-0.1.tar.gz cd incus-0.1 ``` -This will unpack the release tarball and place you inside of the source tree. -Then proceed to the instructions below to actually build and install Incus. +これでリリース tarball を展開し、ソースツリー内に移動します。 +その後下記の手順にしたがって実際に Incus をビルド、インストールしてください。 -### Start the build +### ビルドを開始する -The actual building is done by two separate invocations of the Makefile: `make deps` -- which builds libraries required -by Incus -- and `make`, which builds Incus itself. At the end of `make deps`, a message will be displayed which will specify environment variables that should be set prior to invoking `make`. As new versions of Incus are released, these environment -variable settings may change, so be sure to use the ones displayed at the end of the `make deps` process, as the ones -below (shown for example purposes) may not exactly match what your version of Incus requires: +実際のビルドは Makefile の 2 回の別々の実行により行われます。 +一つは`make deps`でこれは Incus に必要とされるライブラリをビルドします。 +もう一つは`make`で Incus 自体をビルドします。 +`make deps`の最後に`make`の実行に必要な環境変数を設定するための手順が表示されます。 +新しいバージョンの Incus がリリースされたらこれらの環境変数の設定は変わるかもしれませんので、`make deps`の最後に表示された手順を使うようにしてください。 +下記の手順（例示のために表示します）はあなたがビルドする Incus のバージョンのものとは一致しないかもしれません。 -We recommend having at least 2GiB of RAM to allow the build to complete. +ビルドには最低 2GiB の RAM を搭載することを推奨します。 ```{terminal} :input: make deps @@ -178,50 +177,47 @@ Please set the following in your environment (possibly ~/.bashrc) :input: make ``` -### From source: Install +### ソースからのビルド結果のインストール -Once the build completes, you simply keep the source tree, add the directory referenced by `$(go env GOPATH)/bin` to -your shell path, and set the `LD_LIBRARY_PATH` variable printed by `make deps` to your environment. This might look -something like this for a `~/.bashrc` file: +ビルドが完了したら、ソースツリーを維持したまま、あなたのお使いのシェルのパスに`$(go env GOPATH)/bin`を追加し、`LD_LIBRARY_PATH`環境変数を`make deps`で表示された値に設定します。これは`~/.bashrc`ファイルの場合は以下のようになります。 ```bash export PATH="${PATH}:$(go env GOPATH)/bin" export LD_LIBRARY_PATH="$(go env GOPATH)/deps/cowsql/.libs/:$(go env GOPATH)/deps/raft/.libs/:${LD_LIBRARY_PATH}" ``` -Now, the `incusd` and `incus` binaries will be available to you and can be used to set up Incus. The binaries will automatically find and use the dependencies built in `$(go env GOPATH)/deps` thanks to the `LD_LIBRARY_PATH` environment variable. +これで`incusd`と`incus`コマンドの実行ファイルが利用可能になり Incus をセットアップするのに使用できます。 +`LD_LIBRARY_PATH`環境変数のおかげで実行ファイルは`$(go env GOPATH)/deps`にビルドされた依存ライブラリを自動的に見つけて使用します。 -### Machine setup +### マシンセットアップ -You'll need sub{u,g}ids for root, so that Incus can create the unprivileged containers: +Incus が非特権コンテナを作成できるように、root ユーザーに対する sub{u,g}id の設定が必要です。 ```bash echo "root:1000000:1000000000" | sudo tee -a /etc/subuid /etc/subgid ``` -Now you can run the daemon (the `--group sudo` bit allows everyone in the `sudo` -group to talk to Incus; you can create your own group if you want): +これでデーモンを実行できます(`sudo`グループに属する全員が Incus とやりとりできるように `--group sudo` を指定します。別に指定したいグループを作ることもできます)。 ```bash sudo -E PATH=${PATH} LD_LIBRARY_PATH=${LD_LIBRARY_PATH} $(go env GOPATH)/bin/incus --group sudo ``` ```{note} -If `newuidmap/newgidmap` tools are present on your system and `/etc/subuid`, `etc/subgid` exist, they must be configured to allow the root user a contiguous range of at least 10M UID/GID. +`newuidmap/newgidmap`ツールがシステムに存在し、`/etc/subuid`、`/etc/subgid`が存在する場合は、rootユーザーに少なくとも10MのUID/GIDの連続した範囲を許可するように設定する必要があります。 ``` (installing-manage-access)= -## Manage access to Incus +## Incusへのアクセスを管理する -Access control for Incus is based on group membership. -The root user and all members of the `incus-admin` group can interact with the local daemon. -See {ref}`security-daemon-access` for more information. +Incus のアクセス制御はグループのメンバーシップに基づいています。 +root ユーザーと`incus-admin`グループのすべてのメンバーはローカルデーモンとやりとりできます。 +詳細は{ref}`security-daemon-access`を参照してください。 -If the `incus-admin` group is missing on your system, create it and restart the Incus daemon. -You can then add trusted users to the group. -Anyone added to this group will have full control over Incus. +お使いのシステムに`incus-admin`グループが存在しない場合は、作成して Incus デーモンを再起動してください。 +このグループに追加されたメンバーは Incus の完全な制御ができます。 -Because group membership is normally only applied at login, you might need to either re-open your user session or use the `newgrp incus-admin` command in the shell you're using to talk to Incus. +グループのメンバーシップは通常ログイン時にのみ適用されますので、セッションを開き直すか、Incus とやりとりするシェル上で`newgrp incus-admin`コマンドを実行する必要があります。 ````{important} % Include content from [../README.md](../README.md) @@ -232,15 +228,15 @@ Because group membership is normally only applied at login, you might need to ei ```` (installing-upgrade)= -## Upgrade Incus +## Incusをアップグレードする -After upgrading Incus to a newer version, Incus might need to update its database to a new schema. -This update happens automatically when the daemon starts up after a Incus upgrade. -A backup of the database before the update is stored in the same location as the active database (at `/var/lib/incus/database`). +Incus を新しいバージョンにアップグレードした後、Incus はデータベースを新しいスキーマにアップデートする必要があるかもしれません。 +このアップデートは Incus のアップグレードの後のデーモン起動時に自動的に実行されます。 +アップデート前のデータベースのバックアップはアクティブなデータベースと同じ場所（`/var/lib/incus/database`）に保存されます。 ```{important} -After a schema update, older versions of Incus might regard the database as invalid. -That means that downgrading Incus might render your Incus installation unusable. +スキーマのアップデート後は、古いバージョンのIncusはデータベースを無効とみなすかもしれません。 +これはつまりIncusをダウングレードしてもあなたのIncusの環境は利用不可能と言われるかもしれないということです。 -In that case, if you need to downgrade, restore the database backup before starting the downgrade. +このようなダウングレードが必要な場合は、ダウングレードを行う前にデータベースのバックアップをリストアしてください。 ``` diff --git a/doc/instance-exec.md b/doc/instance-exec.md index fc009d539ad..59d6b40c06d 100644 --- a/doc/instance-exec.md +++ b/doc/instance-exec.md @@ -1,73 +1,73 @@ (run-commands)= -# How to run commands in an instance +# インスタンス内でコマンドを実行するには -Incus allows to run commands inside an instance using the Incus client, without needing to access the instance through the network. +Incus では、ネットワークを経由してインスタンスにアクセスする必要なしに、Incus クライアントを使用してインスタンス内でコマンドを実行できます。 -For containers, this always works and is handled directly by Incus. -For virtual machines, the `incus-agent` process must be running inside of the virtual machine for this to work. +コンテナでは、これは常に機能し、Incus によって直接処理されます。 +仮想マシンでは、これが機能するには、仮想マシン内で `incus-agent` プロセスが稼働している必要があります。 -To run commands inside your instance, use the [`incus exec`](incus_exec.md) command. -By running a shell command (for example, `/bin/bash`), you can get shell access to your instance. +インスタンス内部でコマンドを実行するには [`incus exec`](incus_exec.md) コマンドを使います。 +シェルコマンド（たとえば `/bin/bash`）を実行することで、インスタンスにシェルアクセスできます。 -## Run commands inside your instance +## インスタンス内部でコマンドを実行する -To run a single command from the terminal of the host machine, use the [`incus exec`](incus_exec.md) command: +ホストマシンの端末から単一のコマンドを実行するには、[`incus exec`](incus_exec.md) コマンドを使います: incus exec -- -For example, enter the following command to update the package list on your container: +たとえば、コンテナ上のパッケージリストを更新するには以下のコマンドを入力します: incus exec ubuntu-container -- apt-get update -### Execution mode +### 実行モード -Incus can execute commands either interactively or non-interactively. +Incus はコマンドをインタラクティブにも非インタラクティブにも実行できます。 -In interactive mode, a pseudo-terminal device (PTS) is used to handle input (stdin) and output (stdout, stderr). -This mode is automatically selected by the CLI if connected to a terminal emulator (and not run from a script). -To force interactive mode, add either `--force-interactive` or `--mode interactive` to the command. +インタラクティブモードでは、入力（stdin）と出力（stdout, stderr）を扱うために疑似端末装置（PTS）が使用されます。 +これは、ターミナル・エミュレータに接続されている場合（スクリプトから実行されていない場合）、CLI によって自動的に選択されます。 +インタラクティブ・モードを強制するには、`--force-interactive`か`--mode interactive`をコマンドに追加します。 -In non-interactive mode, pipes are allocated instead (one for each of stdin, stdout and stderr). -This method allows running a command and properly getting separate stdin, stdout and stderr as required by many scripts. -To force non-interactive mode, add either `--force-noninteractive` or `--mode non-interactive` to the command. +非インタラクティブ・モードでは、代わりにパイプが (stdin、stdout、stderr のそれぞれに 1 つずつ) 割り当てられます。 +これにより、多くのスクリプトで必要とされるように、コマンドを実行しながら、stdin、stdout、stderr を別々に適切に取得することができます。 +非インタラクティブ・モードを強制するには、`--force-noninteractive`か`--mode non-interactive`をコマンドに追加します。 -### User, groups and working directory +### ユーザー、グループ、作業ディレクトリー -Incus has a policy not to read data from within the instances or trust anything that can be found in the instance. -Therefore, Incus does not parse files like `/etc/passwd`, `/etc/group` or `/etc/nsswitch.conf` to handle user and group resolution. +Incus はインスタンス内のデータを読まない、あるいはその中にあるものを信用しないというポリシーを持っています。 +これは、Incus がユーザーやグループの解決を処理するために、`/etc/passwd`、`/etc/group`や`/etc/nsswitch.conf`のようなものを解析しないことを意味しています。 -As a result, Incus doesn't know the home directory for the user or the supplementary groups the user is in. +結果として、Incus はユーザーのホームディレクトリーがどこにあるか、あるいはどのような補助的なグループがあるかを知りません。 -By default, Incus runs commands as `root` (UID 0) with the default group (GID 0) and the working directory set to `/root`. -You can override the user, group and working directory by specifying absolute values through the following flags: +デフォルトでは、Incus は root（UID 0）、デフォルトのグループ（GID 0）としてコマンドを実行し、作業ディレクトリーは`/root`に設定されています。 +ユーザー、グループ、作業ディレクトリーは以下のフラグによって上書きできます。 -- `--user` - the user ID for running the command -- `--group` - the group ID for running the command -- `--cwd` - the directory in which the command should run +- `--user` - コマンドを実行するユーザー ID +- `--group` - コマンドを実行するグループ ID +- `--cwd` - コマンドを実行するディレクトリー -### Environment +### 環境 -You can pass environment variables to an exec session in the following two ways: +以下の 2 つの方法で exec セッションに環境変数を渡せます。 -Set environment variables as instance options -: To set the `ENVVAR` environment variable to `VALUE` in the instance, set the `environment.ENVVAR` instance option (see {config:option}`instance-miscellaneous:environment.*`): +インスタンスオプションとして環境変数を渡す +: インスタンス内で`ENVVAR`環境変数を`VALUE`に設定するには、`environment.ENVVAR`インスタンスオプション を設定します（{config:option}`instance-miscellaneous:environment.*`参照）: - incus config set environment.ENVVAR=VALUE + lxc config set environment.ENVVAR=VALUE -Pass environment variables to the exec command -: To pass an environment variable to the exec command, use the `--env` flag. - For example: +exec コマンドに環境変数を渡す +: exec コマンドに環境変数を渡すには、`--env`フラグを使います。 + たとえば以下のようにします: incus exec --env ENVVAR=VALUE -- -In addition, Incus sets the following default values (unless they are passed in one of the ways described above): +さらに、Incus は (上記のいずれかの方法で渡されない限り) 以下のデフォルト値を設定します: ```{list-table} :header-rows: 1 -* - Variable name - - Condition - - Value +* - 変数名 + - 条件 + - 値 * - `PATH` - \- - Concatenation of: @@ -90,20 +90,20 @@ In addition, Incus sets the following default values (unless they are passed in - `root` ``` -## Get shell access to your instance +## インスタンスにシェルアクセスする -If you want to run commands directly in your instance, run a shell command inside it. -For example, enter the following command (assuming that the `/bin/bash` command exists in your instance): +インスタンス内で直接コマンドを実行したい場合、インスタンス内でシェルコマンドを実行します。 +たとえば、以下のコマンド（インスタンス内に`/bin/bash`コマンドが存在する想定）を入力します。 - incus exec -- /bin/bash + lxc exec -- /bin/bash -By default, you are logged in as the `root` user. -If you want to log in as a different user, enter the following command: +デフォルトでは`root`ユーザーでログインします。 +別のユーザーでログインしたい場合は、以下のコマンドを入力します: - incus exec -- su --login + lxc exec -- su --login ```{note} -Depending on the operating system that you run in your instance, you might need to create a user first. +インスタンス内で稼働しているオペレーティングシステムによっては、先にユーザを作成する必要があるかもしれません。 ``` -To exit the instance shell, enter `exit` or press `Ctrl`+`d`. +インスタンスシェルを終了するには、`exit`を入力するか`Ctrl`+`d`を押します。 diff --git a/doc/instances.md b/doc/instances.md index 453bb4f018e..b0bd3ab6a8a 100644 --- a/doc/instances.md +++ b/doc/instances.md @@ -5,18 +5,18 @@ :titlesonly: explanation/instances.md -Create instances -Manage instances -Configure instances -Back up instances -Use profiles -Use cloud-init -Run commands -Access the console -Access files -Add a routed NIC to a VM -Troubleshoot errors +インスタンスの作成 +インスタンスの管理 +インスタンスの設定 +インスタンスのバックアップ +プロファイルの使用 +cloud-initの使用 +コマンドの実行 +コンソールへのアクセス +ファイルへのアクセス +VMにrouted NICを追加 +エラーのトラブルシューティング explanation/instance_config.md -Container environment +コンテナ実行環境 migration ``` diff --git a/doc/internals.md b/doc/internals.md index af80c72278d..4a693cdaeb2 100644 --- a/doc/internals.md +++ b/doc/internals.md @@ -1,13 +1,14 @@ -# Internals & debugging +# 内部動作とデバッグ ```{toctree} :maxdepth: 1 daemon-behavior -Debug Incus -Requirements +Incus のデバッグ +動作環境 +パッケージ作成の推奨 environment syscall-interception -User namespace setup -Configuration option index +User Namespace の設定 +設定オプション一覧 ``` diff --git a/doc/metrics.md b/doc/metrics.md index 734435421eb..4f9a1bde716 100644 --- a/doc/metrics.md +++ b/doc/metrics.md @@ -1,23 +1,21 @@ (metrics)= -# How to monitor metrics +# メトリクスを監視するには -Incus collects metrics for all running instances as well as some internal metrics. -These metrics cover the CPU, memory, network, disk and process usage. -They are meant to be consumed by Prometheus, and you can use Grafana to display the metrics as graphs. -See {ref}`provided-metrics` for lists of available metrics. +Incus はすべての実行中のインスタンスについてのメトリクスといくつかの内部メトリクスを収集します。 +これは CPU、メモリー、ネットワーク、ディスク、プロセスの使用量を含みます。 +Prometheus で読み取って Grafana でグラフを表示するのに使うことを想定しています。 +利用可能なメトリクスの一覧は{ref}`provided-metrics`を参照してください。 -In a cluster environment, Incus returns only the values for instances running on the server that is being accessed. -Therefore, you must scrape each cluster member separately. +クラスタ環境では、 Incus はアクセスされているサーバー上で稼働中のインスタンスの値だけを返します。ですので、各クラスタメンバーから別々にデータを取得する必要があります。。 -The instance metrics are updated when calling the `/1.0/metrics` endpoint. -To handle multiple scrapers, they are cached for 8 seconds. -Fetching metrics is a relatively expensive operation for Incus to perform, so if the impact is too high, consider scraping at a higher than default interval. +インスタンスメトリクスは `/1.0/metrics` エンドポイントを呼ぶと更新されます。 +複数のスクレイパーに対応するためメトリクスは 8 秒キャッシュします。メトリクスの取得は比較的重い処理ですので、影響が大きすぎるようならデフォルトの間隔より長い間隔でスクレイピングすることを検討してください。 -## Query the raw data +## 生データを取得する -To view the raw data that Incus collects, use the [`incus query`](incus_query.md) command to query the `/1.0/metrics` endpoint: +Incus が収集した生データを見るには、`1.0/metrics` エンドポイントに [`incus query`](incus_query.md) コマンドで問い合わせてください。 ```{terminal} :input: incus query /1.0/metrics @@ -45,87 +43,87 @@ incus_disk_read_bytes_total{device="loop3",name="vm",project="default",type="vir ... ``` -## Set up Prometheus +## Prometheusをセットアップする -To gather and store the raw metrics, you should set up [Prometheus](https://prometheus.io/). -You can then configure it to scrape the metrics through the metrics API endpoint. +生のメトリクスを収集し保管するには、[Prometheus](https://prometheus.io/)をセットアップするのが良いです。 +メトリクス API エンドポイントを使ってメトリクスを収集するように設定できます。 -### Expose the metrics endpoint +### メトリクスエンドポイントを公開する -To expose the `/1.0/metrics` API endpoint, you must set the address on which it should be available. +`/1.0/metrics` API エンドポイントを公開するには、利用可能にするアドレスを設定する必要があります。 -To do so, you can set either the {config:option}`server-core:core.metrics_address` server configuration option or the {config:option}`server-core:core.https_address` server configuration option. -The `core.metrics_address` option is intended for metrics only, while the `core.https_address` option exposes the full API. -So if you want to use a different address for the metrics API than for the full API, or if you want to expose only the metrics endpoint but not the full API, you should set the `core.metrics_address` option. +そのためには、{config:option}`server-core:core.metrics_address`サーバー設定オプションか{config:option}`server-core:core.https_address`サーバー設定オプションのいずれかを設定できます。 +`core.metrics_address`オプションはメトリクスのみを公開し、`core.https_address`は完全な API を公開します。 +ですので、完全な API とメトリクスの API で別のアドレスを使いたい場合、あるいはメトリクスの API のみ公開し完全な API は公開したくない場合は`core.metrics_address`オプションを設定するのが良いです。 -For example, to expose the full API on the `8443` port, enter the following command: +たとえば、完全な API を`8443`ポートで公開するには、次のコマンドを入力します: incus config set core.https_address ":8443" -To expose only the metrics API endpoint on the `8444` port, enter the following command: +メトリクス API エンドポイントのみを`8444`ポートで公開するには、次のコマンドを入力します: incus config set core.metrics_address ":8444" -To expose only the metrics API endpoint on a specific IP address and port, enter a command similar to the following: +メトリクス API エンドポイントのみを指定した IP アドレスとポートで公開するには、次のようなコマンドを入力します: incus config set core.metrics_address "192.0.2.101:8444" -### Add a metrics certificate to Incus +### メトリクス用証明書の追加 -Authentication for the `/1.0/metrics` API endpoint is done through a metrics certificate. -A metrics certificate (type `metrics`) is different from a client certificate (type `client`) in that it is meant for metrics only and doesn't work for interaction with instances or any other Incus entities. +`/1.0/metrics` API エンドポイントの認証はメトリクス証明書で行われます。 +メトリクス証明書（タイプが`metrics`）は、メトリクス専用でインスタンスや他の Incus のエンティティの操作には使用できないという点でクライアント証明書（タイプが`client`）とは異なります。 -To create a certificate, enter the following command: +新しい証明書は以下のように作成します: openssl req -x509 -newkey ec -pkeyopt ec_paramgen_curve:secp384r1 -sha384 -keyout metrics.key -nodes -out metrics.crt -days 3650 -subj "/CN=metrics.local" ```{note} -The command requires OpenSSL version 1.1.0 or later. +上のコマンドは OpenSSL 1.1.0以降が必要です。 ``` -Then add this certificate to the list of trusted clients, specifying the type as `metrics`: +作成後、証明書を信頼済みクライアントのリストに`metrics`というタイプを指定して追加する必要があります: incus config trust add metrics.crt --type=metrics -If requiring TLS client authentication isn't possible in your environment, the `/1.0/metrics` API endpoint can be made available to unauthenticated clients. -While not recommended, this might be acceptable if you have other controls in place to restrict who can reach that API endpoint. To disable the authentication on the metrics API: +あなたの環境で TLS クライアント証明書を要求することができない場合、`/1.0/metrics` API エンドポイントを認証されていないクライアントで利用可能にできます。 +お勧めはしませんが、API エンドポイントに誰がアクセスできるかを別の手段で制御できるのであれば許容できるかもしれません。メトリクス API の認証を無効にするには以下のようにします: ```bash # Disable authentication (NOT RECOMMENDED) incus config set core.metrics_authentication false ``` -### Make the metrics certificate available for Prometheus +### メトリクス用証明書をPrometheusで利用可能にする -If you run Prometheus on a different machine than your Incus server, you must copy the required certificates to the Prometheus machine: +Prometheus を Incus サーバーと別のマシンで稼働させる場合、必要な証明書を Prometheus のマシンにコピーする必要があります。 -- The metrics certificate (`metrics.crt`) and key (`metrics.key`) that you created -- The Incus server certificate (`server.crt`) located in `/var/lib/incus/` +- 作成したメトリクス用証明書（`metrics.crt`）と鍵（`metrics.key`） +- `/var/lib/incus/`に置かれている Incus サーバー証明書（`server.crt`） -Copy these files into a `tls` directory that is accessible to Prometheus, for example, `/etc/prometheus/tls`. -See the following example commands: +これらのファイルを Prometheus からアクセスできる`tls`ディレクトリー、たとえば、`/etc/prometheus/tls`にコピーしてください。 +次の例のコマンドを参照してください: ```bash -# Create tls directory +# tls ディレクトリーを作成 mkdir /etc/prometheus/tls/ -# Copy newly created certificate and key to tls directory +# 新規に作成された証明書と鍵を tls ディレクトリーにコピー cp metrics.crt metrics.key /etc/prometheus/tls/ -# Copy Incus server certificate to tls directory +# Incus サーバー証明書を tls ディレクトリーにコピー cp /var/lib/incus/server.crt /etc/prometheus/tls/ -# Make the files accessible by prometheus +# ファイルを Prometheus からアクセス可能にします chown -R prometheus:prometheus /etc/prometheus/tls ``` -### Configure Prometheus to scrape from Incus +### PrometheusをIncusからデータ収集できるように設定する -Finally, you must add Incus as a target to the Prometheus configuration. +最後に、 Incus をターゲットとして Prometheus の設定に追加する必要があります。 -To do so, edit `/etc/prometheus/prometheus.yaml` and add a job for Incus. +そのためには、`/etc/prometheus/prometheus.yaml`を編集し、Incus にジョブを追加します。 -Here's what the configuration needs to look like: +必要な設定は以下のようになります: ```yaml scrape_configs: @@ -138,16 +136,16 @@ scrape_configs: ca_file: 'tls/server.crt' cert_file: 'tls/metrics.crt' key_file: 'tls/metrics.key' - # XXX: server_name is required if the target name - # is not covered by the certificate (not in the SAN list) + # XXX: server_name は targets のホスト名が証明書でカバーされない + # （証明書の SAN リストに含まれない）場合は必須です server_name: 'foo' ``` ````{note} -The `server_name` must be specified if the Incus server certificate does not contain the same host name as used in the `targets` list. -To verify this, open `server.crt` and check the Subject Alternative Name (SAN) section. +Incus サーバ証明書が`targets`リスト内で使用するのと同じホスト名を含まない場合は`server_name`の指定は必須です。 +これを確認するには、`server.crt`を開いて Subject Alternative Name (SAN) セクションを確認してください。 -For example, assume that `server.crt` has the following content: +例えば、`server.crt` が以下の内容を持つとします: ```{terminal} :input: openssl x509 -noout -text -in /etc/prometheus/tls/server.crt @@ -158,24 +156,23 @@ For example, assume that `server.crt` has the following content: ... ``` -Since the Subject Alternative Name (SAN) list doesn't include the host name provided in the `targets` list (`foo.example.com`), you must override the name used for comparison using the `server_name` directive. +Subject Alternative Name (SAN) リストが `targets` リスト（`foo.example.com`）のホスト名を含んでいないので、 `server_name` ディレクティブを使用して比較に使用する名前を上書きする必要があります。 ```` -Here is an example of a `prometheus.yml` configuration where multiple jobs are used to scrape the metrics of multiple Incus servers: +以下は複数の Incus サーバーのメトリックを収集するために複数のジョブを使用する `prometheus.yaml` の設定例です: ```yaml scrape_configs: - # abydos, langara and orilla are part of a single cluster (called `hdc` here) - # initially bootstrapped by abydos which is why all 3 targets - # share the same `ca_file` and `server_name`. That `ca_file` corresponds - # to the `/var/lib/incus/cluster.crt` file found on every member of - # the Incus cluster. + # abydos, langara, orilla は最初にabydosからブートストラップした単一クラスタで + # (ここでは`hdc`と呼びます)、このため3ノードで`ca_file`と`server_name`を共有しています。 + # `ca_file`は Incus クラスタの各メンバー上に存在する`/var/lib/incus/cluster.crt` + # ファイルに対応しています。 # - # Note: the `project` param is are provided when not using the `default` project - # or when multiple projects are used. + # 注意: `project`パラメータは`default`プロジェクトを使用しないか複数のプロジェクトを + # 使用する場合に提供されます。 # - # Note: each member of the cluster only provide metrics for instances it runs locally - # this is why the `incus-hdc` cluster lists 3 targets + # 注意: クラスタの各メンバーはローカルで稼働するインスタンスのメトリクスだけを提供します。 + # これが`incus-hdc`クラスタが3つのターゲットを一覧表示している理由です。 - job_name: "incus-hdc" metrics_path: '/1.0/metrics' params: @@ -192,8 +189,8 @@ scrape_configs: key_file: 'tls/metrics.key' server_name: 'abydos' - # jupiter, mars and saturn are 3 standalone Incus servers. - # Note: only the `default` project is used on them, so it is not specified. +# jupiter, mars, saturn は3つのスタンドアロンの Incus サーバーです。 + # 注意: これらでは`default`プロジェクトのみが使用されているため、プロジェクトの設定は省略しています。 - job_name: "incus-jupiter" metrics_path: '/1.0/metrics' scheme: 'https' @@ -228,64 +225,62 @@ scrape_configs: server_name: 'saturn' ``` -After editing the configuration, restart Prometheus (for example, `systemctl restart prometheus`) to start scraping. +設定を編集後、Prometheus を再起動する（たとえば、`systemctl restart prometheus`）とデータ収集を開始します。 -## Set up a Grafana dashboard +## Grafanaダッシュボードをセットアップする -To visualize the metrics data, set up [Grafana](https://grafana.com/). -Incus provides a [Grafana dashboard](https://grafana.com/grafana/dashboards/19727-incus/) that is configured to display the Incus metrics scraped by Prometheus. +メトリクスデータを可視化するには、[Grafana](https://grafana.com/)を設定します。 +Incus は、Prometheus によって収集された Incus メトリクスを表示するように設定された[Grafanaダッシュボード](https://grafana.com/grafana/dashboards/19727-incus/)を提供します。 ```{note} -The dashboard requires Grafana 8.4 or later. +このダッシュボードはGrafana 8.4以降が必要です。 ``` -See the Grafana documentation for instructions on installing and signing in: +Grafana のドキュメントを参照して、インストールとサインインの手順を確認してください: -- [Install Grafana](https://grafana.com/docs/grafana/latest/setup-grafana/installation/) -- [Sign in to Grafana](https://grafana.com/docs/grafana/latest/setup-grafana/sign-in-to-grafana/) +- [Grafanaをインストールする](https://grafana.com/docs/grafana/latest/setup-grafana/installation/) +- [Grafanaにサインインする](https://grafana.com/docs/grafana/latest/setup-grafana/sign-in-to-grafana/) -Complete the following steps to import the [Incus dashboard](https://grafana.com/grafana/dashboards/19727-incus/): +次の手順で[Incusダッシュボード](https://grafana.com/grafana/dashboards/19727-incus/)をインポートします: -1. Configure Prometheus as the data source: +1. Prometheus をデータソースとして設定します: - 1. Go to {guilabel}`Configuration` > {guilabel}`Data sources`. - 1. Click {guilabel}`Add data source`. + 1. {guilabel}`Configuration` > {guilabel}`Data sources`に移動します。 + 1. {guilabel}`Add data source`をクリックします。 - ![Add data source in Grafana](images/grafana_add_datasource.png) + ![Grafanaでデータソースを追加](images/grafana_add_datasource.png) - 1. Select {guilabel}`Prometheus`. + 1. {guilabel}`Prometheus`を選択します。 - ![Select Prometheus as the data source](images/grafana_select_prometheus.png) + ![データソースとしてPrometheusを選択](images/grafana_select_prometheus.png) - 1. In the {guilabel}`URL` field, enter `http://localhost:9090/`. + 1. {guilabel}`URL`フィールドに`http://localhost:9090/`を入力します。 - ![Enter Prometheus URL](images/grafana_configure_datasource.png) + ![Prometheus URLを入力](images/grafana_configure_datasource.png) - 1. Keep the default configuration for the other fields and click {guilabel}`Save & test`. + 1. 他のフィールドはデフォルトの設定のままにし、{guilabel}`保存＆テスト`をクリックします。 -1. Import the Incus dashboard: + 1. {guilabel}`Dashboards` > {guilabel}`Browse`に移動します。 + 1. {guilabel}`New`をクリックし、{guilabel}`Import`を選択します。 - 1. Go to {guilabel}`Dashboards` > {guilabel}`Browse`. - 1. Click {guilabel}`New` and select {guilabel}`Import`. + ![Grafanaでダッシュボードをインポート](images/grafana_dashboard_import.png) - ![Import a dashboard in Grafana](images/grafana_dashboard_import.png) + 1. {guilabel}`Import via grafana.com`フィールドにダッシュボード ID `19727`を入力します。 - 1. In the {guilabel}`Import via grafana.com` field, enter the dashboard ID `19727`. + ![Incus ダッシュボードIDを入力](images/grafana_dashboard_id.png) - ![Enter the Incus dashboard ID](images/grafana_dashboard_id.png) + 1. {guilabel}`Load`をクリックします。 + 1. {guilabel}`Incus`のドロップダウンメニューから、設定した Prometheus のデータソースを選択します。 - 1. Click {guilabel}`Load`. - 1. In the {guilabel}`Incus` drop-down menu, select the Prometheus data source that you configured. + ![Prometheusのデータソースを選択](images/grafana_dashboard_select_datasource.png) - ![Select the Prometheus data source](images/grafana_dashboard_select_datasource.png) + 1. {guilabel}`Import`をクリックします。 - 1. Click {guilabel}`Import`. +これで Incus ダッシュボードが表示されるはずです。 +プロジェクトを選択し、インスタンスによってフィルタリングすることができます。 -You should now see the Incus dashboard. -You can select the project and filter by instances. +![Incus Grafanaダッシュボードのリソース概要](images/grafana_resources.png) -![Resource overview in the Incus Grafana dashboard](images/grafana_resources.png) +ページの下部で、各インスタンスのデータを見ることができます。 -At the bottom of the page, you can see data for each instance. - -![Instance data in the Incus Grafana dashboard](images/grafana_instances.png) +![Incus Grafanaダッシュボードのインスタンスデータ](images/grafana_instances.png) diff --git a/doc/migration.md b/doc/migration.md index 7c40b07c2ee..c69d332f67f 100644 --- a/doc/migration.md +++ b/doc/migration.md @@ -1,31 +1,31 @@ (migration)= -# Migration +# マイグレーション -Incus provides tools and functionality to migrate instances in different contexts. +Incus は異なる状況でインスタンスをマイグレートするためのツールと機能を提供します。 -Migrate existing Incus instances between servers -: The most basic kind of migration is if you have a Incus instance on one server and want to move it to a different Incus server. - For virtual machines, you can do that as a live migration, which means that you can migrate your VM while it is running and there will be no downtime. +サーバー間で既存の Incus インスタンスをマイグレートする +: 最も基本的な種類のマイグレーションは 1 つのサーバー上に Incus インスタンスがあり、それを別の Incus サーバーに移動したいというものです。 + 仮想マシンでは、ライブマイグレーションを行えます。これは稼働中にダウンタイムなしで VM をマイグレートできることを意味します。 - See {ref}`move-instances` for more information. + 詳細は {ref}`move-instances` を参照してくだい。 -Migrate physical or virtual machines to Incus instances -: If you have an existing machine, either physical or virtual (VM or container), you can use the `incus-migrate` tool to create a Incus instance based on your existing machine. - The tool copies the provided partition, disk or image to the Incus storage pool of the provided Incus server, sets up an instance using that storage and allows you to configure additional settings for the new instance. +物理または仮想マシンを Incus インスタンスにマイグレートする +: 物理または仮想（VM またはコンテナ）の既存のマシンがある場合、既存のマシン上に Incus インスタンスを作成するために `incus-migrate` ツールが使えます。 + このツールは提供されたパーティション、ディスクやイメージを Incus サーバーの Incus ストレージプールにコピーし、そのストレージを使ってインスタンスをセットアップします。新しいインスタンスの追加の設定を行うこともできます。 - See {ref}`import-machines-to-instances` for more information. + 詳細は {ref}`import-machines-to-instances` を参照してくだい。 -Migrate instances from LXC to Incus -: If you are using LXC and want to migrate all or some of your LXC containers to a Incus installation on the same machine, you can use the `lxc-to-incus` tool. - The tool analyzes the LXC configuration and copies the data and configuration of your existing LXC containers into new Incus containers. +Incus から Incus へインスタンスをマイグレートする +: LXC を使っていてすべてまたは一部の LXC コンテナを同じマシン上の Incus に移動したい場合、 `lxc-to-incus` ツールが使えます。 + このツールは LXC 設定を解析し、既存の LXC コンテナのデータと設定を新しい Incus コンテナにコピーします。 - See {ref}`migrate-from-lxc` for more information. + 詳細は {ref}`migrate-from-lxc` を参照してくだい。 ```{toctree} :maxdepth: 1 :hidden: -Move instances -Import existing machines -Migrate from LXC +インスタンスの移動 +既存のマシンのインポート +LXCからのマイグレート ``` diff --git a/doc/networks.md b/doc/networks.md index 7cf2fb3460a..052ae615be0 100644 --- a/doc/networks.md +++ b/doc/networks.md @@ -5,15 +5,15 @@ :maxdepth: 1 /explanation/networks -Create and configure a network -Configure a network -Configure network ACLs -Configure network forwards -Configure network zones -Configure Incus as BGP server -Display Incus IPAM information +ネットワークの作成 +ネットワークの設定 +ネットワーク ACL の設定 +ネットワークフォワードの設定 +ネットワークゾーンの設定 +Incus を BGP サーバーとして設定 +Incus IPAM 情報を表示 /reference/network_bridge /reference/network_ovn /reference/network_external -Increase bandwidth +帯域幅の拡大 ``` diff --git a/doc/packaging.md b/doc/packaging.md new file mode 100644 index 00000000000..548d206ce88 --- /dev/null +++ b/doc/packaging.md @@ -0,0 +1,44 @@ +# バッケージ作成の推奨 +以下は Incus のパッケージ作成者向けの推奨事項です。 + +以下の推奨に従うとさまざまな Linux ディストリビューションでより期待通りな経験を提供できるでしょう。 + +## パッケージ + +通常は、少なくとも `incus` と `incus-client` パッケージに分割するのが良いでしょう。 +後者はデーモンやその依存物をインストールせずに `incus` コマンドだけをインストールできるようにします。 + +さらに、`fuidshift`、`lxc-to-incus`、`incus-benchmark`、`incus-migrate` のような使用頻度の低いツールを `incus-tools` パッケージに分離すると便利かもしれません。 + +## グループ + +2 つのグループを提供すると良いです: + +- `incus-admin` は `unix.socket` ソケットへのアクセスを許可し、Incus への実質的に完全な制御を許可します。 +- `incus` は `user.socket` ソケットへのアクセスを許可し、制限された Incus プロジェクトを利用できるようにします。 + +## 初期化スクリプト + +以下は `systemd` の使用を想定しています。 +`systemd` を使用しないディストリビューションでは似たような命名規則に従うのがよいですが、ソケットアクティベーションのような点は一部差異があるでしょう。 + +- `incus.service` は `incusd` デーモンを起動・停止するメインのユニットです。 +- `incus.socket` は `incus.service` ユニット用のソケットアクティベーションのユニットです。存在する場合、`incus.service` は単体では起動しないようにします。 +- `incus-user.service` は `incus-user` デーモンを起動・停止するメインのユニットです。 +- `incus-user.socket` は `incus-user.service` ユニット用のソケットアクティベーションのユニットです。存在する場合、`incus-user.service` は単体では起動しないようにします。 +- `incus-startup.service` は `incusd activateifneeded` コマンドを使って必要であればデーモンの起動をトリガーします。さらに `incusd shutdown` を呼んでホストのシャットダウン時にインスタンスを順番にシャットダウンします。 + +## バイナリ + +`incusd` と `incus-user` デーモンはユーザーの `PATH` の通らない場所に置くのが良いです。 +`incus-agent` も同様で、デーモンの `PATH` に存在する必要がありますが、ユーザーは利用できないようにしてください。 + +ユーザーに利用できるようにするべきメインのバイナリは `incus` です。 + +これらに加えて、以下のオプショナルなバイナリも利用できるようにしてください: + +- `fuidshift`（root のみに限定するべき） +- `incus-benchmark` +- `incus-migrate` +- `lxc-to-incus` +- `lxd-to-incus`（root のみに限定するべき） diff --git a/doc/profiles.md b/doc/profiles.md index dafae30e0a9..97a736a16fe 100644 --- a/doc/profiles.md +++ b/doc/profiles.md @@ -1,67 +1,67 @@ (profiles)= -# How to use profiles +# プロファイルを使用するには -Profiles store a set of configuration options. -They can contain instance options, devices and device options. +プロファイルは一組の設定オプションを保持します。 +プロファイルにはインスタンスオプション、デバイスとデバイスオプションを含められます。 -You can apply any number of profiles to an instance. -They are applied in the order they are specified, so the last profile to specify a specific key takes precedence. -However, instance-specific configuration always overrides the configuration coming from the profiles. +1 つのインスタンスには任意の数のプロファイルを適用できます。 +プロファイルは指定された順番に適用され、その結果最後に指定したプロファイルが特定のキーを上書きします。 +どのような場合でも、インスタンス固有の設定はプロファイル由来のものを上書きします。 ```{note} -Profiles can be applied to containers and virtual machines. -Therefore, they might contain options and devices that are valid for either type. +プロファイルはコンテナと仮想マシンに適用できます。 +ですので、どちらのタイプに有効なオプションとデバイスを含めることができます。 -When applying a profile that contains configuration that is not suitable for the instance type, this configuration is ignored and does not result in an error. +インスタンスタイプに適用できない設定を含むプロファイルを適用すると、この設定は無視されエラーにはなりません。 ``` -If you don't specify any profiles when launching a new instance, the `default` profile is applied automatically. -This profile defines a network interface and a root disk. -The `default` profile cannot be renamed or removed. +新しいインスタンスを起動する際にプロファイルを指定しない場合は、自動的には`default`プロファイルが適用されます。 +このプロファイルはネットワークインターフェースとルートディスクを定義します。 +`default`プロファイルはリネームや削除はできません。 -## View profiles +## プロファイルを表示する -Enter the following command to display a list of all available profiles: +すべての利用可能なプロファイルを一覧表示するには以下のコマンドを入力します: incus profile list -Enter the following command to display the contents of a profile: +プロファイルの内容を表示するには以下のコマンドを入力します: incus profile show -## Create an empty profile +## 空のプロファイルを作成する -Enter the following command to create an empty profile: +空のプロファイルを作成するには以下のコマンドを入力します: incus profile create (profiles-edit)= -## Edit a profile +## プロファイルを編集する -You can either set specific configuration options for a profile or edit the full profile in YAML format. +プロファイルの特定の設定オプションを設定するか、あるいは YAML 形式でプロファイル全体を編集できます。 -### Set specific options for a profile +### プロファイルの特定の設定オプションを設定する -To set an instance option for a profile, use the [`incus profile set`](incus_profile_set.md) command. -Specify the profile name and the key and value of the instance option: +プロファイルのインスタンスオプションを設定するには、[`incus profile set`](incus_profile_set.md) コマンドを使います。 +プロファイル名とインスタンスオプションのキーとバリューを指定します: incus profile set = = ... -To add and configure an instance device for your profile, use the [`incus profile device add`](incus_profile_device_add.md) command. -Specify the profile name, a device name, the device type and maybe device options (depending on the {ref}`device type `): +プロファイルのインスタンスデバイスを追加と変更するには、[`incus profile device add`](incus_profile_device_add.md) コマンドを使います。 +プロファイル名、デバイス名、デバイスタイプと({ref}`デバイスタイプ `ごとの)必要に応じてデバイスオプションを指定します: incus profile device add = = ... -To configure instance device options for a device that you have added to the profile earlier, use the [`incus profile device set`](incus_profile_device_set.md) command: +以前にプロファイルに追加したデバイスのインスタンスデバイスオプションを設定するには、[`incus profile device set`](incus_profile_device_set.md) コマンドを使います: incus profile device set = = ... -### Edit the full profile +### プロファイル全体を編集する -Instead of setting each configuration option separately, you can provide all options at once in YAML format. +個々の設定オプションを別々に設定する代わりに、YAML 形式で一度にすべてのオプションを提供できます。 -Check the contents of an existing profile or instance configuration for the required markup. -For example, the `default` profile might look like this: +既存のプロファイルまたはインスタンス設定の中身で必要なマークアップをチェックします。 +たとえば、`default`プロファイルは以下のようになっているかもしれません: config: {} description: Default Incus profile @@ -77,39 +77,39 @@ For example, the `default` profile might look like this: name: default used_by: -Instance options are provided as an array under `config`. -Instance devices and instance device options are provided under `devices`. +インスタンスオプションは`config`の下に提供されます。 +インスタンスデバイスとインスタンスデバイスオプションは`devices`の下に提供されます。 -To edit a profile using your standard terminal editor, enter the following command: +ターミナルの標準エディタを使ってプロファイルを編集するには、以下のコマンドを入力します: incus profile edit -Alternatively, you can create a YAML file (for example, `profile.yaml`) with the configuration and write the configuration to the profile with the following command: +別の方法として、設定を含む YAML ファイル（たとえば、`profile.yaml`）を作成して、以下のコマンドで設定をプロファイルに書き込めます: incus profile edit < profile.yaml -## Apply a profile to an instance +## インスタンスにプロファイルを適用する -Enter the following command to apply a profile to an instance: +インスタンスにプロファイルを適用するには以下のコマンドを入力します: incus profile add ```{tip} -Check the configuration after adding the profile: [`incus config show `](incus_config_show.md) +プロファイル追加後に [`incus config show `](incus_config_show.md) を実行して設定を確認します。 -You will see that your profile is now listed under `profiles`. -However, the configuration options from the profile are not shown under `config` (unless you add the `--expanded` flag). -The reason for this behavior is that these options are taken from the profile and not the configuration of the instance. +プロファイルが`profiles`の下に一覧表示されます。 +しかし、プロファイルからの設定オプションは（`--expanded`フラグを追加しない限り）`config`の下には表示されません。 +この挙動の理由はこれらの設定はプロファイルからは取得されインスタンス設定から取得されるわけではないからです。 -This means that if you edit a profile, the changes are automatically applied to all instances that use the profile. +これはプロファイルを編集する場合、変更はプロファイルを使用している全てのインスタンスに自動的に適用されることを意味します。 ``` -You can also specify profiles when launching an instance by adding the `--profile` flag: +インスタンスの起動時に`--profile`フラグを追加してプロファイルを指定することもできます: incus launch --profile --profile ... -## Remove a profile from an instance +## インスタンスからプロファイルを削除する -Enter the following command to remove a profile from an instance: +インスタンスからプロファイルを削除するには以下のコマンドを入力します: incus profile remove diff --git a/doc/projects.md b/doc/projects.md index 2f51751c974..233d04a81ec 100644 --- a/doc/projects.md +++ b/doc/projects.md @@ -1,12 +1,12 @@ (projects)= -# Projects +# プロジェクト ```{toctree} :maxdepth: 1 explanation/projects -Create and configure projects -Work with different projects -Confine projects to users +プロジェクトの作成と設定 +異なるプロジェクトで作業 +ユーザーにプロジェクトを制限 reference/projects ``` diff --git a/doc/reference/cluster_member_config.md b/doc/reference/cluster_member_config.md index 1f0b6c71028..df1432eb52d 100644 --- a/doc/reference/cluster_member_config.md +++ b/doc/reference/cluster_member_config.md @@ -1,12 +1,12 @@ (cluster-member-config)= -# Cluster member configuration +# クラスタメンバーの設定 -Each cluster member has its own key/value configuration with the following supported namespaces: +各クラスタメンバーは以下のサポートされる Namespace 内で独自のキー・バリュー設定を持てます: -- `user` (free form key/value for user metadata) -- `scheduler` (options related to how the member is automatically targeted by the cluster) +- `user`（ユーザーのメタデータ用に自由形式のキー・バリュー） +- `scheduler`（メンバーが自クラスタによりどのように動的にターゲットされるかに関連するオプション） -The following keys are currently supported: +現状サポートされるキーは以下のとおりです: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt diff --git a/doc/reference/devices.md b/doc/reference/devices.md index 7c055fa22c2..c4636d1e5af 100644 --- a/doc/reference/devices.md +++ b/doc/reference/devices.md @@ -1,29 +1,29 @@ (devices)= -# Devices +# デバイス -Devices are attached to an instance (see {ref}`instances-configure-devices`) or to a profile (see {ref}`profiles-edit`). +デバイスはインスタンス（{ref}`instances-configure-devices` 参照）またはプロファイル（{ref}`profiles-edit` 参照）にアタッチされます。 -They include, for example, network interfaces, mount points, USB and GPU devices. -These devices can have instance device options, depending on the type of the instance device. +デバイスには、たとえば、ネットワークインターフェース、マウントポイント、USB そして GPU デバイスがあります。 +これらのデバイスはインスタンスデバイスの種別に応じてインスタンスデバイスオプションを持つことができます。 -Incus supports the following device types: +Incus では次のデバイスタイプが使えます: -| ID (database) | Name | Condition | Description | -|:--------------|:---------------------------------------|:----------|:--------------------------------| -| 0 | [`none`](devices-none) | - | Inheritance blocker | -| 1 | [`nic`](devices-nic) | - | Network interface | -| 2 | [`disk`](devices-disk) | - | Mount point inside the instance | -| 3 | [`unix-char`](devices-unix-char) | container | Unix character device | -| 4 | [`unix-block`](devices-unix-block) | container | Unix block device | -| 5 | [`usb`](devices-usb) | - | USB device | -| 6 | [`gpu`](devices-gpu) | - | GPU device | -| 7 | [`infiniband`](devices-infiniband) | container | InfiniBand device | -| 8 | [`proxy`](devices-proxy) | container | Proxy device | -| 9 | [`unix-hotplug`](devices-unix-hotplug) | container | Unix hotplug device | -| 10 | [`tpm`](devices-tpm) | - | TPM device | -| 11 | [`pci`](devices-pci) | VM | PCI device | +| ID (データベース) | 名前 | 条件 | 説明 | +| :------------------ | :------------------------------------ | :----------- | :--------------------------------- | +| 0 | [`none`](devices-none) | - | 継承ブロッカー | +| 1 | [`nic`](devices-nic) | - | ネットワークインターフェース | +| 2 | [`disk`](devices-disk) | - | インスタンス内のマウントポイント | +| 3 | [`unix-char`](devices-unix-char) | コンテナ | Unix キャラクタデバイス | +| 4 | [`unix-block`](devices-unix-block) | コンテナ | Unix ブロックデバイス | +| 5 | [`usb`](devices-usb) | - | USB デバイス | +| 6 | [`gpu`](devices-gpu) | - | GPU デバイス | +| 7 | [`infiniband`](devices-infiniband) | コンテナ | インフィニバンドデバイス | +| 8 | [`proxy`](devices-proxy) | コンテナ | プロキシデバイス | +| 9 | [`unix-hotplug`](devices-unix-hotplug) | コンテナ | Unix ホットプラグデバイス | +| 10 | [`tpm`](devices-tpm) | - | TPM デバイス | +| 11 | [`pci`](devices-pci) | 仮想マシン | PCI デバイス | -Each instance comes with a set of {ref}`standard-devices`. +各インスタンスには一組の {ref}`standard-devices` が付属します。 ```{toctree} :maxdepth: 1 diff --git a/doc/reference/devices_disk.md b/doc/reference/devices_disk.md index 7189e87e263..b7c0968f4bb 100644 --- a/doc/reference/devices_disk.md +++ b/doc/reference/devices_disk.md @@ -1,112 +1,110 @@ (devices-disk)= -# Type: `disk` +# タイプ: `disk` ```{note} -The `disk` device type is supported for both containers and VMs. -It supports hotplugging for both containers and VMs. +`disk` デバイスタイプはコンテナと VM の両方でサポートされます。 +コンテナと VM の両方でホットプラグをサポートします。 ``` -Disk devices supply additional storage to instances. +ディスクデバイスはインスタンスに追加のストレージを提供します。 -For containers, they are essentially mount points inside the instance (either as a bind-mount of an existing file or directory on the host, or, if the source is a block device, a regular mount). -Virtual machines share host-side mounts or directories through `9p` or `virtiofs` (if available), or as VirtIO disks for block-based disks. +コンテナにとっては、それらはインスタンス内の実質的なマウントポイントです（ホスト上の既存のファイルまたはディレクトリーのバインドマウントとしてか、あるいは、ソースがブロックデバイスの場合は通常のマウントのマウントポイント）。 +仮想マシンは `9p` または `virtiofs`（使用可能な場合）を通してホスト側のマウントまたはディレクトリーを共有するか、あるいはブロックベースのディスクに対する VirtIO ディスクとして共有します。 (devices-disk-types)= -## Types of disk devices +## ディスクデバイスの種類 -You can create disk devices from different sources. -The value that you specify for the `source` option specifies the type of disk device that is added: +さまざまなソースからディスクデバイスを作成できます。 +`source` オプションに指定する値によって、追加されるディスクデバイスのタイプが決まります: -Storage volume -: The most common type of disk device is a storage volume. - To add a storage volume, specify its name as the `source` of the device: +ストレージボリューム +: 最も一般的なタイプのディスクデバイスはストレージボリュームです。 + ストレージボリュームを追加するには、デバイスの`source`としてその名前を指定します: incus config device add disk pool= source= [path=] - The path is required for file system volumes, but not for block volumes. + path はファイルシステムボリュームには必要ですが、ブロックボリュームには必要ありません。 - Alternatively, you can use the [`incus storage volume attach`](incus_storage_volume_attach.md) command to {ref}`storage-attach-volume`. - Both commands use the same mechanism to add a storage volume as a disk device. + また、[`incus storage volume attach`](incus_storage_volume_attach.md) コマンドを使用して{ref}`storage-attach-volume`することもできます。 + どちらのコマンドも、ストレージボリュームをディスクデバイスとして追加するための同じメカニズムを使用します。 -Path on the host -: You can share a path on your host (either a file system or a block device) to your instance by adding it as a disk device with the host path as the `source`: +ホスト上のパス +: ホストのパス（ファイルシステムまたはブロックデバイスのいずれか）をインスタンスと共有するには、ディスクデバイスとして追加し、`source`としてホストパスを指定します: incus config device add disk source= [path=] - The path is required for file systems, but not for block devices. + path はファイルシステムボリュームには必要ですが、ブロックデバイスには必要ありません。 Ceph RBD -: Incus can use Ceph to manage an internal file system for the instance, but if you have an existing, externally managed Ceph RBD that you would like to use for an instance, you can add it with the following command: +: Incus は、インスタンスの内部ファイルシステムを管理するために Ceph を使用できますが、既存の外部管理 Ceph RBD をインスタンスに使用したい場合は、次のコマンドで追加できます: incus config device add disk source=ceph:/ ceph.user_name= ceph.cluster_name= [path=] - The path is required for file systems, but not for block devices. + path はファイルシステムボリュームには必要ですが、ブロックデバイスには必要ありません。 CephFS -: Incus can use Ceph to manage an internal file system for the instance, but if you have an existing, externally managed Ceph file system that you would like to use for an instance, you can add it with the following command: +: Incus はインスタンスで内部のファイルシステムの管理に Ceph を使えますが、既存の外部で管理されている Ceph ファイルシステムをインスタンスで使用したい場合は、以下のコマンドで追加できます: incus config device add disk source=cephfs:/ ceph.user_name= ceph.cluster_name= path= ISO file -: You can add an ISO file as a disk device for a virtual machine. - It is added as a ROM device inside the VM. +: 仮想マシンには ISO ファイルをディスクデバイスとして追加できます。 + ISO ファイルは VM 内部の ROM デバイスとして追加されます。 - This source type is applicable only to VMs. + このソースタイプは VM でのみ利用可能です。 - To add an ISO file, specify its file path as the `source`: + ISO ファイルを追加するには、そのファイルパスを`source`として指定します: incus config device add disk source= VM `cloud-init` -: You can generate a `cloud-init` configuration ISO from the {config:option}`instance-cloud-init:cloud-init.vendor-data` and {config:option}`instance-cloud-init:cloud-init.user-data` configuration keys and attach it to a virtual machine. - The `cloud-init` that is running inside the VM then detects the drive on boot and applies the configuration. +: {config:option}`instance-cloud-init:cloud-init.vendor-data`、{config:option}`instance-cloud-init:cloud-init.user-data`から`cloud-init`設定の ISO イメージを生成し、仮想マシンにアタッチできます。 - This source type is applicable only to VMs. + このソースタイプは VM でのみ利用可能です。 - To add such a device, use the following command: + そのようなデバイスを追加するには、以下のコマンドを使用します: incus config device add disk source=cloud-init:config (devices-disk-initial-config)= -## Initial volume configuration for instance root disk devices +## インスタンスルートディスクデバイスの初期ボリューム設定 -Initial volume configuration allows setting specific configurations for the root disk devices of new instances. -These settings are prefixed with `initial.` and are only applied when the instance is created. -This method allows creating instances that have unique configurations, independent of the default storage pool settings. +初期ボリューム設定は新しいインスタンスのルートディスクデバイスに個別の設定をできるようにします。 +これらの設定は `initial.` という接頭辞がつき、インスタンスが作成されたときのみ適用されます。 +この方法はデフォルトのストレージプールの設定とは独立に、個別の設定を持つインスタンスを作れるようにします。 -For example, you can add an initial volume configuration for `zfs.block_mode` to an existing profile, and this -will then take effect for each new instance you create using this profile: +たとえば、既存のプロファイルに `zfs.block_mode` の初期ボリューム設定を追加し、このプロファイルを使ってインスタンスを作成する都度適用できます: incus profile device set initial.zfs.block_mode=true -You can also set an initial configuration directly when creating an instance. For example: +インスタンス作成時に初期設定を直接指定もできます。たとえば: incus init --device ,initial.zfs.block_mode=true -Note that you cannot use initial volume configurations with custom volume options or to set the volume's size. - -## Device options - -`disk` devices have the following device options: - -Key | Type | Default | Required | Description -:-- | :-- | :-- | :-- | :-- -`boot.priority` | integer | - | no | Boot priority for VMs (higher value boots first) -`ceph.cluster_name` | string | `ceph` | no | The cluster name of the Ceph cluster (required for Ceph or CephFS sources) -`ceph.user_name` | string | `admin` | no | The user name of the Ceph cluster (required for Ceph or CephFS sources) -`initial.*` | n/a | - | no | {ref}`devices-disk-initial-config` that allows setting unique configurations independent of default storage pool settings -`io.cache` | string | `none` | no | Only for VMs: Override the caching mode for the device (`none`, `writeback` or `unsafe`) -`limits.max` | string | - | no | I/O limit in byte/s or IOPS for both read and write (same as setting both `limits.read` and `limits.write`) -`limits.read` | string | - | no | I/O limit in byte/s (various suffixes supported, see {ref}`instances-limit-units`) or in IOPS (must be suffixed with `iops`) - see also {ref}`storage-configure-IO` -`limits.write` | string | - | no | I/O limit in byte/s (various suffixes supported, see {ref}`instances-limit-units`) or in IOPS (must be suffixed with `iops`) - see also {ref}`storage-configure-IO` -`path` | string | - | yes | Path inside the instance where the disk will be mounted (only for containers) -`pool` | string | - | no | The storage pool to which the disk device belongs (only applicable for storage volumes managed by Incus) -`propagation` | string | - | no | Controls how a bind-mount is shared between the instance and the host (can be one of `private`, the default, or `shared`, `slave`, `unbindable`, `rshared`, `rslave`, `runbindable`, `rprivate`; see the Linux Kernel [shared subtree](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) documentation for a full explanation) -`raw.mount.options` | string | - | no | File system specific mount options -`readonly` | bool | `false` | no | Controls whether to make the mount read-only -`recursive` | bool | `false` | no | Controls whether to recursively mount the source path -`required` | bool | `true` | no | Controls whether to fail if the source doesn't exist -`shift` | bool | `false` | no | Sets up a shifting overlay to translate the source UID/GID to match the instance (only for containers) -`size` | string | - | no | Disk size in bytes (various suffixes supported, see {ref}`instances-limit-units`) - only supported for the `rootfs` (`/`) -`size.state` | string | - | no | Same as `size`, but applies to the file-system volume used for saving runtime state in VMs -`source` | string | - | yes | Source of a file system or block device (see {ref}`devices-disk-types` for details) +カスタムボリュームオプションに初期ボリューム設定を使ったりボリュームのサイズを設定はできないことに注意してください。 + +## デバイスオプション + +`disk` デバイスには以下のデバイスオプションがあります: + +キー | 型 | デフォルト値 | 必須 | 説明 +:-- | :-- | :-- | :-- | :-- +`boot.priority` | integer | - | no | VM のブート優先度（高いほうが先にブート） +`ceph.cluster_name` | string | `ceph` | no | Ceph クラスタのクラスタ名（Ceph か CephFS のソースには必須） +`ceph.user_name` | string | `admin` | no | Ceph クラスタのユーザー名（Ceph か CephFS のソースには必須） +`initial.*` | n/a | - | no | デフォルトストレージプール設定と独立して個別の設定を許可する{ref}`devices-disk-initial-config` +`io.cache` | string | `none` | no | VMのみ: デバイスのキャッシュモードを上書きする（`none`、`writeback`または`unsafe`） +`limits.max` | string | - | no | 読み取りと書き込み両方のbyte/sかIOPSによるI/O制限（`limits.read`と`limits.write`の両方を設定するのと同じ） +`limits.read` | string | - | no | byte/s（さまざまな単位が使用可能、{ref}`instances-limit-units`参照）もしくはIOPS（あとに`iops`と付けなければなりません）で指定する読み込みのI/O制限値 - {ref}`storage-configure-IO` も参照 +`limits.write` | string | - | no | byte/s（さまざまな単位が使用可能、{ref}`instances-limit-units`参照）もしくはIOPS（あとに`iops`と付けなければなりません）で指定する書き込みのI/O制限値 - {ref}`storage-configure-IO` も参照 +`path` | string | - | yes | ディスクをマウントするインスタンス内のパス（コンテナのみ） +`pool` | string | - | no | ディスクデバイスが属するストレージプール（Incus が管理するストレージボリュームにのみ適用可能） +`propagation` | string | - | no | バインドマウントをインスタンスとホストでどのように共有するかを管理する（`private` （デフォルト）、`shared`、`slave`、`unbindable`、 `rshared`、`rslave`、`runbindable`、`rprivate` のいずれか。完全な説明は Linux Kernel の文書 [shared subtree](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) 参照） +`raw.mount.options` | string | - | no | ファイルシステム固有のマウントオプション +`readonly` | bool | `false` | no | マウントを読み込み専用とするかどうかを制御 +`recursive` | bool | `false` | no | ソースパスを再帰的にマウントするかどうかを制御 +`required` | bool | `true` | no | ソースが存在しないときに失敗とするかどうかを制御 +`shift` | bool | `false` | no | ソースの UID/GID をインスタンスにマッチするように変換させるためにオーバーレイの shift を設定するか（コンテナのみ） +`size` | string | - | no | byte（さまざまな単位が使用可能、 {ref}`instances-limit-units` 参照）で指定するディスクサイズ。`rootfs`（`/`） でのみサポートされます +`size.state` | string | - | no | 上の `size` と同じですが、仮想マシン内のランタイム状態を保存するために使われるファイルシステムボリュームに適用されます +`source` | string | - | yes | ファイルシステムまたはブロックデバイスのソース（詳細は{ref}`devices-disk-types`参照） diff --git a/doc/reference/devices_gpu.md b/doc/reference/devices_gpu.md index 6015c74a62a..9b089192fef 100644 --- a/doc/reference/devices_gpu.md +++ b/doc/reference/devices_gpu.md @@ -1,114 +1,114 @@ (devices-gpu)= -# Type: `gpu` +# タイプ: `gpu` -GPU devices make the specified GPU device or devices appear in the instance. +GPU デバイスは、指定の GPU デバイスをインスタンス内に出現させます。 ```{note} -For containers, a `gpu` device may match multiple GPUs at once. -For VMs, each device can match only a single GPU. +コンテナでは、`gpu` デバイスは同時に複数の GPU にマッチングさせることができます。 +VM では、各デバイスは1つの GPU にしかマッチできません。 ``` -The following types of GPUs can be added using the `gputype` device option: +以下のタイプの GPU が `gputype` デバイスオプションを使って追加できます: -- [`physical`](gpu-physical) (container and VM): Passes an entire GPU through into the instance. - This value is the default if `gputype` is unspecified. -- [`mdev`](gpu-mdev) (VM only): Creates and passes a virtual GPU through into the instance. -- [`mig`](gpu-mig) (container only): Creates and passes a MIG (Multi-Instance GPU) through into the instance. -- [`sriov`](gpu-sriov) (VM only): Passes a virtual function of an SR-IOV-enabled GPU into the instance. +- [`physical`](#gpu-physical)（コンテナと VM）: GPU 全体をインスタンスにパススルーします。 + `gputype` が指定されない場合これがデフォルトです。 +- [`mdev`](#gpu-mdev)（VM のみ）: 仮想 GPU を作成しインスタンスにパススルーします。 +- [`mig`](#gpu-mig)（コンテナのみ）: MIG（Multi-Instance GPU）を作成しインスタンスにパススルーします。 +- [`sriov`](#gpu-sriov)（VM のみ）: SR-IOV を有効にした GPU の仮想ファンクション（virtual function）をインスタンスに与えます。 -The available device options depend on the GPU type and are listed in the tables in the following sections. +利用可能なデバイスオプションは GPU タイプごとに異なり、以下のセクションの表に一覧表示されます。 (gpu-physical)= ## `gputype`: `physical` ```{note} -The `physical` GPU type is supported for both containers and VMs. -It supports hotplugging only for containers, not for VMs. +`physical` GPU タイプはコンテナと VM の両方でサポートされます。 +ホットプラグはコンテナのみでサポートし、VM ではサポートしません。 ``` -A `physical` GPU device passes an entire GPU through into the instance. +`physical` GPU デバイスは GPU 全体をインスタンスにパススルーします。 -### Device options +### デバイスオプション -GPU devices of type `physical` have the following device options: +`physical` タイプのデバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`gid` | int | `0` | GID of the device owner in the instance (container only) -`id` | string | - | The DRM card ID of the GPU device -`mode` | int | `0660` | Mode of the device in the instance (container only) -`pci` | string | - | The PCI address of the GPU device -`productid` | string | - | The product ID of the GPU device -`uid` | int | `0` | UID of the device owner in the instance (container only) -`vendorid` | string | - | The vendor ID of the GPU device +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`gid` | int | `0` | インスタンス（コンテナのみ）内のデバイス所有者のGID +`id` | string | - | GPUデバイスのDRMカードID +`mode` | int | `0660` | インスタンス（コンテナのみ）内のデバイスのモード +`pci` | string | - | GPUデバイスのPCIアドレス +`productid` | string | - | GPUデバイスのプロダクトID +`uid` | int | `0` | インスタンス（コンテナのみ）内のデバイス所有者のUID +`vendorid` | string | - | GPUデバイスのベンダーID (gpu-mdev)= ## `gputype`: `mdev` ```{note} -The `mdev` GPU type is supported only for VMs. -It does not support hotplugging. +`mdev` GPU タイプは VM でのみサポートされます。 +ホットプラグはサポートしていません。 ``` -An `mdev` GPU device creates and passes a virtual GPU through into the instance. -You can check the list of available `mdev` profiles by running [`incus info --resources`](incus_info.md). +`mdev` GPU デバイスは仮想 GPU を作成しインスタンスにパススルーします。 +利用可能な`mdev`プロファイルの一覧は [`incus info --resources`](incus_info.md) を実行すると確認できます。 -### Device options +### デバイスオプション -GPU devices of type `mdev` have the following device options: +`mdev` タイプのデバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`id` | string | - | The DRM card ID of the GPU device -`mdev` | string | - | The `mdev` profile to use (required - for example, `i915-GVTg_V5_4`) -`pci` | string | - | The PCI address of the GPU device -`productid` | string | - | The product ID of the GPU device -`vendorid` | string | - | The vendor ID of the GPU device +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`id` | string | - | GPUデバイスのDRMカードID +`mdev` | string | - | 使用する`mdev`プロファイル（必須 - 例:`i915-GVTg_V5_4`） +`pci` | string | - | GPUデバイスのPCIアドレス +`productid` | string | - | GPUデバイスのプロダクトID +`vendorid` | string | - | GPUデバイスのベンダーID (gpu-mig)= ## `gputype`: `mig` ```{note} -The `mig` GPU type is supported only for containers. -It does not support hotplugging. +`mig` GPU タイプはコンテナでのみサポートされます。 +ホットプラグはサポートしていません。 ``` -A `mig` GPU device creates and passes a MIG compute instance through into the instance. -Currently, this requires NVIDIA MIG instances to be pre-created. +`mig` GPU デバイスは MIG コンピュートインスタンスを作成しインスタンスにパススルーします。 +現状これは NVIDIA MIG を事前に作成しておく必要があります。 -### Device options +### デバイスオプション -GPU devices of type `mig` have the following device options: +`mig` タイプのデバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`id` | string | - | The DRM card ID of the GPU device -`mig.ci` | int | - | Existing MIG compute instance ID -`mig.gi` | int | - | Existing MIG GPU instance ID -`mig.uuid` | string | - | Existing MIG device UUID (`MIG-` prefix can be omitted) -`pci` | string | - | The PCI address of the GPU device -`productid` | string | - | The product ID of the GPU device -`vendorid` | string | - | The vendor ID of the GPU device +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`id` | string | - | GPUデバイスのDRMカードID +`mig.ci` | int | - | 既存のMIGコンピュートインスタンスID +`mig.gi` | int | - | 既存のMIG GPUインスタンスID +`mig.uuid` | string | - | 既存のMIGデバイスUUID（`MIG-`接頭辞は省略可） +`pci` | string | - | GPUデバイスのPCIアドレス +`productid` | string | - | GPUデバイスのプロダクトID +`vendorid` | string | - | GPUデバイスのベンダーID -You must set either `mig.uuid` (NVIDIA drivers 470+) or both `mig.ci` and `mig.gi` (old NVIDIA drivers). +`mig.uuid`（NVIDIA drivers 470+）か、`mig.ci`と`mig.gi`（古い NVIDIA ドライバー）の両方を設定する必要があります。 (gpu-sriov)= ## `gputype`: `sriov` ```{note} -The `sriov` GPU type is supported only for VMs. -It does not support hotplugging. +`sriov` GPU タイプは VM でのみサポートされます。 +ホットプラグはサポートしていません。 ``` -An `sriov` GPU device passes a virtual function of an SR-IOV-enabled GPU into the instance. +`sriov` GPU デバイスは SR-IOV が有効な GPU の仮想ファンクション（virtual function）をインスタンスにパススルーします。 -### Device options +### デバイスオプション -GPU devices of type `sriov` have the following device options: +`sriov`タイプのデバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`id` | string | - | The DRM card ID of the parent GPU device -`pci` | string | - | The PCI address of the parent GPU device -`productid` | string | - | The product ID of the parent GPU device -`vendorid` | string | - | The vendor ID of the parent GPU device +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`id` | string | - | GPUデバイスのDRMカードID +`pci` | string | - | 親GPUデバイスのPCIアドレス +`productid` | string | - | 親GPUデバイスのプロダクトID +`vendorid` | string | - | 親GPUデバイスのベンダーID diff --git a/doc/reference/devices_infiniband.md b/doc/reference/devices_infiniband.md index 71559421fcd..8a5dd7e4eae 100644 --- a/doc/reference/devices_infiniband.md +++ b/doc/reference/devices_infiniband.md @@ -1,38 +1,38 @@ (devices-infiniband)= -# Type: `infiniband` +# タイプ: `infiniband` ```{note} -The `infiniband` device type is supported for both containers and VMs. -It supports hotplugging only for containers, not for VMs. +`infiniband`デバイスタイプはコンテナと VM の両方でサポートされます。 +ホットプラグはコンテナのみでサポートし、VM ではサポートしません。 ``` -Incus supports two different kinds of network types for InfiniBand devices: +Incus では、InfiniBand デバイスに対する 2 種類の異なったネットワークタイプが使えます: -- `physical`: Passes a physical device from the host through to the instance. - The targeted device will vanish from the host and appear in the instance. -- `sriov`: Passes a virtual function of an SR-IOV-enabled physical network device into the instance. +- `physical`: ホストの物理デバイスをインスタンスにパススルーします。 + 対象のデバイスはホスト上では見えなくなり、インスタンス内に出現します。 +- `sriov`: SR-IOV が有効な物理ネットワークデバイスの仮想ファンクション（virtual function）をインスタンスにパススルーします。 ```{note} - InfiniBand devices support SR-IOV, but in contrast to other SR-IOV-enabled devices, InfiniBand does not support dynamic device creation in SR-IOV mode. - Therefore, you must pre-configure the number of virtual functions by configuring the corresponding kernel module. + InfiniBandデバイスはSR-IOVをサポートしますが、他のSR-IOVが有効なデバイスと異なり、InfiniBandはSR-IOVモードの動的なデバイスの作成をサポートしません。 + このため、対応するカーネルモジュールを設定することで仮想ファンクションの数を事前に設定する必要があります。 ``` -To create a `physical` `infiniband` device, use the following command: +`physical`な`infiniband`デバイスを作成するには、以下のコマンドを使用します: incus config device add infiniband nictype=physical parent= -To create an `sriov` `infiniband` device, use the following command: +`sriov`の`infiniband`デバイスを作成するには、以下のコマンドを使用します: incus config device add infiniband nictype=sriov parent= -## Device options +## デバイスオプション -`infiniband` devices have the following device options: +`infiniband`デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Required | Description -:-- | :-- | :-- | :-- | :-- -`hwaddr` | string | randomly assigned | no | The MAC address of the new interface (can be either the full 20-byte variant or the short 8-byte variant, which will only modify the last 8 bytes of the parent device) -`mtu` | integer | parent MTU | no | The MTU of the new interface -`name` | string | kernel assigned | no | The name of the interface inside the instance -`nictype` | string | - | yes | The device type (one of `physical` or `sriov`) -`parent` | string | - | yes | The name of the host device or bridge +キー | 型 | デフォルト値 | 必須 | 説明 +:-- | :-- | :-- | :-- | :-- +`hwaddr` | string | ランダムに割り当て | no | 新しいインターフェースのMACアドレス。20バイトすべてを指定するか短い8バイト（この場合親デバイスの最後の8バイトだけを変更）のどちらかを設定可能 +`mtu` | integer | 親の MTU | no | 新しいインターフェースのMTU +`name` | string | カーネルが割り当て | no | インスタンス内部でのインターフェース名 +`nictype` | string | - | yes | デバイスタイプ（`physical`か`sriov`のいずれか） +`parent` | string | - | yes | ホスト上のデバイスまたはブリッジの名前 diff --git a/doc/reference/devices_nic.md b/doc/reference/devices_nic.md index af9271b6f14..a74f7bceb96 100644 --- a/doc/reference/devices_nic.md +++ b/doc/reference/devices_nic.md @@ -1,193 +1,193 @@ (devices-nic)= -# Type: `nic` +# タイプ: `nic` ```{note} -The `nic` device type is supported for both containers and VMs. +`nic`デバイスタイプはコンテナと VM の両方でサポートされます。 -NICs support hotplugging for both containers and VMs (with the exception of the `ipvlan` NIC type). +（`ipvlan` NIC タイプを除いて）NIC はコンテナと VM の両方でホットプラグをサポートします。 ``` -Network devices, also referred to as *Network Interface Controllers* or *NICs*, supply a connection to a network. -Incus supports several different types of network devices (*NIC types*). +ネットワークデバイス（*ネットワークインタフェースコントローラー*や*NIC*とも呼びます）はネットワークへの接続を提供します。 +Incus はさまざまな異なるタイプのネットワークデバイス（*NICタイプ*）をサポートします。 -## `nictype` vs. `network` +## `nictype` 対 `network` -When adding a network device to an instance, there are two methods to specify the type of device that you want to add: through the `nictype` device option or the `network` device option. +インスタンスにネットワークデバイスを追加する際には、追加したいデバイスのタイプを選択するのに 2 つの方法があります。`nictype`プロパティを指定するか`network`プロパティを使うかです。 -These two device options are mutually exclusive, and you can specify only one of them when you create a device. -However, note that when you specify the `network` option, the `nictype` option is derived automatically from the network type. +これらの 2 つのデバイスオプションは相互排他であり、デバイスを作成時にどちらか 1 つのみ指定可能です。 +しかし、`network`オプションを指定する際には、`nictype`オプションはネットワークタイプから自動的に導出されることに注意してください。 `nictype` -: When using the `nictype` device option, you can specify a network interface that is not controlled by Incus. - Therefore, you must specify all information that Incus needs to use the network interface. +: nictype`デバイスオプションを使用する際は、Incus に管理されていないネットワークインターフェースを指定できます。 + このため、Incus がネットワークインターフェースを使用するために必要なすべての情報を指定する必要があります。 - When using this method, the `nictype` option must be specified when creating the device, and it cannot be changed later. + この方法を使用する際は、`nictype`オプションはデバイス作成時に指定する必要があり、作成後は変更できません。 `network` -: When using the `network` device option, the NIC is linked to an existing {ref}`managed network `. - In this case, Incus has all required information about the network, and you need to specify only the network name when adding the device. +: `network`デバイスオプションを使用する際は、NIC は既存の{ref}`管理されたネットワーク `にリンクされます。 + この場合、Incus はネットワークについて必要な情報をすべて持っているので、デバイス追加時にはネットワーク名を指定するだけでよいです。 - When using this method, Incus derives the `nictype` option automatically. - The value is read-only and cannot be changed. + この方法を使用する際は、`nictype`オプションは Incus が自動的に導出します。 + 値は読み取り専用で変更できません。 - Other device options that are inherited from the network are marked with a "yes" in the "Managed" column of the NIC-specific tables of device options. - You cannot customize these options directly for the NIC if you're using the `network` method. + ネットワークから継承される他のデバイスオプションは NIC 固有のデバイスオプションの「管理」カラムで「yes」と記載されています。 + `network`の方法を使う場合、NIC のこれらのオプションを直接カスタマイズはできません。 -See {ref}`networks` for more information. +詳細な情報は{ref}`networks`を参照してください。 -## Available NIC types +## 利用可能なNIC -The following NICs can be added using the `nictype` or `network` options: +次の NIC は`nictype`か`network`オプションを使って追加できます: -- [`bridged`](nic-bridged): Uses an existing bridge on the host and creates a virtual device pair to connect the host bridge to the instance. -- [`macvlan`](nic-macvlan): Sets up a new network device based on an existing one, but using a different MAC address. -- [`sriov`](nic-sriov): Passes a virtual function of an SR-IOV-enabled physical network device into the instance. -- [`physical`](nic-physical): Passes a physical device from the host through to the instance. - The targeted device will vanish from the host and appear in the instance. +- [`bridged`](nic-bridged): ホスト上に存在する既存のブリッジを使い、ホストのブリッジをインスタンスに接続する仮想デバイスペアを作成します。 +- [`macvlan`](nic-macvlan): 既存のネットワークデバイスをベースに MAC アドレスが異なる新しいネットワークデバイスを作成します。 +- [`sriov`](nic-sriov): SR-IOV が有効な物理ネットワークデバイスの仮想ファンクション（virtual function）をインスタンスにパススルーします。 +- [`physical`](nic-physical): ホストの物理デバイスをインスタンスにパススルーします。 + 対象のデバイスはホスト上では見えなくなり、インスタンス内に出現します。 -The following NICs can be added using only the `network` option: +次の NIC は`network`オプションでのみ追加できます: -- [`ovn`](nic-ovn): Uses an existing OVN network and creates a virtual device pair to connect the instance to it. +- [`ovn`](nic-ovn): 既存の OVN ネットワークを使用し、インスタンスが接続する仮想デバイスペアを作成します。 -The following NICs can be added using only the `nictype` option: +次の NIC は`nictype`オプションでのみ追加できます: -- [`ipvlan`](nic-ipvlan): Sets up a new network device based on an existing one, using the same MAC address but a different IP. -- [`p2p`](nic-p2p): Creates a virtual device pair, putting one side in the instance and leaving the other side on the host. -- [`routed`](nic-routed): Creates a virtual device pair to connect the host to the instance and sets up static routes and proxy ARP/NDP entries to allow the instance to join the network of a designated parent interface. +- [`ipvlan`](nic-ipvlan): 既存のネットワークデバイスをベースに MAC アドレスは同じですが IP アドレスが異なる新しいネットワークデバイスを作成します。 +- [`p2p`](nic-p2p): 仮想デバイスペアを作成し、片方をインスタンス内に置き、残りの片方をホスト上に残します。 +- [`routed`](nic-routed): 仮想デバイスペアを作成し、ホストからインスタンスに繋いで静的ルートとプロキシ ARP/NDP エントリーを作成します。これにより指定された親インターフェースのネットワークにインスタンスが参加できるようになります。 -The available device options depend on the NIC type and are listed in the tables in the following sections. +利用可能なデバイスオプションは NIC タイプによって異なり、以下のセクションの表に一覧表示されます。 (nic-bridged)= ### `nictype`: `bridged` ```{note} -You can select this NIC type through the `nictype` option or the `network` option (see {ref}`network-bridge` for information about the managed `bridge` network). +この NIC タイプは`nictype`オプションか`network`オプションで選択できます（管理された`bridge`ネットワークの情報については{ref}`network-bridge`参照）。 ``` -A `bridged` NIC uses an existing bridge on the host and creates a virtual device pair to connect the host bridge to the instance. - -#### Device options - -NIC devices of type `bridged` have the following device options: - -Key | Type | Default | Managed | Description -:-- | :-- | :-- | :-- | :-- -`boot.priority` | integer | - | no | Boot priority for VMs (higher value boots first) -`host_name` | string | randomly assigned | no | The name of the interface inside the host -`hwaddr` | string | randomly assigned | no | The MAC address of the new interface -`ipv4.address` | string | - | no | An IPv4 address to assign to the instance through DHCP (can be `none` to restrict all IPv4 traffic when `security.ipv4_filtering` is set) -`ipv4.routes` | string | - | no | Comma-delimited list of IPv4 static routes to add on host to NIC -`ipv4.routes.external` | string | - | no | Comma-delimited list of IPv4 static routes to route to the NIC and publish on uplink network (BGP) -`ipv6.address` | string | - | no | An IPv6 address to assign to the instance through DHCP (can be `none` to restrict all IPv6 traffic when `security.ipv6_filtering` is set) -`ipv6.routes` | string | - | no | Comma-delimited list of IPv6 static routes to add on host to NIC -`ipv6.routes.external` | string | - | no | Comma-delimited list of IPv6 static routes to route to the NIC and publish on uplink network (BGP) -`limits.egress` | string | - | no | I/O limit in bit/s for outgoing traffic (various suffixes supported, see {ref}`instances-limit-units`) -`limits.ingress` | string | - | no | I/O limit in bit/s for incoming traffic (various suffixes supported, see {ref}`instances-limit-units`) -`limits.max` | string | - | no | I/O limit in bit/s for both incoming and outgoing traffic (same as setting both `limits.ingress` and `limits.egress`) -`limits.priority` | integer | - | no | The `skb->priority` value (32-bit unsigned integer) for outgoing traffic, to be used by the kernel queuing discipline (qdisc) to prioritize network packets (The effect of this value depends on the particular qdisc implementation, for example, `SKBPRIO` or `QFQ`. Consult the kernel qdisc documentation before setting this value.) -`mtu` | integer | parent MTU | yes | The MTU of the new interface -`name` | string | kernel assigned | no | The name of the interface inside the instance -`network` | string | - | no | The managed network to link the device to (instead of specifying the `nictype` directly) -`parent` | string | - | yes | The name of the host device (required if specifying the `nictype` directly) -`queue.tx.length` | integer | - | no | The transmit queue length for the NIC -`security.ipv4_filtering`| bool | `false` | no | Prevent the instance from spoofing another instance's IPv4 address (enables `security.mac_filtering`) -`security.ipv6_filtering`| bool | `false` | no | Prevent the instance from spoofing another instance's IPv6 address (enables `security.mac_filtering`) -`security.mac_filtering` | bool | `false` | no | Prevent the instance from spoofing another instance's MAC address -`security.port_isolation`| bool | `false` | no | Prevent the NIC from communicating with other NICs in the network that have port isolation enabled -`vlan` | integer | - | no | The VLAN ID to use for non-tagged traffic (can be `none` to remove port from default VLAN) -`vlan.tagged` | integer | - | no | Comma-delimited list of VLAN IDs or VLAN ranges to join for tagged traffic +`bridged` NIC はホストの既存のブリッジを使用し、ホストのブリッジをインスタンスに接続するための仮想デバイスのペアを作成します。 + +#### デバイスオプション + +`bridged` タイプの NIC デバイスには以下のデバイスオプションがあります: + +キー | 型 | デフォルト値 | 管理 | 説明 +:-- | :-- | :-- | :-- | :-- +`boot.priority` | integer | - | no | VMのブート優先度（高いほうが先にブート） +`host_name` | string | ランダムに割り当て | no | ホスト内でのインターフェースの名前 +`hwaddr` | string | ランダムに割り当て | no | 新しいインターフェースのMACアドレス +`ipv4.address` | string | - | no | DHCPでインスタンスに割り当てるIPv4アドレス（`security.ipv4_filtering`設定時にすべてのIPv4トラフィックを制限するには`none`と設定可能） +`ipv4.routes` | string | - | no | ホスト上でNICに追加するIPv4静的ルートのカンマ区切りリスト +`ipv4.routes.external` | string | - | no | NICにルーティングしアップリンクのネットワーク（BGP）で公開するIPv4静的ルートのカンマ区切りリスト +`ipv6.address` | string | - | no | DHCPでインスタンスに割り当てるIPv6アドレス（`security.ipv6_filtering`設定時にすべてのIPv6トラフィックを制限するには`none`と設定可能） +`ipv6.routes` | string | - | no | ホスト上でNICに追加するIPv6静的ルートのカンマ区切りリスト +`ipv6.routes.external` | string | - | no | NICにルーティングしアップリンクのネットワーク（BGP）で公開するIPv6静的ルートのカンマ区切りリスト +`limits.egress` | string | - | no | 外向きトラフィックのI/O制限値（さまざまな単位が使用可能、{ref}`instances-limit-units`参照） +`limits.ingress` | string | - | no | 内向きトラフィックのI/O制限値（さまざまな単位が使用可能、{ref}`instances-limit-units`参照） +`limits.max` | string | - | no | 内向きと外向きの両方のトラフィックI/O制限値（`limits.ingress`と`limits.egress`の両方を設定するのと同じ） +`limits.priority` | integer | - | no | 外向きトラフィックへの `skb->priority` の値（32-bit 符号なし整数）、カーネルでネットワークパケットに優先度をつけるために kernel queuing discipline （qdisc） によって使用される（この値の効果は特定の qdisc 実装、たとえば、`SKBPRIO` または `QFQ` によって異なる。この値を設定する前に kernel qdisc ドキュメントを参照のこと） +`mtu` | integer | 親の MTU | yes | 新しいインターフェースのMTU +`name` | string | カーネルが割り当て | no | インスタンス内でのインターフェースの名前 +`network` | string | - | no | （`nictype`を直接設定する代わりに）デバイスをリンクする先の管理されたネットワーク +`parent` | string | - | yes | ホストデバイスの名前（`nictype`を直接設定する場合は必須） +`queue.tx.length` | integer | - | no | NICの送信キューの長さ +`security.ipv4_filtering` | bool | `false` | no | インスタンスが他のインスタンスのIPv4アドレスになりすますのを防ぐ（これを設定すると`mac_filtering`も有効になります） +`security.ipv6_filtering` | bool | `false` | no | インスタンスが他のインスタンスのIPv6アドレスになりすますのを防ぐ（これを設定すると`mac_filtering`も有効になります） +`security.mac_filtering` | bool | `false` | no | インスタンスが他のインスタンスのMACアドレスになりすますのを防ぐ +`security.port_isolation` | bool | `false` | no | NICがポート隔離を有効にしたネットワーク内の他のNICと通信するのを防ぐ +`vlan` | integer | - | no | タグなしのトラフィックに使用するVLAN ID（デフォルトのVLANからポートを削除するには`none`を指定） +`vlan.tagged` | integer | - | no | タグありのトラフィックに参加するVLAN IDまたはVLANの範囲のカンマ区切りリスト (nic-macvlan)= ### `nictype`: `macvlan` ```{note} -You can select this NIC type through the `nictype` option or the `network` option (see {ref}`network-macvlan` for information about the managed `macvlan` network). +この NIC タイプは`nictype`オプションか`network`オプションで選択できます（管理された`macvlan`ネットワークの情報については{ref}`network-macvlan`参照）。 ``` -A `macvlan` NIC sets up a new network device based on an existing one, but using a different MAC address. +`macvlan` NIC は既存の NIC をベースにしますが、MAC アドレスが異なる新しいネットワークデバイスをセットアップします。 -If you are using a `macvlan` NIC, communication between the Incus host and the instances is not possible. -Both the host and the instances can talk to the gateway, but they cannot communicate directly. +`macvlan` NIC を使う場合、Incus ホストとインスタンス間の通信はできません。 +ホストとインスタンスの両方がゲートウェイと通信できますが、それらが直接通信はできません。 -#### Device options +#### デバイスオプション -NIC devices of type `macvlan` have the following device options: +`macvlan`タイプの NIC デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Managed | Description -:-- | :-- | :-- | :-- | :-- -`boot.priority` | integer | - | no | Boot priority for VMs (higher value boots first) -`gvrp` | bool | `false` | no | Register VLAN using GARP VLAN Registration Protocol -`hwaddr` | string | randomly assigned | no | The MAC address of the new interface -`mtu` | integer | parent MTU | yes | The MTU of the new interface -`name` | string | kernel assigned | no | The name of the interface inside the instance -`network` | string | - | no | The managed network to link the device to (instead of specifying the `nictype` directly) -`parent` | string | - | yes | The name of the host device (required if specifying the `nictype` directly) -`vlan` | integer | - | no | The VLAN ID to attach to +キー | 型 | デフォルト値 | 管理 | 説明 +:-- | :-- | :-- | :-- | :-- +`boot.priority` | integer | - | no | VMのブート優先度（高いほうが先にブート） +`gvrp` | bool | `false` | no | GARP VLAN Registration Protocolを使ってVLANを登録する +`hwaddr` | string | ランダムに割り当て | no | 新しいインターフェースのMACアドレス +`mtu` | integer | 親の MTU | yes | 新しいインターフェースのMTU +`name` | string | カーネルが割り当て | no | インスタンス内部でのインターフェース名 +`network` | string | - | no | （`nictype`を直接設定する代わりに）デバイスをリンクする先の管理されたネットワーク +`parent` | string | - | yes | ホストデバイスの名前（`nictype`を直接設定する場合は必須） +`vlan` | integer | - | no | アタッチ先のVLAN ID (nic-sriov)= ### `nictype`: `sriov` ```{note} -You can select this NIC type through the `nictype` option or the `network` option (see {ref}`network-sriov` for information about the managed `sriov` network). +この NIC タイプは`nictype`オプションか`network`オプションで選択できます（管理された`sriov`ネットワークの情報については{ref}`network-sriov`参照）。 ``` -An `sriov` NIC passes a virtual function of an SR-IOV-enabled physical network device into the instance. +`sriov` NIC は SR-IOV を有効にした物理ネットワークデバイスの仮想ファンクションをインスタンスにパススルーします。 -An SR-IOV-enabled network device associates a set of virtual functions (VFs) with the single physical function (PF) of the network device. -PFs are standard PCIe functions. -VFs, on the other hand, are very lightweight PCIe functions that are optimized for data movement. -They come with a limited set of configuration capabilities to prevent changing properties of the PF. +SR-IOV を有効にしたネットワークデバイスは一組の仮想ファンクション（VF）をネットワークデバイスの単一の物理ファンクション(PF)に関連付けます。 +PF は標準的な PCIe 関数です。 +一方、VF はデータの移動に最適化された非常に軽量な PCIe 関数です。 +PF のプロパティを変えるのを防ぐため、VF の構成機能は限定されています。 -Given that VFs appear as regular PCIe devices to the system, they can be passed to instances just like a regular physical device. +VF はシステムには通常の PCIe デバイスのように見えますので、通常の物理デバイスと全く同じようにインスタンスにパススルーできます。 -VF allocation -: The `sriov` interface type expects to be passed the name of an SR-IOV enabled network device on the system via the `parent` property. - Incus then checks for any available VFs on the system. +VF の割り当て +: `sriov`インターフェースタイプは`parent`プロパティを通してシステム上の SR-IOV を有効にしたネットワークデバイスの名前を渡されることを想定しています。 + すると Incus はシステム上の任意の利用可能な VF をチェックします。 - By default, Incus allocates the first free VF it finds. - If it detects that either none are enabled or all currently enabled VFs are in use, it bumps the number of supported VFs to the maximum value and uses the first free VF. - If all possible VFs are in use or the kernel or card doesn't support incrementing the number of VFs, Incus returns an error. + デフォルトでは、Incus は見つけた最初の未使用な VF を割り当てます。 + 有効になっているものが 1 つもないか、有効な VF がすべて使用中の場合、サポートされている VF の数を最大に上げて最初の未使用な VF を使用します。 + すべての利用可能な VF が使用中か、カーネルまたはカードが VF の数の増加をサポートしない場合は、Incus はエラーを返します。 ```{note} - If you need Incus to use a specific VF, use a `physical` NIC instead of a `sriov` NIC and set its `parent` option to the VF name. + Incus に特定の VF を使わせたい場合、`sriov` NIC の代わりに`physical` NIC を使用し、`parent`オプションを VF 名に設定してください。 ``` -#### Device options +#### デバイスオプション -NIC devices of type `sriov` have the following device options: +`sriov`タイプの NIC デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Managed | Description -:-- | :-- | :-- | :-- | :-- -`boot.priority` | integer | - | no | Boot priority for VMs (higher value boots first) -`hwaddr` | string | randomly assigned | no | The MAC address of the new interface -`mtu` | integer | kernel assigned | yes | The MTU of the new interface -`name` | string | kernel assigned | no | The name of the interface inside the instance -`network` | string | - | no | The managed network to link the device to (instead of specifying the `nictype` directly) -`parent` | string | - | yes | The name of the host device (required if specifying the `nictype` directly) -`security.mac_filtering`| bool | `false` | no | Prevent the instance from spoofing another instance's MAC address -`vlan` | integer | - | no | The VLAN ID to attach to +キー | 型 | デフォルト値 | 管理 | 説明 +:-- | :-- | :-- | :-- | :-- +`boot.priority` | integer | - | no | VMのブート優先度（高いほうが先にブート） +`hwaddr` | string | ランダムに割り当て | no | 新しいインターフェースのMACアドレス +`mtu` | integer | カーネルが割り当て | yes | 新しいインターフェースのMTU +`name` | string | カーネルが割り当て | no | インスタンス内部でのインターフェース名 +`network` | string | - | no | （`nictype`を直接設定する代わりに）デバイスをリンクする先の管理されたネットワーク +`parent` | string | - | yes | ホストデバイスの名前（`nictype`を直接設定する場合は必須） +`security.mac_filtering` | bool | `false` | no | インスタンスが他のインスタンスのMACアドレスになりすますのを防ぐ +`vlan` | integer | - | no | アタッチ先のVLAN ID (nic-ovn)= ### `nictype`: `ovn` ```{note} -You can select this NIC type only through the `network` option (see {ref}`network-ovn` for information about the managed `ovn` network). +この NIC タイプは`network`オプションでのみ選択できます（管理された`ovn`ネットワークの情報については{ref}`network-ovn`参照）。 ``` -An `ovn` NIC uses an existing OVN network and creates a virtual device pair to connect the instance to it. +`ovn` NIC は既存の OVN ネットワークを使用し、それにインスタンスが接続する仮想デバイスペアを作成します。 (devices-nic-hw-acceleration)= -SR-IOV hardware acceleration -: To use `acceleration=sriov`, you must have a compatible SR-IOV physical NIC that supports the Ethernet switch device driver model (`switchdev`) in your Incus host. - Incus assumes that the physical NIC (PF) is configured in `switchdev` mode and connected to the OVN integration OVS bridge, and that it has one or more virtual functions (VFs) active. +SR-IOV ハードウェアアクセラレーション +: `acceleration=sriov`を使用するには、Incus ホスト内の Ethernet スイッチデバイスのドライバーモデル（`switchdev`）をサポートする互換性のある SR-IOV 物理 NIC を持っている必要があります。 + Incus は物理 NIC（PF）が`switchdev`モードに設定され、OVN 統合 OVS ブリッジに接続され、1 つ以上の仮想ファンクション（VF）がアクティブになっていることを前提とします。 - To achieve this, follow these basic prerequisite setup steps: + これを実現するには、基本的な前提条件となる以下のセットアップ手順に従ってください。 - 1. Set up PF and VF: + 1. PF と VF をセットアップする: - 1. Activate some VFs on PF (called `enp9s0f0np0` in the following example, with a PCI address of `0000:09:00.0`) and unbind them. - 1. Enable `switchdev` mode and `hw-tc-offload` on the PF. - 1. Rebind the VFs. + 1. PF 上でいくつかの VF をアクティベートし（以下の例では`enp9s0f0np0`とし、PCI アドレスは`0000:09:00.0`とします）、アンバインドします。 + 1. `switchdev`モードと PF 上の`hw-tc-offload`を有効にします。 + 1. VF をリバインドします。 ``` echo 4 > /sys/bus/pci/devices/0000:09:00.0/sriov_numvfs @@ -197,7 +197,7 @@ SR-IOV hardware acceleration for i in $(lspci -nnn | grep "Virtual Function" | cut -d' ' -f1); do echo 0000:$i > /sys/bus/pci/drivers/mlx5_core/bind; done ``` - 1. Set up OVS by enabling hardware offload and adding the PF NIC to the integration bridge (normally called `br-int`): + 1. ハードウェアオフロードを有効にし、統合ブリッジ（通常`br-int`と呼ばれます）に PF NIC を追加して OVS をセットアップします: ``` ovs-vsctl set open_vswitch . other_config:hw-offload=true @@ -206,200 +206,201 @@ SR-IOV hardware acceleration ip link set enp9s0f0np0 up ``` -VDPA hardware acceleration -: To use `acceleration=vdpa`, you must have a compatible VDPA physical NIC. - The setup is the same as for SR-IOV hardware acceleration, except that you must also enable the `vhost_vdpa` module and check that you have some available VDPA management devices : + +VDPA ハードウェアアクセラレーション +: `acceleration=vdpa`を使用するには互換性のある VDPA 物理 NIC が必要です。 + セットアップ手順は SR-IOV ハードウェアアクセラレーションと同様ですが、さらに`vhost_vdpa`モジュールをセットアップし、利用可能な VDPA 管理デバイスがあることを確認する必要があります: ``` modprobe vhost_vdpa && vdpa mgmtdev show ``` -#### Device options - -NIC devices of type `ovn` have the following device options: - -Key | Type | Default | Managed | Description -:-- | :-- | :-- | :-- | :-- -`acceleration` | string | `none` | no | Enable hardware offloading (either `none`, `sriov` or `vdpa`, see {ref}`devices-nic-hw-acceleration`) -`boot.priority` | integer | - | no | Boot priority for VMs (higher value boots first) -`host_name` | string | randomly assigned | no | The name of the interface inside the host -`hwaddr` | string | randomly assigned | no | The MAC address of the new interface -`ipv4.address` | string | - | no | An IPv4 address to assign to the instance through DHCP -`ipv4.routes` | string | - | no | Comma-delimited list of IPv4 static routes to route to the NIC -`ipv4.routes.external` | string | - | no | Comma-delimited list of IPv4 static routes to route to the NIC and publish on uplink network -`ipv6.address` | string | - | no | An IPv6 address to assign to the instance through DHCP -`ipv6.routes` | string | - | no | Comma-delimited list of IPv6 static routes to route to the NIC -`ipv6.routes.external` | string | - | no | Comma-delimited list of IPv6 static routes to route to the NIC and publish on uplink network -`name` | string | kernel assigned | no | The name of the interface inside the instance -`nested` | string | - | no | The parent NIC name to nest this NIC under (see also `vlan`) -`network` | string | - | yes | The managed network to link the device to (required) -`security.acls` | string | - | no | Comma-separated list of network ACLs to apply -`security.acls.default.egress.action` | string | `reject` | no | Action to use for egress traffic that doesn't match any ACL rule -`security.acls.default.egress.logged` | bool | `false` | no | Whether to log egress traffic that doesn't match any ACL rule -`security.acls.default.ingress.action`| string | `reject` | no | Action to use for ingress traffic that doesn't match any ACL rule -`security.acls.default.ingress.logged`| bool | `false` | no | Whether to log ingress traffic that doesn't match any ACL rule -`vlan` | integer | - | no | The VLAN ID to use when nesting (see also `nested`) +#### デバイスオプション + +`ovn` タイプの NIC デバイスには以下のデバイスオプションがあります: + +キー | 型 | デフォルト値 | 管理 | 説明 +:-- | :-- | :-- | :-- | :-- +`acceleration` | string | `none` | no | ハードウェアオフローディングを有効にする（`none`か`sriov`か`vdpa`、{ref}`devices-nic-hw-acceleration`参照） +`boot.priority` | integer | - | no | VMのブート優先度（高いほうが先にブート） +`host_name` | string | ランダムに割り当て | no | ホスト内部でのインターフェース名 +`hwaddr` | string | ランダムに割り当て | no | 新しいインターフェースのMACアドレス +`ipv4.address` | string | - | no | DHCPでインスタンスに割り当てるIPv4アドレス +`ipv4.routes` | string | - | no | NICへルーティングするIPv4静的ルートのカンマ区切りリスト +`ipv4.routes.external` | string | - | no | NICへのルーティングとアップリンクネットワークでの公開に使用するIPv4静的ルートのカンマ区切りリスト +`ipv6.address` | string | - | no | DHCPでインスタンスに割り当てるIPv6アドレス +`ipv6.routes` | string | - | no | NICへルーティングするIPv6静的ルートのカンマ区切りリスト +`ipv6.routes.external` | string | - | no | NICへのルーティングとアップリンクネットワークでの公開に使用するIPv6静的ルートのカンマ区切りリスト +`name` | string | カーネルが割り当て | no | インスタンス内部でのインターフェース名 +`nested` | string | - | no | このNICをどの親NICの下にネストするか（`vlan`も参照） +`network` | string | - | yes | デバイスの接続先の管理されたネットワーク（必須） +`security.acls` | string | - | no | 適用するネットワークACLのカンマ区切りリスト +`security.acls.default.egress.action` | string | `reject` | no | どのACLルールにもマッチしない外向きトラフィックに使うアクション +`security.acls.default.egress.logged` | bool | `false` | no | どのACLルールにもマッチしない外向きトラフィックをログ出力するかどうか +`security.acls.default.ingress.action` | string | `reject` | no | どのACLルールにもマッチしない内向きトラフィックに使うアクション +`security.acls.default.ingress.logged` | bool | `false` | no | どのACLルールにもマッチしない内向きトラフィックをログ出力するかどうか +`vlan` | integer | - | no | ネストする際に使用する VLAN ID （`nested`も参照） (nic-physical)= ### `nictype`: `physical` ```{note} -- You can select this NIC type through the `nictype` option or the `network` option (see {ref}`network-physical` for information about the managed `physical` network). -- You can have only one `physical` NIC for each parent device. +- この NIC タイプは`nictype`オプションまたは`network`オプションで選択できます（管理された`physical`ネットワークの情報については{ref}`network-physical`参照）。 +- それぞれの親デバイスに対して`physical` NIC は1つだけ持つことができます。 ``` -A `physical` NIC provides straight physical device pass-through from the host. -The targeted device will vanish from the host and appear in the instance (which means that you can have only one `physical` NIC for each targeted device). +`physical` NIC はホストからパススルーされるそのままの物理デバイスを提供します。 +対象のデバイスはホストから消失し、インスタンス内に出現します（これは各ターゲットデバイスに`physical` NIC は 1 つだけ持つことができることを意味します）。 -#### Device options +#### デバイスオプション -NIC devices of type `physical` have the following device options: +`physical`タイプの NIC デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Managed | Description -:-- | :-- | :-- | :-- | :-- -`boot.priority` | integer | - | no | Boot priority for VMs (higher value boots first) -`gvrp` | bool | `false` | no | Register VLAN using GARP VLAN Registration Protocol -`hwaddr` | string | randomly assigned | no | The MAC address of the new interface -`mtu` | integer | parent MTU | no | The MTU of the new interface -`name` | string | kernel assigned | no | The name of the interface inside the instance -`network` | string | - | no | The managed network to link the device to (instead of specifying the `nictype` directly) -`parent` | string | - | yes | The name of the host device (required if specifying the `nictype` directly) -`vlan` | integer | - | no | The VLAN ID to attach to +キー | 型 | デフォルト値 | 管理 | 説明 +:-- | :-- | :-- | :-- | :-- +`boot.priority` | integer | - | no | VMのブート優先度（高いほうが先にブート） +`gvrp` | bool | `false` | no | GARP VLAN Registration Protocolを使ってVLANを登録する +`hwaddr` | string | ランダムに割り当て | no | 新しいインターフェースのMACアドレス +`mtu` | integer | 親の MTU | no | 新しいインターフェースのMTU +`name` | string | カーネルが割り当て | no | インスタンス内部でのインターフェース名 +`network` | string | - | no | デバイスのリンク先（`nictype`を直接指定する代わりに）の管理ネットワーク +`parent` | string | - | yes | ホストデバイスの名前（`nictype`を直接指定する場合は必須） +`vlan` | integer | - | no | アタッチ先のVLAN ID (nic-ipvlan)= ### `nictype`: `ipvlan` ```{note} -- This NIC type is available only for containers, not for virtual machines. -- You can select this NIC type only through the `nictype` option. -- This NIC type does not support hotplugging. +- この NIC タイプはコンテナのみで利用でき、仮想マシンでは利用できません。 +- この NIC タイプは`nictype`オプションでのみ選択できます。 +- この NIC タイプはホットプラグをサポートしません。 ``` -An `ipvlan` NIC sets up a new network device based on an existing one, using the same MAC address but a different IP. +`ipvlan` NIC は既存のネットワークデバイスを元に、同じ MAC アドレスですが IP アドレスは異なるような新しいネットワークデバイスをセットアップします。 -If you are using an `ipvlan` NIC, communication between the Incus host and the instances is not possible. -Both the host and the instances can talk to the gateway, but they cannot communicate directly. +`ipvlan` NIC を使う場合、Incus ホストとインスタンス間の通信はできません。 +ホストとインスタンスの両方がゲートウェイと通信できますが、それらが直接通信はできません。 -Incus currently supports IPVLAN in L2 and L3S mode. -In this mode, the gateway is automatically set by Incus, but the IP addresses must be manually specified using the `ipv4.address` and/or `ipv6.address` options before the container is started. +Incus は現状 L2 と L3S モードで IPVLAN をサポートします。 +このモードでは、ゲートウェイは Incus により自動的に設定されますが、コンテナが起動する前に`ipv4.address`と`ipv6.address`の設定の 1 つあるいは両方を使うことにより IP アドレスを手動で指定する必要があります。 DNS -: The name servers must be configured inside the container, because they are not set automatically. - To do this, set the following `sysctls`: +: ネームサーバーは自動的には設定されないので、コンテナ内部で設定する必要があります。 + このためには、以下の`sysctl`の設定をしてください: - - When using IPv4 addresses: + - IPv4 アドレスを使用する場合: ``` net.ipv4.conf..forwarding=1 ``` - - When using IPv6 addresses: + - IPv6 アドレスを使用する場合: ``` net.ipv6.conf..forwarding=1 net.ipv6.conf..proxy_ndp=1 ``` -#### Device options - -NIC devices of type `ipvlan` have the following device options: - -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`gvrp` | bool | `false` | Register VLAN using GARP VLAN Registration Protocol -`hwaddr` | string | randomly assigned | The MAC address of the new interface -`ipv4.address` | string | - | Comma-delimited list of IPv4 static addresses to add to the instance (in `l2` mode, these can be specified as CIDR values or singular addresses using a subnet of `/24`) -`ipv4.gateway` | string | `auto` (`l3s`), - (`l2`) | In `l3s` mode, whether to add an automatic default IPv4 gateway (can be `auto` or `none`); in `l2` mode, the IPv4 address of the gateway -`ipv4.host_table` | integer | - | The custom policy routing table ID to add IPv4 static routes to (in addition to the main routing table) -`ipv6.address` | string | - | Comma-delimited list of IPv6 static addresses to add to the instance (in `l2` mode, these can be specified as CIDR values or singular addresses using a subnet of `/64`) -`ipv6.gateway` | string | `auto` (`l3s`), - (`l2`) | In `l3s` mode, whether to add an automatic default IPv6 gateway (can be `auto` or `none`); in `l2` mode, the IPv6 address of the gateway -`ipv6.host_table` | integer | - | The custom policy routing table ID to add IPv6 static routes to (in addition to the main routing table) -`mode` | string | `l3s` | The IPVLAN mode (either `l2` or `l3s`) -`mtu` | integer | parent MTU | The MTU of the new interface -`name` | string | kernel assigned | The name of the interface inside the instance -`parent` | string | - | The name of the host device (required) -`vlan` | integer | - | The VLAN ID to attach to +#### デバイスオプション + +`ipvlan`タイプの NIC デバイスには以下のデバイスオプションがあります: + +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`gvrp` | bool | `false` | GARP VLAN Registration Protocolを使ってVLANを登録する +`hwaddr` | string | ランダムに割り当て | 新しいインターフェースのMACアドレス +`ipv4.address` | string | - | インスタンスに追加するIPv4静的アドレスのカンマ区切りリスト（`l2`モードでは、CIDR形式か`/24`のサブネットの単一アドレスで指定可能） +`ipv4.gateway` | string | `auto` （`l3s`）, - （`l2`） | `l3s`モードでは、デフォルトIPv4ゲートウェイを自動的に追加するかどうか（`auto`か`none`を指定可能）。`l2`モードでは、ゲートウェイのIPv4アドレス +`ipv4.host_table` | integer | - | （メインのルーティングテーブルに加えて）IPv4の静的ルートを追加する先のカスタムポリシー・ルーティングテーブルID +`ipv6.address` | string | - | インスタンスに追加するIPv6静的アドレスのカンマ区切りリスト（`l2`モードでは、CIDR 形式か`/64`のサブネットの単一アドレスで指定可能） +`ipv6.gateway` | string | `auto` （`l3s`）, - （`l2`） | `l3s`モードでは、デフォルトIPv6ゲートウェイを自動的に追加するかどうか（`auto`か`none`を指定可能）。`l2`モードで、はゲートウェイのIPv6アドレス +`ipv6.host_table` | integer | - | （メインのルーティングテーブルに加えて）IPv6の静的ルートを追加する先のカスタムポリシー・ルーティングテーブルID +`mode` | string | `l3s` | IPVLANのモード（`l2`か`l3s`のいずれか） +`mtu` | integer | 親の MTU | 新しいインターフェースのMTU +`name` | string | カーネルが割り当て | インスタンス内部でのインターフェース名 +`parent` | string | - | ホストデバイスの名前(必須) +`vlan` | integer | - | アタッチ先のVLAN ID (nic-p2p)= ### `nictype`: `p2p` ```{note} -You can select this NIC type only through the `nictype` option. +この NIC タイプは`nictype`オプションでのみ選択できます。 ``` -A `p2p` NIC creates a virtual device pair, putting one side in the instance and leaving the other side on the host. +`p2p` NIC は仮想デバイスペアを作成し、片方はインスタンス内に配置し、もう片方はホストに残します。 -#### Device options +#### デバイスオプション -NIC devices of type `p2p` have the following device options: +`p2p`タイプの NIC デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`boot.priority` | integer | - | Boot priority for VMs (higher value boots first) -`host_name` | string | randomly assigned | The name of the interface inside the host -`hwaddr` | string | randomly assigned | The MAC address of the new interface -`ipv4.routes` | string | - | Comma-delimited list of IPv4 static routes to add on host to NIC -`ipv6.routes` | string | - | Comma-delimited list of IPv6 static routes to add on host to NIC -`limits.egress` | string | - | I/O limit in bit/s for outgoing traffic (various suffixes supported, see {ref}`instances-limit-units`) -`limits.ingress` | string | - | I/O limit in bit/s for incoming traffic (various suffixes supported, see {ref}`instances-limit-units`) -`limits.max` | string | - | I/O limit in bit/s for both incoming and outgoing traffic (same as setting both `limits.ingress` and `limits.egress`) -`limits.priority` | integer | - | The `skb->priority` value (32-bit unsigned integer) for outgoing traffic, to be used by the kernel queuing discipline (qdisc) to prioritize network packets (The effect of this value depends on the particular qdisc implementation, for example, `SKBPRIO` or `QFQ`. Consult the kernel qdisc documentation before setting this value.) -`mtu` | integer | kernel assigned | The MTU of the new interface -`name` | string | kernel assigned | The name of the interface inside the instance -`queue.tx.length` | integer | - | The transmit queue length for the NIC +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`boot.priority` | integer | - | VMのブート優先度 （高いほうが先にブート） +`host_name` | string | ランダムに割り当て | ホスト内でのインターフェースの名前 +`hwaddr` | string | ランダムに割り当て | 新しいインターフェースのMACアドレス +`ipv4.routes` | string | - | ホスト上でNICに追加するIPv4静的ルートのカンマ区切りリスト +`ipv6.routes` | string | - | ホスト上でNICに追加するIPv6静的ルートのカンマ区切りリスト +`limits.egress` | string | - | 外向きトラフィックのI/O制限値（さまざまな単位が使用可能、{ref}`instances-limit-units`参照） +`limits.ingress` | string | - | 内向きトラフィックのI/O制限値（さまざまな単位が使用可能、{ref}`instances-limit-units`参照） +`limits.max` | string | - | 内向きと外向きの両方のトラフィックI/O制限値（`limits.ingress`と`limits.egress`の両方を設定するのと同じ） +`limits.priority` | integer | - | 外向きトラフィックへの `skb->priority` の値（32-bit 符号なし整数）、カーネルでネットワークパケットに優先度をつけるために kernel queuing discipline （qdisc） によって使用される（この値の効果は特定の qdisc 実装、たとえば、`SKBPRIO` または `QFQ` によって異なる。この値を設定する前に kernel qdisc ドキュメントを参照のこと） +`mtu` | integer | カーネルが割り当て | 新しいインターフェースのMTU +`name` | string | カーネルが割り当て | インスタンス内部でのインターフェース名 +`queue.tx.length` | integer | - | NIC の送信キューの長さ (nic-routed)= ### `nictype`: `routed` ```{note} -You can select this NIC type only through the `nictype` option. +この NIC タイプは`nictype`オプションでのみ選択できます。 ``` -A `routed` NIC creates a virtual device pair to connect the host to the instance and sets up static routes and proxy ARP/NDP entries to allow the instance to join the network of a designated parent interface. -For containers it uses a virtual Ethernet device pair, and for VMs it uses a TAP device. +`routed` NIC タイプはホストをインスタンスに接続する仮想デバイスペアを作成し、インスタンスが指定された親インターフェースのネットワークに参加できるように、静的ルートとプロキシ ARP/NDP エントリをセットアップします。 +コンテナでは仮想イーサネットデバイスペアを使用し、VM では TAP デバイスを使用します。 -This NIC type is similar in operation to `ipvlan`, in that it allows an instance to join an external network without needing to configure a bridge and shares the host's MAC address. -However, it differs from `ipvlan` because it does not need IPVLAN support in the kernel, and the host and the instance can communicate with each other. +この NIC タイプは運用上は IPVLAN に似ていて、ブリッジを設定することなくホストの MAC アドレスを共用して、インスタンスが外部ネットワークに参加できるようにします。 +しかし、カーネルに IPVLAN サポートを必要としないことと、ホストとインスタンスが互いに通信できることが`ipvlan`とは異なります。 -This NIC type respects `netfilter` rules on the host and uses the host's routing table to route packets, which can be useful if the host is connected to multiple networks. +この NIC タイプは`netfilter`のルールを尊重し、ホストのルーティングテーブルを使ってパケットをルーティングしますので、ホストが複数のネットワークに接続している場合に役立ちます。 -IP addresses, gateways and routes -: You must manually specify the IP addresses (using `ipv4.address` and/or `ipv6.address`) before the instance is started. +IP アドレス、ゲートウェイ、ルーティング +: インスタンスが起動する前に IP アドレスを（`ipv4.address`と`ipv6.address`の設定のいずれかあるいは両方を使って）手動で指定する必要があります。 - For containers, the NIC configures the following link-local gateway IPs on the host end and sets them as the default gateways in the container's NIC interface: + コンテナでは、NIC はホスト上に下記のリンクローカルゲートウェイ IP アドレスを設定し、それらをコンテナの NIC インターフェースのデフォルトゲートウェイに設定します: 169.254.0.1 fe80::1 - For VMs, the gateways must be configured manually or via a mechanism like `cloud-init` (see the {ref}`how to guide `). + VM では、ゲートウェイは手動か`cloud-init`（{ref}`ハウツーガイド `参照）のような仕組みを使って設定する必要があります。 ```{note} - If your container image is configured to perform DHCP on the interface, it will likely remove the automatically added configuration. - In this case, you must configure the IP addresses and gateways manually or via a mechanism like `cloud-init`. + お使いのコンテナイメージがインタフェースに対して DHCP を使うように設定されている場合、上記の自動的に追加される設定は削除される可能性が高いです。 + この場合、IP アドレスとゲートウェイを手動か`cloud-init`のような仕組みを使って設定する必要があります。 ``` - The NIC type configures static routes on the host pointing to the instance's `veth` interface for all of the instance's IPs. + この NIC タイプはインスタンスの IP アドレスすべてをインスタンスの`veth`インターフェースに向ける静的ルートをホスト上に設定します。 -Multiple IP addresses -: Each NIC device can have multiple IP addresses added to it. +複数の IP アドレス +: それぞれの NIC デバイスに複数の IP アドレスを追加できます。 - However, it might be preferable to use multiple `routed` NIC interfaces instead. - In this case, set the `ipv4.gateway` and `ipv6.gateway` values to `none` on any subsequent interfaces to avoid default gateway conflicts. - Also consider specifying a different host-side address for these subsequent interfaces using `ipv4.host_address` and/or `ipv6.host_address`. + しかし、代わりに複数の`routed` NIC インターフェースを使うほうが望ましいかもしれません。 + この場合、`ipv4.gateway`と`ipv6.gateway`の値を`none`に設定し、後続のインターフェースがデフォルトゲートウェイの衝突を避けるようにします。 + さらに、これらの後続のインターフェースに`ipv4.host_address`と`ipv6.host_address`を使って異なるホスト側のアドレスを指定することを検討してください。 -Parent interface -: This NIC can operate with and without a `parent` network interface set. +親のインターフェース +: この NIC は`parent`のネットワークインターフェースのセットがあってもなくても利用できます。 -: With the `parent` network interface set, proxy ARP/NDP entries of the instance's IPs are added to the parent interface, which allows the instance to join the parent interface's network at layer 2. -: To enable this, the following network configuration must be applied on the host via `sysctl`: +: `parent`ネットワークインターフェースのセットがある場合、インスタンスの IP のプロキシ ARP/NDP エントリが親のインターフェースに追加され、インスタンスが親のインターフェースのネットワークにレイヤ 2 で参加できるようにします。 +: これを有効にするには以下のネットワーク設定を `sysctl` でホストに適用する必要があります: - - When using IPv4 addresses: + - IPv4 アドレスを使用する場合: ``` net.ipv4.conf..forwarding=1 ``` - - When using IPv6 addresses: + - IPv6 アドレスを使用する場合: ``` net.ipv6.conf.all.forwarding=1 @@ -408,48 +409,48 @@ Parent interface net.ipv6.conf..proxy_ndp=1 ``` -#### Device options - -NIC devices of type `routed` have the following device options: - -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`gvrp` | bool | `false` | Register VLAN using GARP VLAN Registration Protocol -`host_name` | string | randomly assigned | The name of the interface inside the host -`hwaddr` | string | randomly assigned | The MAC address of the new interface -`ipv4.address` | string | - | Comma-delimited list of IPv4 static addresses to add to the instance -`ipv4.gateway` | string | `auto` | Whether to add an automatic default IPv4 gateway (can be `auto` or `none`) -`ipv4.host_address` | string | `169.254.0.1` | The IPv4 address to add to the host-side `veth` interface -`ipv4.host_table` | integer | - | The custom policy routing table ID to add IPv4 static routes to (in addition to the main routing table) -`ipv4.neighbor_probe` | bool | `true` | Whether to probe the parent network for IP address availability -`ipv4.routes` | string | - | Comma-delimited list of IPv4 static routes to add on host to NIC (without L2 ARP/NDP proxy) -`ipv6.address` | string | - | Comma-delimited list of IPv6 static addresses to add to the instance -`ipv6.gateway` | string | `auto` | Whether to add an automatic default IPv6 gateway (can be `auto` or `none`) -`ipv6.host_address` | string | `fe80::1` | The IPv6 address to add to the host-side `veth` interface -`ipv6.host_table` | integer | - | The custom policy routing table ID to add IPv6 static routes to (in addition to the main routing table) -`ipv6.neighbor_probe` | bool | `true` | Whether to probe the parent network for IP address availability -`ipv6.routes` | string | - | Comma-delimited list of IPv6 static routes to add on host to NIC (without L2 ARP/NDP proxy) -`limits.egress` | string | - | I/O limit in bit/s for outgoing traffic (various suffixes supported, see {ref}`instances-limit-units`) -`limits.ingress` | string | - | I/O limit in bit/s for incoming traffic (various suffixes supported, see {ref}`instances-limit-units`) -`limits.max` | string | - | I/O limit in bit/s for both incoming and outgoing traffic (same as setting both `limits.ingress` and `limits.egress`) -`limits.priority` | integer | - | The `skb->priority` value (32-bit unsigned integer) for outgoing traffic, to be used by the kernel queuing discipline (qdisc) to prioritize network packets (The effect of this value depends on the particular qdisc implementation, for example, `SKBPRIO` or `QFQ`. Consult the kernel qdisc documentation before setting this value.) -`mtu` | integer | parent MTU | The MTU of the new interface -`name` | string | kernel assigned | The name of the interface inside the instance -`parent` | string | - | The name of the host device to join the instance to -`queue.tx.length` | integer | - | The transmit queue length for the NIC -`vlan` | integer | - | The VLAN ID to attach to - -## `bridged`, `macvlan` or `ipvlan` for connection to physical network - -The `bridged`, `macvlan` and `ipvlan` interface types can be used to connect to an existing physical network. - -`macvlan` effectively lets you fork your physical NIC, getting a second interface that is then used by the instance. -This method saves you from creating a bridge device and virtual Ethernet device pairs and usually offers better performance than a bridge. - -The downside to this method is that `macvlan` devices, while able to communicate between themselves and to the outside, cannot talk to their parent device. -This means that you can't use `macvlan` if you ever need your instances to talk to the host itself. - -In such case, a `bridge` device is preferable. -A bridge also lets you use MAC filtering and I/O limits, which cannot be applied to a `macvlan` device. - -`ipvlan` is similar to `macvlan`, with the difference being that the forked device has IPs statically assigned to it and inherits the parent's MAC address on the network. +#### デバイスオプション + +`routed`タイプの NIC デバイスには以下のデバイスオプションがあります: + +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`gvrp` | bool | `false` | GARP VLAN Registration Protocolを使ってVLANを登録する +`host_name` | string | ランダムに割り当て | ホスト内でのインターフェース名 +`hwaddr` | string | ランダムに割り当て | 新しいインターフェースのMACアドレス +`ipv4.address` | string | - | インスタンスに追加するIPv4静的アドレスのカンマ区切りリスト +`ipv4.gateway` | string | `auto` | 自動的にIPv4デフォルトゲートウェイを追加するかどうか（`auto`か`none`を指定可能） +`ipv4.host_address` | string | `169.254.0.1` | ホスト側の`veth`インターフェースに追加するIPv4アドレス +`ipv4.host_table` | integer | - | （メインのルーティングテーブルに加えて）IPv4の静的ルートを追加する先のカスタムポリシー・ルーティングテーブルID +`ipv4.neighbor_probe` | bool | `true` | IPアドレスが利用可能か知るために親のネットワークを調べるかどうか +`ipv4.routes` | string | - | ホスト上でNICに追加するIPv4静的ルートのカンマ区切りリスト（L2 ARP/NDPプロキシを除く） +`ipv6.address` | string | - | インスタンスに追加するIPv6静的アドレスのカンマ区切りリスト +`ipv6.gateway` | string | `auto` | 自動的にIPv6のデフォルトゲートウェイを追加するかどうか（`auto`か`none`を指定可能） +`ipv6.host_address` | string | `fe80::1` | ホスト側の`veth`インターフェースに追加するIPv6アドレス +`ipv6.host_table` | integer | - | （メインのルーティングテーブルに加えて）IPv6の静的ルートを追加する先のカスタムポリシー・ルーティングテーブルID +`ipv6.neighbor_probe` | bool | `true` | IPアドレスが利用可能か知るために親のネットワークを調べるかどうか +`ipv6.routes` | string | - | ホスト上でNICに追加するIPv6静的ルートのカンマ区切りリスト（L2 ARP/NDPプロキシを除く） +`limits.egress` | string | - | 内向きトラフィックに対するbit/sでのI/O制限値（さまざまな単位をサポート、{ref}`instances-limit-units`参照） +`limits.ingress` | string | - | 外向きトラフィックに対するbit/sでのI/O制限値（さまざまな単位をサポート、{ref}`instances-limit-units`参照） +`limits.max` | string | - | 内向きと外向き両方のトラフィックのI/O 制限値（`limits.ingress`と`limits.egress`の両方を設定するのと同じ） +`limits.priority` | integer | - | 外向きトラフィックへの `skb->priority` の値（32-bit 符号なし整数）、カーネルでネットワークパケットに優先度をつけるために kernel queuing discipline （qdisc） によって使用される（この値の効果は特定の qdisc 実装、たとえば、`SKBPRIO` または `QFQ` によって異なる。この値を設定する前に kernel qdisc ドキュメントを参照のこと） +`mtu` | integer | 親の MTU | 新しいインターフェースのMTU +`name` | string | カーネルが割り当て | インスタンス内でのインターフェース名 +`parent` | string | - | インスタンスが参加するホストデバイス名 +`queue.tx.length` | integer | - | NICの送信キューの長さ +`vlan` | integer | - | アタッチ先の VLAN ID + +## `bridge`、`macvlan`、`ipvlan`を使った物理ネットワークへの接続 + +`bridged`、`macvlan`、`ipvlan`インターフェースタイプのいずれも、既存の物理ネットワークへ接続するために使用できます。 + +`macvlan`は、物理 NIC を効率的に分岐できます。つまり、物理 NIC からインスタンスで使える第 2 のインターフェースを取得できます。 +この方法はブリッジデバイスと仮想イーサネットデバイスペアの作成を不要にしますし、通常はブリッジよりも良いパフォーマンスが得られます。 + +`macvlan`の欠点は、`macvlan`はインスタンス自身と外部との間で通信はできますが、親デバイスとは通信できないことです。 +つまりインスタンスとホストが通信する必要がある場合は`macvlan`は使えません。 + +そのような場合は、`bridge`デバイスを選ぶのが良いでしょう。 +`macvlan`では使えない MAC フィルタリングと I/O 制限も使えます。 + +`ipvlan`は`macvlan`と同様ですが、フォークされたデバイスが静的に割り当てられた IP アドレスを持ち、ネットワーク上の親の MAC アドレスを受け継ぐ点が異なります。 diff --git a/doc/reference/devices_none.md b/doc/reference/devices_none.md index 3fceb69e29c..76f8cfe2ca9 100644 --- a/doc/reference/devices_none.md +++ b/doc/reference/devices_none.md @@ -1,13 +1,13 @@ (devices-none)= -# Type: `none` +# タイプ: `none` ```{note} -The `none` device type is supported for both containers and VMs. +`none`デバイスタイプはコンテナとVMの両方でサポートされます。 ``` -A `none` device doesn't have any properties and doesn't create anything inside the instance. +`none`タイプのデバイスはプロパティを一切持たず、インスタンス内に何も作成しません。 -Its only purpose is to stop inheriting devices that come from profiles. -To do so, add a device with the same name as the one that you do not want to inherit, but with the device type `none`. +これはプロファイルからのデバイスの継承を止めるためだけに存在します。 +そうするには、継承をスキップしたいデバイスと同じ名前の`none`タイプのデバイスを追加してください。 -You can add this device either in a profile that is applied after the profile that contains the original device, or directly on the instance. +デバイスは、元のデバイスを含むプロファイルより後に適用するプロファイルに追加するか、インスタンス上に直接追加できます。 diff --git a/doc/reference/devices_pci.md b/doc/reference/devices_pci.md index 76de8f81f0f..bc5831248fe 100644 --- a/doc/reference/devices_pci.md +++ b/doc/reference/devices_pci.md @@ -1,20 +1,20 @@ (devices-pci)= -# Type: `pci` +# タイプ: `pci` ```{note} -The `pci` device type is supported for VMs. -It does not support hotplugging. +`pci`デバイスタイプは VM でサポートされます。 +ホットプラグはサポートされません。 ``` -PCI devices are used to pass raw PCI devices from the host into a virtual machine. +PCI デバイスは生の PCI デバイスをホストから仮想マシンにパススルーするために使用されます。 -They are mainly intended to be used for specialized single-function PCI cards like sound cards or video capture cards. -In theory, you can also use them for more advanced PCI devices like GPUs or network cards, but it's usually more convenient to use the specific device types that Incus provides for these devices ([`gpu` device](devices-gpu) or [`nic` device](devices-nic)). +これらや主にサウンドカードやビデオキャプチャーカードのような特別な単一機能の PCI カードに使われることを意図しています。 +理論上は、GPU やネットワークカードなどより高度な PCI デバイスも使用できますが、通常はそれらのデバイスのために Incus が提供する個別のデバイスタイプ（[`gpu`デバイス](devices-gpu)や[`nic` デバイス](devices-nic)）を使うほうがより便利です。 -## Device options +## デバイスオプション -`pci` devices have the following device options: +`pci` デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Required | Description -:-- | :-- | :-- | :-- | :-- -`address` | string | - | yes | PCI address of the device +キー | 型 | デフォルト値 | 必須 | 説明 +:-- | :-- | :-- | :-- | :-- +`address` | string | - | yes | デバイスのPCIアドレス diff --git a/doc/reference/devices_proxy.md b/doc/reference/devices_proxy.md index 74e6325c093..e144c2aeef0 100644 --- a/doc/reference/devices_proxy.md +++ b/doc/reference/devices_proxy.md @@ -1,18 +1,18 @@ (devices-proxy)= -# Type: `proxy` +# タイプ: `proxy` ```{note} -The `proxy` device type is supported for both containers (NAT and non-NAT modes) and VMs (NAT mode only). -It supports hotplugging for both containers and VMs. +`proxy`デバイスタイプはコンテナ（NAT と非 NAT モード）と VM（NAT モードのみ）でサポートされます。 +コンテナと VM の両方でホットプラグをサポートします。 ``` -Proxy devices allow forwarding network connections between host and instance. -This method makes it possible to forward traffic hitting one of the host's addresses to an address inside the instance, or to do the reverse and have an address in the instance connect through the host. +プロキシデバイスにより、ホストとインスタンス間のネットワーク接続を転送できます。 +この方法で、ホストのアドレスの一つに到達したトラフィックをインスタンス内のアドレスに転送したり、その逆でインスタンス内にアドレスを持ちホストを通して接続することができます。 -In {ref}`devices-proxy-nat-mode`, a proxy device can be used for TCP and UDP proxying. -In non-NAT mode, you can also proxy traffic between Unix sockets (which can be useful to, for example, forward graphical GUI or audio traffic from the container to the host system) or even across protocols (for example, you can have a TCP listener on the host system and forward its traffic to a Unix socket inside a container). +{ref}`devices-proxy-nat-mode`では、プロキシデバイスを TCP と UDP のプロキシに使用することができます。 +NAT モードではない場合、Unix ソケット間のトラフィックをプロキシすることもできます（これはたとえば、コンテナからホストシステムへのグラフィカルな GUI やオーディオトラフィックを転送するのに便利です）。また、プロトコル間でもプロキシすることができます（たとえば、ホストシステム上に TCP リスナーを設置し、そのトラフィックをコンテナ内の Unix ソケットに転送することができます）。 -The supported connection types are: +利用できる接続タイプは次の通りです: - `tcp <-> tcp` - `udp <-> udp` @@ -24,57 +24,57 @@ The supported connection types are: - `udp <-> unix` - `unix <-> udp` -To add a `proxy` device, use the following command: +`proxy`デバイスを追加するには、以下のコマンドを使用します: incus config device add proxy listen=::[-][,] connect=:: bind= (devices-proxy-nat-mode)= -## NAT mode +## NATモード -The proxy device also supports a NAT mode (`nat=true`), where packets are forwarded using NAT rather than being proxied through a separate connection. -This mode has the benefit that the client address is maintained without the need for the target destination to support the HAProxy PROXY protocol (which is the only way to pass the client address through when using the proxy device in non-NAT mode). +プロキシデバイスは NAT モード（`nat=true`）もサポートします。NAT モードではパケットは別の接続を通してプロキシされるのではなく NAT を使ってフォワードされます。 +これはターゲットの送り先が HAProxy の PROXY プロトコル（非 NAT モードでプロキシデバイスを使う場合はこれはクライアントアドレスを渡す唯一の方法です）をサポートする必要なく、クライアントのアドレスを維持できるという利点があります。 -However, NAT mode is supported only if the host that the instance is running on is the gateway (which is the case if you're using `incusbr0`, for example). +しかし、NAT モードはインスタンスが稼働しているホストがゲートウェイの場合（たとえば `incusbr0`を使用しているケース）のみサポートされます。 -In NAT mode, the supported connection types are: +NAT モードでサポートされる接続のタイプは以下の通りです: - `tcp <-> tcp` - `udp <-> udp` -When configuring a proxy device with `nat=true`, you must ensure that the target instance has a static IP configured on its NIC device. +プロキシデバイスを`nat=true`に設定する際は、以下のようにターゲットのインスタンスが NIC デバイス上に静的 IP を持つようにする必要があります。 -## Specifying IP addresses +## IPアドレスを指定する -Use the following command to configure a static IP for an instance NIC: +インスタンス NIC に静的 IP を設定するには、以下のコマンドを使用します: incus config device set ipv4.address= ipv6.address= -To define a static IPv6 address, the parent managed network must have `ipv6.dhcp.stateful` enabled. +静的な IPv6 アドレスを設定するためには、親のマネージドネットワークは`ipv6.dhcp.stateful`を有効にする必要があります。 -When defining IPv6 addresses, use the square bracket notation, for example: +IPv6 アドレスを設定する場合は以下のような角括弧の記法を使います。たとえば以下のようにします: connect=tcp:[2001:db8::1]:80 -You can specify that the connect address should be the IP of the instance by setting the connect IP to the wildcard address (`0.0.0.0` for IPv4 and `[::]` for IPv6). +connect のアドレスをワイルドカード（IPv4 では 0.0.0.0、IPv6 では[::]にします）に設定することで、接続アドレスをインスタンスの IP アドレスになるように指定できます。 ```{note} -The listen address can also use wildcard addresses when using non-NAT mode. -However, when using NAT mode, you must specify an IP address on the Incus host. +listen のアドレスも非 NAT モードではワイルドカードのアドレスが使用できます。 +しかし、NAT モードを使う際は Incus ホスト上の IP アドレスを指定する必要があります。 ``` -## Device options - -`proxy` devices have the following device options: - -Key | Type | Default | Required | Description -:-- | :-- | :-- | :-- | :-- -`bind` | string | `host` | no | Which side to bind on (`host`/`instance`) -`connect` | string | - | yes | The address and port to connect to (`::[-][,]`) -`gid` | int | `0` | no | GID of the owner of the listening Unix socket -`listen` | string | - | yes | The address and port to bind and listen (`::[-][,]`) -`mode` | int | `0644` | no | Mode for the listening Unix socket -`nat` | bool | `false` | no | Whether to optimize proxying via NAT (requires that the instance NIC has a static IP address) -`proxy_protocol`| bool | `false` | no | Whether to use the HAProxy PROXY protocol to transmit sender information -`security.gid` | int | `0` | no | What GID to drop privilege to -`security.uid` | int | `0` | no | What UID to drop privilege to -`uid` | int | `0` | no | UID of the owner of the listening Unix socket +## デバイスオプション + +`proxy` デバイスには以下のデバイスオプションがあります: + +キー | 型 | デフォルト値 | 必須 | 説明 +:-- | :-- | :-- | :-- | :-- +`bind` | string | `host` | no | どちら側にバインドするか（`host`/`instance`） +`connect` | string | - | yes | 接続するアドレスとポート（`::[-][,]`） +`gid` | int | `0` | no | listenするUnixソケットの所有者のGID +`listen` | string | - | yes | バインドし、接続を待ち受けるアドレスとポート（`::[-][,]`） +`mode` | int | `0644` | no | listenするUnixソケットのモード +`nat` | bool | `false` | no | NAT経由でプロキシを最適化するかどうか（インスタンスのNICが静的IPを持つ必要あり） +`proxy_protocol` | bool | `false` | no | 送信者情報を送信するのに HAProxy の PROXY プロトコルを使用するかどうか +`security.gid` | int | `0` | no | 特権を落とすGID +`security.uid` | int | `0` | no | 特権を落とすUID +`uid` | int | `0` | no | listenするUnixソケットの所有者のUID diff --git a/doc/reference/devices_tpm.md b/doc/reference/devices_tpm.md index 328d9dbb70b..9390f6688dc 100644 --- a/doc/reference/devices_tpm.md +++ b/doc/reference/devices_tpm.md @@ -1,24 +1,24 @@ (devices-tpm)= -# Type: `tpm` +# タイプ: `tpm` ```{note} -The `tpm` device type is supported for both containers and VMs. -It supports hotplugging only for containers, not for VMs. +`tpm`デバイスタイプは、コンテナと VM の両方でサポートされています。 +ただし、コンテナではホットプラグがサポートされていますが、VM ではサポートされていません。 ``` -TPM devices enable access to a {abbr}`TPM (Trusted Platform Module)` emulator. +TPM デバイスは、{abbr}`TPM (Trusted Platform Module)`エミュレータへのアクセスを有効にします。 -TPM devices can be used to validate the boot process and ensure that no steps in the boot chain have been tampered with, and they can securely generate and store encryption keys. +TPM デバイスは、ブートプロセスを検証し、ブートチェーンのステップが改ざんされていないことを確認するために使用できます。また、暗号化キーを安全に生成および保存することもできます。 -Incus uses a software TPM that supports TPM 2.0. -For containers, the main use case is sealing certificates, which means that the keys are stored outside of the container, making it virtually impossible for attackers to retrieve them. -For virtual machines, TPM can be used both for sealing certificates and for validating the boot process, which allows using full disk encryption compatible with, for example, Windows BitLocker. +Incus は、TPM 2.0 をサポートするソフトウェア TPM を使用します。 +コンテナの主な使用例は、証明書のシールで、これによりキーがコンテナの外部に保存され、攻撃者がそれらを取得することがほぼ不可能になります。 +仮想マシンでは、TPM を証明書のシールに使用するだけでなく、ブートプロセスの検証にも使用できます。これにより、たとえば、Windows BitLocker と互換性のあるフルディスク暗号化が可能になります。 -## Device options +## デバイスオプション -`tpm` devices have the following device options: +`tpm`デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Required | Description -:-- | :-- | :-- | :-- | :-- -`path` | string | - | for containers | Only for containers: path inside the instance (for example, `/dev/tpm0`) -`pathrm` | string | - | for containers | Only for containers: resource manager path inside the instance (for example, `/dev/tpmrm0`) +キー | 型 | デフォルト値 | 必須 | 説明 +:-- | :-- | :-- | :-- | :-- +`path` | string | - | コンテナでは必須 | コンテナのみ: インスタンス内でのパス（例:`/dev/tpm0`） +`pathrm` | string | - | コンテナでは必須 | コンテナのみ: インスタンス内でのリソースマネージャのパス（例:`dev/tpmrm0`） diff --git a/doc/reference/devices_unix_block.md b/doc/reference/devices_unix_block.md index 9992996811d..0f7194c59a0 100644 --- a/doc/reference/devices_unix_block.md +++ b/doc/reference/devices_unix_block.md @@ -1,33 +1,35 @@ (devices-unix-block)= -# Type: `unix-block` +# タイプ: `unix-block` ```{note} -The `unix-block` device type is supported for containers. -It supports hotplugging. +`unix-block`デバイスタイプはコンテナでサポートされます。 +ホットプラグをサポートします。 ``` -Unix block devices make the specified block device appear as a device in the instance (under `/dev`). -You can read from the device and write to it. +Unix ブロックデバイスは、指定したブロックデバイスをインスタンス内の（`/dev`以下の）デバイスとして出現させます。 +そのデバイスから読み取りやデバイスへ書き込みができます。 -## Device options +## デバイスオプション -`unix-block` devices have the following device options: +`unix-block`デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`gid` | int | `0` | GID of the device owner in the instance -`major` | int | device on host | Device major number -`minor` | int | device on host | Device minor number -`mode` | int | `0660` | Mode of the device in the instance -`path` | string | - | Path inside the instance (one of `source` and `path` must be set) -`required` | bool | `true` | Whether this device is required to start the instance (see {ref}`devices-unix-block-hotplugging`) -`source` | string | - | Path on the host (one of `source` and `path` must be set) -`uid` | int | `0` | UID of the device owner in the instance +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`gid` | int | `0` | インスタンス内のデバイス所有者のGID +`major` | int | ホスト上のデバイス | デバイスのメジャー番号 +`minor` | int | ホスト上のデバイス | デバイスのマイナー番号 +`mode` | int | `0660` | インスタンス内のデバイスのモード +`path` | string | - | インスタンス内のパス（`source`と`path`のどちらかを設定しなければいけません） +`required` | bool | `true` | このデバイスがインスタンスの起動に必要かどうか（{ref}`devices-unix-block-hotplugging`参照） +`source` | string | - | ホスト上のパス（`source`と`path`のどちらかを設定しなければいけません） +`uid` | int | `0` | インスタンス内のデバイス所有者の UID (devices-unix-block-hotplugging)= -## Hotplugging +## ホットプラグ -Hotplugging is enabled if you set `required=false` and specify the `source` option for the device. + -In this case, the device is automatically passed into the container when it appears on the host, even after the container starts. -If the device disappears from the host system, it is removed from the container as well. +ホットプラグは`required=false`を設定しデバイスの`source`オプションを指定した場合に有効になります。 + +この場合、デバイスはホスト上で出現したときに、コンテナの起動後であっても、自動的にコンテナにパススルーされます。 +ホストシステムからデバイスが消えると、コンテナからも消えます。 diff --git a/doc/reference/devices_unix_char.md b/doc/reference/devices_unix_char.md index e5d35f439ef..6cc50468d73 100644 --- a/doc/reference/devices_unix_char.md +++ b/doc/reference/devices_unix_char.md @@ -1,33 +1,33 @@ (devices-unix-char)= -# Type: `unix-char` +# タイプ: `unix-char` ```{note} -The `unix-char` device type is supported for containers. -It supports hotplugging. +`unix-char`デバイスタイプはコンテナでサポートされます。 +ホットプラグをサポートします。 ``` -Unix character devices make the specified character device appear as a device in the instance (under `/dev`). -You can read from the device and write to it. +Unix キャラクタデバイスは、指定したキャラクタデバイスをインスタンス内の（`/dev`以下の）デバイスとして出現させます。 +そのデバイスから読み取りやデバイスへ書き込みができます。 -## Device options +## デバイスオプション -`unix-char` devices have the following device options: +`unix-char`デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`gid` | int | `0` | GID of the device owner in the instance -`major` | int | device on host | Device major number -`minor` | int | device on host | Device minor number -`mode` | int | `0660` | Mode of the device in the instance -`path` | string | - | Path inside the instance (one of `source` and `path` must be set) -`required` | bool | `true` | Whether this device is required to start the instance (see {ref}`devices-unix-char-hotplugging`) -`source` | string | - | Path on the host (one of `source` and `path` must be set) -`uid` | int | `0` | UID of the device owner in the instance +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`gid` | int | `0` | インスタンス内のデバイス所有者のGID +`major` | int | ホスト上のデバイス | デバイスのメジャー番号 +`minor` | int | ホスト上のデバイス | デバイスのマイナー番号 +`mode` | int | `0660` | インスタンス内のデバイスのモード +`path` | string | - | インスタンス内のパス（`source`と`path`のどちらかを設定しなければいけません） +`required` | bool | `true` | このデバイスがインスタンスの起動に必要かどうか（{ref}`devices-unix-char-hotplugging`参照） +`source` | string | - | ホスト上のパス（`source`と`path`のどちらかを設定しなければいけません） +`uid` | int | `0` | インスタンス内のデバイス所有者の UID (devices-unix-char-hotplugging)= -## Hotplugging +## ホットプラグ % Include content from [devices_unix_block.md](device_unix_block.md) ```{include} devices_unix_block.md - :start-after: Hotplugging + :start-after: Hotplugging --> ``` diff --git a/doc/reference/devices_unix_hotplug.md b/doc/reference/devices_unix_hotplug.md index c5241971a6e..d46975188e4 100644 --- a/doc/reference/devices_unix_hotplug.md +++ b/doc/reference/devices_unix_hotplug.md @@ -1,25 +1,25 @@ (devices-unix-hotplug)= -# Type: `unix-hotplug` +# タイプ: `unix-hotplug` ```{note} -The `unix-hotplug` device type is supported for containers. -It supports hotplugging. +`unix-hotplug`デバイスタイプはコンテナでサポートされます。 +ホットプラグをサポートします。 ``` -Unix hotplug devices make the requested Unix device appear as a device in the instance (under `/dev`). -If the device exists on the host system, you can read from it and write to it. +Unix ホットプラグデバイスは、指定した Unix デバイスをインスタンス内の（`/dev`以下の）デバイスとして出現させます。 +デバイスがホストシステム上にある場合は、デバイスから読み取りやデバイスへ書き込みができます。 -The implementation depends on `systemd-udev` to be run on the host. +実装はホスト上で稼働する`systemd-udev`に依存します。 -## Device options +## デバイスオプション -`unix-hotplug` devices have the following device options: +`unix-hotplug`デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`gid` | int | `0` | GID of the device owner in the instance -`mode` | int | `0660` | Mode of the device in the instance -`productid` | string | - | The product ID of the Unix device -`required` | bool | `false` | Whether this device is required to start the instance (the default is `false`, and all devices can be hotplugged) -`uid` | int | `0` | UID of the device owner in the instance -`vendorid` | string | - | The vendor ID of the Unix device +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`gid` | int | `0` | インスタンス内でのデバイスオーナーのGID +`mode` | int | `0660` | インスタンス内でのデバイスのモード +`productid` | string | - | Unixデバイスの製品ID +`required` | bool | `false` | このデバイスがインスタンスを起動するのに必要かどうか（デフォルトは`false`で、すべてのデバイスはホットプラグ可能です） +`uid` | int | `0` | インスタンス内でのデバイスオーナーのUID +`vendorid` | string | - | UnixデバイスのベンダーID diff --git a/doc/reference/devices_usb.md b/doc/reference/devices_usb.md index de2b163ec72..69ff5b6176b 100644 --- a/doc/reference/devices_usb.md +++ b/doc/reference/devices_usb.md @@ -1,30 +1,30 @@ (devices-usb)= -# Type: `usb` +# タイプ: `usb` ```{note} -The `usb` device type is supported for both containers and VMs. -It supports hotplugging for both containers and VMs. +`usb`デバイスタイプはコンテナと VM の両方でサポートされます。 +コンテナと VM の両方でホットプラグをサポートします。 ``` -USB devices make the specified USB device appear in the instance. -For performance issues, avoid using devices that require high throughput or low latency. +USB デバイスは、指定された USB デバイスをインスタンスに出現させます。 +パフォーマンスの問題のため、高スループットまたは低レイテンシを要求するデバイスの使用は避けてください。 -For containers, only `libusb` devices (at `/dev/bus/usb`) are passed to the instance. -This method works for devices that have user-space drivers. -For devices that require dedicated kernel drivers, use a [`unix-char` device](devices-unix-char) or a [`unix-hotplug` device](devices-unix-hotplug) instead. +コンテナでは、（`/dev/bus/usb`にある）`libusb`デバイスのみがインスタンスに渡されます。 +この方法はユーザースペースのドライバーを持つデバイスで機能します。 +専用のカーネルドライバーを必要とするデバイスは、代わりに[`unix-char`デバイス](devices-unix-char)か[`unix-hotplug`デバイス](devices-unix-hotplug)を使用してください。 -For virtual machines, the entire USB device is passed through, so any USB device is supported. -When a device is passed to the instance, it vanishes from the host. +仮想マシンでは、USB デバイス全体がパススルーされますので、あらゆる USB デバイスがサポートされます。 +デバイスがインスタンスに渡されると、ホストからは消失します。 -## Device options +## デバイスオプション -`usb` devices have the following device options: +`usb`デバイスには以下のデバイスオプションがあります: -Key | Type | Default | Description -:-- | :-- | :-- | :-- -`gid` | int | `0` | Only for containers: GID of the device owner in the instance -`mode` | int | `0660` | Only for containers: Mode of the device in the instance -`productid` | string | - | The product ID of the USB device -`required` | bool | `false` | Whether this device is required to start the instance (the default is `false`, and all devices can be hotplugged) -`uid` | int | `0` | Only for containers: UID of the device owner in the instance -`vendorid` | string | - | The vendor ID of the USB device +キー | 型 | デフォルト値 | 説明 +:-- | :-- | :-- | :-- +`gid` | int | `0` | コンテナのみ: インスタンス内のデバイス所有者のGID +`mode` | int | `0660` | コンテナのみ: インスタンス内のデバイスのモード +`productid` | string | - | USBデバイスのプロダクトID +`required` | bool | `false` | このデバイスがインスタンスの起動に必要かどうか（デフォルトは`false`で、すべてのデバイスがホットプラグ可能です） +`uid` | int | `0` | コンテナのみ: インスタンス内のデバイス所有者のUID +`vendorid` | string | - | USBデバイスのベンダーID diff --git a/doc/reference/image_format.md b/doc/reference/image_format.md index 64b52eb1122..bec997c359e 100644 --- a/doc/reference/image_format.md +++ b/doc/reference/image_format.md @@ -1,14 +1,14 @@ (image-format)= -# Image format +# イメージ形式 -Images contain a root file system and a metadata file that describes the image. -They can also contain templates for creating files inside an instance that uses the image. +イメージはルートファイルシステムとイメージを記述するメタデータファイルを含みます。 +またイメージを使用するインスタンス内部でファイルを生成するためのテンプレートも含められます。 -Images can be packaged as either a unified image (single file) or a split image (two files). +イメージは統合イメージ（単一ファイル）か分離イメージ（2 つのファイル）としてパッケージできます。 -## Content +## 中身 -Images for containers have the following directory structure: +コンテナのイメージは以下のディレクトリー構造を持ちます: ``` metadata.yaml @@ -16,7 +16,7 @@ rootfs/ templates/ ``` -Images for VMs have the following directory structure: +仮想マシンのイメージは以下のディレクトリー構造を持ちます: ``` metadata.yaml @@ -24,12 +24,12 @@ rootfs.img templates/ ``` -For both instance types, the `templates/` directory is optional. +どちらのインスタンスタイプでも、`templates/`ディレクトリーは省略可能です。 -### Metadata +### メタデータ -The `metadata.yaml` file contains information that is relevant to running the image in Incus. -It includes the following information: +`metadata.yaml`ファイルはイメージが Incus 内で稼働するために関連する情報を含みます。 +以下の情報を含んでいます: ```yaml architecture: x86_64 @@ -42,32 +42,32 @@ templates: ... ``` -The `architecture` and `creation_date` fields are mandatory. -The `properties` field contains a set of default properties for the image. -The `os`, `release`, `name` and `description` fields are commonly used, but are not mandatory. +`architecture`と`creation_date`フィールドは必須です。 +`properties`フィールドはイメージのデフォルトプロパティのセットを含みます。 +`os`, `release`, `name`, `description`フィールドはよく使われますが、必須ではありません。 -The `templates` field is optional. -See {ref}`image_format_templates` for information on how to configure templates. +`templates`フィールドは省略可能です。 +テンプレートをどのように設定するかの情報は{ref}`image_format_templates`を参照してください。 -### Root file system +### ルートファイルシステム -For containers, the `rootfs/` directory contains a full file system tree of the root directory (`/`) in the container. +コンテナでは、`rootfs/`ディレクトリーがコンテナ内のルートディレクトリー（`/`）の完全なファイルシステムツリーを含みます。 -Virtual machines use a `rootfs.img` `qcow2` file instead of a `rootfs/` directory. -This file becomes the main disk device. +仮想マシンは`rootfs/`ディレクトリーの代わりに`rootfs.img` `qcow2`ファイルを使います。 +このファイルはメインのディスクデバイスになります。 (image_format_templates)= -### Templates (optional) +### テンプレート（省略可能＿ -You can use templates to dynamically create files inside an instance. -To do so, configure template rules in the `metadata.yaml` file and place the template files in a `templates/` directory. +インスタンス内部でファイルを動的に作成するのにテンプレートを使用できます。 +そのためには、`metadata.yaml`ファイル内でテンプレートルールを設定し、`templates/`ディレクトリー内にテンプレートファイルを配置します。 -As a general rule, you should never template a file that is owned by a package or is otherwise expected to be overwritten by normal operation of an instance. +一般的なルールとして、パッケージに所有されるファイルはテンプレート化は決してするべきではないです。そうでないとインスタンスの通常のオペレーションで上書きされてしまうでしょう。 -#### Template rules +#### テンプレートルール -For each file that should be generated, create a rule in the `metadata.yaml` file. -For example: +生成すべき各ファイルに対して、`metadata.yaml`ファイル内でルールを作成します。 +たとえば: ```yaml templates: @@ -89,66 +89,66 @@ templates: create_only: true ``` -The `when` key can be one or more of: +`when`キーは以下の 1 つ以上を指定できます: -- `create` - run at the time a new instance is created from the image -- `copy` - run when an instance is created from an existing one -- `start` - run every time the instance is started +- `create` - 新規インスタンスがイメージから作成された時に実行 +- `copy` - 既存インスタンスからインスタンスが作成されたときに実行 +- `start` - インスタンスが開始する度に毎回実行 -The `template` key points to the template file in the `templates/` directory. +`template`キーは`templates/`ディレクトリー内のテンプレートファイルを指します。 -You can pass user-defined template properties to the template file through the `properties` key. +`properties`キーでユーザー定義のテンプレートプロパティをテンプレートファイルに渡せます。 -Set the `create_only` key if you want Incus to create the file if it doesn't exist, but not overwrite an existing file. +ファイルが存在しない場合にのみ Incus にファイルを作らせ、ファイルが存在する場合は上書きしてほしくない場合は、`create_only`キーをセットします。 -#### Template files +#### テンプレートファイル -Template files use the [Pongo2](https://www.schlachter.tech/solutions/pongo2-template-engine/) format. +テンプレートファイルは[Pongo2](https://www.schlachter.tech/solutions/pongo2-template-engine/)形式を使います。 -They always receive the following context: +テンプレートファイルは常に以下のコンテキストを受け取ります。 -| Variable | Type | Description | -|--------------|--------------------------------|-------------------------------------------------------------------------------------| -| `trigger` | `string` | Name of the event that triggered the template | -| `path` | `string` | Path of the file that uses the template | -| `instance` | `map[string]string` | Key/value map of instance properties (name, architecture, privileged and ephemeral) | -| `config` | `map[string]string` | Key/value map of the instance's configuration | -| `devices` | `map[string]map[string]string` | Key/value map of the devices assigned to the instance | -| `properties` | `map[string]string` | Key/value map of the template properties specified in `metadata.yaml` | +| 変数 | 型 | 説明 +| -------------- | -------------------------------- | ------------------------------------------------------------------------------------- | +| `trigger` | `string` | テンプレートをトリガーしたイベント名 | +| `path` | `string` | テンプレートを使用するファイルのパス | +| `instance` | `map[string]string` | インスタンスプロパティのキー/値マップ（名前、アーキテクチャ、特権、一時的） | +| `config` | `map[string]string` | インスタンス設定のキー/値マップ | +| `devices` | `map[string]map[string]string` | インスタンスに割り当てられたデバイスのキー/値マップ | +| `properties` | `map[string]string` | `metadata.yaml`で指定されたテンプレートプロパティのキー/値マップ | -For convenience, the following functions are exported to the Pongo2 templates: +利便性のため、以下の関数が Pongo2 テンプレートにエクスポートされます。 -- `config_get("user.foo", "bar")` - Returns the value of `user.foo`, or `"bar"` if not set. +- `config_get("user.foo", "bar")` - `user.foo`の値か、未設定の場合は`"bar"`を返します。 -## Image tarballs +## イメージのtarball -Incus supports two Incus-specific image formats: a unified tarball and split tarballs. +Incus は 2 種類の Incus 固有のイメージ形式、統合 tarball と分離 tarball をサポートします。 -These tarballs can be compressed. -Incus supports a wide variety of compression algorithms for tarballs. -However, for compatibility purposes, you should use `gzip` or `xz`. +これらの tarball は圧縮されていても構いません。 +Incus は tarball の広範囲の圧縮アルゴリズムをサポートします。 +しかし、互換性のためには`gzip`または`xz`を使うのが良いです。 (image-format-unified)= -### Unified tarball +### 統合tarball -A unified tarball is a single tarball (usually `*.tar.xz`) that contains the full content of the image, including the metadata, the root file system and optionally the template files. +統合 tarball は単一の tarball（通常`*.tar.xz`）で、イメージの完全な中身を含みます。それにはメタデータ、ルートファイルシステムと省略可能なテンプレートファイルが含まれます。 -This is the format that Incus itself uses internally when publishing images. -It is usually easier to work with; therefore, you should use the unified format when creating Incus-specific images. +これが Incus 自身がイメージを公開する際に内部的に使用している形式です。 +通常こちらのほうが扱いやすいので、Incus 固有のイメージを作る際は統合形式を使うのが良いです。 -The image identifier for such images is the SHA-256 of the tarball. +この形式のイメージの識別子は tarball の SHA-256 ハッシュ値です。 (image-format-split)= -### Split tarballs +### 分離tarball -A split image consists of two separate tarballs. -One tarball contains the metadata and optionally the template files (usually `*.tar.xz`), and the other contains the root file system (usually `*.squashfs` for containers or `*.qcow2` for virtual machines). +分離イメージは 2 つの分離した tarball から構成されます。 +1 つの tarball（通常`*.tar.xz`）はメタデータと省略可能なテンプレートファイルを含み、もう 1 つ（通常、コンテナでは`*.squashfs`で仮想マシンでは`*.qcow2`）はルートファイルシステムを含みます。 -For containers, the root file system tarball can be SquashFS-formatted. -For virtual machines, the `rootfs.img` file always uses the `qcow2` format. -It can optionally be compressed using `qcow2`'s native compression. +コンテナでは、ルートファイルシステムの tarball は SquashFS でフォーマットされていても構いません。 +仮想マシンでは、`rootfs.img`ファイルは常に`qcow2`形式を使用します。 +任意で`qcow2`のネイティブ圧縮を使って圧縮しても構いません。 -This format is designed to allow for easy image building from existing non-Incus rootfs tarballs that are already available. -You should also use this format if you want to create images that can be consumed by both Incus and other tools. +この形式は既に利用可能である既存の Incus 以外の rootfs tarball から簡単にイメージをビルドできるように設計されています。 +Incus と他のツールの両方で使用するイメージを作りたい場合もこの形式を使うのが良いです。 -The image identifier for such images is the SHA-256 of the concatenation of the metadata and root file system tarball (in that order). +この形式のイメージの識別子はメタデータとルートファイルシステム tarball を（この順で）結合したものの SHA-256 ハッシュ値です。 diff --git a/doc/reference/instance_options.md b/doc/reference/instance_options.md index 94d6dae24ad..86dd55875a0 100644 --- a/doc/reference/instance_options.md +++ b/doc/reference/instance_options.md @@ -1,16 +1,16 @@ (instance-options)= -# Instance options +# インスタンスオプション -Instance options are configuration options that are directly related to the instance. +インスタンスオプションはインスタンスに直接関係する設定オプションです。 -See {ref}`instances-configure-options` for instructions on how to set the instance options. +インスタンスオプションをどのように設定するかの手順は{ref}`instances-configure-options`を参照してください。 -The key/value configuration is namespaced. -The following options are available: +key/value 形式の設定は、名前空間で分けられています。 +以下のオプションが利用できます: - {ref}`instance-options-misc` - {ref}`instance-options-boot` -- [`cloud-init` configuration](instance-options-cloud-init) +- [`cloud-init` 設定](instance-options-cloud-init) - {ref}`instance-options-limits` - {ref}`instance-options-migration` - {ref}`instance-options-nvidia` @@ -19,12 +19,13 @@ The following options are available: - {ref}`instance-options-snapshots` - {ref}`instance-options-volatile` -Note that while a type is defined for each option, all values are stored as strings and should be exported over the REST API as strings (which makes it possible to support any extra values without breaking backward compatibility). + +各オプションに型が定義されていますが、すべての値は文字列として保管され、REST API で文字列としてエクスポートされる（こうすることで後方互換性を壊すことなく任意の追加の値をサポートできます）ことに注意してください。 (instance-options-misc)= -## Miscellaneous options +## その他のオプション -In addition to the configuration options listed in the following sections, these instance options are supported: +以下のセクションに一覧表示される設定オプションに加えて、以下のインスタンスオプションがサポートされます: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -35,16 +36,16 @@ In addition to the configuration options listed in the following sections, these ```{config:option} environment.* instance-miscellaneous :type: "string" :liveupdate: "yes (exec)" -:shortdesc: "Environment variables for the instance" +:shortdesc: "インスタンスのための環境変数" -You can export key/value environment variables to the instance. -These are then set for [`incus exec`](incus_exec.md). +key/value の環境変数をインスタンスにエクスポートできます。 +これらはその後 [`incus exec`](incus_exec.md) に設定されます。 ``` (instance-options-boot)= -## Boot-related options +## ブート関連のオプション -The following instance options control the boot-related behavior of the instance: +以下のインスタンスオプションはインスタンスのブート関連の挙動を制御します: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -53,9 +54,9 @@ The following instance options control the boot-related behavior of the instance ``` (instance-options-cloud-init)= -## `cloud-init` configuration +## `cloud-init` 設定 -The following instance options control the [`cloud-init`](cloud-init) configuration of the instance: +以下のインスタンスオプションはインスタンスの[`cloud-init`](cloud-init)設定を制御します: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -63,15 +64,15 @@ The following instance options control the [`cloud-init`](cloud-init) configurat :end-before: ``` -Support for these options depends on the image that is used and is not guaranteed. +これらのオプションのサポートは使用するイメージに依存し、保証はされません。 -If you specify both `cloud-init.user-data` and `cloud-init.vendor-data`, the content of both options is merged. -Therefore, make sure that the `cloud-init` configuration you specify in those options does not contain the same keys. +`cloud-init.user-data`と`cloud-init.vendor-data`の両方を指定すると、両方のオプションの設定がマージされます。 +このため、これらのオプションに設定する`cloud-init`設定が同じキーを含まないようにしてください。 (instance-options-limits)= -## Resource limits +## リソース制限 -The following instance options specify resource limits for the instance: +以下のインスタンスオプションはインスタンスのリソース制限を指定します: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -83,139 +84,140 @@ The following instance options specify resource limits for the instance: :type: "string" :liveupdate: "no" :condition: "container" -:shortdesc: "Kernel resources per instance" +:shortdesc: "インスタンスごとのカーネルリソース" -You can set kernel limits on an instance, for example, you can limit the number of open files. -See {ref}`instance-options-limits-kernel` for more information. +インスタンスにカーネルの制限を設定できます、たとえば、オープンできるファイル数を制限できます。 +詳細は {ref}`instance-options-limits-kernel` を参照してください。 ``` -### CPU limits +### PU制限 -You have different options to limit CPU usage: +CPU 使用率を制限するための異なるオプションがあります: -- Set `limits.cpu` to restrict which CPUs the instance can see and use. - See {ref}`instance-options-limits-cpu` for how to set this option. -- Set `limits.cpu.allowance` to restrict the load an instance can put on the available CPUs. - This option is available only for containers. - See {ref}`instance-options-limits-cpu-container` for how to set this option. +- `limits.cpu`を設定して、インスタンスが見ることができ、使用することができる CPU を制限します。 + このオプションの設定方法は、{ref}`instance-options-limits-cpu`を参照してください。 +- `limits.cpu.allowance`を設定して、インスタンスが利用可能な CPU にかける負荷を制限します。 + このオプションはコンテナのみで利用可能です。 + このオプションの設定方法は、{ref}`instance-options-limits-cpu-container`を参照してください。 -It is possible to set both options at the same time to restrict both which CPUs are visible to the instance and the allowed usage of those instances. -However, if you use `limits.cpu.allowance` with a time limit, you should avoid using `limits.cpu` in addition, because that puts a lot of constraints on the scheduler and might lead to less efficient allocations. +これらのオプションは同時に設定して、インスタンスが見ることができる CPU とそれらのインスタンスの許可される使用量の両方を制限することが可能です。 +しかし、`limits.cpu.allowance`を時間制限と共に使用する場合、スケジューラーに多くの制約をかけ、効率的な割り当てが難しくなる可能性があるため、`limits.cpu`の追加使用は避けるべきです。 -The CPU limits are implemented through a mix of the `cpuset` and `cpu` cgroup controllers. +CPU 制限は cgroup コントローラーの`cpuset`と`cpu`を組み合わせて実装しています。 (instance-options-limits-cpu)= -#### CPU pinning +#### CPUピンニング -`limits.cpu` results in CPU pinning through the `cpuset` controller. -You can specify either which CPUs or how many CPUs are visible and available to the instance: +`limits.cpu`は`cpuset`コントローラーを使って、CPU を固定（ピンニング）します。 +どの CPU を、またはどれぐらいの数の CPU を、インスタンスから見えるようにし、使えるようにするかを指定できます: -- To specify which CPUs to use, set `limits.cpu` to either a set of CPUs (for example, `1,2,3`) or a CPU range (for example, `0-3`). +- どの CPU を使うかを指定するには、`limits.cpu`を CPU の組み合わせ（例:`1,2,3`）あるいは CPU の範囲（例:`0-3`）で指定できます。 - To pin to a single CPU, use the range syntax (for example, `1-1`) to differentiate it from a number of CPUs. -- If you specify a number (for example, `4`) of CPUs, Incus will do dynamic load-balancing of all instances that aren't pinned to specific CPUs, trying to spread the load on the machine. - Instances are re-balanced every time an instance starts or stops, as well as whenever a CPU is added to the system. + 単一の CPU にピンニングするためには、CPU の個数との区別をつけるために、範囲を指定する文法（例:`1-1`）を使う必要があります。 +- CPU の個数を指定した場合（例:`4`）、Incus は特定の CPU にピンニングされていないすべてのインスタンスをダイナミックに負荷分散し、マシン上の負荷を分散しようとします。 + インスタンスが起動したり停止するたびに、またシステムに CPU が追加されるたびに、インスタンスはリバランスされます。 -##### CPU limits for virtual machines +##### 仮想マシンのCPUリミット ```{note} -Incus supports live-updating the `limits.cpu` option. -However, for virtual machines, this only means that the respective CPUs are hotplugged. -Depending on the guest operating system, you might need to either restart the instance or complete some manual actions to bring the new CPUs online. +Incus は`limits.cpu`オプションのライブアップデートをサポートします。 +しかし、仮想マシンの場合は、対応する CPU がホットプラグされるだけです。 +ゲストのオペレーティングシステムによって、新しい CPU をオンラインにするためには、インスタンスを再起動するか、なんらかの手動の操作を実行する必要があります。 ``` -Incus virtual machines default to having just one vCPU allocated, which shows up as matching the host CPU vendor and type, but has a single core and no threads. +Incus の仮想マシンはデフォルトでは 1 つの vCPU だけを割り当てられ、ホストの CPU のベンダーとタイプとマッチした CPU として現れますが、シングルコアでスレッドなしになります。 -When `limits.cpu` is set to a single integer, Incus allocates multiple vCPUs and exposes them to the guest as full cores. -Those vCPUs are not pinned to specific physical cores on the host. -The number of vCPUs can be updated while the VM is running. +`limits.cpu`を単一の整数に設定する場合、Incus は複数の vCPU を割り当ててゲストにはフルなコアとして公開します。 +これらの vCPU はホスト上の特定の物理コアにはピンニングされません。 +vCPU の個数は VM の稼働中に変更できます。 -When `limits.cpu` is set to a range or comma-separated list of CPU IDs (as provided by [`incus info --resources`](incus_info.md)), the vCPUs are pinned to those physical cores. -In this scenario, Incus checks whether the CPU configuration lines up with a realistic hardware topology and if it does, it replicates that topology in the guest. -When doing CPU pinning, it is not possible to change the configuration while the VM is running. +`limits.cpu`を CPU ID（[`incus info --resources`](incus_info.md) で表示されます）の範囲またはカンマ区切りリストの組に設定する場合、vCPU は物理コアにピンニングされます。 +このシナリオでは、Incus は CPU 設定が現実のハードウェアトポロジーとぴったり合うかチェックし、合う場合はそのトポロジーをゲスト内に複製します。 +CPU ピンニングを行う場合、VM の稼働中に設定を変更することはできません。 -For example, if the pinning configuration includes eight threads, with each pair of thread coming from the same core and an even number of cores spread across two CPUs, the guest will show two CPUs, each with two cores and each core with two threads. -The NUMA layout is similarly replicated and in this scenario, the guest would most likely end up with two NUMA nodes, one for each CPU socket. +たとえば、ピンニング設定が 8 個のスレッド、同じコアのスレッドの各ペアと 2 個の CPU に散在する偶数のコアを持つ場合、ゲストは 2 個の CPU、各 CPU に 2 個のコア、各コアに 2 個のスレッドを持ちます。 +NUMA レイアウトは同様に複製され、このシナリオでは、ゲストではほとんどの場合、2 個の NUMA ノード、各 CPU ソケットに 1 個のノードを持つことになるでしょう。 -In such an environment with multiple NUMA nodes, the memory is similarly divided across NUMA nodes and be pinned accordingly on the host and then exposed to the guest. +複数の NUMA ノードを持つような環境では、メモリーは同様に NUMA ノードで分割され、ホスト上で適切にピンニングされ、その後ゲストに公開されます。 -All this allows for very high performance operations in the guest as the guest scheduler can properly reason about sockets, cores and threads as well as consider NUMA topology when sharing memory or moving processes across NUMA nodes. +これらすべてにより、ゲストスケジューラはソケット、コア、スレッドを適切に判断し、メモリーを共有したり NUMA ノード間でプロセスを移動する際に NUMA トポロジーを考慮できるので、ゲスト内で非常に高パフォーマンスな操作を可能にします。 (instance-options-limits-cpu-container)= -#### Allowance and priority (container only) +#### 割り当てと優先度（コンテナのみ） + +`limits.cpu.allowance`は、時間の制限を与えたときは CFS スケジューラのクォータを、パーセント指定をした場合は全体的な CPU シェアの仕組みを使います: -`limits.cpu.allowance` drives either the CFS scheduler quotas when passed a time constraint, or the generic CPU shares mechanism when passed a percentage value: +- 時間制限（たとえば、`20ms/50ms`）はハードリミットです。 + たとえば、コンテナが最大で 1 つの CPU を使用することを許可する場合は、`limits.cpu.allowance`を`100ms/100ms`のような値に設定します。この値は 1 つの CPU に相当する時間に対する相対値なので、2 つの CPU の時間を制限するには、`100ms/50ms`あるいは`200ms/100ms`のような値を使用します。 +- パーセント指定を使う場合は、制限は負荷状態にある場合のみに適用されるソフトリミットです。 + 設定は、同じ CPU(もしくは CPU の組)を使う他のインスタンスとの比較で、インスタンスに対するスケジューラの優先度を計算するのに使われます。 + たとえば、負荷時のコンテナの CPU 使用率を 1 つの CPU に制限するためには、`limits.cpu.allowance`を`100%`に設定します。 -- The time constraint (for example, `20ms/50ms`) is a hard limit. - For example, if you want to allow the container to use a maximum of one CPU, set `limits.cpu.allowance` to a value like `100ms/100ms`. - The value is relative to one CPU worth of time, so to restrict to two CPUs worth of time, use something like `100ms/50ms` or `200ms/100ms`. -- When using a percentage value, the limit is a soft limit that is applied only when under load. - It is used to calculate the scheduler priority for the instance, relative to any other instance that is using the same CPU or CPUs. - For example, to limit the CPU usage of the container to one CPU when under load, set `limits.cpu.allowance` to `100%`. -`limits.cpu.nodes` can be used to restrict the CPUs that the instance can use to a specific set of NUMA nodes. -To specify which NUMA nodes to use, set `limits.cpu.nodes` to either a set of NUMA node IDs (for example, `0,1`) or a set of NUMA node ranges (for example, `0-1,2-4`). +`limits.cpu.nodes`はインスタンスが使用する CPU を特定の NUMA ノードに限定するのに使えます。 +どの NUMA ノードを使用するか指定するには、`limits.cpu.nodes`に NUMA ノード ID の組（たとえば、`0,1`）または NUMA ノードの範囲（たとえば、`0-1,2-4`）のどちらかを設定します。 -`limits.cpu.priority` is another factor that is used to compute the scheduler priority score when a number of instances sharing a set of CPUs have the same percentage of CPU assigned to them. +`limits.cpu.priority` は、CPU の組を共有する複数のインスタンスに割り当てられた CPU の割合が同じ場合に、スケジューラの優先度スコアを計算するために使われる別の因子です。 (instance-options-limits-hugepages)= -### Huge page limits +### huge page の制限 -Incus allows to limit the number of huge pages available to a container through the `limits.hugepage.[size]` key. +Incus では `limits.hugepage.[size]` キーを使ってコンテナが利用できる huge page の数を制限できます。 -Architectures often expose multiple huge-page sizes. -The available huge-page sizes depend on the architecture. +アーキテクチャはしばしば huge page のサイズを公開しています。 +利用可能な huge page サイズはアーキテクチャによって異なります。 -Setting limits for huge pages is especially useful when Incus is configured to intercept the `mount` syscall for the `hugetlbfs` file system in unprivileged containers. -When Incus intercepts a `hugetlbfs` `mount` syscall, it mounts the `hugetlbfs` file system for a container with correct `uid` and `gid` values as mount options. -This makes it possible to use huge pages from unprivileged containers. -However, it is recommended to limit the number of huge pages available to the container through `limits.hugepages.[size]` to stop the container from being able to exhaust the huge pages available to the host. +huge page の制限は非特権コンテナ内で`hugetlbfs`ファイルシステムの`mount`システムコールをインターセプトするように Incus を設定しているときには特に有用です。 +Incus が`hugetlbfs` `mount`システムコールをインターセプトすると Incus は正しい`uid`と`gid`の値を`mount`オプションに指定して`hugetblfs`ファイルシステムをコンテナにマウントします。 +これにより非特権コンテナからも huge page が利用可能となります。 +しかし、ホストで利用可能な huge page をコンテナが使い切ってしまうのを防ぐため、`limits.hugepages.[size]`を使ってコンテナが利用可能な huge page の数を制限することを推奨します。 -Limiting huge pages is done through the `hugetlb` cgroup controller, which means that the host system must expose the `hugetlb` controller in the legacy or unified cgroup hierarchy for these limits to apply. +huge page の制限は`hugetlb` cgroup コントローラーによって実行されます。これはこれらの制限を適用するために、ホストシステムが`hugetlb`コントローラーをレガシーあるいは cgroup の単一階層構造(訳注:cgroup v2)に公開する必要があることを意味します。 (instance-options-limits-kernel)= -### Kernel resource limits +### カーネルリソース制限 -Incus exposes a generic namespaced key `limits.kernel.*` that can be used to set resource limits for an instance. +Incus は、インスタンスのリソース制限を設定するのに使用できる一般の名前空間キー`limits.kernel.*`を公開しています。 -It is generic in the sense that Incus does not perform any validation on the resource that is specified following the `limits.kernel.*` prefix. -Incus cannot know about all the possible resources that a given kernel supports. -Instead, Incus simply passes down the corresponding resource key after the `limits.kernel.*` prefix and its value to the kernel. -The kernel does the appropriate validation. -This allows users to specify any supported limit on their system. +`limits.kernel.*`接頭辞に続いて指定されるリソースについて Incus が全く検証を行わないという意味でこれは汎用です。 +Incus は対象のカーネルがサポートするすべての利用可能なリソースについて知ることはできません。 +代わりに、Incus は`limits.kernel.*`接頭辞の後の対応するリソースキーとその値をカーネルに単に渡します。 +カーネルが適切な検証を行います。 +これによりユーザーはシステム上でサポートされる任意の制限を指定できます。 -Some common limits are: +よくある制限のいくつかは以下のとおりです: -Key | Resource | Description +キー | リソース | 説明 :-- | :--- | :---------- -`limits.kernel.as` | `RLIMIT_AS` | Maximum size of the process's virtual memory -`limits.kernel.core` | `RLIMIT_CORE` | Maximum size of the process's core dump file -`limits.kernel.cpu` | `RLIMIT_CPU` | Limit in seconds on the amount of CPU time the process can consume -`limits.kernel.data` | `RLIMIT_DATA` | Maximum size of the process's data segment -`limits.kernel.fsize` | `RLIMIT_FSIZE` | Maximum size of files the process may create -`limits.kernel.locks` | `RLIMIT_LOCKS` | Limit on the number of file locks that this process may establish -`limits.kernel.memlock` | `RLIMIT_MEMLOCK` | Limit on the number of bytes of memory that the process may lock in RAM -`limits.kernel.nice` | `RLIMIT_NICE` | Maximum value to which the process's nice value can be raised -`limits.kernel.nofile` | `RLIMIT_NOFILE` | Maximum number of open files for the process -`limits.kernel.nproc` | `RLIMIT_NPROC` | Maximum number of processes that can be created for the user of the calling process -`limits.kernel.rtprio` | `RLIMIT_RTPRIO` | Maximum value on the real-time-priority that may be set for this process -`limits.kernel.sigpending`| `RLIMIT_SIGPENDING` | Maximum number of signals that may be queued for the user of the calling process - -A full list of all available limits can be found in the manpages for the `getrlimit(2)`/`setrlimit(2)` system calls. - -To specify a limit within the `limits.kernel.*` namespace, use the resource name in lowercase without the `RLIMIT_` prefix. -For example, `RLIMIT_NOFILE` should be specified as `nofile`. - -A limit is specified as two colon-separated values that are either numeric or the word `unlimited` (for example, `limits.kernel.nofile=1000:2000`). -A single value can be used as a shortcut to set both soft and hard limit to the same value (for example, `limits.kernel.nofile=3000`). - -A resource with no explicitly configured limit will inherit its limit from the process that starts up the instance. -Note that this inheritance is not enforced by Incus but by the kernel. +`limits.kernel.as` | `RLIMIT_AS` | プロセスの仮想メモリーの最大サイズ +`limits.kernel.core` | `RLIMIT_CORE` | プロセスのコアダンプファイルの最大サイズ +`limits.kernel.cpu` | `RLIMIT_CPU` | プロセスが使えるCPU時間の秒単位の制限 +`limits.kernel.data` | `RLIMIT_DATA` | プロセスのデータセグメントの最大サイズ +`limits.kernel.fsize` | `RLIMIT_FSIZE` | プロセスが作成できるファイルの最大サイズ +`limits.kernel.locks` | `RLIMIT_LOCKS` | プロセスが確立できるファイルロック数の制限 +`limits.kernel.memlock` | `RLIMIT_MEMLOCK` | プロセスがRAM上でロックできるメモリーのバイト数の制限 +`limits.kernel.nice` | `RLIMIT_NICE` | 引き上げることができるプロセスのnice値の最大値 +`limits.kernel.nofile` | `RLIMIT_NOFILE` | プロセスがオープンできるファイルの最大値 +`limits.kernel.nproc` | `RLIMIT_NPROC` | 呼び出し元プロセスのユーザーが作れるプロセスの最大数 +`limits.kernel.rtprio` | `RLIMIT_RTPRIO` | プロセスに対して設定できるリアルタイム優先度の最大値 +`limits.kernel.sigpending`| `RLIMIT_SIGPENDING` | 呼び出し元プロセスのユーザーがキューに入れられるシグナルの最大数 + + +指定できる制限の完全なリストは `getrlimit(2)`/`setrlimit(2)`システムコールの man ページで確認できます。 + +`limits.kernel.*`名前空間内で制限を指定するには、`RLIMIT_`を付けずに、リソース名を小文字で指定します。 +たとえば、`RLIMIT_NOFILE`は`nofile`と指定します。 + +制限は、コロン区切りのふたつの数字もしくは`unlimited`という文字列で指定します（たとえば、`limits.kernel.nofile=1000:2000`）。 +単一の値を使って、ソフトリミットとハードリミットを同じ値に設定できます（たとえば、`limits.kernel.nofile=3000`）。 + +明示的に設定されないリソースは、インスタンスを起動したプロセスから継承されます。 +この継承は Incus でなく、カーネルによって強制されることに注意してください。 (instance-options-migration)= -## Migration options +## マイグレーションオプション -The following instance options control the behavior if the instance is {ref}`moved from one Incus server to another `: +以下のインスタンスオプションはインスタンスが{ref}`あるLXDサーバーから別のサーバーに移動される `場合の挙動を制御します: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -224,9 +226,9 @@ The following instance options control the behavior if the instance is {ref}`mov ``` (instance-options-nvidia)= -## NVIDIA and CUDA configuration +## NVIDIAとCUDAの設定 -The following instance options specify the NVIDIA and CUDA configuration of the instance: +以下のインスタンスオプションはインスタンスの NVIDIA と CUDA の設定を指定します: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -235,9 +237,9 @@ The following instance options specify the NVIDIA and CUDA configuration of the ``` (instance-options-raw)= -## Raw instance configuration overrides +## rawインスタンス設定のオーバーライド -The following instance options allow direct interaction with the backend features that Incus itself uses: +以下のインスタンスオプションは Incus 自身が使用するバックエンド機能に直接制御できるようにします: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -246,33 +248,33 @@ The following instance options allow direct interaction with the backend feature ``` ```{important} -Setting these `raw.*` keys might break Incus in non-obvious ways. -Therefore, you should avoid setting any of these keys. +これらの`raw.*`キーを設定すると Incus を予期せぬ形で壊してしまうかもしれません。 +このため、これらのキーを設定するのは避けるほうが良いです。 ``` (instance-options-qemu)= -### Override QEMU configuration +### QEMU設定のオーバーライド -For VM instances, Incus configures QEMU through a configuration file that is passed to QEMU with the `-readconfig` command-line option. -This configuration file is generated for each instance before boot. -It can be found at `/var/log/incus//qemu.conf`. +VM インスタンスに対しては、Incus は`-readconfig`コマンドラインオプションで QEMU に渡す設定ファイルを使って QEMU を設定します。 +この設定ファイルは各インスタンスの起動前に生成されます。 +設定ファイルは`/var/log/lxd//qemu.conf`に作られます。 -The default configuration works fine for Incus' most common use case: modern UEFI guests with VirtIO devices. -In some situations, however, you might need to override the generated configuration. -For example: +デフォルトの設定はほとんどの典型的な利用ケース、VirtIO デバイスを持つモダンな UEFI ゲスト、では正常に動作します。 +しかし、いくつかの状況では、生成された設定をオーバーライドする必要があります。 +たとえば以下のような場合です。 -- To run an old guest OS that doesn't support UEFI. -- To specify custom virtual devices when VirtIO is not supported by the guest OS. -- To add devices that are not supported by Incus before the machines boots. -- To remove devices that conflict with the guest OS. +- UEFI をサポートしない古いゲスト OS を実行する。 +- VirtIO がゲスト OS でサポートされない場合にカスタムな仮想デバイスを指定する。 +- マシンの起動前に Incus でサポートされないデバイスを追加する。 +- ゲスト OS と衝突するデバイスを削除する。 -To override the configuration, set the `raw.qemu.conf` option. -It supports a format similar to `qemu.conf`, with some additions. -Since it is a multi-line configuration option, you can use it to modify multiple sections or keys. +設定をオーバーライドするには、`raw.qemu.conf`オプションを設定します。 +これは`qemu.conf`と似たような形式ですが、いくつか拡張した形式をサポートします。 +これは複数行の設定オプションですので、複数のセクションやキーを変更するのに使えます。 -- To replace a section or key in the generated configuration file, add a section with a different value. +- 生成された設定ファイルのセクションやキーを置き換えるには、別の値を持つセクションを追加します。 - For example, use the following section to override the default `virtio-gpu-pci` GPU driver: + たとえば、デフォルトの`virtio-gpu-pci` GPU ドライバーをオーバーライドするには以下のセクションを使います: ``` raw.qemu.conf: |- @@ -280,16 +282,16 @@ Since it is a multi-line configuration option, you can use it to modify multiple driver = "qxl-vga" ``` -- To remove a section, specify a section without any keys. - For example: +- セクションを削除するには、キー無しのセクションを指定します。 + たとえば: ``` raw.qemu.conf: |- [device "qemu_gpu"] ``` -- To remove a key, specify an empty string as the value. - For example: +- キーを削除するには、空の文字列を値として指定します。 + たとえば: ``` raw.qemu.conf: |- @@ -297,10 +299,10 @@ Since it is a multi-line configuration option, you can use it to modify multiple driver = "" ``` -- To add a new section, specify a section name that is not present in the configuration file. +- 新規のセクションを追加するには、設定ファイル内に存在しないセクション名を指定します。 -The configuration file format used by QEMU allows multiple sections with the same name. -Here's a piece of the configuration generated by Incus: +QEMU で使用される設定ファイル形式は同じ名前の複数のセクションを許可します。 +以下は Incus で生成される設定の抜粋です。 ``` [global] @@ -314,8 +316,8 @@ property = "disable_s4" value = "1" ``` -To specify which section to override, specify an index. -For example: +オーバーライドするセクションを指定するには、インデクスを指定します。 +たとえば: ``` raw.qemu.conf: |- @@ -323,7 +325,7 @@ raw.qemu.conf: |- value = "0" ``` -Section indexes start at 0 (which is the default value when not specified), so the above example would generate the following configuration: +セクションのインデクスは 0（指定しない場合のデフォルト値）から始まりますので、上の例は以下の設定を生成します: ``` [global] @@ -338,9 +340,9 @@ value = "0" ``` (instance-options-security)= -## Security policies +## セキュリティーポリシー -The following instance options control the {ref}`security` policies of the instance: +以下のインスタンスオプションはインスタンスの{ref}`security`ポリシーを制御します: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -349,9 +351,9 @@ The following instance options control the {ref}`security` policies of the insta ``` (instance-options-snapshots)= -## Snapshot scheduling and configuration +## スナップショットのスケジュールと設定 -The following instance options control the creation and expiry of {ref}`instance snapshots `: +以下のインスタンスオプションは{ref}`インスタンススナップショット `の作成と削除を制御します: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -360,14 +362,14 @@ The following instance options control the creation and expiry of {ref}`instance ``` (instance-options-snapshots-names)= -### Automatic snapshot names +### スナップショットの自動命名 {{snapshot_pattern_detail}} (instance-options-volatile)= -## Volatile internal data +## 揮発性の内部データ -The following volatile keys are currently used internally by Incus to store internal data specific to an instance: +以下の揮発性のキーはインスタンスに固有な内部データを保管するため Incus で現在内部的に使用されています: % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -376,5 +378,5 @@ The following volatile keys are currently used internally by Incus to store inte ``` ```{note} -Volatile keys cannot be set by the user. +揮発性のキーはユーザは設定できません。 ``` diff --git a/doc/reference/instance_properties.md b/doc/reference/instance_properties.md index 84c587d341e..a7502763693 100644 --- a/doc/reference/instance_properties.md +++ b/doc/reference/instance_properties.md @@ -1,36 +1,36 @@ (instance-properties)= -# Instance properties +# インスタンスプロパティ -Instance properties are set when the instance is created. -They cannot be part of a {ref}`profile `. +インスタンスプロパティはインスタンスが作成されたときに設定されます。 +これらは{ref}`プロファイル `の一部にはできません。 -The following instance properties are available: +以下のインスタンスプロパティが利用可能です: ```{list-table} :header-rows: 1 :widths: 2 1 4 -* - Property - - Read-only - - Description +* - プロパティ + - 読み取り専用 + - 説明 * - `name` - yes - - Instance name (see {ref}`instance-name-requirements`) + - インスタンス名 (see {ref}`instance-name-requirements`) * - `architecture` - no - - Instance architecture + - インスタンスアーキテクチャ ``` (instance-name-requirements)= -## Instance name requirements +## インスタンス名の要件 -The instance name can be changed only by renaming the instance with the [`incus rename`](incus_rename.md) command. +インスタンス名は [`incus rename`](incus_rename.md) コマンドでインスタンスをリネームすることでのみ変更できます。 -Valid instance names must fulfill the following requirements: +有効なインスタンス名は次の要件を満たさなければなりません。 -- The name must be between 1 and 63 characters long. -- The name must contain only letters, numbers and dashes from the ASCII table. -- The name must not start with a digit or a dash. -- The name must not end with a dash. +- 名前は 1～63 文字である必要があります。 +- 名前は ASCII テーブルの文字、数字、ダッシュのみを含む必要があります。 +- 名前は数字またはダッシュで始まってはいけません。 +- 名前はダッシュで終わってはいけません。 -The purpose of these requirements is to ensure that the instance name can be used in DNS records, on the file system, in various security profiles and as the host name of the instance itself. +これらの要件は、インスタンス名が DNS レコードとして、ファイルシステム上で、色々なセキュリティープロファイル、そしてインスタンス自身のホスト名として使えるように定められています。 diff --git a/doc/reference/instance_units.md b/doc/reference/instance_units.md index d8d30efe507..051b93ec2d2 100644 --- a/doc/reference/instance_units.md +++ b/doc/reference/instance_units.md @@ -1,11 +1,11 @@ (instances-limit-units)= -# Units for storage and network limits +# ストレージとネットワーク制限の単位 -Any value that represents bytes or bits can make use of a number of suffixes to make it easier to understand what a particular limit is. +バイト数とビット数を表す値はすべていくつかの単位を使用し特定の制限がどういう値かをより理解しやすいようにできます。 -Both decimal and binary (kibi) units are supported, with the latter mostly making sense for storage limits. +10 進と 2 進（kibi）の単位の両方がサポートされており、後者は主にストレージの制限に有用です。 -The full list of bit suffixes currently supported is: +現在サポートされているビットの単位の完全なリストは以下の通りです: - bit (1) - kbit (1000) @@ -21,7 +21,7 @@ The full list of bit suffixes currently supported is: - Pibit (1024^5) - Eibit (1024^6) -The full list of byte suffixes currently supported is: +現在サポートされているバイトの単位の完全なリストは以下の通りです: - B or bytes (1) - kB (1000) diff --git a/doc/reference/network_bridge.md b/doc/reference/network_bridge.md index 6588c7ccc77..e907215877c 100644 --- a/doc/reference/network_bridge.md +++ b/doc/reference/network_bridge.md @@ -1,130 +1,130 @@ (network-bridge)= -# Bridge network +# ブリッジネットワーク -As one of the possible network configuration types under Incus, Incus supports creating and managing network bridges. +Incus でのネットワークの設定タイプの 1 つとして、Incus はネットワークブリッジの作成と管理をサポートしています。 -A network bridge creates a virtual L2 Ethernet switch that instance NICs can connect to, making it possible for them to communicate with each other and the host. -Incus bridges can leverage underlying native Linux bridges and Open vSwitch. +ネットワークブリッジはインスタンス NIC が接続できる仮想的な L2 イーサネットスイッチを作成し、インスタンスが他のインスタンスやホストと通信できるようにします。 +Incus のブリッジは下層のネイティブな Linux のブリッジと Open vSwitch を利用できます。 -The `bridge` network type allows to create an L2 bridge that connects the instances that use it together into a single network L2 segment. -Bridges created by Incus are managed, which means that in addition to creating the bridge interface itself, Incus also sets up a local `dnsmasq` process to provide DHCP, IPv6 route announcements and DNS services to the network. -By default, it also performs NAT for the bridge. +`bridge`ネットワークはそれを利用する複数のインスタンスを接続する L2 ブリッジを作成しそれらのインスタンスを単一の L2 ネットワークセグメントにします。 +Incus で作成されたブリッジは"managed"です。 +つまり、ブリッジインターフェース自体を作成するのに加えて、Incus さらに DHCP、IPv6 ルート広告と DNS サービスを提供するローカルの`dnsmasq`プロセスをセットアップします。 +デフォルトではブリッジに対して NAT も行います。 -See {ref}`network-bridge-firewall` for instructions on how to configure your firewall to work with Incus bridge networks. +Incus ブリッジネットワークでファイアウォールを設定するための手順については{ref}`network-bridge-firewall`を参照してください。 ```{note} -Static DHCP assignments depend on the client using its MAC address as the DHCP identifier. -This method prevents conflicting leases when copying an instance, and thus makes statically assigned leases work properly. +静的な DHCP 割当は MAC アドレスを DHCP 識別子として使用するクライアントに依存します。 +この方法はインスタンスをコピーする際に衝突するリースを回避し、静的に割り当てられたリースが正しく動くようにします。 ``` -## IPv6 prefix size +## IPv6プリフィクスサイズ -If you're using IPv6 for your bridge network, you should use a prefix size of 64. +ブリッジネットワークで IPv6 を使用する場合、64 のプリフィクスサイズを使用するべきです。 -Larger subnets (i.e., using a prefix smaller than 64) should work properly too, but they aren't typically that useful for {abbr}`SLAAC (Stateless Address Auto-configuration)`. +より大きなサブネット（つまり 64 より小さいプリフィクスを使用する）も正常に動くはずですが、通常それらは{abbr}`SLAAC (Stateless Address Auto-configuration)`には役立ちません。 -Smaller subnets are in theory possible (when using stateful DHCPv6 for IPv6 allocation), but they aren't properly supported by `dnsmasq` and might cause problems. -If you must create a smaller subnet, use static allocation or another standalone router advertisement daemon. +より小さなサブネットも（IPv6 の割当にはステートフル DHCPv6 を使用する場合）理論上は可能ですが、`dnsmasq`に適切にサポートされていないので問題が起きるかもしれません。より小さなサブネットを作らなければならない場合は、静的割当を使うか別のルータ広告デーモンを使用してください。 (network-bridge-options)= -## Configuration options +## 設定オプション -The following configuration key namespaces are currently supported for the `bridge` network type: +`bridge`ネットワークタイプでは現在以下の設定キーNamespace がサポートされています: -- `bgp` (BGP peer configuration) -- `bridge` (L2 interface configuration) -- `dns` (DNS server and resolution configuration) -- `ipv4` (L3 IPv4 configuration) -- `ipv6` (L3 IPv6 configuration) -- `security` (network ACL configuration) -- `raw` (raw configuration file content) -- `tunnel` (cross-host tunneling configuration) -- `user` (free-form key/value for user metadata) +- `bgp` (BGP ピア設定) +- `bridge` (L2 インターフェースの設定) +- `dns` (DNS サーバーと名前解決の設定) +- `ipv4` (L3 IPv4 設定) +- `ipv6` (L3 IPv6 設定) +- `security` (ネットワーク ACL 設定) +- `raw` (raw の設定のファイルの内容) +- `tunnel` (ホスト間のトンネリングの設定) +- `user` (key/value の自由形式のユーザーメタデータ) ```{note} {{note_ip_addresses_CIDR}} ``` -The following configuration options are available for the `bridge` network type: - -Key | Type | Condition | Default | Description -:-- | :-- | :-- | :-- | :-- -`bgp.peers.NAME.address` | string | BGP server | - | Peer address (IPv4 or IPv6) -`bgp.peers.NAME.asn` | integer | BGP server | - | Peer AS number -`bgp.peers.NAME.password` | string | BGP server | - (no password) | Peer session password (optional) -`bgp.peers.NAME.holdtime` | integer | BGP server | `180` | Peer session hold time (in seconds; optional) -`bgp.ipv4.nexthop` | string | BGP server | local address | Override the next-hop for advertised prefixes -`bgp.ipv6.nexthop` | string | BGP server | local address | Override the next-hop for advertised prefixes -`bridge.driver` | string | - | `native` | Bridge driver: `native` or `openvswitch` -`bridge.external_interfaces` | string | - | - | Comma-separated list of unconfigured network interfaces to include in the bridge -`bridge.hwaddr` | string | - | - | MAC address for the bridge -`bridge.mtu` | integer | - | `1500` | Bridge MTU (default varies if tunnel in use) -`dns.domain` | string | - | `incus` | Domain to advertise to DHCP clients and use for DNS resolution -`dns.mode` | string | - | `managed` | DNS registration mode: `none` for no DNS record, `managed` for Incus-generated static records or `dynamic` for client-generated records -`dns.search` | string | - | - | Full comma-separated domain search list, defaulting to `dns.domain` value -`dns.zone.forward` | string | - | `managed` | Comma-separated list of DNS zone names for forward DNS records -`dns.zone.reverse.ipv4` | string | - | `managed` | DNS zone name for IPv4 reverse DNS records -`dns.zone.reverse.ipv6` | string | - | `managed` | DNS zone name for IPv6 reverse DNS records -`ipv4.address` | string | standard mode | - (initial value on creation: `auto`) | IPv4 address for the bridge (use `none` to turn off IPv4 or `auto` to generate a new random unused subnet) (CIDR) -`ipv4.dhcp` | bool | IPv4 address | `true` | Whether to allocate addresses using DHCP -`ipv4.dhcp.expiry` | string | IPv4 DHCP | `1h` | When to expire DHCP leases -`ipv4.dhcp.gateway` | string | IPv4 DHCP | IPv4 address | Address of the gateway for the subnet -`ipv4.dhcp.ranges` | string | IPv4 DHCP | all addresses | Comma-separated list of IP ranges to use for DHCP (FIRST-LAST format) -`ipv4.firewall` | bool | IPv4 address | `true` | Whether to generate filtering firewall rules for this network -`ipv4.nat` | bool | IPv4 address | `false` (initial value on creation if `ipv4.address` is set to `auto`: `true`) | Whether to NAT -`ipv4.nat.address` | string | IPv4 address | - | The source address used for outbound traffic from the bridge -`ipv4.nat.order` | string | IPv4 address | `before` | Whether to add the required NAT rules before or after any pre-existing rules -`ipv4.ovn.ranges` | string | - | - | Comma-separated list of IPv4 ranges to use for child OVN network routers (FIRST-LAST format) -`ipv4.routes` | string | IPv4 address | - | Comma-separated list of additional IPv4 CIDR subnets to route to the bridge -`ipv4.routing` | bool | IPv4 address | `true` | Whether to route traffic in and out of the bridge -`ipv6.address` | string | standard mode | - (initial value on creation: `auto`) | IPv6 address for the bridge (use `none` to turn off IPv6 or `auto` to generate a new random unused subnet) (CIDR) -`ipv6.dhcp` | bool | IPv6 address | `true` | Whether to provide additional network configuration over DHCP -`ipv6.dhcp.expiry` | string | IPv6 DHCP | `1h` | When to expire DHCP leases -`ipv6.dhcp.ranges` | string | IPv6 stateful DHCP | all addresses | Comma-separated list of IPv6 ranges to use for DHCP (FIRST-LAST format) -`ipv6.dhcp.stateful` | bool | IPv6 DHCP | `false` | Whether to allocate addresses using DHCP -`ipv6.firewall` | bool | IPv6 address | `true` | Whether to generate filtering firewall rules for this network -`ipv6.nat` | bool | IPv6 address | `false` (initial value on creation if `ipv6.address` is set to `auto`: `true`) | Whether to NAT -`ipv6.nat.address` | string | IPv6 address | - | The source address used for outbound traffic from the bridge -`ipv6.nat.order` | string | IPv6 address | `before` | Whether to add the required NAT rules before or after any pre-existing rules -`ipv6.ovn.ranges` | string | - | - | Comma-separated list of IPv6 ranges to use for child OVN network routers (FIRST-LAST format) -`ipv6.routes` | string | IPv6 address | - | Comma-separated list of additional IPv6 CIDR subnets to route to the bridge -`ipv6.routing` | bool | IPv6 address | `true` | Whether to route traffic in and out of the bridge -`raw.dnsmasq` | string | - | - | Additional `dnsmasq` configuration to append to the configuration file -`security.acls` | string | - | - | Comma-separated list of Network ACLs to apply to NICs connected to this network (see {ref}`network-acls-bridge-limitations`) -`security.acls.default.egress.action`| string | `security.acls` | `reject` | Action to use for egress traffic that doesn't match any ACL rule -`security.acls.default.egress.logged`| bool | `security.acls` | `false` | Whether to log egress traffic that doesn't match any ACL rule -`security.acls.default.ingress.action`| string | `security.acls` | `reject` | Action to use for ingress traffic that doesn't match any ACL rule -`security.acls.default.ingress.logged`| bool | `security.acls` | `false` | Whether to log ingress traffic that doesn't match any ACL rule -`tunnel.NAME.group` | string | `vxlan` | `239.0.0.1` | Multicast address for `vxlan` (used if local and remote aren't set) -`tunnel.NAME.id` | integer | `vxlan` | `0` | Specific tunnel ID to use for the `vxlan` tunnel -`tunnel.NAME.interface` | string | `vxlan` | - | Specific host interface to use for the tunnel -`tunnel.NAME.local` | string | `gre` or `vxlan` | - | Local address for the tunnel (not necessary for multicast `vxlan`) -`tunnel.NAME.port` | integer | `vxlan` | `0` | Specific port to use for the `vxlan` tunnel -`tunnel.NAME.protocol` | string | standard mode | - | Tunneling protocol: `vxlan` or `gre` -`tunnel.NAME.remote` | string | `gre` or `vxlan` | - | Remote address for the tunnel (not necessary for multicast `vxlan`) -`tunnel.NAME.ttl` | integer | `vxlan` | `1` | Specific TTL to use for multicast routing topologies -`user.*` | string | - | - | User-provided free-form key/value pairs +`bridge`ネットワークタイプには以下の設定オプションがあります: + +キー | 型 | 条件 | デフォルト | 説明 +:-- | :-- | :-- | :-- | :-- +`bgp.peers.NAME.address` | string | BGPサーバー | - | ピアのアドレス（IPv4かIPv6） +`bgp.peers.NAME.asn` | integer | BGPサーバー | - | ピアのAS番号 +`bgp.peers.NAME.password` | string | BGPサーバー | - （パスワード無し） | ピアのセッションパスワード（省略可能） +`bgp.peers.NAME.holdtime` | integer | BGPサーバー | `180` | ピアセッションホールドタイム（秒で指定、省略可能） +`bgp.ipv4.nexthop` | string | BGPサーバー | ローカルアドレス | 広告されたプリフィクスのnext-hopをオーバーライド +`bgp.ipv6.nexthop` | string | BGPサーバー | ローカルアドレス | 広告されたプリフィクスのnext-hopをオーバーライド +`bridge.driver` | string | - | `native` | ブリッジのドライバー: `native`か`openvswitch` +`bridge.external_interfaces` | string | - | - | ブリッジに含める未設定のネットワークインターフェースのカンマ区切りリスト +`bridge.hwaddr` | string | - | - | ブリッジのMACアドレス +`bridge.mtu` | integer | - | `1500` | ブリッジのMTU（tunnel使用時はデフォルト値は変わる） +`dns.domain` | string | - | `incus` | DHCPのクライアントに広告しDNSの名前解決に使用するドメイン +`dns.mode` | string | - | `managed` | DNSの登録モード: `none`はDNSレコード無し、`managed`はIncusが静的レコードを生成、`dynamic`はクライアントがレコードを生成 +`dns.search` | string | - | - | 完全なドメインサーチのカンマ区切りリスト、デフォルトは`dns.domain`の値 +`dns.zone.forward` | string | - | `managed` | 正引きDNSレコード用のDNSゾーン名のカンマ区切りリスト +`dns.zone.reverse.ipv4` | string | - | `managed` | IPv4逆引きDNSレコード用のDNSゾーン名 +`dns.zone.reverse.ipv6` | string | - | `managed` | IPv6逆引きDNSレコード用のDNSゾーン名 +`ipv4.address` | string | 標準モード | - （作成時の初期値: `auto`） | ブリッジのIPv4アドレス（CIDR形式）（IPv4をオフにするには`none`、新しいランダムな未使用のサブネットを生成するには`auto`を指定） +`ipv4.dhcp` | bool | IPv4 アドレス | `true` | DHCPを使ってアドレスを割り当てるかどうか +`ipv4.dhcp.expiry` | string | IPv4 DHCP | `1h` | DHCPリースの有効期限 +`ipv4.dhcp.gateway` | string | IPv4 DHCP | IPv4 アドレス | サブネットのゲートウェイのアドレス +`ipv4.dhcp.ranges` | string | IPv4 DHCP | すべてのアドレス | DHCPに使用するIPv4の範囲（開始-終了の形式）のカンマ区切りリスト +`ipv4.firewall` | bool | IPv4 アドレス | `true` | このネットワークに対するファイアウォールのフィルタリングルールを生成するかどうか +`ipv4.nat` | bool | IPv4 アドレス | `false`（`ipv4.address`が`auto`の場合の作成時の初期値: `true`） | NATにするかどうか +`ipv4.nat.address` | string | IPv4 アドレス | - | ブリッジからの送信時に使うソースアドレス +`ipv4.nat.order` | string | IPv4 アドレス | `before` | 必要なNATのルールを既存のルールの前に追加するか後に追加するか +`ipv4.ovn.ranges` | string | - | - | 子供のOVNネットワークルーターに使用するIPv4アドレスの範囲（開始-終了の形式）のカンマ区切りリスト +`ipv4.routes` | string | IPv4 アドレス | - | ブリッジへルーティングする追加のIPv4 CIDRサブネットのカンマ区切りリスト +`ipv4.routing` | bool | IPv4 アドレス | `true` | ブリッジの内外にトラフィックをルーティングするかどうか +`ipv6.address` | string | 標準モード | - （作成時の初期値: `auto`） | ブリッジのIPv6アドレス（CIDR形式）（IPv6をオフにするには`none`、新しいランダムな未使用のサブネットを生成するには`auto`を指定） +`ipv6.dhcp` | bool | IPv6 アドレス | `true` | DHCP上で追加のネットワーク設定を提供するかどうか +`ipv6.dhcp.expiry` | string | IPv6 DHCP | `1h` | DHCPリースの有効期限 +`ipv6.dhcp.ranges` | string | IPv6 stateful DHCP | すべてのアドレス | DHCPに使用するIPv6の範囲（開始-終了の形式）のカンマ区切りリスト +`ipv6.dhcp.stateful` | bool | IPv6 DHCP | `false` | DHCPを使ってアドレスを割り当てるかどうか +`ipv6.firewall` | bool | IPv6 アドレス | `true` | このネットワークに対するファイアウォールのフィルタリングルールを生成するかどうか +`ipv6.nat` | bool | IPv6 アドレス | `false`（`ipv6.address`が`auto`の場合の作成時の初期値: `true`） | NATにするかどうか +`ipv6.nat.address` | string | IPv6 アドレス | - | ブリッジからの送信時に使うソースアドレス +`ipv6.nat.order` | string | IPv6 アドレス | `before` | 必要なNATのルールを既存のルールの前に追加するか後に追加するか +`ipv6.ovn.ranges` | string | - | - | 子供のOVNネットワークルーターに使用するIPv6アドレスの範囲（開始-終了の形式）のカンマ区切りリスト +`ipv6.routes` | string | IPv6 アドレス | - | ブリッジへルーティングする追加のIPv4 CIDRサブネットのカンマ区切りリスト +`ipv6.routing` | bool | IPv6 アドレス | `true` | ブリッジの内外にトラフィックをルーティングするかどうか +`raw.dnsmasq` | string | - | - | 設定に追加する`dnsmasq`の設定ファイル +`security.acls` | string | - | - | このネットワークに接続されたNICに適用するカンマ区切りのネットワークACL（{ref}`network-acls-bridge-limitations`参照） +`security.acls.default.egress.action` | string | `security.acls` | `reject` | どのACLルールにもマッチしない外向きトラフィックに使うアクション +`security.acls.default.egress.logged` | bool | `security.acls` | `false` | どのACLルールにもマッチしない外向きトラフィックをログ出力するかどうか +`security.acls.default.ingress.action` | string | `security.acls` | `reject` | どのACLルールにもマッチしない内向きトラフィックに使うアクション +`security.acls.default.ingress.logged` | bool | `security.acls` | `false` | どのACLルールにもマッチしない内向きトラフィックをログ出力するかどうか +`tunnel.NAME.group` | string | `vxlan` | `239.0.0.1` | `vxlan`のマルチキャスト設定（localとremoteが未設定の場合に使われます） +`tunnel.NAME.id` | integer | `vxlan` | `0` | `vxlan`トンネルに使用するトンネルID +`tunnel.NAME.interface` | string | `vxlan` | - | トンネルに使用するホスト・インターフェース +`tunnel.NAME.local` | string | `gre` or `vxlan` | - | トンネルに使用するローカルアドレス（マルチキャスト`vxlan`の場合は不要） +`tunnel.NAME.port` | integer | `vxlan` | `0` | `vxlan`トンネルに使用するポート +`tunnel.NAME.protocol` | string | 標準モード | - | トンネリングのプロトコル: `vxlan`か`gre` +`tunnel.NAME.remote` | string | `gre` or `vxlan` | - | トンネルに使用するリモートアドレス（マルチキャスト`vxlan`の場合は不要） +`tunnel.NAME.ttl` | integer | `vxlan` | `1` | マルチキャストルーティングトポロジーに使用する固有の TTL +`user.*` | string | - | - | ユーザー指定の自由形式のキー／バリューペア (network-bridge-features)= -## Supported features +## サポートされている機能 -The following features are supported for the `bridge` network type: +`bridge`ネットワークタイプでは以下の機能がサポートされています: - {ref}`network-acls` - {ref}`network-forwards` - {ref}`network-zones` - {ref}`network-bgp` -- [How to integrate with `systemd-resolved`](network-bridge-resolved) +- [`systemd-resolved`と統合するには](network-bridge-resolved) ```{toctree} :maxdepth: 1 :hidden: -Integrate with resolved -Configure your firewall +resolvedとの統合 +ファイアウォールの設定 ``` diff --git a/doc/reference/network_external.md b/doc/reference/network_external.md index 9079eb96c90..1966bd9b4e5 100644 --- a/doc/reference/network_external.md +++ b/doc/reference/network_external.md @@ -1,14 +1,14 @@ (network-external)= -# External networks +# 外部ネットワーク -External networks use network interfaces that already exist. -Therefore, Incus has limited possibility to control them, and Incus features like network ACLs, network forwards and network zones are not supported. +外部ネットワークは既に存在するネットワークを使用します。 +そのため、 Incus がそれらを制御するには限界があるため、ネットワーク ACL、ネットワークフォワードやネットワークゾーンのような Incus の機能はサポートされません。 -The main purpose for using external networks is to provide an uplink network through a parent interface. -This external network specifies the presets to use when connecting instances or other networks to a parent interface. +外部ネットワークを使用する主な目的は親インターフェースによるアップリンクのネットワークを提供することです。 +この外部ネットワークはインスタンスや他のネットワークを親のインターフェースに接続する際のプリセットを指定します。 -Incus supports the following external network types: +Incus は以下の外部ネットワークタイプをサポートします: ```{toctree} diff --git a/doc/reference/network_macvlan.md b/doc/reference/network_macvlan.md index add17a460d7..44131360314 100644 --- a/doc/reference/network_macvlan.md +++ b/doc/reference/network_macvlan.md @@ -1,36 +1,37 @@ (network-macvlan)= -# Macvlan network +# macvlan ネットワーク -Macvlan is a virtual {abbr}`LAN (Local Area Network)` that you can use if you want to assign several IP addresses to the same network interface, basically splitting up the network interface into several sub-interfaces with their own IP addresses. -You can then assign IP addresses based on the randomly generated MAC addresses. +macvlan は仮想的な {abbr}`LAN (Local Area Network)` で同じネットワークインターフェースに複数の IP アドレスを割り当てたい場合に使用できます。 +基本的にはネットワークインターフェースをそれぞれの IP アドレスを持つ複数のサブインターフェースに分割することになります。 +その後ランダムに生成された MAC アドレスに基づいて IP アドレスを設定できます。 -The `macvlan` network type allows to specify presets to use when connecting instances to a parent interface. -In this case, the instance NICs can simply set the `network` option to the network they connect to without knowing any of the underlying configuration details. +`macvlan` ネットワークタイプは親のインターフェースにインスタンスを接続する際に使用するプリセットを指定できます。 +この場合、接続先のネットワークについて基本的な設定詳細を一切知る必要なしに単に `network` オプションをインスタンス NIC に設定できます。 ```{note} -If you are using a `macvlan` network, communication between the Incus host and the instances is not possible. -Both the host and the instances can talk to the gateway, but they cannot communicate directly. +`macvlan` NIC を使う場合、Incus ホストとインスタンス間の通信はできません。 +ホストとインスタンスの両方がゲートウェイと通信できますが、それらが直接通信はできません。 ``` (network-macvlan-options)= -## Configuration options +## 設定オプション -The following configuration key namespaces are currently supported for the `macvlan` network type: +`macvlan` ネットワークタイプでは現在以下の設定キーNamespace がサポートされています: -- `user` (free-form key/value for user metadata) +- `user`（key/value の自由形式のユーザーメタデータ） ```{note} {{note_ip_addresses_CIDR}} ``` -The following configuration options are available for the `macvlan` network type: +`macvlan` ネットワークタイプでは以下の設定オプションが使用できます: -Key | Type | Condition | Default | Description -:-- | :-- | :-- | :-- | :-- -`gvrp` | bool | - | `false` | Register VLAN using GARP VLAN Registration Protocol -`mtu` | integer | - | - | The MTU of the new interface -`parent` | string | - | - | Parent interface to create `macvlan` NICs on -`vlan` | integer | - | - | The VLAN ID to attach to -`user.*` | string | - | - | User-provided free-form key/value pairs +キー | 型 | 条件 | デフォルト | 説明 +:-- | :-- | :-- | :-- | :-- +`gvrp` | bool | - | `false` | GARP VLAN Registration Protocol を使って VLAN を登録する +`mtu` | integer | - | - | 作成するインターフェースの MTU +`parent` | string | - | - | `macvlan` NIC を作成する親のインターフェース +`vlan` | integer | - | - | アタッチする先の VLAN ID +`user.*` | string | - | - | ユーザー指定の自由形式のキー／バリューペア diff --git a/doc/reference/network_ovn.md b/doc/reference/network_ovn.md index 4e382d6b92c..542c4bb185c 100644 --- a/doc/reference/network_ovn.md +++ b/doc/reference/network_ovn.md @@ -1,19 +1,19 @@ (network-ovn)= -# OVN network +# OVN ネットワーク -{abbr}`OVN (Open Virtual Network)` is a software-defined networking system that supports virtual network abstraction. -You can use it to build your own private cloud. -See [`www.ovn.org`](https://www.ovn.org/) for more information. +{abbr}`OVN (Open Virtual Network)`は仮想ネットワーク抽象化をサポートするソフトウェアで定義されたネットワークシステムです。 +あなた自身のプライベートクラウドを構築するのに使用できます。 +詳細は[`www.ovn.org`](https://www.ovn.org/)をご参照ください。 -The `ovn` network type allows to create logical networks using the OVN {abbr}`SDN (software-defined networking)`. -This kind of network can be useful for labs and multi-tenant environments where the same logical subnets are used in multiple discrete networks. +`ovn`ネットワークタイプは OVN{abbr}`SDN (software-defined networking)`を使って論理的なネットワークの作成を可能にします。 +この種のネットワークは複数の個別のネットワーク内で同じ論理ネットワークのサブネットを使うような検証環境やマルチテナントの環境で便利です。 -A Incus OVN network can be connected to an existing managed {ref}`network-bridge` or {ref}`network-physical` to gain access to the wider network. -By default, all connections from the OVN logical networks are NATed to an IP allocated from the uplink network. +Incus の OVN ネットワークはより広いネットワークへの外向きのアクセスを可能にするため既存の管理された{ref}`network-bridge`や{ref}`network-physical`に接続できます。 +デフォルトでは、OVN 論理ネットワークからのすべての接続はアップリンクのネットワークによって割り当てられた IP に NAT されます。 -See {ref}`network-ovn-setup` for basic instructions for setting up an OVN network. +OVN ネットワークをセットアップする基本的な手順については{ref}`network-ovn-setup`をご参照ください。 % Include content from [network_bridge.md](network_bridge.md) ```{include} network_bridge.md @@ -22,55 +22,55 @@ See {ref}`network-ovn-setup` for basic instructions for setting up an OVN networ ``` (network-ovn-options)= -## Configuration options +## 設定オプション -The following configuration key namespaces are currently supported for the `ovn` network type: +`ovn`ネットワークタイプでは現在以下の設定キーNamespace がサポートされています: -- `bridge` (L2 interface configuration) -- `dns` (DNS server and resolution configuration) -- `ipv4` (L3 IPv4 configuration) -- `ipv6` (L3 IPv6 configuration) -- `security` (network ACL configuration) -- `user` (free-form key/value for user metadata) +- `bridge` （L2 インターフェースの設定） +- `dns` （DNS サーバーと名前解決の設定） +- `ipv4` （L3 IPv4 設定） +- `ipv6` （L3 IPv6 設定） +- `security` （ネットワーク ACL 設定） +- `user` （key/value の自由形式のユーザーメタデータ） ```{note} {{note_ip_addresses_CIDR}} ``` -The following configuration options are available for the `ovn` network type: - -Key | Type | Condition | Default | Description -:-- | :-- | :-- | :-- | :-- -`network` | string | - | - | Uplink network to use for external network access -`bridge.hwaddr` | string | - | - | MAC address for the bridge -`bridge.mtu` | integer | - | `1442` | Bridge MTU (default allows host to host Geneve tunnels) -`dns.domain` | string | - | `incus` | Domain to advertise to DHCP clients and use for DNS resolution -`dns.search` | string | - | - | Full comma-separated domain search list, defaulting to `dns.domain` value -`dns.zone.forward` | string | - | - | Comma-separated list of DNS zone names for forward DNS records -`dns.zone.reverse.ipv4` | string | - | - | DNS zone name for IPv4 reverse DNS records -`dns.zone.reverse.ipv6` | string | - | - | DNS zone name for IPv6 reverse DNS records -`ipv4.address` | string | standard mode | - (initial value on creation: `auto`) | IPv4 address for the bridge (use `none` to turn off IPv4 or `auto` to generate a new random unused subnet) (CIDR) -`ipv4.dhcp` | bool | IPv4 address | `true` | Whether to allocate addresses using DHCP -`ipv4.l3only` | bool | IPv4 address | `false` | Whether to enable layer 3 only mode. -`ipv4.nat` | bool | IPv4 address | `false` (initial value on creation if `ipv4.address` is set to `auto`: `true`) | Whether to NAT -`ipv4.nat.address` | string | IPv4 address | - | The source address used for outbound traffic from the network (requires uplink `ovn.ingress_mode=routed`) -`ipv6.address` | string | standard mode | - (initial value on creation: `auto`) | IPv6 address for the bridge (use `none` to turn off IPv6 or `auto` to generate a new random unused subnet) (CIDR) -`ipv6.dhcp` | bool | IPv6 address | `true` | Whether to provide additional network configuration over DHCP -`ipv6.dhcp.stateful` | bool | IPv6 DHCP | `false` | Whether to allocate addresses using DHCP -`ipv6.l3only` | bool | IPv6 DHCP stateful | `false` | Whether to enable layer 3 only mode. -`ipv6.nat` | bool | IPv6 address | `false` (initial value on creation if `ipv6.address` is set to `auto`: `true`) | Whether to NAT -`ipv6.nat.address` | string | IPv6 address | - | The source address used for outbound traffic from the network (requires uplink `ovn.ingress_mode=routed`) -`security.acls` | string | - | - | Comma-separated list of Network ACLs to apply to NICs connected to this network -`security.acls.default.egress.action`| string | `security.acls` | `reject` | Action to use for egress traffic that doesn't match any ACL rule -`security.acls.default.egress.logged`| bool | `security.acls` | `false` | Whether to log egress traffic that doesn't match any ACL rule -`security.acls.default.ingress.action` | string | `security.acls` | `reject` | Action to use for ingress traffic that doesn't match any ACL rule -`security.acls.default.ingress.logged` | bool | `security.acls` | `false` | Whether to log ingress traffic that doesn't match any ACL rule -`user.*` | string | - | - | User-provided free-form key/value pairs +`ovn` ネットワークタイプには以下の設定オプションがあります: + +キー | 型 | 条件 | デフォルト | 説明 +:-- | :-- | :-- | :-- | :-- +`network` | string | - | - | 外部ネットワークへのアクセスに使うアップリンクのネットワーク +`bridge.hwaddr` | string | - | - | ブリッジのMACアドレス +`bridge.mtu` | integer | - | `1442` | ブリッジのMTU（デフォルトではホストからホストへのGeneveトンネルを許可します） +`dns.domain` | string | - | `incus` | DHCPのクライアントに広告しDNSの名前解決に使用するドメイン +`dns.search` | string | - | - | 完全なドメインサーチのカンマ区切りリスト（デフォルトは`dns.domain`の値） +`dns.zone.forward` | string | - | - | 正引きDNSレコード用のDNSゾーン名のカンマ区切りリスト +`dns.zone.reverse.ipv4` | string | - | - | IPv4逆引きDNSレコード用のDNSゾーン名 +`dns.zone.reverse.ipv6` | string | - | - | IPv6逆引きDNSレコード用のDNSゾーン名 +`ipv4.address` | string | 標準モード | - （作成時の初期値: `auto`） | ブリッジのIPv4アドレス（CIDR形式）。IPv4をオフにするには`none`、新しいランダムな未使用のサブネットを生成するには`auto`を指定。 +`ipv4.dhcp` | bool | IPv4 アドレス | `true` | DHCPを使ってアドレスを割り当てるかどうか +`ipv4.l3only` | bool | IPv4 アドレス | `false` | layer 3 only モード を有効にするかどうか +`ipv4.nat` | bool | IPv4 アドレス | `false` （`ipv4.address`が`auto`の場合の作成時の初期値: `true`） | NATするかどうか +`ipv4.nat.address` | string | IPv4 アドレス | - | ネットワークからの外向きトラフィックに使用されるソースアドレス（アップリンクに`ovn.ingress_mode=routed`が必要） +`ipv6.address` | string | 標準モード | - （作成時の初期値: `auto`） | ブリッジのIPv6アドレス（CIDR形式）。IPv6をオフにするには`none`、新しいランダムな未使用のサブネットを生成するには`auto`を指定。 +`ipv6.dhcp` | bool | IPv6 アドレス | `true` | Whether to provide additional network configuration over DHCP +`ipv6.dhcp.stateful` | bool | IPv6 DHCP | `false` | DHCPを使ってアドレスを割り当てるかどうか +`ipv6.l3only` | bool | IPv6 DHCP ステートフル | `false` | layer 3 only モード を有効にするかどうか +`ipv6.nat` | bool | IPv6 アドレス | `false` （`ipv6.address`が`auto`の場合の作成時の初期値: `true`） | NATするかどうか +`ipv6.nat.address` | string | IPv6 アドレス | - | ネットワークからの外向きトラフィックに使用されるソースアドレス（アップリンクに`ovn.ingress_mode=routed`が必要） +`security.acls` | string | - | - | このネットワークに接続するNICに適用するネットワークACLのカンマ区切りリスト +`security.acls.default.egress.action` | string | `security.acls` | `reject` | どのACLルールにもマッチしない外向きトラフィックに使うアクション +`security.acls.default.egress.logged` | bool | `security.acls` | `false` | どのACLルールにもマッチしない外向きトラフィックをログ出力するかどうか +`security.acls.default.ingress.action` | string | `security.acls` | `reject` | どのACLルールにもマッチしない内向きトラフィックに使うアクション +`security.acls.default.ingress.logged` | bool | `security.acls` | `false` | どのACLルールにもマッチしない内向きトラフィックをログ出力するかどうか +`user.*` | string | - | - | ユーザー指定の自由形式のキー／バリューペア (network-ovn-features)= -## Supported features +## サポートされている機能 -The following features are supported for the `ovn` network type: +`ovn`ネットワークタイプでは以下の機能がサポートされています: - {ref}`network-acls` - {ref}`network-forwards` @@ -82,7 +82,7 @@ The following features are supported for the `ovn` network type: :maxdepth: 1 :hidden: -Set up OVN -Create routing relationships -Configure network load balancers +OVNのセットアップ +ルーティング関係を作成 +ネットワークロードバランサーを設定 ``` diff --git a/doc/reference/network_physical.md b/doc/reference/network_physical.md index 3da8cf731a4..41107138a30 100644 --- a/doc/reference/network_physical.md +++ b/doc/reference/network_physical.md @@ -1,56 +1,55 @@ (network-physical)= -# Physical network +# 物理ネットワーク -The `physical` network type connects to an existing physical network, which can be a network interface or a bridge, and serves as an uplink network for OVN. +物理 (`physical`) ネットワークタイプは既存のネットワークに接続します。これはネットワークインターフェースまたはブリッジになることができ、OVN のためのアップリンクネットワークとしての役目を果たします。 -This network type allows to specify presets to use when connecting OVN networks to a parent interface or to allow an instance to use a physical interface as a NIC. -In this case, the instance NICs can simply set the `network`option to the network they connect to without knowing any of the underlying configuration details. +このネットワークタイプは OVN ネットワークを親インターフェースに接続する際に使用するプリセットの設定を提供したり、インスタンスが物理インターフェースを NIC として使用できるようにします。この場合、インスタンス NIC は接続先の設定詳細を知ること無く単に `network` オプションを設定できるようにします。 (network-physical-options)= -## Configuration options +## 設定オプション -The following configuration key namespaces are currently supported for the `physical` network type: +物理ネットワークでは現在以下の設定キーNamespace がサポートされています: -- `bgp` (BGP peer configuration) -- `dns` (DNS server and resolution configuration) -- `ipv4` (L3 IPv4 configuration) -- `ipv6` (L3 IPv6 configuration) -- `ovn` (OVN configuration) -- `user` (free-form key/value for user metadata) +- `bgp`（BGP ピア設定） +- `dns`（DNS サーバーと名前解決の設定） +- `ipv4`（L3 IPv4 設定） +- `ipv6`（L3 IPv6 設定） +- `ovn`（OVN 設定） +- `user`（key/value の自由形式のユーザーメタデータ） ```{note} {{note_ip_addresses_CIDR}} ``` -The following configuration options are available for the `physical` network type: - -Key | Type | Condition | Default | Description -:-- | :-- | :-- | :-- | :-- -`gvrp` | bool | - | `false` | Register VLAN using GARP VLAN Registration Protocol -`mtu` | integer | - | - | The MTU of the new interface -`parent` | string | - | - | Existing interface to use for network -`vlan` | integer | - | - | The VLAN ID to attach to -`bgp.peers.NAME.address` | string | BGP server | - | Peer address (IPv4 or IPv6) for use by `ovn` downstream networks -`bgp.peers.NAME.asn` | integer | BGP server | - | Peer AS number for use by `ovn` downstream networks -`bgp.peers.NAME.password` | string | BGP server | - (no password) | Peer session password (optional) for use by `ovn` downstream networks -`bgp.peers.NAME.holdtime` | integer | BGP server | `180` | Peer session hold time (in seconds; optional) -`dns.nameservers` | string | standard mode | - | List of DNS server IPs on `physical` network -`ipv4.gateway` | string | standard mode | - | IPv4 address for the gateway and network (CIDR) -`ipv4.ovn.ranges` | string | - | - | Comma-separated list of IPv4 ranges to use for child OVN network routers (FIRST-LAST format) -`ipv4.routes` | string | IPv4 address | - | Comma-separated list of additional IPv4 CIDR subnets that can be used with child OVN networks `ipv4.routes.external` setting -`ipv4.routes.anycast` | bool | IPv4 address | `false` | Allow the overlapping routes to be used on multiple networks/NIC at the same time -`ipv6.gateway` | string | standard mode | - | IPv6 address for the gateway and network (CIDR) -`ipv6.ovn.ranges` | string | - | - | Comma-separated list of IPv6 ranges to use for child OVN network routers (FIRST-LAST format) -`ipv6.routes` | string | IPv6 address | - | Comma-separated list of additional IPv6 CIDR subnets that can be used with child OVN networks `ipv6.routes.external` setting -`ipv6.routes.anycast` | bool | IPv6 address | `false` | Allow the overlapping routes to be used on multiple networks/NIC at the same time -`ovn.ingress_mode` | string | standard mode | `l2proxy` | Sets the method how OVN NIC external IPs will be advertised on uplink network: `l2proxy` (proxy ARP/NDP) or `routed` -`user.*` | string | - | - | User-provided free-form key/value pairs +物理ネットワークタイプには以下の設定オプションがあります: + +キー | 型 | 条件 | デフォルト | 説明 +:-- | :-- | :-- | :-- | :-- +`gvrp` | bool | - | `false` | GARP VLAN Registration Protocol を使って VLAN を登録する +`mtu` | integer | - | - | 作成するインターフェースの MTU +`parent` | string | - | - | ネットワークで使う既存のインターフェース +`vlan` | integer | - | - | アタッチする先の VLAN ID +`bgp.peers.NAME.address` | string | BGP server | - | `ovn` ダウンストリームネットワークで使用するピアアドレス (IPv4 か IPv6) +`bgp.peers.NAME.asn` | integer | BGP server | - | `ovn` ダウンストリームネットワークで使用する AS 番号 +`bgp.peers.NAME.password` | string | BGP server | - (パスワード無し) | `ovn` ダウンストリームネットワークで使用するピアのセッションパスワード（省略可能） +`bgp.peers.NAME.holdtime` | integer | BGP server | `180` | ピアセッションホールドタイム (秒で指定、省略可能) +`dns.nameservers` | string | 標準モード | - | 物理 (`physical`) ネットワークの DNS サーバー IP のリスト +`ipv4.gateway` | string | 標準モード | - | ゲートウェイとネットワークの IPv4 アドレス（CIDR表記） +`ipv4.ovn.ranges` | string | - | - | 子供の OVN ネットワークルーターに使用する IPv4 アドレスの範囲（開始-終了 形式) のカンマ区切りリスト +`ipv4.routes` | string | IPv4 アドレス | - | 子供の OVN ネットワークの `ipv4.routes.external` 設定で利用可能な追加の IPv4 CIDR サブネットのカンマ区切りリスト +`ipv4.routes.anycast` | bool | IPv4 アドレス | `false` | 複数のネットワーク／NICで同時にオーバーラップするルートが使われることを許可するかどうか +`ipv6.gateway` | string | 標準モード | - | ゲートウェイとネットワークの IPv6 アドレス（CIDR表記） +`ipv6.ovn.ranges` | string | - | - | 子供の OVN ネットワークルーターに使用する IPv6 アドレスの範囲（開始-終了 形式) のカンマ区切りリスト +`ipv6.routes` | string | IPv6 アドレス | - | 子供の OVN ネットワークの `ipv6.routes.external` 設定で利用可能な追加の IPv6 CIDR サブネットのカンマ区切りリスト +`ipv6.routes.anycast` | bool | IPv6 アドレス | `false` | 複数のネットワーク／NICで同時にオーバーラップするルートが使われることを許可するかどうか +`ovn.ingress_mode` | string | 標準モード | `l2proxy` | OVN NIC の外部 IP アドレスがアップリンクネットワークで広告される方法を設定します。 `l2proxy` (proxy ARP/NDP) か `routed` です。 +`user.*` | string | - | - | ユーザー指定の自由形式のキー／バリューペア (network-physical-features)= -## Supported features +## サポートされている機能 -The following features are supported for the `physical` network type: +物理ネットワークタイプでは以下の機能がサポートされています: - {ref}`network-bgp` diff --git a/doc/reference/network_sriov.md b/doc/reference/network_sriov.md index 6312d8f10b2..f3f40c452ae 100644 --- a/doc/reference/network_sriov.md +++ b/doc/reference/network_sriov.md @@ -1,29 +1,29 @@ (network-sriov)= -# SR-IOV network +# SR-IOV ネットワーク -{abbr}`SR-IOV (Single root I/O virtualization)` is a hardware standard that allows a single network card port to appear as several virtual network interfaces in a virtualized environment. +{abbr}`SR-IOV (Single root I/O virtualization)` は仮想環境内で単一のネットワークポートを複数の仮想ネットワークインターフェースのように見せるように出来るハードウェア標準です。 -The `sriov` network type allows to specify presets to use when connecting instances to a parent interface. -In this case, the instance NICs can simply set the `network` option to the network they connect to without knowing any of the underlying configuration details. +`sriov` ネットワークタイプは親のインターフェースに接続する際に使用するプリセットを指定できるようにします。 +この場合接続先の設定詳細を一切知ること無くインスタンス NIC に単に `network` オプションを設定できます。 (network-sriov-options)= -## Configuration options +## 設定オプション -The following configuration key namespaces are currently supported for the `sriov` network type: +`sriov` ネットワークでは現在以下の設定キーNamespace がサポートされています。 -- `user` (free-form key/value for user metadata) +- `user`（key/value の自由形式のユーザーメタデータ） ```{note} {{note_ip_addresses_CIDR}} ``` -The following configuration options are available for the `sriov` network type: +`sriov` ネットワークタイプには以下の設定オプションがあります。 -Key | Type | Condition | Default | Description -:-- | :-- | :-- | :-- | :-- -`mtu` | integer | - | - | The MTU of the new interface -`parent` | string | - | - | Parent interface to create `sriov` NICs on -`vlan` | integer | - | - | The VLAN ID to attach to -`user.*` | string | - | - | User-provided free-form key/value pairs +キー | 型 | 条件 | デフォルト | 説明 +:-- | :-- | :-- | :-- | :-- +`mtu` | integer | - | - | 作成するインターフェースの MTU +`parent` | string | - | - | `sriov` NIC を作成する親のインターフェース +`vlan` | integer | - | - | アタッチする先の VLAN ID +`user.*` | string | - | - | ユーザー指定の自由形式のキー／バリューペア diff --git a/doc/reference/projects.md b/doc/reference/projects.md index 439d4938294..dc76a9c2fda 100644 --- a/doc/reference/projects.md +++ b/doc/reference/projects.md @@ -1,11 +1,11 @@ (ref-projects)= -# Project configuration +# プロジェクトの設定 -Projects can be configured through a set of key/value configuration options. -See {ref}`projects-configure` for instructions on how to set these options. +プロジェクトは、キー/値の設定オプションのセットを通じて設定することができます。 +これらのオプションを設定する方法については、{ref}`projects-configure` を参照してください。 -The key/value configuration is namespaced. -The following options are available: +キー/値の設定は名前空間化されています。 +次のオプションが利用可能です: - {ref}`project-features` - {ref}`project-limits` @@ -13,17 +13,17 @@ The following options are available: - {ref}`project-specific-config` (project-features)= -## Project features +## プロジェクトの機能 -The project features define which entities are isolated in the project and which are inherited from the `default` project. +プロジェクトの機能は、プロジェクト内でどのエンティティが隔離され、どのエンティティが`default`プロジェクトから継承されるかを定義します。 -If a `feature.*` option is set to `true`, the corresponding entity is isolated in the project. +`feature.*` オプションが `true` に設定されている場合、対応するエンティティはプロジェクト内で隔離されます。 ```{note} -When you create a project without explicitly configuring a specific option, this option is set to the initial value given in the following table. +特定のオプションを明示的に設定せずにプロジェクトを作成すると、このオプションは以下の表で与えられた初期値に設定されます。 -However, if you unset one of the `feature.*` options, it does not go back to the initial value, but to the default value. -The default value for all `feature.*` options is `false`. +ただし、`feature.*` オプションのいずれかを解除すると、初期値に戻るのではなく、デフォルト値に戻ります。 +すべての `feature.*` オプションのデフォルト値は `false` です。 ``` % Include content from [../config_options.txt](../config_options.txt) @@ -33,24 +33,25 @@ The default value for all `feature.*` options is `false`. ``` (project-limits)= -## Project limits +## プロジェクトの制限 -Project limits define a hard upper bound for the resources that can be used by the containers and VMs that belong to a project. +プロジェクトの制限は、プロジェクトに属するコンテナや VM が使用できるリソースの上限を定義します。 -Depending on the `limits.*` option, the limit applies to the number of entities that are allowed in the project (for example, {config:option}`project-limits:limits.containers` or {config:option}`project-limits:limits.networks`) or to the aggregate value of resource usage for all instances in the project (for example, {config:option}`project-limits:limits.cpu` or {config:option}`project-limits:limits.processes`). -In the latter case, the limit usually applies to the {ref}`instance-options-limits` that are configured for each instance (either directly or via a profile), and not to the resources that are actually in use. +`limits.*` オプションによっては、プロジェクト内で許可されるエンティティの数に制限が適用されることがあります（たとえば {config:option}`project-limits:limits.containers` や {config:option}`project-limits:limits.networks`）。また、プロジェクト内のすべてのインスタンスのリソース使用量の合計値に制限が適用されることもあります（たとえば、 {config:option}`project-limits:limits.cpu` や {config:option}`project-limits:limits.processes`）。 +後者の場合、制限は通常、各インスタンスに設定されている {ref}`instance-options-limits` に適用されます（直接またはプロファイル経由で設定されている場合）、実際に使用されているリソースではありません。 -For example, if you set the project's {config:option}`project-limits:limits.memory` configuration to `50GiB`, the sum of the individual values of all {config:option}`instance-resource-limits:limits.memory` configuration keys defined on the project's instances will be kept under 50 GiB. +たとえば、プロジェクトの {config:option}`project-limits:limits.memory` 設定を `50GB` に設定した場合、プロジェクトのインスタンスで定義されたすべての {config:option}`project-limits:limits.memory` 設定キーの個別の値の合計が 50GB 未満に保たれます。 +{config:option}`project-limits:limits.memory` 設定の合計が 50GB を超えるインスタンスを作成しようとすると、エラーが発生します。 -Similarly, setting the project's {config:option}`project-limits:limits.cpu` configuration key to `100` means that the sum of individual {config:option}`instance-resource-limits:limits.cpu` values will be kept below 100. +同様に、プロジェクトの {config:option}`project-limits:limits.cpu` 設定キーを `100` に設定すると、個々の {config:option}`project-limits:limits.cpu` 値の合計が 100 未満に保たれます。 -When using project limits, the following conditions must be fulfilled: +プロジェクトの制限を使用する場合、以下の条件を満たす必要があります: -- When you set one of the `limits.*` configurations and there is a corresponding configuration for the instance, all instances in the project must have the corresponding configuration defined (either directly or via a profile). - See {ref}`instance-options-limits` for the instance configuration options. -- The {config:option}`project-limits:limits.cpu` configuration cannot be used if {ref}`instance-options-limits-cpu` is enabled. - This means that to use {config:option}`project-limits:limits.cpu` on a project, the {config:option}`instance-resource-limits:limits.cpu` configuration of each instance in the project must be set to a number of CPUs, not a set or a range of CPUs. -- The {config:option}`project-limits:limits.memory` configuration must be set to an absolute value, not a percentage. +- `limits.*` 設定のいずれかを設定し、インスタンスに対応する設定がある場合、プロジェクト内のすべてのインスタンスに対応する設定が定義されている必要があります（直接またはプロファイル経由で設定）。 + インスタンスの設定オプションについては {ref}`instance-options-limits` を参照してください。 +- {ref}`instance-options-limits-cpu` が有効になっている場合、{ref}`instance-options-limits-cpu` 設定は使用できません。 + これは、プロジェクトで {ref}`instance-options-limits-cpu` を使用するためには、プロジェクト内の各インスタンスの {ref}`instance-options-limits-cpu` 設定を CPU の数、または CPU のセットや範囲ではなく、数値に設定する必要があることを意味します。 +- {config:option}`project-limits:limits.memory` 設定は、パーセンテージではなく絶対値で設定する必要があります。 % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt @@ -59,26 +60,26 @@ When using project limits, the following conditions must be fulfilled: ``` (project-restrictions)= -## Project restrictions +## プロジェクトの制約 -To prevent the instances of a project from accessing security-sensitive features (such as container nesting or raw LXC configuration), set the {config:option}`project-restricted:restricted` configuration option to `true`. -You can then use the various `restricted.*` options to pick individual features that would normally be blocked by {config:option}`project-restricted:restricted` and allow them, so they can be used by the instances of the project. +プロジェクトのインスタンスがセキュリティーに関連する機能（コンテナのネストや raw LXC 設定など）にアクセスできないようにするには、{config:option}`project-restricted:restricted` 設定オプションを `true` に設定します。 +その後、さまざまな `restricted.*` オプションを使用して、通常は {config:option}`project-restricted:restricted` によってブロックされる個々の機能を選択し、プロジェクトのインスタンスで使用できるように許可できます。 -For example, to restrict a project and block all security-sensitive features, but allow container nesting, enter the following commands: +たとえば、プロジェクトを制限し、すべてのセキュリティー関連機能をブロックしつつ、コンテナのネストを許可するには、次のコマンドを入力します: incus project set restricted=true incus project set restricted.containers.nesting=allow -Each security-sensitive feature has an associated `restricted.*` project configuration option. -If you want to allow the usage of a feature, change the value of its `restricted.*` option. -Most `restricted.*` configurations are binary switches that can be set to either `block` (the default) or `allow`. -However, some options support other values for more fine-grained control. +セキュリティーに関連する各機能には、関連する `restricted.*` プロジェクト設定オプションがあります。 +機能の使用を許可する場合は、その `restricted.*` オプションの値を変更してください。 +ほとんどの `restricted.*` 設定は、`block`（デフォルト）または `allow` に設定できる二値スイッチです。 +ただし、一部のオプションは、より細かい制御のために他の値をサポートしています。 ```{note} -You must set the `restricted` configuration to `true` for any of the `restricted.*` options to be effective. -If `restricted` is set to `false`, changing a `restricted.*` option has no effect. +`restricted.*` オプションを有効にするには、`restricted` 設定を `true` に設定する必要があります。 +`restricted` が `false` に設定されている場合、`restricted.*` オプションを変更しても効果はありません。 -Setting all `restricted.*` keys to `allow` is equivalent to setting `restricted` itself to `false`. +すべての `restricted.*` キーを `allow` に設定することは、`restricted` 自体を `false` に設定することと同等です。 ``` % Include content from [../config_options.txt](../config_options.txt) @@ -88,10 +89,10 @@ Setting all `restricted.*` keys to `allow` is equivalent to setting `restricted` ``` (project-specific-config)= -## Project-specific configuration +## プロジェクト固有の設定 -There are some {ref}`server` options that you can override for a project. -In addition, you can add user metadata for a project. +プロジェクトに対していくつかの {ref}`server` オプションを上書きできます。 +また、プロジェクトにユーザーメタデータを追加することができます。 % Include content from [../config_options.txt](../config_options.txt) ```{include} ../config_options.txt diff --git a/doc/reference/provided_metrics.md b/doc/reference/provided_metrics.md index b119c83b938..9a7a2b5974b 100644 --- a/doc/reference/provided_metrics.md +++ b/doc/reference/provided_metrics.md @@ -1,155 +1,155 @@ (provided-metrics)= -# Provided metrics +# 提供されるメトリクス -Incus provides a number of instance metrics and internal metrics. -See {ref}`metrics` for instructions on how to work with these metrics. +Incus は、数々のインスタンスメトリクスと内部メトリクスを提供します。 +これらのメトリクスの取り扱い方については、{ref}`metrics`を参照してください。 -## Instance metrics +## インスタンスメトリクス -The following instance metrics are provided: +以下のインスタンスメトリクスが提供されています: ```{list-table} :header-rows: 1 -* - Metric - - Description +* - メトリック + - 説明 * - `incus_cpu_effective_total` - - Total number of effective CPUs + - 使用可能なCPUの総数 * - `incus_cpu_seconds_total{cpu="", mode=""}` - - Total number of CPU time used (in seconds) + - 使用されたCPU時間の合計（秒単位） * - `incus_disk_read_bytes_total{device=""}` - - Total number of bytes read + - 読み出されたバイト数合計 * - `incus_disk_reads_completed_total{device=""}` - - Total number of completed reads + - 完了した読み取り回数合計 * - `incus_disk_written_bytes_total{device=""}` - - Total number of bytes written + - 書き込まれたバイト数合計 * - `incus_disk_writes_completed_total{device=""}` - - Total number of completed writes + - 完了した書き込み回数合計 * - `incus_filesystem_avail_bytes{device="",fstype=""}` - - Available space (in bytes) + - 利用可能な領域（バイト単位） * - `incus_filesystem_free_bytes{device="",fstype=""}` - - Free space (in bytes) + - 空き領域（バイト単位） * - `incus_filesystem_size_bytes{device="",fstype=""}` - - Size of the file system (in bytes) + - ファイルシステムのサイズ（バイト単位） * - `incus_memory_Active_anon_bytes` - - Amount of anonymous memory on active LRU list + - アクティブLRUリスト上のアノニマスメモリの量 * - `incus_memory_Active_bytes` - - Amount of memory on active LRU list + - アクティブLRUリスト上のメモリの量 * - `incus_memory_Active_file_bytes` - - Amount of file-backed memory on active LRU list + - アクティブLRUリスト上のディスク同期して解放できる（file-backed）メモリの量 * - `incus_memory_Cached_bytes` - - Amount of cached memory + - キャッシュメモリの量 * - `incus_memory_Dirty_bytes` - - Amount of memory waiting to be written back to the disk + - ディスクへの書き戻し待ちのメモリの量 * - `incus_memory_HugepagesFree_bytes` - - Amount of free memory for `hugetlb` + - `hugetlb`の空きメモリの量 * - `incus_memory_HugepagesTotal_bytes` - - Amount of used memory for `hugetlb` + - `hugetlb`の使用メモリの量 * - `incus_memory_Inactive_anon_bytes` - - Amount of anonymous memory on inactive LRU list + - 非アクティブLRUリスト上のアノニマスメモリの量 * - `incus_memory_Inactive_bytes` - - Amount of memory on inactive LRU list + - 非アクティブLRUリスト上のメモリの量 * - `incus_memory_Inactive_file_bytes` - - Amount of file-backed memory on inactive LRU list + - 非アクティブLRUリスト上のディスク同期して解放できる（file-backed）メモリの量 * - `incus_memory_Mapped_bytes` - - Amount of mapped memory + - マップされたメモリの量 * - `incus_memory_MemAvailable_bytes` - - Amount of available memory + - 利用可能なメモリの量 * - `incus_memory_MemFree_bytes` - - Amount of free memory + - 空きメモリの量 * - `incus_memory_MemTotal_bytes` - - Amount of used memory + - 使用中メモリの量 * - `incus_memory_OOM_kills_total` - - The number of out-of-memory kills + - out-of-memoryでkillされた回数 * - `incus_memory_RSS_bytes` - - Amount of anonymous and swap cache memory + - アノニマスとswapキャッシュメモリの量 * - `incus_memory_Shmem_bytes` - - Amount of cached file system data that is swap-backed + - スワップアウトして解放できる（swap-backed）キャッシュされたファイルシステムデータの量 * - `incus_memory_Swap_bytes` - - Amount of used swap memory + - 使用中のスワップメモリの量 * - `incus_memory_Unevictable_bytes` - - Amount of unevictable memory + - 回収不可のメモリの使用量 * - `incus_memory_Writeback_bytes` - - Amount of memory queued for syncing to disk + - ディスクへの同期のためにキューに入れられているメモリの量 * - `incus_network_receive_bytes_total{device=""}` - - Amount of received bytes on a given interface + - 指定のインタフェース上の受信したバイト数 * - `incus_network_receive_drop_total{device=""}` - - Amount of received dropped bytes on a given interface + - 指定のインタフェース上の受信でドロップしたバイト数 * - `incus_network_receive_errs_total{device=""}` - - Amount of received errors on a given interface + - 指定のインタフェース上の受信エラー数 * - `incus_network_receive_packets_total{device=""}` - - Amount of received packets on a given interface + - 指定のインタフェース上の受信パケット数 * - `incus_network_transmit_bytes_total{device=""}` - - Amount of transmitted bytes on a given interface + - 指定のインタフェース上の送信したバイト数 * - `incus_network_transmit_drop_total{device=""}` - - Amount of transmitted dropped bytes on a given interface + - 指定のインタフェース上の送信でドロップしたバイト数 * - `incus_network_transmit_errs_total{device=""}` - - Amount of transmitted errors on a given interface + - 指定のインタフェース上の送信エラー数 * - `incus_network_transmit_packets_total{device=""}` - - Amount of transmitted packets on a given interface + - 指定のインタフェース上の送信パケット数 * - `incus_procs_total` - - Number of running processes + - 稼働中のプロセス数 ``` -## Internal metrics +## 内部メトリクス -The following internal metrics are provided: +以下の内部メトリクスが提供されています: ```{list-table} :header-rows: 1 -* - Metric - - Description +* - メトリック + - 説明 * - `incus_go_alloc_bytes_total` - - Total number of bytes allocated (even if freed) + - 割り当てられた（その後の解放された分も含む）バイト数累計 * - `incus_go_alloc_bytes` - - Number of bytes allocated and still in use + - 割り当てられ使用中のバイト数 * - `incus_go_buck_hash_sys_bytes` - - Number of bytes used by the profiling bucket hash table + - プロファイルのバケットハッシュテーブルで使用されたバイト数 * - `incus_go_frees_total` - - Total number of frees + - 解放の合計回数 * - `incus_go_gc_sys_bytes` - - Number of bytes used for garbage collection system metadata + - システムメタデータのガベージコレクションで使用されたバイト数 * - `incus_go_goroutines` - - Number of goroutines that currently exist + - 現在存在するgoroutine数 * - `incus_go_heap_alloc_bytes` - - Number of heap bytes allocated and still in use + - 割り当てられ使用中のヒープのバイト数 * - `incus_go_heap_idle_bytes` - - Number of heap bytes waiting to be used + - 使用を待っているヒープのバイト数 * - `incus_go_heap_inuse_bytes` - - Number of heap bytes that are in use + - 使用中のヒープのバイト数 * - `incus_go_heap_objects` - - Number of allocated objects + - 割り当てられたオブジェクト数 * - `incus_go_heap_released_bytes` - - Number of heap bytes released to OS + - OSに開放されたヒープのバイト数 * - `incus_go_heap_sys_bytes` - - Number of heap bytes obtained from system + - システムから取得されたヒープのバイト数 * - `incus_go_lookups_total` - - Total number of pointer lookups + - ポインタルックアップの合計回数 * - `incus_go_mallocs_total` - - Total number of `mallocs` + - `mallocs`の合計回数 * - `incus_go_mcache_inuse_bytes` - - Number of bytes in use by `mcache` structures + - `mcache`構造で使用されるバイト数 * - `incus_go_mcache_sys_bytes` - - Number of bytes used for `mcache` structures obtained from system + - システムから取得された`mcache`構造で使用されるバイト数 * - `incus_go_mspan_inuse_bytes` - - Number of bytes in use by `mspan` structures + - `mspan`構造で使用されるバイト数 * - `incus_go_mspan_sys_bytes` - - Number of bytes used for `mspan` structures obtained from system + - システムから取得された`mspan`構造で使用されるバイト数 * - `incus_go_next_gc_bytes` - - Number of heap bytes when next garbage collection will take place + - 次のガベージコレクションが発生する際のヒープのバイト数 * - `incus_go_other_sys_bytes` - - Number of bytes used for other system allocations + - 他のシステム割当に使用されるバイト数 * - `incus_go_stack_inuse_bytes` - - Number of bytes in use by the stack allocator + - スタックアロケータに使用されるバイト数 * - `incus_go_stack_sys_bytes` - - Number of bytes obtained from system for stack allocator + - スタックアロケータ用にシステムから取得されたバイト数 * - `incus_go_sys_bytes` - - Number of bytes obtained from system + - システムから取得されたバイト数 * - `incus_operations_total` - - Number of running operations + - 実行中の処理の数 * - `incus_uptime_seconds` - - Daemon uptime (in seconds) + - デーモンのuptime（秒単位） * - `incus_warnings_total` - - Number of active warnings + - アクティブな警告の数 ``` diff --git a/doc/reference/remote_image_servers.md b/doc/reference/remote_image_servers.md index 4d979547631..90feab75d56 100644 --- a/doc/reference/remote_image_servers.md +++ b/doc/reference/remote_image_servers.md @@ -1,31 +1,32 @@ (remote-image-servers)= -# Remote image servers +# リモートイメージサーバー -The [`incus`](incus.md) CLI command comes pre-configured with the following default remote image servers: + +[`incus`](incus.md) CLI コマンドは下記のデフォルトリモートイメージサーバーが初期設定されています: `images:` -: This server provides unofficial images for a variety of Linux distributions. - The images are maintained by the [Linux Containers](https://linuxcontainers.org/) team and are built to be compact and minimal. +: このサーバーはさまざまな Linux ディストリビューションの非公式イメージを提供します。 + イメージは[Linux Containers](https://linuxcontainers.org/)チームによりメンテナンスされ、コンパクトで最小限にビルドされています。 - See [`images.linuxcontainers.org`](https://images.linuxcontainers.org) for an overview of available images. + 利用可能なイメージの概要については[`images.linuxcontainers.org`](https://images.linuxcontainers.org)を参照してください。 (remote-image-server-types)= -## Remote server types +## リモートサーバータイプ -Incus supports the following types of remote image servers: +Incus は下記のタイプのリモートイメージサーバーをサポートします: -Simple streams servers -: Pure image servers that use the [simple streams format](https://git.launchpad.net/simplestreams/tree/). - The default image servers are simple streams servers. +simple streams サーバー +: [simple streams形式](https://git.launchpad.net/simplestreams/tree/)を使う純粋なイメージサーバー。 + デフォルトのイメージサーバーは simple streams サーバーです。 -Public Incus servers -: Incus servers that are used solely to serve images and do not run instances themselves. +公開 Incus サーバー +: イメージを配布するためだけに稼働し、このサーバー自身ではインスタンスを稼働しない Incus サーバー。 - To make a Incus server publicly available over the network on port 8443, set the {config:option}`server-core:core.https_address` configuration option to `:8443` and do not configure any authentication methods (see {ref}`server-expose` for more information). - Then set the images that you want to share to `public`. + Incus サーバーをポート 8443 で公開で利用可能にするには、{config:option}`server-core:core.https_address`設定オプションを`:8443`に設定し、認証方法をなにも設定しないようにします（詳細は{ref}`server-expose`参照）。 + そして共有したいイメージを`public`にセットします。 -Incus servers -: Regular Incus servers that you can manage over a network, and that can also be used as image servers. +Incus サーバー +: ネットワーク越しに管理できる通常の Incus サーバー、イメージサーバーとしても利用可能。 - For security reasons, you should restrict the access to the remote API and configure an authentication method to control access. - See {ref}`server-expose` and {ref}`authentication` for more information. + セキュリティー上の理由により、リモート API へのアクセスを制限し、アクセス制御のための認証方法を設定するほうが良いです。 + 詳細な情報は{ref}`server-expose`と{ref}`authentication`を参照してください。 diff --git a/doc/reference/standard_devices.md b/doc/reference/standard_devices.md index 55c1ff232e2..efa4005c8c2 100644 --- a/doc/reference/standard_devices.md +++ b/doc/reference/standard_devices.md @@ -1,23 +1,23 @@ (standard-devices)= -# Standard devices +# 標準デバイス -Incus provides each instance with the basic devices that are required for a standard POSIX system to work. -These devices aren't visible in the instance or profile configuration, and they may not be overridden. +Incus は、標準の POSIX システムが動作するのに必要な基本的なデバイスを常にインスタンスに提供します。 +これらはインスタンスやプロファイルの設定では見えず、上書きもできません。 -The standard devices are: +標準デバイスは次のようなデバイスが含まれます。 -| Device | Type of device | -|:---------------|:------------------| -| `/dev/null` | Character device | -| `/dev/zero` | Character device | -| `/dev/full` | Character device | -| `/dev/console` | Character device | -| `/dev/tty` | Character device | -| `/dev/random` | Character device | -| `/dev/urandom` | Character device | -| `/dev/net/tun` | Character device | -| `/dev/fuse` | Character device | -| `lo` | Network interface | +| デバイス | デバイスのタイプ | +| :--------------- | :------------------ | +| `/dev/null` | キャラクタデバイス | +| `/dev/zero` | キャラクタデバイス | +| `/dev/full` | キャラクタデバイス | +| `/dev/console` | キャラクタデバイス | +| `/dev/tty` | キャラクタデバイス | +| `/dev/random` | キャラクタデバイス | +| `/dev/urandom` | キャラクタデバイス | +| `/dev/net/tun` | キャラクタデバイス | +| `/dev/fuse` | キャラクタデバイス | +| `lo` | ネットワークインターフェース | -Any other devices must be defined in the instance configuration or in one of the profiles used by the instance. -The default profile typically contains a network interface that becomes `eth0` in the instance. +これ以外に関しては、インスタンスの設定もしくはインスタンスで使われるいずれかのプロファイルで定義する必要があります。 +デフォルトのプロファイルには、インスタンス内で`eth0`になるネットワークインターフェースが通常は含まれます。 diff --git a/doc/reference/storage_btrfs.md b/doc/reference/storage_btrfs.md index bc9d977ef79..54291714bf1 100644 --- a/doc/reference/storage_btrfs.md +++ b/doc/reference/storage_btrfs.md @@ -1,90 +1,90 @@ (storage-btrfs)= # Btrfs - `btrfs` -{abbr}`Btrfs (B-tree file system)` is a local file system based on the {abbr}`COW (copy-on-write)` principle. -COW means that data is stored to a different block after it has been modified instead of overwriting the existing data, reducing the risk of data corruption. -Unlike other file systems, Btrfs is extent-based, which means that it stores data in contiguous areas of memory. +{abbr}`Btrfs (B-tree file system)` は {abbr}`COW (copy-on-write)` 原則に基づいたローカルファイルシステムです。 +COW はデータが修正された後に既存のデータを上書きするのではなく別のブロックに保管され、データ破壊のリスクが低くなることを意味します。 +他のファイルシステムと異なり、Btrfs はエクステントベースです。これはデータを連続したメモリー領域に保管することを意味します。 -In addition to basic file system features, Btrfs offers RAID and volume management, pooling, snapshots, checksums, compression and other features. +基本的なファイルシステムの機能に加えて、Btrfs は RAID、ボリューム管理、プーリング、スナップショット、チェックサム、圧縮、その他の機能を提供します。 -To use Btrfs, make sure you have `btrfs-progs` installed on your machine. +Btrfs を使うにはマシンに `btrfs-progs` がインストールされているか確認してください。 -## Terminology +## 用語 -A Btrfs file system can have *subvolumes*, which are named binary subtrees of the main tree of the file system with their own independent file and directory hierarchy. -A *Btrfs snapshot* is a special type of subvolume that captures a specific state of another subvolume. -Snapshots can be read-write or read-only. +Btrfs ファイルシステムは*サブボリューム*を持つことができます。これはファイルシステムのメインツリーの名前をつけられたバイナリサブツリーでそれ自身の独立したファイルとディレクトリー階層を持ちます。 +*Btrfs スナップショット*は特殊なタイプのサブボリュームで別のサブボリュームの特定の状態をキャプチャーします。 +スナップショットは読み書き可または読み取り専用にできます。 -## `btrfs` driver in Incus +## Incus の `btrfs` ドライバー -The `btrfs` driver in Incus uses a subvolume per instance, image and snapshot. -When creating a new entity (for example, launching a new instance), it creates a Btrfs snapshot. +Incus の `btrfs` ドライバーはインスタンス、イメージ、スナップショットごとにサブボリュームを使用します。 +新しいエンティティを作成する際（たとえば、新しいインスタンスを起動する）、 Btrfs スナップショットを作成します。 -Btrfs doesn't natively support storing block devices. -Therefore, when using Btrfs for VMs, Incus creates a big file on disk to store the VM. -This approach is not very efficient and might cause issues when creating snapshots. +Btrfs はブロックデバイスの保管をネイティブにはサポートしていません。 +このため、仮想マシンに Btrfs を使用する場合、 Incus は仮想マシンを格納するディスク上に巨大なファイルを作成します。 +このアプローチはあまり効率的ではなく、スナップショット作成時に問題を引き起こすかもしれません。 -Btrfs can be used as a storage backend inside a container in a nested Incus environment. -In this case, the parent container itself must use Btrfs. -Note, however, that the nested Incus setup does not inherit the Btrfs quotas from the parent (see {ref}`storage-btrfs-quotas` below). +Btrfs はネストした Incus 環境内のコンテナ内部でストレージバックエンドとして使用できます。 +この場合、親のコンテナ自体は Btrfs を使う必要があります。 +しかし、ネストした Incus のセットアップは親から Btrfs のクォータは引き継がないことに注意してください（以下の {ref}`storage-btrfs-quotas` 参照）。 (storage-btrfs-quotas)= -### Quotas +### クォータ -Btrfs supports storage quotas via qgroups. -Btrfs qgroups are hierarchical, but new subvolumes will not automatically be added to the qgroups of their parent subvolumes. -This means that users can trivially escape any quotas that are set. -Therefore, if strict quotas are needed, you should consider using a different storage driver (for example, ZFS with `refquota` or LVM with Btrfs on top). +Btrfs は qgroups 経由でストレージクォータをサポートします。 +Btrfs qgroups は階層的ですが、新しいサブボリュームは親のサブボリュームの qgroups に自動的に追加されるわけではありません。 +これはユーザーが設定されたクォータから逃れることができることは自明であることを意味します。 +このため、厳密なクォータが必要な場合は、別のストレージドライバーを検討すべきです（たとえば、`refquotas` ありの ZFS や LVM 上の Btrfs）。 -When using quotas, you must take into account that Btrfs extents are immutable. -When blocks are written, they end up in new extents. -The old extents remain until all their data is dereferenced or rewritten. -This means that a quota can be reached even if the total amount of space used by the current files in the subvolume is smaller than the quota. +クォータを使用する際は、 Btrfs のエクステントはイミュータブルであることを考慮に入れる必要があります。 +ブロックが書かれると、それらは新しいエクステントに現れます。 +古いエクステントはその上のすべてのデータが参照されなくなるか上書きされるまで残ります。 +これはサブボリューム内で現在存在するファイルで使用されている合計容量がクォータより小さい場合でもクォータに達することがあり得ることを意味します。 ```{note} -This issue is seen most often when using VMs on Btrfs, due to the random I/O nature of using raw disk image files on top of a Btrfs subvolume. +この問題は Btrfs 上で仮想マシンを使用する際にもっともよく発生します。これは Btrfs サブボリューム上に生のディスクイメージを使用する際のランダムな I/O の性質のためです。 -Therefore, you should never use VMs with Btrfs storage pools. +このため、仮想マシンには Btrfs ストレージプールは決して使うべきではありません。 -If you really need to use VMs with Btrfs storage pools, set the instance root disk's [`size.state`](devices-disk) property to twice the size of the root disk's size. -This configuration allows all blocks in the disk image file to be rewritten without reaching the qgroup quota. -The [`btrfs.mount_options=compress-force`](storage-btrfs-pool-config) storage pool option can also avoid this scenario, because a side effect of enabling compression is to reduce the maximum extent size such that block rewrites don't cause as much storage to be double-tracked. -However, this is a storage pool option, and it therefore affects all volumes on the pool. +どうしても仮想マシンに Btrfs ストレージプールを使う必要がある場合、インスタンスのルートディスクの [`size.state`](devices-disk) をルートディスクのサイズの2倍に設定してください。 +この設定により、ディスクイメージファイルの全てのブロックが qgroup クォータに達すること無しに上書きできるようになります。 +[`btrfs.mount_options=compress-force`](storage-btrfs-pool-config) ストレージプールオプションでもこのシナリオを回避できます。圧縮を有効にすることの副作用で最大のエクステントサイズを縮小しブロックの再書き込みが2倍のストレージを消費しないようになるからです。 +しかし、これはストレージプールのオプションなので、プール上の全てのボリュームに影響します。 ``` -## Configuration options +## 設定オプション -The following configuration options are available for storage pools that use the `btrfs` driver and for storage volumes in these pools. +`btrfs` ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。 (storage-btrfs-pool-config)= -### Storage pool configuration +## ストレージプール設定 -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`btrfs.mount_options` | string | `user_subvol_rm_allowed` | Mount options for block devices -`size` | string | auto (20% of free disk space, >= 5 GiB and <= 30 GiB) | Size of the storage pool when creating loop-based pools (in bytes, suffixes supported, can be increased to grow storage pool) -`source` | string | - | Path to an existing block device, loop file or Btrfs subvolume -`source.wipe` | bool | `false` | Wipe the block device specified in `source` prior to creating the storage pool +キー | 型 | デフォルト値 | 説明 +:-- | :--- | :-------- | :---------- +`btrfs.mount_options` | string | `user_subvol_rm_allowed` | ブロックデバイスのマウントオプション +`size` | string | 自動（空きディスクスペースの 20%, >= 5 GiB and <= 30 GiB） | ループベースのプールを作成する際のストレージプールのサイズ（バイト単位、接尾辞のサポートあり、増やすとストレージプールのサイズを拡大） +`source` | string | - | 既存のブロックデバイス、ループファイル、あるいはBtrfsサブボリュームのパス +`source.wipe` | bool | `false` | ストレージプールを作成する前に`source`で指定されたブロックデバイスの中身を消去する {{volume_configuration}} -### Storage volume configuration +### ストレージボリューム設定 -Key | Type | Condition | Default | Description -:-- | :--- | :-------- | :------ | :---------- -`security.shifted` | bool | custom volume | same as `volume.security.shifted` or `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | same as `volume.security.unmapped` or `false` | Disable ID mapping for the volume -`size` | string | appropriate driver | same as `volume.size` | Size/quota of the storage volume -`snapshots.expiry` | string | custom volume | same as `volume.snapshots.expiry` | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | same as `volume.snapshots.pattern` or `snap%d`| {{snapshot_pattern_format}} [^*] -`snapshots.schedule` | string | custom volume | same as `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}} [^*]: {{snapshot_pattern_detail}} -### Storage bucket configuration +### ストレージバケット設定 -To enable storage buckets for local storage pool drivers and allow applications to access the buckets via the S3 protocol, you must configure the {config:option}`server-core:core.storage_buckets_address` server setting. +ローカルのストレージプールドライバーでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには{config:option}`server-core:core.storage_buckets_address`サーバー設定を調整する必要があります。 -Key | Type | Condition | Default | Description -:-- | :--- | :-------- | :------ | :---------- -`size` | string | appropriate driver | same as `volume.size` | Size/quota of the storage bucket +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`size` | string | 適切なドライバー | `volume.size` と同じ | ストレージバケットのサイズ/クォータ diff --git a/doc/reference/storage_ceph.md b/doc/reference/storage_ceph.md index b0a26a9da1a..072cc3b086a 100644 --- a/doc/reference/storage_ceph.md +++ b/doc/reference/storage_ceph.md @@ -2,113 +2,113 @@ # Ceph RBD - `ceph` -[Ceph](https://ceph.io/en/) is an open-source storage platform that stores its data in a storage cluster based on {abbr}`RADOS (Reliable Autonomic Distributed Object Store)`. -It is highly scalable and, as a distributed system without a single point of failure, very reliable. +[Ceph](https://ceph.io/en/) はオープンソースのストレージプラットフォームで、データを {abbr}`RADOS (Reliable Autonomic Distributed Object Store)` に基づいたストレージクラスタ内に保管します。 +非常にスケーラブルで、単一障害点がない分散システムであり非常に信頼性が高いです。 ```{tip} -If you want to quickly set up a basic Ceph cluster, check out [MicroCeph](https://microcloud.is). +ベーシックなCephクラスタを素早く構築したい場合、[MicroCeph](https://microcloud.is)をチェックしてみてください。 ``` -Ceph provides different components for block storage and for file systems. +Ceph はブロックストレージ用とファイルシステム用に異なるコンポーネントを提供します。 -Ceph {abbr}`RBD (RADOS Block Device)` is Ceph's block storage component that distributes data and workload across the Ceph cluster. -It uses thin provisioning, which means that it is possible to over-commit resources. +Ceph {abbr}`RBD (RADOS Block Device)` はデータとワークロードを Ceph クラスタに分散する Ceph のブロックストレージコンポーネントです。 +これは薄いプロビジョニングを使用し、リソースをオーバーコミットできることを意味します。 -## Terminology +## 用語 -Ceph uses the term *object* for the data that it stores. -The daemon that is responsible for storing and managing data is the *Ceph {abbr}`OSD (Object Storage Daemon)`*. -Ceph's storage is divided into *pools*, which are logical partitions for storing objects. -They are also referred to as *data pools*, *storage pools* or *OSD pools*. +Ceph は保管するデータに *オブジェクト* という用語を使用します。 +データを保存と管理する責任を持つデーモンは *Ceph {abbr}`OSD (Object Storage Daemon)`* です。 +Ceph のストレージは *プール* に分割されます。これはオブジェクトを保管する論理的なパーティションです。 +これらは *データプール*, *ストレージプール*, *OSD プール* とも呼ばれます。 -Ceph block devices are also called *RBD images*, and you can create *snapshots* and *clones* of these RBD images. +Ceph ブロックデバイスは *RBD イメージ* とも呼ばれ、これらの RBD イメージの *スナップショット* と *クローン* を作成できます。 -## `ceph` driver in Incus +## Incus の `ceph` ドライバー ```{note} -To use the Ceph RBD driver, you must specify it as `ceph`. -This is slightly misleading, because it uses only Ceph RBD (block storage) functionality, not full Ceph functionality. -For storage volumes with content type `filesystem` (images, containers and custom file-system volumes), the `ceph` driver uses Ceph RBD images with a file system on top (see [`block.filesystem`](storage-ceph-vol-config)). +Ceph RBD ドライバを使用するには `ceph` と指定する必要があります。 +これは少し誤解を招く恐れがあります。 Ceph の全ての機能ではなく Ceph RBD（ブロックストレージ）の機能しか使わないからです。 +コンテントタイプ `filesystem`（イメージ、コンテナとカスタムファイルシステムボリューム）のストレージボリュームには `ceph` ドライバは Ceph RDB イメージをその上にファイルシステムがある状態で使用します（[`block.filesystem`](storage-ceph-vol-config) 参照）。 -Alternatively, you can use the {ref}`CephFS ` driver to create storage volumes with content type `filesystem`. +別の方法として、コンテントタイプ `filesystem` でストレージボリュームを作成するのに {ref}`CephFS ` を使用することもできます。 ``` -Unlike other storage drivers, this driver does not set up the storage system but assumes that you already have a Ceph cluster installed. +他のストレージドライバーとは異なり、このドライバーはストレージシステムをセットアップはせず、既に Ceph クラスタをインストール済みであると想定します。 -This driver also behaves differently than other drivers in that it provides remote storage. -As a result and depending on the internal network, storage access might be a bit slower than for local storage. -On the other hand, using remote storage has big advantages in a cluster setup, because all cluster members have access to the same storage pools with the exact same contents, without the need to synchronize storage pools. +このドライバーはリモートのストレージを提供するという意味でも他のドライバーとは異なる振る舞いをします。 +結果として、内部ネットワークに依存し、ストレージへのアクセスはローカルのストレージより少し遅くなるかもしれません。 +一方で、リモートのストレージを使うことはクラスタ構成では大きな利点があります。これはストレージプールを同期する必要なしに、すべてのクラスタメンバーが同じ内容を持つ同じストレージプールにアクセスできるからです。 -The `ceph` driver in Incus uses RBD images for images, and snapshots and clones to create instances and snapshots. +Incus 内の `ceph` ドライバーはイメージ、スナップショットに RBD イメージを使用し、インスタンスとスナップショットを作成するのにクローンを使用します。 -Incus assumes that it has full control over the OSD storage pool. -Therefore, you should never maintain any file system entities that are not owned by Incus in a Incus OSD storage pool, because Incus might delete them. +Incus は OSD ストレージプールに対して完全制御できることを想定します。 +このため、 Incus OSD ストレージプール内に Incus が所有しないファイルシステムエンティティは Incus が消してしまうかもしれないので決して置くべきではありません。 -Due to the way copy-on-write works in Ceph RBD, parent RBD images can't be removed until all children are gone. -As a result, Incus automatically renames any objects that are removed but still referenced. -Such objects are kept with a `zombie_` prefix until all references are gone and the object can safely be removed. +Ceph RBD 内で copy-on-write が動作する方法のため、親の RBD イメージはすべての子がいなくなるまで削除できません。 +結果として Incus は削除されたがまだ参照されているオブジェクトを自動的にリネームします。 +そのようなオブジェクトはすべての参照がいなくなりオブジェクトが安全に削除できるようになるまで `zombie_` 接頭辞をつけて維持されます。 -### Limitations +### 制限 -The `ceph` driver has the following limitations: +`ceph` ドライバーには以下の制限があります。 -Sharing custom volumes between instances -: Custom storage volumes with {ref}`content type ` `filesystem` can usually be shared between multiple instances different cluster members. - However, because the Ceph RBD driver "simulates" volumes with content type `filesystem` by putting a file system on top of an RBD image, custom storage volumes can only be assigned to a single instance at a time. - If you need to share a custom volume with content type `filesystem`, use the {ref}`CephFS ` driver instead. +インスタンス間でのカスタムボリュームの共有 +: {ref}`コンテントタイプ ` `filesystem` のカスタムストレージボリュームは異なるクラスタメンバーの複数のインスタンス間で通常は共有できます。 + しかし、 Ceph RBD ドライバーは RBD イメージ上にファイルシステムを置くことでコンテントタイプ `filesystem` のボリュームを「シミュレート」しているため、カスタムストレージボリュームは一度に 1 つのインスタンスにしか割り当てできません。 + コンテントタイプ `filesystem` のカスタムボリュームを共有する必要がある場合は代わりに {ref}`storage-cephfs` ドライバーを使用してください。 -Sharing the OSD storage pool between installations -: Sharing the same OSD storage pool between multiple Incus installations is not supported. +複数インストールされた Incus 間で OSD ストレージプールの共有 +: 複数インストールされた Incus 間で同じ OSD ストレージプールを共有することはサポートされていません。 -Using an OSD pool of type "erasure" -: To use a Ceph OSD pool of type "erasure", you must create the OSD pool beforehand. - You must also create a separate OSD pool of type "replicated" that will be used for storing metadata. - This is required because Ceph RBD does not support `omap`. - To specify which pool is "erasure coded", set the [`ceph.osd.data_pool_name`](storage-ceph-pool-config) configuration option to the erasure coded pool name and the [`source`](storage-ceph-pool-config) configuration option to the replicated pool name. +タイプ "erasure" の OSD プールの使用 +: タイプ "erasure" の OSD プールを使用するには事前に OSD プールを作成する必要があります。 + さらにタイプ "replicated" の別の OSD プールを作成する必要もあります。これはメタデータを保管するのに使用されます。 + これは Ceph RBD が `omap` をサポートしないために必要となります。 + どのプールが "erasure coded" であるかを指定するために [`ceph.osd.data_pool_name`](storage-ceph-pool-config) 設定オプションをイレージャーコーディングされたプールの名前に設定し [`source`](storage-ceph-pool-config) 設定オプションをリプリケートされたプールの名前に設定します。 -## Configuration options +## 設定オプション -The following configuration options are available for storage pools that use the `ceph` driver and for storage volumes in these pools. +`ceph` ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。 (storage-ceph-pool-config)= -### Storage pool configuration - -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`ceph.cluster_name` | string | `ceph` | Name of the Ceph cluster in which to create new storage pools -`ceph.osd.data_pool_name` | string | - | Name of the OSD data pool -`ceph.osd.pg_num` | string | `32` | Number of placement groups for the OSD storage pool -`ceph.osd.pool_name` | string | name of the pool | Name of the OSD storage pool -`ceph.rbd.clone_copy` | bool | `true` | Whether to use RBD lightweight clones rather than full dataset copies -`ceph.rbd.du` | bool | `true` | Whether to use RBD `du` to obtain disk usage data for stopped instances -`ceph.rbd.features` | string | `layering` | Comma-separated list of RBD features to enable on the volumes -`ceph.user.name` | string | `admin` | The Ceph user to use when creating storage pools and volumes -`source` | string | - | Existing OSD storage pool to use -`volatile.pool.pristine` | string | `true` | Whether the pool was empty on creation time +### ストレージプール設定 + +キー | 型 | デフォルト値 | 説明 +:-- | :--- | :------ | :---------- +`ceph.cluster_name` | string | `ceph` | 新しいストレージプールを作成する Ceph クラスタの名前 +`ceph.osd.data_pool_name` | string | - | OSD data pool の名前 +`ceph.osd.pg_num` | string | `32` | OSD ストレージプール用の placement グループの数 +`ceph.osd.pool_name` | string | プールの名前 | OSD ストレージプールの名前 +`ceph.rbd.clone_copy` | bool | `true` | フルのデータセットコピーではなく RBD のライトウェイトクローンを使うかどうか +`ceph.rbd.du` | bool | `true` | 停止したインスタンスのディスク使用データを取得するのに RBD `du` を使用するかどうか +`ceph.rbd.features` | string | `layering` | ボリュームで有効にする RBD の機能のカンマ区切りリスト +`ceph.user.name` | string | `admin` | ストレージプールとボリュームの作成に使用する Ceph ユーザー +`source` | string | - | 使用する既存の OSD ストレージプール +`volatile.pool.pristine` | string | `true` | プールが作成時に空かどうか {{volume_configuration}} (storage-ceph-vol-config)= -### Storage volume configuration - -Key | Type | Condition | Default | Description -:-- | :--- | :-------- | :------ | :---------- -`block.filesystem` | string | block-based volume with content type `filesystem` | same as `volume.block.filesystem` | {{block_filesystem}} -`block.mount_options` | string | block-based volume with content type `filesystem` | same as `volume.block.mount_options` | Mount options for block-backed file system volumes -`security.shifted` | bool | custom volume | same as `volume.security.shifted` or `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | same as `volume.security.unmapped` or `false` | Disable ID mapping for the volume -`size` | string | | same as `volume.size` | Size/quota of the storage volume -`snapshots.expiry` | string | custom volume | same as `volume.snapshots.expiry` | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | same as `volume.snapshots.pattern` or `snap%d` | {{snapshot_pattern_format}} [^*] -`snapshots.schedule` | string | custom volume | same as `volume.snapshots.schedule` | {{snapshot_schedule_format}} +### ストレージボリューム設定 + +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`block.filesystem` | string | | `volume.block.filesystem` と同じ | {{block_filesystem}} +`block.mount_options` | string | | `volume.block.mount_options` と同じ | block-backedなファイルシステムボリュームのマウントオプション +`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}} [^*]: {{snapshot_pattern_detail}} diff --git a/doc/reference/storage_cephfs.md b/doc/reference/storage_cephfs.md index 7c1f617cff0..ed7a89167ce 100644 --- a/doc/reference/storage_cephfs.md +++ b/doc/reference/storage_cephfs.md @@ -7,10 +7,10 @@ :end-before: ``` -{abbr}`CephFS (Ceph File System)` is Ceph's file system component that provides a robust, fully-featured POSIX-compliant distributed file system. -Internally, it maps files to Ceph objects and stores file metadata (for example, file ownership, directory paths, access permissions) in a separate data pool. +{abbr}`CephFS (Ceph File System)` は堅牢でフル機能の POSIX 互換の分散ファイルシステムを提供する Ceph のファイルシステムコンポーネントです。 +内部的には ファイルを Ceph オブジェクトにマップし、ファイルのメタデータ（たとえば、ファイルの所有権、ディレクトリーパス、アクセス権限）を別のデータプールに保管します。 -## Terminology +## 用語 % Include content from [storage_ceph.md](storage_ceph.md) ```{include} storage_ceph.md @@ -18,15 +18,15 @@ Internally, it maps files to Ceph objects and stores file metadata (for example, :end-before: ``` -A *CephFS file system* consists of two OSD storage pools, one for the actual data and one for the file metadata. +*CephFS ファイルシステム* は 2 つの OSD ストレージプールから構成され、ひとつは実際のデータ、もうひとつはファイルメタデータに使用されます。 -## `cephfs` driver in Incus +## Incus の `cephfs` ドライバー ```{note} -The `cephfs` driver can only be used for custom storage volumes with content type `filesystem`. +`cephfs` ドライバはコンテントタイプ `filesystem` のカスタムストレージボリュームにのみ使用できます。 -For other storage volumes, use the {ref}`Ceph ` driver. -That driver can also be used for custom storage volumes with content type `filesystem`, but it implements them through Ceph RBD images. +他のストレージボリュームには {ref}`Ceph ` ドライバを使用してください。 +そのドライバはコンテントタイプ `filesystem` のカスタムストレージボリュームにも使用できますが、 Ceph RBD イメージを使って実装しています。 ``` % Include content from [storage_ceph.md](storage_ceph.md) @@ -35,7 +35,7 @@ That driver can also be used for custom storage volumes with content type `files :end-before: ``` -You must create the CephFS file system that you want to use beforehand and specify it through the [`source`](storage-cephfs-pool-config) option. +使用したい CephFS ファイルシステムは事前に作成する必要があり [`source`](storage-cephfs-pool-config) オプションで指定する必要があります。 % Include content from [storage_ceph.md](storage_ceph.md) ```{include} storage_ceph.md @@ -49,35 +49,33 @@ You must create the CephFS file system that you want to use beforehand and speci :end-before: ``` -The `cephfs` driver in Incus supports snapshots if snapshots are enabled on the server side. +Incus の `cephfs` ドライバーはサーバー側でスナップショットが有効な場合はスナップショットをサポートします。 -## Configuration options +## 設定オプション -The following configuration options are available for storage pools that use the `cephfs` driver and for storage volumes in these pools. +`cephfs` ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。 (storage-cephfs-pool-config)= -### Storage pool configuration +## ストレージプール設定 -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`cephfs.cluster_name` | string | `ceph` | Name of the Ceph cluster that contains the CephFS file system -`cephfs.fscache` | bool | `false` | Enable use of kernel `fscache` and `cachefilesd` -`cephfs.path` | string | `/` | The base path for the CephFS mount -`cephfs.user.name` | string | `admin` | The Ceph user to use -`source` | string | - | Existing CephFS file system or file system path to use -`volatile.pool.pristine` | string | `true` | Whether the CephFS file system was empty on creation time +キー | 型 | デフォルト値 | 説明 +:-- | :--- | :------ | :---------- +`cephfs.cluster_name` | string | `ceph` | CephFS ファイルシステムを含む Ceph クラスタの名前 +`cephfs.fscache` | bool | `false` | カーネルの `fscache` と `cachefilesd` を使用するか +`cephfs.path` | string | `/` | CephFS をマウントするベースのパス +`cephfs.user.name` | string | `admin` | 使用する Ceph のユーザー +`source` | string | - | 使用する既存の CephFS ファイルシステムかファイルシステムパス +`volatile.pool.pristine` | string | `true` | 作成時に CephFS ファイルシステムが空だったか {{volume_configuration}} -### Storage volume configuration - -Key | Type | Condition | Default | Description -:-- | :--- | :-------- | :------ | :---------- -`security.shifted` | bool | custom volume | same as `volume.security.shifted` or `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | same as `volume.security.unmapped` or `false` | Disable ID mapping for the volume -`size` | string | appropriate driver | same as `volume.size` | Size/quota of the storage volume -`snapshots.expiry` | string | custom volume | same as `volume.snapshots.expiry` | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | same as `volume.snapshots.pattern` or `snap%d` | {{snapshot_pattern_format}} [^*] -`snapshots.schedule` | string | custom volume | same as `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}} [^*]: {{snapshot_pattern_detail}} diff --git a/doc/reference/storage_cephobject.md b/doc/reference/storage_cephobject.md index 7555b1fb6fa..c8af3cebcbb 100644 --- a/doc/reference/storage_cephobject.md +++ b/doc/reference/storage_cephobject.md @@ -7,10 +7,10 @@ :end-before: ``` -[Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/) is an object storage interface built on top of [`librados`](https://docs.ceph.com/en/latest/rados/api/librados-intro/) to provide applications with a RESTful gateway to [Ceph Storage Clusters](https://docs.ceph.com/en/latest/rados/). -It provides object storage functionality with an interface that is compatible with a large subset of the Amazon S3 RESTful API. +[Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/) は [`librados`](https://docs.ceph.com/en/latest/rados/api/librados-intro/) 上に構築されたオブジェクトストレージインターフェースであり [Ceph Storage Clusters](https://docs.ceph.com/en/latest/rados/) への RESTful ゲートウェイを持つアプリケーションを提供します。 +Amazon S3 RESTful API の大きなサブセットと互換性を持つオブジェクトストレージの機能を提供します。 -## Terminology +## 用語 % Include content from [storage_ceph.md](storage_ceph.md) ```{include} storage_ceph.md @@ -18,14 +18,14 @@ It provides object storage functionality with an interface that is compatible wi :end-before: ``` -A *Ceph Object Gateway* consists of several OSD pools and one or more *Ceph Object Gateway daemon* (`radosgw`) processes that provide object gateway functionality. +*Ceph Object Gateway* は複数の OSD プールとゲートウェイの機能を提供する 1 つ以上の *Ceph Object Gateway daemon* (`radosgw`) プロセスから構成されます。 -## `cephobject` driver in Incus +## Incus の `cephobject` ドライバー ```{note} -The `cephobject` driver can only be used for buckets. +`cephobject` ドライバはバケットのみに使用できます。 -For storage volumes, use the {ref}`Ceph ` or {ref}`CephFS ` drivers. +ストレージボリュームには {ref}`Ceph ` または {ref}`CephFS ` ドライバを使用してください。 ``` % Include content from [storage_ceph.md](storage_ceph.md) @@ -34,12 +34,11 @@ For storage volumes, use the {ref}`Ceph ` or {ref}`CephFS ``` -You must set up a `radosgw` environment beforehand and ensure that its HTTP/HTTPS endpoint URL is reachable from the Incus server or servers. -See [Manual Deployment](https://docs.ceph.com/en/latest/install/manual-deployment/) for information on how to set up a Ceph cluster and [Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/) on how to set up a `radosgw` environment. +事前に `radosgw` 環境をセットアップし、 HTTP/HTTPS エンドポイント URL が Incus サーバーからアクセス可能なことを確認してください。 +Ceph クラスタをどのようにセットアップするかの情報については [Manual Deployment](https://docs.ceph.com/en/latest/install/manual-deployment/) を、そして `radosgw` 環境をどのようにセットアップするかについては [Ceph Object Gateway](https://docs.ceph.com/en/latest/radosgw/) を参照してください。 -The `radosgw` URL can be specified at pool creation time using the [`cephobject.radosgw.endpoint`](storage-cephobject-pool-config) option. - -Incus uses the `radosgw-admin` command to manage buckets. So this command must be available and operational on the Incus servers. +`radosgw` URL はプールの作成時に [`cephobject.radosgw.endpoint`](storage-cephobject-pool-config) オプションを使って指定できます。 +また Incus はバケットの管理に `radosgw-admin` コマンドを使用しています。ですのでこのコマンドが Incus サーバー上で利用可能で操作可能である必要があります。 % Include content from [storage_ceph.md](storage_ceph.md) ```{include} storage_ceph.md @@ -53,24 +52,24 @@ Incus uses the `radosgw-admin` command to manage buckets. So this command must b :end-before: ``` -## Configuration options +## 設定オプション -The following configuration options are available for storage pools that use the `cephobject` driver and for storage buckets in these pools. +`cephobject` ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。 (storage-cephobject-pool-config)= -### Storage pool configuration - -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`cephobject.bucket.name_prefix` | string | - | Prefix to add to bucket names in Ceph -`cephobject.cluster_name` | string | `ceph` | The Ceph cluster to use -`cephobject.radosgw.endpoint` | string | - | URL of the `radosgw` gateway process -`cephobject.radosgw.endpoint_cert_file` | string | - | Path to the file containing the TLS client certificate to use for endpoint communication -`cephobject.user.name` | string | `admin` | The Ceph user to use -`volatile.pool.pristine` | string | `true` | Whether the `radosgw` `incus-admin` user existed at creation time - -### Storage bucket configuration - -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`size` | string | - | Quota of the storage bucket +### ストレージプール設定 + +キー | 型 | デフォルト値 | 説明 +:-- | :--- | :------ | :---------- +`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 875dcb87920..390bc98ed87 100644 --- a/doc/reference/storage_dir.md +++ b/doc/reference/storage_dir.md @@ -1,54 +1,54 @@ (storage-dir)= -# Directory - `dir` +# ディレクトリー - `dir` -The directory storage driver is a basic backend that stores its data in a standard file and directory structure. -This driver is quick to set up and allows inspecting the files directly on the disk, which can be convenient for testing. -However, Incus operations are {ref}`not optimized ` for this driver. +ディレクトリーストレージドライバーは基本的なバックエンドで通常のファイルとディレクトリー構造にデータを保管します。 +このドライバーは素早くセットアップできディスク上のファイルを直接見ることができるので、テストには便利かもしれません。 +しかし、 Incus の操作はこのドライバー用には {ref}`最適化されていません `。 -## `dir` driver in Incus +## Incus の `dir` ドライバー -The `dir` driver in Incus is fully functional and provides the same set of features as other drivers. -However, it is much slower than all the other drivers because it must unpack images and do instant copies of instances, snapshots and images. +Incus の `dir` ドライバーは完全に機能し、他のドライバーと同じ機能セットを提供します。 +しかし、他のドライバーよりは圧倒的に遅いです。これはインスタンス、スナップ、ショットを一瞬でコピーする代わりにイメージの解凍を行う必要があるためです。 -Unless specified differently during creation (with the `source` configuration option), the data is stored in the `/var/lib/incus/storage-pools/` directory. +作成時に（`source` 設定オプションを使って）別途指定されてない限り、データは `/var/lib/incus/storage-pools/` ディレクトリーに保管されます。 (storage-dir-quotas)= -### Quotas +### クォータ -The `dir` driver supports storage quotas when running on either ext4 or XFS with project quotas enabled at the file system level. +`dir` ドライバーは ext4 か XFS 上で動作しファイルシステムレベルでプロジェクトのクォータが有効な場合にストレージのクォータをサポートします。 -## Configuration options +## 設定オプション -The following configuration options are available for storage pools that use the `dir` driver and for storage volumes in these pools. +`dir` ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。 -### Storage pool configuration +## ストレージプール設定 -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`rsync.bwlimit` | string | `0` (no limit) | The upper limit to be placed on the socket I/O when `rsync` must be used to transfer storage entities -`rsync.compression` | bool | `true` | Whether to use compression while migrating storage pools -`source` | string | - | Path to an existing directory +キー | 型 | デフォルト値 | 説明 +:-- | :--- | :------ | :---------- +`rsync.bwlimit` | string | `0` (no limit) | ストレージエンティティの転送に rsync を使う必要があるときにソケット I/O に指定する上限を設定 +`rsync.compression` | bool | `true` | ストレージブールのマイグレーションの際に圧縮を使うかどうか +`source` | string | - | ブロックデバイスかループファイルかファイルシステムエントリのパス {{volume_configuration}} -### Storage volume configuration +## ストレージボリューム設定 -Key | Type | Condition | Default | Description -:-- | :--- | :-------- | :------ | :---------- -`security.shifted` | bool | custom volume | same as `volume.security.shifted` or `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | same as `volume.security.unmapped` or `false` | Disable ID mapping for the volume -`size` | string | appropriate driver | same as `volume.size` | Size/quota of the storage volume -`snapshots.expiry` | string | custom volume | same as `volume.snapshots.expiry` | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | same as `volume.snapshots.pattern` or `snap%d` | {{snapshot_pattern_format}} [^*] -`snapshots.schedule` | string | custom volume | same as `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}} [^*]: {{snapshot_pattern_detail}} -### Storage bucket configuration +### ストレージバケット設定 -To enable storage buckets for local storage pool drivers and allow applications to access the buckets via the S3 protocol, you must configure the {config:option}`server-core:core.storage_buckets_address` server setting. +ローカルのストレージプールドライバーでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには{config:option}`server-core:core.storage_buckets_address`サーバー設定を調整する必要があります。 -Storage buckets do not have any configuration for `dir` pools. -Unlike the other storage pool drivers, the `dir` driver does not support bucket quotas via the `size` setting. +ストレージバケットは `dir` プール用の設定はありません。 +他のストレージプールドライバーとは異なり、 `dir` ドライバーは `size` 設定によるバケットクォータのサポートはありません。 diff --git a/doc/reference/storage_drivers.md b/doc/reference/storage_drivers.md index d0890d6d62d..e17536b7a96 100644 --- a/doc/reference/storage_drivers.md +++ b/doc/reference/storage_drivers.md @@ -1,7 +1,7 @@ (storage-drivers)= -# Storage drivers +# ストレージドライバー -Incus supports the following storage drivers for storing images, instances and custom volumes: +Incus はイメージ、インスタンスとカスタムボリュームを保管するのに以下のストレージドライバーをサポートします: ```{toctree} :maxdepth: 1 @@ -15,30 +15,31 @@ storage_cephfs storage_cephobject ``` -See the corresponding pages for driver-specific information and configuration options. + +ドライバー固有の情報と設定オプションについては対応するページを参照してください。 (storage-drivers-features)= -## Feature comparison - -Where possible, Incus uses the advanced features of each storage system to optimize operations. - -Feature | Directory | Btrfs | LVM | ZFS | Ceph RBD | CephFS | Ceph Object -:--- | :--- | :--- | :--- | :--- | :--- | :--- | :--- -{ref}`storage-optimized-image-storage` | no | yes | yes | yes | yes | n/a | n/a -Optimized instance creation | no | yes | yes | yes | yes | n/a | n/a -Optimized snapshot creation | no | yes | yes | yes | yes | yes | n/a -Optimized image transfer | no | yes | no | yes | yes | n/a | n/a -{ref}`storage-optimized-volume-transfer` | no | yes | no | yes | yes | n/a | n/a -Copy on write | no | yes | yes | yes | yes | yes | n/a -Block based | no | no | yes | no | yes | no | n/a -Instant cloning | no | yes | yes | yes | yes | yes | n/a -Storage driver usable inside a container | yes | yes | no | yes[^1] | no | n/a | n/a -Restore from older snapshots (not latest) | yes | yes | yes | no | yes | yes | n/a -Storage quotas | yes[^2] | yes | yes | yes | yes | yes | yes -Available on `incus admin init` | yes | yes | yes | yes | yes | no | no -Object storage | yes | yes | yes | yes | no | no | yes - -[^1]: Requires [`zfs.delegate`](storage-zfs-vol-config) to be enabled. +## 機能比較 + +可能であれば、各システムの高度な機能を使って、Incus は操作を最適化しようとします。 + +機能 | ディレクトリー | 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-volume-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 | yes[^1] | no | n/a | n/a +古い（最新ではない）スナップショットからのリストア | yes | yes | yes | no | yes | yes | n/a +ストレージクオータ | yes[^2] | yes | yes | yes | yes | yes | yes +`incus admin init` で利用可能 | yes | yes | yes | yes | yes | no | no +オブジェクトストレージ | yes | yes | yes | yes | no | no | yes + +[^1]: [`zfs.delegate`](storage-zfs-vol-config)を有効にする必要があります。 [^2]: % Include content from [storage_dir.md](storage_dir.md) ```{include} storage_dir.md @@ -47,54 +48,52 @@ Object storage | yes | yes | yes | yes ``` (storage-optimized-image-storage)= -### Optimized image storage +### 最適化されたイメージストレージ -All storage drivers except for the directory driver have some kind of optimized image storage format. -To make instance creation near instantaneous, Incus clones a pre-made image volume when creating an instance rather than unpacking the image tarball from scratch. +ディレクトリードライバーを除くすべてのストレージドライバーはなんらかの種類の最適化されたイメージ保管フォーマットがあります。 +インスタンスの作成をほぼ瞬時に行うため、 Incus はインスタンスの作成時にイメージの tarball を一から展開するのではなく事前に作成したイメージボリュームを複製します。 -To prevent preparing such a volume on a storage pool that might never be used with that image, the volume is generated on demand. -Therefore, the first instance takes longer to create than subsequent ones. +全く使われないかもしれないイメージのためにストレージプール上にそのようなボリュームを準備するのを避けるため、ボリュームはオンデマンドで生成されます。 +このため、最初のインスタンスの作成は後続のインスタンスより時間がかかります。 (storage-optimized-volume-transfer)= -### Optimized volume transfer +### 最適化されたボリュームの転送 -Btrfs, ZFS and Ceph RBD have an internal send/receive mechanism that allows for optimized volume transfer. +Btrfs, ZFS と Ceph RBD は内部で送信/受信の機構を持ち最適化されたボリューム転送を行えます。 -Incus uses this optimized transfer when transferring instances and snapshots between storage pools that use the same storage driver, if the storage driver supports optimized transfer and the optimized transfer is actually quicker. -Otherwise, Incus uses `rsync` to transfer container and file system volumes, or raw block transfer to transfer virtual machine and custom block volumes. +同じストレージドライバーを使うストレージプール間でボリュームを転送する場合、ストレージドライバーが最適化された転送をサポートしている場合は、Incus はこの最適化された転送を使用し、最適化された転送のほうが速いです。 +そうでない場合は、Incus はコンテナとファイルシステムボリュームを転送するのに`rsync`を使用するか、仮想マシンとカスタムボリュームブロックを転送するのに raw ブロック転送を使います。 -The optimized transfer uses the underlying storage driver's native functionality for transferring data, which is usually faster than using `rsync`. -However, the full potential of the optimized transfer becomes apparent when refreshing a copy of an instance or custom volume that uses periodic snapshots. -With optimized transfer, Incus bases the refresh on the latest snapshot, which means: +最適化された転送は下層のストレージドライバーのデータ転送のネイティブの機能を使い、`rsync`を使うより通常は速いです。 +しかし、最適化された転送のフルのポテンシャルが明らかになるのは、インスタンスや定期的なスナップショットを使用するカスタムボリュームのコピーを更新するときです。つまり: -- When you take a first snapshot and refresh the copy, the transfer will take roughly the same time as a full copy. - Incus transfers the new snapshot and the difference between the snapshot and the main volume. -- For subsequent snapshots, the transfer is considerably faster. - Incus does not transfer the full new snapshot, but only the difference between the new snapshot and the latest snapshot that already exists on the target. -- When refreshing without a new snapshot, Incus transfers only the differences between the main volume and the latest snapshot on the target. - This transfer is usually faster than using `rsync` (as long as the latest snapshot is not too outdated). +- 初回のスナップショットを作成しコピーを更新する際、転送はほぼフルコピーと同じ時間がかかります。 + Incus は新しいスナップショットとスナップショットとメインボリュームの差分を転送します。 +- 後続のスナップショットでは、転送は大幅に速くなります。 + Incus はフルの新規のスナップショットは転送せず、新規のスナップショットとターゲット上に存在する最新のスナップショットとの差分のみを転送します。 +- 新規のスナップショット無しで更新する場合、Incus はメインボリュームとターゲット上に存在する最新のスナップショットとの差分のみを転送します。 + この転送は`rsync`を使うより通常は速いです（最新のスナップショットがあまりにも古すぎない限りは）。 -On the other hand, refreshing copies of instances without snapshots (either because the instance doesn't have any snapshots or because the refresh uses the `--instance-only` flag) would actually be slower than using `rsync`. -In such cases, the optimized transfer would transfer the difference between the (non-existent) latest snapshot and the main volume, thus the full volume. -Therefore, Incus uses `rsync` instead of the optimized transfer for refreshes without snapshots. +一方で、スナップショットなしのインスタンスのコピーを更新する際は`rsync`を使うよりも（インスタンスがスナップショットを 1 つも持っていないか、リフレッシュが`--instance-only`フラグを使うことのために）遅くなるでしょう。そのような場合には最適化された転送であれば（存在しない）最新のスナップショットとメインボリュームの差分、つまりフルのボリュームを転送したでしょう。 +ですので、Incus はスナップショットがないリフレッシュには最適化された転送ではなく`rsync`を使用します。 -## Recommended setup +## おすすめのセットアップ -The two best options for use with Incus are ZFS and Btrfs. -They have similar functionalities, but ZFS is more reliable. +Incus で使う場合のベストな 2 つのオプションは ZFS と Btrfs です。 +このふたつは同様の機能を持ちますが、ZFS のほうがより信頼性が上です。 -Whenever possible, you should dedicate a full disk or partition to your Incus storage pool. -Incus allows to create loop-based storage, but this isn't recommended for production use. -See {ref}`storage-location` for more information. +可能であれば、Incus のストレージプールにディスク全体かパーティションを専用で使用させるべきです。 +Incus で loop ベースのストレージを作れますが、プロダクション環境ではおすすめしません。 +詳細は {ref}`storage-location` を参照してください。 -The directory backend should be considered as a last resort option. -It supports all main Incus features, but is slow and inefficient because it cannot perform instant copies or snapshots. -Therefore, it constantly copies the instance's full storage. +ディレクトリーバックエンドは最後の手段の選択肢と捉えるべきです。 +Incus のすべてのメインの機能をサポートしますが、インスタントコピーやスナップショットを実行できないため遅く非効率です。 +そのため、絶えずインスタンスのストレージ全体をコピーすることになります。 -## Security considerations +## セキュリティーの考慮 -Currently, the Linux kernel might silently ignore mount options and not apply them when a block-based file system (for example, `ext4`) is already mounted with different mount options. -This means when dedicated disk devices are shared between different storage pools with different mount options set, the second mount might not have the expected mount options. -This becomes security relevant when, for example, one storage pool is supposed to provide `acl` support and the second one is supposed to not provide `acl` support. +現在、 Linux Kernel はブロックベースのファイルシステム（例: `ext4`）が別のオプションでマウント済みの場合マウントオプションは黙って無視し適用しません。 +これは専用ディスクデバイスが異なるストレージプール間で異なるマウントオプションで共有されている時、2 つめのマウントは期待しているマウントオプションにならないかもしれないことを意味します。 +これはたとえば 1 つめのストレージプールが `acl` サポートを提供する想定で、2 つめのストレージプールが `acl` サポートを提供しない想定であるようなときにセキュリティー上の問題になります。 -For this reason, it is currently recommended to either have dedicated disk devices per storage pool or to ensure that all storage pools that share the same dedicated disk device use the same mount options. +この理由により、現状はストレージプールごとに専用のディスクデバイスを持つか、同じ専用ディスクを共有するすべてのストレージプールで確実に同じマウントオプションを使うことを推奨します。 diff --git a/doc/reference/storage_lvm.md b/doc/reference/storage_lvm.md index b2c61ad4f87..a34d315ad5a 100644 --- a/doc/reference/storage_lvm.md +++ b/doc/reference/storage_lvm.md @@ -1,83 +1,80 @@ (storage-lvm)= # LVM - `lvm` -{abbr}`LVM (Logical Volume Manager)` is a storage management framework rather than a file system. -It is used to manage physical storage devices, allowing you to create a number of logical storage volumes that use and virtualize the underlying physical storage devices. +{abbr}`LVM (Logical Volume Manager)` はファイルシステムというよりストレージマネージメントフレームワークです。 +これは物理ストレージデバイスを管理するのに使用され、複数のストレージボリュームを作成し、配下の物理ストレージデバイスを使用し仮想化できるようにします。 -Note that it is possible to over-commit the physical storage in the process, to allow flexibility for scenarios where not all available storage is in use at the same time. +この過程で物理ストレージをオーバーコミットすることが可能で、すべての利用可能なストレージが同時に使用されるわけではないシナリオに対して柔軟性を提供できることに注意してください。 -To use LVM, make sure you have `lvm2` installed on your machine. +LVM を使用するにはマシン上に `lvm2` がインストールされていることを確認してください。 -## Terminology -LVM can combine several physical storage devices into a *volume group*. -You can then allocate *logical volumes* of different types from this volume group. +LVM は複数の物理ストレージデバイスを組み合わせて *ボリュームグループ* にすることができます。 +その後このボリュームグループから異なるタイプの *論理ボリューム* を割り当てることができます。 -One supported volume type is a *thin pool*, which allows over-committing the resources by creating thinly provisioned volumes whose total allowed maximum size is larger than the available physical storage. -Another type is a *volume snapshot*, which captures a specific state of a logical volume. +サポートされるボリュームタイプの 1 つに *thin pool* があります。これは許可された最大サイズの合計は利用可能な物理ストレージより大きいような薄くプロビジョンされたボリュームを作成することでリソースをオーバーコミットすることを可能にします。 +別のタイプは *ボリュームスナップショット* でこれは論理ボリュームの特定の状態をキャプチャーします。 -## `lvm` driver in Incus +## Incus の `lvm` ドライバー -The `lvm` driver in Incus uses logical volumes for images, and volume snapshots for instances and snapshots. +Incus の `lvm` ドライバーはイメージに論理ボリュームを、インスタンスとスナップショットにボリュームスナップショットを使用します。 -Incus assumes that it has full control over the volume group. -Therefore, you should not maintain any file system entities that are not owned by Incus in an LVM volume group, because Incus might delete them. -However, if you need to reuse an existing volume group (for example, because your setup has only one volume group), you can do so by setting the [`lvm.vg.force_reuse`](storage-lvm-pool-config) configuration. +Incus はボリュームグループを完全制御できると想定しています。 +このため、 Incus が所有しないファイルシステムエンティティは Incus が消してしまうかもしれないので、LVM ボリュームグループ内に置くべきではありません。 +しかし、既存のボリュームグループを再利用する必要がある場合（たとえば、あなたの環境ではボリュームグループが 1 つしかない場合）、[`lvm.vg.force_reuse`](storage-lvm-pool-config) を設定することでこれは可能です。 -By default, LVM storage pools use an LVM thin pool and create logical volumes for all Incus storage entities (images, instances and custom volumes) in there. -This behavior can be changed by setting [`lvm.use_thinpool`](storage-lvm-pool-config) to `false` when you create the pool. -In this case, Incus uses "normal" logical volumes for all storage entities that are not snapshots. -Note that this entails serious performance and space reductions for the `lvm` driver (close to the `dir` driver both in speed and storage usage). -The reason for this is that most storage operations must fall back to using `rsync`, because logical volumes that are not thin pools do not support snapshots of snapshots. -In addition, non-thin snapshots take up much more storage space than thin snapshots, because they must reserve space for their maximum size at creation time. -Therefore, this option should only be chosen if the use case requires it. +デフォルトでは LVM ストレージプールは LVM thin pool を使用しその中にすべての Incus ストレージエンティティ（イメージ、インスタンス、カスタムボリューム）の論理ボリュームを作成します。 +この挙動はプール作成時に [`lvm.use_thinpool`](storage-lvm-pool-config) を `false` に設定することで変更できます。 +この場合、Incus はスナップショットでないすべてのストレージエンティティに "通常の" 論理ボリュームを使用します。 +これは深刻なパフォーマンスの低下とディスクの空き容量の低下を `lvm` ドライバーに必然的にもたらすことに注意してください（スピードとストレージ使用量の両面で `dir` ドライバーに近くなります）。 +この理由は thin pool でない論理ボリュームがスナップショットのスナップショットをサポートしないため、ほとんどのストレージ操作が `rsync` の使用にフォールバックするためです。 +さらに、 thin でないスナップショットは作成時に最大のサイズのストレージを予約しなければならないため、 thin スナップショットよりもはるかに大容量のストレージを使用するからです。 +このため、このオプションはどうしても必要なユースケースの場合にのみ選択すべきです。 -For environments with a high instance turnover (for example, continuous integration) you should tweak the backup `retain_min` and `retain_days` settings in `/etc/lvm/lvm.conf` to avoid slowdowns when interacting with Incus. +インスタンスの入れ替わりが激しい環境（たとえば、継続的インテグレーション）では、Incus の操作が遅くなるのを回避するため `/etc/lvm/lvm.conf` 内のバックアップの `retain_min` と `retain_days` 設定を調整すべきです。 -## Configuration options +## 設定オプション -The following configuration options are available for storage pools that use the `lvm` driver and for storage volumes in these pools. +`lvm` ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。 (storage-lvm-pool-config)= -### Storage pool configuration - -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`lvm.thinpool_name` | string | `IncusThinPool` | Thin pool where volumes are created -`lvm.thinpool_metadata_size` | string | `0` (auto) | The size of the thin pool metadata volume (the default is to let LVM calculate an appropriate size) -`lvm.use_thinpool` | bool | `true` | Whether the storage pool uses a thin pool for logical volumes -`lvm.vg.force_reuse` | bool | `false` | Force using an existing non-empty volume group -`lvm.vg_name` | string | name of the pool | Name of the volume group to create -`rsync.bwlimit` | string | `0` (no limit) | The upper limit to be placed on the socket I/O when `rsync` must be used to transfer storage entities -`rsync.compression` | bool | `true` | Whether to use compression while migrating storage pools -`size` | string | auto (20% of free disk space, >= 5 GiB and <= 30 GiB) | Size of the storage pool when creating loop-based pools (in bytes, suffixes supported, can be increased to grow storage pool) -`source` | string | - | Path to an existing block device, loop file or LVM volume group -`source.wipe` | bool | `false` | Wipe the block device specified in `source` prior to creating the storage pool +## ストレージプール設定 + +キー | 型 | デフォルト値 | 説明 +:-- | :--- | :------ | :---------- +`lvm.thinpool_name` | string | `LXDThinPool` | ボリュームが作成される thin pool +`lvm.thinpool_metadata_size` | string | `0`（auto） | thin pool メタデータボリュームのサイズ（デフォルトは LVM が適切なサイズを計算） +`lvm.use_thinpool` | bool | `true` | ストレージプールは論理ボリュームに thin pool を使うかどうか +`lvm.vg.force_reuse` | bool | `false` | 既存の空でないボリュームグループの使用を強制 +`lvm.vg_name` | string | プールの名前 | 作成するボリュームグループ名 +`rsync.bwlimit` | string | `0`（no limit） | ストレージエンティティーの転送に`rsync`を使う場合、ソケットI/Oに設定する上限を指定 +`rsync.compression` | bool | `true` | ストレージプールをマイグレートする際に圧縮を使用するかどうか +`size` | string | 自動（空きディスクスペースの 20%, >= 5 GiB and <= 30 GiB） | ループベースのプールを作成する際のストレージプールのサイズ (バイト単位、接尾辞のサポートあり、増やすとストレージプールのサイズを拡大) +`source` | string | - | 既存のブロックデバイスかループファイルかLVMボリュームグループのパス +`source.wipe` | bool | `false` | ストレージプールを作成する前に`source`で指定されたブロックデバイスの中身を消去する {{volume_configuration}} (storage-lvm-vol-config)= -### Storage volume configuration - -Key | Type | Condition | Default | Description -:-- | :--- | :------ | :------ | :---------- -`block.filesystem` | string | block-based volume with content type `filesystem` | same as `volume.block.filesystem` | {{block_filesystem}} -`block.mount_options` | string | block-based volume with content type `filesystem` | same as `volume.block.mount_options` | Mount options for block-backed file system volumes -`lvm.stripes` | string | | same as `volume.lvm.stripes` | Number of stripes to use for new volumes (or thin pool volume) -`lvm.stripes.size` | string | | same as `volume.lvm.stripes.size` | Size of stripes to use (at least 4096 bytes and multiple of 512 bytes) -`security.shifted` | bool | custom volume | same as `volume.security.shifted` or `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | same as `volume.security.unmapped` or `false` | Disable ID mapping for the volume -`size` | string | | same as `volume.size` | Size/quota of the storage volume -`snapshots.expiry` | string | custom volume | same as `volume.snapshots.expiry` | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | same as `volume.snapshots.pattern` or `snap%d` | {{snapshot_pattern_format}} [^*] -`snapshots.schedule` | string | custom volume | same as `volume.snapshots.schedule` | {{snapshot_schedule_format}} +## ストレージボリューム設定 + +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`block.filesystem` | string | | `volume.block.filesystem` と同じ | {{block_filesystem}} +`block.mount_options` | string | | `volume.block.mount_options` と同じ | block-backedなファイルシステムボリュームのマウントオプション +`lvm.stripes` | string | | `volume.lvm.stripes` と同じ | 新しいボリューム（あるいは thin pool ボリューム）に使用するストライプ数 +`lvm.stripes.size` | string | | `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}} [^*]: {{snapshot_pattern_detail}} -### Storage bucket configuration +ローカルのストレージプールドライバーでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには{config:option}`server-core:core.storage_buckets_address`サーバー設定を調整する必要があります。 -To enable storage buckets for local storage pool drivers and allow applications to access the buckets via the S3 protocol, you must configure the {config:option}`server-core:core.storage_buckets_address` server setting. - -Key | Type | Condition | Default | Description -:-- | :--- | :-------- | :------ | :---------- -`size` | string | appropriate driver | same as `volume.size` | Size/quota of the storage bucket +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`size` | string | 適切なドライバー | `volume.size` と同じ | ストレージバケットのサイズ/クォータ diff --git a/doc/reference/storage_zfs.md b/doc/reference/storage_zfs.md index 2fa75cabb80..54efa639a83 100644 --- a/doc/reference/storage_zfs.md +++ b/doc/reference/storage_zfs.md @@ -1,133 +1,136 @@ (storage-zfs)= # ZFS - `zfs` -{abbr}`ZFS (Zettabyte file system)` combines both physical volume management and a file system. -A ZFS installation can span across a series of storage devices and is very scalable, allowing you to add disks to expand the available space in the storage pool immediately. +{abbr}`ZFS (Zettabyte file system)` は物理ボリューム管理とファイルシステムを兼ね備えています。 +ZFS のインストールは一連のストレージデバイスに広がることができ非常にスケーラブルで、ディスクを追加してストレージプールの空き容量を即座に拡大できます。 -ZFS is a block-based file system that protects against data corruption by using checksums to verify, confirm and correct every operation. -To run at a sufficient speed, this mechanism requires a powerful environment with a lot of RAM. +ZFS はブロックベースのファイルシステムで、あらゆる操作を検証、確認、訂正するのにチェックサムを使用することでデータ破壊から守ります。 +十分な速度で動作するためには、この機構には強力な環境と大量の RAM が必要です。 -In addition, ZFS offers snapshots and replication, RAID management, copy-on-write clones, compression and other features. +さらに、 ZFS はスナップショット、レプリケーション、RAID 管理、コピー・オン・ライトのクローン、圧縮、その他の機能を提供します。 -To use ZFS, make sure you have `zfsutils-linux` installed on your machine. +ZFS を使用するにはマシンに `zfsutils-linux` をインストールしていることを確認してください。 -## Terminology +## 用語 -ZFS creates logical units based on physical storage devices. -These logical units are called *ZFS pools* or *zpools*. -Each zpool is then divided into a number of *{spellexception}`datasets`*. -These {spellexception}`datasets` can be of different types: +ZFS は物理ストレージデバイスに基づいた論理ユニットを作成します。 +これらの論理ユニットは *ZFS pools* または *zpools* と呼ばれます。 +さらにそれぞれの zpool は複数の *`データセット`* に分割されます。 +これらの`データセット`は以下の異なるタイプがあります。 -- A *{spellexception}`ZFS filesystem`* can be seen as a partition or a mounted file system. -- A *ZFS volume* represents a block device. -- A *ZFS snapshot* captures a specific state of either a {spellexception}`ZFS filesystem` or a ZFS volume. - ZFS snapshots are read-only. -- A *ZFS clone* is a writable copy of a ZFS snapshot. +- *ZFS ファイルシステム* はパーティションまたはマウントされたファイルシステムとして扱えます。 +- *ZFS ボリューム* はブロックデバイスを表します。 +- *ZFS スナップショット* は ZFS ファイルシステムまたは ZFS ボリュームの特定の状態をキャプチャーします。 + ZFS スナップショットは読み取り専用です。 +- *ZFS クローン* は ZFS スナップショットの書き込み可能なコピーです。 -## `zfs` driver in Incus +## Incus の `zfs` ドライバー -The `zfs` driver in Incus uses {spellexception}`ZFS filesystems` and ZFS volumes for images and custom storage volumes, and ZFS snapshots and clones to create instances from images and for instance and custom volume snapshots. -By default, Incus enables compression when creating a ZFS pool. +Incus の `zfs` ドライバーは `ZFS ファイルシステム`と ZFS ボリュームをイメージとカスタムストレージボリュームに使用し、ZFS スナップショットとクローンをイメージからのインスタンス作成とインスタンスとカスタムボリュームスナップショットに使用します。 +デフォルトでは Incus は ZFS プール作成時に圧縮を有効にします。 -Incus assumes that it has full control over the ZFS pool and {spellexception}`dataset`. -Therefore, you should never maintain any {spellexception}`datasets` or file system entities that are not owned by Incus in a ZFS pool or {spellexception}`dataset`, because Incus might delete them. +Incus は ZFS プールと`データセット`を完全制御できると想定します。 +このため、ZFS プールまたは`データセット`内に、Incus が所有しないファイルシステムエンティティは、決して置くべきではありません。Incus が消してしまうかもしれないからです。 -Due to the way copy-on-write works in ZFS, parent {spellexception}`ZFS filesystems` can't be removed until all children are gone. -As a result, Incus automatically renames any objects that are removed but still referenced. -Such objects are kept at a random `deleted/` path until all references are gone and the object can safely be removed. -Note that this method might have ramifications for restoring snapshots. -See {ref}`storage-zfs-limitations` below. +ZFS のコピー・オン・ライトが動作する仕組みのため、親の ZFS ファイルシステムはすべての子供がいなくなるまで削除できません。 +その結果、Incus は削除されたがまだ参照されているすべてのオブジェクトを自動的にリネームします。 +それらのオブジェクトはすべての参照がいなくなりオブジェクトが安全に削除できるようになるまでランダムな `deleted/` パスに保管されます。 +この方法はスナップショットの復元に予期しない結果をもたらすかもしれないことに注意してください。 +下記の {ref}`storage-zfs-limitations` を参照してください。 -Incus automatically enables trimming support on all newly created pools on ZFS 0.8 or later. -This increases the lifetime of SSDs by allowing better block re-use by the controller, and it also allows to free space on the root file system when using a loop-backed ZFS pool. -If you are running a ZFS version earlier than 0.8 and want to enable trimming, upgrade to at least version 0.8. -Then use the following commands to make sure that trimming is automatically enabled for the ZFS pool in the future and trim all currently unused space: +ZFS 0.8 以降の上で新しく作成されたすべてのプールで Incus はトリミングサポートを自動的に有効化します。 +これはコントローラーによるより良いブロックの再利用を可能にすることで SSD の寿命を伸ばし、ループバックの ZFS プールを使用する際にはルートファイルシステム上の容量を解放できるようにもします。 +ZFS の 0.8 より前のバージョンを稼働していてトリミングを有効にしたい場合は、少なくともバージョン 0.8 にアップグレードしてください。 +そして以下のコマンドを実行し、今後作成されるプールにトリミングが自動的に有効化され、現在未使用のスペースのすべてがトリムされることを確認してください: zpool upgrade ZPOOL-NAME zpool set autotrim=on ZPOOL-NAME zpool trim ZPOOL-NAME (storage-zfs-limitations)= -### Limitations +### 制限 -The `zfs` driver has the following limitations: +`zfs` ドライバーには以下の制限があります。 -Restoring from older snapshots -: ZFS doesn't support restoring from snapshots other than the latest one. - You can, however, create new instances from older snapshots. - This method makes it possible to confirm whether a specific snapshot contains what you need. - After determining the correct snapshot, you can {ref}`remove the newer snapshots ` so that the snapshot you need is the latest one and you can restore it. +プールの一部を委譲する +: ZFS はプールの一部をコンテナユーザーに委譲することをサポートしていません。 + ZFS のアップストリームではこの機能を提供すべくアクティブに作業中です。 - Alternatively, you can configure Incus to automatically discard the newer snapshots during restore. - To do so, set the [`zfs.remove_snapshots`](storage-zfs-vol-config) configuration for the volume (or the corresponding `volume.zfs.remove_snapshots` configuration on the storage pool for all volumes in the pool). +古いスナップショットからの復元 +: ZFS は最新ではないスナップショットからの復元をサポートしていません。 + ですが、古いスナップショットから新しいインスタンスを作成することはできます。 + この方法は特定のスナップショットが必要なものを含んでいるかを確認することを可能にします。 + 正しいスナップショットを決定したら {ref}`指定より新しいスナップショットを削除 ` して必要なスナップショットが最新になるようにして復元できるようにします。 - Note, however, that if [`zfs.clone_copy`](storage-zfs-pool-config) is set to `true`, instance copies use ZFS snapshots too. - In that case, you cannot restore an instance to a snapshot taken before the last copy without having to also delete all its descendants. - If this is not an option, you can copy the wanted snapshot into a new instance and then delete the old instance. - You will, however, lose any other snapshots the instance might have had. + 別の方法として、復元中により新しいスナップショットを自動的に破棄するように Incus を設定することもできます。 + そのためにはボリュームの [`zfs.remove_snapshots`](storage-zfs-vol-config)（あるいはプール内のすべてのボリュームのストレージプールの対応する `volume.zfs.remove_snapshots` 設定）を設定します。 -Observing I/O quotas -: I/O quotas are unlikely to affect {spellexception}`ZFS filesystems` very much. - That's because ZFS is a port of a Solaris module (using SPL) and not a native Linux file system using the Linux VFS API, which is where I/O limits are applied. + しかし、 [`zfs.clone_copy`](storage-zfs-pool-config) が `true` に設定される場合は、インスタンスのコピーは ZFS のスナップショットも使用することに注意してください。 + この場合は、スナップショットのすべての子孫を削除すること無しに、インスタンスを最後のコピーの前に取られたスナップショットに復元できません。 + この選択肢が選べない場合、欲しいスナップショットを新しいインスタンスにコピーしてから古いインスタンスを削除することはできます。 + しかし、インスタンスが持っていたであろう他のすべてのスナップショットは失うことになります。 -Feature support in ZFS -: Some features, like the use of idmaps or delegation of a ZFS dataset, require ZFS 2.2 or higher and are therefore not widely available yet. +I/O クォータを観測する +: I/O クォータは ZFS ファイルシステムに大きな影響は与えません。 + これは ZFS は (SPL を使用した) Solaris モジュールの移植でありネイティブな Linux ファイルシステムではないためで、 I/O の制限はネイティブ Linux ファイルシステムに適用されるからです。 -### Quotas +### クォータ -ZFS provides two different quota properties: `quota` and `refquota`. -`quota` restricts the total size of a {spellexception}`dataset`, including its snapshots and clones. -`refquota` restricts only the size of the data in the {spellexception}`dataset`, not its snapshots and clones. +ZFS は `quota` と `refquota` という 2 種類の異なるクォータのプロパティを提供します。 +`quota` はスナップショットとクローンを含むデータセットの合計サイズを制限します。 +`refquota` はスナップショットとクローンは含まずデータセット内のデータのサイズだけを制限します。 -By default, Incus uses the `quota` property when you set up a quota for your storage volume. -If you want to use the `refquota` property instead, set the [`zfs.use_refquota`](storage-zfs-vol-config) configuration for the volume (or the corresponding `volume.zfs.use_refquota` configuration on the storage pool for all volumes in the pool). +デフォルトでは、ストレージボリュームにクォータを設定する際は Incus は `quota` プロパティを使用します。 +代わりに `refquota` プロパティを使用したい場合はボリュームの [`zfs.use_refquota`](storage-zfs-vol-config) 設定（あるいはプール内のすべてのボリュームのストレージプールの対応する `volume.zfs.use_refquota` 設定）を設定します。 -You can also set the [`zfs.use_reserve_space`](storage-zfs-vol-config) (or `volume.zfs.use_reserve_space`) configuration to use ZFS `reservation` or `refreservation` along with `quota` or `refquota`. +また [`zfs.use_reserve_space`](storage-zfs-vol-config) (または `volume.zfs.use_reserve_space`) 設定を to use ZFS の `reservation` または `refreservation` を `quota` または `refquota` と使用するために設定することもできます。 -## Configuration options +## 設定オプション -The following configuration options are available for storage pools that use the `zfs` driver and for storage volumes in these pools. +`zfs` ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。 (storage-zfs-pool-config)= -### Storage pool configuration +## ストレージプール設定 -Key | Type | Default | Description -:-- | :--- | :------ | :---------- -`size` | string | auto (20% of free disk space, >= 5 GiB and <= 30 GiB) | Size of the storage pool when creating loop-based pools (in bytes, suffixes supported, can be increased to grow storage pool) -`source` | string | - | Path to an existing block device, loop file or ZFS dataset/pool -`source.wipe` | bool | `false` | Wipe the block device specified in `source` prior to creating the storage pool -`zfs.clone_copy` | string | `true` | Whether to use ZFS lightweight clones rather than full {spellexception}`dataset` copies (Boolean), or `rebase` to copy based on the initial image -`zfs.export` | bool | `true` | Disable zpool export while unmount performed -`zfs.pool_name` | string | name of the pool | Name of the zpool +キー | 型 | デフォルト値 | 説明 +:-- | :--- | :------ | :---------- +`size` | string | 自動（空きディスクスペースの 20%, >= 5 GiB and <= 30 GiB） | ループベースのプールを作成する際のストレージプールのサイズ（バイト単位、接尾辞のサポートあり、増やすとストレージプールのサイズを拡大） +`source` | string | - | 既存のブロックデバイスかループファイルか ZFS データセット/プールのパス +`source.wipe` | bool | `false` | ストレージプールを作成する前に`source`で指定されたブロックデバイスの中身を消去する +`zfs.clone_copy` | string | `true` | Boolean の文字列を指定した場合は ZFS のフル `データセット`コピーの代わりに軽量なクローンを使うかどうかを制御し、 `rebase` という文字列を指定した場合は初期イメージをベースにコピーします。 +`zfs.export` | bool | `true` | アンマウントの実行中にzpoolのエクスポートを無効にする +`zfs.pool_name` | string | プールの名前 | zpool 名 {{volume_configuration}} (storage-zfs-vol-config)= -### Storage volume configuration - -Key | Type | Condition | Default | Description -:-- | :--- | :-------- | :------ | :---------- -`block.filesystem` | string | block-based volume with content type `filesystem` (`zfs.block_mode` enabled) | same as `volume.block.filesystem` | {{block_filesystem}} -`block.mount_options` | string | block-based volume with content type `filesystem` (`zfs.block_mode` enabled) | same as `volume.block.mount_options` | Mount options for block-backed file system volumes -`security.shifted` | bool | custom volume | same as `volume.security.shifted` or `false` | {{enable_ID_shifting}} -`security.unmapped` | bool | custom volume | same as `volume.security.unmapped` or `false` | Disable ID mapping for the volume -`size` | string | | same as `volume.size` | Size/quota of the storage volume -`snapshots.expiry` | string | custom volume | same as `volume.snapshots.expiry` | {{snapshot_expiry_format}} -`snapshots.pattern` | string | custom volume | same as `volume.snapshots.pattern` or `snap%d` | {{snapshot_pattern_format}} [^*] -`snapshots.schedule` | string | custom volume | same as `snapshots.schedule` | {{snapshot_schedule_format}} -`zfs.blocksize` | string | | same as `volume.zfs.blocksize` | Size of the ZFS block in range from 512 to 16 MiB (must be power of 2) - for block volume, a maximum value of 128 KiB will be used even if a higher value is set -`zfs.block_mode` | bool | | same as `volume.zfs.block_mode` | Whether to use a formatted `zvol` rather than a {spellexception}`dataset` (`zfs.block_mode` can be set only for custom storage volumes; use `volume.zfs.block_mode` to enable ZFS block mode for all storage volumes in the pool, including instance volumes) -`zfs.delegate` | bool | ZFS 2.2 or higher | same as `volume.zfs.delegate` | Controls whether to delegate the ZFS dataset and anything underneath it to the container(s) using it. Allows the use of the `zfs` command in the container. -`zfs.remove_snapshots` | bool | | same as `volume.zfs.remove_snapshots` or `false` | Remove snapshots as needed -`zfs.use_refquota` | bool | | same as `volume.zfs.use_refquota` or `false` | Use `refquota` instead of `quota` for space -`zfs.reserve_space` | bool | | same as `volume.zfs.reserve_space` or `false` | Use `reservation`/`refreservation` along with `quota`/`refquota` +## ストレージボリューム設定 + +```{rst-class} break-col-4 min-width-4-8 +``` + +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`block.filesystem` | string | `zfs.block_mode`が有効 | `volume.block.filesystem` と同じ | {{block_filesystem}} +`block.mount_options` | string | `zfs.block_mode`が有効 | `volume.block.mount_options` と同じ | block-backedなファイルシステムボリュームのマウントオプション +`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 | | `volume.zfs.blocksize` と同じ | ZFSブロックのサイズを512～16MiBの範囲で指定します（2の累乗でなければなりません）。ブロックボリュームでは、より大きな値が設定されていても、最大値の128KiBが使用されます。 +`zfs.block_mode` | bool | | `volume.zfs.block_mode` と同じ | `dataset` よりもフォーマットした `zvol` を使うかどうか +`zfs.remove_snapshots` | bool | | `volume.zfs.remove_snapshots` と同じか `false` | 必要に応じてスナップショットを削除するかどうか +`zfs.use_refquota` | bool | | `volume.zfs.use_refquota` と同じか `false` | 領域の `quota` の代わりに `refquota` を使うかどうか +`zfs.reserve_space` | bool | | `volume.zfs.reserve_space` と同じか `false` | `qouta`/`refquota` に加えて `reservation`/`refreservation` も使用するかどうか [^*]: {{snapshot_pattern_detail}} -### Storage bucket configuration +### ストレージバケット設定 -To enable storage buckets for local storage pool drivers and allow applications to access the buckets via the S3 protocol, you must configure the {config:option}`server-core:core.storage_buckets_address` server setting. +ローカルのストレージプールドライバーでストレージバケットを有効にし、 S3 プロトコル経由でアプリケーションがバケットにアクセスできるようにするには{config:option}`server-core:core.storage_buckets_address`サーバー設定を調整する必要があります。 -Key | Type | Condition | Default | Description -:-- | :--- | :-------- | :------ | :---------- -`size` | string | appropriate driver | same as `volume.size` | Size/quota of the storage bucket +キー | 型 | 条件 | デフォルト値 | 説明 +:-- | :--- | :-------- | :------ | :---------- +`size` | string | 適切なドライバー | `volume.size` と同じ | ストレージバケットのサイズ/クォータ diff --git a/doc/remotes.md b/doc/remotes.md index bc8ef007a56..229b18fef87 100644 --- a/doc/remotes.md +++ b/doc/remotes.md @@ -1,24 +1,25 @@ -# How to add remote servers +# リモートサーバーを追加するには -Remote servers are a concept in the Incus command-line client. -By default, the command-line client interacts with the local Incus daemon, but you can add other servers or clusters to interact with. +リモートサーバーは Incus コマンドラインクライアント内の概念です。 +デフォルトでは、コマンドラインクライアントはローカルの Incus デーモンとやりとりしますが、他のサーバーやクラスタを追加できます。 -One use case for remote servers is to distribute images that can be used to create instances on local servers. -See {ref}`remote-image-servers` for more information. +リモートサーバーの用途の 1 つはローカルサーバーでインスタンスを作成するのに使えるイメージを配布することです。 +詳細は{ref}`remote-image-servers`を参照してください。 -You can also add a full Incus server as a remote server to your client. -In this case, you can interact with the remote server in the same way as with your local daemon. -For example, you can manage instances or update the server configuration on the remote server. +完全な Incus サーバーをお使いのクライアントにリモートサーバーとして追加することもできます。 +この場合、ローカルのデーモンと同様にリモートサーバーとやりとりできます。 +たとえば、リモートサーバー上のインスタンスを管理したりサーバー設定を更新できます。 -## Authentication +## 認証 -To be able to add a Incus server as a remote server, the server's API must be exposed, which means that its {config:option}`server-core:core.https_address` server configuration option must be set. +Incus サーバーをリモートサーバーとして追加できるようにするには、サーバーの API が公開されている必要があります。 +それはつまり、{config:option}`server-core:core.https_address`サーバー設定オプションが設定されている必要があることを意味します。 -When adding the server, you must then authenticate with it using the chosen method for {ref}`authentication`. +サーバーを追加する際は、{ref}`authentication`の方法で認証する必要があります。 -See {ref}`server-expose` for more information. +詳細は{ref}`server-expose`を参照してください。 -## List configured remotes +## 追加されたリモートを一覧表示する % Include parts of the content from file [howto/images_remote.md](howto/images_remote.md) ```{include} howto/images_remote.md @@ -26,7 +27,7 @@ See {ref}`server-expose` for more information. :end-before: ``` -## Add a remote Incus server +## リモートのIncusサーバーを追加する % Include parts of the content from file [howto/images_remote.md](howto/images_remote.md) ```{include} howto/images_remote.md @@ -34,31 +35,32 @@ See {ref}`server-expose` for more information. :end-before: ``` -## Select a default remote +## デフォルトのリモートを選択する -The Incus command-line client is pre-configured with the `local` remote, which is the local Incus daemon. +Incus コマンドラインクライアントは`local`リモート、つまりローカルの Incus デーモン、に接続する用に初期設定されています。 -To select a different remote as the default remote, enter the following command: +別のリモートをデフォルトのリモートとして選択するには、以下のように入力します: incus remote switch -To see which server is configured as the default remote, enter the following command: +どのサーバーがデフォルトのリモートとして設定されているか確認するには、以下のように入力します。 incus remote get-default -## Configure a global remote +## グローバルのリモートを設定する -You can configure remotes on a global, per-system basis. -These remotes are available for every user of the Incus server for which you add the configuration. +グローバルなシステム毎の設定としてリモートを設定できます。 +これらのリモートは、設定を追加した Incus サーバーのすべてのユーザーで利用できます。 -Users can override these system remotes (for example, by running [`incus remote rename`](incus_remote_rename.md) or [`incus remote set-url`](incus_remote_set-url.md)), which results in the remote and its associated certificates being copied to the user configuration. +ユーザーはこれらのシステムで設定されたリモートを（たとえば [`incus remote rename`](incus_remote_rename.md)または[`incus remote set-url`](incus_remote_set-url.md)を実行することで）オーバーライドできます。 +その結果、リモートと対応する証明書がユーザー設定にコピーされます。 -To configure a global remote, create or edit a `config.yml` file that is located in `/etc/incus/`. +グローバルリモートを設定するには、`/etc/incus/`に置かれた`config.yml`ファイルを編集します。 -Certificates for the remotes must be stored in the `servercerts` directory in the same location (for example, `/etc/incus/servercerts/`). -They must match the remote name (for example, `foo.crt`). +リモートへの接続用の証明書は同じ場所の`servercerts`ディレクトリー(たとえば、 `/etc/incus/servercerts/`)に保管する必要があります。 +証明書はリモート名に対応する(たとえば、`foo.crt`)必要があります。 -See the following example configuration: +以下の設定例を参照してください: ``` remotes: diff --git a/doc/requirements.md b/doc/requirements.md index 0369abe1185..884de7badf7 100644 --- a/doc/requirements.md +++ b/doc/requirements.md @@ -1,56 +1,55 @@ -# Requirements +# 動作環境 ## Go -Incus requires Go 1.18 or higher and is only tested with the Golang compiler. +Incus は Go 1.18 以上を必要とし、Golang のコンパイラのみでテストされています。 +（訳注：以前は gccgo もサポートされていましたが Golang のみになりました） -We recommend having at least 2GiB of RAM to allow the build to complete. +ビルドには最低 2GB の RAM を推奨します。 -## Kernel requirements +## 必要なカーネルバージョン -The minimum supported kernel version is 5.4. +される最小のカーネルバージョンは 5.4 です。 -Incus requires a kernel with support for: +Incus には以下の機能をサポートするカーネルが必要です。 -* Namespaces (`pid`, `net`, `uts`, `ipc` and `mount`) +* Namespaces （`pid`、`net`、`uts`、`ipc`と`mount`） * Seccomp * Native Linux AIO - ([`io_setup(2)`](https://man7.org/linux/man-pages/man2/io_setup.2.html), etc.) + （[`io_setup(2)`](https://man7.org/linux/man-pages/man2/io_setup.2.html)など） -The following optional features also require extra kernel options: +以下のオプションの機能はさらなるカーネルオプションを必要とします。 -* Namespaces (`user` and `cgroup`) -* AppArmor (including Ubuntu patch for mount mediation) -* Control Groups (`blkio`, `cpuset`, `devices`, `memory`, `pids` and `net_prio`) -* CRIU (exact details to be found with CRIU upstream) +* Namespaces （`user`と`cgroup`） +* AppArmor （mount mediation に対する Ubuntu パッチを含む） +* Control Groups （`blkio`、`cpuset`、`devices`、`memory`、`pids`と`net_prio`） +* CRIU (正確な詳細は CRIU のアップストリームを参照のこと) -As well as any other kernel feature required by the LXC version in use. +さらに使用している Incus のバージョンで必要とされるほかのカーネルの機能も必要です。 ## LXC -Incus requires LXC 4.0.0 or higher with the following build options: +Incus は以下のビルドオプションでビルドされた LXC 4.0.0 以上を必要とします。 -* `apparmor` (if using Incus' AppArmor support) +* `apparmor` （もし Incus の AppArmor サポートを使用するのであれば） * `seccomp` -To run recent version of various distributions, including Ubuntu, LXCFS -should also be installed. +Ubuntu を含むさまざまなディストリビューションの最近のバージョンを動かすためには、LXCFS もインストールする必要があります。 ## QEMU -For virtual machines, QEMU 6.0 or higher is required. +仮想マシンを利用するには QEMU 6.0 以降が必要です。 -## Additional libraries (and development headers) +## 追加のライブラリ（と開発用のヘッダ） -Incus uses `cowsql` for its database, to build and set it up, you can -run `make deps`. +Incus はデータベースとして`cowsql`を使用しています。 +ビルドしセットアップするためには`make deps`を実行してください。 -Incus itself also uses a number of (usually packaged) C libraries: +Incus はほかにもいくつかの (たいていはパッケージ化されている)C ライブラリを使用しています。 * `libacl1` * `libcap2` -* `libuv1` (for `cowsql`) -* `libsqlite3` >= 3.25.0 (for `cowsql`) +* `libuv1`（`cowsql`で使用） +* `libsqlite3` >= 3.25.0（`cowsql`で使用） -Make sure you have all these libraries themselves and their development -headers (`-dev` packages) installed. +ライブラリそのものとライブラリの開発用ヘッダ (`-dev` パッケージ)のすべてをインストールしたことを確認してください。 diff --git a/doc/rest-api.md b/doc/rest-api.md index 17231e5b099..e81c539d1eb 100644 --- a/doc/rest-api.md +++ b/doc/rest-api.md @@ -1,196 +1,195 @@ # REST API -All communication between Incus and its clients happens using a RESTful API over HTTP. -This API is encapsulated over either TLS (for remote operations) or a Unix socket (for local operations). +Incus とクライアント間のすべての通信は HTTP 上の RESTful API を使用します。 +この API や（リモートの通信では）TLS あるいは（ローカルの操作では）Unix ソケットで通信します。 -See {ref}`authentication` for information about how to access the API remotely. +どのようにリモートの API にアクセスするかについての情報は{ref}`authentication`を参照してください。 ```{tip} -- For examples on how the API is used, run any command of the Incus client ([`incus`](incus.md)) with the `--debug` flag. -The debug information displays the API calls and the return values. -- For quickly querying the API, the Incus client provides a [`incus query`](incus_query.md) command. +- どのように API が使われるかの例を見るにはLXDクライアント（[`incus`](incus.md)）で`--debug`フラグを追加してコマンドを実行してください。 +デバッグ情報がAPIの呼び出しと戻り値を表示します。 +- 手軽にに API を呼び出せるように、Incus クライアントは [`incus query`](incus_query.md) コマンドを提供しています。 ``` -## API versioning +## API のバージョニング -The list of supported major API versions can be retrieved using `GET /`. +サポートされている API のメジャーバージョンのリストは `GET /` を使って取得できます。 -The reason for a major API bump is if the API breaks backward compatibility. +後方互換性を壊す場合は API のメジャーバージョンが上がります。 -Feature additions done without breaking backward compatibility only -result in addition to `api_extensions` which can be used by the client -to check if a given feature is supported by the server. +後方互換性を壊さずに追加される機能は `api_extensions` の追加という形になり、 +特定の機能がサーバーでサポートされているかクライアントがチェックすることで +利用できます。 -## Return values +## 戻り値 -There are three standard return types: +次の 3 つの標準的な戻り値の型があります。 -* Standard return value -* Background operation -* Error +* 標準の戻り値 +* バックグラウンド操作 +* エラー -### Standard return value - -For a standard synchronous operation, the following JSON object is returned: +### 標準の戻り値 +標準の同期的な操作に対しては以下のような dict が返されます: ```js { "type": "sync", "status": "Success", "status_code": 200, - "metadata": {} // Extra resource/action specific metadata + "metadata": {} // リソースやアクションに固有な追加のメタデータ } ``` -HTTP code must be 200. +HTTP ステータスコードは必ず 200 です。 -### Background operation +### バックグラウンド操作 -When a request results in a background operation, the HTTP code is set to 202 (Accepted) -and the Location HTTP header is set to the operation URL. +リクエストの結果がバックグラウンド操作になる場合、 HTTP ステータスコードは 202（Accepted） +になり、操作の URL を指す HTTP の Location ヘッダが返されます。 -The body is a JSON object with the following structure: +レスポンスボディは以下のような構造を持つ dict です: ```js { "type": "async", "status": "OK", "status_code": 100, - "operation": "/1.0/instances/", // URL to the background operation - "metadata": {} // Operation metadata (see below) + "operation": "/1.0/instances/", // バックグラウンド操作の URL + "metadata": {} // 操作のメタデータ（下記参照） } ``` -The operation metadata structure looks like: +操作のメタデータの構造は以下のようになります: ```js { - "id": "a40f5541-5e98-454f-b3b6-8a51ef5dbd3c", // UUID of the operation - "class": "websocket", // Class of the operation (task, websocket or token) - "created_at": "2015-11-17T22:32:02.226176091-05:00", // When the operation was created - "updated_at": "2015-11-17T22:32:02.226176091-05:00", // Last time the operation was updated - "status": "Running", // String version of the operation's status - "status_code": 103, // Integer version of the operation's status (use this rather than status) - "resources": { // Dictionary of resource types (container, snapshots, images) and affected resources + "id": "a40f5541-5e98-454f-b3b6-8a51ef5dbd3c", // 操作の UUID + "class": "websocket", // 操作の種別（task, websocket, token のいずれか） + "created_at": "2015-11-17T22:32:02.226176091-05:00", // 操作の作成日時 + "updated_at": "2015-11-17T22:32:02.226176091-05:00", // 操作の最終更新日時 + "status": "Running", // 文字列表記での操作の状態 + "status_code": 103, // 整数表記での操作の状態（status ではなくこちらを利用してください。訳注: 詳しくは下記のステータスコードの項を参照） + "resources": { // リソース種別（container, snapshots, images のいずれか）の dict を影響を受けるリソース "containers": [ "/1.0/instances/test" ] }, - "metadata": { // Metadata specific to the operation in question (in this case, exec) + "metadata": { // 対象となっている（この例では exec）操作に固有なメタデータ "fds": { "0": "2a4a97af81529f6608dca31f03a7b7e47acc0b8dc6514496eb25e325f9e4fa6a", "control": "5b64c661ef313b423b5317ba9cb6410e40b705806c28255f601c0ef603f079a7" } }, - "may_cancel": false, // Whether the operation can be canceled (DELETE over REST) - "err": "" // The error string should the operation have failed + "may_cancel": false, //（REST で DELETE を使用して）操作がキャンセル可能かどうか + "err": "" // 操作が失敗した場合にエラー文字列が設定されます } ``` -The body is mostly provided as a user friendly way of seeing what's -going on without having to pull the target operation, all information in -the body can also be retrieved from the background operation URL. +対象の操作に対して追加のリクエストを送って情報を取り出さなくても、 +何が起こっているかユーザーにとってわかりやすい形でボディは構成されています。 +ボディに含まれるすべての情報はバックグラウンド操作の URL から取得する +こともできます。 -### Error +### エラー -There are various situations in which something may immediately go -wrong, in those cases, the following return value is used: +さまざまな状況によっては操作を行う前に直ぐに問題が起きる場合があり、 +そういう場合には以下のような値が返されます: ```js { "type": "error", "error": "Failure", "error_code": 400, - "metadata": {} // More details about the error + "metadata": {} // エラーについてのさらなる詳細 } ``` -HTTP code must be one of of 400, 401, 403, 404, 409, 412 or 500. - -## Status codes - -The Incus REST API often has to return status information, be that the -reason for an error, the current state of an operation or the state of -the various resources it exports. - -To make it simple to debug, all of those are always doubled. There is a -numeric representation of the state which is guaranteed never to change -and can be relied on by API clients. Then there is a text version meant -to make it easier for people manually using the API to figure out what's -happening. - -In most cases, those will be called status and `status_code`, the former -being the user-friendly string representation and the latter the fixed -numeric value. - -The codes are always 3 digits, with the following ranges: - -* 100 to 199: resource state (started, stopped, ready, ...) -* 200 to 399: positive action result -* 400 to 599: negative action result -* 600 to 999: future use - -### List of current status codes - -Code | Meaning -:--- | :------ -100 | Operation created -101 | Started -102 | Stopped -103 | Running -104 | Canceling -105 | Pending -106 | Starting -107 | Stopping -108 | Aborting -109 | Freezing -110 | Frozen -111 | Thawed -112 | Error -113 | Ready -200 | Success -400 | Failure -401 | Canceled +HTTP ステータスコードは 400、401、403、404、409、412、500 のいずれかです。 + +## ステータスコード +Incus REST API はステータス情報を返す必要があります。それはエラーの理由だったり、 +操作の現在の状態だったり、 Incus が提供する様々なリソースの状態だったりします。 + +デバッグをシンプルにするため、ステータスは常に文字列表記と整数表記で +重複して返されます。ステータスの整数表記の値は将来に渡って不変なので +API クライアントが個々の値に依存できます。文字列表記のステータスは +人間が API を手動で実行したときに何が起きているかをより簡単に判断 +できるように用意されています。 + +ほとんどのケースでこれらは `status` と `status_code` と呼ばれ、前者は +ユーザーフレンドリーな文字列表記で後者は固定の数値です。 + +整数表記のコードは常に 3 桁の数字で以下の範囲の値となっています。 + +* 100 to 199: リソースの状態（started、stopped、ready、…） +* 200 to 399: 成功したアクションの結果 +* 400 to 599: 失敗したアクションの結果 +* 600 to 999: 将来使用するために予約されている番号の範囲 + +### 現在使用されているステータスコード一覧 + +コード | 意味 +:--- | :------ +100 | 操作が作成された +101 | 開始された +102 | 停止された +103 | 実行中 +104 | キャンセル中 +105 | ペンディング +106 | 開始中 +107 | 停止中 +108 | 中断中 +109 | 凍結中 +110 | 凍結された +111 | 解凍された +112 | エラー +113 | 準備完了 +200 | 成功 +400 | 失敗 +401 | キャンセルされた (rest-api-recursion)= -## Recursion +## 再帰 -To optimize queries of large lists, recursion is implemented for collections. -A `recursion` argument can be passed to a GET query against a collection. +巨大な一覧のクエリを最適化するために、コレクションに対して再帰が実装されています。 +コレクションに対するクエリの GET リクエストに `recursion` パラメーターを指定できます。 -The default value is 0 which means that collection member URLs are -returned. Setting it to 1 will have those URLs be replaced by the object -they point to (typically another JSON object). +デフォルト値は 0 でコレクションのメンバーの URL が返されることを意味します。 +1 を指定するとこれらの URL がそれが指すオブジェクト（通常は dict 形式）で +置き換えられます。 -Recursion is implemented by simply replacing any pointer to an job (URL) -by the object itself. +再帰はジョブへのポインタ（URL）をオブジェクトそのもので単に置き換えるように +実装されています。 (rest-api-filtering)= -## Filtering +## フィルタ -To filter your results on certain values, filter is implemented for collections. -A `filter` argument can be passed to a GET query against a collection. +検索結果をある値でフィルタするために、コレクションにフィルタが実装されています。 +コレクションに対する GET クエリに `filter` 引数を渡せます。 -Filtering is available for the instance, image and storage volume endpoints. +フィルタはインスタンス、イメージ、ストレージボリュームのエンドポイントに提供されています。 -There is no default value for filter which means that all results found will -be returned. The following is the language used for the filter argument: +フィルタにはデフォルト値はありません。これは見つかったすべての結果が返されることを意味します。 +フィルタの引数には以下のような言語を設定します。 ?filter=field_name eq desired_field_assignment -The language follows the OData conventions for structuring REST API filtering -logic. Logical operators are also supported for filtering: not (`not`), equals (`eq`), -not equals (`ne`), and (`and`), or (`or`). Filters are evaluated with left associativity. -Values with spaces can be surrounded with quotes. Nesting filtering is also supported. -For instance, to filter on a field in a configuration you would pass: +この言語は REST API のフィルタロジックを構成するための OData の慣習に従います。 +フィルタは下記の論理演算子もサポートします。 +not（`not`）、equals（`eq`）、not equals（`ne`）、and（`and`）、or（`or`） +フィルタは左結合で評価されます。 +空白を含む値はクォートで囲むことができます。 +ネストしたフィルタもサポートされます。 +たとえば設定内のフィールドに対してフィルタするには以下のように指定します: ?filter=config.field_name eq desired_field_assignment -For filtering on device attributes you would pass: +device の属性についてフィルタするには以下のように指定します: ?filter=devices.device_name.field_name eq desired_field_assignment -Here are a few GET query examples of the different filtering methods mentioned above: +以下に上記の異なるフィルタの方法を含む GET クエリをいくつか示します: containers?filter=name eq "my container" and status eq Running @@ -198,53 +197,40 @@ Here are a few GET query examples of the different filtering methods mentioned a images?filter=Properties.os eq Centos and not UpdateSource.Protocol eq simplestreams -## Asynchronous operations - -Any operation which may take more than a second to be done must be done -in the background, returning a background operation ID to the client. - -The client will then be able to either poll for a status update or wait -for a notification using the long-poll API. - -## Notifications - -A WebSocket-based API is available for notifications, different notification -types exist to limit the traffic going to the client. +## 非同期操作 -It's recommended that the client always subscribes to the operations -notification type before triggering remote operations so that it doesn't -have to then poll for their status. +完了までに 1 秒以上かかるかもしれない操作はバックグラウンドで実行しなければ +なりません。そしてクライアントにはバックグラウンド操作 ID を返します。 -## PUT vs PATCH +クライアントは操作のステータス更新をポーリングするか long-poll API を使って +通知を待つことが出来ます。 -The Incus API supports both PUT and PATCH to modify existing objects. +## 通知 -PUT replaces the entire object with a new definition, it's typically -called after the current object state was retrieved through GET. +通知のために WebSocket ベースの API が利用できます。クライアントへ送られる +トラフィックを制限するためにいくつかの異なる通知種別が存在します。 -To avoid race conditions, the ETag header should be read from the GET -response and sent as If-Match for the PUT request. This will cause Incus -to fail the request if the object was modified between GET and PUT. +リモート操作の状態をポーリングしなくて済むように、リモート操作を開始する +前に操作の通知をクライアントが常に購読しておくのがお勧めです。 -PATCH can be used to modify a single field inside an object by only -specifying the property that you want to change. To unset a key, setting -it to empty will usually do the trick, but there are cases where PATCH -won't work and PUT needs to be used instead. +## PUT と PATCH の使い分け -## Instances, containers and virtual-machines +Incus API は既存のオブジェクトを変更するのに PUT と PATCH の両方をサポートします。 -The documentation shows paths such as `/1.0/instances/...`, which were introduced with Incus 3.19. -Older releases that supported only containers and not virtual machines supply the exact same API at `/1.0/containers/...`. +PUT はオブジェクト全体を新しい定義で置き換えます。典型的には GET で現在の +オブジェクトの状態を取得した後に PUT が呼ばれます。 -For backward compatibility reasons, Incus does still expose and support -that `/1.0/containers` API, though for the sake of brevity, we decided -not to double-document everything. +レースコンディションを避けるため、 GET のレスポンスから ETag ヘッダを読み取り +PUT リクエストの If-Match ヘッダに設定するべきです。こうしておけば GET と +PUT の間にオブジェクトが他から変更されていた場合は更新が失敗するようになります。 -An additional endpoint at `/1.0/virtual-machines` is also present and -much like `/1.0/containers` will only show you instances of that type. +PATCH は変更したいプロパティだけを指定することでオブジェクト内の単一の +フィールドを変更するのに用いられます。キーを削除するには通常は空の値を +設定すれば良いようになっていますが、 PATCH ではキーの削除は出来ず、代わりに +PUT を使う必要がある場合もあります。 -## API structure +## API 構造 -Incus has an auto-generated [Swagger](https://swagger.io/) specification describing its API endpoints. -The YAML version of this API specification can be found in [`rest-api.yaml`](https://github.com/lxc/incus/blob/main/doc/rest-api.yaml). -See {doc}`api` for a convenient web rendering of it. +Incus は API エンドポイントを記述する [Swagger](https://swagger.io/) 仕様を自動生成しています。 +この API 仕様の YAML 版が [`rest-api.yaml`](https://github.com/lxc/incus/blob/main/doc/rest-api.yaml) にあります。 +手軽にウェブで見る場合は {doc}`api` を参照してください。 diff --git a/doc/security.md b/doc/security.md index 63c1f45cd4f..42f47da8142 100644 --- a/doc/security.md +++ b/doc/security.md @@ -6,4 +6,4 @@ explanation/security authentication -Expose Incus to the network +Incusをネットワークに公開 diff --git a/doc/server.md b/doc/server.md index 7ae2c52d46f..5318b935067 100644 --- a/doc/server.md +++ b/doc/server.md @@ -4,14 +4,14 @@ ```{toctree} :maxdepth: 1 -Configure the server +サーバーを設定するには /server_config -System settings -Backups -Performance tuning -Benchmarking -Monitor metrics -Recover instances -Database +システム設定 +バックアップ +パフォーマンスチューニング +ベンチマーク +メトリクス監視 +インスタンスの復旧 +データベース /architectures ``` diff --git a/doc/server_config.md b/doc/server_config.md index ab457e7f8d4..a7820767b1e 100644 --- a/doc/server_config.md +++ b/doc/server_config.md @@ -1,10 +1,10 @@ (server)= -# Server configuration +# サーバー設定 -The Incus server can be configured through a set of key/value configuration options. +Incus サーバーは key/value 設定オプションで設定できます。 -The key/value configuration is namespaced. -The following options are available: +key/value 設定は名前空間が分けられています。 +以下のオプションが利用可能です: - {ref}`server-options-core` - {ref}`server-options-acme` @@ -13,17 +13,17 @@ The following options are available: - {ref}`server-options-loki` - {ref}`server-options-misc` -See {ref}`server-configure` for instructions on how to set the configuration options. +設定オプションをどのように設定するかについての手順は{ref}`server-configure`を参照してください。 ```{note} -Options marked with a `global` scope are immediately applied to all cluster members. -Options with a `local` scope must be set on a per-member basis. +このページの表で`global`スコープと表記されたオプションは即時に全てのクラスタメンバーに適用されます。 +`local`スコープと表記されたオプションはメンバーごとに設定する必要があります。 ``` (server-options-core)= -## Core configuration +## コア設定 -The following server options control the core daemon configuration: +以下のサーバーオプションはコアデーモンの設定を制御します: % Include content from [config_options.txt](config_options.txt) ```{include} config_options.txt @@ -32,9 +32,9 @@ The following server options control the core daemon configuration: ``` (server-options-acme)= -## ACME configuration +## ACME設定 -The following server options control the {ref}`ACME ` configuration: +以下のサーバーオプションは{ref}`ACME `設定を制御します: % Include content from [config_options.txt](config_options.txt) ```{include} config_options.txt @@ -43,9 +43,9 @@ The following server options control the {ref}`ACME ` integration, {ref}`Backups ` and {ref}`storage`: +以下のサーバーオプションは{ref}`instances`のサーバー固有設定、MAAS 統合、{ref}`OVN `統合、{ref}`バックアップ `、{ref}`storage`を設定します: % Include content from [config_options.txt](config_options.txt) ```{include} config_options.txt diff --git a/doc/storage.md b/doc/storage.md index 3c5e8e52f53..99da93e9f12 100644 --- a/doc/storage.md +++ b/doc/storage.md @@ -1,15 +1,15 @@ (storage)= -# Storage +# ストレージ ```{toctree} :maxdepth: 1 -About storage -Manage pools -Create an instance in a pool -Manage volumes -Move or copy a volume -Back up a volume -Manage buckets +ストレージについて +プールの管理 +プール内にインスタンスを作成 +ボリュームの管理 +ボリュームの移動とコピー +ボリュームのバックアップ +バケットの管理 reference/storage_drivers ``` diff --git a/doc/substitutions.yaml b/doc/substitutions.yaml index c2b3f122a4e..33b7814ef16 100644 --- a/doc/substitutions.yaml +++ b/doc/substitutions.yaml @@ -1,9 +1,9 @@ # Key/value substitutions to use within the Sphinx doc. -{note_ip_addresses_CIDR: "Incus uses the [CIDR notation](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) where network subnet information is required, for example, `192.0.2.0/24` or `2001:db8::/32`. This does not apply to cases where a single address is required, for example, local/remote addresses of tunnels, NAT addresses or specific addresses to apply to an instance.", -snapshot_expiry_format: "Controls when snapshots are to be deleted (expects an expression like `1M 2H 3d 4w 5m 6y`)", -snapshot_pattern_format: "Pongo2 template string that represents the snapshot name (used for scheduled snapshots and unnamed snapshots)", -snapshot_pattern_detail: "The `snapshots.pattern` option takes a Pongo2 template string to format the snapshot name.\n\nTo add a time stamp to the snapshot name, use the Pongo2 context variable `creation_date`.\nMake sure to format the date in your template string to avoid forbidden characters in the snapshot name.\nFor example, set `snapshots.pattern` to `{{ creation_date|date:'2006-01-02_15-04-05' }}` to name the snapshots after their time of creation, down to the precision of a second.\n\nAnother way to avoid name collisions is to use the placeholder `%d` in the pattern.\nFor the first snapshot, the placeholder is replaced with `0`.\nFor subsequent snapshots, the existing snapshot names are taken into account to find the highest number at the placeholder's position.\nThis number is then incremented by one for the new name.", -snapshot_schedule_format: "Cron expression (` `), a comma-separated list of schedule aliases (`@hourly`, `@daily`, `@midnight`, `@weekly`, `@monthly`, `@annually`, `@yearly`), or empty to disable automatic snapshots (the default)", -enable_ID_shifting: "Enable ID shifting overlay (allows attach by multiple isolated instances)", -block_filesystem: "File system of the storage volume: `btrfs`, `ext4` or `xfs` (`ext4` if not set)", -volume_configuration: "```{tip}\nIn addition to these configurations, you can also set default values for the storage volume configurations. See {ref}`storage-configure-vol-default`.\n```"} +{note_ip_addresses_CIDR: "ネットワークのサブネット情報を指定する箇所では Incus は [CIDR 表記](https://ja.wikipedia.org/wiki/Classless_Inter-Domain_Routing) (例えば `192.0.2.0/24` や `2001:db8::/32`) を使用します。これは単一のアドレスが必要なケース (例えば、トンネルのローカル／リモートアドレス、インスタンスに適用する NAT アドレスや特定のアドレス) では適用されません。", +snapshot_expiry_format: "スナップショットをいつ削除するかを制御 (`1M 2H 3d 4w 5m 6y` のような式を期待)", +snapshot_pattern_format: "スナップショットの名前を表す Pongo2 テンプレート文字列 (スケジュールされたスナップショットと名前無しのスナップショットで使用)", +snapshot_pattern_detail: "`snapshots.pattern` オプションはスナップショット名をフォーマットする Pongo2 テンプレート文字列です。\n\nスナップショット名にタイムスタンプを追加するには、Pongo2 コンテキスト変数 `creation_date` を使用します。\nスナップショット名に使用できない文字を含まないようにテンプレート文字列をフォーマットするようにしてください。\n例えば、 `snapshots.pattern` を `{{ creation_date|date:'2006-01-02_15-04-05' }}` に設定し、作成日時を秒の制度まで落として、スナップショットを命名するようにします。\n\n名前の衝突を防ぐ別の方法はパターン内に `%d` プレースホルダを使うことです。\n最初のスナップショットでは、プレースホルダは `0` に置換されます。\n後続のスナップショットでは、既存のスナップショットが考慮され、プレースホルダの位置の最大の数を見つけます。\nこの数が 1 増加されて新しい名前に使用されます。", +snapshot_schedule_format: "Cron 表記 (` `)、またはスケジュールエイリアスのカンマ区切りリスト(`@hourly`, `@daily`, `@midnight`, `@weekly`, `@monthly`, `@annually`, `@yearly`)、または自動スナップショットを無効にする場合は空文字(デフォルト)", +enable_ID_shifting: "ID シフトオーバーレイを有効にする (複数の分離されたインスタンスによるアタッチを許可する)", +block_filesystem: "ストレージボリュームのファイルシステム: `btrfs`, `ext4` または `xfs` (未指定の場合 `ext4`)", +volume_configuration: "```{tip}\nこれらの設定に加えて、ストレージボリューム設定のデフォルト値を設定できます。 {ref}`storage-configure-vol-default` を参照してください。\n```"} diff --git a/doc/support.md b/doc/support.md index 55fcb44ae3b..c899cc0a8a8 100644 --- a/doc/support.md +++ b/doc/support.md @@ -1,19 +1,19 @@ -# Support +# サポート -Incus maintains different release branches in parallel: +Incus は同時に複数のリリースブランチをメンテナンスしています。 -- Long term support (LTS) releases: upcoming -- Feature releases: Incus 0.x +- 長期サポート（LTS）リリース：近く発表予定 +- 機能リリース：Incus 0.x -The upcoming LTS release will be Incus 6.0, which will supported until June 2029 and will get frequent bugfix and security updates, but won't receive any feature additions. +近く発表予定の LTS リリースは Incus 6.0 です。これは 2029 年 6 月までサポートされ、随時バグ修正とセキュリティーアップデートが入りますが、機能追加は含まれません。 -Feature releases will be pushed out about every quarter and contain new features as well as bugfixes. -The normal support length for those releases is until the next release comes out. -Some Linux distributions might offer longer support for particular feature releases that they decided to ship. +機能リリースはおよそ四半期ごとに更新され、バグ修正に加えて新機能を含みます。 +これらのリリースの通常のサポート期間は時期リリースが出るまでです。 +一部の Linux ディストリビューションでは、ディストリビューションが決めた特定の機能リリースをより長い期間サポートするかもしれません。 % Include content from [../README.md](../README.md) ```{include} ../README.md diff --git a/doc/syscall-interception.md b/doc/syscall-interception.md index aef796277d2..780d410e424 100644 --- a/doc/syscall-interception.md +++ b/doc/syscall-interception.md @@ -1,32 +1,23 @@ -# System call interception +# システムコールのインターセプション -Incus supports intercepting some specific system calls from unprivileged -containers. If they're considered to be safe, it executes them with -elevated privileges on the host. +Incus では非特権コンテナで、いくつか特定のシステムコールをインターセプトできます。 +もし、それが安全であると見なせるのであれば、ホスト上で特権を昇格させて実行します。 -Doing so comes with a performance impact for the syscall in question and -will cause some work for Incus to evaluate the request and if allowed, -process it with elevated privileges. +これを行うことで、対象のシステムコールではパフォーマンスに影響があり、Incus ではリクエストを評価するための作業が必要となり、もし許可されれば昇格した特権で実行されます。 -Enabling of specific system call interception options is done on a -per-container basis through container configuration options. +特定のシステムコールインターセプションのオプションの有効化はコンテナの設定オプションを使ってコンテナ単位で行われます。 -## Available system calls +## 利用できるシステムコール ### `mknod` / `mknodat` -The `mknod` and `mknodat` system calls can be used to create a variety of special files. +`mknod` と `mknodat` システムコールを使用して、色々なスペシャルファイルを作成できます。 -Most commonly inside containers, they may be called to create block or character devices. -Creating such devices isn't allowed in unprivileged containers as this -is a very easy way to escalate privileges by allowing direct write -access to resources like disks or memory. +もっとも一般的にはコンテナ内部で、ブロックデバイスやキャラクターデバイスを作成するために呼び出されます。このようなデバイスを作成することは、非特権コンテナ内では許可されません。これは、ディスクやメモリーのようなリソースに直接書き込みのアクセスを許可することになり、特権を昇格するのに非常に簡単な方法であるためです。 -But there are files which are safe to create. For those, intercepting -this syscall may unblock some specific workloads and allow them to run -inside an unprivileged containers. +しかし、作成しても安全であるファイルもあります。このような場合に、システムコールをインターセプトすることで、特定の処理のブロックが解除され、非特権コンテナ内部で実行できるようになります。 -The devices which are currently allowed are: +現時点で許可されているデバイスは次のものです: - overlayfs whiteout (char 0:0) - `/dev/console` (char 5:1) @@ -37,90 +28,81 @@ The devices which are currently allowed are: - `/dev/urandom` (char 1:9) - `/dev/zero` (char 1:5) -All file types other than character devices are currently sent to the -kernel as usual, so enabling this feature doesn't change their behavior -at all. +キャラクターデバイス以外のすべてのファイルタイプは、現時点では通常通りカーネルに送られるので、この機能を有効にしても動作は全く変わりません。 -This can be enabled by setting `security.syscalls.intercept.mknod` to `true`. +この機能は `security.syscalls.intercept.mknod` を `true` に設定することで有効に出来ます。 ### `bpf` -The `bpf` system call is used to manage eBPF programs in the kernel. -Those can be attached to a variety of kernel subsystems. +カーネル内の eBPF プログラムを管理するために `bpf` システムコールを使用します。 +これらは様々なカーネルサブシステムにアタッチされます。 -In general, loading of eBPF programs that are not trusted can be problematic as it -can facilitate timing based attacks. +一般に、信頼していない eBPF プログラムをロードするのはタイミングベースの攻撃を +容易にするので問題です。 -Incus' eBPF support is currently restricted to programs managing devices -cgroup entries. To enable it, you need to set both -`security.syscalls.intercept.bpf` and -`security.syscalls.intercept.bpf.devices` to true. +Incus の eBPF サポートは現在のところデバイスの cgroup エントリを管理するプログラムに +限定しています。有効にするには `security.syscalls.intercept.bpf` と +`security.syscalls.intercept.bpf.devices` の両方を true に設定する必要があります。 ### `mount` -The `mount` system call allows for mounting both physical and virtual file systems. -By default, unprivileged containers are restricted by the kernel to just -a handful of virtual and network file systems. +`mount` システムコールは物理と仮想ファイルシステムの両方のマウントを可能にします。 +デフォルトでは、非特権コンテナはカーネルにより制限され、いくつかの仮想とネットワーク +ファイルシステムのみに限定されています。 -To allow mounting physical file systems, system call interception can be used. -Incus offers a variety of options to handle this. +物理ファイルシステムをマウントできるようにするにはシステムコールインターセプションが使えます。 +Incus はこれを取り扱うために様々な選択肢を提供しています。 -`security.syscalls.intercept.mount` is used to control the entire -feature and needs to be turned on for any of the other options to work. +`security.syscalls.intercept.mount` は全体の機能を制御するのに使用され、 +他のいずれかの選択肢を機能させるためには有効にする必要があります。 -`security.syscalls.intercept.mount.allowed` allows specifying a list of -file systems which can be directly mounted in the container. This is the -most dangerous option as it allows the user to feed data that is not trusted at -the kernel. This can easily be used to crash the host system or to -attack it. It should only ever be used in trusted environments. +`security.syscalls.intercept.mount.allowed` はコンテナ内に直接マウント可能な +ファイルシステムのリストを指定できます。 +これはユーザーが信頼できないデータをカーネルに送り込むことを許すため +最も危険な選択肢です。 +これにより簡単にホストシステムをクラッシュさせたり攻撃が出来てしまいます。 +そのため信頼された環境でのみ使うようにすべきです。 -`security.syscalls.intercept.mount.shift` can be set on top of that so -the resulting mount is shifted to the UID/GID map used by the container. -This is needed to avoid everything showing up as `nobody`/`nogroup` inside -of unprivileged containers. +`security.syscalls.intercept.mount.shift` は上記に加えてコンテナで使用される +UID/GID マップでマウントした結果をシフトさせるのに使用できます。 +これは非特権コンテナ内ですべてが `nobody`/`nogroup` として表示されるのを回避するために必要です。 -The much safer alternative to those is -`security.syscalls.intercept.mount.fuse` which can be set to pairs of -file-system name and FUSE handler. When this is set, an attempt at -mounting one of the configured file systems will be transparently -redirected to instead calling the FUSE equivalent of that file system. +これらよりもっと安全な代替は `security.syscalls.intercept.mount.fuse` で +ファイルシステムの名前と FUSE ハンドラの組を指定できます。 +これが設定されると指定されたファイルシステムのどれかをマウントしようとすると +そのファイルシステムに対応する FUSE ハンドラ呼び出しにリダイレクトされます。 -As this is all running as the caller, it avoids the entire issue around -the kernel attack surface and so is generally considered to be safe, -though you should keep in mind that any kind of system call interception -makes for an easy way to overload the host system. +これはすべて呼び出し側として実行されるので、カーネルのアタックサーフェスに +まつわるすべての問題を回避し、そのため一般的に安全と考えられます。 +しかし、あらゆる種類のシステムコールインターセプションはホストシステムに +過大な負荷をかける簡単な方法になることを留意しておくべきです。 ### `sched_setscheduler` -The `sched_setscheduler` system call is used to manage process priority. +`sched_setscheduler` システムコールはプロセスの優先度を管理するのに使えます。 -Granting this may allow a user to significantly increase the priority of -their processes, potentially taking a lot of system resources. +これを許可するとユーザーが自分のプロセスの優先度を著しく上げることを許すため、 +潜在的に多くのシステムリソースを使われることになります。 -It also allows access to schedulers like `SCHED_FIFO` which are generally -considered to be flawed and can significantly impact overall system -stability. This is why under normal conditions, only the real root user -(or global `CAP_SYS_NICE`) would allow its use. +これはまた `SCHED_FIFO` のようなスケジューラへのアクセスを許すので、 +一般的には欠陥と考えられ、システム全体の安定性に著しく影響を与える可能性があります。 +このため通常の状況下では、真の root ユーザー（あるいはグローバルの `CAP_SYS_NICE`） +のみがこれの使用を許すべきです。 ### `setxattr` -The `setxattr` system call is used to set extended attributes on files. +`setxattr` システムコールは、拡張ファイル属性を設定するのに使われます。 -The attributes which are handled by this currently are: +現時点で、これにより処理される属性は次のものです: - `trusted.overlay.opaque` (overlayfs directory whiteout) -Note that because the mediation must happen on a number of character -strings, there is no easy way at present to only intercept the few -attributes we care about. As we only allow the attributes above, this -may result in breakage for other attributes that would have been -previously allowed by the kernel. +この介入は多数の文字列で行う必要があるため、現在のところ、対象の少数の属性のみインターセプトする簡単な方法がありません。上記の属性のみを許可しているため、カーネルが以前に許可していた他の属性を破損する可能性があります。 -This can be enabled by setting `security.syscalls.intercept.setxattr` to `true`. +この機能は `security.syscalls.intercept.setxattr` を `true` に設定することで有効にできます。 ### `sysinfo` -The `sysinfo` system call is used by some distributions instead of `/proc/` entries to report on resource usage. +`sysinfo` システムコールはいくつかのディストリビューションでリソース使用量を報告するのに `/proc/` エントリーの代わりに使用されます。 -In order to provide resource usage information specific to the container, rather than the whole system, this -syscall interception mode uses cgroup-based resource usage information to fill in the system call response. +システム全体ではなく個々のコンテナのリソース使用情報を提供するために、このシステムコール・インターセプションモードはシステムコールのレスポンスに cgroup ベースのリソース使用情報を設定します。 diff --git a/doc/tutorial/first_steps.md b/doc/tutorial/first_steps.md index 611a16f27e5..2e6372c2526 100644 --- a/doc/tutorial/first_steps.md +++ b/doc/tutorial/first_steps.md @@ -1,182 +1,179 @@ (first-steps)= -# First steps with Incus +# Incusを使う最初のステップ -This tutorial guides you through the first steps with Incus. -It covers installing and initializing Incus, creating and configuring some instances, interacting with the instances, and creating snapshots. +このチュートリアルは Incus を使う最初のステップのガイドです。 +Incus のインストールと初期化、インスタンスの作成と設定、インスタンスの操作、スナップショットの作成を取り扱います。 -After going through these steps, you will have a general idea of how to use Incus, and you can start exploring more advanced use cases! +これらのステップを経験した後、どのように Incus を使うかのアイデアがあれば、より高度な使用例について探索を開始できることでしょう！ -## Install and initialize Incus +## Incusのインストールと初期化 -Currently the easiest way to install Incus is to use the Debian or Ubuntu packages provided by [Zabbly](https://zabbly.com). -There are two repositories available, one for the current stable release and one for daily (untested) builds. +現時点で Incus をインストールする一番簡単な方法は[Zabbly](https://zabbly.com)で提供されている Debian または Ubuntu のパッケージを使う方法です。 +最新の安定版リリースと（テストされていない）デイリービルドの 2 つのリポジトリがあります。 -Installation instructions may be found here: [`https://github.com/zabbly/incus`](https://github.com/zabbly/incus) +インストール手順は[`https://github.com/zabbly/incus`](https://github.com/zabbly/incus)にあります。 -If you prefer a different installation method, see {ref}`installing`. +他のインストール方法については{ref}`installing`を参照してください。 -1. Allow your user to control Incus +1. あなたのユーザーに Incus を制御する許可を与えます。 - Access to Incus in the packages above is controlled through two groups: + 上記のパッケージに含まれる Incus へのアクセスは 2 つのグループで制御されます。 - - `incus` allows basic user access, no configuration and all actions restricted to a per-user project. - - `incus-admin` allows full control over Incus. + - `incus`は基本的なユーザーアクセスを許可します。設定はできずすべてのアクションはユーザーごとのプロジェクトに限定されます。 + - `incus-admin`は Incus の完全なコントロールを許可します。 - To control Incus without having to run all commands as root, you can add yourself to the `incus-admin` group: + すべてのコマンドを root で実行することなく Incus を制御するには、あなた自身を`incus-admin`グループに追加してください。 sudo adduser YOUR-USERNAME incus-admin newgrp incus-admin - The `newgrp` step is needed in any terminal that interacts with Incus until you restart your user session. + `newgrp`の手順はあなたの端末セッションを再起動しないままで Incus を利用する場合に必要です（訳注：端末を起動し直す場合は不要です）。 -1. Initialize Incus with: +1. Incus を初期化します。 incus admin init --minimal - This will create a minimal setup with default options. - If you want to tune the initialization options, see {ref}`initialize` for more information. + この手順はフォルトのオプションで最小セットアップの構成を作成します。 + 初期化オプションをチューニングしたい場合、詳細は{ref}`initialize`を参照してください。 -## Launch and inspect instances +## インスタンスの起動と調査 -Incus is image based and can load images from different image servers. -In this tutorial, we will use the [official image server](https://images.linuxcontainers.org/). +Incus はイメージベースです。そしてさまざまなイメージサーバーからイメージをロードできます。 +このチュートリアルでは、[公式イメージサーバ](https://images.linuxcontainers.org/)イメージサーバーを使います。 -You can list all images that are available on this server with: +このイメージサーバーで利用可能なすべてのイメージを一覧表示するには以下のようにします。 - incus image list images: + lxc image list images: -See {ref}`images` for more information about the images that Incus uses. +Incus が使用するイメージについてのより詳細情報は{ref}`images`を参照してください。 -Now, let's start by launching a few instances. -With *instance*, we mean either a container or a virtual machine. -See {ref}`containers-and-vms` for information about the difference between the two instance types. +では、いくつかインスタンスを起動してみましょう。 +コンテナまたは仮想マシンのことを*インスタンス*と呼びます。 +2 つのインスタンスタイプの違いについての情報は{ref}`containers-and-vms`を参照してください。 -For managing instances, we use the Incus command line client `incus`. +インスタンスを管理するには、Incus のコマンドラインクライアント`incus`を使います。 -1. Launch a container called `first` using the Ubuntu 22.04 image: +1. Ubuntu 22.04 イメージを使って`first`という名前のコンテナを起動します。 incus launch images:ubuntu/22.04 first ```{note} - Launching this container takes a few seconds, because the image must be downloaded and unpacked first. + 最初はイメージをダウンロードして展開しなければならないため、コンテナの起動には少し時間がかかることに注意してください。 ``` -1. Launch a container called `second` using the same image: +1. 同じイメージを使って`second`という名前のコンテナを起動します。 incus launch images:ubuntu/22.04 second ```{note} - Launching this container is quicker than launching the first, because the image is already available. + イメージを取得済みなので、最初の（first）コンテナの起動に比べると早く起動します。 ``` -1. Copy the first container into a container called `third`: +1. 最初の（first）コンテナを`third`という名前のコンテナとしてコピーします。 incus copy first third -1. Launch a VM called `ubuntu-vm` using the Ubuntu 22.04 image: +1. Ubuntu 22.04 イメージを使って`ubuntu-vm`という名前の仮想マシンを起動します。 incus launch images:ubuntu/22.04 ubuntu-vm --vm ```{note} - Even though you are using the same image name to launch the instance, Incus downloads a slightly different image that is compatible with VMs. + インスタンスの起動に同じイメージ名を使っていますが、Incusは仮想マシンに適した少し異なるイメージをダウンロードします。 ``` -1. Check the list of instances that you launched: +1. 起動したインスタンスのリストをチェックします。 incus list - You will see that all but the third container are running. - This is because you created the third container by copying the first, but you didn't start it. + 3 番目のコンテナ以外は稼働中になっています。 + 3 つ目のコンテナ以外が起動していることが確認できるでしょう。これは、3 つ目のコンテナを最初の（first）コンテナからコピーして作成はしたものの、起動処理を実行していないからです。 - You can start the third container with: + 3 つ目のインスタンスを次のように起動できます。 incus start third -1. Query more information about each instance with: +1. それぞれのコンテナの情報をもう少し詳しく見ることができます。 incus info first incus info second incus info third incus info ubuntu-vm -1. We don't need all of these instances for the remainder of the tutorial, so let's clean some of them up: +1. チュートリアルではこの後、これらのインスタンスすべては必要ありませんので、不要なインスタンスを消しましょう。 - 1. Stop the second container: + 1. 2 つ目のコンテナを停止します。 incus stop second - 1. Delete the second container: + 1. 2 つ目のコンテナを削除します。 incus delete second - 1. Delete the third container: + 1. 3 つ目のコンテナを削除します。 incus delete third - Since this container is running, you get an error message that you must stop it first. - Alternatively, you can force-delete it: + このコンテナはまだ実行中なので、最初に停止しないとエラーメッセージが出るでしょう。その代わりに、強制的に削除できます。 incus delete third --force -See {ref}`instances-create` and {ref}`instances-manage` for more information. +詳細は{ref}`instances-create`と{ref}`instances-manage`を参照してください。 -## Configure instances +## インスタンスの設定 -There are several limits and configuration options that you can set for your instances. -See {ref}`instance-options` for an overview. +インスタンスに設定できる制限や設定オプションがいくつか存在します。その概要については{ref}`instance-options`を参照してください。 -Let's create another container with some resource limits: +リソース制限を持つインスタンスを 1 つ作ってみましょう。 -1. Launch a container and limit it to one vCPU and 192 MiB of RAM: +1. コンテナを起動し、1vCPU と 192MiB メモリーの制限を設定します。 incus launch images:ubuntu/22.04 limited --config limits.cpu=1 --config limits.memory=192MiB -1. Check the current configuration and compare it to the configuration of the first (unlimited) container: +1. 現在の設定を確認し、制限が設定されていない最初の（first）コンテナの設定と比べてみましょう。 incus config show limited incus config show first -1. Check the amount of free and used memory on the parent system and on the two containers: +1. 親環境のシステムと 2 つのコンテナで空きメモリーと使用済メモリーの量をチェックしましょう。 free -m incus exec first -- free -m incus exec limited -- free -m ```{note} - The total amount of memory is identical for the parent system and the first container, because by default, the container inherits the resources from its parent environment. - The limited container, on the other hand, has only 192 MiB available. + デフォルトでは、コンテナは親環境からリソースを継承するため、親環境と最初の（first）インスタンスではメモリの総量が同じであることに注意してください。一方で、制限を設定したインスタンスは192MiBだけが使用できます。 ``` -1. Check the number of CPUs available on the parent system and on the two containers: +1. 親環境と 2 つのインスタンスで使用できる CPU の数をチェックしましょう。 nproc incus exec first -- nproc incus exec limited -- nproc ```{note} - Again, the number is identical for the parent system and the first container, but reduced for the limited container. + ふたたび、親環境と最初の（first）インスタンスのCPU数は同じで、制限を設定したインスタンスでは減少していることに注意してください。 ``` -1. You can also update the configuration while your container is running: +1. 実行中のインスタンスの設定を更新することもできます。 - 1. Configure a memory limit for your container: + 1. インスタンスのメモリー制限を設定する。 incus config set limited limits.memory=128MiB - 1. Check that the configuration has been applied: + 1. 適用した設定をチェックする。 incus config show limited - 1. Check the amount of memory that is available to the container: + 1. コンテナで使用できるメモリー量をチェックする。 incus exec limited -- free -m - Note that the number has changed. + 数値が変わっていることを確認してください。 -1. Depending on the instance type and the storage drivers that you use, there are more configuration options that you can specify. - For example, you can configure the size of the root disk device for a VM: +1. 使用するインスタンスタイプとストレージドライバーによっては、より多くの設定を指定できます。 + たとえば、仮想マシンの root ディスクデバイスのサイズを指定できます。 - 1. Check the current size of the root disk device of the Ubuntu VM: + 1. Ubuntu 仮想マシンの root ディスクデバイスの現在のサイズをチェックします。 ```{terminal} :input: incus exec ubuntu-vm -- df -h @@ -190,15 +187,15 @@ Let's create another container with some resource limits: /dev/sda15 105M 6.1M 99M 6% /boot/efi ``` - 1. Override the size of the root disk device: + 1. root ディスクデバイスのサイズを上書きします。 incus config device override ubuntu-vm root size=30GiB - 1. Restart the VM: + 1. 仮想マシンを再起動します。 incus restart ubuntu-vm - 1. Check the size of the root disk device again: + 1. ふたたび、root ディスクデバイスのサイズをチェックします。 ```{terminal} :input: incus exec ubuntu-vm -- df -h @@ -212,51 +209,51 @@ Let's create another container with some resource limits: /dev/sda15 105M 6.1M 99M 6% /boot/efi ``` -See {ref}`instances-configure` and {ref}`instance-config` for more information. +より詳細な情報は`instances-configure`と{ref}`instance-config`を参照してください。 -## Interact with instances +## インスタンスの操作 -You can interact with your instances by running commands in them (including an interactive shell) or accessing the files in the instance. +インスタンス内で（インタラクティブなシェルを含む）コマンドを実行したりインスタンス内のファイルにアクセスできます。 -Start by launching an interactive shell in your instance: +まずインスタンス内でインタラクティブなシェルを起動しましょう。 -1. Run the `bash` command in your container: +1. コンテナ内で`bash`コマンドを実行します。 incus exec first -- bash -1. Enter some commands, for example, display information about the operating system: +1. たとえば以下のコマンドを入力するとオペレーティングシステムについての情報が表示されます。 cat /etc/*release -1. Exit the interactive shell: +1. インタラクティブなシェルを抜けます。 exit -Instead of logging on to the instance and running commands there, you can run commands directly from the host. +インスタンスにログインしてコマンドを実行する代わりに、ホストから直接コマンドを実行できます。 -For example, you can install a command line tool on the instance and run it: +たとえば、コンテナ上にコマンドラインツールをインストールし、それを実行できます。 incus exec first -- apt-get update incus exec first -- apt-get install sl -y incus exec first -- /usr/games/sl -See {ref}`run-commands` for more information. +詳細は{ref}`run-commands`を参照してください。 -You can also access the files from your instance and interact with them: +インスタンスのファイルにアクセスしたり、ファイルを操作できます。 -1. Pull a file from the container: +1. インスタンスからファイルを取得します。 incus file pull first/etc/hosts . -1. Add an entry to the file: +1. ファイルにエントリーを追加します。 echo "1.2.3.4 my-example" >> hosts -1. Push the file back to the container: +1. インスタンスにファイルを戻します。 incus file push hosts first/etc/hosts -1. Use the same mechanism to access log files: +1. ログファイルにアクセスするために同じメカニズムを使います。 incus file pull first/var/log/syslog - | less @@ -264,49 +261,49 @@ You can also access the files from your instance and interact with them: Press `q` to exit the `less` command. ``` -See {ref}`instances-access-files` for more information. +詳細は{ref}`instances-access-files`を参照してください。 -## Manage snapshots +## スナップショットの管理 -You can create a snapshot of your instance, which makes it easy to restore the instance to a previous state. +インスタンスのスナップショットを作成したり、スナップショットからリストアしたりできます。 -1. Create a snapshot called "clean": +1. "clean"という名前のスナップショットを作ります。 incus snapshot create first clean -1. Confirm that the snapshot has been created: +1. スナップショットが作られたことを確認します。 incus list first incus info first ```{note} - `incus list` shows the number of snapshots. - `incus info` displays information about each snapshot. + `incus list`はスナップショットの数を表示します。 + `incus info`はそれぞれのスナップショットについての情報を表示します。 ``` -1. Break the container: +1. コンテナを破壊します。 incus exec first -- rm /usr/bin/bash -1. Confirm the breakage: +1. 壊れたことを確認します。 incus exec first -- bash ```{note} - You do not get a shell, because you deleted the `bash` command. + `bash`コマンドを削除したので、シェルが実行できないことに注意してください。 ``` -1. Restore the container to the state of the snapshot: +1. スナップショットの状態にインスタンスをリストアします。 incus snapshot restore first clean -1. Confirm that everything is back to normal: +1. すべて通常状態に戻ったことを確認します。 incus exec first -- bash exit -1. Delete the snapshot: +1. スナップショットを削除します。 incus delete first/clean -See {ref}`instances-snapshots` for more information. +詳細は{ref}`instances-snapshots`を参照してください。 diff --git a/doc/userns-idmap.md b/doc/userns-idmap.md index 5d90409a690..d6cc04205b9 100644 --- a/doc/userns-idmap.md +++ b/doc/userns-idmap.md @@ -1,92 +1,93 @@ -# Idmaps for user namespace +# User Namespace 用の ID のマッピング -Incus runs safe containers. This is achieved mostly through the use of -user namespaces which make it possible to run containers unprivileged, -greatly limiting the attack surface. +Incus は安全なコンテナを実行します。これは主に User Namespace の使用 +によって実現されています。User Namespace はコンテナを非特権で実行 +することを可能にし、攻撃対象を大幅に限定します。 -User namespaces work by mapping a set of UIDs and GIDs on the host to a -set of UIDs and GIDs in the container. +User Namespace はコンテナの UID と GID の組をホストの UID と +GID の組にマッピングすることで機能します。 -For example, we can define that the host UIDs and GIDs from 100000 to -165535 may be used by Incus and should be mapped to UID/GID 0 through -65535 in the container. +たとえば、 100000 から 165535 までのホストの UID と GID を Incus が使用できる +ようにし、コンテナで 0 から 65535 までの UID/GID にマッピングするように +設定できます。 -As a result a process running as UID 0 in the container will actually be -running as UID 100000. +この結果、コンテナ内で 0 の UID で動くプロセスが実際には UID 100000 で動く +ことになります。 -Allocations should always be of at least 65536 UIDs and GIDs to cover -the POSIX range including root (0) and nobody (65534). +root（0）と nobody（65534）の POSIX の範囲をカバーするため、割当は必ず +最低 65535 個の UID と GID であるべきです。 -## Kernel support +## カーネルのサポート -User namespaces require a kernel >= 3.12, Incus will start even on older -kernels but will refuse to start containers. +User Namespace の使用にはカーネル 3.12 以上が必要です。 Incus は +古いカーネルでも起動しますが、コンテナを起動するのは拒否します。 -## Allowed ranges +## 使用可能な範囲 -On most hosts, Incus will check `/etc/subuid` and `/etc/subgid` for -allocations for the `incus` user and on first start, set the default -profile to use the first 65536 UIDs and GIDs from that range. +ほとんどのホストでは、 Incus は初回起動時に `lxd` ユーザーの割当のために +`/etc/subuid` と `/etc/subgid` をチェックし、そこで指定されている範囲の +最初の 65536 個の UID と GID をデフォルト・プロファイルで使用するように +設定します。 -If the range is shorter than 65536 (which includes no range at all), -then Incus will fail to create or start any container until this is corrected. +範囲が 65536 より小さい場合（範囲が全く無い場合を含む）、これが修正される +まで Incus はコンテナの作成と起動に失敗します。 -If some but not all of `/etc/subuid`, `/etc/subgid`, `newuidmap` (path lookup) -and `newgidmap` (path lookup) can be found on the system, Incus will fail -the startup of any container until this is corrected as this shows a -broken shadow setup. +`/etc/subuid` 、 `/etc/subgid` 、 `newuidmap`（パスを検索）、 `newgidmap` +（パスを検索）のいくつか（ただし全部ではない）がシステムに存在する場合、 +これは shadow の設定が間違っていることを示しているので、これが修正されるまで +Incus はコンテナの起動に失敗します。 -If none of those files can be found, then Incus will assume a 1000000000 -UID/GID range starting at a base UID/GID of 1000000. +これらのファイルが 1 つも無い場合、 Incus は 1000000 の基点の UID/GID から開始する +1000000000 の UID/GID の範囲を想定します。 -This is the most common case and is usually the recommended setup when -not running on a system which also hosts fully unprivileged containers -(where the container runtime itself runs as a user). +これは最もよくあるケースであり、完全に非特権なコンテナをホストするシステム上で稼働するのではない場合 +（コンテナランタイム自身はユーザー権限で実行するような場合）に、通常は推奨される設定です。 -## Varying ranges between hosts +## ホスト間で異なる範囲の使用 -The source map is sent when moving containers between hosts so that they -can be remapped on the receiving host. +ホスト間でコンテナを移動する時、送信側のマッピングが送られるので、受信側の +ホストで異なる範囲にマッピング可能です。 -## Different idmaps per container +## コンテナ毎に異なる ID マッピング -Incus supports using different idmaps per container, to further isolate -containers from each other. This is controlled with two per-container -configuration keys, `security.idmap.isolated` and `security.idmap.size`. +コンテナを他のコンテナからより一層隔離するために、 Incus はコンテナ毎に +異なる ID マッピングを使用することをサポートしています。これはコンテナ毎に +`security.idmap.isolated` と `security.idmap.size` という 2 つの設定項目で +制御できます。 -Containers with `security.idmap.isolated` will have a unique ID range computed -for them among the other containers with `security.idmap.isolated` set (if none -is available, setting this key will simply fail). +`security.idmap.isolated` が設定されたコンテナは +`security.idmap.isolated` が設定された他のコンテナと衝突しないユニークな +ID の範囲を持つように設定されます (もしそのようなコンテナが 1 つも存在しない場合、 +このキーを設定しようとしても失敗します)。 -Containers with `security.idmap.size` set will have their ID range set to this -size. Isolated containers without this property set default to a ID range of -size 65536; this allows for POSIX compliance and a `nobody` user inside the -container. +`security.idmap.size` が設定されたコンテナはこのサイズに ID の範囲が設定 +されます。このプロパティが設定されていない隔離されたコンテナは ID の範囲が +デフォルトのサイズ 65536 に設定されます。これにより POSIX に準拠し、コンテナ内で +`nobody` ユーザーが使用できます。 -To select a specific map, the `security.idmap.base` key will let you -override the auto-detection mechanism and tell Incus what host UID/GID you -want to use as the base for the container. +特定のマッピングを選択するには `security.idmap.base` を設定すると +自動検出機構をオーバーライドし、コンテナでベースとして使用したい +ホストの UID/GID を Incus に伝えることができます。 -These properties require a container reboot to take effect. +これらのプロパティを反映するにはコンテナの再起動が必要です。 -## Custom idmaps +## カスタムの ID マッピング -Incus also supports customizing bits of the idmap, e.g. to allow users to bind -mount parts of the host's file system into a container without the need for any -UID-shifting file system. The per-container configuration key for this is -`raw.idmap`, and looks like: +さらに Incus は ID マッピングの一部をカスタマイズすることをサポートします。たとえば、 +UID を変更するファイルシステムを必要とせずに、ホストのファイルシステムの一部を +コンテナにバインドマウントすることをユーザーに許可できます。このためのコンテナ毎の +設定項目は `raw.idmap` で、設定例は以下のようになります: both 1000 1000 uid 50-60 500-510 gid 100000-110000 10000-20000 -The first line configures both the UID and GID 1000 on the host to map to UID -1000 inside the container (this can be used for example to bind mount a user's -home directory into a container). +1 行目は、ホストの UID と GID 1000 の両方をコンテナ内の UID 1000 にマッピング +する設定です（これはたとえばユーザーのホームディレクトリーをコンテナ内にバインドマウント +するのに使用できます）。 -The second and third lines map only the UID or GID ranges into the container, -respectively. The second entry per line is the source ID, i.e. the ID on the -host, and the third entry is the range inside the container. These ranges must -be the same size. +2 行目と 3 行目は UID または GID のどちらかだけをコンテナ内にマッピングする設定 +です。行の中の 2 番目のエントリーはソース ID 、 つまりホスト上の ID で、 3 番目の +エントリーはコンテナ内部での範囲です。これらの範囲は同じサイズでなければなりません。 -This property requires a container reboot to take effect. +このプロパティを反映するにはコンテナの再起動が必要です。 diff --git a/go.mod b/go.mod index 56389eb5daa..f6c6c1c36a2 100644 --- a/go.mod +++ b/go.mod @@ -17,7 +17,7 @@ require ( github.com/gorilla/mux v1.8.0 github.com/gorilla/websocket v1.5.0 github.com/gosexy/gettext v0.0.0-20160830220431-74466a0a0c4a - github.com/grafana/dskit v0.0.0-20230926170531-d986a37b92ce + github.com/grafana/dskit v0.0.0-20231016121146-cf359dae3636 github.com/j-keck/arping v1.0.3 github.com/jaypipes/pcidb v1.0.0 github.com/jochenvg/go-udev v0.0.0-20171110120927-d6b62d56d37b @@ -44,24 +44,23 @@ require ( github.com/syndtr/gocapability v0.0.0-20200815063812-42c35b437635 github.com/vishvananda/netlink v1.2.1-beta.2 github.com/zitadel/oidc/v2 v2.11.0 - go.starlark.net v0.0.0-20230925163745-10651d5192ab - golang.org/x/crypto v0.13.0 - golang.org/x/oauth2 v0.12.0 - golang.org/x/sync v0.3.0 - golang.org/x/sys v0.12.0 - golang.org/x/term v0.12.0 + go.starlark.net v0.0.0-20231016134836-22325403fcb3 + golang.org/x/crypto v0.14.0 + golang.org/x/oauth2 v0.13.0 + golang.org/x/sync v0.4.0 + golang.org/x/sys v0.13.0 + golang.org/x/term v0.13.0 golang.org/x/text v0.13.0 google.golang.org/protobuf v1.31.0 gopkg.in/tomb.v2 v2.0.0-20161208151619-d5d1b5820637 gopkg.in/yaml.v2 v2.4.0 - gopkg.in/yaml.v3 v3.0.1 k8s.io/utils v0.0.0-20230726121419-3b25d923346b ) require ( github.com/cenkalti/backoff/v4 v4.2.1 // indirect - github.com/cpuguy83/go-md2man/v2 v2.0.2 // indirect - github.com/davecgh/go-spew v1.1.1 // indirect + github.com/cpuguy83/go-md2man/v2 v2.0.3 // indirect + github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc // indirect github.com/dgryski/go-farm v0.0.0-20200201041132-a6ae2369ad13 // indirect github.com/digitalocean/go-libvirt v0.0.0-20221205150000-2939327a8519 // indirect github.com/dustin/go-humanize v1.0.1 // indirect @@ -82,10 +81,10 @@ require ( github.com/jkeiser/iter v0.0.0-20200628201005-c8aa0ae784d1 // indirect github.com/json-iterator/go v1.1.12 // indirect github.com/k-sone/critbitgo v1.4.0 // indirect - github.com/klauspost/compress v1.17.0 // indirect + github.com/klauspost/compress v1.17.1 // indirect github.com/klauspost/cpuid/v2 v2.2.5 // indirect github.com/kr/fs v0.1.0 // indirect - github.com/lufia/plan9stats v0.0.0-20230326075908-cb1d2100619a // indirect + github.com/lufia/plan9stats v0.0.0-20231016141302-07b5767bb0ed // indirect github.com/magiconair/properties v1.8.7 // indirect github.com/mattn/go-isatty v0.0.19 // indirect github.com/mattn/go-runewidth v0.0.15 // indirect @@ -107,14 +106,16 @@ require ( github.com/rs/cors v1.10.1 // indirect github.com/rs/xid v1.5.0 // indirect github.com/russross/blackfriday/v2 v2.1.0 // indirect + github.com/sagikazarmark/locafero v0.3.0 // indirect + github.com/sagikazarmark/slog-shim v0.1.0 // indirect github.com/secure-io/sio-go v0.3.1 // indirect github.com/shirou/gopsutil/v3 v3.23.9 // indirect github.com/shoenig/go-m1cpu v0.1.6 // indirect + github.com/sourcegraph/conc v0.3.0 // indirect github.com/spf13/afero v1.10.0 // indirect github.com/spf13/cast v1.5.1 // indirect - github.com/spf13/jwalterweatherman v1.1.0 // indirect github.com/spf13/pflag v1.0.5 // indirect - github.com/spf13/viper v1.16.0 // indirect + github.com/spf13/viper v1.17.0 // indirect github.com/subosito/gotenv v1.6.0 // indirect github.com/tinylib/msgp v1.1.8 // indirect github.com/tklauser/go-sysconf v0.3.12 // indirect @@ -124,12 +125,15 @@ require ( go.opentelemetry.io/otel v1.19.0 // indirect go.opentelemetry.io/otel/metric v1.19.0 // indirect go.opentelemetry.io/otel/trace v1.19.0 // indirect - golang.org/x/mod v0.12.0 // indirect - golang.org/x/net v0.15.0 // indirect - golang.org/x/tools v0.13.0 // indirect + go.uber.org/multierr v1.11.0 // indirect + golang.org/x/exp v0.0.0-20231006140011-7918f672742d // indirect + golang.org/x/mod v0.13.0 // indirect + golang.org/x/net v0.17.0 // indirect + golang.org/x/tools v0.14.0 // indirect google.golang.org/appengine v1.6.8 // indirect - google.golang.org/genproto/googleapis/rpc v0.0.0-20231002174617-0333e04122ae // indirect - google.golang.org/grpc v1.58.2 // indirect + google.golang.org/genproto/googleapis/rpc v0.0.0-20231016165738-49dd2c1f3d0b // indirect + google.golang.org/grpc v1.58.3 // indirect gopkg.in/ini.v1 v1.67.0 // indirect gopkg.in/square/go-jose.v2 v2.6.0 // indirect + gopkg.in/yaml.v3 v3.0.1 // indirect ) diff --git a/go.sum b/go.sum index db410e7e5cf..607adc56e3d 100644 --- a/go.sum +++ b/go.sum @@ -70,11 +70,13 @@ github.com/coreos/go-systemd/v22 v22.3.2/go.mod h1:Y58oyj3AT4RCenI/lSvhwexgC+NSV github.com/cowsql/go-cowsql v1.22.0 h1:NOMuu3RWkkbKtQ3V+ny9ksR4q3a/h4jU54CbY1BEMBM= github.com/cowsql/go-cowsql v1.22.0/go.mod h1:+QzPcM7QRPIBI8XhsKJ47iUtxGY53lsYGX51G1WQ/4s= github.com/cpuguy83/go-md2man/v2 v2.0.0/go.mod h1:maD7wRr/U5Z6m/iR4s+kqSMx2CaBsrgA7czyZG/E6dU= -github.com/cpuguy83/go-md2man/v2 v2.0.2 h1:p1EgwI/C7NhT0JmVkwCD2ZBK8j4aeHQX2pMHHBfMQ6w= github.com/cpuguy83/go-md2man/v2 v2.0.2/go.mod h1:tgQtvFlXSQOSOSIRvRPT7W67SCa46tRHOmNcaadrF8o= +github.com/cpuguy83/go-md2man/v2 v2.0.3 h1:qMCsGGgs+MAzDFyp9LpAe1Lqy/fY/qCovCm0qnXZOBM= +github.com/cpuguy83/go-md2man/v2 v2.0.3/go.mod h1:tgQtvFlXSQOSOSIRvRPT7W67SCa46tRHOmNcaadrF8o= github.com/davecgh/go-spew v1.1.0/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= -github.com/davecgh/go-spew v1.1.1 h1:vj9j/u1bqnvCEfJOwUhtlOARqs3+rkHYY13jYWTU97c= github.com/davecgh/go-spew v1.1.1/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= +github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc h1:U9qPSI2PIWSS1VwoXQT9A3Wy9MM3WgvqSxFWenqJduM= +github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc/go.mod h1:J7Y8YcW2NihsgmVo/mv3lAwl/skON4iLHjSsI+c5H38= github.com/dgryski/go-farm v0.0.0-20200201041132-a6ae2369ad13 h1:fAjc9m62+UWV/WAFKLNi6ZS0675eEUC9y3AlwSbQu1Y= github.com/dgryski/go-farm v0.0.0-20200201041132-a6ae2369ad13/go.mod h1:SqUrOPUnsFjfmXRMNPybcSiG0BgUW2AuFH8PAnS2iTw= github.com/digitalocean/go-libvirt v0.0.0-20221205150000-2939327a8519 h1:OpkN/n40cmKenDQS+IOAeW9DLhYy4DADSeZnouCEV/E= @@ -172,8 +174,9 @@ github.com/google/go-cmp v0.5.3/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/ github.com/google/go-cmp v0.5.4/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= github.com/google/go-cmp v0.5.5/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= github.com/google/go-cmp v0.5.6/go.mod h1:v8dTdLbMG2kIc/vJvl+f65V22dbkXbowE6jgT/gNBxE= -github.com/google/go-cmp v0.5.9 h1:O2Tfq5qg4qc4AmwVlvv0oLiVAGB7enBSJ2x2DqQFi38= github.com/google/go-cmp v0.5.9/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY= +github.com/google/go-cmp v0.6.0 h1:ofyhxvXcZhMsU5ulbFiLKl/XBFqE1GSq7atu8tAmTRI= +github.com/google/go-cmp v0.6.0/go.mod h1:17dUlkBOakJ0+DkrSSNjCkIjxS6bF9zb3elmeNGIjoY= github.com/google/gofuzz v1.0.0/go.mod h1:dBl0BpW6vV/+mYPU4Po3pmUjxk6FQPldtuIdl/M65Eg= github.com/google/gopacket v1.1.19 h1:ves8RnFZPGiFnTS0uPQStjwru6uO6h+nlr9j6fL7kF8= github.com/google/gopacket v1.1.19/go.mod h1:iJ8V8n6KS+z2U1A8pUwu8bW5SyEMkXJB8Yo/Vo+TKTo= @@ -213,8 +216,8 @@ github.com/gorilla/websocket v1.5.0 h1:PPwGk2jz7EePpoHN/+ClbZu8SPxiqlu12wZP/3sWm github.com/gorilla/websocket v1.5.0/go.mod h1:YR8l580nyteQvAITg2hZ9XVh4b55+EU/adAjf1fMHhE= github.com/gosexy/gettext v0.0.0-20160830220431-74466a0a0c4a h1:N2b2mb4Gki1SlF3WuhR9P1YHOpl7oy/b+xxX4A3iM2E= github.com/gosexy/gettext v0.0.0-20160830220431-74466a0a0c4a/go.mod h1:IEJaV4/6J0VpoQ33kFCUUP6umRjrcBVEbOva6XCub/Q= -github.com/grafana/dskit v0.0.0-20230926170531-d986a37b92ce h1:/11h7vYHcY+epGTAgTp/mUbsTfSJJs0MsdJJOPtJV5w= -github.com/grafana/dskit v0.0.0-20230926170531-d986a37b92ce/go.mod h1:byPCvaG/pqi33Kq+Wvkp7WhLfmrlyy0RAoYG4yRh01I= +github.com/grafana/dskit v0.0.0-20231016121146-cf359dae3636 h1:b2x8B0/mmPVQBmV5pHNKoGNhUGVj/V3FEIli+sKUXsc= +github.com/grafana/dskit v0.0.0-20231016121146-cf359dae3636/go.mod h1:byPCvaG/pqi33Kq+Wvkp7WhLfmrlyy0RAoYG4yRh01I= github.com/grpc-ecosystem/grpc-gateway v1.16.0/go.mod h1:BDjrQk3hbvj6Nolgz8mAMFbcEtjT1g+wF4CSlocrBnw= github.com/hashicorp/consul/api v1.1.0/go.mod h1:VmuI/Lkw1nC05EYQWNKwWGbkg+FbDBtguAZLlVdkD9Q= github.com/hashicorp/consul/sdk v0.1.1/go.mod h1:VKf9jXwCTEY1QZP2MOLRhb5i/I/ssyNV1vwHyQBF0x8= @@ -263,8 +266,8 @@ github.com/kballard/go-shellquote v0.0.0-20180428030007-95032a82bc51 h1:Z9n2FFNU github.com/kballard/go-shellquote v0.0.0-20180428030007-95032a82bc51/go.mod h1:CzGEWj7cYgsdH8dAjBGEr58BoE7ScuLd+fwFZ44+/x8= github.com/kisielk/errcheck v1.5.0/go.mod h1:pFxgyoBC7bSaBwPgfKdkLd5X25qrDl4LWUI2bnpBCr8= github.com/kisielk/gotool v1.0.0/go.mod h1:XhKaO+MFFWcvkIS/tQcRk01m1F5IRFswLeQ+oQHNcck= -github.com/klauspost/compress v1.17.0 h1:Rnbp4K9EjcDuVuHtd0dgA4qNuv9yKDYKK1ulpJwgrqM= -github.com/klauspost/compress v1.17.0/go.mod h1:ntbaceVETuRiXiv4DpjP66DpAtAGkEQskQzEyD//IeE= +github.com/klauspost/compress v1.17.1 h1:NE3C767s2ak2bweCZo3+rdP4U/HoyVXLv/X9f2gPS5g= +github.com/klauspost/compress v1.17.1/go.mod h1:ntbaceVETuRiXiv4DpjP66DpAtAGkEQskQzEyD//IeE= github.com/klauspost/cpuid/v2 v2.0.1/go.mod h1:FInQzS24/EEf25PyTYn52gqo7WaD8xa0213Md/qVLRg= github.com/klauspost/cpuid/v2 v2.2.5 h1:0E5MSMDEoAulmXNFquVs//DdoomxaoTY1kUhbc/qbZg= github.com/klauspost/cpuid/v2 v2.2.5/go.mod h1:Lcz8mBdAVJIBVzewtcLocK12l3Y+JytZYpaMropDUws= @@ -276,8 +279,8 @@ github.com/kr/pty v1.1.1/go.mod h1:pFQYn66WHrOpPYNljwOMqo10TkYh1fy3cYio2l3bCsQ= github.com/kr/text v0.1.0/go.mod h1:4Jbv+DJW3UT/LiOwJeYQe1efqtUx/iVham/4vfdArNI= github.com/kr/text v0.2.0 h1:5Nx0Ya0ZqY2ygV366QzturHI13Jq95ApcVaJBhpS+AY= github.com/lufia/plan9stats v0.0.0-20211012122336-39d0f177ccd0/go.mod h1:zJYVVT2jmtg6P3p1VtQj7WsuWi/y4VnjVBn7F8KPB3I= -github.com/lufia/plan9stats v0.0.0-20230326075908-cb1d2100619a h1:N9zuLhTvBSRt0gWSiJswwQ2HqDmtX/ZCDJURnKUt1Ik= -github.com/lufia/plan9stats v0.0.0-20230326075908-cb1d2100619a/go.mod h1:JKx41uQRwqlTZabZc+kILPrO/3jlKnQ2Z8b7YiVw5cE= +github.com/lufia/plan9stats v0.0.0-20231016141302-07b5767bb0ed h1:036IscGBfJsFIgJQzlui7nK1Ncm0tp2ktmPj8xO4N/0= +github.com/lufia/plan9stats v0.0.0-20231016141302-07b5767bb0ed/go.mod h1:ilwx/Dta8jXAgpFYFvSWEMwxmbWXyiUHkd5FwyKhb5k= github.com/lxc/go-lxc v0.0.0-20230926171149-ccae595aa49e h1:qM376kOMJIIDi5yqcxMzezaA2O+lLybIDSL4o1AEHLI= github.com/lxc/go-lxc v0.0.0-20230926171149-ccae595aa49e/go.mod h1:d7gwEiQlW13OqE5UDJp2JJO78aTiSabSC/jUiVRZSes= github.com/magiconair/properties v1.8.5/go.mod h1:y3VJvCyxH9uVvJTWEGAELF3aiYNyPKd5NZ3oSwXrF60= @@ -390,6 +393,10 @@ github.com/russross/blackfriday/v2 v2.0.1/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQD github.com/russross/blackfriday/v2 v2.1.0 h1:JIOH55/0cWyOuilr9/qlrm0BSXldqnqwMsf35Ld67mk= github.com/russross/blackfriday/v2 v2.1.0/go.mod h1:+Rmxgy9KzJVeS9/2gXHxylqXiyQDYRxCVz55jmeOWTM= github.com/ryanuber/columnize v0.0.0-20160712163229-9b3edd62028f/go.mod h1:sm1tb6uqfes/u+d4ooFouqFdy9/2g9QGwK3SQygK0Ts= +github.com/sagikazarmark/locafero v0.3.0 h1:zT7VEGWC2DTflmccN/5T1etyKvxSxpHsjb9cJvm4SvQ= +github.com/sagikazarmark/locafero v0.3.0/go.mod h1:w+v7UsPNFwzF1cHuOajOOzoq4U7v/ig1mpRjqV+Bu1U= +github.com/sagikazarmark/slog-shim v0.1.0 h1:diDBnUNK9N/354PgrxMywXnAwEr1QZcOr6gto+ugjYE= +github.com/sagikazarmark/slog-shim v0.1.0/go.mod h1:SrcSrq8aKtyuqEI1uvTDTK1arOWRIczQRv+GVI1AkeQ= github.com/sean-/seed v0.0.0-20170313163322-e2103e2c3529/go.mod h1:DxrIzT+xaE7yg65j358z/aeFdxmN0P9QXhEzd20vsDc= github.com/secure-io/sio-go v0.3.1 h1:dNvY9awjabXTYGsTF1PiCySl9Ltofk9GA3VdWlo7rRc= github.com/secure-io/sio-go v0.3.1/go.mod h1:+xbkjDzPjwh4Axd07pRKSNriS9SCiYksWnZqdnfpQxs= @@ -404,6 +411,8 @@ github.com/sirupsen/logrus v1.9.3 h1:dueUQJ1C2q9oE3F7wvmSGAaVtTmUizReu6fjN8uqzbQ github.com/sirupsen/logrus v1.9.3/go.mod h1:naHLuLoDiP4jHNo9R0sCBMtWGeIprob74mVsIT4qYEQ= github.com/smartystreets/assertions v0.0.0-20180927180507-b2de0cb4f26d/go.mod h1:OnSkiWE9lh6wB0YB77sQom3nweQdgAjqCqsofrRNTgc= github.com/smartystreets/goconvey v1.6.4/go.mod h1:syvi0/a8iFYH4r/RixwvyeAJjdLS9QV7WQ/tjFTllLA= +github.com/sourcegraph/conc v0.3.0 h1:OQTbbt6P72L20UqAkXXuLOj79LfEanQ+YQFNpLA9ySo= +github.com/sourcegraph/conc v0.3.0/go.mod h1:Sdozi7LEKbFPqYX2/J+iBAM6HpqSLTASQIKqDmF7Mt0= github.com/spf13/afero v1.6.0/go.mod h1:Ai8FlHk4v/PARR026UzYexafAt9roJ7LcLMAmO6Z93I= github.com/spf13/afero v1.10.0 h1:EaGW2JJh15aKOejeuJ+wpFSHnbd7GE6Wvp3TsNhb6LY= github.com/spf13/afero v1.10.0/go.mod h1:UBogFpq8E9Hx+xc5CNTTEpTnuHVmXDwZcZcE1eb/UhQ= @@ -414,13 +423,12 @@ github.com/spf13/cobra v1.2.1/go.mod h1:ExllRjgxM/piMAM+3tAZvg8fsklGAf3tPfi+i8t6 github.com/spf13/cobra v1.5.0/go.mod h1:dWXEIy2H428czQCjInthrTRUg7yKbok+2Qi/yBIJoUM= github.com/spf13/cobra v1.7.0 h1:hyqWnYt1ZQShIddO5kBpj3vu05/++x6tJ6dg8EC572I= github.com/spf13/cobra v1.7.0/go.mod h1:uLxZILRyS/50WlhOIKD7W6V5bgeIt+4sICxh6uRMrb0= -github.com/spf13/jwalterweatherman v1.1.0 h1:ue6voC5bR5F8YxI5S67j9i582FU4Qvo2bmqnqMYADFk= github.com/spf13/jwalterweatherman v1.1.0/go.mod h1:aNWZUN0dPAAO/Ljvb5BEdw96iTZ0EXowPYD95IqWIGo= github.com/spf13/pflag v1.0.5 h1:iy+VFUOCP1a+8yFto/drg2CJ5u0yRoB7fZw3DKv/JXA= github.com/spf13/pflag v1.0.5/go.mod h1:McXfInJRrz4CZXVZOBLb0bTZqETkiAhM9Iw0y3An2Bg= github.com/spf13/viper v1.8.1/go.mod h1:o0Pch8wJ9BVSWGQMbra6iw0oQ5oktSIBaujf1rJH9Ns= -github.com/spf13/viper v1.16.0 h1:rGGH0XDZhdUOryiDWjmIvUSWpbNqisK8Wk0Vyefw8hc= -github.com/spf13/viper v1.16.0/go.mod h1:yg78JgCJcbrQOvV9YLXgkLaZqUidkY9K+Dd1FofRzQg= +github.com/spf13/viper v1.17.0 h1:I5txKw7MJasPL/BrfkbA0Jyo/oELqVmux4pR/UxOMfI= +github.com/spf13/viper v1.17.0/go.mod h1:BmMMMLQXSbcHK6KAOiFLz0l5JHrU89OdIRHvsk0+yVI= github.com/stretchr/objx v0.1.0/go.mod h1:HFkY916IF+rwdDfMAkV7OtwuqBVzrE8GR6GFx+wExME= github.com/stretchr/objx v0.4.0/go.mod h1:YvHI0jy2hoMjB+UWwv71VJQ9isScKT/TqJzVSSt89Yw= github.com/stretchr/objx v0.5.0/go.mod h1:Yh+to48EsGEfYuaHDzXPcE3xhTkx73EhmCGUpEOglKo= @@ -477,10 +485,12 @@ go.opentelemetry.io/otel/metric v1.19.0 h1:aTzpGtV0ar9wlV4Sna9sdJyII5jTVJEvKETPi go.opentelemetry.io/otel/metric v1.19.0/go.mod h1:L5rUsV9kM1IxCj1MmSdS+JQAcVm319EUrDVLrt7jqt8= go.opentelemetry.io/otel/trace v1.19.0 h1:DFVQmlVbfVeOuBRrwdtaehRrWiL1JoVs9CPIQ1Dzxpg= go.opentelemetry.io/otel/trace v1.19.0/go.mod h1:mfaSyvGyEJEI0nyV2I4qhNQnbBOUUmYZpYojqMnX2vo= -go.starlark.net v0.0.0-20230925163745-10651d5192ab h1:7QkXlIVjYdSsKKSGnM0jQdw/2w9W5qcFDGTc00zKqgI= -go.starlark.net v0.0.0-20230925163745-10651d5192ab/go.mod h1:LcLNIzVOMp4oV+uusnpk+VU+SzXaJakUuBjoCSWH5dM= +go.starlark.net v0.0.0-20231016134836-22325403fcb3 h1:CKbpFNZNfaNyEWd6C+F1vLZ0WJjukoU45zDErBmRKPs= +go.starlark.net v0.0.0-20231016134836-22325403fcb3/go.mod h1:LcLNIzVOMp4oV+uusnpk+VU+SzXaJakUuBjoCSWH5dM= go.uber.org/atomic v1.7.0/go.mod h1:fEN4uk6kAWBTFdckzkM89CLk9XfWZrxpCo0nPH17wJc= go.uber.org/multierr v1.6.0/go.mod h1:cdWPpRnG4AhwMwsgIHip0KRBQjJy5kYEpYjJxpXp9iU= +go.uber.org/multierr v1.11.0 h1:blXXJkSxSSfBVBlC76pxqeO+LN3aDfLQo+309xJstO0= +go.uber.org/multierr v1.11.0/go.mod h1:20+QtiLqy0Nd6FdQB9TLXag12DsQkrbs3htMFfDN80Y= go.uber.org/zap v1.17.0/go.mod h1:MXVU+bhUf/A7Xi2HNOnopQOrmycQ5Ih87HtOu4q5SSo= golang.org/x/crypto v0.0.0-20181029021203-45a5f77698d3/go.mod h1:6SG95UA2DQfeDnfUPMdvaQW0Q7yPrPDi9nlGo2tz2b4= golang.org/x/crypto v0.0.0-20190308221718-c2843e01d9a2/go.mod h1:djNgcEr1/C05ACkg1iLfiJU5Ep61QUkGW8qpdssI0+w= @@ -495,8 +505,8 @@ golang.org/x/crypto v0.0.0-20210421170649-83a5a9bb288b/go.mod h1:T9bdIzuCu7OtxOm golang.org/x/crypto v0.0.0-20210921155107-089bfa567519/go.mod h1:GvvjBRRGRdwPK5ydBHafDWAxML/pGHZbMvKqRZ5+Abc= golang.org/x/crypto v0.0.0-20220722155217-630584e8d5aa/go.mod h1:IxCIyHEi3zRg3s0A5j5BB6A9Jmi73HwBIUl50j+osU4= golang.org/x/crypto v0.1.0/go.mod h1:RecgLatLF4+eUMCP1PoPZQb+cVrJcOPbHkTkbkB9sbw= -golang.org/x/crypto v0.13.0 h1:mvySKfSWJ+UKUii46M40LOvyWfN0s2U+46/jDd0e6Ck= -golang.org/x/crypto v0.13.0/go.mod h1:y6Z2r+Rw4iayiXXAIxJIDAJ1zMW4yaTpebo8fPOliYc= +golang.org/x/crypto v0.14.0 h1:wBqGXzWJW6m1XrIKlAH0Hs1JJ7+9KBwnIO8v66Q9cHc= +golang.org/x/crypto v0.14.0/go.mod h1:MVFd36DqK4CsrnJYDkBA3VC4m2GkXAM0PvzMCn4JQf4= golang.org/x/exp v0.0.0-20190121172915-509febef88a4/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= golang.org/x/exp v0.0.0-20190306152737-a1d7652674e8/go.mod h1:CJ0aWSM057203Lf6IL+f9T1iT9GByDxfZKAQTCR3kQA= golang.org/x/exp v0.0.0-20190510132918-efd6b22b2522/go.mod h1:ZjyILWgesfNpC6sMxTJOJm9Kp84zZh5NQWvqDGG3Qr8= @@ -507,6 +517,8 @@ golang.org/x/exp v0.0.0-20191227195350-da58074b4299/go.mod h1:2RIsYlXP63K8oxa1u0 golang.org/x/exp v0.0.0-20200119233911-0405dc783f0a/go.mod h1:2RIsYlXP63K8oxa1u096TMicItID8zy7Y6sNkU49FU4= golang.org/x/exp v0.0.0-20200207192155-f17229e696bd/go.mod h1:J/WKrq2StrnmMY6+EHIKF9dgMWnmCNThgcyBT1FY9mM= golang.org/x/exp v0.0.0-20200224162631-6cc2880d07d6/go.mod h1:3jZMyOhIsHpP37uCMkUooju7aAi5cS1Q23tOzKc+0MU= +golang.org/x/exp v0.0.0-20231006140011-7918f672742d h1:jtJma62tbqLibJ5sFQz8bKtEM8rJBtfilJ2qTU199MI= +golang.org/x/exp v0.0.0-20231006140011-7918f672742d/go.mod h1:ldy0pHrwJyGW56pPQzzkH36rKxoZW1tw7ZJpeKx+hdo= golang.org/x/image v0.0.0-20190227222117-0694c2d4d067/go.mod h1:kZ7UVZpmo3dzQBMxlp+ypCbDeSB+sBbTgSJuh5dn5js= golang.org/x/image v0.0.0-20190802002840-cff245a6509b/go.mod h1:FeLwcggjj3mMvU+oOTbSwawSJRM1uh48EjtB4UJZlP0= golang.org/x/lint v0.0.0-20181026193005-c67002cb31c3/go.mod h1:UVdnD1Gm6xHRNCYTkRU2/jEulfH38KcIWyp/GAMgvoE= @@ -534,8 +546,8 @@ golang.org/x/mod v0.4.1/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA= golang.org/x/mod v0.4.2/go.mod h1:s0Qsj1ACt9ePp/hMypM3fl4fZqREWJwdYDEqhRiZZUA= golang.org/x/mod v0.6.0-dev.0.20220419223038-86c51ed26bb4/go.mod h1:jJ57K6gSWd91VN4djpZkiMVwK6gcyfeH4XE8wZrZaV4= golang.org/x/mod v0.7.0/go.mod h1:iBbtSCu2XBx23ZKBPSOrRkjjQPZFPuis4dIYUhu/chs= -golang.org/x/mod v0.12.0 h1:rmsUpXtvNzj340zd98LZ4KntptpfRHwpFOHG188oHXc= -golang.org/x/mod v0.12.0/go.mod h1:iBbtSCu2XBx23ZKBPSOrRkjjQPZFPuis4dIYUhu/chs= +golang.org/x/mod v0.13.0 h1:I/DsJXRlw/8l/0c24sM9yb0T4z9liZTduXvdAWYiysY= +golang.org/x/mod v0.13.0/go.mod h1:hTbmBsO62+eylJbnUtE2MGJUyE7QWk4xUqPFrRgJ+7c= golang.org/x/net v0.0.0-20180724234803-3673e40ba225/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= golang.org/x/net v0.0.0-20180826012351-8a410e7b638d/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= golang.org/x/net v0.0.0-20181023162649-9b4f9f5ad519/go.mod h1:mL1N/T3taQHkDXs73rZJwtUhF3w3ftmwwsq0BUmARs4= @@ -577,8 +589,8 @@ golang.org/x/net v0.0.0-20211112202133-69e39bad7dc2/go.mod h1:9nx3DQGgdP8bBQD5qx golang.org/x/net v0.0.0-20220722155237-a158d28d115b/go.mod h1:XRhObCWvk6IyKnWLug+ECip1KBveYUHfp+8e9klMJ9c= golang.org/x/net v0.1.0/go.mod h1:Cx3nUiGt4eDBEyega/BKRp+/AlGL8hYe7U9odMt2Cco= golang.org/x/net v0.3.0/go.mod h1:MBQ8lrhLObU/6UmLb4fmbmk5OcyYmqtbGd/9yIeKjEE= -golang.org/x/net v0.15.0 h1:ugBLEUaxABaB5AJqW9enI0ACdci2RUd4eP51NTBvuJ8= -golang.org/x/net v0.15.0/go.mod h1:idbUs1IY1+zTqbi8yxTbhexhEEk5ur9LInksu6HrEpk= +golang.org/x/net v0.17.0 h1:pVaXccu2ozPjCXewfr1S7xza/zcXTity9cCdXQYSjIM= +golang.org/x/net v0.17.0/go.mod h1:NxSsAGuq816PNPmqtQdLE42eU2Fs7NoRIZrHJAlaCOE= golang.org/x/oauth2 v0.0.0-20180821212333-d2e6202438be/go.mod h1:N/0e6XlmueqKjAGxoOufVs8QHGRruUQn6yWY3a++T0U= golang.org/x/oauth2 v0.0.0-20190226205417-e64efc72b421/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= golang.org/x/oauth2 v0.0.0-20190604053449-0f29369cfe45/go.mod h1:gOpvHmFTYa4IltrdGE7lF6nIHvwfUNPOp7c8zoXwtLw= @@ -591,8 +603,8 @@ golang.org/x/oauth2 v0.0.0-20210218202405-ba52d332ba99/go.mod h1:KelEdhl1UZF7XfJ golang.org/x/oauth2 v0.0.0-20210220000619-9bb904979d93/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A= golang.org/x/oauth2 v0.0.0-20210313182246-cd4f82c27b84/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A= golang.org/x/oauth2 v0.0.0-20210402161424-2e8d93401602/go.mod h1:KelEdhl1UZF7XfJ4dDtk6s++YSgaE7mD/BuKKDLBl4A= -golang.org/x/oauth2 v0.12.0 h1:smVPGxink+n1ZI5pkQa8y6fZT0RW0MgCO5bFpepy4B4= -golang.org/x/oauth2 v0.12.0/go.mod h1:A74bZ3aGXgCY0qaIC9Ahg6Lglin4AMAco8cIv9baba4= +golang.org/x/oauth2 v0.13.0 h1:jDDenyj+WgFtmV3zYVoi8aE2BwtXFLWOA67ZfNWftiY= +golang.org/x/oauth2 v0.13.0/go.mod h1:/JMhi4ZRXAf4HG9LiNmxvk+45+96RUlVThiH8FzNBn0= golang.org/x/sync v0.0.0-20180314180146-1d60e4601c6f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.0.0-20181108010431-42b317875d0f/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.0.0-20181221193216-37e7f081c4d4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= @@ -606,8 +618,8 @@ golang.org/x/sync v0.0.0-20201207232520-09787c993a3a/go.mod h1:RxMgew5VJxzue5/jJ golang.org/x/sync v0.0.0-20210220032951-036812b2e83c/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.0.0-20220722155255-886fb9371eb4/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= golang.org/x/sync v0.1.0/go.mod h1:RxMgew5VJxzue5/jJTE5uejpjVlOe/izrB70Jof72aM= -golang.org/x/sync v0.3.0 h1:ftCYgMx6zT/asHUrPw8BLLscYtGznsLAnjq5RH9P66E= -golang.org/x/sync v0.3.0/go.mod h1:FU7BRWz2tNW+3quACPkgCx/L+uEAv1htQ0V83Z9Rj+Y= +golang.org/x/sync v0.4.0 h1:zxkM55ReGkDlKSM+Fu41A+zmbZuaPVbGMzvvdUPznYQ= +golang.org/x/sync v0.4.0/go.mod h1:FU7BRWz2tNW+3quACPkgCx/L+uEAv1htQ0V83Z9Rj+Y= golang.org/x/sys v0.0.0-20180823144017-11551d06cbcc/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= golang.org/x/sys v0.0.0-20180830151530-49385e6e1522/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= golang.org/x/sys v0.0.0-20181026203630-95b1ffbd15a5/go.mod h1:STP8DvDyc/dI5b8T5hshtkjS+E42TnysNCUPdjciGhY= @@ -671,14 +683,15 @@ golang.org/x/sys v0.5.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.6.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.8.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/sys v0.11.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= -golang.org/x/sys v0.12.0 h1:CM0HF96J0hcLAwsHPJZjfdNzs0gftsLfgKt57wWHJ0o= golang.org/x/sys v0.12.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= +golang.org/x/sys v0.13.0 h1:Af8nKPmuFypiUBjVoU9V20FiaFXOcuZI21p0ycVYYGE= +golang.org/x/sys v0.13.0/go.mod h1:oPkhp1MJrh7nUepCBck5+mAzfO9JrbApNNgaTdGDITg= golang.org/x/term v0.0.0-20201126162022-7de9c90e9dd1/go.mod h1:bj7SfCRtBDWHUb9snDiAeCFNEtKQo2Wmx5Cou7ajbmo= golang.org/x/term v0.0.0-20210927222741-03fcf44c2211/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8= golang.org/x/term v0.1.0/go.mod h1:jbD1KX2456YbFQfuXm/mYQcufACuNUgVhRMnK/tPxf8= golang.org/x/term v0.3.0/go.mod h1:q750SLmJuPmVoN1blW3UFBPREJfb1KmY3vwxfr+nFDA= -golang.org/x/term v0.12.0 h1:/ZfYdc3zq+q02Rv9vGqTeSItdzZTSNDmfTi0mBAuidU= -golang.org/x/term v0.12.0/go.mod h1:owVbMEjm3cBLCHdkQu9b1opXd4ETQWc3BhuQGKgXgvU= +golang.org/x/term v0.13.0 h1:bb+I9cTfFazGW51MZqBVmZy7+JEJMouUHTUSKVQLBek= +golang.org/x/term v0.13.0/go.mod h1:LTmsnFJwVN6bCy1rVCoS+qHT1HhALEFxKncY3WNNh4U= golang.org/x/text v0.0.0-20170915032832-14c0d48ead0c/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= golang.org/x/text v0.3.0/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= golang.org/x/text v0.3.1-0.20180807135948-17ff2d5776d2/go.mod h1:NqM8EUOU14njkJ3fqMW+pc6Ldnwhi/IjpwHt7yyuwOQ= @@ -750,8 +763,8 @@ golang.org/x/tools v0.1.0/go.mod h1:xkSsbof2nBLbhDlRMhhhyNLN/zl3eTqcnHD5viDpcZ0= golang.org/x/tools v0.1.2/go.mod h1:o0xws9oXOQQZyjljx8fwUC0k7L1pTE6eaCbjGeHmOkk= golang.org/x/tools v0.1.12/go.mod h1:hNGJHUnrk76NpqgfD5Aqm5Crs+Hm0VOH/i9J2+nxYbc= golang.org/x/tools v0.4.0/go.mod h1:UE5sM2OK9E/d67R0ANs2xJizIymRP5gJU295PvKXxjQ= -golang.org/x/tools v0.13.0 h1:Iey4qkscZuv0VvIt8E0neZjtPVQFSc870HQ448QgEmQ= -golang.org/x/tools v0.13.0/go.mod h1:HvlwmtVNQAhOuCjW7xxvovg8wbNq7LwfXh/k7wXUl58= +golang.org/x/tools v0.14.0 h1:jvNa2pY0M4r62jkRQ6RwEZZyPcymeL9XZMLBbV7U2nc= +golang.org/x/tools v0.14.0/go.mod h1:uYBEerGOWcJyEORxN+Ek8+TT266gXkNlHdJBwexUsBg= golang.org/x/xerrors v0.0.0-20190717185122-a985d3407aa7/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= golang.org/x/xerrors v0.0.0-20191011141410-1b5146add898/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= golang.org/x/xerrors v0.0.0-20191204190536-9bdfabe68543/go.mod h1:I/5z698sn9Ka8TeJc9MKroUUfqBBauWjQqLJ2OPfmY0= @@ -830,8 +843,8 @@ google.golang.org/genproto v0.0.0-20210310155132-4ce2db91004e/go.mod h1:FWY/as6D google.golang.org/genproto v0.0.0-20210319143718-93e7006c17a6/go.mod h1:FWY/as6DDZQgahTzZj3fqbO1CbirC29ZNUFHwi0/+no= google.golang.org/genproto v0.0.0-20210402141018-6c239bbf2bb1/go.mod h1:9lPAdzaEmUacj36I+k7YKbEc5CXzPIeORRgDAUOu28A= google.golang.org/genproto v0.0.0-20210602131652-f16073e35f0c/go.mod h1:UODoCrxHCcBojKKwX1terBiRUaqAsFqJiF615XL43r0= -google.golang.org/genproto/googleapis/rpc v0.0.0-20231002174617-0333e04122ae h1:N1ck9rECP06bx1uA6m1v/j3QV9EBRxoxP7QkYMukucw= -google.golang.org/genproto/googleapis/rpc v0.0.0-20231002174617-0333e04122ae/go.mod h1:v7nGkzlmW8P3n/bKmWBn2WpBjpOEx8Q6gMueudAmKfY= +google.golang.org/genproto/googleapis/rpc v0.0.0-20231016165738-49dd2c1f3d0b h1:ZlWIi1wSK56/8hn4QcBp/j9M7Gt3U/3hZw3mC7vDICo= +google.golang.org/genproto/googleapis/rpc v0.0.0-20231016165738-49dd2c1f3d0b/go.mod h1:swOH3j0KzcDDgGUWr+SNpyTen5YrXjS3eyPzFYKc6lc= google.golang.org/grpc v1.19.0/go.mod h1:mqu4LbDTu4XGKhr4mRzUsmM4RtVoemTSY81AxZiDr8c= google.golang.org/grpc v1.20.1/go.mod h1:10oTOabMzJvdu6/UiuZezV6QK5dSlG84ov/aaiqXj38= google.golang.org/grpc v1.21.1/go.mod h1:oYelfM1adQP15Ek0mdvEgi9Df8B9CZIaU1084ijfRaM= @@ -852,8 +865,8 @@ google.golang.org/grpc v1.35.0/go.mod h1:qjiiYl8FncCW8feJPdyg3v6XW24KsRHe+dy9BAG google.golang.org/grpc v1.36.0/go.mod h1:qjiiYl8FncCW8feJPdyg3v6XW24KsRHe+dy9BAGRRjU= google.golang.org/grpc v1.36.1/go.mod h1:qjiiYl8FncCW8feJPdyg3v6XW24KsRHe+dy9BAGRRjU= google.golang.org/grpc v1.38.0/go.mod h1:NREThFqKR1f3iQ6oBuvc5LadQuXVGo9rkm5ZGrQdJfM= -google.golang.org/grpc v1.58.2 h1:SXUpjxeVF3FKrTYQI4f4KvbGD5u2xccdYdurwowix5I= -google.golang.org/grpc v1.58.2/go.mod h1:tgX3ZQDlNJGU96V6yHh1T/JeoBQ2TXdr43YbYSsCJk0= +google.golang.org/grpc v1.58.3 h1:BjnpXut1btbtgN/6sp+brB2Kbm2LjNXnidYujAVbSoQ= +google.golang.org/grpc v1.58.3/go.mod h1:tgX3ZQDlNJGU96V6yHh1T/JeoBQ2TXdr43YbYSsCJk0= google.golang.org/protobuf v0.0.0-20200109180630-ec00e32a8dfd/go.mod h1:DFci5gLYBciE7Vtevhsrf46CRTquxDuWsQurQQe4oz8= google.golang.org/protobuf v0.0.0-20200221191635-4d8936d0db64/go.mod h1:kwYJMbMJ01Woi6D6+Kah6886xMZcty6N08ah7+eCXa0= google.golang.org/protobuf v0.0.0-20200228230310-ab0ca4ff8a60/go.mod h1:cfTl7dwQJ+fmap5saPgwCLgHXTUD7jkjRqWcaiX5VyM= diff --git a/internal/linux/poll.go b/internal/linux/poll.go new file mode 100644 index 00000000000..11d05f538e1 --- /dev/null +++ b/internal/linux/poll.go @@ -0,0 +1,114 @@ +package linux + +import ( + "context" + "fmt" + "io" + "os" + + "golang.org/x/sys/unix" +) + +// GetPollRevents poll for events on provided fd. +func GetPollRevents(fd int, timeout int, flags int) (int, int, error) { + pollFd := unix.PollFd{ + Fd: int32(fd), + Events: int16(flags), + Revents: 0, + } + + pollFds := []unix.PollFd{pollFd} + +again: + n, err := unix.Poll(pollFds, timeout) + if err != nil { + if err == unix.EAGAIN || err == unix.EINTR { + goto again + } + + return -1, -1, err + } + + return n, int(pollFds[0].Revents), err +} + +// NewExecWrapper returns a new ReadWriteCloser wrapper for an os.File. +// The ctx is used to indicate when the executed process has ended, at which point any further Read calls will +// return io.EOF rather than potentially blocking on the poll syscall if the process is a shell that still has +// background processes running that are not producing any output. +func NewExecWrapper(ctx context.Context, f *os.File) io.ReadWriteCloser { + return &execWrapper{ + ctx: ctx, + f: f, + } +} + +// execWrapper implements a ReadWriteCloser wrapper for an os.File connected to a PTY. +type execWrapper struct { + f *os.File + ctx context.Context + hangup bool +} + +// Read uses the poll syscall with a timeout of 1s to check if there is any data to read. +// This avoids potentially blocking in the poll syscall in situations where the process is a shell that has +// background processes that are not producing any output. +// If the ctx has been cancelled before the poll starts then io.EOF error is returned. +func (w *execWrapper) Read(p []byte) (int, error) { + rawConn, err := w.f.SyscallConn() + if err != nil { + return 0, err + } + + var opErr error + var n int + err = rawConn.Read(func(fd uintptr) bool { + for { + // Call poll() with 1s timeout, this prevents blocking if a shell process exits leaving + // background processes running that are not outputting anything. + _, revents, err := GetPollRevents(int(fd), 1000, (unix.POLLIN | unix.POLLPRI | unix.POLLERR | unix.POLLNVAL | unix.POLLHUP | unix.POLLRDHUP)) + + if revents&(unix.POLLHUP|unix.POLLRDHUP) > 0 { + w.hangup = true // Record a hangup event if seen. + } + + if err != nil { + opErr = err + return true + } else if revents&unix.POLLERR > 0 { + opErr = fmt.Errorf("Got POLLERR event") + return true + } else if revents&unix.POLLNVAL > 0 { + opErr = fmt.Errorf("Got POLLNVAL event") + return true + } else if !w.hangup && w.ctx.Err() != nil { + // If we've not seen a hangup event and context has been cancelled then return EOF. + // This ensures that if there is a background process generating lots of output it + // doesn't block the session from finishing when the process has ended. + opErr = io.EOF + return true + } else if revents&(unix.POLLIN|unix.POLLPRI) > 0 { + // If there is something to read then read it. + n, opErr = unix.Read(int(fd), p) + return true + } else if w.hangup { + // If we've seen a hangup event and there's nothing to read then return EOF. + opErr = io.EOF + return true + } + } + }) + if err != nil { + return n, err + } + + return n, opErr +} + +func (w *execWrapper) Write(p []byte) (int, error) { + return w.f.Write(p) +} + +func (w *execWrapper) Close() error { + return w.f.Close() +} diff --git a/internal/server/certificate/cache.go b/internal/server/certificate/cache.go new file mode 100644 index 00000000000..da30c40a96e --- /dev/null +++ b/internal/server/certificate/cache.go @@ -0,0 +1,97 @@ +package certificate + +import ( + "crypto/x509" + "sync" +) + +// Cache represents an thread-safe in-memory cache of the certificates in the database. +type Cache struct { + // certificates is a map of certificate Type to map of certificate fingerprint to x509.Certificate. + certificates map[Type]map[string]x509.Certificate + + // projects is a map of certificate fingerprint to slice of projects the certificate is restricted to. + // If a certificate fingerprint is present in certificates, but not present in projects, it means the certificate is + // not restricted. + projects map[string][]string + mu sync.RWMutex +} + +// SetCertificatesAndProjects sets both certificates and projects on the Cache. +func (c *Cache) SetCertificatesAndProjects(certificates map[Type]map[string]x509.Certificate, projects map[string][]string) { + c.mu.Lock() + defer c.mu.Unlock() + + c.certificates = certificates + c.projects = projects +} + +// SetCertificates sets the certificates on the Cache. +func (c *Cache) SetCertificates(certificates map[Type]map[string]x509.Certificate) { + c.mu.Lock() + defer c.mu.Unlock() + + c.certificates = certificates +} + +// SetProjects sets the projects on the Cache. +func (c *Cache) SetProjects(projects map[string][]string) { + c.mu.Lock() + defer c.mu.Unlock() + + c.projects = projects +} + +// GetCertificatesAndProjects returns a read-only copy of the certificate and project maps. +func (c *Cache) GetCertificatesAndProjects() (map[Type]map[string]x509.Certificate, map[string][]string) { + c.mu.RLock() + defer c.mu.RUnlock() + + certificates := make(map[Type]map[string]x509.Certificate, len(c.certificates)) + for t, m := range c.certificates { + certificates[t] = make(map[string]x509.Certificate, len(m)) + for f, cert := range m { + certificates[t][f] = cert + } + } + + projects := make(map[string][]string, len(c.projects)) + for f, projectNames := range c.projects { + projectNamesCopy := make([]string, 0, len(projectNames)) + projectNamesCopy = append(projectNamesCopy, projectNames...) + projects[f] = projectNamesCopy + } + + return certificates, projects +} + +// GetCertificates returns a read-only copy of the certificate map. +func (c *Cache) GetCertificates() map[Type]map[string]x509.Certificate { + c.mu.RLock() + defer c.mu.RUnlock() + + certificates := make(map[Type]map[string]x509.Certificate, len(c.certificates)) + for t, m := range c.certificates { + certificates[t] = make(map[string]x509.Certificate, len(m)) + for f, cert := range m { + certificates[t][f] = cert + } + } + + return certificates +} + +// GetProjects returns a read-only copy of the project map. +func (c *Cache) GetProjects() map[string][]string { + c.mu.RLock() + defer c.mu.RUnlock() + + projects := make(map[string][]string, len(c.projects)) + for f, projectNames := range c.projects { + projectNamesCopy := make([]string, 0, len(projectNames)) + projectNamesCopy = append(projectNamesCopy, projectNames...) + projects[f] = projectNamesCopy + } + + return projects +} diff --git a/internal/server/certificate/type.go b/internal/server/certificate/type.go new file mode 100644 index 00000000000..fd6641152ad --- /dev/null +++ b/internal/server/certificate/type.go @@ -0,0 +1,33 @@ +package certificate + +import ( + "fmt" + + "github.com/lxc/incus/shared/api" +) + +// Type indicates the type of the certificate. +type Type int + +// TypeClient indicates a client certificate type. +const TypeClient = Type(1) + +// TypeServer indicates a server certificate type. +const TypeServer = Type(2) + +// TypeMetrics indicates a metrics certificate type. +const TypeMetrics = Type(3) + +// FromAPIType converts an API type to the equivalent Type. +func FromAPIType(apiType string) (Type, error) { + switch apiType { + case api.CertificateTypeClient: + return TypeClient, nil + case api.CertificateTypeServer: + return TypeServer, nil + case api.CertificateTypeMetrics: + return TypeMetrics, nil + } + + return -1, fmt.Errorf("Invalid certificate type") +} diff --git a/internal/server/cluster/gateway.go b/internal/server/cluster/gateway.go index 64f9a832875..ae1a10cd1ea 100644 --- a/internal/server/cluster/gateway.go +++ b/internal/server/cluster/gateway.go @@ -21,8 +21,8 @@ import ( client "github.com/cowsql/go-cowsql/client" "github.com/lxc/incus/internal/revert" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/db" - "github.com/lxc/incus/internal/server/db/cluster" "github.com/lxc/incus/internal/server/response" "github.com/lxc/incus/internal/server/state" localUtil "github.com/lxc/incus/internal/server/util" @@ -154,7 +154,7 @@ func setDqliteVersionHeader(request *http.Request) { // These handlers might return 404, either because this server is a // non-clustered member not available over the network or because it is not a // database node part of the dqlite cluster. -func (g *Gateway) HandlerFuncs(heartbeatHandler HeartbeatHandler, trustedCerts func() map[cluster.CertificateType]map[string]x509.Certificate) map[string]http.HandlerFunc { +func (g *Gateway) HandlerFuncs(heartbeatHandler HeartbeatHandler, trustedCerts func() map[certificate.Type]map[string]x509.Certificate) map[string]http.HandlerFunc { database := func(w http.ResponseWriter, r *http.Request) { g.lock.RLock() if !tlsCheckCert(r, g.networkCert, g.state().ServerCert(), trustedCerts()) { diff --git a/internal/server/cluster/gateway_test.go b/internal/server/cluster/gateway_test.go index a0fadc16660..d551dd5258d 100644 --- a/internal/server/cluster/gateway_test.go +++ b/internal/server/cluster/gateway_test.go @@ -15,9 +15,9 @@ import ( "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/cluster" "github.com/lxc/incus/internal/server/db" - dbCluster "github.com/lxc/incus/internal/server/db/cluster" "github.com/lxc/incus/internal/server/state" localtls "github.com/lxc/incus/shared/tls" ) @@ -37,7 +37,7 @@ func TestGateway_Single(t *testing.T) { gateway := newGateway(t, node, cert, s) defer func() { _ = gateway.Shutdown() }() - trustedCerts := func() map[dbCluster.CertificateType]map[string]x509.Certificate { + trustedCerts := func() map[certificate.Type]map[string]x509.Certificate { return nil } @@ -101,7 +101,7 @@ func TestGateway_SingleWithNetworkAddress(t *testing.T) { gateway := newGateway(t, node, cert, s) defer func() { _ = gateway.Shutdown() }() - trustedCerts := func() map[dbCluster.CertificateType]map[string]x509.Certificate { + trustedCerts := func() map[certificate.Type]map[string]x509.Certificate { return nil } @@ -146,7 +146,7 @@ func TestGateway_NetworkAuth(t *testing.T) { gateway := newGateway(t, node, cert, s) defer func() { _ = gateway.Shutdown() }() - trustedCerts := func() map[dbCluster.CertificateType]map[string]x509.Certificate { + trustedCerts := func() map[certificate.Type]map[string]x509.Certificate { return nil } diff --git a/internal/server/cluster/heartbeat_test.go b/internal/server/cluster/heartbeat_test.go index e5cb1e0c13c..0ad79622237 100644 --- a/internal/server/cluster/heartbeat_test.go +++ b/internal/server/cluster/heartbeat_test.go @@ -12,10 +12,10 @@ import ( "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/cluster" clusterConfig "github.com/lxc/incus/internal/server/cluster/config" "github.com/lxc/incus/internal/server/db" - dbCluster "github.com/lxc/incus/internal/server/db/cluster" "github.com/lxc/incus/internal/server/node" "github.com/lxc/incus/internal/server/state" "github.com/lxc/incus/internal/version" @@ -214,7 +214,7 @@ func (f *heartbeatFixture) node() (*state.State, *cluster.Gateway, string) { mux := http.NewServeMux() server := newServer(serverCert, mux) - trustedCerts := func() map[dbCluster.CertificateType]map[string]x509.Certificate { + trustedCerts := func() map[certificate.Type]map[string]x509.Certificate { return nil } diff --git a/internal/server/cluster/membership.go b/internal/server/cluster/membership.go index 04e1b9c0fea..68f110cf982 100644 --- a/internal/server/cluster/membership.go +++ b/internal/server/cluster/membership.go @@ -13,6 +13,7 @@ import ( "github.com/cowsql/go-cowsql/app" "github.com/cowsql/go-cowsql/client" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/db" "github.com/lxc/incus/internal/server/db/cluster" "github.com/lxc/incus/internal/server/node" @@ -182,7 +183,7 @@ func EnsureServerCertificateTrusted(serverName string, serverCert *localtls.Cert dbCert := cluster.Certificate{ Fingerprint: fingerprint, - Type: cluster.CertificateTypeServer, // Server type for intra-member communication. + Type: certificate.TypeServer, // Server type for intra-member communication. Name: serverName, Certificate: string(pem.EncodeToMemory(&pem.Block{Type: "CERTIFICATE", Bytes: serverCertx509.Raw})), } @@ -192,11 +193,11 @@ func EnsureServerCertificateTrusted(serverName string, serverCert *localtls.Cert ctx := context.Background() existingCert, _ := cluster.GetCertificate(ctx, tx.Tx(), dbCert.Fingerprint) if existingCert != nil { - if existingCert.Name != dbCert.Name && existingCert.Type == cluster.CertificateTypeServer { + if existingCert.Name != dbCert.Name && existingCert.Type == certificate.TypeServer { // Don't alter an existing server certificate that has our fingerprint but not our name. // Something is wrong as this shouldn't happen. return fmt.Errorf("Existing server certificate with different name %q already in trust store", existingCert.Name) - } else if existingCert.Name != dbCert.Name && existingCert.Type != cluster.CertificateTypeServer { + } else if existingCert.Name != dbCert.Name && existingCert.Type != certificate.TypeServer { // Ensure that if a client certificate already exists that matches our fingerprint, that it // has the correct name and type for cluster operation, to allow us to associate member // server names to certificate names. @@ -1058,7 +1059,7 @@ func Purge(c *db.Cluster, name string) error { return fmt.Errorf("Failed to remove member %q: %w", name, err) } - err = cluster.DeleteCertificates(context.Background(), tx.Tx(), name, cluster.CertificateTypeServer) + err = cluster.DeleteCertificates(context.Background(), tx.Tx(), name, certificate.TypeServer) if err != nil { return fmt.Errorf("Failed to remove member %q certificate from trust store: %w", name, err) } diff --git a/internal/server/cluster/membership_test.go b/internal/server/cluster/membership_test.go index e3967f628f3..0518dc98d29 100644 --- a/internal/server/cluster/membership_test.go +++ b/internal/server/cluster/membership_test.go @@ -14,6 +14,7 @@ import ( "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/cluster" clusterConfig "github.com/lxc/incus/internal/server/cluster/config" "github.com/lxc/incus/internal/server/db" @@ -131,7 +132,7 @@ func TestBootstrap(t *testing.T) { // The cluster certificate is in place. assert.True(t, util.PathExists(filepath.Join(state.OS.VarDir, "cluster.crt"))) - trustedCerts := func() map[dbCluster.CertificateType]map[string]x509.Certificate { + trustedCerts := func() map[certificate.Type]map[string]x509.Certificate { return nil } @@ -289,9 +290,9 @@ func TestJoin(t *testing.T) { altServerCert := localtls.TestingAltKeyPair() trustedAltServerCert, _ := x509.ParseCertificate(altServerCert.KeyPair().Certificate[0]) - trustedCerts := func() map[dbCluster.CertificateType]map[string]x509.Certificate { - return map[dbCluster.CertificateType]map[string]x509.Certificate{ - dbCluster.CertificateTypeServer: { + trustedCerts := func() map[certificate.Type]map[string]x509.Certificate { + return map[certificate.Type]map[string]x509.Certificate{ + certificate.TypeServer: { altServerCert.Fingerprint(): *trustedAltServerCert, }, } diff --git a/internal/server/cluster/tls.go b/internal/server/cluster/tls.go index 677fca191fc..1784da90abb 100644 --- a/internal/server/cluster/tls.go +++ b/internal/server/cluster/tls.go @@ -7,7 +7,7 @@ import ( "net/http" "time" - "github.com/lxc/incus/internal/server/db/cluster" + "github.com/lxc/incus/internal/server/certificate" localUtil "github.com/lxc/incus/internal/server/util" "github.com/lxc/incus/shared/logger" localtls "github.com/lxc/incus/shared/tls" @@ -53,7 +53,7 @@ func tlsClientConfig(networkCert *localtls.CertInfo, serverCert *localtls.CertIn } // tlsCheckCert checks certificate access, returns true if certificate is trusted. -func tlsCheckCert(r *http.Request, networkCert *localtls.CertInfo, serverCert *localtls.CertInfo, trustedCerts map[cluster.CertificateType]map[string]x509.Certificate) bool { +func tlsCheckCert(r *http.Request, networkCert *localtls.CertInfo, serverCert *localtls.CertInfo, trustedCerts map[certificate.Type]map[string]x509.Certificate) bool { _, err := x509.ParseCertificate(networkCert.KeyPair().Certificate[0]) if err != nil { // Since we have already loaded this certificate, typically @@ -77,7 +77,7 @@ func tlsCheckCert(r *http.Request, networkCert *localtls.CertInfo, serverCert *l } // Check the trusted server certficates list provided. - trusted, _ = localUtil.CheckTrustState(*i, trustedCerts[cluster.CertificateTypeServer], networkCert, false) + trusted, _ = localUtil.CheckTrustState(*i, trustedCerts[certificate.TypeServer], networkCert, false) if trusted { return true } diff --git a/internal/server/cluster/upgrade_test.go b/internal/server/cluster/upgrade_test.go index a514dc11f11..dfe2a51c3f0 100644 --- a/internal/server/cluster/upgrade_test.go +++ b/internal/server/cluster/upgrade_test.go @@ -16,9 +16,9 @@ import ( "github.com/stretchr/testify/assert" "github.com/stretchr/testify/require" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/cluster" "github.com/lxc/incus/internal/server/db" - dbCluster "github.com/lxc/incus/internal/server/db/cluster" "github.com/lxc/incus/internal/server/node" "github.com/lxc/incus/internal/server/state" localtls "github.com/lxc/incus/shared/tls" @@ -158,7 +158,7 @@ func TestUpgradeMembersWithoutRole(t *testing.T) { gateway := newGateway(t, state.DB.Node, serverCert, state) defer func() { _ = gateway.Shutdown() }() - trustedCerts := func() map[dbCluster.CertificateType]map[string]x509.Certificate { + trustedCerts := func() map[certificate.Type]map[string]x509.Certificate { return nil } diff --git a/internal/server/config/generate/incus_doc_test.go b/internal/server/config/generate/incus_doc_test.go index b79b4f899dc..ebe60327a73 100644 --- a/internal/server/config/generate/incus_doc_test.go +++ b/internal/server/config/generate/incus_doc_test.go @@ -6,7 +6,7 @@ import ( "github.com/stretchr/testify/assert" ) -// Test the alphabetical sorting of a `lxd-metadata` JSON structure. +// Test the alphabetical sorting of a `incus-doc` JSON structure. func TestJSONSorted(t *testing.T) { projectEntries := make(map[string]any) projectEntries["entityKey1"] = map[string]any{ diff --git a/internal/server/db/certificates.go b/internal/server/db/certificates.go index f5b424c38d0..693421f76c1 100644 --- a/internal/server/db/certificates.go +++ b/internal/server/db/certificates.go @@ -5,6 +5,7 @@ package db import ( "context" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/db/cluster" "github.com/lxc/incus/internal/server/db/query" ) @@ -32,7 +33,7 @@ func (db *DB) UpdateCertificate(ctx context.Context, fingerprint string, cert cl func (n *NodeTx) GetCertificates(ctx context.Context) ([]cluster.Certificate, error) { type cert struct { fingerprint string - certType cluster.CertificateType + certType certificate.Type name string certificate string } diff --git a/internal/server/db/cluster/certificates.go b/internal/server/db/cluster/certificates.go index dd3c3f01433..7dd0ca52100 100644 --- a/internal/server/db/cluster/certificates.go +++ b/internal/server/db/cluster/certificates.go @@ -8,6 +8,7 @@ import ( "fmt" "net/http" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/db/query" "github.com/lxc/incus/shared/api" ) @@ -39,7 +40,7 @@ import ( type Certificate struct { ID int Fingerprint string `db:"primary=yes"` - Type CertificateType + Type certificate.Type Name string Certificate string Restricted bool @@ -50,43 +51,17 @@ type CertificateFilter struct { ID *int Fingerprint *string Name *string - Type *CertificateType -} - -// CertificateType indicates the type of the certificate. -type CertificateType int - -// CertificateTypeClient indicates a client certificate type. -const CertificateTypeClient = CertificateType(1) - -// CertificateTypeServer indicates a server certificate type. -const CertificateTypeServer = CertificateType(2) - -// CertificateTypeMetrics indicates a metrics certificate type. -const CertificateTypeMetrics = CertificateType(3) - -// CertificateAPITypeToDBType converts an API type to the equivalent DB type. -func CertificateAPITypeToDBType(apiType string) (CertificateType, error) { - switch apiType { - case api.CertificateTypeClient: - return CertificateTypeClient, nil - case api.CertificateTypeServer: - return CertificateTypeServer, nil - case api.CertificateTypeMetrics: - return CertificateTypeMetrics, nil - } - - return -1, fmt.Errorf("Invalid certificate type") + Type *certificate.Type } // ToAPIType returns the API equivalent type. func (cert *Certificate) ToAPIType() string { switch cert.Type { - case CertificateTypeClient: + case certificate.TypeClient: return api.CertificateTypeClient - case CertificateTypeServer: + case certificate.TypeServer: return api.CertificateTypeServer - case CertificateTypeMetrics: + case certificate.TypeMetrics: return api.CertificateTypeMetrics } diff --git a/internal/server/db/cluster/certificates.interface.mapper.go b/internal/server/db/cluster/certificates.interface.mapper.go index 9c06259692d..cbbff503cff 100644 --- a/internal/server/db/cluster/certificates.interface.mapper.go +++ b/internal/server/db/cluster/certificates.interface.mapper.go @@ -5,6 +5,8 @@ package cluster import ( "context" "database/sql" + + "github.com/lxc/incus/internal/server/certificate" ) // CertificateGenerated is an interface of generated methods for Certificate. @@ -35,7 +37,7 @@ type CertificateGenerated interface { // DeleteCertificates deletes the certificate matching the given key parameters. // generator: certificate DeleteMany-by-Name-and-Type - DeleteCertificates(ctx context.Context, tx *sql.Tx, name string, certificateType CertificateType) error + DeleteCertificates(ctx context.Context, tx *sql.Tx, name string, certificateType certificate.Type) error // UpdateCertificate updates the certificate matching the given key parameters. // generator: certificate Update diff --git a/internal/server/db/cluster/certificates.mapper.go b/internal/server/db/cluster/certificates.mapper.go index d99a3af9d9f..cd00d4e1515 100644 --- a/internal/server/db/cluster/certificates.mapper.go +++ b/internal/server/db/cluster/certificates.mapper.go @@ -12,6 +12,7 @@ import ( "net/http" "strings" + "github.com/lxc/incus/internal/server/certificate" "github.com/lxc/incus/internal/server/db/query" "github.com/lxc/incus/shared/api" ) @@ -336,7 +337,7 @@ func DeleteCertificate(ctx context.Context, tx *sql.Tx, fingerprint string) erro // DeleteCertificates deletes the certificate matching the given key parameters. // generator: certificate DeleteMany-by-Name-and-Type -func DeleteCertificates(ctx context.Context, tx *sql.Tx, name string, certificateType CertificateType) error { +func DeleteCertificates(ctx context.Context, tx *sql.Tx, name string, certificateType certificate.Type) error { stmt, err := Stmt(tx, certificateDeleteByNameAndType) if err != nil { return fmt.Errorf("Failed to get \"certificateDeleteByNameAndType\" prepared statement: %w", err) diff --git a/internal/server/instance/drivers/driver_common.go b/internal/server/instance/drivers/driver_common.go index 44d48dd7f89..85b6399ac3f 100644 --- a/internal/server/instance/drivers/driver_common.go +++ b/internal/server/instance/drivers/driver_common.go @@ -1400,7 +1400,7 @@ func (d *common) devicesRemove(inst instance.Instance) { } // updateBackupFileLock acquires the update backup file lock that protects concurrent access to actions that will call UpdateBackupFile() as part of their operation. -func (d *common) updateBackupFileLock(ctx context.Context) locking.UnlockFunc { +func (d *common) updateBackupFileLock(ctx context.Context) (locking.UnlockFunc, error) { parentName, _, _ := api.GetParentAndSnapshotName(d.Name()) return locking.Lock(ctx, fmt.Sprintf("instance_updatebackupfile_%s_%s", d.Project().Name, parentName)) } diff --git a/internal/server/instance/drivers/driver_lxc.go b/internal/server/instance/drivers/driver_lxc.go index efbee6da260..9ab887a8a4b 100644 --- a/internal/server/instance/drivers/driver_lxc.go +++ b/internal/server/instance/drivers/driver_lxc.go @@ -1916,6 +1916,11 @@ func (d *lxc) startCommon() (string, []func() error, error) { return "", nil, fmt.Errorf("The image used by this instance requires a CGroupV1 host system") } + // Ensure privileged is turned off for images that cannot work privileged + if util.IsFalse(d.localConfig["image.requirements.privileged"]) && util.IsTrue(d.expandedConfig["security.privileged"]) { + return "", nil, fmt.Errorf("The image used by this instance is incompatible with privileged containers. Please unset security.privileged on the instance") + } + // Load any required kernel modules kernelModules := d.expandedConfig["linux.kernel_modules"] if kernelModules != "" { @@ -2320,7 +2325,11 @@ func (d *lxc) detachInterfaceRename(netns string, ifName string, hostName string // Start starts the instance. func (d *lxc) Start(stateful bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() d.logger.Debug("Start started", logger.Ctx{"stateful": stateful}) @@ -2329,7 +2338,7 @@ func (d *lxc) Start(stateful bool) error { // Check that we are startable before creating an operation lock. // Must happen before creating operation Start lock to avoid the status check returning Stopped due to the // existence of a Start operation lock. - err := d.validateStartup(stateful, d.statusCode()) + err = d.validateStartup(stateful, d.statusCode()) if err != nil { return err } @@ -3403,7 +3412,11 @@ func (d *lxc) snapshot(name string, expiry time.Time, stateful bool) error { // Snapshot takes a new snapshot. func (d *lxc) Snapshot(name string, expiry time.Time, stateful bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() return d.snapshot(name, expiry, stateful) @@ -3626,7 +3639,11 @@ func (d *lxc) cleanup() { // Delete deletes the instance. func (d *lxc) Delete(force bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() // Setup a new operation. @@ -3770,7 +3787,11 @@ func (d *lxc) delete(force bool) error { // Rename renames the instance. Accepts an argument to enable applying deferred TemplateTriggerRename. func (d *lxc) Rename(newName string, applyTemplateTrigger bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() oldName := d.Name() @@ -3783,7 +3804,7 @@ func (d *lxc) Rename(newName string, applyTemplateTrigger bool) error { d.logger.Info("Renaming instance", ctxMap) // Quick checks. - err := instance.ValidName(newName, d.IsSnapshot()) + err = instance.ValidName(newName, d.IsSnapshot()) if err != nil { return err } @@ -3954,7 +3975,11 @@ func (d *lxc) CGroupSet(key string, value string) error { // Update applies updated config. func (d *lxc) Update(args db.InstanceArgs, userRequested bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() // Setup a new operation @@ -6594,11 +6619,15 @@ func (d *lxc) inheritInitPidFd() (int, *os.File) { // FileSFTPConn returns a connection to the forkfile handler. func (d *lxc) FileSFTPConn() (net.Conn, error) { // Lock to avoid concurrent spawning. - spawnUnlock := locking.Lock(context.TODO(), fmt.Sprintf("forkfile_%d", d.id)) + spawnUnlock, err := locking.Lock(context.TODO(), fmt.Sprintf("forkfile_%d", d.id)) + if err != nil { + return nil, err + } + defer spawnUnlock() // Create any missing directories in case the instance has never been started before. - err := os.MkdirAll(d.LogPath(), 0700) + err = os.MkdirAll(d.LogPath(), 0700) if err != nil { return nil, err } @@ -6655,7 +6684,12 @@ func (d *lxc) FileSFTPConn() (net.Conn, error) { chReady := make(chan error) go func() { // Lock to avoid concurrent running forkfile. - runUnlock := locking.Lock(context.TODO(), d.forkfileRunningLockName()) + runUnlock, err := locking.Lock(context.TODO(), d.forkfileRunningLockName()) + if err != nil { + chReady <- err + return + } + defer runUnlock() // Mount the filesystem if needed. @@ -6826,7 +6860,14 @@ func (d *lxc) FileSFTP() (*sftp.Client, error) { func (d *lxc) stopForkfile(force bool) { // Make sure that when the function exits, no forkfile is running by acquiring the lock (which indicates // that forkfile isn't running and holding the lock) and then releasing it. - defer func() { locking.Lock(context.TODO(), d.forkfileRunningLockName())() }() + defer func() { + unlock, err := locking.Lock(context.TODO(), d.forkfileRunningLockName()) + if err != nil { + return + } + + unlock() + }() content, err := os.ReadFile(filepath.Join(d.LogPath(), "forkfile.pid")) if err != nil { @@ -8084,7 +8125,7 @@ func (d *lxc) UpdateBackupFile() error { return err } - return pool.UpdateInstanceBackupFile(d, nil) + return pool.UpdateInstanceBackupFile(d, true, nil) } // Info returns "lxc" and the currently loaded version of LXC. diff --git a/internal/server/instance/drivers/driver_qemu.go b/internal/server/instance/drivers/driver_qemu.go index 734eeb8112e..5c00f621ff6 100644 --- a/internal/server/instance/drivers/driver_qemu.go +++ b/internal/server/instance/drivers/driver_qemu.go @@ -1069,7 +1069,11 @@ func (d *qemu) validateStartup(stateful bool, statusCode api.StatusCode) error { // Start starts the instance. func (d *qemu) Start(stateful bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() return d.start(stateful, nil) @@ -2498,8 +2502,7 @@ func (d *qemu) generateConfigShare() error { agentServiceUnit := `[Unit] Description=Incus - agent Documentation=https://linuxcontainers.org/incus/docs/main/ -ConditionPathExists=/dev/virtio-ports/org.linuxcontainers.incus -Before=cloud-init.target cloud-init.service cloud-init-local.service +Before=multi-user.target cloud-init.target cloud-init.service cloud-init-local.service DefaultDependencies=no [Service] @@ -2511,9 +2514,6 @@ Restart=on-failure RestartSec=5s StartLimitInterval=60 StartLimitBurst=10 - -[Install] -WantedBy=multi-user.target ` err = os.WriteFile(filepath.Join(configDrivePath, "systemd", "incus-agent.service"), []byte(agentServiceUnit), 0400) @@ -2573,7 +2573,11 @@ chown -R root:root "${PREFIX}" return err } - agentRules := `ACTION=="add", SYMLINK=="virtio-ports/org.linuxcontainers.incus", TAG+="systemd", ACTION=="add", RUN+="/bin/systemctl start incus-agent.service"` + agentRules := `SYMLINK=="virtio-ports/org.linuxcontainers.incus", TAG+="systemd", ENV{SYSTEMD_WANTS}+="incus-agent.service" + +# Legacy. +SYMLINK=="virtio-ports/org.linuxcontainers.lxd", TAG+="systemd", ENV{SYSTEMD_WANTS}+="incus-agent.service" +` err = os.WriteFile(filepath.Join(configDrivePath, "udev", "99-incus-agent.rules"), []byte(agentRules), 0400) if err != nil { return err @@ -4602,7 +4606,11 @@ func (d *qemu) snapshot(name string, expiry time.Time, stateful bool) error { // Snapshot takes a new snapshot. func (d *qemu) Snapshot(name string, expiry time.Time, stateful bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() return d.snapshot(name, expiry, stateful) @@ -4730,7 +4738,11 @@ func (d *qemu) Restore(source instance.Instance, stateful bool) error { // Rename the instance. Accepts an argument to enable applying deferred TemplateTriggerRename. func (d *qemu) Rename(newName string, applyTemplateTrigger bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() oldName := d.Name() @@ -4743,7 +4755,7 @@ func (d *qemu) Rename(newName string, applyTemplateTrigger bool) error { d.logger.Info("Renaming instance", ctxMap) // Quick checks. - err := instance.ValidName(newName, d.IsSnapshot()) + err = instance.ValidName(newName, d.IsSnapshot()) if err != nil { return err } @@ -4889,7 +4901,11 @@ func (d *qemu) Rename(newName string, applyTemplateTrigger bool) error { // Update the instance config. func (d *qemu) Update(args db.InstanceArgs, userRequested bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() // Setup a new operation. @@ -5558,7 +5574,11 @@ func (d *qemu) init() error { // Delete the instance. func (d *qemu) Delete(force bool) error { - unlock := d.updateBackupFileLock(context.Background()) + unlock, err := d.updateBackupFileLock(context.Background()) + if err != nil { + return err + } + defer unlock() // Setup a new operation. @@ -7704,7 +7724,7 @@ func (d *qemu) UpdateBackupFile() error { return err } - return pool.UpdateInstanceBackupFile(d, nil) + return pool.UpdateInstanceBackupFile(d, true, nil) } type cpuTopology struct { diff --git a/internal/server/locking/lock.go b/internal/server/locking/lock.go index 26f958893cb..0d2c4c9043e 100644 --- a/internal/server/locking/lock.go +++ b/internal/server/locking/lock.go @@ -2,6 +2,7 @@ package locking import ( "context" + "fmt" "sync" ) @@ -21,7 +22,7 @@ type UnlockFunc func() // Will block until the lock is established or the context is cancelled. // On successfully acquiring the lock, it returns an unlock function which needs to be called to unlock the lock. // If the context is canceled then nil will be returned. -func Lock(ctx context.Context, lockName string) UnlockFunc { +func Lock(ctx context.Context, lockName string) (UnlockFunc, error) { for { // Get exclusive access to the map and see if there is already an operation ongoing. locksMutex.Lock() @@ -53,7 +54,7 @@ func Lock(ctx context.Context, lockName string) UnlockFunc { // map entry has been deleted, this will allow any waiting users // to try and get access to the map to create a new operation. locksMutex.Unlock() - } + }, nil } // An existing operation is ongoing, lets wait for that to finish and then try @@ -64,7 +65,7 @@ func Lock(ctx context.Context, lockName string) UnlockFunc { case <-waitCh: continue case <-ctx.Done(): - return nil + return nil, fmt.Errorf("Failed to obtain lock %q: %w", lockName, ctx.Err()) } } } diff --git a/internal/server/network/driver_bridge.go b/internal/server/network/driver_bridge.go index b46d6f288f9..107dee2ddbb 100644 --- a/internal/server/network/driver_bridge.go +++ b/internal/server/network/driver_bridge.go @@ -1972,7 +1972,7 @@ func (n *bridge) getExternalSubnetInUse() ([]externalSubnetUsage, error) { proxySubnet, err := ParseIPToNet(proxyListenAddr.Address) if err != nil { - return err + continue // If proxy listen isn't a valid IP it can't conflict. } externalSubnets = append(externalSubnets, externalSubnetUsage{ diff --git a/internal/server/network/driver_ovn.go b/internal/server/network/driver_ovn.go index 9b2ec8f89a9..06fcb3a2556 100644 --- a/internal/server/network/driver_ovn.go +++ b/internal/server/network/driver_ovn.go @@ -1144,7 +1144,11 @@ func (n *ovn) startUplinkPort() error { // Lock uplink network so that if multiple OVN networks are trying to connect to the same uplink we don't // race each other setting up the connection. - unlock := locking.Lock(context.TODO(), n.uplinkOperationLockName(uplinkNet)) + unlock, err := locking.Lock(context.TODO(), n.uplinkOperationLockName(uplinkNet)) + if err != nil { + return err + } + defer unlock() switch uplinkNet.Type() { @@ -1481,7 +1485,11 @@ func (n *ovn) deleteUplinkPort() error { } // Lock uplink network so we don't race each other networks using the OVS uplink bridge. - unlock := locking.Lock(context.TODO(), n.uplinkOperationLockName(uplinkNet)) + unlock, err := locking.Lock(context.TODO(), n.uplinkOperationLockName(uplinkNet)) + if err != nil { + return err + } + defer unlock() switch uplinkNet.Type() { diff --git a/internal/server/resources/storage.go b/internal/server/resources/storage.go index 520f3edb537..9c6d10a0042 100644 --- a/internal/server/resources/storage.go +++ b/internal/server/resources/storage.go @@ -83,10 +83,21 @@ func storageAddDriveInfo(devicePath string, disk *api.ResourcesStorageDisk) erro } // Serial number - if udevProperties["E:ID_SERIAL_SHORT"] != "" { - disk.Serial = udevProperties["E:ID_SERIAL_SHORT"] + serial := udevProperties["E:SCSI_IDENT_SERIAL"] + if serial == "" { + serial = udevProperties["E:ID_SCSI_SERIAL"] } + if serial == "" { + serial = udevProperties["E:ID_SERIAL_SHORT"] + } + + if serial == "" { + serial = udevProperties["E:ID_SERIAL"] + } + + disk.Serial = serial + // Model number (attempt to get original string from encoded value) if udevProperties["E:ID_MODEL_ENC"] != "" { model, err := udevDecode(udevProperties["E:ID_MODEL_ENC"]) diff --git a/internal/server/seccomp/seccomp.go b/internal/server/seccomp/seccomp.go index 92e8912fd0e..636f918cc19 100644 --- a/internal/server/seccomp/seccomp.go +++ b/internal/server/seccomp/seccomp.go @@ -251,7 +251,7 @@ static inline int pidfd_getfd(int pidfd, int fd, int flags) return syscall(__NR_pidfd_getfd, pidfd, fd, flags); } -#define ptr_to_u64(p) ((__aligned_u64)((uintptr_t)(p))) +#define ptr_to_u64(p) ((__u64)((uintptr_t)(p))) static inline int bpf(int cmd, union bpf_attr *attr, size_t size) { diff --git a/internal/server/storage/backend.go b/internal/server/storage/backend.go index 3a3d34553b0..ce4a006cf29 100644 --- a/internal/server/storage/backend.go +++ b/internal/server/storage/backend.go @@ -2519,7 +2519,7 @@ func (b *backend) BackupInstance(inst instance.Instance, tarWriter *instancewrit } // Ensure the backup file reflects current config. - err = b.UpdateInstanceBackupFile(inst, op) + err = b.UpdateInstanceBackupFile(inst, snapshots, op) if err != nil { return err } @@ -2862,7 +2862,11 @@ func (b *backend) CreateInstanceSnapshot(inst instance.Instance, src instance.In // Lock this operation to ensure that the only one snapshot is made at the time. // Other operations will wait for this one to finish. - unlock := locking.Lock(context.TODO(), drivers.OperationLockName("CreateInstanceSnapshot", b.name, vol.Type(), contentType, src.Name())) + unlock, err := locking.Lock(context.TODO(), drivers.OperationLockName("CreateInstanceSnapshot", b.name, vol.Type(), contentType, src.Name())) + if err != nil { + return err + } + defer unlock() err = b.driver.CreateVolumeSnapshot(vol, op) @@ -2942,7 +2946,7 @@ func (b *backend) RenameInstanceSnapshot(inst instance.Instance, newName string, }) // Ensure the backup file reflects current config. - err = b.UpdateInstanceBackupFile(inst, op) + err = b.UpdateInstanceBackupFile(inst, true, op) if err != nil { return err } @@ -3233,7 +3237,11 @@ func (b *backend) EnsureImage(fingerprint string, op *operations.Operation) erro // We need to lock this operation to ensure that the image is not being created multiple times. // Uses a lock name of "EnsureImage_" to avoid deadlocking with CreateVolume below that also // establishes a lock on the volume type & name if it needs to mount the volume before filling. - unlock := locking.Lock(context.TODO(), drivers.OperationLockName("EnsureImage", b.name, drivers.VolumeTypeImage, "", fingerprint)) + unlock, err := locking.Lock(context.TODO(), drivers.OperationLockName("EnsureImage", b.name, drivers.VolumeTypeImage, "", fingerprint)) + if err != nil { + return err + } + defer unlock() // Load image info from database. @@ -3466,7 +3474,11 @@ func (b *backend) DeleteImage(fingerprint string, op *operations.Operation) erro defer l.Debug("DeleteImage finished") // We need to lock this operation to ensure that the image is not being deleted multiple times. - unlock := locking.Lock(context.TODO(), drivers.OperationLockName("DeleteImage", b.name, drivers.VolumeTypeImage, "", fingerprint)) + unlock, err := locking.Lock(context.TODO(), drivers.OperationLockName("DeleteImage", b.name, drivers.VolumeTypeImage, "", fingerprint)) + if err != nil { + return err + } + defer unlock() // Load the storage volume in order to get the volume config which is needed for some drivers. @@ -3723,7 +3735,11 @@ func (b *backend) UpdateBucket(projectName string, bucketName string, bucket api if len(changedConfig) > 0 && !userOnly { if memberSpecific { // Stop MinIO process if running so volume can be resized if needed. - minioProc := miniod.Get(curBucketVol.Name()) + minioProc, err := miniod.Get(curBucketVol.Name()) + if err != nil { + return err + } + if minioProc != nil { err = minioProc.Stop(context.Background()) if err != nil { @@ -3786,7 +3802,11 @@ func (b *backend) DeleteBucket(projectName string, bucketName string, op *operat // Handle common MinIO implementation for local storage drivers. // Stop MinIO process if running. - minioProc := miniod.Get(bucketVolName) + minioProc, err := miniod.Get(bucketVolName) + if err != nil { + return err + } + if minioProc != nil { err = minioProc.Stop(context.Background()) if err != nil { @@ -3795,7 +3815,7 @@ func (b *backend) DeleteBucket(projectName string, bucketName string, op *operat } vol := b.GetVolume(drivers.VolumeTypeBucket, drivers.ContentTypeFS, bucketVolName, nil) - err := b.driver.DeleteVolume(vol, op) + err = b.driver.DeleteVolume(vol, op) if err != nil { return err } @@ -5561,7 +5581,11 @@ func (b *backend) CreateCustomVolumeSnapshot(projectName, volName string, newSna // Lock this operation to ensure that the only one snapshot is made at the time. // Other operations will wait for this one to finish. - unlock := locking.Lock(context.TODO(), drivers.OperationLockName("CreateCustomVolumeSnapshot", b.name, vol.Type(), contentType, volName)) + unlock, err := locking.Lock(context.TODO(), drivers.OperationLockName("CreateCustomVolumeSnapshot", b.name, vol.Type(), contentType, volName)) + if err != nil { + return err + } + defer unlock() // Create the snapshot on the storage device. @@ -5913,7 +5937,7 @@ func (b *backend) GenerateInstanceBackupConfig(inst instance.Instance, snapshots } // UpdateInstanceBackupFile writes the instance's config to the backup.yaml file on the storage device. -func (b *backend) UpdateInstanceBackupFile(inst instance.Instance, op *operations.Operation) error { +func (b *backend) UpdateInstanceBackupFile(inst instance.Instance, snapshots bool, op *operations.Operation) error { l := b.logger.AddContext(logger.Ctx{"project": inst.Project().Name, "instance": inst.Name()}) l.Debug("UpdateInstanceBackupFile started") defer l.Debug("UpdateInstanceBackupFile finished") @@ -5923,7 +5947,7 @@ func (b *backend) UpdateInstanceBackupFile(inst instance.Instance, op *operation return nil } - config, err := b.GenerateInstanceBackupConfig(inst, true, op) + config, err := b.GenerateInstanceBackupConfig(inst, snapshots, op) if err != nil { return err } diff --git a/internal/server/storage/backend_mock.go b/internal/server/storage/backend_mock.go index ea9eb2cc26e..fe79dbc7869 100644 --- a/internal/server/storage/backend_mock.go +++ b/internal/server/storage/backend_mock.go @@ -148,7 +148,7 @@ func (b *mockBackend) GenerateInstanceBackupConfig(inst instance.Instance, snaps return nil, nil } -func (b *mockBackend) UpdateInstanceBackupFile(inst instance.Instance, op *operations.Operation) error { +func (b *mockBackend) UpdateInstanceBackupFile(inst instance.Instance, snapshot bool, op *operations.Operation) error { return nil } diff --git a/internal/server/storage/drivers/driver_btrfs_volumes.go b/internal/server/storage/drivers/driver_btrfs_volumes.go index e5d56b4b762..d32ac6fd629 100644 --- a/internal/server/storage/drivers/driver_btrfs_volumes.go +++ b/internal/server/storage/drivers/driver_btrfs_volumes.go @@ -1137,7 +1137,11 @@ func (d *btrfs) ListVolumes() ([]Volume, error) { // MountVolume simulates mounting a volume. func (d *btrfs) MountVolume(vol Volume, op *operations.Operation) error { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return err + } + defer unlock() // Don't attempt to modify the permission of an existing custom volume root. @@ -1156,7 +1160,11 @@ func (d *btrfs) MountVolume(vol Volume, op *operations.Operation) error { // UnmountVolume simulates unmounting a volume. // As driver doesn't have volumes to unmount it returns false indicating the volume was already unmounted. func (d *btrfs) UnmountVolume(vol Volume, keepBlockDev bool, op *operations.Operation) (bool, error) { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return false, err + } + defer unlock() refCount := vol.MountRefCountDecrement() @@ -1794,7 +1802,11 @@ func (d *btrfs) DeleteVolumeSnapshot(snapVol Volume, op *operations.Operation) e // MountVolumeSnapshot sets up a read-only mount on top of the snapshot to avoid accidental modifications. func (d *btrfs) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) error { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return err + } + defer unlock() snapPath := snapVol.MountPath() @@ -1808,7 +1820,7 @@ func (d *btrfs) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) er } } - _, err := mountReadOnly(snapPath, snapPath) + _, err = mountReadOnly(snapPath, snapPath) if err != nil { return err } @@ -1819,7 +1831,11 @@ func (d *btrfs) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) er // UnmountVolumeSnapshot removes the read-only mount placed on top of a snapshot. func (d *btrfs) UnmountVolumeSnapshot(snapVol Volume, op *operations.Operation) (bool, error) { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return false, err + } + defer unlock() refCount := snapVol.MountRefCountDecrement() diff --git a/internal/server/storage/drivers/driver_ceph_volumes.go b/internal/server/storage/drivers/driver_ceph_volumes.go index 966d6ccf94c..180a66b26ad 100644 --- a/internal/server/storage/drivers/driver_ceph_volumes.go +++ b/internal/server/storage/drivers/driver_ceph_volumes.go @@ -1167,7 +1167,11 @@ func (d *ceph) ListVolumes() ([]Volume, error) { // MountVolume mounts a volume and increments ref counter. Please call UnmountVolume() when done with the volume. func (d *ceph) MountVolume(vol Volume, op *operations.Operation) error { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return err + } + defer unlock() revert := revert.New() @@ -1227,10 +1231,13 @@ func (d *ceph) MountVolume(vol Volume, op *operations.Operation) error { // UnmountVolume simulates unmounting a volume. // keepBlockDev indicates if backing block device should be not be unmapped if volume is unmounted. func (d *ceph) UnmountVolume(vol Volume, keepBlockDev bool, op *operations.Operation) (bool, error) { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return false, err + } + defer unlock() - var err error ourUnmount := false mountPath := vol.MountPath() @@ -1565,7 +1572,11 @@ func (d *ceph) DeleteVolumeSnapshot(snapVol Volume, op *operations.Operation) er // MountVolumeSnapshot simulates mounting a volume snapshot. func (d *ceph) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) error { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return err + } + defer unlock() revert := revert.New() @@ -1658,10 +1669,13 @@ func (d *ceph) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) err // UnmountVolume simulates unmounting a volume snapshot. func (d *ceph) UnmountVolumeSnapshot(snapVol Volume, op *operations.Operation) (bool, error) { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return false, err + } + defer unlock() - var err error ourUnmount := false mountPath := snapVol.MountPath() refCount := snapVol.MountRefCountDecrement() diff --git a/internal/server/storage/drivers/driver_cephfs_volumes.go b/internal/server/storage/drivers/driver_cephfs_volumes.go index 6d5c0315147..a38e2625c24 100644 --- a/internal/server/storage/drivers/driver_cephfs_volumes.go +++ b/internal/server/storage/drivers/driver_cephfs_volumes.go @@ -348,7 +348,11 @@ func (d *cephfs) ListVolumes() ([]Volume, error) { // MountVolume sets up the volume for use. func (d *cephfs) MountVolume(vol Volume, op *operations.Operation) error { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return err + } + defer unlock() vol.MountRefCountIncrement() // From here on it is up to caller to call UnmountVolume() when done. @@ -358,7 +362,11 @@ func (d *cephfs) MountVolume(vol Volume, op *operations.Operation) error { // UnmountVolume clears any runtime state for the volume. // As driver doesn't have volumes to unmount it returns false indicating the volume was already unmounted. func (d *cephfs) UnmountVolume(vol Volume, keepBlockDev bool, op *operations.Operation) (bool, error) { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return false, err + } + defer unlock() refCount := vol.MountRefCountDecrement() @@ -530,7 +538,11 @@ func (d *cephfs) DeleteVolumeSnapshot(snapVol Volume, op *operations.Operation) // MountVolumeSnapshot makes the snapshot available for use. func (d *cephfs) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) error { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return err + } + defer unlock() snapVol.MountRefCountIncrement() // From here on it is up to caller to call UnmountVolumeSnapshot() when done. @@ -539,7 +551,11 @@ func (d *cephfs) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) e // UnmountVolumeSnapshot clears any runtime state for the snapshot. func (d *cephfs) UnmountVolumeSnapshot(snapVol Volume, op *operations.Operation) (bool, error) { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return false, err + } + defer unlock() refCount := snapVol.MountRefCountDecrement() diff --git a/internal/server/storage/drivers/driver_dir_volumes.go b/internal/server/storage/drivers/driver_dir_volumes.go index bd0a4b8e181..35645b7add8 100644 --- a/internal/server/storage/drivers/driver_dir_volumes.go +++ b/internal/server/storage/drivers/driver_dir_volumes.go @@ -368,7 +368,11 @@ func (d *dir) ListVolumes() ([]Volume, error) { // MountVolume simulates mounting a volume. func (d *dir) MountVolume(vol Volume, op *operations.Operation) error { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return err + } + defer unlock() // Don't attempt to modify the permission of an existing custom volume root. @@ -387,7 +391,11 @@ func (d *dir) MountVolume(vol Volume, op *operations.Operation) error { // UnmountVolume simulates unmounting a volume. // As driver doesn't have volumes to unmount it returns false indicating the volume was already unmounted. func (d *dir) UnmountVolume(vol Volume, keepBlockDev bool, op *operations.Operation) (bool, error) { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return false, err + } + defer unlock() refCount := vol.MountRefCountDecrement() @@ -502,7 +510,11 @@ func (d *dir) DeleteVolumeSnapshot(snapVol Volume, op *operations.Operation) err // MountVolumeSnapshot sets up a read-only mount on top of the snapshot to avoid accidental modifications. func (d *dir) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) error { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return err + } + defer unlock() snapPath := snapVol.MountPath() @@ -516,7 +528,7 @@ func (d *dir) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) erro } } - _, err := mountReadOnly(snapPath, snapPath) + _, err = mountReadOnly(snapPath, snapPath) if err != nil { return err } @@ -527,7 +539,11 @@ func (d *dir) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) erro // UnmountVolumeSnapshot removes the read-only mount placed on top of a snapshot. func (d *dir) UnmountVolumeSnapshot(snapVol Volume, op *operations.Operation) (bool, error) { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return false, err + } + defer unlock() mountPath := snapVol.MountPath() diff --git a/internal/server/storage/drivers/driver_lvm_utils.go b/internal/server/storage/drivers/driver_lvm_utils.go index da24511638b..4309e85c964 100644 --- a/internal/server/storage/drivers/driver_lvm_utils.go +++ b/internal/server/storage/drivers/driver_lvm_utils.go @@ -61,7 +61,11 @@ func (d *lvm) openLoopFile(source string) (string, error) { } if filepath.IsAbs(source) && !linux.IsBlockdevPath(source) { - unlock := locking.Lock(context.TODO(), OperationLockName("openLoopFile", d.name, "", "", "")) + unlock, err := locking.Lock(context.TODO(), OperationLockName("openLoopFile", d.name, "", "", "")) + if err != nil { + return "", err + } + defer unlock() loopDeviceName, err := loopDeviceSetup(source) diff --git a/internal/server/storage/drivers/driver_lvm_volumes.go b/internal/server/storage/drivers/driver_lvm_volumes.go index 723d1996538..3439c69a1f5 100644 --- a/internal/server/storage/drivers/driver_lvm_volumes.go +++ b/internal/server/storage/drivers/driver_lvm_volumes.go @@ -618,7 +618,11 @@ func (d *lvm) ListVolumes() ([]Volume, error) { // MountVolume mounts a volume and increments ref counter. Please call UnmountVolume() when done with the volume. func (d *lvm) MountVolume(vol Volume, op *operations.Operation) error { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return err + } + defer unlock() revert := revert.New() @@ -680,10 +684,13 @@ func (d *lvm) MountVolume(vol Volume, op *operations.Operation) error { // UnmountVolume unmounts volume if mounted and not in use. Returns true if this unmounted the volume. // keepBlockDev indicates if backing block device should be not be deactivated when volume is unmounted. func (d *lvm) UnmountVolume(vol Volume, keepBlockDev bool, op *operations.Operation) (bool, error) { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return false, err + } + defer unlock() - var err error ourUnmount := false mountPath := vol.MountPath() @@ -927,13 +934,16 @@ func (d *lvm) DeleteVolumeSnapshot(snapVol Volume, op *operations.Operation) err // MountVolumeSnapshot sets up a read-only mount on top of the snapshot to avoid accidental modifications. func (d *lvm) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) error { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return err + } + defer unlock() revert := revert.New() defer revert.Fail() - var err error mountPath := snapVol.MountPath() // Check if already mounted. @@ -1035,10 +1045,13 @@ func (d *lvm) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) erro // UnmountVolumeSnapshot removes the read-only mount placed on top of a snapshot. // If a temporary snapshot volume exists then it will attempt to remove it. func (d *lvm) UnmountVolumeSnapshot(snapVol Volume, op *operations.Operation) (bool, error) { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return false, err + } + defer unlock() - var err error ourUnmount := false mountPath := snapVol.MountPath() diff --git a/internal/server/storage/drivers/driver_zfs_volumes.go b/internal/server/storage/drivers/driver_zfs_volumes.go index 409457072db..8d6d1f0fb02 100644 --- a/internal/server/storage/drivers/driver_zfs_volumes.go +++ b/internal/server/storage/drivers/driver_zfs_volumes.go @@ -1531,9 +1531,9 @@ func (d *zfs) ValidateVolume(vol Volume, removeUnknownKeys bool) error { commonRules := d.commonVolumeRules() // Disallow block.* settings for regular custom block volumes. These settings only make sense - // when using custom filesystem volumes with block mode enabled. LXD will create the filesystem + // when using custom filesystem volumes with block mode enabled. Incus will create the filesystem // for these volumes, and use the mount options. When attaching a regular block volumes to a VM, - // these are not mounted by LXD and therefore don't need these config keys. + // these are not mounted by Incus and therefore don't need these config keys. if vol.IsVMBlock() || vol.volType == VolumeTypeCustom && vol.contentType == ContentTypeBlock { delete(commonRules, "zfs.block_mode") delete(commonRules, "block.filesystem") @@ -2074,7 +2074,11 @@ func (d *zfs) deactivateVolume(vol Volume) (bool, error) { // MountVolume mounts a volume and increments ref counter. Please call UnmountVolume() when done with the volume. func (d *zfs) MountVolume(vol Volume, op *operations.Operation) error { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return err + } + defer unlock() revert := revert.New() @@ -2173,10 +2177,13 @@ func (d *zfs) MountVolume(vol Volume, op *operations.Operation) error { // UnmountVolume unmounts volume if mounted and not in use. Returns true if this unmounted the volume. // keepBlockDev indicates if backing block device should be not be deactivated when volume is unmounted. func (d *zfs) UnmountVolume(vol Volume, keepBlockDev bool, op *operations.Operation) (bool, error) { - unlock := vol.MountLock() + unlock, err := vol.MountLock() + if err != nil { + return false, err + } + defer unlock() - var err error ourUnmount := false dataset := d.dataset(vol, false) mountPath := vol.MountPath() @@ -2877,10 +2884,14 @@ func (d *zfs) DeleteVolumeSnapshot(vol Volume, op *operations.Operation) error { // MountVolumeSnapshot simulates mounting a volume snapshot. func (d *zfs) MountVolumeSnapshot(snapVol Volume, op *operations.Operation) error { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return err + } + defer unlock() - _, err := d.mountVolumeSnapshot(snapVol, d.dataset(snapVol, false), snapVol.MountPath(), op) + _, err = d.mountVolumeSnapshot(snapVol, d.dataset(snapVol, false), snapVol.MountPath(), op) if err != nil { return err } @@ -3077,10 +3088,13 @@ func (d *zfs) mountVolumeSnapshot(snapVol Volume, snapshotDataset string, mountP // UnmountVolume simulates unmounting a volume snapshot. func (d *zfs) UnmountVolumeSnapshot(snapVol Volume, op *operations.Operation) (bool, error) { - unlock := snapVol.MountLock() + unlock, err := snapVol.MountLock() + if err != nil { + return false, err + } + defer unlock() - var err error ourUnmount := false mountPath := snapVol.MountPath() snapshotDataset := d.dataset(snapVol, false) diff --git a/internal/server/storage/drivers/volume.go b/internal/server/storage/drivers/volume.go index 669e505b3f6..86b69f5d4ef 100644 --- a/internal/server/storage/drivers/volume.go +++ b/internal/server/storage/drivers/volume.go @@ -180,7 +180,7 @@ func (v Volume) mountLockName() string { } // MountLock attempts to lock the mount lock for the volume and returns the UnlockFunc. -func (v Volume) MountLock() locking.UnlockFunc { +func (v Volume) MountLock() (locking.UnlockFunc, error) { return locking.Lock(context.TODO(), v.mountLockName()) } diff --git a/internal/server/storage/pool_interface.go b/internal/server/storage/pool_interface.go index 6cb4ce93747..1acc3fc51be 100644 --- a/internal/server/storage/pool_interface.go +++ b/internal/server/storage/pool_interface.go @@ -71,7 +71,7 @@ type Pool interface { RenameInstance(inst instance.Instance, newName string, op *operations.Operation) error DeleteInstance(inst instance.Instance, op *operations.Operation) error UpdateInstance(inst instance.Instance, newDesc string, newConfig map[string]string, op *operations.Operation) error - UpdateInstanceBackupFile(inst instance.Instance, op *operations.Operation) error + UpdateInstanceBackupFile(inst instance.Instance, snapshots bool, op *operations.Operation) error GenerateInstanceBackupConfig(inst instance.Instance, snapshots bool, op *operations.Operation) (*backupConfig.Config, error) CheckInstanceBackupFileSnapshots(backupConf *backupConfig.Config, projectName string, deleteMissing bool, op *operations.Operation) ([]*api.InstanceSnapshot, error) ImportInstance(inst instance.Instance, poolVol *backupConfig.Config, op *operations.Operation) (revert.Hook, error) diff --git a/internal/server/storage/s3/miniod/miniod.go b/internal/server/storage/s3/miniod/miniod.go index 86420dcc128..593b952b3e7 100644 --- a/internal/server/storage/s3/miniod/miniod.go +++ b/internal/server/storage/s3/miniod/miniod.go @@ -93,7 +93,11 @@ func (p *Process) Stop(ctx context.Context) error { return nil } - spawnUnlock := locking.Lock(context.TODO(), fmt.Sprintf("%s%s", minioLockPrefix, p.bucketName)) + spawnUnlock, err := locking.Lock(context.TODO(), fmt.Sprintf("%s%s", minioLockPrefix, p.bucketName)) + if err != nil { + return err + } + defer spawnUnlock() defer p.cancel.Cancel() @@ -162,7 +166,11 @@ func EnsureRunning(s *state.State, bucketVol storageDrivers.Volume) (*Process, e bucketName := bucketVol.Name() // Prevent concurrent spawning of same bucket. - spawnUnlock := locking.Lock(context.TODO(), fmt.Sprintf("%s%s", minioLockPrefix, bucketName)) + spawnUnlock, err := locking.Lock(context.TODO(), fmt.Sprintf("%s%s", minioLockPrefix, bucketName)) + if err != nil { + return nil, err + } + defer spawnUnlock() // Check if there is an existing running minio process for the bucket, and if so return it. @@ -347,9 +355,13 @@ func EnsureRunning(s *state.State, bucketVol storageDrivers.Volume) (*Process, e } // Get returns an existing MinIO process if it exists. -func Get(bucketName string) *Process { +func Get(bucketName string) (*Process, error) { // Wait for any ongoing spawn of the bucket process to finish. - spawnUnlock := locking.Lock(context.TODO(), fmt.Sprintf("%s%s", minioLockPrefix, bucketName)) + spawnUnlock, err := locking.Lock(context.TODO(), fmt.Sprintf("%s%s", minioLockPrefix, bucketName)) + if err != nil { + return nil, err + } + defer spawnUnlock() // Check if there is an existing running minio process for the bucket, and if so return it. @@ -362,10 +374,10 @@ func Get(bucketName string) *Process { minioProc.transactions++ minios[bucketName] = minioProc - return minioProc + return minioProc, nil } - return nil + return nil, nil } // StopAll stops all MinIO processes cleanly. diff --git a/internal/server/storage/storage.go b/internal/server/storage/storage.go index 0c7283c92f8..40d1629cf0b 100644 --- a/internal/server/storage/storage.go +++ b/internal/server/storage/storage.go @@ -231,6 +231,8 @@ func UsedBy(ctx context.Context, s *state.State, pool Pool, firstOnly bool, memb if firstOnly { return nil } + + break } } diff --git a/internal/server/vsock/vsock.go b/internal/server/vsock/vsock.go index 1c96077035e..27df4a408fb 100644 --- a/internal/server/vsock/vsock.go +++ b/internal/server/vsock/vsock.go @@ -12,11 +12,6 @@ import ( localtls "github.com/lxc/incus/shared/tls" ) -// ContextID returns the local VM sockets context ID. -func ContextID() (uint32, error) { - return vsock.ContextID() -} - // Dial connects to a remote vsock. func Dial(cid, port uint32) (net.Conn, error) { return vsock.Dial(cid, port, nil) diff --git a/internal/version/api.go b/internal/version/api.go index 91c5a7c94eb..f72c080f897 100644 --- a/internal/version/api.go +++ b/internal/version/api.go @@ -380,6 +380,8 @@ var APIExtensions = []string{ "event_lifecycle_name_and_project", "instances_nic_limits_priority", "disk_initial_volume_configuration", + "operation_wait", + "image_restriction_privileged", } // APIExtensionsCount returns the number of available API extensions. diff --git a/package.json b/package.json index 4543f3a09e4..24e935223cf 100644 --- a/package.json +++ b/package.json @@ -37,6 +37,7 @@ "textlint-rule-no-hankaku-kana": "^2.0.1", "textlint-rule-no-mix-dearu-desumasu": "^5.0.0", "textlint-rule-no-mixed-zenkaku-and-hankaku-alphabet": "^1.0.1", + "textlint-rule-preset-ja-spacing": "^2.3.0", "textlint-rule-prh": "^5.3.0" } } diff --git a/pnpm-lock.yaml b/pnpm-lock.yaml index d09d77fdbaa..9bb388b8d3e 100644 --- a/pnpm-lock.yaml +++ b/pnpm-lock.yaml @@ -59,6 +59,9 @@ dependencies: textlint-rule-no-mixed-zenkaku-and-hankaku-alphabet: specifier: ^1.0.1 version: 1.0.1 + textlint-rule-preset-ja-spacing: + specifier: ^2.3.0 + version: 2.3.0 textlint-rule-prh: specifier: ^5.3.0 version: 5.3.0 @@ -1685,6 +1688,13 @@ packages: morpheme-match-all: 1.2.0 dev: false + /textlint-rule-ja-nakaguro-or-halfwidth-space-between-katakana@2.2.0: + resolution: {integrity: sha512-6e5LfdjQgpkvGqMPFLxXtXyfXgc8iLOBuBda1jPWT873ttlfzTR9djjS7zmTkmNZDO4x0nvYPNTxCvgvilzlMQ==} + dependencies: + match-index: 1.0.3 + textlint-rule-helper: 2.3.0 + dev: false + /textlint-rule-ja-no-inappropriate-words@2.0.0: resolution: {integrity: sha512-gS2g8BqXv33D0QDz301aZh7EgWc2Vz70qBGJG0T3Dbtzxj/omqQCpxJtpVs5JKoGIBNkmxN5L+l0nf5TZ/luAw==} dependencies: @@ -1709,6 +1719,49 @@ packages: textlint-util-to-string: 3.3.2 dev: false + /textlint-rule-ja-no-space-around-parentheses@2.2.0: + resolution: {integrity: sha512-7m6n2XzOyYRVDvRfdYIxz6Qg23KA7BslYW44dAxYtmdVuDzQNKoSbZoGkZju/ITKsiN4JW+e/zEfFAY/qBEucQ==} + dependencies: + match-index: 1.0.3 + textlint-rule-helper: 2.3.0 + dev: false + + /textlint-rule-ja-no-space-between-full-width@2.2.0: + resolution: {integrity: sha512-oe5hOTbiKyhSTsBVroRk1mJqfUuCFeHexK3Sb6KWBET9sAhN3j7BnoKwxe2mjiDX5nXg+7Ka3ziwfQlnQ41l0w==} + dependencies: + match-index: 1.0.3 + regx: 1.0.4 + textlint-rule-helper: 2.3.0 + dev: false + + /textlint-rule-ja-space-after-exclamation@2.2.0: + resolution: {integrity: sha512-Foc9OzQ1WvdyKJnfXlj8DmODStNw13LpWhQK+yLecVYd3h8vLhaGvnpTitM6hj2Ep7klmX54Csn/iKDfGHb4Hw==} + dependencies: + match-index: 1.0.3 + textlint-rule-helper: 2.3.0 + dev: false + + /textlint-rule-ja-space-after-question@2.2.0: + resolution: {integrity: sha512-SoYKd8x0kPVp/4sa8XOE/62SAganWpbDcGl1CJ7aTk151+pO2C7Z34UnjeC9olYYxM9m0pZ0AOfdCwB3yvteJw==} + dependencies: + match-index: 1.0.3 + textlint-rule-helper: 2.3.0 + dev: false + + /textlint-rule-ja-space-around-code@2.2.0: + resolution: {integrity: sha512-JJfnSTFJCBL618TYVMqFfil8r7MhZuY0tEg2kyD6k/gcjbYFBx050pEl/RJJ5uD3UShLV7y4t289Gg9zuNjklw==} + dependencies: + match-index: 1.0.3 + textlint-rule-helper: 2.3.0 + dev: false + + /textlint-rule-ja-space-between-half-and-full-width@2.3.0: + resolution: {integrity: sha512-XJmw9fiKCK32P1fVGnYsqr1RdrWxTSqVqBPPHFVaIZhS1pBR7FsxdcR1SD6vEKe+EBJDEEZhJxrw8Pi1E5E22g==} + dependencies: + match-index: 1.0.3 + textlint-rule-helper: 2.3.0 + dev: false + /textlint-rule-ja-unnatural-alphabet@2.0.1: resolution: {integrity: sha512-n93V8qh6OKdh8OB6yLT+9Xl8DSoZ7gWi51tWdhlLEPIWgBm18nLMgm6Ck+nVc3eENOdRcQURWUpCGotI8wTemA==} dependencies: @@ -1782,6 +1835,18 @@ packages: textlint-rule-helper: 2.3.0 dev: false + /textlint-rule-preset-ja-spacing@2.3.0: + resolution: {integrity: sha512-HqDv2P69uNFFRSYE22GW3xuApXUmcNr17pAaYn72nVRdUQsxfP4GBNlxONghj1US1G1ipXcfllE9xQ7tKTZWpw==} + dependencies: + textlint-rule-ja-nakaguro-or-halfwidth-space-between-katakana: 2.2.0 + textlint-rule-ja-no-space-around-parentheses: 2.2.0 + textlint-rule-ja-no-space-between-full-width: 2.2.0 + textlint-rule-ja-space-after-exclamation: 2.2.0 + textlint-rule-ja-space-after-question: 2.2.0 + textlint-rule-ja-space-around-code: 2.2.0 + textlint-rule-ja-space-between-half-and-full-width: 2.3.0 + dev: false + /textlint-rule-prh@5.3.0: resolution: {integrity: sha512-gdod+lL1SWUDyXs1ICEwvQawaSshT3mvPGufBIjF2R5WFPdKQDMsiuzsjkLm+aF+9d97dA6pFsiyC8gSW7mSgg==} dependencies: diff --git a/scripts/bash/incus b/scripts/bash/incus index e8cbf5d0f73..049659b88a0 100644 --- a/scripts/bash/incus +++ b/scripts/bash/incus @@ -184,7 +184,7 @@ _have incus && { 3) case ${no_dashargs[2]} in "trust") - COMPREPLY=( $(compgen -W "list add remove" -- $cur) ) + COMPREPLY=( $(compgen -W "add add-certificate edit list list-tokens remove revoke-token show" -- $cur) ) ;; "device") COMPREPLY=( $(compgen -W "add get set unset list show remove" -- $cur) ) diff --git a/shared/api/url.go b/shared/api/url.go index 16e9a258d70..47ec34633b5 100644 --- a/shared/api/url.go +++ b/shared/api/url.go @@ -32,14 +32,20 @@ func (u *URL) Host(host string) *URL { // Path sets the path of the URL from one or more path parts. // It appends each of the pathParts (escaped using url.PathEscape) prefixed with "/" to the URL path. func (u *URL) Path(pathParts ...string) *URL { - var b strings.Builder + var path, rawPath strings.Builder for _, pathPart := range pathParts { - b.WriteString("/") // Build an absolute URL. - b.WriteString(url.PathEscape(pathPart)) + // Generate unencoded path. + path.WriteString("/") // Build an absolute URL. + path.WriteString(pathPart) + + // Generate encoded path hint (this will be used by u.URL.EncodedPath() to decide its methodology). + rawPath.WriteString("/") // Build an absolute URL. + rawPath.WriteString(url.PathEscape(pathPart)) } - u.URL.Path = b.String() + u.URL.Path = path.String() + u.URL.RawPath = rawPath.String() return u } diff --git a/shared/api/url_test.go b/shared/api/url_test.go index 769bd7c73a7..3ea4783cf7a 100644 --- a/shared/api/url_test.go +++ b/shared/api/url_test.go @@ -14,11 +14,11 @@ func ExampleURL() { fmt.Println(u.Host("example.com")) fmt.Println(u.Scheme("https")) - // Output: /1.0/networks/name-with-%252F-in-it - // /1.0/networks/name-with-%252F-in-it - // /1.0/networks/name-with-%252F-in-it?project=project-with-%25-in-it - // /1.0/networks/name-with-%252F-in-it?project=project-with-%25-in-it - // /1.0/networks/name-with-%252F-in-it?project=project-with-%25-in-it&target=member-with-%25-in-it - // //example.com/1.0/networks/name-with-%252F-in-it?project=project-with-%25-in-it&target=member-with-%25-in-it - // https://example.com/1.0/networks/name-with-%252F-in-it?project=project-with-%25-in-it&target=member-with-%25-in-it + // Output: /1.0/networks/name-with-%2F-in-it + // /1.0/networks/name-with-%2F-in-it + // /1.0/networks/name-with-%2F-in-it?project=project-with-%25-in-it + // /1.0/networks/name-with-%2F-in-it?project=project-with-%25-in-it + // /1.0/networks/name-with-%2F-in-it?project=project-with-%25-in-it&target=member-with-%25-in-it + // //example.com/1.0/networks/name-with-%2F-in-it?project=project-with-%25-in-it&target=member-with-%25-in-it + // https://example.com/1.0/networks/name-with-%2F-in-it?project=project-with-%25-in-it&target=member-with-%25-in-it } diff --git a/shared/osarch/architectures.go b/shared/osarch/architectures.go index 799c2864640..341e2dcc567 100644 --- a/shared/osarch/architectures.go +++ b/shared/osarch/architectures.go @@ -20,6 +20,7 @@ const ( ARCH_64BIT_RISCV_LITTLE_ENDIAN = 12 ARCH_32BIT_ARMV6_LITTLE_ENDIAN = 13 ARCH_32BIT_ARMV8_LITTLE_ENDIAN = 14 + ARCH_64BIT_LOONGARCH = 15 ) var architectureNames = map[int]string{ @@ -37,6 +38,7 @@ var architectureNames = map[int]string{ ARCH_64BIT_MIPS: "mips64", ARCH_32BIT_RISCV_LITTLE_ENDIAN: "riscv32", ARCH_64BIT_RISCV_LITTLE_ENDIAN: "riscv64", + ARCH_64BIT_LOONGARCH: "loongarch64", } var architectureAliases = map[int][]string{ @@ -53,6 +55,7 @@ var architectureAliases = map[int][]string{ ARCH_64BIT_MIPS: {"mips64el", "mips64le"}, ARCH_32BIT_RISCV_LITTLE_ENDIAN: {}, ARCH_64BIT_RISCV_LITTLE_ENDIAN: {}, + ARCH_64BIT_LOONGARCH: {"loong64"}, } var architecturePersonalities = map[int]string{ @@ -70,6 +73,7 @@ var architecturePersonalities = map[int]string{ ARCH_64BIT_MIPS: "linux64", ARCH_32BIT_RISCV_LITTLE_ENDIAN: "linux32", ARCH_64BIT_RISCV_LITTLE_ENDIAN: "linux64", + ARCH_64BIT_LOONGARCH: "linux64", } var architectureSupportedPersonalities = map[int][]int{ @@ -87,6 +91,7 @@ var architectureSupportedPersonalities = map[int][]int{ ARCH_64BIT_MIPS: {ARCH_32BIT_MIPS}, ARCH_32BIT_RISCV_LITTLE_ENDIAN: {}, ARCH_64BIT_RISCV_LITTLE_ENDIAN: {}, + ARCH_64BIT_LOONGARCH: {}, } const ArchitectureDefault = "x86_64" diff --git a/shared/ws/mirror.go b/shared/ws/mirror.go index 490e6c7a148..03c3c73884a 100644 --- a/shared/ws/mirror.go +++ b/shared/ws/mirror.go @@ -1,7 +1,6 @@ package ws import ( - "context" "io" "github.com/gorilla/websocket" @@ -11,15 +10,15 @@ import ( // Mirror takes a websocket and replicates all read/write to a ReadWriteCloser. // Returns channels indicating when reads and writes are finished (respectively). -func Mirror(ctx context.Context, conn *websocket.Conn, rwc io.ReadWriteCloser) (chan struct{}, chan struct{}) { - chRead := MirrorRead(ctx, conn, rwc) - chWrite := MirrorWrite(ctx, conn, rwc) +func Mirror(conn *websocket.Conn, rwc io.ReadWriteCloser) (chan struct{}, chan struct{}) { + chRead := MirrorRead(conn, rwc) + chWrite := MirrorWrite(conn, rwc) return chRead, chWrite } // MirrorRead is a uni-directional mirror which replicates an io.ReadCloser to a websocket. -func MirrorRead(ctx context.Context, conn *websocket.Conn, rc io.ReadCloser) chan struct{} { +func MirrorRead(conn *websocket.Conn, rc io.ReadCloser) chan struct{} { chDone := make(chan struct{}, 1) if rc == nil { close(chDone) @@ -32,29 +31,20 @@ func MirrorRead(ctx context.Context, conn *websocket.Conn, rc io.ReadCloser) cha go func() { defer close(chDone) - _, _ = io.Copy(connRWC, rc) - // Send write barrier. - connRWC.Close() + _, _ = io.Copy(connRWC, rc) logger.Debug("Websocket: Stopped read mirror", logger.Ctx{"address": conn.RemoteAddr().String()}) - }() - go func() { - // Handle cancelation. - select { - case <-ctx.Done(): - // Close the ReadCloser on cancel. - rc.Close() - case <-chDone: - } + // Send write barrier. + connRWC.Close() }() return chDone } // MirrorWrite is a uni-directional mirror which replicates a websocket to an io.WriteCloser. -func MirrorWrite(ctx context.Context, conn *websocket.Conn, wc io.WriteCloser) chan struct{} { +func MirrorWrite(conn *websocket.Conn, wc io.WriteCloser) chan struct{} { chDone := make(chan struct{}, 1) if wc == nil { close(chDone) @@ -72,15 +62,5 @@ func MirrorWrite(ctx context.Context, conn *websocket.Conn, wc io.WriteCloser) c logger.Debug("Websocket: Stopped write mirror", logger.Ctx{"address": conn.RemoteAddr().String()}) }() - go func() { - // Handle cancelation. - select { - case <-ctx.Done(): - // Close the WriteCloser on cancel. - wc.Close() - case <-chDone: - } - }() - return chDone } diff --git a/test/main.sh b/test/main.sh index a4b86fbf23e..79aa62dc205 100755 --- a/test/main.sh +++ b/test/main.sh @@ -339,6 +339,7 @@ if [ "${1:-"all"}" != "cluster" ]; then run_test test_backup_export "backup export" run_test test_backup_rename "backup rename" run_test test_backup_volume_export "backup volume export" + run_test test_backup_export_import_instance_only "backup export and import instance only" run_test test_backup_volume_rename_delete "backup volume rename and delete" run_test test_backup_different_instance_uuid "backup instance and check instance UUIDs" run_test test_backup_volume_expiry "backup volume expiry" @@ -354,6 +355,7 @@ if [ "${1:-"all"}" != "cluster" ]; then run_test test_metrics "Metrics" run_test test_storage_volume_recover "Recover storage volumes" run_test test_syslog_socket "Syslog socket" + run_test test_incus_user "incus-user" fi # shellcheck disable=SC2034 diff --git a/test/suites/backup.sh b/test/suites/backup.sh index 0d063618d7a..b3e3aaa64d0 100644 --- a/test/suites/backup.sh +++ b/test/suites/backup.sh @@ -50,8 +50,8 @@ EOF if [ "$poolDriver" = "zfs" ]; then # Ensure custom storage volumes have been recovered. - incus storage volume show "${poolName}" vol3| grep -q 'content_type: filesystem' - incus storage volume show "${poolName}" vol4| grep -q 'content_type: filesystem' + incus storage volume show "${poolName}" vol3 | grep -q 'content_type: filesystem' + incus storage volume show "${poolName}" vol4 | grep -q 'content_type: filesystem' # Cleanup incus storage volume delete "${poolName}" vol3 @@ -62,7 +62,7 @@ EOF rm -f foo.iso incus storage volume delete "${poolName}" vol1 incus storage volume delete "${poolName}" vol2 - shutdown_incus "${INCUS_DIR}" + shutdown_incus "${INCUS_IMPORT_DIR}" } test_container_recover() { @@ -971,7 +971,7 @@ test_backup_export_import_recover() { # Create and export an instance. incus launch testimage c1 incus export c1 "${INCUS_DIR}/c1.tar.gz" - incus rm -f c1 + incus delete -f c1 # Import instance and remove no longer required tarball. incus import "${INCUS_DIR}/c1.tar.gz" c2 @@ -992,3 +992,27 @@ EOF incus rm -f c2 ) } + +test_backup_export_import_instance_only() { + poolName=$(incus profile device get default root pool) + + ensure_import_testimage + ensure_has_localhost_remote "${INCUS_ADDR}" + + # Create an instance with snapshot. + incus init testimage c1 + incus snapshot create c1 + + # Export the instance and remove it. + incus export c1 "${INCUS_DIR}/c1.tar.gz" --instance-only + incus delete -f c1 + + # Import the instance from tarball. + incus import "${INCUS_DIR}/c1.tar.gz" + + # Verify imported instance has no snapshots. + [ "$(incus query "/1.0/storage-pools/${poolName}/volumes/container/c1/snapshots" | jq "length == 0")" = "true" ] + + rm "${INCUS_DIR}/c1.tar.gz" + incus delete -f c1 +} diff --git a/test/suites/basic.sh b/test/suites/basic.sh index 7613b69a00d..20814ca44da 100644 --- a/test/suites/basic.sh +++ b/test/suites/basic.sh @@ -655,4 +655,13 @@ test_basic_usage() { ! incus profile assign c1 foo || false incus profile delete foo incus delete -f c1 + + # Multiple ephemeral instances delete + incus launch testimage c1 + incus launch testimage c2 + incus launch testimage c3 + + incus delete -f c1 c2 c3 + remaining_instances="$(incus list --format csv)" + [ -z "${remaining_instances}" ] } diff --git a/test/suites/clustering.sh b/test/suites/clustering.sh index 9a92f048bc2..5d6c0362f72 100644 --- a/test/suites/clustering.sh +++ b/test/suites/clustering.sh @@ -658,9 +658,19 @@ test_clustering_storage() { INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume copy pool1/vol1 pool1/vol1 --target=node1 --destination-target=node2 INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume copy pool1/vol1 pool1/vol1 --target=node1 --destination-target=node2 --refresh + # Check renaming storage volume works. + INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume create pool1 vol2 --target=node1 + INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume move pool1/vol2 pool1/vol3 --target=node1 + INCUS_DIR="${INCUS_TWO_DIR}" incus storage volume show pool1 vol3 | grep -q node1 + INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume move pool1/vol3 pool1/vol2 --target=node1 --destination-target=node2 + INCUS_DIR="${INCUS_TWO_DIR}" incus storage volume show pool1 vol2 | grep -q node2 + INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume rename pool1 vol2 vol3 --target=node2 + INCUS_DIR="${INCUS_TWO_DIR}" incus storage volume show pool1 vol3 | grep -q node2 + # Delete pool and check cleaned up. INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume delete pool1 vol1 --target=node1 INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume delete pool1 vol1 --target=node2 + INCUS_DIR="${INCUS_ONE_DIR}" incus storage volume delete pool1 vol3 --target=node2 INCUS_DIR="${INCUS_TWO_DIR}" incus storage delete pool1 ! stat "${INCUS_ONE_SOURCE}/containers" || false ! stat "${INCUS_TWO_SOURCE}/containers" || false diff --git a/test/suites/incus_user.sh b/test/suites/incus_user.sh new file mode 100644 index 00000000000..d4c4f8a31c2 --- /dev/null +++ b/test/suites/incus_user.sh @@ -0,0 +1,20 @@ +test_incus_user() { + ensure_import_testimage + ensure_has_localhost_remote "${INCUS_ADDR}" + + incus-user --group nogroup & + USER_PID="$!" + while :; do + [ -S "${INCUS_DIR}/unix.socket.user" ] && break + sleep 0.5 + done + + USER_TEMPDIR="${TEST_DIR}/user" + mkdir "${USER_TEMPDIR}" + chown nobody:nogroup "${USER_TEMPDIR}" + + cmd=$(unset -f incus; command -v incus) + sudo -u nobody -Es -- env INCUS_CONF="${USER_TEMPDIR}" "${cmd}" project list + + kill -9 "${USER_PID}" +} diff --git a/test/suites/syslog.sh b/test/suites/syslog.sh index c17be4e6b57..a40594c02a4 100644 --- a/test/suites/syslog.sh +++ b/test/suites/syslog.sh @@ -1,9 +1,4 @@ test_syslog_socket() { - INCUS_DIR=$(mktemp -d -p "${TEST_DIR}" XXX) - export INCUS_DIR - chmod +x "${INCUS_DIR}" - spawn_incus "${INCUS_DIR}" true - incus config set core.syslog_socket=true incus monitor --type=network-acl > "${TEST_DIR}/ovn.log" & monitorOVNPID=$! @@ -17,5 +12,5 @@ test_syslog_socket() { grep -qF "type: network-acl" "${TEST_DIR}/ovn.log" grep -qF "name=\"some-acl\"" "${TEST_DIR}/ovn.log" - shutdown_incus "${INCUS_DIR}" + incus config unset core.syslog_socket }