Ansible devel - en to ja translation catalogue (1297 entries)

en: YAML Syntax
ja: YAML 構文

en: This page provides a basic overview of correct YAML syntax, which is how Ansible playbooks (our configuration management language) are expressed.
ja: このページでは、Ansible Playbook (Ansible での設定管理言語) の表現方法である、正しい YAML 構文について概説します。

en: We use YAML because it is easier for humans to read and write than other common data formats like XML or JSON.  Further, there are libraries available in most programming languages for working with YAML.
ja: Ansible では、XML や JSON などのような一般的なその他のデータ形式に比べて人間による解読および記述が簡単であるため、YAML を使用しています。さらに、プログラミング言語の多くには、YAML に対応するライブラリーが提供されています。

en: You may also wish to read :ref:`working_with_playbooks` at the same time to see how this is used in practice.
ja: :ref:`working_with_playbooks` も合わせて参照し、実際にどのように使用されているかを確認してください。

en: YAML Basics
ja: YAML の基礎

en: For Ansible, nearly every YAML file starts with a list. Each item in the list is a list of key/value pairs, commonly called a "hash" or a "dictionary".  So, we need to know how to write lists and dictionaries in YAML.
ja: Ansible で使用する場合は、YAML ファイルのほぼすべてがリストで開始します。リストの各項目は、一般的に「ハッシュ」または「ディクショナリー」と呼ばれるキー/値のペアのリストとなっています。そのため、YAML でリストとディクショナリーを記述する方法を理解する必要があります。

en: There's another small quirk to YAML.  All YAML files (regardless of their association with Ansible or not) can optionally begin with ``---`` and end with ``...``.  This is part of the YAML format and indicates the start and end of a document.
ja: YAML には、他にもわずかな特徴があります。YAML ファイルはすべて (Ansible との関係の有無に関係なく)、必要に応じて ``---`` で開始して ``...`` で終わらせることができます。これは、YAML 形式の一部で、ドキュメントの最初と最後を示します。

en: All members of a list are lines beginning at the same indentation level starting with a ``"- "`` (a dash and a space)::
ja: リストのメンバーはすべて同じインデントレベルで、``"- "`` (ダッシュとスペース) で開始する行になります::

en: A dictionary is represented in a simple ``key: value`` form (the colon must be followed by a space)::
ja: ディクショナリーは、シンプルな ``key: value`` の形式で表現します (コロンの後にはスペースを挿入する必要があります)::

en: More complicated data structures are possible, such as lists of dictionaries, dictionaries whose values are lists or a mix of both::
ja: リストがディクショナリーやその値の場合や、ディクショナリーと値が混合している場合など、より複雑なデータ構造も可能です。

en: Dictionaries and lists can also be represented in an abbreviated form if you really want to::
ja: ディクショナリーとリストは、必要であれば、略語形式で表現することも可能です::

en: These are called "Flow collections".
ja: 以下は「フローコレクション」と呼ばれます。

en: Ansible doesn't really use these too much, but you can also specify a boolean value (true/false) in several forms::
ja: Ansible では以下の形式はあまり使用されませんが、ブール型値 (True/False) を複数の形式で指定することもできます::

en: Use lowercase 'true' or 'false' for boolean values in dictionaries if you want to be compatible with default yamllint options.
ja: デフォルトの yamllint オプションと互換性を持たせる場合は、ディクショナリーのブール値に小文字の「true」または「false」を使用します。

en: Values can span multiple lines using ``|`` or ``>``.  Spanning multiple lines using a "Literal Block Scalar" ``|`` will include the newlines and any trailing spaces. Using a "Folded Block Scalar" ``>`` will fold newlines to spaces; it's used to make what would otherwise be a very long line easier to read and edit. In either case the indentation will be ignored. Examples are::
ja: 値は、``|`` または ``>`` を使用することで複数の行にまたがって指定することができます。「リテラル形式のブロックスカラー」``|`` を使用して複数行にまたがる場合は、改行と末尾のスペースが含まれます。「折り畳み形式のブロックスカラー」``>`` を使用すると、折り返しに使用される改行はすべてスペースに変換されます。これは、非常に長い行を読みやすく、編集しやすくするために使われます。いずれの場合も、インデントは無視されます。以下に例を示します。

en: While in the above ``>`` example all newlines are folded into spaces, there are two ways to enforce a newline to be kept::
ja: 上記の ``>`` の例では、改行はすべてスペースに変換されますが、強制的に改行を行う方法が 2 種類あります。

en: Let's combine what we learned so far in an arbitrary YAML example. This really has nothing to do with Ansible, but will give you a feel for the format::
ja: これまでに説明した内容を、任意の YAML の例にまとめてみましょう。以下は、Ansible とは関係ありませんが、どのような形式になるかを示しています::

en: That's all you really need to know about YAML to start writing `Ansible` playbooks.
ja: `Ansible` Playbook の記述を開始するにあたり、以上が YAML について理解しておく必要のある内容です。

en: While you can put just about anything into an unquoted scalar, there are some exceptions. A colon followed by a space (or newline) ``": "`` is an indicator for a mapping. A space followed by the pound sign ``" #"`` starts a comment.
ja: 引用符で囲まれていないスカラーには何でも挿入できますが、一部例外があります。コロンの後にスペース (または改行) を続けて記述 (``": "``) した場合は、マッピングを示すインジケーターになります。スペースに続けてポンド記号を記述 (``" #"``) した場合は、コメントの開始を表します。

en: Because of this, the following is going to result in a YAML syntax error::
ja: このため、以下のような場合には、YAML 構文がエラーになります。

en: ...but this will work::
ja: ...ただし、以下は有効します::

en: You will want to quote hash values using colons followed by a space or the end of the line::
ja: コロンを使用してハッシュ記号を引用し、その後ろにスペースを指定するか、行末にしてください::

en: ...and then the colon will be preserved.
ja: ...そしてコロンが保存されます。

en: Alternatively, you can use double quotes::
ja: または、二重引用符を使用してください。

en: The difference between single quotes and double quotes is that in double quotes you can use escapes::
ja: 二重引用符ではエスケープを使用できる点が、一重引用符と二重引用符との相違点です::

en: The list of allowed escapes can be found in the YAML Specification under "Escape Sequences" (YAML 1.1) or "Escape Characters" (YAML 1.2).
ja: 使用可能なエスケープの一覧は、YAML 仕様の「Escape Sequences」(YAML 1.1) または「Escape Characters」(YAML 1.2) を参照してください。

en: The following is invalid YAML:
ja: 以下は無効な YAML です。

en: Further, Ansible uses "{{ var }}" for variables.  If a value after a colon starts with a "{", YAML will think it is a dictionary, so you must quote it, like so::
ja: さらに、Ansible は変数に "{{ var }}" を使用します。コロンの後に "{" が指定されている場合は、その値がディクショナリーであると YAML が認識するため、以下のように引用する必要があります::

en: If your value starts with a quote the entire value must be quoted, not just part of it. Here are some additional examples of how to properly quote things::
ja: 値を引用符でする場合は、値の一部だけでなく、値全体を引用符で囲む必要があります。値を引用する方法について正しい例を以下に示します。

en: Not valid::
ja: 以下は有効ではありません::

en: In addition to ``'`` and ``"`` there are a number of characters that are special (or reserved) and cannot be used as the first character of an unquoted scalar: ``[] {} > | * & ! % # ` @ ,``.
ja: ``'`` および ``"`` 以外に、引用符で囲まれていないスカラーの最初の文字として使用できない特殊文字 (予約文字) がいくつかあります (``[] {} > | * & ! % # ` @ ,`` など)。

en: You should also be aware of ``? : -``. In YAML, they are allowed at the beginning of a string if a non-space character follows, but YAML processor implementations differ, so it's better to use quotes.
ja: また、``? : -`` には常に注意してください。YAML では、スペース以外の文字が続く場合は、文字列の先頭で許可されますが、YAML プロセッサーの実装は異なるため、引用符を使用することが推奨されます。

en: In Flow Collections, the rules are a bit more strict::
ja: フローコレクションでは、ルールはもう少し厳密です::

en: Boolean conversion is helpful, but this can be a problem when you want a literal `yes` or other boolean values as a string. In these cases just use quotes::
ja: ブール値の変換は便利ですが、リテラルの `yes` や、文字列として他のブール値を指定する場合など問題になる場合があります。この場合は、引用符だけを使用します::

en: YAML converts certain strings into floating-point values, such as the string `1.0`. If you need to specify a version number (in a requirements.yml file, for example), you will need to quote the value if it looks like a floating-point value::
ja: YAML は、特定の文字列を文字列 `1.0` などの浮動小数点値に変換します。(たとえば requirements.yml ファイルで) バージョン番号を指定する必要があり、それが浮動小数点の値のように見える場合は、その値を引用符で囲む必要があります。

en: Learn what playbooks can do and how to write/run them.
ja: Playbook でできることと、Playbook を記述および実行する方法を学びます。

en: YAML Lint (online) helps you debug YAML syntax if you are having problems
ja: YAML ヒント (オンライン) は、問題が発生した場合に YAML 構文のデバッグに役立ちます。

en: `GitHub examples directory <https://github.com/ansible/ansible-examples>`_
ja: `GitHub examples ディレクトリー <https://github.com/ansible/ansible-examples>`_

en: Complete playbook files from the github project source
ja: Github プロジェクトソースの完全な Playbook ファイル

en: `Wikipedia YAML syntax reference <https://en.wikipedia.org/wiki/YAML>`_
ja: `Wikipedia YAML 構文リファレンス <https://en.wikipedia.org/wiki/YAML>`_

en: A good guide to YAML syntax
ja: YAML 構文の適切なガイド

en: `Mailing List <https://groups.google.com/group/ansible-project>`_
ja: `メーリングリスト <https://groups.google.com/group/ansible-project>`_

en: Questions? Help? Ideas?  Stop by the list on Google Groups
ja: ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。

en: #ansible IRC chat channel
ja: IRC チャットチャンネル (#ansible)

en: #yaml for YAML specific questions
ja: YAML に関する質問 (#yaml)

en: The Specification for YAML 1.1, which PyYAML and libyaml are currently implementing
ja: PyYAML および libyaml が現在実装されている YAML 1.1 の仕様

en: `YAML 1.2 Specification <https://yaml.org/spec/1.2/spec.html>`_
ja: `YAML 1.2 仕様 <https://yaml.org/spec/1.2/spec.html>`_

en: For completeness, YAML 1.2 is the successor of 1.1
ja: 完全を期すため、YAML 1.2 は 1.1 の後継となります。

en: `Ansible Automation Hub <https://www.ansible.com/products/automation-hub>`_ is the official location to discover and download supported :ref:`collections <collections>`, included as part of an Ansible Automation Platform subscription. These content collections contain modules, plugins, roles, and playbooks in a downloadable package.
ja: `Ansible Automation Hub <https://www.ansible.com/products/automation-hub>`_ は、Ansible Platform サブスクリプションに同梱される、サポート対象の :ref:`コレクション <collections>` を検出してダウンロードする公式の場所です。このようなコンテンツコレクションでは、ダウンロード可能なパッケージにモジュール、プラグイン、ロール、Playbook が含まれます。

en: Ansible Automation Hub gives you direct access to trusted content collections from Red Hat and Certified Partners. You can find content by topic or Ansible Partner organizations.
ja: Ansible Automation Hub を使用すると、Red Hat および認定パートナーから、信頼できるコンテンツコレクションに直接アクセスできます。コンテンツは、トピック別または Ansible パートナー組織別に検索できます。

en: Ansible Automation Hub is the downstream Red Hat supported product version of Ansible Galaxy. Find out more about Ansible Automation Hub features and how to access it at `Ansible Automation Hub <https://www.ansible.com/products/automation-hub>`_. Ansible Automation Hub is part of the Red Hat Ansible Automation Platform subscription, and comes bundled with support from Red Hat, Inc.
ja: Ansible Automation Hub は、Red Hat がサポートする Ansible Galaxy の製品バージョン (ダウンストリーム) です。Ansible Automation Hub の機能とそのアクセス方法の詳細は、「`Ansible Automation Hub <https://www.ansible.com/products/automation-hub>`_」を参照してください。Ansible Automation Hub は、Red Hat Ansible Automation Platform サブスクリプションで利用でき、Red Hat, Inc のサポートが含まれています。

en: Return Values
ja: 戻り値

en: Topics
ja: トピック

en: Ansible modules normally return a data structure that can be registered into a variable, or seen directly when output by the `ansible` program. Each module can optionally document its own unique return values (visible through ansible-doc and on the :ref:`main docsite<ansible_documentation>`).
ja: Ansible のモジュールは通常、データ構造を返します。このデータ構造は、変数に登録したり、`ansible` プログラムで出力されたときに直接確認したりできます。各モジュールは任意で、独自の戻り値をドキュメント化できます (ansible-doc や :ref:`メインのドキュメントサイト<ansible_documentation>` で確認できます)。

en: This document covers return values common to all modules.
ja: 本ガイドでは、全モジュールに共通する戻り値を説明します。

en: Some of these keys might be set by Ansible itself once it processes the module's return information.
ja: モジュールの戻り値情報の処理が終わると、Ansible によりこのキーの一部が設定される場合があります。

en: Common
ja: 共通

en: For those modules that implement `backup=no|yes` when manipulating files, a path to the backup file created.
ja: ファイルを操作するときに `backup=no|yes` を実装するモジュール向け。作成したバックアップファイルへのパス。

en: A boolean indicating if the task had to make changes to the target or delegated host.
ja: タスクがターゲットまたは委任されたホストに変更を加える必要があるかどうかを示すブール値。

en: Information on differences between the previous and current state. Often a dictionary with entries ``before`` and ``after``, which will then be formatted by the callback plugin to a diff view.
ja: 直前と現在の状態の相違点に関する情報。通常、``before`` と ``after`` のエントリーが含まれるディクショナリーを指し、callback プラグインによって、このディクショナリーが相違点のビュー書式に整えられます。

en: A boolean that indicates if the task was failed or not.
ja: タスクが失敗したかどうかを示すブール値。

en: Information on how the module was invoked.
ja: モジュールがどのように呼び出されたかを示す情報。

en: A string with a generic message relayed to the user.
ja: ユーザーに渡される一般的なメッセージを含む文字列。

en: Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on), this field contains 'return code' of these utilities.
ja: コマンドラインユーティリティーを実行したり、(raw、shell、command など) 直接コマンドを実行するように設定されているモジュール。このフィールドにはこのようなユーティリティーの「戻りコード」が含まれます。

en: If this key exists, it indicates that a loop was present for the task and that it contains a list of the normal module 'result' per item.
ja: このキーが存在する場合には、タスクに対してループが存在し、アイテムごとに通常のモジュールの「結果」が含まれていることを示します。

en: A boolean that indicates if the task was skipped or not
ja: タスクがスキップされたかどうかを示すブール値。

en: Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on), this field contains the error output of these utilities.
ja: コマンドラインユーティリティーを実行したり、(raw、shell、command などの) コマンドを直接実行するように調整されているモジュール。このフィールドにはこのようなユーティリティーのエラー出力が含まれます。

en: When `stderr` is returned we also always provide this field which is a list of strings, one item per line from the original.
ja: `stderr` が返されると、文字列のリストであるこのフィールドも常に表示されます (元の出力の 1 行に 1 項目)。

en: Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on). This field contains the normal output of these utilities.
ja: コマンドラインユーティリティーを実行したり、(raw、shell、command などの) コマンドを直接実行するように調整されているモジュール。このフィールドにはこのようなユーティリティーの通常出力が含まれます。

en: When `stdout` is returned, Ansible always provides a list of strings, each containing one item per line from the original output.
ja: `stdout` が返されると、Ansible は常に文字列のリスト (元の出力の 1 行に項目を 1 つ含める) を渡します。

en: Internal use
ja: Ansible 内での使用

en: These keys can be added by modules but will be removed from registered variables; they are 'consumed' by Ansible itself.
ja: 以下のキーはモジュールで追加できますが、登録変数からは削除されます。これらのキーは、Ansible 自体が「使用」します。

en: This key should contain a dictionary which will be appended to the facts assigned to the host. These will be directly accessible and don't require using a registered variable.
ja: このキーには、ホストに割り当てられたファクトに追加するディクショナリーが含まれているはずです。このキーは、直接アクセスでき、登録変数を使用する必要はありません。

en: This key can contain traceback information caused by an exception in a module. It will only be displayed on high verbosity (-vvv).
ja: このキーには、モジュールの例外で発生したトレースバックの情報が含まれます。これは、詳細レベルが高い (-vvv) 場合に限り表示されます。

en: This key contains a list of strings that will be presented to the user.
ja: このキーには、ユーザーに表示される文字列の一覧が含まれます。

en: This key contains a list of dictionaries that will be presented to the user. Keys of the dictionaries are `msg` and `version`, values are string, value for the `version` key can be an empty string.
ja: このキーには、ユーザーに表示されるディクショナリー一覧が含まれます。ディクショナリーのキーは `msg` と `version` で、値は文字列です。`version` キーの値は空白の文字列にすることができます。

en: Browse existing collections, modules, and plugins
ja: 既存のコレクション、モジュール、およびプラグインの閲覧

en: `GitHub modules directory <https://github.com/ansible/ansible/tree/devel/lib/ansible/modules>`_
ja: `GitHub モジュールディレクトリー <https://github.com/ansible/ansible/tree/devel/lib/ansible/modules>`_

en: Browse source of core and extras modules
ja: コアモジュールおよび追加モジュールのソースの参照

en: `Mailing List <https://groups.google.com/group/ansible-devel>`_
ja: `メーリングリスト<https://groups.google.com/group/ansible-devel>`_

en: Development mailing list
ja: 開発メーリングリスト

en: Ansible Configuration Settings
ja: Ansible 構成設定

en: Ansible supports several sources for configuring its behavior, including an ini file named ``ansible.cfg``, environment variables, command-line options, playbook keywords, and variables. See :ref:`general_precedence_rules` for details on the relative precedence of each source.
ja: Ansible は、``ansible.cfg`` という名前の ini ファイル、環境変数、コマンドラインオプション、Playbook のキーワード、変数など、動作を設定するための複数のソースをサポートします。各ソースの相対優先順位に関する詳細は「:ref:`general_precedence_rules`」を参照してください。

en: The ``ansible-config`` utility allows users to see all the configuration settings available, their defaults, how to set them and where their current value comes from. See :ref:`ansible-config` for more information.
ja: ``ansible-config`` ユーティリティーを使用すると、ユーザーは利用可能なすべての構成設定、デフォルト値、設定方法、および現在の値を受け取る場所を確認できます。詳細は「:ref:`ansible-config`」を参照してください。

en: The configuration file
ja: 設定ファイル

en: Changes can be made and used in a configuration file which will be searched for in the following order:
ja: 変更を行い、次の順序で検索される構成ファイルで使用できます。

en: ``ANSIBLE_CONFIG`` (environment variable if set)
ja: ``ANSIBLE_CONFIG`` (設定されている場合は環境変数メソッド)

en: ``ansible.cfg`` (in the current directory)
ja: ``ansible.cfg`` (現在のディレクトリー)

en: ``~/.ansible.cfg`` (in the home directory)
ja: ``~/.ansible.cfg`` (ホームディレクトリー)

en: Ansible will process the above list and use the first file found, all others are ignored.
ja: Ansible は上記の一覧を処理し、見つかった最初のファイルを使用しますが、その他はすべて無視されます。

en: The configuration file is one variant of an INI format. Both the hash sign (``#``) and semicolon (``;``) are allowed as comment markers when the comment starts the line. However, if the comment is inline with regular values, only the semicolon is allowed to introduce the comment. For instance::
ja: 設定ファイルは、INI 形式の 1 つのバリアントです。コメントが行を開始する場合は、ハッシュ記号 (``#``) とセミコロン (``;``) の両方がコメントマーカーとして許可されます。ただし、コメントが通常の値でインラインである場合は、セミコロンだけがコメントを追加できます。以下に例を示します。

en: Avoiding security risks with ``ansible.cfg`` in the current directory
ja: 現行ディレクトリーで ``ansible.cfg`` を使用したセキュリティーリスクを回避

en: If Ansible were to load ``ansible.cfg`` from a world-writable current working directory, it would create a serious security risk. Another user could place their own config file there, designed to make Ansible run malicious code both locally and remotely, possibly with elevated privileges. For this reason, Ansible will not automatically load a config file from the current working directory if the directory is world-writable.
ja: Ansible が、グローバルで書き込み可能な現在の作業ディレクトリーから ``ansible.cfg`` を読み込んだ場合は、深刻なセキュリティーリスクが発生します。別のユーザーが、場合により昇格した権限で Ansible がローカルとリモートの両方で悪意のあるコードを実行するように設計された独自の構成ファイルをそこに配置できます。そのため、ディレクトリーが誰でも書き込み可能な状態である場合、Ansible は現在の作業ディレクトリーから設定ファイルを自動的に読み込みません。

en: If you depend on using Ansible with a config file in the current working directory, the best way to avoid this problem is to restrict access to your Ansible directories to particular user(s) and/or group(s). If your Ansible directories live on a filesystem which has to emulate Unix permissions, like Vagrant or Windows Subsystem for Linux (WSL), you may, at first, not know how you can fix this as ``chmod``, ``chown``, and ``chgrp`` might not work there. In most of those cases, the correct fix is to modify the mount options of the filesystem so the files and directories are readable and writable by the users and groups running Ansible but closed to others.  For more details on the correct settings, see:
ja: 現在の作業ディレクトリーの設定ファイルで Ansible を使用する場合、この問題を回避する最善の方法は、Ansible ディレクトリーへのアクセスを特定のユーザーやグループに制限することです。Ansible ディレクトリーが、Vagrant や Windows Subsystem for Linux (WSL) などの Unix パーミッションをエミュレートする必要があるファイルシステムに存在する場合、そこでは ``chmod``、``chown``、および ``chgrp`` が機能しない可能性があるため、最初はどのように修正するか分からない場合があります。ほとんどの場合は、適切な修正が、ファイルシステムのマウントオプションを修正することです。これにより、ファイルおよびディレクトリーは、Ansible を実行しているユーザーおよびグループが読み取りおよび書き込みをできるようになり、他のユーザーには許可しないようにすることができます。正しい設定の詳細は、以下を参照してください。

en: for Vagrant, the `Vagrant documentation <https://www.vagrantup.com/docs/synced-folders/>`_ covers synced folder permissions.
ja: Vagrant の場合、`Vagrant documentation <https://www.vagrantup.com/docs/synced-folders/>`_ は同期されたフォルダーのパーミッションに対応します。

en: for WSL, the `WSL docs <https://docs.microsoft.com/en-us/windows/wsl/wsl-config#set-wsl-launch-settings>`_ and this `Microsoft blog post <https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/>`_ cover mount options.
ja: WSL の場合、`WSL docs <https://docs.microsoft.com/en-us/windows/wsl/wsl-config#set-wsl-launch-settings>`_ とこの `Microsoft blog post <https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/>`_ はマウントオプションに対応しています。

en: If you absolutely depend on storing your Ansible config in a world-writable current working directory, you can explicitly specify the config file via the :envvar:`ANSIBLE_CONFIG` environment variable. Please take appropriate steps to mitigate the security concerns above before doing so.
ja: 誰でも書き込み可能な現在の作業ディレクトリーに Ansible 設定を保存することを完全に依存している場合は、:envvar:`ANSIBLE_CONFIG` 環境変数を介して設定ファイルを明示的に指定できます。セキュリティーに関する懸念を軽減するための適切な手順を実行してください。

en: Relative paths for configuration
ja: 設定の相対パス

en: You can specify a relative path for many configuration options. In most of those cases the path used will be relative to the ``ansible.cfg`` file used for the current execution. If you need a path relative to your current working directory (CWD) you can use the ``{{CWD}}`` macro to specify it. We do not recommend this approach, as using your CWD as the root of relative paths can be a security risk. For example: ``cd /tmp; secureinfo=./newrootpassword ansible-playbook ~/safestuff/change_root_pwd.yml``.
ja: 多くの設定オプションに相対パスを指定できます。ほとんどの場合、使用されるパスは、現在の実行に使用される ``ansible.cfg`` ファイルの相対パスになります。現在の作業ディレクトリー (CWD) への相対パスが必要な場合は、``{{CWD}}`` マクロを使用して指定できます。相対パスのルートとして CWD を使用するとセキュリティーリスクが発生する可能性があるため、この方法は推奨されません。たとえば、``cd /tmp; secureinfo=./newrootpassword ansible-playbook ~/safestuff/change_root_pwd.yml`` となります。

en: Common Options
ja: 共通オプション

en: This is a copy of the options available from our release, your local install might have extra options due to additional plugins, you can use the command line utility mentioned above (`ansible-config`) to browse through those.
ja: これは、リリースで利用可能なオプションのコピーで、追加プラグインにより、ローカルインストールに追加のオプションが存在する可能性があります。上記のコマンドラインユーティリティー (`ansible-config`) を使用して、これらを閲覧することができます。

en: Description
ja: 説明

en: By default Ansible will issue a warning when received from a task action (module or action plugin) These warnings can be silenced by adjusting this setting to False.
ja: デフォルトでは、Ansible はタスクアクション (モジュールまたは action プラグイン) から受け取ると、警告を False に調整することで警告を非表示にすることができます。

en: Type
ja: タイプ

en: Default
ja: デフォルト

en: Version Added
ja: 追加されたバージョン

en: Section
ja: セクション

en: Key
ja: キー

en: Environment
ja: 環境

en: Variable
ja: 変数

en: Display an agnostic become prompt instead of displaying a prompt containing the command line supplied become method
ja: become メソッドを提供するコマンドラインを含むプロンプトを表示する代わりに、依存しない become プロンプトを表示します。

en: This setting has been moved to the individual shell plugins as a plugin option :ref:`shell_plugins`. The existing configuration settings are still accepted with the shell plugin adding additional options, like variables. This message will be removed in 2.14.
ja: この設定は、プラグインオプション :ref:`shell_plugins` として個々のシェルプラグインに移動しました。既存の設定は、変数などのオプションを追加するシェルプラグインで使用できます。このメッセージは 2.14 で削除されます。

en: Deprecated in
ja: 非推奨になるバージョン

en: Deprecated detail
ja: 非推奨の詳細

en: moved to shell plugins
ja: シェルプラグインに移動

en: Deprecated alternatives
ja: 非推奨の代替手段

en: Specify where to look for the ansible-connection script. This location will be checked before searching $PATH. If null, ansible will start with the same directory as the ansible script.
ja: ansible-connection スクリプトを探す場所を指定します。この場所は、$PATH の検索前に確認されます。null に設定すると、Ansible は ansible スクリプトと同じディレクトリーで起動します。

en: None
ja: なし

en: White list of cowsay templates that are 'safe' to use, set to empty list if you want to enable all installed templates.
ja: 「安全」に使用できる cowsay テンプレートのホワイトリスト。インストールされたすべてのテンプレートを有効にする場合は空のリストに設定します。

en: normalizing names to new standard
ja: 名前を新しい標準に正規化

en: Specify a custom cowsay path or swap in your cowsay implementation of choice
ja: 選択する Cowsay 実装でカスタムの Cowsay パスまたは swap を指定します。

en: This allows you to chose a specific cowsay stencil for the banners or use 'random' to cycle through them.
ja: これにより、バナーの特定の cowsay ステンシルを選択するか、「random」を使用してバナーを循環させることができます。

en: This option forces color mode even when running without a TTY or the "nocolor" setting is True.
ja: このオプションは、TTY を使用せずに実行し、または「nocolor」設定が True であっても色モードを強制的に実行します。

en: This setting allows suppressing colorizing output, which is used to give a better indication of failure and status information.
ja: この設定により、色付け出力を抑制できます。これは、障害およびステータスの情報をより適切に示すために使用されます。

en: If you have cowsay installed but want to avoid the 'cows' (why????), use this.
ja: cowsay がインストールされているにもかかわらず、「cows」を回避するには、これを使用します。

en: Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer. This can result in a very significant performance improvement when enabled. However this conflicts with privilege escalation (become). For example, when using 'sudo:' operations you must first disable 'requiretty' in /etc/sudoers on all managed hosts, which is why it is disabled by default. This option is disabled if ``ANSIBLE_KEEP_REMOTE_FILES`` is enabled. This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all.
ja: パイプライン (connection プラグインでサポートされる場合) は、実際のファイル転送を行わずに多数の Ansible モジュールを実行して、リモートサーバーでモジュールを実行するために必要なネットワーク操作の数を減らします。これにより、有効にするとパフォーマンスが大幅に改善する可能性があります。ただし、これは特権昇格 (become) と競合します。たとえば、「sudo:」操作を使用する場合は、すべての管理対象ホストの /etc/sudoers で「requiretty」を無効にする必要があります。これが、デフォルトで無効になっている理由です。``ANSIBLE_KEEP_REMOTE_FILES`` が有効な場合、このオプションは無効になります。これはグローバルオプションであり、各 connection プラグインは、より具体的なオプションを指定するか、パイプライン処理をサポートしないかのいずれかによりオーバーライドすることができます。

en: Sets the default value for the any_errors_fatal keyword, if True, Task failures will be considered fatal errors.
ja: any_errors_fatal キーワードのデフォルト値を設定します。True の場合、タスクの失敗は致命的なエラーとみなされます。

en: This setting controls if become is skipped when remote user and become user are the same. I.E root sudo to root.
ja: この設定は、リモートユーザーと become ユーザーが同じである場合に、become をスキップするかどうかを制御します。つまり、root sudo から root に変更できます。

en: Colon separated paths in which Ansible will search for Become Plugins.
ja: Ansible が Become プラグインを検索するコロン区切りパス。

en: Chooses which cache plugin to use, the default 'memory' is ephemeral.
ja: 使用する cache プラグインを選択します。デフォルトの「メモリー」は一時的です。

en: Defines connection or path information for the cache plugin
ja: cache プラグインの接続またはパスの情報を定義

en: Prefix to use for cache plugin files/tables
ja: cache プラグインファイル/テーブルに使用する接頭辞

en: Expiration timeout for the cache plugin data
ja: cache プラグインデータの有効期限のタイムアウト

en: Whitelist of callable methods to be made available to template evaluation
ja: テンプレート評価で利用できる呼び出し可能なメソッドのホワイトリスト

en: List of enabled callbacks, not all callbacks need enabling, but many of those shipped with Ansible do as we don't want them activated by default.
ja: 有効なコールバックのリストです。すべてのコールバックを有効にする必要はありませんが、Ansible に同梱されるコールバックの多くは、デフォルトでアクティブ化されたくないため、そのようになっています。

en: When a collection is loaded that does not support the running Ansible version (via the collection metadata key `requires_ansible`), the default behavior is to issue a warning and continue anyway. Setting this value to `ignore` skips the warning entirely, while setting it to `fatal` will immediately halt Ansible execution.
ja: (コレクションメタデータキー `requires_ansible` を介して) 実行中の Ansible バージョンをサポートしないコレクションが読み込まれると、デフォルトの動作では、警告を表示してとにかく続行します。この値を `ignore` に設定すると警告を完全に飛ばします。`fatal` に設定すると、Ansible の実行をすぐに停止します。

en: Choices
ja: 選択肢

en: Colon separated paths in which Ansible will search for collections content. Collections must be in nested *subdirectories*, not directly in these directories. For example, if ``COLLECTIONS_PATHS`` includes ``~/.ansible/collections``, and you want to add ``my.collection`` to that directory, it must be saved as ``~/.ansible/collections/ansible_collections/my/collection``.
ja: Ansible がコレクションコンテンツを検索するコロン区切りパス。コレクションは、これらのディレクトリーに直接ではなく、入れ子の * サブディレクトリー* に置かれる必要があります。たとえば、``COLLECTIONS_PATHS`` には ``~/.ansible/collections`` が含まれ、そのディレクトリーに ``my.collection`` を追加する場合は、``~/.ansible/collections/ansible_collections/my/collection`` として保存する必要があります。

en: A boolean to enable or disable scanning the sys.path for installed collections
ja: インストールされたコレクションの sys.path のスキャンを有効または無効にするブール値

en: Defines the color to use on 'Changed' task status
ja: 「Changed」タスクの状態に使用する色を定義

en: Defines the default color to use for ansible-console
ja: ansible-console に使用するデフォルトの色を定義します。

en: Defines the color to use when emitting debug messages
ja: デバッグメッセージを生成する際に使用する色を定義します。

en: Defines the color to use when emitting deprecation messages
ja: 非推奨メッセージを生成するときに使用する色を定義します。

en: Defines the color to use when showing added lines in diffs
ja: diffs で追加した行を表示するときに使用する色を定義します。

en: Defines the color to use when showing diffs
ja: 差異を表示するときに使用する色を定義します。

en: Defines the color to use when showing removed lines in diffs
ja: diffs で削除した行を表示するときに使用する色を定義します。

en: Defines the color to use when emitting error messages
ja: エラーメッセージを生成する際に使用する色を定義します。

en: Defines the color to use for highlighting
ja: 強調表示に使用する色を定義します。

en: Defines the color to use when showing 'OK' task status
ja: タスク状態「OK」を表示するときに使用する色を定義します。

en: Defines the color to use when showing 'Skipped' task status
ja: タスク状態「Skipped」を表示するときに使用する色を定義します。

en: Defines the color to use on 'Unreachable' status
ja: タスク状態「到達不能」状態で使用する色を定義します。

en: Defines the color to use when emitting verbose messages. i.e those that show with '-v's.
ja: 詳細メッセージを生成する際に使用する色を定義します (つまり、'-v's で示されるものとなります)。

en: Defines the color to use when emitting warning messages
ja: 警告メッセージを生成するときに使用する色を定義します。

en: Ansible can issue a warning when the shell or command module is used and the command appears to be similar to an existing Ansible module. These warnings can be silenced by adjusting this setting to False. You can also control this at the task level with the module option ``warn``. As of version 2.11, this is disabled by default.
ja: Ansible は、シェルまたはコマンドモジュールが使用され、コマンドが既存の Ansible モジュールと類似しているように見えます。これらの設定を False に設定することで、これらの警告を非表示にすることができます。また、モジュールのオプション ``warn`` を使用してタスクレベルで制御することもできます。バージョン 2.11 の時点で、これはデフォルトでは無効になっています。

en: the command warnings feature is being removed
ja: コマンド警告機能が削除されています。

en: With this setting on (True), running conditional evaluation 'var' is treated differently than 'var.subkey' as the first is evaluated directly while the second goes through the Jinja2 parser. But 'false' strings in 'var' get evaluated as booleans. With this setting off they both evaluate the same but in cases in which 'var' was 'false' (a string) it won't get evaluated as a boolean anymore. Currently this setting defaults to 'True' but will soon change to 'False' and the setting itself will be removed in the future. Expect that this setting eventually will be deprecated after 2.12
ja: この設定を (True) にすると、条件付き評価「var」の実行は「var.subkey」とは異なる方法で処理されます。最初の評価は直接評価され、2 番目の評価は Jinja2 パーサーを通過するためです。ただし、「var」の「false」文字列はブール値として評価されます。この設定をオフにすると、どちらも同じように評価されますが、「var」が「false」(文字列) の場合は、ブール値として評価されなくなります。現在、この設定のデフォルトは「True」ですが、まもなく「False」に変更され、将来のバージョンで設定自体が削除されます。この設定は、2.12 以降で最終的に非推奨になると予想されます。

en: Which modules to run during a play's fact gathering stage based on connection
ja: 接続に基づいてプレイのファクト収集ステージ時に実行するモジュール

en: Toggle to control showing warnings related to running a Python version older than Python 3.8 on the controller
ja: コントローラーで Python 3.8 よりも古い Python の実行に関連する警告の表示を制御するように切り替えます。

en: Sets the output directory on the remote host to generate coverage reports to. Currently only used for remote coverage on PowerShell modules. This is for internal use only.
ja: リモートホストの出力ディレクトリーを設定してカバレッジレポートを生成します。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。

en: Variables
ja: 変数

en: A list of paths for files on the Ansible controller to run coverage for when executing on the remote host. Only files that match the path glob will have its coverage collected. Multiple path globs can be specified and are separated by ``:``. Currently only used for remote coverage on PowerShell modules. This is for internal use only.
ja: リモートホストで実行するときにカバレッジを実行する Ansible コントローラー上のファイルのパスのリスト。パスグロブに一致するファイルのみがカバレッジを収集します。パスグロブは、``:`` で区切ることで複数指定できます。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。

en: Colon separated paths in which Ansible will search for Action Plugins.
ja: Ansible が Action プラグインを検索するコロン区切りパス。

en: When enabled, this option allows lookup plugins (whether used in variables as ``{{lookup('foo')}}`` or as a loop as with_foo) to return data that is not marked 'unsafe'. By default, such data is marked as unsafe to prevent the templating engine from evaluating any jinja2 templating language, as this could represent a security risk.  This option is provided to allow for backwards-compatibility, however users should first consider adding allow_unsafe=True to any lookups which may be expected to contain data which may be run through the templating engine late
ja: このオプションを有効にすると、(変数で ``{{lookup('foo')}}`` として、または with_foo のようなループとして使用されているかに関係なく) lookup プラグインが「安全でない」と表示されていないデータを返します。デフォルトでは、このようなデータは、テンプレートエンジンが jinja2 テンプレート言語を評価できないようにするために、安全ではないと表示されています。これは、セキュリティーリスクを示している場合があるためです。このオプションは、下位互換性を確保するために提供されていますが、ユーザーはまず、後でテンプレートエンジンを介して実行する可能性のあるデータが含まれていると予想されるルックアップに allow_unsafe=True を追加することを検討する必要があります。

en: This controls whether an Ansible playbook should prompt for a login password. If using SSH keys for authentication, you probably do not needed to change this setting.
ja: これは、Ansible Playbook がログインパスワードを要求するかどうかを制御します。認証に SSH 鍵を使用する場合は、この設定を変更する必要がない可能性があります。

en: This controls whether an Ansible playbook should prompt for a vault password.
ja: これは、Ansible Playbook が Vault パスワードを要求するかどうかを制御します。

en: Toggles the use of privilege escalation, allowing you to 'become' another user after login.
ja: 権限昇格の使用を切り替えて、ログイン後に別のユーザーになる (「become」) ことができるようにします。

en: Toggle to prompt for privilege escalation password.
ja: 切り替えて、権限昇格パスワードの入力を求めます。

en: executable to use for privilege escalation, otherwise Ansible will depend on PATH
ja: 特権昇格に使用する実行ファイル。それ以外の場合、Ansible は PATH に依存します。

en: Flags to pass to the privilege escalation executable.
ja: 権限昇格実行ファイルに渡すフラグ。

en: Privilege escalation method to use when `become` is enabled.
ja: `become` が有効な場合に使用する権限昇格方法です。

en: The user your login/remote user 'becomes' when using privilege escalation, most systems will use 'root' when no user is specified.
ja: 権限昇格を使用する際にログイン/リモートユーザーが「なる(becomes)」ユーザー。ユーザーを指定しないと、ほとんどのシステムは「root」を使用します。

en: Colon separated paths in which Ansible will search for Cache Plugins.
ja: Ansible が Cache プラグインを検索するコロン区切りパス。

en: Colon separated paths in which Ansible will search for Callback Plugins.
ja: Ansible が Callback プラグインを検索するコロン区切りパス。

en: Colon separated paths in which Ansible will search for Cliconf Plugins.
ja: Ansible が Cliconf プラグインを検索するコロン区切りパス。

en: Colon separated paths in which Ansible will search for Connection Plugins.
ja: Ansible が connection プラグインを検索するコロン区切りパス。

en: Toggles debug output in Ansible. This is *very* verbose and can hinder multiprocessing.  Debug output can also include secret information despite no_log settings being enabled, which means debug mode should not be used in production.
ja: Ansible でデバッグ出力を切り替えます。これは *非常に* 詳細であり、マルチプロセッシングを妨げる可能性があります。no_log 設定が有効になっている場合でも、デバッグ出力に秘密情報を含めることができます。つまり、デバッグモードは、実稼働環境で使用しないでください。

en: This indicates the command to use to spawn a shell under for Ansible's execution needs on a target. Users may need to change this in rare instances when shell usage is constrained, but in most cases it may be left as is.
ja: これは、ターゲットでの Ansible の実行ニーズに合わせてシェルを生成するために使用するコマンドを示します。シェルの使用が制限されている場合、ユーザーはまれにこれを変更する必要がありますが、ほとんどの場合、そのままにしておくことができます。

en: This option allows you to globally configure a custom path for 'local_facts' for the implied M(ansible.builtin.setup) task when using fact gathering. If not set, it will fallback to the default from the M(ansible.builtin.setup) module: ``/usr/local/etc/ansible/facts.d``. This does **not** affect  user defined tasks that use the M(ansible.builtin.setup) module.
ja: このオプションを使用すると、ファクト収集を使用するときに、暗黙の M(ansible.builtin.setup) タスクの「local_facts」のカスタムパスをグローバルに設定できます。設定されていない場合は、M(ansible.builtin.setup) モジュールからデフォルトにフォールバックします (``/usr/local/etc/ansible/facts.d``)。これは、M(ansible.builtin.setup)  モジュールを使用するユーザー定義のタスクには **影響しません**。

en: Colon separated paths in which Ansible will search for Jinja2 Filter Plugins.
ja: Ansible が Jinja2 フィルタープラグインを検索するコロン区切りパス。

en: This option controls if notified handlers run on a host even if a failure occurs on that host. When false, the handlers will not run if a failure has occurred on a host. This can also be set per play or on the command line. See Handlers and Failure for more details.
ja: このオプションは、ホストで障害が発生した場合でも、通知されたハンドラーがホストで実行されるかどうかを制御します。false にすると、ホストで障害が発生した場合に、ハンドラーは実行されません。これは、プレイごとまたはコマンドラインで設定することもできます。詳細は、「ハンドラーおよび失敗」を参照してください。

en: Maximum number of forks Ansible will use to execute tasks on target hosts.
ja: ターゲットホストでタスクを実行するのに Ansible が使用するフォークの最大数。

en: Set the `gather_subset` option for the M(ansible.builtin.setup) task in the implicit fact gathering. See the module documentation for specifics. It does **not** apply to user defined M(ansible.builtin.setup) tasks.
ja: 暗黙的なファクト収集の M(ansible.builtin.setup) タスクに `gather_subset` オプションを設定します。詳細は、モジュールドキュメントを参照してください。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。

en: Set the timeout in seconds for the implicit fact gathering. It does **not** apply to user defined M(ansible.builtin.setup) tasks.
ja: 暗黙的なファクト収集のタイムアウトを秒単位で設定します。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。

en: This setting controls the default policy of fact gathering (facts discovered about remote systems). When 'implicit' (the default), the cache plugin will be ignored and facts will be gathered per play unless 'gather_facts: False' is set. When 'explicit' the inverse is true, facts will not be gathered unless directly requested in the play. The 'smart' value means each new host that has no facts discovered will be scanned, but if the same host is addressed in multiple plays it will not be contacted again in the playbook run. This option can be useful for those wishing to save fact gathering time. Both 'smart' and 'explicit' will use the cache plugin.
ja: この設定は、ファクト収集 (リモートシステムに関して検出されたファクト) のデフォルトポリシーを制御します。「implicit」(デフォルト) の場合、cache プラグインは無視され、「gather_facts: False」が設定されていない限り、プレイごとにファクトが収集されます。「explicit」の場合はその逆で、プレイ中に直接要求されない限り、ファクトは収集されません。「smart」の値は、検出されたファクトを持たない各新規ホストがスキャンされることを意味しますが、同じホストが複数のプレイで扱われた場合は、Playbook の実行中に再び接触することはありません。このオプションは、ファクト収集の時間を短縮したい場合に便利です。「smart」と「explicit」の両方とも、cache プラグインを使用します。

en: Since 2.0 M(ansible.builtin.include) can be 'dynamic', this setting (if True) forces that if the include appears in a ``handlers`` section to be 'static'.
ja: 2.0 M(ansible.builtin.include) は「動的」である可能性があるため、この設定 (True の場合) は、``handlers`` セクションに表示されるインクルードが「静的」になります。

en: include itself is deprecated and this setting will not matter in the future
ja: インクルード自体は非推奨であるため、この設定は今後重要ではありません。

en: none as its already built into the decision between include_tasks and import_tasks
ja: include_tasks と import_tasks の決定にすでに組み込まれてるため、none です。

en: This setting controls how duplicate definitions of dictionary variables (aka hash, map, associative array) are handled in Ansible. This does not affect variables whose values are scalars (integers, strings) or arrays. **WARNING**, changing this setting is not recommended as this is fragile and makes your content (plays, roles, collections) non portable, leading to continual confusion and misuse. Don't change this setting unless you think you have an absolute need for it. We recommend avoiding reusing variable names and relying on the ``combine`` filter and ``vars`` and ``varnames`` lookups to create merged versions of the individual variables. In our experience this is rarely really needed and a sign that too much complexity has been introduced into the data structures and plays. For some uses you can also look into custom vars_plugins to merge on input, even substituting the default ``host_group_vars`` that is in charge of parsing the ``host_vars/`` and ``group_vars/`` directories. Most users of this setting are only interested in inventory scope, but the setting itself affects all sources and makes debugging even harder. All playbooks and roles in the official examples repos assume the default for this setting. Changing the setting to ``merge`` applies across variable sources, but many sources will internally still overwrite the variables. For example ``include_vars`` will dedupe variables internally before updating Ansible, with 'last defined' overwriting previous definitions in same file. The Ansible project recommends you **avoid ``merge`` for new projects.** It is the intention of the Ansible developers to eventually deprecate and remove this setting, but it is being kept as some users do heavily rely on it. New projects should **avoid 'merge'**.
ja: この設定は、辞書変数 (別名ハッシュ、マップ、連想配列) の重複した定義を Ansible でどのように扱うかを制御します。この設定は、値がスカラー (整数、文字列) や配列である変数には影響しません。**警告** これは脆弱で、コンテンツ (プレイ、ロール、コレクション) が移植できなくなり、継続的な混乱と誤用を招く恐れがあるため、この設定を変更することは推奨されません。絶対に必要だと思われる場合を除き、この設定を変更しないでください。変数名の再利用は回避し、``combine`` フィルターと``vars`` ルックアップおよび``varnames`` ルックアップを利用して、個々の変数のマージバージョンを作成することが推奨されます。経験上、このようなことが本当に必要とされることはほとんどなく、データ構造やプレイが複雑になりすぎていることを示しています。用途によっては、入力時にマージするカスタム vars_plugins を検討することもできますし、``host_vars/`` ディレクトリーおよび ``group_vars/`` ディレクトリーの解析を担当するデフォルトの ``host_group_vars`` を置き換えることもできます。この設定のほとんどのユーザーはインベントリースコープにしか興味がありませんが、この設定自体がすべてのソースに影響し、デバッグをさらに困難にします。公式のサンプルリポジトリーにある Playbook およびロールはすべて、この設定のデフォルトを想定しています。``merge`` に設定を変更すると、変数ソース全体に適用されますが、多くのソースでは内部的に変数が上書きされたままになります。たとえば、``include_vars`` は、Ansible を更新する前に内部で変数の重複を排除し、「最終定義」が同じファイルの以前の定義を上書きします。Ansible プロジェクトでは、**新規プロジェクトでは ``merge`` を回避する** ことが推奨されます。Ansible 開発者は、最終的にこの設定を非推奨にして削除することを意図していますが、一部のユーザーがこの設定に大きく依存しているため、この設定を残しています。新しいプロジェクトでは、**「merge」を回避** してください。

en: Any variable that is defined more than once is overwritten using the order from variable precedence rules (highest wins).
ja: 複数の変数が定義されている変数は、変数の優先順位ルール (最も高いものが優先されます) の順序を使用して上書きされます。

en: Any dictionary variable will be recursively merged with new definitions across the different variable definition sources.
ja: ディクショナリー変数は、異なる変数定義ソース全体で新しい定義と再帰的にマージされます。

en: Comma separated list of Ansible inventory sources
ja: Ansible インベントリーソースのコンマ区切り一覧

en: Colon separated paths in which Ansible will search for HttpApi Plugins.
ja: Ansible が HttpApi プラグインを検索するコロン区切りパス。

en: This sets the interval (in seconds) of Ansible internal processes polling each other. Lower values improve performance with large playbooks at the expense of extra CPU load. Higher values are more suitable for Ansible usage in automation scenarios, when UI responsiveness is not required but CPU usage might be a concern. The default corresponds to the value hardcoded in Ansible <= 2.1
ja: これにより、Ansible の内部プロセスが相互にポーリングする間隔 (秒単位) が設定されます。値を低くすると、CPU の負荷が増える代わりに、大きな Playbook のパフォーマンスが改善します。UI の応答性は必要ありませんが、CPU 使用率が問題になる可能性がある場合は、自動化シナリオでの Ansible の使用には高い値が適しています。デフォルトは、2.1 以下の Ansible でハードコードされた値に対応します

en: Colon separated paths in which Ansible will search for Inventory Plugins.
ja: Ansible が inventory プラグインを検索するコロン区切りパス。

en: This is a developer-specific feature that allows enabling additional Jinja2 extensions. See the Jinja2 documentation for details. If you do not know what these do, you probably don't need to change this setting :)
ja: これは、追加の Jinja2 拡張機能を有効にすることができる開発者固有の機能です。詳細については、Jinja2 ドキュメントを参照してください。この拡張機能が何をするのかわからない場合は、おそらくこの設定を変更する必要はありません。

en: This option preserves variable types during template operations. This requires Jinja2 >= 2.10.
ja: このオプションは、テンプレート操作中、変数タイプを保持します。これには Jinja2 >= 2.10 が必要です。

en: Enables/disables the cleaning up of the temporary files Ansible used to execute the tasks on the remote. If this option is enabled it will disable ``ANSIBLE_PIPELINING``.
ja: リモートでタスクを実行するために Ansible が使用する一時ファイルのクリーンアップを有効または無効にします。このオプションを有効にすると、``ANSIBLE_PIPELINING`` を無効にします。

en: This setting causes libvirt to connect to lxc containers by passing --noseclabel to virsh. This is necessary when running on systems which do not have SELinux.
ja: この設定により、--noseclabel を virsh に渡して、libvirt が lxc コンテナーに接続します。これは、SELinux がないシステムで実行する際に必要です。

en: environment variables without ``ANSIBLE_`` prefix are deprecated
ja: ``ANSIBLE_`` 接頭辞のない環境変数が非推奨になりました。

en: the ``ANSIBLE_LIBVIRT_LXC_NOSECLABEL`` environment variable
ja: ``ANSIBLE_LIBVIRT_LXC_NOSECLABEL`` 環境変数

en: Controls whether callback plugins are loaded when running /usr/bin/ansible. This may be used to log activity from the command line, send notifications, and so on. Callback plugins are always loaded for ``ansible-playbook``.
ja: /usr/bin/ansible の実行時に callback プラグインを読み込まれるかどうかを制御します。これは、コマンドラインからのアクティビティのログ記録、通知の送信などに使用できます。``ansible-playbook`` に callback プラグインが常に読み込まれます。

en: Temporary directory for Ansible to use on the controller.
ja: Ansible がコントローラーで使用するための一時ディレクトリー。

en: List of logger names to filter out of the log file
ja: ログファイルから除外するロガー名の一覧

en: File to which Ansible will log on the controller. When empty logging is disabled.
ja: Ansible がコントローラーにログインするファイル。空のロギングが無効になっている場合。

en: Colon separated paths in which Ansible will search for Lookup Plugins.
ja: Ansible が Lookup プラグインを検索するコロン区切りパス。

en: Sets the macro for the 'ansible_managed' variable available for M(ansible.builtin.template) and M(ansible.windows.win_template) modules.  This is only relevant for those two modules.
ja: M(ansible.builtin.template) モジュールおよび M(ansible.windows.win_template) モジュールで使用可能な「ansible_managed」変数にマクロを設定します。これは、これら 2 つのモジュールにのみ関係します。

en: Ansible managed
ja: Ansible が管理

en: This sets the default arguments to pass to the ``ansible`` adhoc binary if no ``-a`` is specified.
ja: これにより、``ansible`` が指定されていない場合に、``-a`` アドホックバイナリーに渡すデフォルトの引数が設定されます。

en: Compression scheme to use when transferring Python modules to the target.
ja: Python モジュールをターゲットに転送する際に使用する圧縮スキーム。

en: Module to use with the ``ansible`` AdHoc command, if none is specified via ``-m``.
ja: ``-m`` で何も指定されていない場合は、``ansible`` AdHoc コマンドで使用するモジュール。

en: Colon separated paths in which Ansible will search for Modules.
ja: Ansible がモジュールを検索するコロン区切りパス。

en: Colon separated paths in which Ansible will search for Module utils files, which are shared by modules.
ja: モジュールが共有するモジュールのユーティリティーファイルを Ansible が検索するコロン区切りパス。

en: Colon separated paths in which Ansible will search for Netconf Plugins.
ja: Ansible が Netconf プラグインを検索するコロン区切りパス。

en: Toggle Ansible's display and logging of task details, mainly used to avoid security disclosures.
ja: 主にセキュリティーの公開を回避するために、Ansible の表示およびタスク詳細のロギングを使用します。

en: Toggle Ansible logging to syslog on the target when it executes tasks. On Windows hosts this will disable a newer style PowerShell modules from writting to the event log.
ja: タスクの実行時に、Ansible ログをターゲットの syslog へ切り替えます。Windows ホストでは、これにより、新しいスタイルの PowerShell モジュールがイベントログに書き込むことができなくなります。

en: What templating should return as a 'null' value. When not set it will let Jinja2 decide.
ja: テンプレートが「null」値として返すもの。設定しないと、Jinja2 が決定します。

en: For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how often to check back on the status of those tasks when an explicit poll interval is not supplied. The default is a reasonably moderate 15 seconds which is a tradeoff between checking in frequently and providing a quick turnaround when something may have completed.
ja: Ansible の非同期タスク (「非同期アクションとポーリング」で説明) の場合、これは、明示的なポーリング間隔が指定されていない場合に、これらのタスクのステータスを確認する頻度です。デフォルトは適度に中程度の 15 秒です。これは、頻繁に確認することと、何かが完了したときに迅速に対応することとのトレードオフになっています。

en: Option for connections using a certificate or key file to authenticate, rather than an agent or passwords, you can set the default value here to avoid re-specifying --private-key with every invocation.
ja: エージェントやパスワードではなく、証明書またはキーファイルを使用して認証する接続のオプション。ここでデフォルト値を設定して、呼び出しごとに --private-key が再指定されないようにすることができます。

en: Makes role variables inaccessible from other roles. This was introduced as a way to reset role variables to default values if a role is used more than once in a playbook.
ja: ロール変数が他のロールからアクセスできないようにします。これは、Playbook でロールが複数回使用されている場合に、ロール変数をデフォルト値にリセットする方法として導入されました。

en: Port to use in remote connections, when blank it will use the connection plugin default.
ja: リモート接続で使用するポート。空の場合は、connection プラグインのデフォルトを使用します。

en: Sets the login user for the target machines When blank it uses the connection plugin's default, normally the user currently executing Ansible.
ja: ターゲットマシンのログインユーザーを設定します。空の場合は、connection プラグインのデフォルト (通常は現在 Ansible を実行しているユーザー) を使用します。

en: Colon separated paths in which Ansible will search for Roles.
ja: Ansible がロールを検索するコロン区切りパス。

en: Some filesystems do not support safe operations and/or return inconsistent errors, this setting makes Ansible 'tolerate' those in the list w/o causing fatal errors. Data corruption may occur and writes are not always verified when a filesystem is in the list.
ja: 一部のファイルシステムは安全な操作をサポートしていないか、一貫性のないエラーを返します。この設定により、Ansible はリスト内のエラーを「許容」し、致命的なエラーを引き起こしません。ファイルシステムがリストに含まれていると、データが破損する可能性があり、書き込みが常に検証されるとは限りません。

en: Set the main callback used to display Ansible output, you can only have one at a time. You can have many other callbacks, but just one can be in charge of stdout.
ja: Ansible 出力の表示に使用されるメインのコールバックを設定します。一度に 1 つしか使用できません。他にも多くのコールバックを設定できますが、stdout に使用できるのは 1 つだけです。

en: Set the default strategy used for plays.
ja: プレイに使用するデフォルトのストラテジーを設定します。

en: Colon separated paths in which Ansible will search for Strategy Plugins.
ja: Ansible が Strategy プラグインを検索するコロン区切りパス。

en: Toggle the use of "su" for tasks.
ja: タスクに「su」の使用を切り替えます。

en: Syslog facility to use when Ansible logs to the remote target
ja: Ansible がリモートターゲットにログを記録するときに使用する syslog ファシリティー

en: The `include` tasks can be static or dynamic, this toggles the default expected behaviour if autodetection fails and it is not explicitly set in task.
ja: `include` タスクは静的または動的にすることができます。これは、自動検出が失敗し、タスクに自動検出が明示的に設定されていない場合に、デフォルトの想定される動作を切り替えます。

en: None, as its already built into the decision between include_tasks and import_tasks
ja: include_tasks と import_tasks の決定にすでに組み込まれてるため、none です。

en: Colon separated paths in which Ansible will search for Terminal Plugins.
ja: Ansible が Terminal プラグインを検索するコロン区切りパス。

en: Colon separated paths in which Ansible will search for Jinja2 Test Plugins.
ja: Ansible が Jinja2 テストプラグインを検索するコロン区切りパス。

en: This is the default timeout for connection plugins to use.
ja: これは、connection プラグインが使用するデフォルトのタイムアウトです。

en: Default connection plugin to use, the 'smart' option will toggle between 'ssh' and 'paramiko' depending on controller OS and ssh versions
ja: 使用するデフォルトの connection プラグイン。「smart」オプションは、コントローラー OS と ssh のバージョンに応じて、「ssh」と「paramiko」の間で切り替えられます。

en: When True, this causes ansible templating to fail steps that reference variable names that are likely typoed. Otherwise, any '{{ template_expression }}' that contains undefined variables will be rendered in a template or ansible action line exactly as written.
ja: True にすると、タイプミスの可能性が高い変数名を参照するステップが失敗するテンプレートが作成されます。True に設定しないと、未定義の変数を含む '{{ template_expression }}' は、記述されたとおりにテンプレートまたは ansible のアクション行にレンダリングされます。

en: Colon separated paths in which Ansible will search for Vars Plugins.
ja: Ansible が Vars プラグインを検索するコロン区切りパス。

en: The vault_id to use for encrypting by default. If multiple vault_ids are provided, this specifies which to use for encryption. The --encrypt-vault-id cli option overrides the configured value.
ja: デフォルトで暗号化に使用する vault_id です。複数の vault_ids が提供されると、暗号化に使用するものを指定します。--encrypt-vault-id cli オプションは、設定した値をオーバーライドします。

en: If true, decrypting vaults with a vault id will only try the password from the matching vault-id
ja: true の場合、Vault id で Vault を復号すると、一致する Vault id からのみパスワードを試みます。

en: The label to use for the default vault id label in cases where a vault id label is not provided
ja: Vault id ラベルが指定されていない場合にデフォルトの Vault id ラベルに使用するラベル

en: A list of vault-ids to use by default. Equivalent to multiple --vault-id args. Vault-ids are tried in order.
ja: デフォルトで使用する vault-id の一覧。複数の --vault-id 引数と同等です。vault-ids は順番に試行されます。

en: The vault password file to use. Equivalent to --vault-password-file or --vault-id
ja: 使用する vault パスワードファイル。--vault-password-file または --vault-id と同等です。

en: Sets the default verbosity, equivalent to the number of ``-v`` passed in the command line.
ja: コマンドラインで渡された ``-v`` の数と同等の、デフォルトの詳細レベルを設定します。

en: Toggle to control the showing of deprecation warnings
ja: 非推奨の警告の表示を制御するために切り替え

en: Toggle to control showing warnings related to running devel
ja: devel の実行に関連する警告を表示するように制御を切り替え

en: Configuration toggle to tell modules to show differences when in 'changed' status, equivalent to ``--diff``.
ja: 構成の切り替えにより、「changed」状態のときに相違点を表示するようにモジュールに指示します (``--diff`` 相当)。

en: How many lines of context to show when displaying the differences between files.
ja: ファイル間の差異を表示する際に表示するコンテキストの行数。

en: Normally ``ansible-playbook`` will print a header for each task that is run. These headers will contain the name: field from the task if you specified one. If you didn't then ``ansible-playbook`` uses the task's action to help you tell which task is presently running. Sometimes you run many of the same action and so you want more information about the task to differentiate it from others of the same action. If you set this variable to True in the config then ``ansible-playbook`` will also include the task's arguments in the header. This setting defaults to False because there is a chance that you have sensitive values in your parameters and you do not want those to be printed. If you set this to True you should be sure that you have secured your environment's stdout (no one can shoulder surf your screen and you aren't saving stdout to an insecure file) or made sure that all of your playbooks explicitly added the ``no_log: True`` parameter to tasks which have sensitive values See How do I keep secret data in my playbook? for more information.
ja: 通常、``ansible-playbook`` は、実行された各タスクのヘッダーが出力されます。これらのヘッダーにはタスクの name: フィールドが指定されていればそれが含まれます。指定していない場合は、``ansible-playbook`` がタスクのアクションを使用して、どのタスクが現在実行されているかを知ることができます。同じアクションの多くを実行する場合は、同じアクションの他のタスクと区別するために、タスクに関する詳細情報が必要になることがあります。設定でこの変数を True に設定すると、``ansible-playbook`` では、タスクの引数もヘッダーに含まれます。パラメーターに機密性の高い値が含まれている可能性があり、それらを出力しないため、この設定の既定値は False です。これを True に設定した場合は、環境の標準出力 (誰もあなたの画面を肩越しに盗み見ることができず、あなたは標準出力を安全でないファイルに保存していません) を確実に保護するか、すべての Playbook で機密性の高い値を持つタスクに ``no_log: True`` パラメーターを明示的に追加する必要があります。詳細は、「Playbook に機密データを保存するにはどうすれば良いですか」を参照してください。

en: Toggle to control displaying skipped task/host entries in a task in the default callback
ja: デフォルトのコールバックのタスクにスキップされたタスク/ホストエントリーの表示を制御するように切り替えます。

en: the ``ANSIBLE_DISPLAY_SKIPPED_HOSTS`` environment variable
ja: ``ANSIBLE_DISPLAY_SKIPPED_HOSTS`` 環境変数

en: Colon separated paths in which Ansible will search for Documentation Fragments Plugins.
ja: Ansible が Documentation Fragment Plugins を検索するコロン区切りパス。

en: Root docsite URL used to generate docs URLs in warning/error text; must be an absolute URL with valid scheme and trailing slash.
ja: 警告/エラーテキストでドキュメント URL を生成するために使用されるルートドキュメントサイト URL。有効なスキームおよび末尾のスラッシュが含まれる絶対 URL でなければなりません。

en: By default Ansible will issue a warning when a duplicate dict key is encountered in YAML. These warnings can be silenced by adjusting this setting to False.
ja: デフォルトでは、Ansible は、YAML で重複した dict キーが発生した場合に警告を発行します。この警告は、この設定を False に設定すると非表示にすることができます。

en: Whether or not to enable the task debugger, this previously was done as a strategy plugin. Now all strategy plugins can inherit this behavior. The debugger defaults to activating when a task is failed on unreachable. Use the debugger keyword for more flexibility.
ja: タスクデバッガーを有効にするかどうかにかかわらず、これは以前は strategy プラグインとして実行されていました。これで、すべての strategy プラグインがこの動作を継承できるようになりました。デバッガーは、タスクが到達不能で失敗したときにデフォルトでアクティブになります。柔軟性を高めるには、debugger キーワードを使用します。

en: Toggle to allow missing handlers to become a warning instead of an error when notifying.
ja: 通知時に、エラーではなく、不足しているハンドラーが警告になるように切り替えます。

en: Which modules to run during a play's fact gathering stage, using the default of 'smart' will try to figure it out based on connection type.
ja: プレイのファクト収集段階で実行するモジュールは、デフォルトの「smart」を使用すると接続タイプに基づいて確認を試みます。

en: The directory that stores cached responses from a Galaxy server. This is only used by the ``ansible-galaxy collection install`` and ``download`` commands. Cache files inside this dir will be ignored if they are world writable.
ja: Galaxy サーバーからキャッシュされた応答を保存するディレクトリーです。これは ``ansible-galaxy collection install`` コマンドおよび ``download`` コマンドによってのみ使用されます。このディレクトリー内のキャッシュファイルは、誰でも書き込み可能であれば無視されます。

en: Some steps in ``ansible-galaxy`` display a progress wheel which can cause issues on certain displays or when outputing the stdout to a file. This config option controls whether the display wheel is shown or not. The default is to show the display wheel if stdout has a tty.
ja: ``ansible-galaxy`` の一部の手順では、特定の表示で、または標準出力 (stdout) をファイルに出力するときに問題が発生する可能性のある進行状況ホイールを表示します。この設定オプションは、表示ホイールを表示するかどうかを制御します。デフォルトでは、stdout に tty があると、表示ホイールが表示されます。

en: If set to yes, ansible-galaxy will not validate TLS certificates. This can be useful for testing against a server with a self-signed certificate.
ja: yes に設定すると、ansible-galaxy が TLS 証明書を検証しません。これは、自己署名証明書を使用するサーバーに対してテストを行う場合に便利です。

en: Role or collection skeleton directory to use as a template for the ``init`` action in ``ansible-galaxy``, same as ``--role-skeleton``.
ja: ``ansible-galaxy`` の ``init`` アクションのテンプレートとして使用するロールまたはコレクションのスケルトンディレクトリー。``--role-skeleton`` と同じです。

en: patterns of files to ignore inside a Galaxy role or collection skeleton directory
ja: Galaxy ロールまたはコレクションスケルトンディレクトリー内で無視するファイルのパターン

en: URL to prepend when roles don't specify the full URI, assume they are referencing this server as the source.
ja: ロールが完全な URI を指定していない場合に先頭に追加する URL。このサーバーがソースとして参照されていることを前提とします。

en: A list of Galaxy servers to use when installing a collection. The value corresponds to the config ini header ``[galaxy_server.{{item}}]`` which defines the server details. See :ref:`galaxy_server_config` for more details on how to define a Galaxy server. The order of servers in this list is used to as the order in which a collection is resolved. Setting this config option will ignore the :ref:`galaxy_server` config option.
ja: コレクションのインストール時に使用する Galaxy サーバーの一覧。値は、サーバーの詳細を定義する config ini ヘッダー ``[galaxy_server.{{item}}]`` に対応します。Galaxy サーバーの定義方法の詳細は、「:ref:`galaxy_server_config`」を参照してください。この一覧のサーバーの順序は、コレクションの解決順序として使用されます。この設定オプションを設定すると、:ref:`galaxy_server` の設定オプションは無視されます。

en: Local path to galaxy access token file
ja: galaxy アクセストークンファイルへのローカルパス

en: Set this to "False" if you want to avoid host key checking by the underlying tools Ansible uses to connect to the host
ja: Ansible がホストへの接続に使用する基盤のツールでホストキーの確認を行わないようにするには、このパラメーターを「False」に設定します。

en: This setting changes the behaviour of mismatched host patterns, it allows you to force a fatal error, a warning or just ignore it
ja: この設定により、一致しないホストパターンの動作が変更されます。これにより、致命的なエラーや警告を強制したり、無視することが可能になります。

en: Facts are available inside the `ansible_facts` variable, this setting also pushes them as their own vars in the main namespace. Unlike inside the `ansible_facts` dictionary, these will have an `ansible_` prefix.
ja: ファクトは `ansible_facts` 変数内で利用できます。この設定は、主な名前空間で独自の変数としてプッシュされます。`ansible_facts` ディクショナリー内とは異なり、これは `ansible_` の接頭辞があります。

en: Path to the Python interpreter to be used for module execution on remote targets, or an automatic discovery mode. Supported discovery modes are ``auto``, ``auto_silent``, and ``auto_legacy`` (the default). All discovery modes employ a lookup table to use the included system Python (on distributions known to include one), falling back to a fixed ordered list of well-known Python interpreter locations if a platform-specific default is not available. The fallback behavior will issue a warning that the interpreter should be set explicitly (since interpreters installed later may change which one is used). This warning behavior can be disabled by setting ``auto_silent``. The default value of ``auto_legacy`` provides all the same behavior, but for backwards-compatibility with older Ansible releases that always defaulted to ``/usr/bin/python``, will use that interpreter if present (and issue a warning that the default behavior will change to that of ``auto`` in a future Ansible release.
ja: リモートターゲットまたは自動検出モードでのモジュール実行に使用される Python インタープリターへのパス。サポートされている検出モードは、``auto``、``auto_silent``、および ``auto_legacy`` (デフォルト) です。すべての検出モードは、含まれているシステムの Python (含むことがディストリビューションで) を使用するためにルックアップテーブルを使用し、プラットフォーム固有のデフォルトが使用できない場合は、よく知られた Python インタープリターの位置の固定された順序リストにフォールバックします。フォールバック動作では、インタープリターを明示的に設定する必要があるという警告が出力されます (後からインストールされたインタープリターが、使用するインタープリターを変更する可能性があるからです)。この警告動作を無効にするには、``auto_silent`` を設定します。``auto_legacy`` のデフォルト値はすべて同じ動作を提供しますが、以前の Ansible リリースとの下位互換性のために、常にデフォルトで ``/usr/bin/python`` に設定されていた場合、存在する場合はそのインタープリターを使用します (デフォルトの動作が将来の Ansible リリースの ``auto`` の動作に変更することを示す警告を表示します)。

en: If 'false', invalid attributes for a task will result in warnings instead of errors
ja: 「false」の場合は、タスクの無効な属性により、エラーではなく警告が発生します。

en: If 'true', it is a fatal error when any given inventory source cannot be successfully parsed by any available inventory plugin; otherwise, this situation only attracts a warning.
ja: 「true」の場合は、指定のインベントリーソースを利用可能な inventory プラグインで正常に解析できない場合に致命的なエラーになります。そうでないと、この状況は警告を招くだけとなります。

en: Toggle to turn on inventory caching
ja: インベントリーキャッシュを有効に切り替えます。

en: The plugin for caching inventory. If INVENTORY_CACHE_PLUGIN is not provided CACHE_PLUGIN can be used instead.
ja: インベントリーのキャッシュ用のプラグイン。INVENTORY_CACHE_PLUGIN が指定されていない場合は、CACHE_PLUGIN を代わりに使用できます。

en: The inventory cache connection. If INVENTORY_CACHE_PLUGIN_CONNECTION is not provided CACHE_PLUGIN_CONNECTION can be used instead.
ja: インベントリーキャッシュ接続。INVENTORY_CACHE_PLUGIN_CONNECTION が指定されていない場合は、代わりに CACHE_PLUGIN_CONNECTION を使用できます。

en: The table prefix for the cache plugin. If INVENTORY_CACHE_PLUGIN_PREFIX is not provided CACHE_PLUGIN_PREFIX can be used instead.
ja: cache プラグインのテーブル接頭辞。INVENTORY_CACHE_PLUGIN_PREFIX が指定されていない場合は、代わりに CACHE_PLUGIN_PREFIX を使用できます。

en: Expiration timeout for the inventory cache plugin data. If INVENTORY_CACHE_TIMEOUT is not provided CACHE_TIMEOUT can be used instead.
ja: inventory cache プラグインデータの有効期限のタイムアウト。INVENTORY_CACHE_TIMEOUT が指定されていない場合は、代わりに CACHE_TIMEOUT を使用できます。

en: List of enabled inventory plugins, it also determines the order in which they are used.
ja: 有効な inventory プラグインのリスト。また、使用する順序も決定します。

en: Controls if ansible-inventory will accurately reflect Ansible's view into inventory or its optimized for exporting.
ja: ansible-inventory が Ansible のビューをインベントリーに正確に反映させるか、またはエクスポートに最適化するかを制御します。

en: List of extensions to ignore when using a directory as an inventory source
ja: ディレクトリーをインベントリーソースとして使用する際に無視する拡張機能の一覧

en: List of patterns to ignore when using a directory as an inventory source
ja: ディレクトリーをインベントリーソースとして使用する場合に無視するパターンの一覧

en: If 'true' it is a fatal error if every single potential inventory source fails to parse, otherwise this situation will only attract a warning.
ja: 「true」にすると、すべての潜在的なインベントリーソースが解析に失敗した場合に致命的なエラーとなります。そうしないと、この状況は警告を招くだけです。

en: By default Ansible will issue a warning when there are no hosts in the inventory. These warnings can be silenced by adjusting this setting to False.
ja: デフォルトでは、Ansible は、インベントリーにホストがない場合に警告を表示します。この警告は、この設定を False に設定すると非表示にすることができます。

en: Maximum size of files to be considered for diff display
ja: diff 表示に考慮されるファイルの最大サイズ

en: List of extensions to ignore when looking for modules to load This is for rejecting script and binary module fallback extensions
ja: 読み込むモジュールを探すときに無視する拡張機能のリスト。これは、スクリプトおよびバイナリーモジュールのフォールバック拡張機能を拒否するためのものです。

en: This variable is used to enable bastion/jump host with netconf connection. If set to True the bastion/jump host ssh settings should be present in ~/.ssh/config file, alternatively it can be set to custom ssh configuration file path to read the bastion/jump host settings.
ja: この変数は、netconf 接続で bastion/ジャンプホストを有効にするために使用されます。Trueに設定すると、bastion/ジャンプホストの ssh 設定が ~/.ssh/config ファイルに存在する必要があります。または、カスタムの ssh 設定ファイルパスに設定して、bastion/ジャンプホストの設定を読み取ることもできます。

en: the ``ANSIBLE_NETWORK_GROUP_MODULES`` environment variable
ja: ``ANSIBLE_NETWORK_GROUP_MODULES`` 環境変数

en: Previouslly Ansible would only clear some of the plugin loading caches when loading new roles, this led to some behaviours in which a plugin loaded in prevoius plays would be unexpectedly 'sticky'. This setting allows to return to that behaviour.
ja: 以前の Ansible は、新しいロールを読み込むときにプラグインの読み込みキャッシュの一部のみを削除していました。これにより、以前のプレイで読み込まれたプラグインが予期せず「スティッキー」になる動作が発生しました。この設定により、その動作に戻ることができます。

en: This controls the amount of time to wait for response from remote device before timing out persistent connection.
ja: これは、永続的な接続をタイムアウトする前に、リモートデバイスからの応答を待つ時間を制御します。

en: This controls the retry timeout for persistent connection to connect to the local domain socket.
ja: これにより、ローカルドメインソケットに接続する永続接続の再試行タイムアウトを制御します。

en: This controls how long the persistent connection will remain idle before it is destroyed.
ja: これは、アイドル状態になり、永続接続が破棄されるまでの期間を制御します。

en: Path to socket to be used by the connection persistence system.
ja: 接続永続システムによって使用されるソケットへのパス。

en: A number of non-playbook CLIs have a ``--playbook-dir`` argument; this sets the default value for it.
ja: Playbook 以外の CLI の多くに ``--playbook-dir`` 引数があり、これによりデフォルト値が設定されます。

en: This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host_vars/group_vars The ``top`` option follows the traditional behaviour of using the top playbook in the chain to find the root directory. The ``bottom`` option follows the 2.4.0 behaviour of using the current playbook to find the root directory. The ``all`` option examines from the first parent to the current playbook.
ja: これにより、vars プラグインを処理するためのルートとして使用される Playbook ディレクトリーが設定されます。これには、host_vars/group_vars の検索が含まれます。``top`` オプションは、チェーンの最上位の Playbook を使用してルートディレクトリーを見つけるという従来の動作に従います。``bottom`` オプションは、現在の Playbook を使用してルートディレクトリーを検索する 2.4.0 の動作に従います。``all`` オプションは、最初の親から現在の Playbook までを調べます。

en: A path to configuration for filtering which plugins installed on the system are allowed to be used. See :ref:`plugin_filtering_config` for details of the filter file's format.  The default is /usr/local/etc/ansible/plugin_filters.yml
ja: システムにインストールされているプラグインのうち、どのプラグインの使用を許可するかをフィルタリングするための設定のパスです。フィルターファイルの形式の詳細は、「:ref:`plugin_filtering_config`」を参照してください。デフォルトは /usr/local/etc/ansible/plugin_filters.yml です。

en: specifying "plugin_filters_cfg" under the "default" section is deprecated
ja: 「default」セクションに「plugin_filters_cfg」を指定することが非推奨になりました。

en: the "defaults" section instead
ja: 代わりに「default」セクションが使用されます。

en: Attempts to set RLIMIT_NOFILE soft limit to the specified value when executing Python modules (can speed up subprocess usage on Python 2.x. See https://bugs.python.org/issue11284). The value will be limited by the existing hard limit. Default value of 0 does not attempt to adjust existing system-defined limits.
ja: Python モジュールの実行時に RLIMIT_NOFILE ソフト制限を指定された値に設定しようとします (Python2.x でのサブプロセスの使用を高速化できます。https://bugs.python.org/issue11284 を参照してください)。この値は、既存のハード制限によって制限されます。デフォルト値の 0 は、既存のシステム定義の制限を調整しようとはしません。

en: This controls whether a failed Ansible playbook should create a .retry file.
ja: これにより、失敗した Ansible Playbook が .retry ファイルを作成するかどうかを制御します。

en: This sets the path in which Ansible will save .retry files when a playbook fails and retry files are enabled. This file will be overwritten after each run with the list of failed hosts from all plays.
ja: これにより、Playbook が失敗し、再試行ファイルが有効になっている場合に、Ansible が .retry ファイルを保存するパスが設定されます。このファイルは、実行するたびに、すべてのプレイで失敗したホストのリストで上書きされます。

en: This setting can be used to optimize vars_plugin usage depending on user's inventory size and play selection. Setting to C(demand) will run vars_plugins relative to inventory sources anytime vars are 'demanded' by tasks. Setting to C(start) will run vars_plugins relative to inventory sources after importing that inventory source.
ja: この設定は、ユーザーのインベントリーサイズとプレイの選択に応じて vars_plugin の使用を最適化するために使用できます。C(demand) に設定すると、タスクによって変数が「要求」されるたびに、インベントリーソースに関連して vars_plugins が実行されます。C(start) に設定すると、インベントリーソースをインポートした後、インベントリーソースに関連して vars_plugins が実行されます。

en: This adds the custom stats set via the set_stats plugin to the default output
ja: これにより、set_stats プラグインを介してカスタム統計セットがデフォルトの出力に追加されます。

en: Action to take when a module parameter value is converted to a string (this does not affect variables). For string parameters, values such as '1.00', "['a', 'b',]", and 'yes', 'y', etc. will be converted by the YAML parser unless fully quoted. Valid options are 'error', 'warn', and 'ignore'. Since 2.8, this option defaults to 'warn' but will change to 'error' in 2.12.
ja: モジュールパラメーター値が文字列に変換されるときに実行するアクション (これは変数には影響しません)。文字列パラメーターの場合、「1.00」、「['a', 'b',]」、「yes」、「y」などの値は、完全に引用されていない限り、YAML パーサーにより変換されます。有効なオプションは、「error」、「warn」、および「ignore」です。2.8 以降、このオプションのデフォルトは「warn」ですが、2.12では「error」に変更されます。

en: This list of filters avoids 'type conversion' when templating variables Useful when you want to avoid conversion into lists or dictionaries for JSON strings, for example.
ja: このフィルターのリストは、変数をテンプレート化するときに「型変換」を回避します。たとえば、JSON 文字列のリストやディレクトリーへの変換を回避したい場合に便利です。

en: Allows disabling of warnings related to potential issues on the system running ansible itself (not on the managed hosts) These may include warnings about 3rd party packages or other conditions that should be resolved if possible.
ja: Ansible 自体を実行している (管理対象ホストではない) システムの潜在的な問題に関連する警告を無効にすることができます。これには、サードパーティーのパッケージに関する警告や、可能であれば解決する必要のあるその他の条件が含まれる場合があります。

en: default list of tags to run in your plays, Skip Tags has precedence.
ja: プレイで実行するタグのデフォルト一覧。Skip Tags が優先されます。

en: default list of tags to skip in your plays, has precedence over Run Tags
ja: プレイでスキップするタグのデフォルト一覧は Run Tags よりも優先

en: This option defines whether the task debugger will be invoked on a failed task when ignore_errors=True is specified. True specifies that the debugger will honor ignore_errors, False will not honor ignore_errors.
ja: このオプションは、ignore_errors=True が指定されている場合に、失敗したタスクでタスクデバッガーが呼び出されるかどうかを定義します。True に設定すると、デバッガーが ignore_errors を許可するように指定し、False に設定すると ignore_errors が無効になります。

en: Set the maximum time (in seconds) that a task can run for. If set to 0 (the default) there is no timeout.
ja: タスクを実行できる最大時間 (秒単位) を設定します。0 (デフォルト) に設定するとタイムアウトはありません。

en: Make ansible transform invalid characters in group names supplied by inventory sources. If 'never' it will allow for the group name but warn about the issue. When 'ignore', it does the same as 'never', without issuing a warning. When 'always' it will replace any invalid characters with '_' (underscore) and warn the user When 'silently', it does the same as 'always', without issuing a warning.
ja: インベントリーソースから提供されたグループ名の無効な文字を Ansible が変換します。「never」の場合、グループ名は許可されますが、問題について警告されます。「ignore」の場合は、警告を出力せずに「never」と同じように動作します。「always」の場合は、無効な文字を「_」(アンダースコア) に置き換えてユーザーに警告します。「silently」の場合は、警告を発行せずに「always」と同じように動作します。

en: Toggles the use of persistence for connections.
ja: 接続に対して永続性の使用を切り替えます。

en: Whitelist for variable plugins that require it.
ja: 必要になる vars プラグインのホワイトリストです。

en: Allows to change the group variable precedence merge order.
ja: グループ変数の優先順位のマージ順序を変更できます。

en: Force 'verbose' option to use stderr instead of stdout
ja: stdout の代わりに「verbose」オプションを強制的に使用

en: For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how long, in seconds, to wait for the task spawned by Ansible to connect back to the named pipe used on Windows systems. The default is 5 seconds. This can be too low on slower systems, or systems under heavy load. This is not the total time an async command can run for, but is a separate timeout to wait for an async command to start. The task will only start to be timed against its async_timeout once it has connected to the pipe, so the overall maximum duration the task can take will be extended by the amount specified here.
ja: Ansible の非同期タスク (「非同期アクションおよびポーリング」で説明) の場合、これは、Ansible が生成するタスクが Windows システムで使用される名前付きパイプに接続するのを待機する時間 (秒単位) です。デフォルトは 5 秒です。これは、低速のシステムや高負荷のシステムでは低すぎる可能性があります。これは、非同期コマンドを実行できる合計時間ではありませんが、非同期コマンドの開始を待機する別のタイムアウトです。タスクは、パイプに接続された後にのみ async_timeout に対してタイムアウトが開始するため、タスクの全体的な最大期間は、ここで指定された分だけ延長されます。

en: The maximum number of times to check Task Queue Manager worker processes to verify they have exited cleanly. After this limit is reached any worker processes still running will be terminated. This is for internal use only.
ja: Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認する最大回数。この制限に達すると、まだ実行中のワーカープロセスはすべて終了します。これは内部使用のみです。

en: The number of seconds to sleep between polling loops when checking Task Queue Manager worker processes to verify they have exited cleanly. This is for internal use only.
ja: Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認するときに、ポーリングループ間でスリープする秒数。これは内部使用のみです。

en: Check all of these extensions when looking for 'variable' files which should be YAML or JSON or vaulted versions of these. This affects vars_files, include_vars, inventory and vars plugins among others.
ja: YAML または JSON、あるいはこれらの Vault バージョンである必要がある「変数」ファイルを探すときは、これらすべての拡張子を確認してください。これは、vars_files、include_vars、inventory、vars プラグインなどに影響します。

en: Environment Variables
ja: 環境変数

en: Override the default ansible config file
ja: デフォルトの ansible config ファイルを上書きします

en: Specify where to look for the ansible-connection script. This location will be checked before searching $PATH.If null, ansible will start with the same directory as the ansible script.
ja: ansible-connection スクリプトを探す場所を指定します。この場所は、$PATH の検索前にチェックされます。null に設定すると、Ansible は ansible スクリプトと同じディレクトリーで起動します。

en: See also :ref:`ANSIBLE_CONNECTION_PATH <ANSIBLE_CONNECTION_PATH>`
ja: 「:ref:`ANSIBLE_CONNECTION_PATH <ANSIBLE_CONNECTION_PATH>`」も参照してください。

en: See also :ref:`ANSIBLE_COW_SELECTION <ANSIBLE_COW_SELECTION>`
ja: 「:ref:`ANSIBLE_COW_SELECTION <ANSIBLE_COW_SELECTION>`」も参照してください。

en: See also :ref:`ANSIBLE_COW_ACCEPTLIST <ANSIBLE_COW_ACCEPTLIST>`
ja: 「:ref:`ANSIBLE_COW_ACCEPTLIST <ANSIBLE_COW_ACCEPTLIST>`」も参照してください。

en: See also :ref:`ANSIBLE_FORCE_COLOR <ANSIBLE_FORCE_COLOR>`
ja: 「:ref:`ANSIBLE_FORCE_COLOR <ANSIBLE_FORCE_COLOR>`」も参照してください。

en: See also :ref:`ANSIBLE_NOCOLOR <ANSIBLE_NOCOLOR>`
ja: 「:ref:`ANSIBLE_NOCOLOR <ANSIBLE_NOCOLOR>`」も参照してください。

en: See also :ref:`ANSIBLE_NOCOWS <ANSIBLE_NOCOWS>`
ja: 「:ref:`ANSIBLE_NOCOWS <ANSIBLE_NOCOWS>`」も参照してください。

en: See also :ref:`ANSIBLE_COW_PATH <ANSIBLE_COW_PATH>`
ja: 「:ref:`ANSIBLE_COW_PATH <ANSIBLE_COW_PATH>`」も参照してください。

en: Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer.This can result in a very significant performance improvement when enabled.However this conflicts with privilege escalation (become). For example, when using 'sudo:' operations you must first disable 'requiretty' in /etc/sudoers on all managed hosts, which is why it is disabled by default.This option is disabled if ``ANSIBLE_KEEP_REMOTE_FILES`` is enabled.This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all.
ja: パイプライン (connection プラグインでサポートされる場合) は、実際のファイル転送をせずにで多数の Ansible モジュールを実行して、リモートサーバーでモジュールを実行するために必要なネットワーク操作の数を減らします。これにより、有効にするとパフォーマンスが大幅に向上する可能性があります。ただし、これは特権昇格 (become) と競合します。たとえば、「sudo:」操作を使用する場合は、すべての管理対象ホストの /etc/sudoers で「requiretty」を無効にする必要があります。これが、デフォルトで無効になっている理由です。``ANSIBLE_KEEP_REMOTE_FILES`` が有効な場合、このオプションは無効になります。これはグローバルオプションであり、各 connection プラグインは、より具体的なオプションを指定するか、パイプをサポートしないかのいずれかによりオーバーライドすることができます。

en: See also :ref:`ANSIBLE_PIPELINING <ANSIBLE_PIPELINING>`
ja: 「:ref:`ANSIBLE_PIPELINING <ANSIBLE_PIPELINING>`」も参照してください。

en: See also :ref:`ANY_ERRORS_FATAL <ANY_ERRORS_FATAL>`
ja: 「:ref:`ANY_ERRORS_FATAL <ANY_ERRORS_FATAL>`」も参照してください。

en: See also :ref:`BECOME_ALLOW_SAME_USER <BECOME_ALLOW_SAME_USER>`
ja: 「:ref:`BECOME_ALLOW_SAME_USER <BECOME_ALLOW_SAME_USER>`」も参照してください。

en: See also :ref:`AGNOSTIC_BECOME_PROMPT <AGNOSTIC_BECOME_PROMPT>`
ja: 「:ref:`AGNOSTIC_BECOME_PROMPT <AGNOSTIC_BECOME_PROMPT>`」も参照してください。

en: See also :ref:`CACHE_PLUGIN <CACHE_PLUGIN>`
ja: 「:ref:`CACHE_PLUGIN <CACHE_PLUGIN>`」も参照してください。

en: See also :ref:`CACHE_PLUGIN_CONNECTION <CACHE_PLUGIN_CONNECTION>`
ja: 「:ref:`CACHE_PLUGIN_CONNECTION <CACHE_PLUGIN_CONNECTION>`」も参照してください。

en: See also :ref:`CACHE_PLUGIN_PREFIX <CACHE_PLUGIN_PREFIX>`
ja: 「:ref:`CACHE_PLUGIN_PREFIX <CACHE_PLUGIN_PREFIX>`」も参照してください。

en: See also :ref:`CACHE_PLUGIN_TIMEOUT <CACHE_PLUGIN_TIMEOUT>`
ja: 「:ref:`CACHE_PLUGIN_TIMEOUT <CACHE_PLUGIN_TIMEOUT>`」も参照してください。

en: See also :ref:`COLLECTIONS_SCAN_SYS_PATH <COLLECTIONS_SCAN_SYS_PATH>`
ja: 「:ref:`COLLECTIONS_SCAN_SYS_PATH <COLLECTIONS_SCAN_SYS_PATH>`」も参照してください。

en: See also :ref:`COLLECTIONS_PATHS <COLLECTIONS_PATHS>`
ja: 「:ref:`COLLECTIONS_PATHS <COLLECTIONS_PATHS>`」も参照してください。

en: See also :ref:`COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH <COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH>`
ja: 「:ref:`COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH <COLLECTIONS_ON_ANSIBLE_VERSION_MISMATCH>`」も参照してください。

en: See also :ref:`COLOR_CHANGED <COLOR_CHANGED>`
ja: 「:ref:`COLOR_CHANGED <COLOR_CHANGED>`」も参照してください。

en: See also :ref:`COLOR_CONSOLE_PROMPT <COLOR_CONSOLE_PROMPT>`
ja: 「:ref:`COLOR_CONSOLE_PROMPT <COLOR_CONSOLE_PROMPT>`」も参照してください。

en: See also :ref:`COLOR_DEBUG <COLOR_DEBUG>`
ja: 「:ref:`COLOR_DEBUG <COLOR_DEBUG>`」も参照してください。

en: See also :ref:`COLOR_DEPRECATE <COLOR_DEPRECATE>`
ja: 「:ref:`COLOR_DEPRECATE <COLOR_DEPRECATE>`」も参照してください。

en: See also :ref:`COLOR_DIFF_ADD <COLOR_DIFF_ADD>`
ja: 「:ref:`COLOR_DIFF_ADD <COLOR_DIFF_ADD>`」も参照してください。

en: See also :ref:`COLOR_DIFF_LINES <COLOR_DIFF_LINES>`
ja: 「:ref:`COLOR_DIFF_LINES <COLOR_DIFF_LINES>`」も参照してください。

en: See also :ref:`COLOR_DIFF_REMOVE <COLOR_DIFF_REMOVE>`
ja: 「:ref:`COLOR_DIFF_REMOVE <COLOR_DIFF_REMOVE>`」も参照してください。

en: See also :ref:`COLOR_ERROR <COLOR_ERROR>`
ja: 「:ref:`COLOR_ERROR <COLOR_ERROR>`」も参照してください。

en: See also :ref:`COLOR_HIGHLIGHT <COLOR_HIGHLIGHT>`
ja: 「:ref:`COLOR_HIGHLIGHT <COLOR_HIGHLIGHT>`」も参照してください。

en: See also :ref:`COLOR_OK <COLOR_OK>`
ja: 「:ref:`COLOR_OK <COLOR_OK>`」も参照してください。

en: See also :ref:`COLOR_SKIP <COLOR_SKIP>`
ja: 「:ref:`COLOR_SKIP <COLOR_SKIP>`」も参照してください。

en: See also :ref:`COLOR_UNREACHABLE <COLOR_UNREACHABLE>`
ja: 「:ref:`COLOR_UNREACHABLE <COLOR_UNREACHABLE>`」も参照してください。

en: See also :ref:`COLOR_VERBOSE <COLOR_VERBOSE>`
ja: 「:ref:`COLOR_VERBOSE <COLOR_VERBOSE>`」も参照してください。

en: See also :ref:`COLOR_WARN <COLOR_WARN>`
ja: 「:ref:`COLOR_WARN <COLOR_WARN>`」も参照してください。

en: With this setting on (True), running conditional evaluation 'var' is treated differently than 'var.subkey' as the first is evaluated directly while the second goes through the Jinja2 parser. But 'false' strings in 'var' get evaluated as booleans.With this setting off they both evaluate the same but in cases in which 'var' was 'false' (a string) it won't get evaluated as a boolean anymore.Currently this setting defaults to 'True' but will soon change to 'False' and the setting itself will be removed in the future.Expect that this setting eventually will be deprecated after 2.12
ja: この設定を (True) にすると、条件付き評価「var」の実行は「var.subkey」とは異なる方法で処理されます。最初の評価は直接評価され、2 番目の評価は Jinja2 パーサーを通過するためです。ただし、「var」の「false」文字列はブール値として評価されます。この設定をオフにすると、どちらも同じように評価されますが、「var」が「false」(文字列) の場合は、ブール値として評価されなくなります。現在、この設定のデフォルトは「True」ですが、まもなく「False」に変更され、将来のバージョンで設定自体が削除されます。この設定は、2.12 以降で最終的に非推奨になると予想されます。

en: See also :ref:`CONDITIONAL_BARE_VARS <CONDITIONAL_BARE_VARS>`
ja: 「:ref:`CONDITIONAL_BARE_VARS <CONDITIONAL_BARE_VARS>`」も参照してください。

en: Sets the output directory on the remote host to generate coverage reports to.Currently only used for remote coverage on PowerShell modules.This is for internal use only.
ja: リモートホストの出力ディレクトリーを設定してカバレッジレポートを生成します。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。

en: See also :ref:`COVERAGE_REMOTE_OUTPUT <COVERAGE_REMOTE_OUTPUT>`
ja: 「:ref:`COVERAGE_REMOTE_OUTPUT <COVERAGE_REMOTE_OUTPUT>`」も参照してください。

en: A list of paths for files on the Ansible controller to run coverage for when executing on the remote host.Only files that match the path glob will have its coverage collected.Multiple path globs can be specified and are separated by ``:``.Currently only used for remote coverage on PowerShell modules.This is for internal use only.
ja: リモートホストで実行するときにカバレッジを実行する Ansible コントローラー上のファイルのパスのリスト。パスグロブに一致するファイルのみがカバレッジを収集します。パスグロブは、``:`` で区切ることで複数指定できます。現在 PowerShell モジュールのリモートカバレッジにのみ使用されます。これは内部使用のみを目的としています。

en: See also :ref:`COVERAGE_REMOTE_PATHS <COVERAGE_REMOTE_PATHS>`
ja: 「:ref:`COVERAGE_REMOTE_PATHS <COVERAGE_REMOTE_PATHS>`」も参照してください。

en: By default Ansible will issue a warning when received from a task action (module or action plugin)These warnings can be silenced by adjusting this setting to False.
ja: デフォルトでは、Ansible はタスクアクション (モジュールまたは action プラグイン) から受け取ると、警告を False に調整することで警告を非表示にすることができます。

en: See also :ref:`ACTION_WARNINGS <ACTION_WARNINGS>`
ja: 「:ref:`ACTION_WARNINGS <ACTION_WARNINGS>`」も参照してください。

en: Ansible can issue a warning when the shell or command module is used and the command appears to be similar to an existing Ansible module.These warnings can be silenced by adjusting this setting to False. You can also control this at the task level with the module option ``warn``.As of version 2.11, this is disabled by default.
ja: Ansible は、シェルまたはコマンドモジュールが使用され、コマンドが既存の Ansible モジュールと類似しているように見えます。これらの設定を False に設定することで、これらの警告を非表示にすることができます。また、モジュールのオプション ``warn`` を使用してタスクレベルで制御することもできます。バージョン 2.11 の時点で、これはデフォルトでは無効になっています。

en: See also :ref:`COMMAND_WARNINGS <COMMAND_WARNINGS>`
ja: 「:ref:`COMMAND_WARNINGS <COMMAND_WARNINGS>`」も参照してください。

en: By default Ansible will issue a warning when there are no hosts in the inventory.These warnings can be silenced by adjusting this setting to False.
ja: デフォルトでは、Ansible は、インベントリーにホストがない場合に警告を表示します。この警告は、この設定を False に設定すると非表示にすることができます。

en: See also :ref:`LOCALHOST_WARNING <LOCALHOST_WARNING>`
ja: 「:ref:`LOCALHOST_WARNING <LOCALHOST_WARNING>`」も参照してください。

en: See also :ref:`DOC_FRAGMENT_PLUGIN_PATH <DOC_FRAGMENT_PLUGIN_PATH>`
ja: 「:ref:`DOC_FRAGMENT_PLUGIN_PATH <DOC_FRAGMENT_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_ACTION_PLUGIN_PATH <DEFAULT_ACTION_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_ACTION_PLUGIN_PATH <DEFAULT_ACTION_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_ASK_PASS <DEFAULT_ASK_PASS>`
ja: 「:ref:`DEFAULT_ASK_PASS <DEFAULT_ASK_PASS>`」も参照してください。

en: See also :ref:`DEFAULT_ASK_VAULT_PASS <DEFAULT_ASK_VAULT_PASS>`
ja: 「:ref:`DEFAULT_ASK_VAULT_PASS <DEFAULT_ASK_VAULT_PASS>`」も参照してください。

en: See also :ref:`DEFAULT_BECOME <DEFAULT_BECOME>`
ja: 「:ref:`DEFAULT_BECOME <DEFAULT_BECOME>`」も参照してください。

en: See also :ref:`DEFAULT_BECOME_ASK_PASS <DEFAULT_BECOME_ASK_PASS>`
ja: 「:ref:`DEFAULT_BECOME_ASK_PASS <DEFAULT_BECOME_ASK_PASS>`」も参照してください。

en: See also :ref:`DEFAULT_BECOME_METHOD <DEFAULT_BECOME_METHOD>`
ja: 「:ref:`DEFAULT_BECOME_METHOD <DEFAULT_BECOME_METHOD>`」も参照してください。

en: See also :ref:`DEFAULT_BECOME_EXE <DEFAULT_BECOME_EXE>`
ja: 「:ref:`DEFAULT_BECOME_EXE <DEFAULT_BECOME_EXE>`」も参照してください。

en: See also :ref:`DEFAULT_BECOME_FLAGS <DEFAULT_BECOME_FLAGS>`
ja: 「:ref:`DEFAULT_BECOME_FLAGS <DEFAULT_BECOME_FLAGS>`」も参照してください。

en: See also :ref:`BECOME_PLUGIN_PATH <BECOME_PLUGIN_PATH>`
ja: 「:ref:`BECOME_PLUGIN_PATH <BECOME_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_BECOME_USER <DEFAULT_BECOME_USER>`
ja: 「:ref:`DEFAULT_BECOME_USER <DEFAULT_BECOME_USER>`」も参照してください。

en: See also :ref:`DEFAULT_CACHE_PLUGIN_PATH <DEFAULT_CACHE_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_CACHE_PLUGIN_PATH <DEFAULT_CACHE_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`CALLABLE_ACCEPT_LIST <CALLABLE_ACCEPT_LIST>`
ja: 「:ref:`CALLABLE_ACCEPT_LIST <CALLABLE_ACCEPT_LIST>`」も参照してください。

en: See also :ref:`CONTROLLER_PYTHON_WARNING <CONTROLLER_PYTHON_WARNING>`
ja: 「:ref:`CONTROLLER_PYTHON_WARNING <CONTROLLER_PYTHON_WARNING>`」も参照してください。

en: See also :ref:`DEFAULT_CALLBACK_PLUGIN_PATH <DEFAULT_CALLBACK_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_CALLBACK_PLUGIN_PATH <DEFAULT_CALLBACK_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`CALLBACKS_ENABLED <CALLBACKS_ENABLED>`
ja: 「:ref:`CALLBACKS_ENABLED <CALLBACKS_ENABLED>`」も参照してください。

en: See also :ref:`DEFAULT_CLICONF_PLUGIN_PATH <DEFAULT_CLICONF_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_CLICONF_PLUGIN_PATH <DEFAULT_CLICONF_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_CONNECTION_PLUGIN_PATH <DEFAULT_CONNECTION_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_CONNECTION_PLUGIN_PATH <DEFAULT_CONNECTION_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_DEBUG <DEFAULT_DEBUG>`
ja: 「:ref:`DEFAULT_DEBUG <DEFAULT_DEBUG>`」も参照してください。

en: See also :ref:`DEFAULT_EXECUTABLE <DEFAULT_EXECUTABLE>`
ja: 「:ref:`DEFAULT_EXECUTABLE <DEFAULT_EXECUTABLE>`」も参照してください。

en: This option allows you to globally configure a custom path for 'local_facts' for the implied M(ansible.builtin.setup) task when using fact gathering.If not set, it will fallback to the default from the M(ansible.builtin.setup) module: ``/usr/local/etc/ansible/facts.d``.This does **not** affect  user defined tasks that use the M(ansible.builtin.setup) module.
ja: このオプションを使用すると、ファクト収集を使用するときに、暗黙の M(ansible.builtin.setup) タスクの「local_facts」のカスタムパスをグローバルに設定できます。設定されていない場合は、M(ansible.builtin.setup) モジュールからデフォルトにフォールバックします (``/usr/local/etc/ansible/facts.d``)。これは、M(ansible.builtin.setup) モジュールを使用するユーザー定義のタスクには **影響しません**。

en: See also :ref:`DEFAULT_FACT_PATH <DEFAULT_FACT_PATH>`
ja: 「:ref:`DEFAULT_FACT_PATH <DEFAULT_FACT_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_FILTER_PLUGIN_PATH <DEFAULT_FILTER_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_FILTER_PLUGIN_PATH <DEFAULT_FILTER_PLUGIN_PATH>`」も参照してください。

en: This option controls if notified handlers run on a host even if a failure occurs on that host.When false, the handlers will not run if a failure has occurred on a host.This can also be set per play or on the command line. See Handlers and Failure for more details.
ja: このオプションは、ホストで障害が発生した場合でも、通知されたハンドラーがホストで実行されるかどうかを制御します。false にすると、ホストで障害が発生した場合に、ハンドラーは実行されません。これは、プレイごとまたはコマンドラインで設定することもできます。詳細については、「ハンドラーおよび失敗」を参照してください。

en: See also :ref:`DEFAULT_FORCE_HANDLERS <DEFAULT_FORCE_HANDLERS>`
ja: 「:ref:`DEFAULT_FORCE_HANDLERS <DEFAULT_FORCE_HANDLERS>`」も参照してください。

en: See also :ref:`DEFAULT_FORKS <DEFAULT_FORKS>`
ja: 「:ref:`DEFAULT_FORKS <DEFAULT_FORKS>`」も参照してください。

en: This setting controls the default policy of fact gathering (facts discovered about remote systems).When 'implicit' (the default), the cache plugin will be ignored and facts will be gathered per play unless 'gather_facts: False' is set.When 'explicit' the inverse is true, facts will not be gathered unless directly requested in the play.The 'smart' value means each new host that has no facts discovered will be scanned, but if the same host is addressed in multiple plays it will not be contacted again in the playbook run.This option can be useful for those wishing to save fact gathering time. Both 'smart' and 'explicit' will use the cache plugin.
ja: この設定は、ファクト収集 (リモートシステムに関して検出されたファクト) のデフォルトポリシーを制御します。「implicit」(デフォルト) の場合、cache プラグインは無視され、「gather_facts: False」が設定されていない限り、プレイごとにファクトが収集されます。「explicit」の場合はその逆で、プレイ中に直接要求されない限り、ファクトは収集されません。「smart」の値は、検出されたファクトを持たない各新規ホストがスキャンされることを意味しますが、同じホストが複数のプレイで扱われた場合は、Playbook の実行中に再び接触することはありません。このオプションは、ファクト収集の時間を短縮したい場合に便利です。「smart」と「explicit」の両方とも、cache プラグインを使用します。

en: See also :ref:`DEFAULT_GATHERING <DEFAULT_GATHERING>`
ja: 「:ref:`DEFAULT_GATHERING <DEFAULT_GATHERING>`」も参照してください。

en: Set the `gather_subset` option for the M(ansible.builtin.setup) task in the implicit fact gathering. See the module documentation for specifics.It does **not** apply to user defined M(ansible.builtin.setup) tasks.
ja: 暗黙的なファクト収集の M(ansible.builtin.setup) タスクに `gather_subset` オプションを設定します。詳細は、モジュールドキュメントを参照してください。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。

en: See also :ref:`DEFAULT_GATHER_SUBSET <DEFAULT_GATHER_SUBSET>`
ja: 「:ref:`DEFAULT_GATHER_SUBSET <DEFAULT_GATHER_SUBSET>`」も参照してください。

en: Set the timeout in seconds for the implicit fact gathering.It does **not** apply to user defined M(ansible.builtin.setup) tasks.
ja: 暗黙的なファクト収集のタイムアウトを秒単位で設定します。ユーザー定義の M(ansible.builtin.setup) タスクには **適用されません**。

en: See also :ref:`DEFAULT_GATHER_TIMEOUT <DEFAULT_GATHER_TIMEOUT>`
ja: 「:ref:`DEFAULT_GATHER_TIMEOUT <DEFAULT_GATHER_TIMEOUT>`」も参照してください。

en: See also :ref:`DEFAULT_HANDLER_INCLUDES_STATIC <DEFAULT_HANDLER_INCLUDES_STATIC>`
ja: 「:ref:`DEFAULT_HANDLER_INCLUDES_STATIC <DEFAULT_HANDLER_INCLUDES_STATIC>`」も参照してください。

en: This setting controls how duplicate definitions of dictionary variables (aka hash, map, associative array) are handled in Ansible.This does not affect variables whose values are scalars (integers, strings) or arrays.**WARNING**, changing this setting is not recommended as this is fragile and makes your content (plays, roles, collections) non portable, leading to continual confusion and misuse. Don't change this setting unless you think you have an absolute need for it.We recommend avoiding reusing variable names and relying on the ``combine`` filter and ``vars`` and ``varnames`` lookups to create merged versions of the individual variables. In our experience this is rarely really needed and a sign that too much complexity has been introduced into the data structures and plays.For some uses you can also look into custom vars_plugins to merge on input, even substituting the default ``host_group_vars`` that is in charge of parsing the ``host_vars/`` and ``group_vars/`` directories. Most users of this setting are only interested in inventory scope, but the setting itself affects all sources and makes debugging even harder.All playbooks and roles in the official examples repos assume the default for this setting.Changing the setting to ``merge`` applies across variable sources, but many sources will internally still overwrite the variables. For example ``include_vars`` will dedupe variables internally before updating Ansible, with 'last defined' overwriting previous definitions in same file.The Ansible project recommends you **avoid ``merge`` for new projects.**It is the intention of the Ansible developers to eventually deprecate and remove this setting, but it is being kept as some users do heavily rely on it. New projects should **avoid 'merge'**.
ja: この設定は、ディクショナリー変数 (別名ハッシュ、マップ、連想配列) の重複した定義を Ansible でどのように扱うかを制御します。この設定は、値がスカラー (整数、文字列) や配列である変数には影響しません。**警告** これは脆弱で、コンテンツ (プレイ、ロール、コレクション) が移植できなくなり、継続的な混乱と誤用を招く恐れがあるため、この設定を変更することは推奨されません。絶対に必要だと思われる場合を除き、この設定を変更しないでください。変数名の再利用は避け、``combine`` フィルターと``vars`` ルックアップおよび``varnames`` ルックアップを利用して、個々の変数のマージバージョンを作成することが推奨されます。経験上、このようなことが本当に必要とされることはほとんどなく、データ構造やプレイが複雑になりすぎていることを示しています。用途によっては、入力時にマージするカスタム vars_plugins を検討することもできますし、``host_vars/`` ディレクトリーおよび ``group_vars/`` ディレクトリーの解析を担当するデフォルトの ``host_group_vars`` を置き換えることもできます。この設定を使用するほとんどのユーザーはインベントリスコープにしか興味がありませんが、この設定自体がすべてのソースに影響し、デバッグをさらに困難にします。公式のサンプルリポジトリーにある Playbook およびロールはすべて、この設定のデフォルトを想定しています。``merge`` に設定を変更すると、変数ソース全体に適用されますが、多くのソースでは内部的に変数が上書きされたままになります。たとえば、``include_vars`` は、Ansible を更新する前に内部で変数の重複を排除し、「最終定義」が同じファイルの以前の定義を上書きします。Ansible プロジェクトでは、**新規プロジェクトでは ``merge`` を回避する** ことが推奨されます。Ansible 開発者は、最終的にこの設定を非推奨にして削除することを意図していますが、一部のユーザーがこの設定に大きく依存しているため、この設定を残しています。新しいプロジェクトでは、**「merge」を回避** してください。

en: See also :ref:`DEFAULT_HASH_BEHAVIOUR <DEFAULT_HASH_BEHAVIOUR>`
ja: 「:ref:`DEFAULT_HASH_BEHAVIOUR <DEFAULT_HASH_BEHAVIOUR>`」も参照してください。

en: See also :ref:`DEFAULT_HOST_LIST <DEFAULT_HOST_LIST>`
ja: 「:ref:`DEFAULT_HOST_LIST <DEFAULT_HOST_LIST>`」も参照してください。

en: See also :ref:`DEFAULT_HTTPAPI_PLUGIN_PATH <DEFAULT_HTTPAPI_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_HTTPAPI_PLUGIN_PATH <DEFAULT_HTTPAPI_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_INVENTORY_PLUGIN_PATH <DEFAULT_INVENTORY_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_INVENTORY_PLUGIN_PATH <DEFAULT_INVENTORY_PLUGIN_PATH>`」も参照してください。

en: This is a developer-specific feature that allows enabling additional Jinja2 extensions.See the Jinja2 documentation for details. If you do not know what these do, you probably don't need to change this setting :)
ja: これは、追加の Jinja2 拡張機能を有効にすることができる開発者固有の機能です。詳細については、Jinja2 ドキュメントを参照してください。この拡張機能が何をするのかわからない場合は、おそらくこの設定を変更する必要はありません。

en: See also :ref:`DEFAULT_JINJA2_EXTENSIONS <DEFAULT_JINJA2_EXTENSIONS>`
ja: 「:ref:`DEFAULT_JINJA2_EXTENSIONS <DEFAULT_JINJA2_EXTENSIONS>`」も参照してください。

en: See also :ref:`DEFAULT_JINJA2_NATIVE <DEFAULT_JINJA2_NATIVE>`
ja: 「:ref:`DEFAULT_JINJA2_NATIVE <DEFAULT_JINJA2_NATIVE>`」も参照してください。

en: Enables/disables the cleaning up of the temporary files Ansible used to execute the tasks on the remote.If this option is enabled it will disable ``ANSIBLE_PIPELINING``.
ja: リモートでタスクを実行するために Ansible が使用する一時ファイルのクリーンアップを有効または無効にします。このオプションを有効にすると、``ANSIBLE_PIPELINING`` を無効にします。

en: See also :ref:`DEFAULT_KEEP_REMOTE_FILES <DEFAULT_KEEP_REMOTE_FILES>`
ja: 「:ref:`DEFAULT_KEEP_REMOTE_FILES <DEFAULT_KEEP_REMOTE_FILES>`」も参照してください。

en: See also :ref:`DEFAULT_LIBVIRT_LXC_NOSECLABEL <DEFAULT_LIBVIRT_LXC_NOSECLABEL>`
ja: 「:ref:`DEFAULT_LIBVIRT_LXC_NOSECLABEL <DEFAULT_LIBVIRT_LXC_NOSECLABEL>`」も参照してください。

en: See also :ref:`DEFAULT_LOAD_CALLBACK_PLUGINS <DEFAULT_LOAD_CALLBACK_PLUGINS>`
ja: 「:ref:`DEFAULT_LOAD_CALLBACK_PLUGINS <DEFAULT_LOAD_CALLBACK_PLUGINS>`」も参照してください。

en: See also :ref:`DEFAULT_LOCAL_TMP <DEFAULT_LOCAL_TMP>`
ja: 「:ref:`DEFAULT_LOCAL_TMP <DEFAULT_LOCAL_TMP>`」も参照してください。

en: See also :ref:`DEFAULT_LOG_PATH <DEFAULT_LOG_PATH>`
ja: 「:ref:`DEFAULT_LOG_PATH <DEFAULT_LOG_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_LOG_FILTER <DEFAULT_LOG_FILTER>`
ja: 「:ref:`DEFAULT_LOG_FILTER <DEFAULT_LOG_FILTER>`」も参照してください。

en: See also :ref:`DEFAULT_LOOKUP_PLUGIN_PATH <DEFAULT_LOOKUP_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_LOOKUP_PLUGIN_PATH <DEFAULT_LOOKUP_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_MODULE_ARGS <DEFAULT_MODULE_ARGS>`
ja: 「:ref:`DEFAULT_MODULE_ARGS <DEFAULT_MODULE_ARGS>`」も参照してください。

en: See also :ref:`DEFAULT_MODULE_PATH <DEFAULT_MODULE_PATH>`
ja: 「:ref:`DEFAULT_MODULE_PATH <DEFAULT_MODULE_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_MODULE_UTILS_PATH <DEFAULT_MODULE_UTILS_PATH>`
ja: 「:ref:`DEFAULT_MODULE_UTILS_PATH <DEFAULT_MODULE_UTILS_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_NETCONF_PLUGIN_PATH <DEFAULT_NETCONF_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_NETCONF_PLUGIN_PATH <DEFAULT_NETCONF_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_NO_LOG <DEFAULT_NO_LOG>`
ja: 「:ref:`DEFAULT_NO_LOG <DEFAULT_NO_LOG>`」も参照してください。

en: See also :ref:`DEFAULT_NO_TARGET_SYSLOG <DEFAULT_NO_TARGET_SYSLOG>`
ja: 「:ref:`DEFAULT_NO_TARGET_SYSLOG <DEFAULT_NO_TARGET_SYSLOG>`」も参照してください。

en: See also :ref:`DEFAULT_NULL_REPRESENTATION <DEFAULT_NULL_REPRESENTATION>`
ja: 「:ref:`DEFAULT_NULL_REPRESENTATION <DEFAULT_NULL_REPRESENTATION>`」も参照してください。

en: See also :ref:`DEFAULT_POLL_INTERVAL <DEFAULT_POLL_INTERVAL>`
ja: 「:ref:`DEFAULT_POLL_INTERVAL <DEFAULT_POLL_INTERVAL>`」も参照してください。

en: See also :ref:`DEFAULT_PRIVATE_KEY_FILE <DEFAULT_PRIVATE_KEY_FILE>`
ja: 「:ref:`DEFAULT_PRIVATE_KEY_FILE <DEFAULT_PRIVATE_KEY_FILE>`」も参照してください。

en: Makes role variables inaccessible from other roles.This was introduced as a way to reset role variables to default values if a role is used more than once in a playbook.
ja: ロール変数が他のロールからアクセスできないようにします。これは、Playbook でロールが複数回使用されている場合に、ロール変数をデフォルト値にリセットする方法として導入されました。

en: See also :ref:`DEFAULT_PRIVATE_ROLE_VARS <DEFAULT_PRIVATE_ROLE_VARS>`
ja: 「:ref:`DEFAULT_PRIVATE_ROLE_VARS <DEFAULT_PRIVATE_ROLE_VARS>`」も参照してください。

en: See also :ref:`DEFAULT_REMOTE_PORT <DEFAULT_REMOTE_PORT>`
ja: 「:ref:`DEFAULT_REMOTE_PORT <DEFAULT_REMOTE_PORT>`」も参照してください。

en: Sets the login user for the target machinesWhen blank it uses the connection plugin's default, normally the user currently executing Ansible.
ja: ターゲットマシンのログインユーザーを設定します。空の場合は、connection プラグインのデフォルト (通常は現在 Ansible を実行しているユーザー) を使用します。

en: See also :ref:`DEFAULT_REMOTE_USER <DEFAULT_REMOTE_USER>`
ja: 「:ref:`DEFAULT_REMOTE_USER <DEFAULT_REMOTE_USER>`」も参照してください。

en: See also :ref:`DEFAULT_ROLES_PATH <DEFAULT_ROLES_PATH>`
ja: 「:ref:`DEFAULT_ROLES_PATH <DEFAULT_ROLES_PATH>`」も参照してください。

en: Some filesystems do not support safe operations and/or return inconsistent errors, this setting makes Ansible 'tolerate' those in the list w/o causing fatal errors.Data corruption may occur and writes are not always verified when a filesystem is in the list.
ja: 一部のファイルシステムは安全な操作をサポートしていないか、一貫性のないエラーを返します。この設定により、Ansible はリスト内のエラーを「許容」し、致命的なエラーを引き起こしません。ファイルシステムがリストに含まれていると、データが破損する可能性があり、書き込みが常に検証されるとは限りません。

en: See also :ref:`DEFAULT_SELINUX_SPECIAL_FS <DEFAULT_SELINUX_SPECIAL_FS>`
ja: 「:ref:`DEFAULT_SELINUX_SPECIAL_FS <DEFAULT_SELINUX_SPECIAL_FS>`」も参照してください。

en: Set the main callback used to display Ansible output, you can only have one at a time.You can have many other callbacks, but just one can be in charge of stdout.
ja: Ansible 出力の表示に使用されるメインコールバックを設定します。一度に 1 つしか使用できません。他にも多くのコールバックを設定できますが、標準出力 (stdout) に使用できるのは 1 つだけです。

en: See also :ref:`DEFAULT_STDOUT_CALLBACK <DEFAULT_STDOUT_CALLBACK>`
ja: 「:ref:`DEFAULT_STDOUT_CALLBACK <DEFAULT_STDOUT_CALLBACK>`」も参照してください。

en: Whether or not to enable the task debugger, this previously was done as a strategy plugin.Now all strategy plugins can inherit this behavior. The debugger defaults to activating whena task is failed on unreachable. Use the debugger keyword for more flexibility.
ja: タスクデバッガーを有効にするかどうかにかかわらず、これは以前は戦略プラグインとして実行されていました。これで、すべての strategy プラグインがこの動作を継承できるようになりました。デバッガーは、タスクが到達不能で失敗したときにデフォルトでアクティブになります。柔軟性を高めるには、debugger キーワードを使用します。

en: See also :ref:`ENABLE_TASK_DEBUGGER <ENABLE_TASK_DEBUGGER>`
ja: 「:ref:`ENABLE_TASK_DEBUGGER <ENABLE_TASK_DEBUGGER>`」も参照してください。

en: This option defines whether the task debugger will be invoked on a failed task when ignore_errors=True is specified.True specifies that the debugger will honor ignore_errors, False will not honor ignore_errors.
ja: このオプションは、ignore_errors=True が指定されている場合に、失敗したタスクでタスクデバッガーが呼び出されるかどうかを定義します。True に設定すると、デバッガーが ignore_errors を許可するように指定し、False に設定すると ignore_errors が無効になります。

en: See also :ref:`TASK_DEBUGGER_IGNORE_ERRORS <TASK_DEBUGGER_IGNORE_ERRORS>`
ja: 「:ref:`TASK_DEBUGGER_IGNORE_ERRORS <TASK_DEBUGGER_IGNORE_ERRORS>`」も参照してください。

en: See also :ref:`DEFAULT_STRATEGY <DEFAULT_STRATEGY>`
ja: 「:ref:`DEFAULT_STRATEGY <DEFAULT_STRATEGY>`」も参照してください。

en: See also :ref:`DEFAULT_STRATEGY_PLUGIN_PATH <DEFAULT_STRATEGY_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_STRATEGY_PLUGIN_PATH <DEFAULT_STRATEGY_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_SU <DEFAULT_SU>`
ja: 「:ref:`DEFAULT_SU <DEFAULT_SU>`」も参照してください。

en: See also :ref:`DEFAULT_SYSLOG_FACILITY <DEFAULT_SYSLOG_FACILITY>`
ja: 「:ref:`DEFAULT_SYSLOG_FACILITY <DEFAULT_SYSLOG_FACILITY>`」も参照してください。

en: See also :ref:`DEFAULT_TASK_INCLUDES_STATIC <DEFAULT_TASK_INCLUDES_STATIC>`
ja: 「:ref:`DEFAULT_TASK_INCLUDES_STATIC <DEFAULT_TASK_INCLUDES_STATIC>`」も参照してください。

en: See also :ref:`DEFAULT_TERMINAL_PLUGIN_PATH <DEFAULT_TERMINAL_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_TERMINAL_PLUGIN_PATH <DEFAULT_TERMINAL_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_TEST_PLUGIN_PATH <DEFAULT_TEST_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_TEST_PLUGIN_PATH <DEFAULT_TEST_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_TIMEOUT <DEFAULT_TIMEOUT>`
ja: 「:ref:`DEFAULT_TIMEOUT <DEFAULT_TIMEOUT>`」も参照してください。

en: See also :ref:`DEFAULT_TRANSPORT <DEFAULT_TRANSPORT>`
ja: 「:ref:`DEFAULT_TRANSPORT <DEFAULT_TRANSPORT>`」も参照してください。

en: When True, this causes ansible templating to fail steps that reference variable names that are likely typoed.Otherwise, any '{{ template_expression }}' that contains undefined variables will be rendered in a template or ansible action line exactly as written.
ja: True にすると、これにより、タイプミスの可能性が高い変数名を参照するステップが失敗するテンプレートが作成されます。それ以外の場合は、未定義の変数を含む '{{ template_expression }}' は、記述されたとおりにテンプレートまたは Ansible のアクション行にレンダリングされます。

en: See also :ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR <DEFAULT_UNDEFINED_VAR_BEHAVIOR>`
ja: 「:ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR <DEFAULT_UNDEFINED_VAR_BEHAVIOR>`」も参照してください。

en: See also :ref:`DEFAULT_VARS_PLUGIN_PATH <DEFAULT_VARS_PLUGIN_PATH>`
ja: 「:ref:`DEFAULT_VARS_PLUGIN_PATH <DEFAULT_VARS_PLUGIN_PATH>`」も参照してください。

en: See also :ref:`DEFAULT_VAULT_ID_MATCH <DEFAULT_VAULT_ID_MATCH>`
ja: 「:ref:`DEFAULT_VAULT_ID_MATCH <DEFAULT_VAULT_ID_MATCH>`」も参照してください。

en: See also :ref:`DEFAULT_VAULT_IDENTITY <DEFAULT_VAULT_IDENTITY>`
ja: 「:ref:`DEFAULT_VAULT_IDENTITY <DEFAULT_VAULT_IDENTITY>`」も参照してください。

en: See also :ref:`DEFAULT_VAULT_ENCRYPT_IDENTITY <DEFAULT_VAULT_ENCRYPT_IDENTITY>`
ja: 「:ref:`DEFAULT_VAULT_ENCRYPT_IDENTITY <DEFAULT_VAULT_ENCRYPT_IDENTITY>`」も参照してください。

en: See also :ref:`DEFAULT_VAULT_IDENTITY_LIST <DEFAULT_VAULT_IDENTITY_LIST>`
ja: 「:ref:`DEFAULT_VAULT_IDENTITY_LIST <DEFAULT_VAULT_IDENTITY_LIST>`」も参照してください。

en: See also :ref:`DEFAULT_VAULT_PASSWORD_FILE <DEFAULT_VAULT_PASSWORD_FILE>`
ja: 「:ref:`DEFAULT_VAULT_PASSWORD_FILE <DEFAULT_VAULT_PASSWORD_FILE>`」も参照してください。

en: See also :ref:`DEFAULT_VERBOSITY <DEFAULT_VERBOSITY>`
ja: 「:ref:`DEFAULT_VERBOSITY <DEFAULT_VERBOSITY>`」も参照してください。

en: See also :ref:`DEPRECATION_WARNINGS <DEPRECATION_WARNINGS>`
ja: 「:ref:`DEPRECATION_WARNINGS <DEPRECATION_WARNINGS>`」も参照してください。

en: See also :ref:`DEVEL_WARNING <DEVEL_WARNING>`
ja: 「:ref:`DEVEL_WARNING <DEVEL_WARNING>`」も参照してください。

en: See also :ref:`DIFF_ALWAYS <DIFF_ALWAYS>`
ja: 「:ref:`DIFF_ALWAYS <DIFF_ALWAYS>`」も参照してください。

en: See also :ref:`DIFF_CONTEXT <DIFF_CONTEXT>`
ja: 「:ref:`DIFF_CONTEXT <DIFF_CONTEXT>`」も参照してください。

en: Normally ``ansible-playbook`` will print a header for each task that is run. These headers will contain the name: field from the task if you specified one. If you didn't then ``ansible-playbook`` uses the task's action to help you tell which task is presently running. Sometimes you run many of the same action and so you want more information about the task to differentiate it from others of the same action. If you set this variable to True in the config then ``ansible-playbook`` will also include the task's arguments in the header.This setting defaults to False because there is a chance that you have sensitive values in your parameters and you do not want those to be printed.If you set this to True you should be sure that you have secured your environment's stdout (no one can shoulder surf your screen and you aren't saving stdout to an insecure file) or made sure that all of your playbooks explicitly added the ``no_log: True`` parameter to tasks which have sensitive values See How do I keep secret data in my playbook? for more information.
ja: 通常、``ansible-playbook`` は、実行された各タスクのヘッダーが出力されます。これらのヘッダーにはタスクの name: フィールドが指定されていればそれが含まれます。指定していない場合は、``ansible-playbook`` がタスクのアクションを使用して、どのタスクが現在実行されているかを知ることができます。多くの同じアクションを実行する場合は、同じアクションの他のタスクと区別するために、タスクに関する詳細情報が必要になることがあります。設定でこの変数を True に設定すると、``ansible-playbook`` では、タスクの引数もヘッダーに含まれます。パラメーターに機密性の高い値が含まれている可能性があり、それらを出力しないため、この設定のデフォルトは False です。これを True に設定した場合は、環境の標準出力 (誰もあなたの画面を肩越しに盗み見ることができず、あなたは標準出力を安全でないファイルに保存していません) を確実に保護するか、すべての Playbook で機密性の高い値を持つタスクに ``no_log: True`` パラメーターを明示的に追加する必要があります。詳細は、「Playbook に機密データを保存するにはどうすれば良いですか」を参照してください。

en: See also :ref:`DISPLAY_ARGS_TO_STDOUT <DISPLAY_ARGS_TO_STDOUT>`
ja: 「:ref:`DISPLAY_ARGS_TO_STDOUT <DISPLAY_ARGS_TO_STDOUT>`」も参照してください。

en: See also :ref:`DISPLAY_SKIPPED_HOSTS <DISPLAY_SKIPPED_HOSTS>`
ja: 「:ref:`DISPLAY_SKIPPED_HOSTS <DISPLAY_SKIPPED_HOSTS>`」も参照してください。

en: By default Ansible will issue a warning when a duplicate dict key is encountered in YAML.These warnings can be silenced by adjusting this setting to False.
ja: デフォルトでは、Ansible は、YAML で重複した dict キーが発生した場合に警告を発行します。この警告は、この設定を False に設定すると非表示にすることができます。

en: See also :ref:`DUPLICATE_YAML_DICT_KEY <DUPLICATE_YAML_DICT_KEY>`
ja: 「:ref:`DUPLICATE_YAML_DICT_KEY <DUPLICATE_YAML_DICT_KEY>`」も参照してください。

en: See also :ref:`ERROR_ON_MISSING_HANDLER <ERROR_ON_MISSING_HANDLER>`
ja: 「:ref:`ERROR_ON_MISSING_HANDLER <ERROR_ON_MISSING_HANDLER>`」も参照してください。

en: See also :ref:`FACTS_MODULES <FACTS_MODULES>`
ja: 「:ref:`FACTS_MODULES <FACTS_MODULES>`」も参照してください。

en: See also :ref:`GALAXY_IGNORE_CERTS <GALAXY_IGNORE_CERTS>`
ja: 「:ref:`GALAXY_IGNORE_CERTS <GALAXY_IGNORE_CERTS>`」も参照してください。

en: See also :ref:`GALAXY_ROLE_SKELETON <GALAXY_ROLE_SKELETON>`
ja: 「:ref:`GALAXY_ROLE_SKELETON <GALAXY_ROLE_SKELETON>`」も参照してください。

en: See also :ref:`GALAXY_ROLE_SKELETON_IGNORE <GALAXY_ROLE_SKELETON_IGNORE>`
ja: 「:ref:`GALAXY_ROLE_SKELETON_IGNORE <GALAXY_ROLE_SKELETON_IGNORE>`」も参照してください。

en: See also :ref:`GALAXY_SERVER <GALAXY_SERVER>`
ja: 「:ref:`GALAXY_SERVER <GALAXY_SERVER>`」も参照してください。

en: A list of Galaxy servers to use when installing a collection.The value corresponds to the config ini header ``[galaxy_server.{{item}}]`` which defines the server details.See :ref:`galaxy_server_config` for more details on how to define a Galaxy server.The order of servers in this list is used to as the order in which a collection is resolved.Setting this config option will ignore the :ref:`galaxy_server` config option.
ja: コレクションのインストール時に使用する Galaxy サーバーの一覧。値は、サーバーの詳細を定義する config ini ヘッダー ``[galaxy_server.{{item}}]`` に対応します。Galaxy サーバーの定義方法の詳細は、「:ref:`galaxy_server_config`」を参照してください。この一覧のサーバーの順序は、コレクションの解決順序として使用されます。この設定オプションを設定すると、:ref:`galaxy_server` の設定オプションは無視されます。

en: See also :ref:`GALAXY_SERVER_LIST <GALAXY_SERVER_LIST>`
ja: 「:ref:`GALAXY_SERVER_LIST <GALAXY_SERVER_LIST>`」も参照してください。

en: See also :ref:`GALAXY_TOKEN_PATH <GALAXY_TOKEN_PATH>`
ja: 「:ref:`GALAXY_TOKEN_PATH <GALAXY_TOKEN_PATH>`」も参照してください。

en: Some steps in ``ansible-galaxy`` display a progress wheel which can cause issues on certain displays or when outputing the stdout to a file.This config option controls whether the display wheel is shown or not.The default is to show the display wheel if stdout has a tty.
ja: ``ansible-galaxy`` の一部の手順では、特定の表示で、または標準出力 (stdout) をファイルに出力するときに問題を引き起こす可能性のある進行状況ホイールを表示します。この設定オプションは、表示ホイールを表示するかどうかを制御します。デフォルトでは、stdout に tty があると、表示ホイールが表示されます。

en: See also :ref:`GALAXY_DISPLAY_PROGRESS <GALAXY_DISPLAY_PROGRESS>`
ja: 「:ref:`GALAXY_DISPLAY_PROGRESS <GALAXY_DISPLAY_PROGRESS>`」も参照してください。

en: The directory that stores cached responses from a Galaxy server.This is only used by the ``ansible-galaxy collection install`` and ``download`` commands.Cache files inside this dir will be ignored if they are world writable.
ja: Galaxy サーバーからキャッシュされた応答を保存するディレクトリーです。これは ``ansible-galaxy collection install`` コマンドおよび ``download`` コマンドによってのみ使用されます。このディレクトリー内のキャッシュファイルは、誰でも書き込み可能であれば無視されます。

en: See also :ref:`GALAXY_CACHE_DIR <GALAXY_CACHE_DIR>`
ja: 「:ref:`GALAXY_CACHE_DIR <GALAXY_CACHE_DIR>`」も参照してください。

en: See also :ref:`HOST_KEY_CHECKING <HOST_KEY_CHECKING>`
ja: 「:ref:`HOST_KEY_CHECKING <HOST_KEY_CHECKING>`」も参照してください。

en: See also :ref:`HOST_PATTERN_MISMATCH <HOST_PATTERN_MISMATCH>`
ja: 「:ref:`HOST_PATTERN_MISMATCH <HOST_PATTERN_MISMATCH>`」も参照してください。

en: See also :ref:`INTERPRETER_PYTHON <INTERPRETER_PYTHON>`
ja: 「:ref:`INTERPRETER_PYTHON <INTERPRETER_PYTHON>`」も参照してください。

en: Make ansible transform invalid characters in group names supplied by inventory sources.If 'never' it will allow for the group name but warn about the issue.When 'ignore', it does the same as 'never', without issuing a warning.When 'always' it will replace any invalid characters with '_' (underscore) and warn the userWhen 'silently', it does the same as 'always', without issuing a warning.
ja: インベントリーソースから提供されたグループ名の無効な文字を Ansible が変換します。「never」の場合、グループ名は許可されますが、問題について警告されます。「ignore」の場合は、警告を出力せずに「never」と同じように動作します。「always」の場合は、無効な文字を「_」(アンダースコア) に置き換えてユーザーに警告します。「silently」の場合は、警告を出力しませんが「always」と同じように動作します。

en: See also :ref:`TRANSFORM_INVALID_GROUP_CHARS <TRANSFORM_INVALID_GROUP_CHARS>`
ja: 「:ref:`TRANSFORM_INVALID_GROUP_CHARS <TRANSFORM_INVALID_GROUP_CHARS>`」も参照してください。

en: See also :ref:`INVALID_TASK_ATTRIBUTE_FAILED <INVALID_TASK_ATTRIBUTE_FAILED>`
ja: 「:ref:`INVALID_TASK_ATTRIBUTE_FAILED <INVALID_TASK_ATTRIBUTE_FAILED>`」も参照してください。

en: See also :ref:`INVENTORY_ANY_UNPARSED_IS_FAILED <INVENTORY_ANY_UNPARSED_IS_FAILED>`
ja: 「:ref:`INVENTORY_ANY_UNPARSED_IS_FAILED <INVENTORY_ANY_UNPARSED_IS_FAILED>`」も参照してください。

en: See also :ref:`INVENTORY_CACHE_ENABLED <INVENTORY_CACHE_ENABLED>`
ja: 「:ref:`INVENTORY_CACHE_ENABLED <INVENTORY_CACHE_ENABLED>`」も参照してください。

en: See also :ref:`INVENTORY_CACHE_PLUGIN <INVENTORY_CACHE_PLUGIN>`
ja: 「:ref:`INVENTORY_CACHE_PLUGIN <INVENTORY_CACHE_PLUGIN>`」も参照してください。

en: See also :ref:`INVENTORY_CACHE_PLUGIN_CONNECTION <INVENTORY_CACHE_PLUGIN_CONNECTION>`
ja: 「:ref:`INVENTORY_CACHE_PLUGIN_CONNECTION <INVENTORY_CACHE_PLUGIN_CONNECTION>`」も参照してください。

en: See also :ref:`INVENTORY_CACHE_PLUGIN_PREFIX <INVENTORY_CACHE_PLUGIN_PREFIX>`
ja: 「:ref:`INVENTORY_CACHE_PLUGIN_PREFIX <INVENTORY_CACHE_PLUGIN_PREFIX>`」も参照してください。

en: See also :ref:`INVENTORY_CACHE_TIMEOUT <INVENTORY_CACHE_TIMEOUT>`
ja: 「:ref:`INVENTORY_CACHE_TIMEOUT <INVENTORY_CACHE_TIMEOUT>`」も参照してください。

en: See also :ref:`INVENTORY_ENABLED <INVENTORY_ENABLED>`
ja: 「:ref:`INVENTORY_ENABLED <INVENTORY_ENABLED>`」も参照してください。

en: See also :ref:`INVENTORY_EXPORT <INVENTORY_EXPORT>`
ja: 「:ref:`INVENTORY_EXPORT <INVENTORY_EXPORT>`」も参照してください。

en: See also :ref:`INVENTORY_IGNORE_EXTS <INVENTORY_IGNORE_EXTS>`
ja: 「:ref:`INVENTORY_IGNORE_EXTS <INVENTORY_IGNORE_EXTS>`」も参照してください。

en: See also :ref:`INVENTORY_IGNORE_PATTERNS <INVENTORY_IGNORE_PATTERNS>`
ja: 「:ref:`INVENTORY_IGNORE_PATTERNS <INVENTORY_IGNORE_PATTERNS>`」も参照してください。

en: See also :ref:`INVENTORY_UNPARSED_IS_FAILED <INVENTORY_UNPARSED_IS_FAILED>`
ja: 「:ref:`INVENTORY_UNPARSED_IS_FAILED <INVENTORY_UNPARSED_IS_FAILED>`」も参照してください。

en: See also :ref:`MAX_FILE_SIZE_FOR_DIFF <MAX_FILE_SIZE_FOR_DIFF>`
ja: 「:ref:`MAX_FILE_SIZE_FOR_DIFF <MAX_FILE_SIZE_FOR_DIFF>`」も参照してください。

en: See also :ref:`NETWORK_GROUP_MODULES <NETWORK_GROUP_MODULES>`
ja: 「:ref:`NETWORK_GROUP_MODULES <NETWORK_GROUP_MODULES>`」も参照してください。

en: Facts are available inside the `ansible_facts` variable, this setting also pushes them as their own vars in the main namespace.Unlike inside the `ansible_facts` dictionary, these will have an `ansible_` prefix.
ja: ファクトは `ansible_facts` 変数内で利用できます。この設定は、主な名前空間で独自の変数としてプッシュされます。`ansible_facts` ディクショナリー内とは異なり、これには `ansible_` の接頭辞があります。

en: See also :ref:`INJECT_FACTS_AS_VARS <INJECT_FACTS_AS_VARS>`
ja: 「:ref:`INJECT_FACTS_AS_VARS <INJECT_FACTS_AS_VARS>`」も参照してください。

en: List of extensions to ignore when looking for modules to loadThis is for rejecting script and binary module fallback extensions
ja: 読み込むモジュールを探すときに無視する拡張機能のリスト。これは、スクリプトおよびバイナリーモジュールのフォールバック拡張機能を拒否するためのものです。

en: See also :ref:`MODULE_IGNORE_EXTS <MODULE_IGNORE_EXTS>`
ja: 「:ref:`MODULE_IGNORE_EXTS <MODULE_IGNORE_EXTS>`」も参照してください。

en: See also :ref:`OLD_PLUGIN_CACHE_CLEARING <OLD_PLUGIN_CACHE_CLEARING>`
ja: 「:ref:`OLD_PLUGIN_CACHE_CLEARING <OLD_PLUGIN_CACHE_CLEARING>`」も参照してください。

en: See also :ref:`PARAMIKO_HOST_KEY_AUTO_ADD <PARAMIKO_HOST_KEY_AUTO_ADD>`
ja: 「:ref:`PARAMIKO_HOST_KEY_AUTO_ADD <PARAMIKO_HOST_KEY_AUTO_ADD>`」も参照してください。

en: See also :ref:`PARAMIKO_LOOK_FOR_KEYS <PARAMIKO_LOOK_FOR_KEYS>`
ja: 「:ref:`PARAMIKO_LOOK_FOR_KEYS <PARAMIKO_LOOK_FOR_KEYS>`」も参照してください。

en: See also :ref:`PERSISTENT_CONTROL_PATH_DIR <PERSISTENT_CONTROL_PATH_DIR>`
ja: 「:ref:`PERSISTENT_CONTROL_PATH_DIR <PERSISTENT_CONTROL_PATH_DIR>`」も参照してください。

en: See also :ref:`PERSISTENT_CONNECT_TIMEOUT <PERSISTENT_CONNECT_TIMEOUT>`
ja: 「:ref:`PERSISTENT_CONNECT_TIMEOUT <PERSISTENT_CONNECT_TIMEOUT>`」も参照してください。

en: See also :ref:`PERSISTENT_CONNECT_RETRY_TIMEOUT <PERSISTENT_CONNECT_RETRY_TIMEOUT>`
ja: 「:ref:`PERSISTENT_CONNECT_RETRY_TIMEOUT <PERSISTENT_CONNECT_RETRY_TIMEOUT>`」も参照してください。

en: See also :ref:`PERSISTENT_COMMAND_TIMEOUT <PERSISTENT_COMMAND_TIMEOUT>`
ja: 「:ref:`PERSISTENT_COMMAND_TIMEOUT <PERSISTENT_COMMAND_TIMEOUT>`」も参照してください。

en: See also :ref:`PLAYBOOK_DIR <PLAYBOOK_DIR>`
ja: 「:ref:`PLAYBOOK_DIR <PLAYBOOK_DIR>`」も参照してください。

en: This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host_vars/group_varsThe ``top`` option follows the traditional behaviour of using the top playbook in the chain to find the root directory.The ``bottom`` option follows the 2.4.0 behaviour of using the current playbook to find the root directory.The ``all`` option examines from the first parent to the current playbook.
ja: これにより、vars プラグインを処理するためのルートとして使用される Playbook ディレクトリーが設定されます。これには、host_vars/group_vars の検索が含まれます。``top`` オプションは、チェーンの最上位の Playbook を使用してルートディレクトリーを見つけるという従来の動作に従います。``bottom`` オプションは、現在の Playbook を使用してルートディレクトリーを検索する 2.4.0 の動作に従います。``all`` オプションは、最初の親から現在の Playbook までを調べます。

en: See also :ref:`PLAYBOOK_VARS_ROOT <PLAYBOOK_VARS_ROOT>`
ja: 「:ref:`PLAYBOOK_VARS_ROOT <PLAYBOOK_VARS_ROOT>`」も参照してください。

en: See also :ref:`PYTHON_MODULE_RLIMIT_NOFILE <PYTHON_MODULE_RLIMIT_NOFILE>`
ja: 「:ref:`PYTHON_MODULE_RLIMIT_NOFILE <PYTHON_MODULE_RLIMIT_NOFILE>`」も参照してください。

en: See also :ref:`RETRY_FILES_ENABLED <RETRY_FILES_ENABLED>`
ja: 「:ref:`RETRY_FILES_ENABLED <RETRY_FILES_ENABLED>`」も参照してください。

en: This sets the path in which Ansible will save .retry files when a playbook fails and retry files are enabled.This file will be overwritten after each run with the list of failed hosts from all plays.
ja: これにより、Playbook が失敗し、再試行ファイルが有効になっている場合に、Ansible が .retry ファイルを保存するパスが設定されます。このファイルは、実行するたびに、すべてのプレイで失敗したホストのリストで上書きされます。

en: See also :ref:`RETRY_FILES_SAVE_PATH <RETRY_FILES_SAVE_PATH>`
ja: 「:ref:`RETRY_FILES_SAVE_PATH <RETRY_FILES_SAVE_PATH>`」も参照してください。

en: This setting can be used to optimize vars_plugin usage depending on user's inventory size and play selection.Setting to C(demand) will run vars_plugins relative to inventory sources anytime vars are 'demanded' by tasks.Setting to C(start) will run vars_plugins relative to inventory sources after importing that inventory source.
ja: この設定は、ユーザーのインベントリーサイズとプレイの選択に応じて vars_plugin の使用を最適化するために使用できます。C(demand) に設定すると、タスクによって変数が「要求」されるたびに、インベントリーソースに関連して vars_plugins が実行されます。C(start) に設定すると、インベントリーソースをインポートした後、インベントリーソースに関連して vars_plugins が実行されます。

en: See also :ref:`RUN_VARS_PLUGINS <RUN_VARS_PLUGINS>`
ja: 「:ref:`RUN_VARS_PLUGINS <RUN_VARS_PLUGINS>`」も参照してください。

en: See also :ref:`SHOW_CUSTOM_STATS <SHOW_CUSTOM_STATS>`
ja: 「:ref:`SHOW_CUSTOM_STATS <SHOW_CUSTOM_STATS>`」も参照してください。

en: This list of filters avoids 'type conversion' when templating variablesUseful when you want to avoid conversion into lists or dictionaries for JSON strings, for example.
ja: このフィルターのリストは、変数をテンプレート化するときに「型変換」を回避します。たとえば、JSON 文字列のリストやディレクトリーへの変換を回避したい場合に便利です。

en: See also :ref:`STRING_TYPE_FILTERS <STRING_TYPE_FILTERS>`
ja: 「:ref:`STRING_TYPE_FILTERS <STRING_TYPE_FILTERS>`」も参照してください。

en: Allows disabling of warnings related to potential issues on the system running ansible itself (not on the managed hosts)These may include warnings about 3rd party packages or other conditions that should be resolved if possible.
ja: Ansible 自体を実行している (管理対象ホストではない) システムの潜在的な問題に関連する警告を無効にすることができます。これには、サードパーティーのパッケージに関する警告や、可能であれば解決する必要のあるその他の条件が含まれる場合があります。

en: See also :ref:`SYSTEM_WARNINGS <SYSTEM_WARNINGS>`
ja: 「:ref:`SYSTEM_WARNINGS <SYSTEM_WARNINGS>`」も参照してください。

en: See also :ref:`TAGS_RUN <TAGS_RUN>`
ja: 「:ref:`TAGS_RUN <TAGS_RUN>`」も参照してください。

en: See also :ref:`TAGS_SKIP <TAGS_SKIP>`
ja: 「:ref:`TAGS_SKIP <TAGS_SKIP>`」も参照してください。

en: Set the maximum time (in seconds) that a task can run for.If set to 0 (the default) there is no timeout.
ja: タスクを実行する最大時間 (秒単位) を設定します。0 (デフォルト) に設定するとタイムアウトはありません。

en: See also :ref:`TASK_TIMEOUT <TASK_TIMEOUT>`
ja: 「:ref:`TASK_TIMEOUT <TASK_TIMEOUT>`」も参照してください。

en: The maximum number of times to check Task Queue Manager worker processes to verify they have exited cleanly.After this limit is reached any worker processes still running will be terminated.This is for internal use only.
ja: Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認する最大回数。この制限に達すると、まだ実行中のワーカープロセスはすべて終了します。これは内部使用のみです。

en: See also :ref:`WORKER_SHUTDOWN_POLL_COUNT <WORKER_SHUTDOWN_POLL_COUNT>`
ja: 「:ref:`WORKER_SHUTDOWN_POLL_COUNT <WORKER_SHUTDOWN_POLL_COUNT>`」も参照してください。

en: The number of seconds to sleep between polling loops when checking Task Queue Manager worker processes to verify they have exited cleanly.This is for internal use only.
ja: Task Queue Manager ワーカープロセスをチェックして、それらが正常に終了したことを確認するときに、ポーリングループ間でスリープする秒数。これは内部使用のみです。

en: See also :ref:`WORKER_SHUTDOWN_POLL_DELAY <WORKER_SHUTDOWN_POLL_DELAY>`
ja: 「:ref:`WORKER_SHUTDOWN_POLL_DELAY <WORKER_SHUTDOWN_POLL_DELAY>`」も参照してください。

en: See also :ref:`USE_PERSISTENT_CONNECTIONS <USE_PERSISTENT_CONNECTIONS>`
ja: 「:ref:`USE_PERSISTENT_CONNECTIONS <USE_PERSISTENT_CONNECTIONS>`」も参照してください。

en: See also :ref:`VARIABLE_PLUGINS_ENABLED <VARIABLE_PLUGINS_ENABLED>`
ja: 「:ref:`VARIABLE_PLUGINS_ENABLED <VARIABLE_PLUGINS_ENABLED>`」も参照してください。

en: See also :ref:`VARIABLE_PRECEDENCE <VARIABLE_PRECEDENCE>`
ja: 「:ref:`VARIABLE_PRECEDENCE <VARIABLE_PRECEDENCE>`」も参照してください。

en: For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how long, in seconds, to wait for the task spawned by Ansible to connect back to the named pipe used on Windows systems. The default is 5 seconds. This can be too low on slower systems, or systems under heavy load.This is not the total time an async command can run for, but is a separate timeout to wait for an async command to start. The task will only start to be timed against its async_timeout once it has connected to the pipe, so the overall maximum duration the task can take will be extended by the amount specified here.
ja: Ansible の非同期タスク (「非同期アクションおよびポーリング」で説明) の場合、これは、Ansible が生成するタスクが Windows システムで使用される名前付きパイプに接続するのを待機する時間 (秒単位) です。デフォルトは 5 秒です。これは、低速のシステムや高負荷のシステムでは低すぎる可能性があります。これは、非同期コマンドを実行できる合計時間ではありませんが、非同期コマンドの開始を待機する別のタイムアウトです。タスクは、パイプに接続された後にのみ async_timeout に対してタイムアウトが開始するため、タスクの全体的な最大期間は、ここで指定された分だけ延長されます。

en: See also :ref:`WIN_ASYNC_STARTUP_TIMEOUT <WIN_ASYNC_STARTUP_TIMEOUT>`
ja: 「:ref:`WIN_ASYNC_STARTUP_TIMEOUT <WIN_ASYNC_STARTUP_TIMEOUT>`」も参照してください。

en: Check all of these extensions when looking for 'variable' files which should be YAML or JSON or vaulted versions of these.This affects vars_files, include_vars, inventory and vars plugins among others.
ja: YAML または JSON、あるいはこれらの Vault バージョンである必要がある「変数」ファイルを探すときは、これらすべての拡張子を確認してください。これは、vars_files、include_vars、inventory、vars プラグインなどに影響します。

en: See also :ref:`YAML_FILENAME_EXTENSIONS <YAML_FILENAME_EXTENSIONS>`
ja: 「:ref:`YAML_FILENAME_EXTENSIONS <YAML_FILENAME_EXTENSIONS>`」も参照してください。

en: See also :ref:`NETCONF_SSH_CONFIG <NETCONF_SSH_CONFIG>`
ja: 「:ref:`NETCONF_SSH_CONFIG <NETCONF_SSH_CONFIG>`」も参照してください。

en: Action to take when a module parameter value is converted to a string (this does not affect variables). For string parameters, values such as '1.00', "['a', 'b',]", and 'yes', 'y', etc. will be converted by the YAML parser unless fully quoted.Valid options are 'error', 'warn', and 'ignore'.Since 2.8, this option defaults to 'warn' but will change to 'error' in 2.12.
ja: モジュールパラメーター値が文字列に変換されるときに実行するアクション (これは変数には影響しません)。文字列パラメーターの場合、「1.00」、「['a', 'b',]」、「yes」、「y」などの値は、完全に引用されていない限り、YAML パーサーにより変換されます。有効なオプションは、「error」、「warn」、および「ignore」です。2.8 以降、このオプションのデフォルトは「warn」ですが、2.12では「error」に変更されます。

en: See also :ref:`STRING_CONVERSION_ACTION <STRING_CONVERSION_ACTION>`
ja: 「:ref:`STRING_CONVERSION_ACTION <STRING_CONVERSION_ACTION>`」も参照してください。

en: See also :ref:`VERBOSE_TO_STDERR <VERBOSE_TO_STDERR>`
ja: 「:ref:`VERBOSE_TO_STDERR <VERBOSE_TO_STDERR>`」も参照してください。

en: Frequently Asked Questions
ja: よくある質問 (FAQ)

en: Here are some commonly asked questions and their answers.
ja: 以下に、よくある質問とその回答を紹介しています。

en: Where did all the modules go?
ja: すべてのモジュールはどこに移されましたか

en: In July, 2019, we announced that collections would be the `future of Ansible content delivery <https://www.ansible.com/blog/the-future-of-ansible-content-delivery>`_. A collection is a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. In Ansible 2.9 we added support for collections. In Ansible 2.10 we `extracted most modules from the main ansible/ansible repository <https://access.redhat.com/solutions/5295121>`_ and placed them in :ref:`collections <list_of_collections>`. Collections may be maintained by the Ansible team, by the Ansible community, or by Ansible partners. The `ansible/ansible repository <https://github.com/ansible/ansible>`_ now contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-core`` (it was briefly called ``ansible-base`` for version 2.10).
ja: 2019 年 7 月、コレクションが `今後の Ansible コンテンツ配布 <https://www.ansible.com/blog/the-future-of-ansible-content-delivery>`_ になることが発表されました。コレクションは、Playbook、ロール、モジュール、およびプラグインを含む Ansible コンテンツの配布形式です。Ansible 2.9 では、コレクションのサポートを追加しました。Ansible 2.10 では、`ansible/ansible のメインリポジトリーからほとんどモジュールを取り出して <https://access.redhat.com/solutions/5295121>`_、そのモジュールを :ref:`collections <list_of_collections>` に置きました。コレクションは、Ansible チーム、Ansible コミュニティー、または Ansible パートナーによって維持されます。`ansible/ansible リポジトリー <https://github.com/ansible/ansible>`_ には、モジュールコードを管理対象ノードにコピーするなど、基本的な機能および関数のコードが含まれています。このコードは ``ansible-core`` とも呼ばれます (バージョン 2.10 の場合は ``ansible-base`` と呼ばれています)。

en: To learn more about using collections, see :ref:`collections`.
ja: コレクションの使用に関する詳細は、「:ref:`collections`」を参照してください。

en: To learn more about developing collections, see :ref:`developing_collections`.
ja: コレクション開発に関する詳細は、「:ref:`developing_collections`」を参照してください。

en: To learn more about contributing to existing collections, see the individual collection repository for guidelines, or see :ref:`contributing_maintained_collections` to contribute to one of the Ansible-maintained collections.
ja: 既存のコレクションへの貢献の詳細については、個々のコレクションリポジトリーでガイドラインを参照するか、Ansible が管理するコレクションのいずれかに貢献する方法を「:ref:`contributing_maintained_collections`」で参照してください。

en: Where did this specific module go?
ja: この特定のモジュールはどこに移されましたか

en: IF you are searching for a specific module, you can check the `runtime.yml <https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml>`_ file, which lists the first destination for each module that we extracted from the main ansible/ansible repository. Some modules have moved again since then. You can also search on `Ansible Galaxy <https://galaxy.ansible.com/>`_ or ask on one of our :ref:`IRC channels <communication_irc>`.
ja: 特定のモジュールを検索する場合は、`runtime.yml <https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml>`_ ファイルをチェックできます。このファイルには、メインの ansible/ansible リポジトリーから抽出した各モジュールの最初の宛先がリストされています。その後、いくつかのモジュールが再び移動しました。`Ansible Galaxy <https://galaxy.ansible.com/>`_ で検索することもできますし、いずれかの :ref:`IRC チャンネル <communication_irc>` で尋ねることもできます。

en: How can I set the PATH or any other environment variable for a task or entire play?
ja: タスクやプレイ全体に PATH またはその他の環境変数をどのように設定すれば良いですか

en: Setting environment variables can be done with the `environment` keyword. It can be used at the task or other levels in the play.
ja: 環境変数の設定は、`environment` キーワードで実行できます。これは、プレイ内のタスクや他のレベルで使用できます。

en: starting in 2.0.1 the setup task from ``gather_facts`` also inherits the environment directive from the play, you might need to use the ``|default`` filter to avoid errors if setting this at play level.
ja: 2.0.1 以降で、``gather_facts`` の設定タスクは、プレイからの環境ディレクティブも継承します。これがプレイレベルで設定されている場合は、``|default`` フィルターを使用したエラーの回避が必要になる場合があります。

en: How do I handle different machines needing different user accounts or ports to log in with?
ja: 異なるユーザーアカウントまたはポートでログインする必要のある各種マシンをどのように処理すれば良いですか

en: Setting inventory variables in the inventory file is the easiest way.
ja: インベントリーファイルにインベントリー変数を設定する方法が最も簡単です。

en: For instance, suppose these hosts have different usernames and ports:
ja: たとえば、以下では、ホストに異なるユーザー名とポートが指定されています。

en: You can also dictate the connection type to be used, if you want:
ja: 任意で、使用する接続タイプを指定できます。

en: You may also wish to keep these in group variables instead, or file them in a group_vars/<groupname> file. See the rest of the documentation for more information about how to organize variables.
ja: 上記の値を、代わりにグループ変数や group_vars/<groupname> ファイルに保持できます。変数を整理する方法は、本ガイドの他のセクションを参照してください。

en: How do I get ansible to reuse connections, enable Kerberized SSH, or have Ansible pay attention to my local SSH config file?
ja: Ansible を使用して接続を再利用したり、Kerberos を設定した SSH を有効にしたり、Ansible がローカルの SSH 設定を使用するにはどうしたら良いですか

en: Switch your default connection type in the configuration file to ``ssh``, or use ``-c ssh`` to use Native OpenSSH for connections instead of the python paramiko library. In Ansible 1.2.1 and later, ``ssh`` will be used by default if OpenSSH is new enough to support ControlPersist as an option.
ja: 設定ファイルのデフォルトの接続タイプを ``ssh`` に切り替えるか、Python Paramiko ライブラリーの代わりに、``-c ssh`` で、接続にネイティブの OpenSSH を使用してください。Ansible 1.2.1 以降では、OpenSSH が新しく、オプションとして ControlPersist をサポートする場合にはデフォルトで ``ssh`` を使用します。

en: Paramiko is great for starting out, but the OpenSSH type offers many advanced options. You will want to run Ansible from a machine new enough to support ControlPersist, if you are using this connection type. You can still manage older clients. If you are using RHEL 6, CentOS 6, SLES 10 or SLES 11 the version of OpenSSH is still a bit old, so consider managing from a Fedora or openSUSE client even though you are managing older nodes, or just use paramiko.
ja: Paramiko は使用を開始するときには便利ですが、OpenSSH のタイプでは多数の詳細オプションを利用できます。OpenSSH の接続タイプを使用する場合には、ControlPersist をサポートできる新しいマシンから Ansible を実行してください。古いクライアントは引き続き管理できます。RHEL 6、CentOS 6、SLES 10、または SLES 11 を使用している場合は、OpenSSH のバージョンが若干古いため、以前のノードを管理している場合でも、Fedora または openSUSE クライアントからの管理を検討するか、paramiko を使用してください。

en: We keep paramiko as the default as if you are first installing Ansible on these enterprise operating systems, it offers a better experience for new users.
ja: Paramiko は、これらのエンタープライズオペレーティングシステムに Ansible を最初にインストールしている場合と同じようにデフォルトのままとなっており、新規ユーザーによって使用しやすくなっています。

en: How do I configure a jump host to access servers that I have no direct access to?
ja: 直接アクセス権のないサーバーにジャンプホストを使用してアクセスできるように設定するにはどうすれば良いですか

en: You can set a ``ProxyCommand`` in the ``ansible_ssh_common_args`` inventory variable. Any arguments specified in this variable are added to the sftp/scp/ssh command line when connecting to the relevant host(s). Consider the following inventory group:
ja: ``ansible_ssh_common_args`` インベントリー変数に ``ProxyCommand`` を設定することができます。該当のホストに接続したときに、この変数に指定した引数は、sftp/scp/ssh コマンドラインに追加されます。次のインベントリーグループについて考えてみます。

en: You can create `group_vars/gatewayed.yml` with the following contents::
ja: 以下の内容で `group_vars/gatewayed.yml` を作成できます::

en: Ansible will append these arguments to the command line when trying to connect to any hosts in the group ``gatewayed``. (These arguments are used in addition to any ``ssh_args`` from ``ansible.cfg``, so you do not need to repeat global ``ControlPersist`` settings in ``ansible_ssh_common_args``.)
ja: Ansible は、``gatewayed`` グループのホストに接続しようとすると、コマンドラインに 3 つの引数を追加します。(``ansible.cfg`` からの ``ssh_args`` に加えて、上記の引数が使用されるため、``ansible_ssh_common_args`` のグローバル ``ControlPersist`` 設定を繰り返す必要はありません)。

en: Note that ``ssh -W`` is available only with OpenSSH 5.4 or later. With older versions, it's necessary to execute ``nc %h:%p`` or some equivalent command on the bastion host.
ja: ``ssh -W`` は、OpenSSH 5.4 以降でのみ利用できます。以前のバージョンでは、bastion ホストで ``nc %h:%p`` を実行するか、同等のコマンドを実行する必要があります。

en: With earlier versions of Ansible, it was necessary to configure a suitable ``ProxyCommand`` for one or more hosts in ``~/.ssh/config``, or globally by setting ``ssh_args`` in ``ansible.cfg``.
ja: Ansible の以前のバージョンでは、``~/.ssh/config`` のホスト 1 台または複数台に適切な ``ProxyCommand`` を設定するか、``ansible.cfg`` に ``ssh_args`` をグローバルに設定する必要がありました。

en: How do I get Ansible to notice a dead target in a timely manner?
ja: Ansible がダウンしているターゲットを適宜検出できるようにするにはどうすれば良いですか

en: You can add ``-o ServerAliveInterval=NumberOfSeconds`` in ``ssh_args`` from ``ansible.cfg``. Without this option, SSH and therefore Ansible will wait until the TCP connection times out. Another solution is to add ``ServerAliveInterval`` into your global SSH configuration. A good value for ``ServerAliveInterval`` is up to you to decide; keep in mind that ``ServerAliveCountMax=3`` is the SSH default so any value you set will be tripled before terminating the SSH session.
ja: ``ansible.cfg`` から、``ssh_args`` に ``-o ServerAliveInterval=NumberOfSeconds`` を追加できます。このオプションがないと、SSH と Ansible は TCP 接続がタイムアウトになるまで待機します。別の解決方法は、``ServerAliveInterval`` をグローバルの SSH 設定に追加することです。``ServerAliveInterval`` に適した値は、ユーザーが決定します。ただし、SSH のデフォルトは ``ServerAliveCountMax=3`` であるため、SSH セッションの終了前に設定した値が 3 倍になる点に注意してください。

en: How do I speed up run of ansible for servers from cloud providers (EC2, openstack,.. )?
ja: クラウドプロバイダー (EC2、openstack など) からのサーバーで Ansible の実行を高速化するにはどうすれば良いですか

en: Don't try to manage a fleet of machines of a cloud provider from your laptop. Rather connect to a management node inside this cloud provider first and run Ansible from there.
ja: ラップトップからクラウドプロバイダーのマシンのフリートを管理しようとしないでください。代わりに、最初にこのクラウドプロバイダー内の管理ノードに接続し、そこから Ansible を実行します。

en: How do I handle not having a Python interpreter at /usr/bin/python on a remote machine?
ja: リモートマシンの /usr/bin/python に Python インタープリターを配置せずに対応するにはどうすれば良いですか

en: While you can write Ansible modules in any language, most Ansible modules are written in Python, including the ones central to letting Ansible work.
ja: Ansible モジュールはどの言語でも記述できますが、Ansible の機能を司るコアモジュールなど、Ansible モジュールの多くは Python で記述されています。

en: By default, Ansible assumes it can find a :command:`/usr/bin/python` on your remote system that is either Python2, version 2.6 or higher or Python3, 3.5 or higher.
ja: デフォルトでは、Ansible は、Python2 のバージョン 2.6 以降または Python3 の 3.5 以降のリモートマシンの :command:`/usr/bin/python` を検出できます。

en: Setting the inventory variable ``ansible_python_interpreter`` on any host will tell Ansible to auto-replace the Python interpreter with that value instead. Thus, you can point to any Python you want on the system if :command:`/usr/bin/python` on your system does not point to a compatible Python interpreter.
ja: ホストにインベントリー変数 ``ansible_python_interpreter`` を設定すると、Ansible に対して、代わりに Python インタープリターをこのインベントリー変数の値に自動で置き換えるように指示を出します。このように、お使いのシステムの :command:`/usr/bin/python` が互換性のある Python インタープリターを指定していない場合は、使用する Python を指定できます。

en: Some platforms may only have Python 3 installed by default. If it is not installed as :command:`/usr/bin/python`, you will need to configure the path to the interpreter via ``ansible_python_interpreter``. Although most core modules will work with Python 3, there may be some special purpose ones which do not or you may encounter a bug in an edge case. As a temporary workaround you can install Python 2 on the managed host and configure Ansible to use that Python via ``ansible_python_interpreter``. If there's no mention in the module's documentation that the module requires Python 2, you can also report a bug on our `bug tracker <https://github.com/ansible/ansible/issues>`_ so that the incompatibility can be fixed in a future release.
ja: プラットフォームによっては、デフォルトで Python3 のみがインストールされている場合があります。:command:`/usr/bin/python` としてインストールされていない場合は、``ansible_python_interpreter`` を介してインタープリターへのパスを設定する必要があります。コアモジュールの多くが Python 3 と連携しますが、いくつかの特殊用途のモジュールは動作しないかもしれないし、特殊なケースでバグが発生するかもしれません。一時的な回避策として、管理対象ホストに Python 2をインストールし、``ansible_python_interpreter`` からその Python を使用するように Ansible を構成できます。モジュールのドキュメントに Python 2 が必要あるとの記載がない場合は、今後このリリースで非互換性の問題が解決されるように、`バグトラッカー <https://github.com/ansible/ansible/issues>`_ で、バグを報告できます。

en: Do not replace the shebang lines of your python modules. Ansible will do this for you automatically at deploy time.
ja: Python モジュールのシバン行は置き換えないでください。デプロイ時に Ansible が自動でこれを行います。

en: Also, this works for ANY interpreter, for example ruby: ``ansible_ruby_interpreter``, perl: ``ansible_perl_interpreter``, and so on, so you can use this for custom modules written in any scripting language and control the interpreter location.
ja: また、これは、ruby などのすべてのインタープリター (ruby: ``ansible_ruby_interpreter``、perl: ``ansible_perl_interpreter`` など) で機能するため、任意のスクリプト言語で記述したカスタムモジュールにこれを使用して、インタープリターの場所を管理できます。

en: Keep in mind that if you put ``env`` in your module shebang line (``#!/usr/bin/env <other>``), this facility will be ignored so you will be at the mercy of the remote `$PATH`.
ja: モジュールのシバンの行 (``#!/usr/bin/env <other>``) に ``env`` を挿入すると、この機能は無視され、リモートの `$PATH` の設定が使用されます。

en: How do I handle the package dependencies required by Ansible package dependencies during Ansible installation ?
ja: Ansible インストール中に Ansible パッケージに必要な依存関係にどのように対応すれば良いですか

en: While installing Ansible, sometimes you may encounter errors such as `No package 'libffi' found` or `fatal error: Python.h: No such file or directory` These errors are generally caused by the missing packages, which are dependencies of the packages required by Ansible. For example, `libffi` package is dependency of `pynacl` and `paramiko` (Ansible -> paramiko -> pynacl -> libffi).
ja: Ansible のインストール中に、`No package 'libffi' found` または `fatal error: Python.h: No such file or directory` などのエラーが発生する場合があります。このようなエラーは通常、Ansible で必要なパッケージの依存関係パッケージが不足している場合に発生します。たとえば、`libffi` パッケージは `pynacl` および `paramiko` の依存関係です (Ansible -> paramiko -> pynacl -> libffi)。

en: In order to solve these kinds of dependency issues, you might need to install required packages using the OS native package managers, such as `yum`, `dnf`, or `apt`, or as mentioned in the package installation guide.
ja: このような依存関係の問題を解決するには、OS ネイティブのパッケージマネージャー (`yum`、`dnf`、`apt`、またはパッケージのインストールガイドに記載のもの) を使用して必要なパッケージをインストールしないといけない場合があります。

en: Refer to the documentation of the respective package for such dependencies and their installation methods.
ja: このような依存関係とそのインストール方法については、各パッケージのドキュメントを参照してください。

en: Common Platform Issues
ja: 一般的なプラットフォームの問題

en: What customer platforms does Red Hat support?
ja: Red Hat では、どのような顧客のプラットフォームをサポートしていますか

en: A number of them! For a definitive list please see this `Knowledge Base article <https://access.redhat.com/articles/3168091>`_.
ja: その数は多数です。具体的な一覧は、`ナレッジベースの記事 <https://access.redhat.com/articles/3168091>`_ を参照してください。

en: Running in a virtualenv
ja: virtualenv での実行

en: You can install Ansible into a virtualenv on the controller quite simply:
ja: コントローラーの virtualenv に Ansible を簡単にインストールできます。

en: If you want to run under Python 3 instead of Python 2 you may want to change that slightly:
ja: Python 2 ではなく Python 3 で実行する場合は、以下のように変更する場合があります。

en: If you need to use any libraries which are not available via pip (for instance, SELinux Python bindings on systems such as Red Hat Enterprise Linux or Fedora that have SELinux enabled), then you need to install them into the virtualenv. There are two methods:
ja: pip で入手できないライブラリーを使用する必要がある場合は (例: SELinux が有効な Red Hat Enterprise Linux または Fedora などのシステムにある SELinux Python のバインディング)、virtualenv にインストールする必要があります。2 つの方法があります。

en: When you create the virtualenv, specify ``--system-site-packages`` to make use of any libraries installed in the system's Python:
ja: virtualenv の作成時に、``--system-site-packages`` を指定して、お使いのシステムの Python にインストールされているライブラリーを使用します。

en: Copy those files in manually from the system. For instance, for SELinux bindings you might do:
ja: システムから手動でこれらのファイルをコピーします。たとえば、SELinux バインディングでは、以下を行うことができます。

en: Running on BSD
ja: BSD での実行

en: Running on Solaris
ja: Solaris での実行

en: By default, Solaris 10 and earlier run a non-POSIX shell which does not correctly expand the default tmp directory Ansible uses ( :file:`~/.ansible/tmp`). If you see module failures on Solaris machines, this is likely the problem. There are several workarounds:
ja: デフォルトでは Solaris 10 以前では POSIX 以外のシェルを実行しますが、Ansible が使用するデフォルトの tmp ディレクトリー (:file:`~/.ansible/tmp`) を正しく展開しません。Solaris マシンでモジュールの問題が発生する場合には、上記が問題の可能性が高いです。回避策はいくつかあります。

en: You can set ``remote_tmp`` to a path that will expand correctly with the shell you are using (see the plugin documentation for :ref:`C shell<csh_shell>`, :ref:`fish shell<fish_shell>`, and :ref:`Powershell<powershell_shell>`). For example, in the ansible config file you can set::
ja: 使用するシェル (:ref:`C shell<csh_shell>`、:ref:`fish shell<fish_shell>`、および :ref:`Powershell<powershell_shell>` のプラグインのドキュメントを参照) で正しく展開されるパスに ``remote_tmp`` を設定します。設定する ansible 設定ファイルで、以下を指定します。

en: In Ansible 2.5 and later, you can also set it per-host in inventory like this::
ja: Ansible 2.5 以降では、以下のようにインベントリーでホストごとに設定することも可能です。

en: You can set :ref:`ansible_shell_executable<ansible_shell_executable>` to the path to a POSIX compatible shell. For instance, many Solaris hosts have a POSIX shell located at :file:`/usr/xpg4/bin/sh` so you can set this in inventory like so::
ja: :ref:`ansible_shell_executable<ansible_shell_executable>` を、POSIX の互換性のあるパスに設定します。たとえば、多数の Solaris ホストでは POSIX シェルが、:file:`/usr/xpg4/bin/sh` に配置されているため、インベントリーにこの値を以下のように設定できます。

en: (bash, ksh, and zsh should also be POSIX compatible if you have any of those installed).
ja: (bash、ksh、または zsh のいずれかがインストールされている場合には、これも POSIX の互換性が必要です)。

en: Running on z/OS
ja: z/OS での実行

en: There are a few common errors that one might run into when trying to execute Ansible on z/OS as a target.
ja: z/OS でターゲットとして Ansible を実行しようとすると、複数の共通のエラーが発生する可能性があります。

en: Version 2.7.6 of python for z/OS will not work with Ansible because it represents strings internally as EBCDIC.
ja: z/OS 向けの Python バージョン 2.7.6 は、内部で文字列を EBCDIC として表現するため、Ansible では機能しない。

en: To get around this limitation, download and install a later version of `python for z/OS <https://www.rocketsoftware.com/zos-open-source>`_ (2.7.13 or 3.6.1) that represents strings internally as ASCII. Version 2.7.13 is verified to work.
ja: この制限を回避するには、文字列を ASCII で表現する `python for z/OS <https://www.rocketsoftware.com/zos-open-source>`_ (2.7.13 または 3.6.1) をダウンロードしてインストールしてください。バージョン 2.7.13 では機能することが確認されています。

en: When ``pipelining = False`` in `/usr/local/etc/ansible/ansible.cfg` then Ansible modules are transferred in binary mode via sftp however execution of python fails with
ja: `/usr/local/etc/ansible/ansible.cfg` で ``pipelining = False`` と指定されている場合、以下により、Ansible モジュールは Python の実行エラーが何であっても、sftp 経由でバイナリーモードで転送されます。

en: To fix it set ``pipelining = True`` in `/usr/local/etc/ansible/ansible.cfg`.
ja: これを修正するには、`/usr/local/etc/ansible/ansible.cfg` に ``pipelining = True`` を設定します。

en: Python interpret cannot be found in default location ``/usr/bin/python`` on target host.
ja: Python インタープリターがターゲットホストのデフォルトの場所 ``/usr/bin/python`` で検出できない。

en: To fix this set the path to the python installation in your inventory like so::
ja: これを解決するには、以下のようにインベントリーでパスを Python インストールに設定してください。

en: Start of python fails with ``The module libpython2.7.so was not found.``
ja: python の起動に失敗し、``The module libpython2.7.so was not found.`` が表示

en: On z/OS, you must execute python from gnu bash. If gnu bash is installed at ``/usr/lpp/bash``, you can fix this in your inventory by specifying an ``ansible_shell_executable``::
ja: z/OS では、gnu bash から python を実行する必要があります。gnu bash が ``/usr/lpp/bash`` にインストールされている場合は、インベントリーで ``ansible_shell_executable`` を指定して修正できます。

en: Running under fakeroot
ja: fakeroot 下で実行

en: Some issues arise as ``fakeroot`` does not create a full nor POSIX compliant system by default. It is known that it will not correctly expand the default tmp directory Ansible uses (:file:`~/.ansible/tmp`). If you see module failures, this is likely the problem. The simple workaround is to set ``remote_tmp`` to a path that will expand correctly (see documentation of the shell plugin you are using for specifics).
ja: ``fakeroot`` は、デフォルトでは完全なシステムも POSIX 準拠のシステムも作成しないため、いくつかの問題が発生します。Ansible が使用するデフォルトの tmp ディレクトリー (:file:`~/.ansible/tmp`) を正しく展開しないことがわかっています。モジュール障害が発生している場合は、これが問題である可能性があります。簡単な回避策は、正しく展開されるパスに ``remote_tmp`` を設定することです (詳細については、使用している shell プラグインのドキュメントを参照してください)。

en: For example, in the ansible config file (or via environment variable) you can set::
ja: 設定する ansible 設定ファイルで (または環境変数を介して)、以下を指定します。

en: What is the best way to make content reusable/redistributable?
ja: コンテンツを再利用/再配信できるようにする最適な方法にはどんなものがありますか

en: If you have not done so already, read all about "Roles" in the playbooks documentation. This helps you make playbook content self-contained, and works well with things like git submodules for sharing content with others.
ja: Playbook ドキュメントの「ロール」の情報をまだ読んでいない場合は、一読してください。Playbook のコンテンツを自己完結型にし、git submodules などと連携させて、他とのコンテンツ共有が容易になります。

en: If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended.
ja: このようなプラグインタイプの詳細は、Ansible の拡張方法に関する詳細を API ドキュメントで確認してください。

en: Where does the configuration file live and what can I configure in it?
ja: 設定ファイルの配置場所はどこですか。または、どのように設定すれば良いですか

en: See :ref:`intro_configuration`.
ja: 「:ref:`intro_configuration`」を参照してください。

en: How do I disable cowsay?
ja: cowsay はどのように無効化すれば良いですか

en: If cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks. If you decide that you would like to work in a professional cow-free environment, you can either uninstall cowsay, set ``nocows=1`` in ``ansible.cfg``, or set the :envvar:`ANSIBLE_NOCOWS` environment variable:
ja: cowsay がインストールされている場合は、Playbook を実行すると、Ansible がすべてを引き受けて処理します。プロフェッショナルな cowsay のない環境で作業する場合は、cowsay をアンインストールするか、``ansible.cfg`` に ``nocows=1`` を設定するか、:envvar:`ANSIBLE_NOCOWS` の環境変数を設定します。

en: How do I see a list of all of the ansible\_ variables?
ja: ansible\_ 変数一覧を確認するにはどうすれば良いですか

en: Ansible by default gathers "facts" about the machines under management, and these facts can be accessed in playbooks and in templates. To see a list of all of the facts that are available about a machine, you can run the ``setup`` module as an ad hoc action:
ja: Ansible はデフォルトで、管理対象のマシンの「ファクト」を収集し、このファクトには Playbook またはテンプレートでアクセスできます。あるマシンで利用可能なファクトの一覧を表示するには、``setup`` モジュールを ad-hoc アクションとして実行できます。

en: This will print out a dictionary of all of the facts that are available for that particular host. You might want to pipe the output to a pager.This does NOT include inventory variables or internal 'magic' variables. See the next question if you need more than just 'facts'.
ja: これにより、特定のホストで利用可能な全ファクトのディクショナリーが出力されます。ページャーの出力をパイプする場合は、インベントリー変数や内部の「magic」変数は含まれません。「ファクト」以外の情報が必要な場合は、次の質問を確認してください。

en: How do I see all the inventory variables defined for my host?
ja: ホストに定義されたインベントリー変数をすべて確認するにはどうすれば良いですか

en: By running the following command, you can see inventory variables for a host:
ja: 以下のコマンドを実行すると、ホストのインベントリー変数を確認できます。

en: How do I see all the variables specific to my host?
ja: ホスト固有の全変数を確認するにはどうすれば良いですか

en: To see all host specific variables, which might include facts and other sources:
ja: ホスト固有の変数をすべて確認するには以下を実行します (ファクトや他のソースが含まれる可能性があります)。

en: Unless you are using a fact cache, you normally need to use a play that gathers facts first, for facts included in the task above.
ja: ファクトキャッシュを使用していない限り、上記のタスクに含まれるファクトについては、通常、先にファクトを収集するプレイを使用する必要があります。

en: How do I loop over a list of hosts in a group, inside of a template?
ja: テンプレート内のグループに含まれるホストの一覧をループするにはどうすれば良いですか

en: A pretty common pattern is to iterate over a list of hosts inside of a host group, perhaps to populate a template configuration file with a list of servers. To do this, you can just access the "$groups" dictionary in your template, like this:
ja: 非常に一般的なパターンでは、ホストグループ内でホストのリストを反復処理することです。おそらく、テンプレート設定ファイルにサーバーの一覧を入力します。これを行うには、次のように、テンプレートで「$ groups」ディクショナリーにアクセスするだけです。

en: If you need to access facts about these hosts, for instance, the IP address of each hostname, you need to make sure that the facts have been populated. For example, make sure you have a play that talks to db_servers::
ja: このようなホストに関するファクト (各ホスト名の IP アドレスなど) にアクセスする必要がある場合には、ファクトが生成されていることを確認する必要があります。たとえば、db_servers と対話するプレイがあることを確認します::

en: Then you can use the facts inside your template, like this:
ja: 次に、以下のように、テンプレート内のファクトを使用できます。

en: How do I access a variable name programmatically?
ja: プログラムで変数名にアクセスするにはどうすれば良いですか

en: An example may come up where we need to get the ipv4 address of an arbitrary interface, where the interface to be used may be supplied via a role parameter or other input. Variable names can be built by adding strings together using "~", like so:
ja: たとえば、任意のインターフェースの ipv4 アドレスを取得する必要があるかもしれません。そこでは、使用されるインターフェースがロールパラメーターまたは他の入力を介して提供される場合があります。変数名は、次のように「~」を使用して文字列を一緒に追加することで作成できます。

en: The trick about going through hostvars is necessary because it's a dictionary of the entire namespace of variables. ``inventory_hostname`` is a magic variable that indicates the current host you are looping over in the host loop.
ja: それは、変数の名前空間全体のディクショナリーであるため、hostvars 全体をチェックするにはコツが必要です。``inventory_hostname`` はマジック変数で、ホストループでループを行う現在のホストを指定します。

en: In the example above, if your interface names have dashes, you must replace them with underscores:
ja: 上記の例では、インターフェース名にダッシュが含まれている場合は、アンダースコアに置き換える必要があります。

en: Also see dynamic_variables_.
ja: 「dynamic_variables_」も参照してください。

en: How do I access a group variable?
ja: グループ変数にアクセスするにはどうすれば良いですか

en: Technically, you don't, Ansible does not really use groups directly. Groups are labels for host selection and a way to bulk assign variables, they are not a first class entity, Ansible only cares about Hosts and Tasks.
ja: 技術的には、Ansible は実際にはグループを直接使用しません。グループはホスト選択のラベルであり、変数を一括で割り当てる手段を提供します。グループは第一級のエンティティーではなく、Ansible はホストとタスクのみを考慮します。

en: That said, you could just access the variable by selecting a host that is part of that group, see first_host_in_a_group_ below for an example.
ja: ただし、対象のグループに含まれるホストを選択すると、変数にアクセスできます。例については、以下の「first_host_in_a_group_」を参照してください。

en: How do I access a variable of the first host in a group?
ja: グループ内の最初のホストの変数にアクセスするにはどうすれば良いですか

en: What happens if we want the ip address of the first webserver in the webservers group?  Well, we can do that too. Note that if we are using dynamic inventory, which host is the 'first' may not be consistent, so you wouldn't want to do this unless your inventory is static and predictable. (If you are using :ref:`ansible_tower`, it will use database order, so this isn't a problem even if you are using cloud based inventory scripts).
ja: webservers グループの最初の webserver の IP アドレスが必要な場合にはどうすれば良いですか。私たちはそれも行うことができます。動的インベントリーを使用している場合は、どのホストが「最初」であるかが一貫していない可能性があるため、インベントリーが静的で予測可能でない限り、これを実行したくないことに注意してください (:ref:`ansible_tower` を使用している場合は、データベースの順序を使用するため、クラウドベースのインベントリースクリプトを使用している場合でも、これは問題になりません)。

en: Anyway, here's the trick:
ja: 以下に方法を示します。

en: Notice how we're pulling out the hostname of the first machine of the webservers group. If you are doing this in a template, you could use the Jinja2 '#set' directive to simplify this, or in a playbook, you could also use set_fact::
ja: webserver グループの最初のマシンのホスト名を取得している点に注意してください。テンプレートでこれを実行する場合は、Jinja2 '#set' ディレクティブを使用して簡素化するか、Playbook の場合は set_fact を使用することも可能です。

en: Notice how we interchanged the bracket syntax for dots -- that can be done anywhere.
ja: ドットの代わりに括弧の構文を使用している点に注意してください。これはどこでも使用できます。

en: How do I copy files recursively onto a target host?
ja: ターゲットホストにファイルを再帰的にコピーするにはどうすれば良いですか

en: The ``copy`` module has a recursive parameter. However, take a look at the ``synchronize`` module if you want to do something more efficient for a large number of files. The ``synchronize`` module wraps rsync. See the module index for info on both of these modules.
ja: ``copy`` モジュールには再帰的なパラメーターがありますが、多数のファイルにより効率的な場合は、``synchronize`` モジュールを参照してください。``synchronize`` モジュールは rsync をラップします。これらの両方のモジュールの情報は、モジュールインデックスを参照してください。

en: How do I access shell environment variables?
ja: shell 環境変数にアクセスするにはどうすれば良いですか

en: **On controller machine :** Access existing variables from controller use the ``env`` lookup plugin. For example, to access the value of the HOME environment variable on the management machine::
ja: **コントローラーマシンの場合:** コントローラーから既存の変数にアクセスするには、``env`` lookup プラグインを使用します。たとえば、管理マシンで HOME 環境変数の値にアクセスするには、以下を指定します。

en: **On target machines :** Environment variables are available via facts in the ``ansible_env`` variable:
ja: **ターゲットマシン:** 環境変数の場合には、``ansible_env`` 変数のファクトを使用して入手します。

en: If you need to set environment variables for TASK execution, see :ref:`playbooks_environment` in the :ref:`Advanced Playbooks <playbooks_special_topics>` section. There are several ways to set environment variables on your target machines. You can use the :ref:`template <template_module>`, :ref:`replace <replace_module>`, or :ref:`lineinfile <lineinfile_module>` modules to introduce environment variables into files.  The exact files to edit vary depending on your OS and distribution and local configuration.
ja: タスクを実行するために環境変数を設定する必要がある場合は、:ref:`詳細な Playbook <playbooks_special_topics>` セクションの「:ref:`playbooks_environment`」を参照してください。ターゲットマシンで環境変数を設定するには、いくつかの方法があります。:ref:`template <template_module>` モジュール、:ref:`replace <replace_module>` モジュール、または :ref:`lineinfile <lineinfile_module>` モジュールを使用して、環境変数をファイルに取り込むことができます。編集するファイルは、OS、ディストリビューション、およびローカル設定によって異なります。

en: How do I generate encrypted passwords for the user module?
ja: ユーザーモジュールの暗号化パスワードを生成するにはどうすれば良いですか

en: Ansible ad hoc command is the easiest option:
ja: Ansible ad-hoc コマンドを使用するのが最も簡単なオプションです。

en: The ``mkpasswd`` utility that is available on most Linux systems is also a great option:
ja: ほとんどの Linux システムで利用できる ``mkpasswd`` ユーティリティーも優れたオプションです。

en: If this utility is not installed on your system (for example, you are using macOS) then you can still easily generate these passwords using Python. First, ensure that the `Passlib <https://foss.heptapod.net/python-libs/passlib/-/wikis/home>`_ password hashing library is installed:
ja: お使いのシステムにこのユーティリティーがインストールされていない場合 (例: MacOS を使用している場合など) には、Python を使用してこのようなパスワードを簡単に生成できます。まず、`Passlib <https://foss.heptapod.net/python-libs/passlib/-/wikis/home>`_ パスワードハッシュライブラリーがインストールされていることを確認します。

en: Once the library is ready, SHA512 password values can then be generated as follows:
ja: ライブラリーの準備ができたら、以下のように SHA512 パスワードの値を生成できます。

en: Use the integrated :ref:`hash_filters` to generate a hashed version of a password. You shouldn't put plaintext passwords in your playbook or host_vars; instead, use :ref:`playbooks_vault` to encrypt sensitive data.
ja: 統合された :ref:`hash_filters` を使用して、ハッシュ化されたパスワードを生成します。Playbook や host_vars にプレーンテキストのパスワードは使用しないでください。代わりに、:ref:`playbooks_vault` を使用して、機密データを暗号化してください。

en: In OpenBSD, a similar option is available in the base system called ``encrypt (1)``
ja: OpenBSDでは、``encrypt (1)`` と呼ばれるベースシステムで同様のオプションが利用可能です。

en: Ansible allows dot notation and array notation for variables. Which notation should I use?
ja: Ansible では、変数のドット表記とアレイ表記が可能です。どの表記を使用する必要がありますか。

en: The dot notation comes from Jinja and works fine for variables without special characters. If your variable contains dots (.), colons (:), or dashes (-), if a key begins and ends with two underscores, or if a key uses any of the known public attributes, it is safer to use the array notation. See :ref:`playbooks_variables` for a list of the known public attributes.
ja: ドット表記は Jinja からのもので、特殊文字なしに変数と合わせて使用できます。変数にドット (.)、コロン (:)、またはハイフン (-) が含まれていて、キーが 2 つのアンダースコアで開始および終了する場合、またはキーが既知のパブリック属性のいずれかを使用する場合は、配列表記を使用する方が安全です。既知のパブリック属性の一覧は、「:ref:`playbooks_variables`」を参照してください。

en: Also array notation allows for dynamic variable composition, see dynamic_variables_.
ja: また、アレイ表記は、動的な変数の構成が可能です。詳細は、「dynamic_variables_」を参照してください。

en: Another problem with 'dot notation' is that some keys can cause problems because they collide with attributes and methods of python dictionaries.
ja: 「ドット表記」の他の問題として、ドット表記のキーによっては、Python ディクショナリーの属性とメソッドと競合するため、問題が発生する可能性があります。

en: When is it unsafe to bulk-set task arguments from a variable?
ja: 変数からタスク引数の一括設定をすると安全でないのはどのような場合ですか

en: You can set all of a task's arguments from a dictionary-typed variable. This technique can be useful in some dynamic execution scenarios. However, it introduces a security risk. We do not recommend it, so Ansible issues a warning when you do something like this::
ja: ディクショナリー型の変数からタスクの引数をすべて設定することができます。この手法は、動的な実行シナリオで便利な場合があります。ただし、セキュリティーリスクがあります。これは推奨されないため、このような操作を行うと、Ansible では警告を発行します。

en: This particular example is safe. However, constructing tasks like this is risky because the parameters and values passed to ``usermod_args`` could be overwritten by malicious values in the ``host facts`` on a compromised target machine. To mitigate this risk:
ja: この特定の例は、安全です。ただし、``usermod_args`` に渡されるパラメーターや値が、セキュリティー侵害を受けたターゲットマシンの ``host facts`` に含まれる悪意のある値で置き換えられる可能性があるため、このようなタスクの構築にはリスクがあります。このリスクを軽減するには、以下を行います。

en: set bulk variables at a level of precedence greater than ``host facts`` in the order of precedence found in :ref:`ansible_variable_precedence` (the example above is safe because play vars take precedence over facts)
ja: :ref:`ansible_variable_precedence` にある優先順位で、``host facts`` より優先順位の高いレベルで一括変数を設定します (プレイ変数はファクトより優先度が高いため、上記の例は安全です)。

en: disable the :ref:`inject_facts_as_vars` configuration setting to prevent fact values from colliding with variables (this will also disable the original warning)
ja: ファクトの値が変数と競合しないように :ref:`inject_facts_as_vars` 設定オプションを無効にします (元の警告も無効になります)。

en: Can I get training on Ansible?
ja: Ansible のトレーニングはありますか

en: Yes! See our `services page <https://www.ansible.com/products/consulting>`_ for information on our services and training offerings. Email `info@ansible.com <mailto:info@ansible.com>`_ for further details.
ja: サービスおよびトレーニングサービスに関する情報は、「`サービスページ <https://www.ansible.com/products/consulting>`」を参照してください。詳細は、`info@ansible.com <mailto:info@ansible.com>`_ にお問い合わせください。

en: We also offer free web-based training classes on a regular basis. See our `webinar page <https://www.ansible.com/resources/webinars-training>`_ for more info on upcoming webinars.
ja: また、定期的に、Web ベースのトレーニングも無料で提供しています。今後予定されているウェビナーの詳細は、`ウェビナーページ <https://www.ansible.com/resources/webinars-training>`_ を参照してください。

en: Is there a web interface / REST API / GUI?
ja: Web インターフェース、REST API、GUI などがありますか。

en: Yes! Ansible, Inc makes a great product that makes Ansible even more powerful and easy to use. See :ref:`ansible_tower`.
ja: Ansible, Inc は、Ansible がより強力で使いやすくなるように、優れた製品を提供しています。「:ref:`ansible_tower`」を参照してください。

en: How do I keep secret data in my playbook?
ja: Playbook に機密データを保存するにはどうすれば良いですか

en: If you would like to keep secret data in your Ansible content and still share it publicly or keep things in source control, see :ref:`playbooks_vault`.
ja: Ansible のコンテンツに機密データを保存してそのコンテンツを公開するか、ソースコントロールに保持する場合は、「:ref:`playbooks_vault`」を参照してください。

en: If you have a task that you don't want to show the results or command given to it when using -v (verbose) mode, the following task or playbook attribute can be useful::
ja: -v (詳細) モードの使用時に、結果や指定したコマンドを表示したくないタスクがある場合は、次のようなタスクや Playbook 属性が便利です。

en: This can be used to keep verbose output but hide sensitive information from others who would otherwise like to be able to see the output.
ja: これは、詳細な出力を維持しつつ、出力を見たいと思っている人から機密情報を隠すために使うことができます。

en: The ``no_log`` attribute can also apply to an entire play::
ja: ``no_log`` 属性は、プレイ全体にも適用できます。

en: Though this will make the play somewhat difficult to debug. It's recommended that this be applied to single tasks only, once a playbook is completed. Note that the use of the ``no_log`` attribute does not prevent data from being shown when debugging Ansible itself via the :envvar:`ANSIBLE_DEBUG` environment variable.
ja: ただし、これを使用すると、プレイのデバッグが困難になります。Playbook が完了すると、この属性は単一のタスクにのみ適用することが推奨されます。``no_log`` 属性を使用しても、:envvar:`ANSIBLE_DEBUG` 環境変数で Ansible 自体をデバッグするときに、データが表示されてしまう点に注意してください。

en: When should I use {{ }}? Also, how to interpolate variables or dynamic variable names
ja: {{ }} はいつ使用する必要がありますか。また、変数または動的な変数名を補間するにはどうすれば良いですか

en: A steadfast rule is 'always use ``{{ }}`` except when ``when:``'. Conditionals are always run through Jinja2 as to resolve the expression, so ``when:``, ``failed_when:`` and ``changed_when:`` are always templated and you should avoid adding ``{{ }}``.
ja: 不動のルールは「``when:`` の場合を除いて常に ``{{ }}`` を使用する」です。この条件は、式の解決として Jinja2 を介して実行するため、``when:``、``failed_when:``、および ``changed_when:`` は常にテンプレート化され、``{{ }}`` の追加は回避してください。

en: In most other cases you should always use the brackets, even if previously you could use variables without specifying (like ``loop`` or ``with_`` clauses), as this made it hard to distinguish between an undefined variable and a string.
ja: それ以外のケースでは、以前は ``loop`` 句または ``with_`` 句などを指定しなくても変数を使用できていた場合でも、常に括弧を使用するようにしてください。理由は、未定義の変数と文字列を区別しにくいためです。

en: Another rule is 'moustaches don't stack'. We often see this:
ja: 他には「波括弧は並べて使用できない」というルールがありますが、これは頻繁に見受けられます。

en: The above DOES NOT WORK as you expect, if you need to use a dynamic variable use the following as appropriate:
ja: 上記の例は想定通り、機能しません。動的変数を使用する必要がある場合には、随時、以下を使用してください。

en: For 'non host vars' you can use the :ref:`vars lookup<vars_lookup>` plugin:
ja: 「non host vars」の場合には、:ref:`vars lookup<vars_lookup>` プラグインを使用できます。

en: Why don't you ship ansible in wheel format (or other packaging format) ?
ja: wheel 形式 (またはその他のパッケージ形式) で ansible が同梱されないのはなぜですか。

en: In most cases it has to do with maintainability. There are many ways to ship software and we do not have the resources to release Ansible on every platform. In some cases there are technical issues. For example, our dependencies are not present on Python Wheels.
ja: 多くの場合に、メンテナンスができるかどうかに関係します。ソフトウェアを提供する方法は多数あり、全プラットフォームで Ansible をリリースするリソースがありません。場合によっては、技術的な問題があります。たとえば、Python Wheel には依存関係がありません。

en: How do I get the original ansible_host when I delegate a task?
ja: タスクを委譲した場合に元の ansible_host をどのように取得すれば良いですか

en: As the documentation states, connection variables are taken from the ``delegate_to`` host so ``ansible_host`` is overwritten, but you can still access the original via ``hostvars``::
ja: ドキュメントに記載されているように、接続変数は ``delegate_to`` ホストから取得されるため、``ansible_host`` は上書きされますが、``hostvars`` を使用して元の ansible_host にアクセスできます。

en: This works for all overridden connection variables, like ``ansible_user``, ``ansible_port``, and so on.
ja: これは、``ansible_user``、``ansible_port`` などのように、すべての上書きされた接続変数に有効です。

en: How do I fix 'protocol error: filename does not match request' when fetching a file?
ja: ファイルの取得時の「protocol error: filename does not match request」のエラーはどのように修正すれば良いですか

en: Since release ``7.9p1`` of OpenSSH there is a `bug <https://bugzilla.mindrot.org/show_bug.cgi?id=2966>`_ in the SCP client that can trigger this error on the Ansible controller when using SCP as the file transfer mechanism::
ja: OpenSSH のリリース ``7.9p1`` では、SCP クライアントに `bug <https://bugzilla.mindrot.org/show_bug.cgi?id=2966>`_ があり、ファイル転送メカニズムとして SCP を使用する場合に、Ansible コントローラーで以下のエラーが出力される可能性があります。

en: In these releases, SCP tries to validate that the path of the file to fetch matches the requested path. The validation fails if the remote filename requires quotes to escape spaces or non-ascii characters in its path. To avoid this error:
ja: 新しいリリースでは、SCP は、取得するファイルのパスが要求したパスと一致することを検証しようとします。リモートのファイル名が、パスでスペースや ASCII 文字以外の文字を引用符でエスケープする必要がある場合には、検証に失敗します。このエラーを回避するには、以下を行います。

en: Use SFTP instead of SCP by setting ``scp_if_ssh`` to ``smart`` (which tries SFTP first) or to ``False``. You can do this in one of four ways:
ja: ``scp_if_ssh`` を ``smart`` (先に SFTP を試す)、または ``False`` に設定して、SCP の代わりに SFTP を使用します。

en: Rely on the default setting, which is ``smart`` - this works if ``scp_if_ssh`` is not explicitly set anywhere
ja: ``smart`` のデフォルトの設定に依存します。``scp_if_ssh`` が明示的にどこにも設定されていない場合に機能します。

en: Set a :ref:`host variable <host_variables>` or :ref:`group variable <group_variables>` in inventory: ``ansible_scp_if_ssh: False``
ja: インベントリーに :ref:`ホスト変数 <host_variables>` または :ref:`グループ変数 <group_variables>` を設定します (``ansible_scp_if_ssh: False``)。

en: Set an environment variable on your control node: ``export ANSIBLE_SCP_IF_SSH=False``
ja: コントロールノードで環境変数を設定します (``export ANSIBLE_SCP_IF_SSH=False``)。

en: Pass an environment variable when you run Ansible: ``ANSIBLE_SCP_IF_SSH=smart ansible-playbook``
ja: Ansible を実行するときに環境変数を渡します (``ANSIBLE_SCP_IF_SSH=smart ansible-playbook``)。

en: Modify your ``ansible.cfg`` file: add ``scp_if_ssh=False`` to the ``[ssh_connection]`` section
ja: ``ansible.cfg`` ファイルの変更: ``scp_if_ssh=False`` を ``[ssh_connection]`` セクションに追加します。

en: If you must use SCP, set the ``-T`` arg to tell the SCP client to ignore path validation. You can do this in one of three ways:
ja: SCP を使用する必要がある場合は、``-T`` 引数を設定して、SCP クライアントにパスの検証を無視するように指示します。以下の 3 つの方法のいずれかで実行できます。

en: Set a :ref:`host variable <host_variables>` or :ref:`group variable <group_variables>`: ``ansible_scp_extra_args=-T``,
ja: :ref:`ホスト変数 <host_variables>` または :ref:`グループ変数 <group_variables>` を設定します (``ansible_scp_extra_args=-T``)。

en: Export or pass an environment variable: ``ANSIBLE_SCP_EXTRA_ARGS=-T``
ja: 環境変数をエクスポートするか、渡します (``ANSIBLE_SCP_EXTRA_ARGS=-T``)。

en: Modify your ``ansible.cfg`` file: add ``scp_extra_args=-T`` to the ``[ssh_connection]`` section
ja: ``ansible.cfg`` ファイルの変更: ``scp_extra_args=-T`` を ``[ssh_connection]`` セクションに追加します。

en: If you see an ``invalid argument`` error when using ``-T``, then your SCP client is not performing filename validation and will not trigger this error.
ja: ``-T`` の使用時に ``invalid argument`` エラーが表示される場合は、SCP クライアントがファイル名を検証しておらず、このエラーは発生しません。

en: Does Ansible support multiple factor authentication 2FA/MFA/biometrics/finterprint/usbkey/OTP/...
ja: Ansible では、複数のファクター認証 2FA/MFA/biometrics/finterprint/usbkey/OTP/... がサポートされます。

en: No, Ansible is designed to execute multiple tasks against multiple targets, minimizing user interaction. As with most automation tools, it is not compatible with interactive security systems designed to handle human interaction. Most of these systems require a secondary prompt per target, which prevents scaling to thousands of targets.  They also tend to have very short expiration periods so it requires frequent reauthorization, also an issue with many hosts and/or a long set of tasks.
ja: いいえ、Ansible は複数のターゲットに対して複数のタスクを実行するように設計されており、ユーザーの操作を最小限に抑えることができます。ほとんどの自動化ツールと同様に、人間の相互作用を処理するように設計されたインタラクティブなセキュリティーシステムとの互換性はありません。これらのシステムのほとんどは、ターゲットごとにセカンダリープロンプトを必要とするため、数千のターゲットに拡張することができません。また、これらのシステムは有効期限が非常に短いため、再認証が頻繁に必要となりますが、これも多くのホストや長いタスクセットでは問題となります。

en: In such environments we recommend securing around Ansible's execution but still allowing it to use an 'automation user' that does not require such measures. This is something that Tower/AWX excels at by allowing administrators to set up RBAC access to inventory, along with managing credentials and job execution.
ja: このような環境では、Ansible の実行を保護しながら、そのような手段を必要としない「自動化ユーザー」の使用を許可することが推奨されます。これが Tower/AWX の優れている点で、管理者がインベントリーへの RBAC アクセスを設定し、認証情報とジョブの実行を管理することができます。

en: How do I submit a change to the documentation?
ja: ドキュメントへの変更を提出するにはどうすれば良いですか

en: Documentation for Ansible is kept in the main project git repository, and complete instructions for contributing can be found in the docs README `viewable on GitHub <https://github.com/ansible/ansible/blob/devel/docs/docsite/README.md>`_. Thanks!
ja: Ansible のドキュメントは、主要プロジェクトの git リポジトリーに保存されており、貢献に関する説明が `GitHub で確認できる <https://github.com/ansible/ansible/blob/devel/docs/docsite/README.md>`_ README に記載されています。

en: I don't see my question here
ja: ここに記載されている以外に質問があります

en: Please see the section below for a link to IRC and the Google Group, where you can ask your question there.
ja: 以下のセクションに、IRC および Google グループへのリンクがあります。こちらから、質問をしてください。

en: An introduction to playbooks
ja: Playbook の概要

en: Tips and tricks for playbooks
ja: Playbook のヒントと裏技

en: `User Mailing List <https://groups.google.com/group/ansible-project>`_
ja: `メーリングリストの使用 <https://groups.google.com/group/ansible-project>`_

en: Have a question?  Stop by the google group!
ja: ご質問はございますか。Google Group をご覧ください。

en: Controlling how Ansible behaves: precedence rules
ja: Ansible の動作の制御: 優先順位のルール

en: To give you maximum flexibility in managing your environments, Ansible offers many ways to control how Ansible behaves: how it connects to managed nodes, how it works once it has connected. If you use Ansible to manage a large number of servers, network devices, and cloud resources, you may define Ansible behavior in several different places and pass that information to Ansible in several different ways. This flexibility is convenient, but it can backfire if you do not understand the precedence rules.
ja: Ansible には、環境の管理に最大限の柔軟性をもたせられるように、管理対象ノードへの接続方法や、接続後の動作など、Ansible の動作を制御する手段が多数あります。Ansible を使用して多数のサーバー、ネットワークデバイス、クラウドリソースを管理する場合に、Ansible の動作をさまざまな場所で定義して、さまざまな方法で Ansible にその情報を渡すことができます。柔軟性があると便利ですが、優先順位ルールを理解していない場合は、逆効果となる可能性があります。

en: These precedence rules apply to any setting that can be defined in multiple ways (by configuration settings, command-line options, playbook keywords, variables).
ja: このような優先順位ルールは、複数の方法で定義できるオプション (設定オプション、コマンドラインオプション、Playbook キーワード、変数) に適用されます。

en: Precedence categories
ja: 優先順位のカテゴリー

en: Ansible offers four sources for controlling its behavior. In order of precedence from lowest (most easily overridden) to highest (overrides all others), the categories are:
ja: Ansible では、動作の制御に使用するソースが 4 つあります。カテゴリーは以下のとおりです (優先順位の低いもの、つまり最も簡単にオーバーライドされるものから、高いもの、つまり他のすべてをオーバーライドするものに並べています)。

en: Configuration settings
ja: 設定オプション

en: Command-line options
ja: コマンドラインオプション

en: Playbook keywords
ja: Playbook キーワード

en: Each category overrides any information from all lower-precedence categories. For example, a playbook keyword will override any configuration setting.
ja: 各カテゴリーは、そのカテゴリーよりも優先順位の低いカテゴリーからの情報をすべてオーバーライドします。たとえば、Playbook キーワードは、設定オプションをオーバーライドします。

en: Within each precedence category, specific rules apply. However, generally speaking, 'last defined' wins and overrides any previous definitions.
ja: 各優先順位カテゴリーで、固有のルールが適用されます。ただし、一般的に「最後に定義 (last defined)」した内容の優先度が高く、以前の定義をオーバーライドします。

en: :ref:`Configuration settings<ansible_configuration_settings>` include both values from the ``ansible.cfg`` file and environment variables. Within this category, values set in configuration files have lower precedence. Ansible uses the first ``ansible.cfg`` file it finds, ignoring all others. Ansible searches for ``ansible.cfg`` in these locations in order:
ja: :ref:`構成設定<ansible_configuration_settings>` には、``ansible.cfg`` ファイルと環境変数からの両方の値が含まれます。このカテゴリーでは、設定ファイルに指定した値のほうが優先順位が低くなります。Ansible では最初に見つかった ``ansible.cfg`` を使用し、他はすべて無視します。Ansible は、これらの場所で順番に ``ansible.cfg`` を選択します。

en: Environment variables have a higher precedence than entries in ``ansible.cfg``. If you have environment variables set on your control node, they override the settings in whichever ``ansible.cfg`` file Ansible loads. The value of any given environment variable follows normal shell precedence: the last value defined overwrites previous values.
ja: 環境変数は、``ansible.cfg`` のエントリーよりも優先されます。コントロールノードに環境変数を設定している場合には、Ansible が読み込む ``ansible.cfg`` ファイルの設定よりも、環境変数が優先されます。指定された環境変数の値は、shell の通常の優先順位 (最後に定義した値が、それ以前の値をオーバーライド) に準拠します。

en: Any command-line option will override any configuration setting.
ja: コマンドラインオプションは、設定オプションをすべてオーバーライドします。

en: When you type something directly at the command line, you may feel that your hand-crafted values should override all others, but Ansible does not work that way. Command-line options have low precedence - they override configuration only. They do not override playbook keywords, variables from inventory or variables from playbooks.
ja: コマンドラインに直接入力すると、手動で入力した値が、それ以外の設定をすべてオーバーライドするように感じますが、Ansible の仕様は異なります。コマンドラインオプションの優先順位は低いため、オーバーライドできるのは、設定のみです。Playbook のキーワードや、インベントリーからの変数、または Playbook から変数をオーバーライドすることはありません。

en: You can override all other settings from all other sources in all other precedence categories at the command line by  :ref:`general_precedence_extra_vars`, but that is not a command-line option, it is a way of passing a :ref:`variable<general_precedence_variables>`.
ja: :ref:`general_precedence_extra_vars` により、コマンドラインで、他の優先順位カテゴリーの他のソースからの他の設定をすべて上書きできます。ただし、これはコマンドラインオプションではなく、:ref:`variable<general_precedence_variables>` を渡す手段としてコマンドラインを使用しています。

en: At the command line, if you pass multiple values for a parameter that accepts only a single value, the last defined value wins. For example, this :ref:`ad hoc task<intro_adhoc>` will connect as ``carol``, not as ``mike``::
ja: コマンドラインで、単値のみを受け入れるパラメーターに多値を渡すと、最後に定義された値が優先されます。たとえば、この :ref:`ad hoc task<intro_adhoc>` は、``mike`` ではなく、``carol`` として接続します。

en: Some parameters allow multiple values. In this case, Ansible will append all values from the hosts listed in inventory files inventory1 and inventory2::
ja: パラメーターによっては、多値を使用できます。以下の場合には、Ansible は、インベントリーファイル「inventory1」および「inventory2」に記載されているホストからの値をすべて追加します。

en: The help for each :ref:`command-line tool<command_line_tools>` lists available options for that tool.
ja: 各 :ref:`コマンドラインツール<command_line_tools>` のヘルプは、対象のツールで利用可能なオプションを表示します。

en: Any :ref:`playbook keyword<playbook_keywords>` will override any command-line option and any configuration setting.
ja: :ref:`Playbook キーワード<playbook_keywords>` は、コマンドラインオプションと、構成設定をすべてオーバーライドします。

en: Within playbook keywords, precedence flows with the playbook itself; the more specific wins against the more general:
ja: Playbook キーワード内の優先順位は、Playbook の内容により左右されます (一般的な設定より具体的な設定が優先されます)。

en: play (most general)
ja: プレイ (最も一般的)

en: blocks/includes/imports/roles (optional and can contain tasks and each other)
ja: blocks/includes/imports/roles (任意で、タスクを含めることも、相互に含めることも可能)

en: tasks (most specific)
ja: タスク (最も具体的)

en: A simple example::
ja: 簡単な例::

en: In this example, the ``connection`` keyword is set to ``ssh`` at the play level. The first task inherits that value, and connects using ``ssh``. The second task inherits that value, overrides it, and connects using ``paramiko``. The same logic applies to blocks and roles as well. All tasks, blocks, and roles within a play inherit play-level keywords; any task, block, or role can override any keyword by defining a different value for that keyword within the task, block, or role.
ja: この例では、``connection`` キーワードはプレイレベルで ``ssh`` に設定されています。最初のタスクはその値を継承し、``ssh`` を使用して接続します。2 番目のタスクは、その値を継承してオーバーライドし、``paramiko`` を使用して接続します。block や role でも同じロジックが適用されます。プレイ内の task、block、role はすべて、プレイレベルのキーワードを継承します。キーワードより task または block、role を優先させるには、task、block、role 内の対象のキーワードに異なる値を定義します。

en: Remember that these are KEYWORDS, not variables. Both playbooks and variable files are defined in YAML but they have different significance. Playbooks are the command or 'state description' structure for Ansible, variables are data we use to help make playbooks more dynamic.
ja: 上記は、変数ではなく、キーワードである点に注意してください。Playbook や変数ファイルはいずれも YAML で定義しますが、それぞれ重要性が異なります。Playbook はコマンドまたは Ansible の「状態記述」構造で、変数は Playbook をより動的に使用できるようにするためのデータです。

en: Any variable will override any playbook keyword, any command-line option, and any configuration setting.
ja: 変数は、Playbook のキーワード、コマンドラインオプション、構成設定をすべてオーバーライドします。

en: Variables that have equivalent playbook keywords, command-line options, and configuration settings are known as :ref:`connection_variables`. Originally designed for connection parameters, this category has expanded to include other core variables like the temporary directory and the python interpreter.
ja: 同等の Playbook キーワード、コマンドラインオプション、および構成設定を含む変数は :ref:`connection_variables` と呼ばれています。このカテゴリーは、当初は設定パラメーター向けに設計されてましたが、一時ディレクトリーや Python インタープリターなど、他のコア変数を含めるように拡張されました。

en: Connection variables, like all variables, can be set in multiple ways and places. You can define variables for hosts and groups in :ref:`inventory<intro_inventory>`. You can define variables for tasks and plays in ``vars:`` blocks in :ref:`playbooks<about_playbooks>`. However, they are still variables - they are data, not keywords or configuration settings. Variables that override playbook keywords, command-line options, and configuration settings follow the same rules of :ref:`variable precedence <ansible_variable_precedence>` as any other variables.
ja: 接続変数はすべての変数と同様、複数の手法や場所で設定できます。:ref:`インベントリー<intro_inventory>` でホストとグループの変数を定義できます。:ref:`Playbook<about_playbooks>` の ``vars:`` ブロックに、タスクとプレイの変数を定義できます。ただし、上記は、キーワードや構成設定ではなく、データを格納する変数です。Playbook キーワード、コマンドラインオプション、および設定オプションをオーバーライドする変数は、他の変数が使用する :ref:`変数の優先順位 <ansible_variable_precedence>` と同じルールに従います。

en: When set in a playbook, variables follow the same inheritance rules as playbook keywords. You can set a value for the play, then override it in a task, block, or role::
ja: 変数は、Playbook に設定されると、Playbook キーワードと同じ継承ルールに従います。プレイの値を設定すると、タスク、ブロック、またはロールの値をオーバーライドできます。

en: Variable scope: how long is a value available?
ja: 変数の範囲: 値が有効な期間

en: Variable values set in a playbook exist only within the playbook object that defines them. These 'playbook object scope' variables are not available to subsequent objects, including other plays.
ja: Playbook に設定した変数の値は、その値を定義する Playbook オブジェクト内にのみ存在します。このような「Playbook オブジェクトの範囲」の変数は、他のプレイなど、後続のオブジェクトでは利用できません。

en: Variable values associated directly with a host or group, including variables defined in inventory, by vars plugins, or using modules like :ref:`set_fact<set_fact_module>` and :ref:`include_vars<include_vars_module>`, are available to all plays. These 'host scope' variables are also available via the ``hostvars[]`` dictionary.
ja: インベントリー、vars プラグイン、:ref:`set_fact<set_fact_module>` や :ref:`include_vars<include_vars_module>` といったモジュールの使用など、ホストやグループに直接関連付けられた変数値は、全プレイで利用できます。また、これらの「ホスト範囲」変数は、``hostvars[]`` ディクショナリーから利用できます。

en: Using ``-e`` extra variables at the command line
ja: コマンドラインでの追加変数 (``-e``) の使用

en: To override all other settings in all other categories, you can use extra variables: ``--extra-vars`` or ``-e`` at the command line. Values passed with ``-e`` are variables, not command-line options, and they will override configuration settings, command-line options, and playbook keywords as well as variables set elsewhere. For example, this task will connect as ``brian`` not as ``carol``::
ja: 他のカテゴリーの全設定をオーバーライドするには、コマンドラインで追加変数 (``--extra-vars`` または ``-e``) を使用します。``-e`` で渡される値は、コマンドラインオプションではなく変数で、他で設定した変数をはじめ、構成設定、コマンドラインオプション、Playbook キーワードをオーバーライドします。たとえば、このタスクは、``carol`` ではなく ``brian`` として接続します。

en: You must specify both the variable name and the value with ``--extra-vars``.
ja: 変数名と値は、``--extra-vars`` で指定する必要があります。

en: Glossary
ja: 用語集

en: The following is a list (and re-explanation) of term definitions used elsewhere in the Ansible documentation.
ja: 以下は、Ansible ドキュメントの各所で使用される用語の定義 (と再説) 一覧です。

en: Consult the documentation home page for the full documentation and to see the terms in context, but this should be a good resource to check your knowledge of Ansible's components and understand how they fit together.  It's something you might wish to read for review or when a term comes up on the mailing list.
ja: 全ドキュメント、および文中で用語を確認するには、ドキュメントのホームページを参照してください。このページは、Ansible のコンポーネントの説明を読み、どのように組み合わされているかを理解するのに適しています。レビューのために、またはメーリングリストで用語が使用された時などにご利用になれます。

en: Action
ja: アクション

en: An action is a part of a task that specifies which of the modules to run and which arguments to pass to that module.  Each task can have only one action, but it may also have other parameters.
ja: アクションはタスクの一部を指し、実行するモジュールや、そのモジュールが渡す引数を指定します。各タスクには、アクションを 1 つだけ指定できますが、他に複数のパラメーターが指定されている可能性があります。

en: Ad Hoc
ja: アドホック

en: Refers to running Ansible to perform some quick command, using :command:`/usr/bin/ansible`, rather than the :term:`orchestration` language, which is :command:`/usr/bin/ansible-playbook`.  An example of an ad hoc command might be rebooting 50 machines in your infrastructure.  Anything you can do ad hoc can be accomplished by writing a :term:`playbook <playbooks>` and playbooks can also glue lots of other operations together.
ja: Ansible を実行して、:command:`/usr/bin/ansible-playbook` の :term:`オーケストレーション` 言語ではなく、:command:`/usr/bin/ansible` を使用してクイックコマンドを実行することを指します。アドホックコマンドの例には、インフラストラクチャー内での 50 台のマシンを再起動することなどが含まれます。アドホックに実行できるすべてのことは :term:`playbook <playbooks>` を作成して実行でき、Playbook は数多くの他の操作を 1 つにまとめることができます。

en: Ansible (the package)
ja: Ansible (パッケージ)

en: A software package (Python, deb, rpm, and so on) that contains ansible-core and a select group of collections. Playbooks that worked with Ansible 2.9 should still work with the Ansible 2.10 package. See the :file:`ansible-<version>.build` file in the release-specific directory at  `ansible-build-data <https://github.com/ansible-community/ansible-build-data>`_ for a list of collections included in Ansible, as well as the included ``ansible-core`` version.
ja: ansible-core および選択したコレクショングループを含むソフトウェアパッケージ (Python、deb、rpm など)。Ansible 2.9 で動作した Playbook は、Ansible 2.10 パッケージでも動作するはずです。Ansible に含まれているコレクションのリストと同梱されている ``ansible-core`` バージョンについては、`ansible-build-data <https://github.com/ansible-community/ansible-build-data>`_ のリリース固有のディレクトリーにある :file:`ansible-<version>.build` ファイルを参照してください。

en: Used only for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository <https://github.com/ansible/ansible>`_. See ``ansible-core``.
ja: 2.10 でのみ使用されます。`ansible/ansible リポジトリー <https://github.com/ansible/ansible>`_ から生成されたインストール可能なパッケージ (RPM/Python/Deb パッケージ) です。「``ansible-core``」を参照してください。

en: Name used starting with 2.11. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository <https://github.com/ansible/ansible>`_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-core`` package includes a few modules and plugins and allows you to add others by installing collections.
ja: 2.11 以降で使用される名前。`ansible/ansible リポジトリー <https://github.com/ansible/ansible>`_ から生成されるインストール可能なパッケージ (RPM/Python/Deb パッケージ)。コマンドラインツールと、基本的な機能および関数 (モジュールコードの管理対象ノードへのコピーなど) のコードが含まれています。``ansible-core`` パッケージにはいくつかのモジュールとプラグインが含まれており、コレクションをインストールすることで他のモジュールを追加できます。

en: An `online resource <galaxy.ansible.com>`_ for finding and sharing Ansible community content. Also, the command-line utility that lets users install individual Ansible Collections, for example`` ansible-galaxy install community.crypto``.
ja: Ansible コミュニティーのコンテンツを見つけて共有するための `オンラインリソース <galaxy.ansible.com>`_。また、ユーザーが個々の Ansible コレクションをインストールできるようにするコマンドラインユーティリティー (`` ansible-galaxy install community.crypto`` など)。

en: Async
ja: 非同期

en: Refers to a task that is configured to run in the background rather than waiting for completion.  If you have a long process that would run longer than the SSH timeout, it would make sense to launch that task in async mode.  Async modes can poll for completion every so many seconds or can be configured to "fire and forget", in which case Ansible will not even check on the task again; it will just kick it off and proceed to future steps.  Async modes work with both :command:`/usr/bin/ansible` and :command:`/usr/bin/ansible-playbook`.
ja: 完了を待たずにバックグラウンドで実行するように構成されたタスクを指します。SSH タイムアウトよりも長く実行される長いプロセスがある場合は、そのタスクを非同期モードで起動することは理にかなっています。非同期モードでは、何秒かごとに完了をポーリングすることも、「ファイアアンドフォーゲット (自動追尾機能)」ように設定することもできます。その場合、Ansible は再度タスクをチェックしません。起動して次のステップに進みます。非同期モードは :command:`/usr/bin/ansible` と :command:`/usr/bin/ansible-playbook` の両方で動作します。

en: Callback Plugin
ja: Callback プラグイン

en: Refers to some user-written code that can intercept results from Ansible and do something with them.  Some supplied examples in the GitHub project perform custom logging, send email, or even play sound effects.
ja: Ansible からの結果を傍受でき、それらについて何らかの処理を行うユーザー作成コードを指します。GitHub プロジェクトで提供されている一部のサンプルの実行内容には、カスタムロギングやメール送信、さらにはサウンド効果のプレイなどが含まれます。

en: Check Mode
ja: Check Mode (チェックモード)

en: Refers to running Ansible with the ``--check`` option, which does not make any changes on the remote systems, but only outputs the changes that might occur if the command ran without this flag.  This is analogous to so-called "dry run" modes in other systems, though the user should be warned that this does not take into account unexpected command failures or cascade effects (which is true of similar modes in other systems).  Use this to get an idea of what might happen, but do not substitute it for a good staging environment.
ja: ``--check`` オプションを指定して Ansible を実行することを指します。このオプションを選択してもリモートシステムに変更は加えられることはなく、コマンドがこのフラグなしに実行された場合に生じる可能性のある変更のみを出力します。これは、他のシステムでのいわゆる「ドライラン」モードに類似しています。ただし、この場合は予期しないコマンドの失敗やカスケード効果が考慮されないことに注意してください (他のシステムの同様のモードについても同じです)。このモードを使用すると、起こり得ることの概要を把握することはできますが、これが適切なステージング環境の代わりになる訳ではありません。

en: Collection
ja: コレクション

en: A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-core`` so features can be available sooner to users. Some collections are packaged with Ansible (version 2.10 or later). You can install other collections (or other versions of collections) with ``ansible-galaxy collection install <namespace.collection>``.
ja: プラグイン、ロール、モジュールなどを含む Ansible コンテンツをバンドルして配布するためのパッケージングフォーマット。コレクションは他のコレクションまたは ``ansible-core`` とは独立してリリースされるため、ユーザーはより早く機能を利用できます。一部のコレクションは Ansible (バージョン 2.10 以降) でパッケージ化されています。他のコレクション (またはコレクションの他のバージョン) は、``ansible-galaxy collection install <namespace.collection>`` でインストールできます。

en: Collection name
ja: コレクション名

en: The second part of a Fully Qualified Collection Name. The collection name divides the collection namespace and usually reflects the function of the collection content. For example, the ``cisco`` namespace might contain ``cisco.ios``, ``cisco.aci``, and ``cisco.nxos``, with content for managing the different network devices maintained by Cisco.
ja: 完全修飾コレクション名の 2 番目の部分。コレクション名は、コレクションの名前空間を分割し、通常はコレクションの内容の機能を反映します。たとえば、``cisco`` 名前空間には、``cisco.ios``、``cisco.aci``、および ``cisco.nxos`` が含まれ、シスコが管理するさまざまなネットワークデバイスを管理するためのコンテンツが含まれます。

en: community.general (collection)
ja: community.general (コレクション)

en: A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do ont have their own dedicated Collection. See `community.general <https://galaxy.ansible.com/community/general>`_` on Galaxy.
ja: Ansible 2.9 に同梱された、専用のコレクションを持たないすべてのモジュールとプラグインを含む Ansible Community Team が管理する特定のコレクション。Galaxy の「`community.general <https://galaxy.ansible.com/community/general>`_`」を参照してください。

en: community.network (collection)
ja: community.network (コレクション)

en: Similar to ``community.general``, focusing on network content. `community.network <https://galaxy.ansible.com/community/network>`_` on Galaxy.
ja: ``community.general`` と同様に、ネットワークコンテンツに焦点を宛てています (Galaxy の `community.network <https://galaxy.ansible.com/community/network>`_')。

en: Connection Plugin
ja: Connection プラグイン

en: By default, Ansible talks to remote machines through pluggable libraries.  Ansible uses native OpenSSH (:term:`SSH (Native)`) or a Python implementation called :term:`paramiko`.  OpenSSH is preferred if you are using a recent version, and also enables some features like Kerberos and jump hosts.  This is covered in the :ref:`getting started section <remote_connection_information>`.  There are also other connection types like ``accelerate`` mode, which must be bootstrapped over one of the SSH-based connection types but is very fast, and local mode, which acts on the local system.  Users can also write their own connection plugins.
ja: デフォルトでは、Ansible はプラグ可能なライブラリーを介してリモートマシンと対話します。Ansible はネイティブの OpenSSH (:term:`SSH (Native)`) や、:term:`paramiko` と呼ばれる Python の実装を使用します。最新バージョンを使用している場合は OpenSSH が推奨され、Kerberos やジャンプホストなどの一部の機能も有効になります。これについては、「:ref:`getting started section <remote_connection_information>`」で説明します。他にも ``accelerate`` モードのような接続タイプがあります。これは SSH ベースの接続タイプのうちのひとつを使用して起動しなければなりませんが、非常に高速です。また、ローカルシステム上で動作するローカルモードもあります。ユーザーは独自の connection プラグインを記述することもできます。

en: Conditionals
ja: 条件 (Conditional)

en: A conditional is an expression that evaluates to true or false that decides whether a given task is executed on a given machine or not. Ansible's conditionals are powered by the 'when' statement, which are discussed in the :ref:`working_with_playbooks`.
ja: 条件は、True または False に評価して、指定のタスクを所定のマシンで実行するかどうかを決定する式のことです。Ansible の条件文は、「when」ステートメントによって強化されています。「:ref:`working_with_playbooks`」を参照してください。

en: Declarative
ja: 宣言的 (Declarative)

en: An approach to achieving a task that uses a description of the final state rather than a description of the sequence of steps necessary to achieve that state. For a real world example, a declarative specification of a task would be: "put me in California". Depending on your current location, the sequence of steps to get you to California may vary, and if you are already in California, nothing at all needs to be done. Ansible's Resources are declarative; it figures out the steps needed to achieve the final state. It also lets you know whether or not any steps needed to be taken to get to the final state.
ja: あるタスクを達成するために、その状態を達成するために必要な一連の手順を記述するのではなく、最終的な状態を記述するアプローチのこと。現実世界の例では、「私をカリフォルニアに連れて行ってください」というタスクの宣言的な指定があります。あなたの現在地によって、あなたをカリフォルニアに連れて行くための一連のステップは異なるかもしれないし、あなたがすでにカリフォルニアにいる場合は、何もする必要はありません。Ansible の Resource は宣言型で、最終的な状態を実現するために必要なステップを把握しています。また、最終的な状態に到達するために必要なステップがあるかどうかも知ることができます。

en: Diff Mode
ja: 差分モード

en: A ``--diff`` flag can be passed to Ansible to show what changed on modules that support it. You can combine it with ``--check`` to get a good 'dry run'.  File diffs are normally in unified diff format.
ja: ``--diff`` フラグを Ansible に渡して、それをサポートするモジュールで何が変更されたかを示すことができます。``--check`` と組み合わせると優れた「ドライラン」を得ることができます。ファイルの差分は通常、統一された差分形式です。

en: Executor
ja: エグゼキューター (Executor)

en: A core software component of Ansible that is the power behind :command:`/usr/bin/ansible` directly -- and corresponds to the invocation of each task in a :term:`playbook <playbooks>`.  The Executor is something Ansible developers may talk about, but it's not really user land vocabulary.
ja: Ansible の中核となるソフトウェアコンポーネントで、:command:`/usr/bin/ansible` を直接支える力であり、:term:`playbook <playbooks>` の各タスクの呼び出しに対応しています。エグゼキューターは、Ansible の開発者が使用する用語で、ユーザー側が使用する用語ではありません。

en: Facts
ja: ファクト

en: Facts are simply things that are discovered about remote nodes.  While they can be used in :term:`playbooks` and templates just like variables, facts are things that are inferred, rather than set.  Facts are automatically discovered by Ansible when running plays by executing the internal :ref:`setup module <setup_module>` on the remote nodes.  You never have to call the setup module explicitly, it just runs, but it can be disabled to save time if it is not needed or you can tell ansible to collect only a subset of the full facts via the ``gather_subset:`` option. For the convenience of users who are switching from other configuration management systems, the fact module will also pull in facts from the :program:`ohai` and :program:`facter` tools if they are installed.  These are fact libraries from Chef and Puppet, respectively. (These may also be disabled via ``gather_subset:``)
ja: 端的に言うと、ファクトはリモートノードについて発見される事柄を指します。ファクトは変数のように :term:`playbooks` やテンプレートで使用できますが、ファクトは設定される事柄というよりは推測される事柄と言えます。ファクトは、リモートノードで内部 :ref:`セットアップモジュール <setup_module>` を実行することでプレイの実行中に Ansible により自動的に検出されるため、セットアップモジュールを明示的に呼び出すはありません。それはただ実行されます。その必要がなければ時間を節約するために無効にすることもできますし、``gather_subset:`` オプションで全ファクトのサブセットだけを収集するように Ansible に指示することもできます。他の設定管理システムから切り替えを行われている場合の利点として、ファクトモジュールは、Chef と Puppet のファクトライブラリーから、それぞれ :program:`ohai` ツールおよび :program:`facter` ツールからも (インストールされている場合) ファクトを取り込みます (これは ``gather_subset:`` で無効にすることもできます)。

en: Filter Plugin
ja: Filter プラグイン

en: A filter plugin is something that most users will never need to understand.  These allow for the creation of new :term:`Jinja2` filters, which are more or less only of use to people who know what Jinja2 filters are.  If you need them, you can learn how to write them in the :ref:`API docs section <developing_filter_plugins>`.
ja: filter プラグインは、ほとんどのユーザーが理解する必要がないものです。この filter プラグインは、新しい :term:`Jinja2` フィルターを作成するためのもので、多かれ少なかれ、Jinja2 のフィルターを知っている人にしか使えません。必要であれば、:ref:`API ドキュメントのセクション <developing_filter_plugins>` で記述方法を参照してください。

en: Forks
ja: フォーク

en: Ansible talks to remote nodes in parallel and the level of parallelism can be set either by passing ``--forks`` or editing the default in a configuration file.  The default is a very conservative five (5) forks, though if you have a lot of RAM, you can easily set this to a value like 50 for increased parallelism.
ja: Ansible は、複数のリモートノードと同時に対話でき、その並列処理のレベルは、``--forks`` を渡すか、設定ファイルのデフォルトを編集することで設定できます。デフォルトには非常に控え目に 5 つのフォークが設定されていますが、RAM が多数ある場合は、並列処理のレベルを上げるために値を大きく (50 など) 設定することもできます。

en: Fully Qualified Collection Name (FQCN)
ja: FQCN (完全修飾コレクション名)

en: The full definition of a module, plugin, or role hosted within a collection, in the form <namespace.collection.content_name>. Allows a Playbook to refer to a specific module or plugin from a specific source in an unambiguous manner, for example, ``community.grafana.grafana_dashboard``. The FQCN is required when you want to specify the exact source of a plugin. For example, if multiple collections contain a module plugin called ``user``, the FQCN specifies which one to use for a given task. When you have multiple collections installed, the FQCN is always the explicit and authoritative indicator of which collection to search for the correct plugin for each task.
ja: コレクション内でホストされているモジュール、プラグイン、またはロールの完全な定義を <namespace.collection.content_name> のような形で示します。Playbook が特定のソースから特定のモジュールまたはプラグインを曖昧さのない方法で参照できるようにします (たとえば、``community.grafana.grafana_dashboard`` です)。FQCN は、プラグインの正確なソースを指定したい場合に必要です。たとえば、複数のコレクションに ``user`` という名前の module プラグインが含まれている場合、FQCN は特定のタスクにどのプラグインを使用するかを指定します。複数のコレクションがインストールされている場合、FQCN は常に、各タスクに適したプラグインをどのコレクションで検索するかを明示的かつ権威的に示します。

en: Gather Facts (Boolean)
ja: ファクトの収集 (ブール値)

en: :term:`Facts` are mentioned above.  Sometimes when running a multi-play :term:`playbook <playbooks>`, it is desirable to have some plays that don't bother with fact computation if they aren't going to need to utilize any of these values.  Setting ``gather_facts: False`` on a playbook allows this implicit fact gathering to be skipped.
ja: :term:`Facts` は上述のとおりです。マルチプレイ (:term:`playbook <playbooks>`) を実行する際に、これらの値を利用する必要がない場合は、ファクト計算を行わないプレイをいくつか用意することが望ましい場合があります。Playbook に ``gather_facts: False`` を設定すると、この暗黙のファクト収集を省略することができます。

en: Globbing
ja: グラッビング (Globbing)

en: Globbing is a way to select lots of hosts based on wildcards, rather than the name of the host specifically, or the name of the group they are in.  For instance, it is possible to select ``ww*`` to match all hosts starting with ``www``.   This concept is pulled directly from :program:`Func`, one of Michael DeHaan's (an Ansible Founder) earlier projects.  In addition to basic globbing, various set operations are also possible, such as 'hosts in this group and not in another group', and so on.
ja: グラッビングとは、特定のホスト名や所属するグループ名ではなく、ワイルドカードに基づいて多数のホストを選択する方法です。たとえば ``ww*`` を選択すると、``www`` で始まるすべてのホストに一致させることができます。この概念は、Ansible の創始者である Michael DeHaan 氏の初期のプロジェクトの 1 つである :program:`Func` から直接引用しています。基本的なグラッビングに加えて、「このグループに含まれ、他のグループには含まれないホスト」など、さまざまなセット操作が可能です。

en: Group
ja: グループ

en: A group consists of several hosts assigned to a pool that can be conveniently targeted together, as well as given variables that they share in common.
ja: グループは、プールに割り当てられた複数のホストで構成されます。これらのホストは、一緒に対象に設定でき、それらが共通して共有する特定の変数です。

en: Group Vars
ja: グループ変数

en: The :file:`group_vars/` files are files that live in a directory alongside an inventory file, with an optional filename named after each group.  This is a convenient place to put variables that are provided to a given group, especially complex data structures, so that these variables do not have to be embedded in the :term:`inventory` file or :term:`playbook <playbooks>`.
ja: :file:`group_vars/` ファイルは、各グループに由来する任意のファイル名で、インベントリーファイルと共にディレクトリーに存在するファイルのことです。このファイルは、特にデータ構造が複雑な場合などに、所定グループに提供される変数を配置できる便利な場所になります。これにより、これらの変数が :term:`inventory` ファイルまたは :term:`playbook <playbooks>` に埋め込む必要がなくなります。

en: Handlers
ja: ハンドラー

en: Handlers are just like regular tasks in an Ansible :term:`playbook <playbooks>` (see :term:`Tasks`) but are only run if the Task contains a ``notify`` directive and also indicates that it changed something.  For example, if a config file is changed, then the task referencing the config file templating operation may notify a service restart handler.  This means services can be bounced only if they need to be restarted.  Handlers can be used for things other than service restarts, but service restarts are the most common usage.
ja: ハンドラーは Ansible :term:`playbook <playbooks>` の通常のタスクのような機能を持ちます(「:term:`タスク`」を参照) が、タスクに ``notify`` ディレクティブがあり、変更があったことが示唆される場合にのみ実行されます。たとえば、設定ファイルが変更された後に、設定ファイルを参照するテンプレート作成操作のタスクは、サービス再起動ハンドラーに通知する可能性があります。これは、サービスが再起動する必要がある場合にのみバウンスできることを意味します。ハンドラーはサービスの再起動以外のタスクに使用できますが、サービスの再起動が最も一般的な使用例になります。

en: Host
ja: ホスト

en: A host is simply a remote machine that Ansible manages.  They can have individual variables assigned to them, and can also be organized in groups.  All hosts have a name they can be reached at (which is either an IP address or a domain name) and, optionally, a port number, if they are not to be accessed on the default SSH port.
ja: ホストとは、Ansible が管理するリモートマシンのことです。ホストには、個別に変数を割り当てることも、グループでまとめることもできます。すべてのホストには、アクセス可能な名前 (IP アドレスまたはドメイン名) と、デフォルトの SSH ポートでアクセスしない場合は、任意でポート番号が割り当てられます。

en: Host Specifier
ja: ホスト指定子

en: Each :term:`Play <plays>` in Ansible maps a series of :term:`tasks` (which define the role, purpose, or orders of a system) to a set of systems.
ja: Ansible の各 :term:`プレイ <plays>` は、一連の :term:`タスク` (システムのロール、目的、または順序を定義します) を一連のシステムにマッピングします。

en: This ``hosts:`` directive in each play is often called the hosts specifier.
ja: 各プレイの ``hosts:`` ディレクティブは、しばしばホスト指定子と呼ばれます。

en: It may select one system, many systems, one or more groups, or even some hosts that are in one group and explicitly not in another.
ja: 1 つのシステム、多数のシステム、1 つ以上のグループ、または 1 つのグループにあり明示的に別のグループにはない複数のホストを選択することができます。

en: Host Vars
ja: ホスト変数

en: Just like :term:`Group Vars`, a directory alongside the inventory file named :file:`host_vars/` can contain a file named after each hostname in the inventory file, in :term:`YAML` format.  This provides a convenient place to assign variables to the host without having to embed them in the :term:`inventory` file.  The Host Vars file can also be used to define complex data structures that can't be represented in the inventory file.
ja: :term:`Group Vars` のように、インベントリーファイルの横にある :file:`host_vars/` ディレクトリーには、インベントリーファイルの各ホスト名にちなんで :term:`YAML` 形式のファイルを置くことができます。これは、:term:`inventory` ファイルに変数を埋め込まなくても、ホストに変数を割り当てるための便利な場所となります。ホストの vars ファイルは、インベントリーファイルでは表現できない複雑なデータ構造を定義するのにも使用できます。

en: Idempotency
ja: 冪等性

en: An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions.
ja: 操作を 1 回実行した結果が、何も介入せずに繰り返し実行した結果とまったく同じであれば、操作は冪等です。

en: Includes
ja: インクルード (Include)

en: The idea that :term:`playbook <playbooks>` files (which are nothing more than lists of :term:`plays`) can include other lists of plays, and task lists can externalize lists of :term:`tasks` in other files, and similarly with :term:`handlers`.  Includes can be parameterized, which means that the loaded file can pass variables.  For instance, an included play for setting up a WordPress blog may take a parameter called ``user`` and that play could be included more than once to create a blog for both ``alice`` and ``bob``.
ja: :term:`playbook <playbooks>` のファイル (これは :term:`plays` のリストに他ならない) は、他のプレイリストを含むことができ、タスクリストは他のファイルの :term:`tasks` のリストを具体化することができ、:term:`handlers` でも同様となるという考え方です。インクルードはパラメーター化できるため、読み込まれたファイルは変数を渡すことができます。たとえば、WordPress ブログをセットアップするためのインクルードプレイは、``user`` というパラメーターを取り、そのプレイを複数回インクルードすることで、``alice`` と ``bob`` の両方にブログを作成することができます。

en: Inventory
ja: インベントリー

en: A file (by default, Ansible uses a simple INI format) that describes :term:`Hosts <Host>` and :term:`Groups <Group>` in Ansible.  Inventory can also be provided via an :term:`Inventory Script` (sometimes called an "External Inventory Script").
ja: Ansible で :term:`ホスト <Host>` と :term:`グループ <Group>` を記述したファイル (デフォルトでは、Ansible は簡単な INI 形式を使用)。インベントリーは、:term:`Inventory Script` (「外部インベントリースクリプト」と呼ばれることもあります) を介して提供することもできます。

en: Inventory Script
ja: インベントリースクリプト

en: A very simple program (or a complicated one) that looks up :term:`hosts <Host>`, :term:`group` membership for hosts, and variable information from an external resource -- whether that be a SQL database, a CMDB solution, or something like LDAP.  This concept was adapted from Puppet (where it is called an "External Nodes Classifier") and works more or less exactly the same way.
ja: :term:`ホスト <Host>`、ホストの :term:`グループ` メンバーシップ、および変数情報を、SQL データベース、CMDB ソリューションまたは LDAP に類する外部リソースから参照する非常に簡単なプログラム (または複雑なプログラム) のことです。この概念は Puppet (「外部ノード分類子」と呼ばれています) から採用されたもので、ほぼ同じように機能します。

en: Jinja2 is the preferred templating language of Ansible's template module.  It is a very simple Python template language that is generally readable and easy to write.
ja: Jinja2 は、Ansible のテンプレートモジュールで推奨されるテンプレート言語です。これは非常にシンプルな Python テンプレート言語であり、一般的に読みやすく、簡単に記述できます。

en: Ansible uses JSON for return data from remote modules.  This allows modules to be written in any language, not just Python.
ja: Ansible はリモートモジュールから返されるデータに JSON を使用します。モジュールは Python だけではなくすべての言語で作成することができます。

en: Lazy Evaluation
ja: 遅延評価

en: In general, Ansible evaluates any variables in :term:`playbook <playbooks>` content at the last possible second, which means that if you define a data structure that data structure itself can define variable values within it, and everything "just works" as you would expect.  This also means variable strings can include other variables inside of those strings.
ja: 一般的に Ansible は、:term:`playbook <playbooks>` のコンテンツに含まれるすべての変数を可能な限り最後の瞬間に評価します。つまり、データ構造を定義した場合、そのデータ構造自体がその中に変数値を定義することができ、すべてが期待通りに「ただ動く」のです。これは、変数文字列が、その文字列内に他の変数を含むことができることも意味します。

en: Library
ja: ライブラリー

en: A collection of modules made available to :command:`/usr/bin/ansible` or an Ansible :term:`playbook <playbooks>`.
ja: :command:`/usr/bin/ansible` または Ansible :term:`playbook <playbooks>` で利用できるようになったモジュールのコレクション。

en: Limit Groups
ja: グループの制限

en: By passing ``--limit somegroup`` to :command:`ansible` or :command:`ansible-playbook`, the commands can be limited to a subset of :term:`hosts <Host>`.  For instance, this can be used to run a :term:`playbook <playbooks>` that normally targets an entire set of servers to one particular server.
ja: ``--limit somegroup`` を :command:`ansible` または :command:`ansible-playbook` に渡すことで、コマンドを :term:`hosts <Host>` のサブセットに限定することができます。たとえば、通常はサーバーのセット全体を対象としている :term:`playbook <playbooks>` を、特定のサーバーに向けて実行する場合に使用できます。

en: Local Action
ja: ローカルアクション

en: A local_action directive in a :term:`playbook <playbooks>` targeting remote machines means that the given step will actually occur on the local machine, but that the variable ``{{ ansible_hostname }}`` can be passed in to reference the remote hostname being referred to in that step.  This can be used to trigger, for example, an rsync operation.
ja: リモートマシンを対象とした :term:`playbook <playbooks>` の local_action ディレクティブは、指定した手順が実際にはローカルマシン上で実行されるが、そのステップで参照されるリモートホスト名を参照するために変数 ``{{ ansible_hostname }}`` を渡すことができることを意味します。これを利用して、たとえば rsync の操作を行うことができます。

en: Local Connection
ja: ローカル接続

en: By using ``connection: local`` in a :term:`playbook <playbooks>`, or passing ``-c local`` to :command:`/usr/bin/ansible`, this indicates that we are managing the local host and not a remote machine.
ja: :term:`playbook <playbooks>` で ``connection: local`` を使用するか、``-c local`` を :command:`/usr/bin/ansible` に渡した場合は、リモートホストではなくローカルホストを管理していることを示しています。

en: Lookup Plugin
ja: Lookup プラグイン

en: A lookup plugin is a way to get data into Ansible from the outside world. Lookup plugins are an extension of Jinja2 and can be accessed in templates, for example, ``{{ lookup('file','/path/to/file') }}``. These are how such things as ``with_items``, are implemented. There are also lookup plugins like ``file`` which loads data from a file and ones for querying environment variables, DNS text records, or key value stores.
ja: Lookup プラグインとは、外部から Ansible にデータを取り込むための方法です。Lookup プラグインは Jinja2 の拡張機能で、``{{ lookup('file','/path/to/file') }}`` などのテンプレートでアクセスできます。``with_items`` のようなものがこれらによって実装されています。Lookup プラグインには、``file`` のようにファイルからデータを読み込むものや、環境変数や DNS のテキストレコード、キーバリューストアなどを照会するものもあります。

en: Loops
ja: ループ

en: Generally, Ansible is not a programming language. It prefers to be more declarative, though various constructs like ``loop`` allow a particular task to be repeated for multiple items in a list. Certain modules, like :ref:`yum <yum_module>` and :ref:`apt <apt_module>`, actually take lists directly, and can install all packages given in those lists within a single transaction, dramatically speeding up total time to configuration, so they can be used without loops.
ja: 一般的に、Ansible はプログラミング言語ではありません。しかし、``loop`` のような様々な構造によって、リストの複数のアイテムに対して特定のタスクを繰り返すことができます。:ref:`yum <yum_module>` や:ref:`apt <apt_module>` などのモジュールは、実際にリストを直接受け取り、それらのリストで指定されたすべてのパッケージを 1 つのトランザクション内でインストールすることができ、設定にかかる時間を劇的に短縮することができます。したがってループを使用せずに使用できます。

en: Modules
ja: モジュール

en: Modules are the units of work that Ansible ships out to remote machines.   Modules are kicked off by either :command:`/usr/bin/ansible` or :command:`/usr/bin/ansible-playbook` (where multiple tasks use lots of different modules in conjunction). Modules can be implemented in any language, including Perl, Bash, or Ruby -- but can leverage some useful communal library code if written in Python.  Modules just have to return :term:`JSON`.  Once modules are executed on remote machines, they are removed, so no long running daemons are used.  Ansible refers to the collection of available modules as a :term:`library`.
ja: モジュールは、Ansible がリモートマシンに送出する作業単位です。モジュールは、:command:`/usr/bin/ansible` か :command:`/usr/bin/ansible-playbook` (複数のタスクが多数の異なるモジュールを組み合わせて使用する場合) のいずれかで起動します。モジュールは、Perl、Bash、Ruby を含む任意の言語で実装できますが、Python で記述されている場合は、いくつかの有用な共通ライブラリーコードを利用できます。モジュールは :term:`JSON` を返せば十分です。モジュールがリモートマシン上で実行すると、それらは削除されるため、実行中のデーモンは使用されません。Ansible は、利用可能なモジュールの集合を :term:`library` として参照します。

en: Multi-Tier
ja: 多層

en: The concept that IT systems are not managed one system at a time, but by interactions between multiple systems and groups of systems in well defined orders.  For instance, a web server may need to be updated before a database server and pieces on the web server may need to be updated after *THAT* database server and various load balancers and monitoring servers may need to be contacted.  Ansible models entire IT topologies and workflows rather than looking at configuration from a "one system at a time" perspective.
ja: IT システムは、一度に 1 つのシステムではなく、複数のシステムとシステムのグループ間の相互作用によって、明確に定義された順序で管理されるという概念。たとえば、データベースサーバーの前に Web サーバーを更新する必要があり、*その* データベースサーバーとさまざまなロードバランサーおよび監視サーバーに接続する必要がある場合は、Web サーバー上の部分を更新する必要があります。Ansible は、「一度に 1 つのシステム」の観点から構成を検討するのではなく、IT トポロジーとワークフロー全体をモデル化します。

en: Namespace
ja: 名前空間

en: The first part of a fully qualified collection name, the namespace usually reflects a functional content category. Example: in ``cisco.ios.ios_config``, ``cisco`` is the namespace. Namespaces are reserved and distributed by Red Hat at Red Hat's discretion. Many, but not all, namespaces will correspond with vendor names. See `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for namespace requirements.
ja: 完全修飾コレクション名の最初の部分で、名前空間は通常、機能的なコンテンツカテゴリーを反映しています。たとえば、``cisco.ios.ios_config`` では、``cisco`` が名前空間になります。名前空間は Red Hat によって予約され、Red Hat の裁量で配布されます。すべてではありませんが、多くの名前空間はベンダーの名前に対応しています。名前空間の要件については、Galaxy ドキュメントサイトの「`Galaxy 名前空間 <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_」を参照してください。

en: Notify
ja: Notify (通知)

en: The act of a :term:`task <tasks>` registering a change event and informing a :term:`handler <handlers>` task that another :term:`action` needs to be run at the end of the :term:`play <plays>`.  If a handler is notified by multiple tasks, it will still be run only once.  Handlers are run in the order they are listed, not in the order that they are notified.
ja: 変更イベントを登録し、:term:`ハンドラー <handlers>` タスクに :term:`プレイ <plays>` の終了時に別の :term:`操作` の実行が必要であることを知らせる :term:`タスク <tasks>` の行為です。ハンドラーが複数のタスクによる通知を受けても、ハンドラーは 1 回のみ実行されます。ハンドラーは、それらが通知を受けた順番ではなく、一覧表示された順に実行されます。

en: Orchestration
ja: オーケストレーション

en: Many software automation systems use this word to mean different things.  Ansible uses it as a conductor would conduct an orchestra. A datacenter or cloud architecture is full of many systems, playing many parts -- web servers, database servers, maybe load balancers, monitoring systems, continuous integration systems, and so on.  In performing any process, it is necessary to touch systems in particular orders, often to simulate rolling updates or to deploy software correctly.  Some system may perform some steps, then others, then previous systems already processed may need to perform more steps. Along the way, emails may need to be sent or web services contacted. Ansible orchestration is all about modeling that kind of process.
ja: 多くのソフトウェア自動化システムでは、この言葉をさまざまな意味で使用しています。Ansible は、この言葉を「指揮者がオーケストラを指揮する」という意味で使用しています。データセンターやクラウドのアーキテクチャには、Web サーバー、データベースサーバー、ロードバランサー、監視システム、継続的統合システムなど、多くのシステムが存在し、さまざまな役割を担っています。プロセスを実行する際には、特定の順序でシステムに触れる必要があります。これは、ローリングアップデートをシミュレートしたり、ソフトウェアを正しくデプロイするためです。あるシステムがいくつかのステップを実行し、次に他のシステムを実行し、すでに処理された前のシステムがさらにステップを実行する必要があるかもしれません。その過程で、メールの送信や Web サービスへの問い合わせが必要になることもあります。Ansible のオーケストレーションは、このようなプロセスをモデル化するためのものです。

en: paramiko
ja: Paramiko

en: By default, Ansible manages machines over SSH.   The library that Ansible uses by default to do this is a Python-powered library called paramiko.  The paramiko library is generally fast and easy to manage, though users who want to use Kerberos or Jump Hosts may wish to switch to a native SSH binary such as OpenSSH by specifying the connection type in their :term:`playbooks`, or using the ``-c ssh`` flag.
ja: デフォルトでは、Ansible は SSH でマシンを管理します。Ansible がこれを行うためにデフォルトで使用しているのは、paramiko という名前の Python を使用したライブラリーです。paramiko ライブラリーは一般的に高速で管理も簡単ですが、Kerberos や Jump Host を使いたい場合は、:term:`playbooks` で接続タイプを指定するか、``-c ssh`` フラグを使用して OpenSSH などのネイティブな SSH バイナリーに切り替えたほうがいいでしょう。

en: Playbooks
ja: Playbook

en: Playbooks are the language by which Ansible orchestrates, configures, administers, or deploys systems.  They are called playbooks partially because it's a sports analogy, and it's supposed to be fun using them. They aren't workbooks :)
ja: Playbook は、Ansible がシステムのオーケストレーション、設定、管理、またはデプロイするための言語です。これが Playbook と呼ばれるのは、ある種スポーツに似ており、それを使用することで楽しめるからです。したがって、ワークブックではありません。

en: Plays
ja: プレイ

en: A :term:`playbook <playbooks>` is a list of plays.  A play is minimally a mapping between a set of :term:`hosts <Host>` selected by a host specifier (usually chosen by :term:`groups <Group>` but sometimes by hostname :term:`globs <Globbing>`) and the :term:`tasks` which run on those hosts to define the role that those systems will perform. There can be one or many plays in a playbook.
ja: :term:`playbook <playbooks>` はプレイのリストです。最小単位のプレイのマッピングは、ホスト指定子で選択される :term:`ホスト <Host>` のセット (通常は :term:`グループ <Group>` で選択されますが、ホスト名 :term:`globs <Globbing>` で選択されることもある) と、システムが実行するロールを定義するためにホストで実行される :term:`タスク` 間のマッピングです。Playbook には 1 つまたは数多くのプレイが含まれる場合があります。

en: Pull Mode
ja: プルモード

en: By default, Ansible runs in :term:`push mode`, which allows it very fine-grained control over when it talks to each system.  Pull mode is provided for when you would rather have nodes check in every N minutes on a particular schedule.  It uses a program called :command:`ansible-pull` and can also be set up (or reconfigured) using a push-mode :term:`playbook <playbooks>`.  Most Ansible users use push mode, but pull mode is included for variety and the sake of having choices.
ja: デフォルトでは、Ansible は :term:`push mode` で実行します。これにより、各システムと対話するタイミングを非常に細かく制御することができます。また、特定のスケジュールで N 分ごとにノードをチェックしたい場合は、プルモードが用意されています。これには :command:`ansible-pull` というプログラムを使用します。また、プッシュモード :term:`playbook <playbooks>` を使用して設定 (または再設定) することもできます。ほとんどの Ansible ユーザーはプッシュモードを使用していますが、多様性と選択肢を持たせるためにプルモードも含まれています。

en: :command:`ansible-pull` works by checking configuration orders out of git on a crontab and then managing the machine locally, using the :term:`local connection` plugin.
ja: :command:`ansible-pull` は、crontab で git から設定順序を確認し、:term:`local connection` プラグインを使用してマシンをローカルで管理することで機能します。

en: Push Mode
ja: プッシュモード

en: Push mode is the default mode of Ansible. In fact, it's not really a mode at all -- it's just how Ansible works when you aren't thinking about it.  Push mode allows Ansible to be fine-grained and conduct nodes through complex orchestration processes without waiting for them to check in.
ja: プッシュモードは、Ansible のデフォルトモードです。実際には、モードというよりも、意識していないときに Ansible がどのように動作するかを示すものです。プッシュモードでは、Ansible を細かく設定することができ、複雑なオーケストレーションプロセスでもノードのチェックインを待たずに実行することができます。

en: Register Variable
ja: 登録変数

en: The result of running any :term:`task <tasks>` in Ansible can be stored in a variable for use in a template or a conditional statement. The keyword used to define the variable is called ``register``, taking its name from the idea of registers in assembly programming (though Ansible will never feel like assembly programming).  There are an infinite number of variable names you can use for registration.
ja: Ansible で :term:`task <tasks>` を実行した結果を変数に格納し、テンプレートや条件文で使用することができます。変数の定義に使用されるキーワードは ``register`` と呼ばれ、その名前はアセンブリープログラミングにおけるレジスターの考え方に由来しています (ただし、Ansible がアセンブリープログラミングのように感じることはありません)。登録に使用できる変数名は無限にあります。

en: Resource Model
ja: リソースモデル

en: Ansible modules work in terms of resources.   For instance, the :ref:`file module <file_module>` will select a particular file and ensure that the attributes of that resource match a particular model. As an example, we might wish to change the owner of :file:`/etc/motd` to ``root`` if it is not already set to ``root``, or set its mode to ``0644`` if it is not already set to ``0644``.  The resource models are :term:`idempotent <idempotency>` meaning change commands are not run unless needed, and Ansible will bring the system back to a desired state regardless of the actual state -- rather than you having to tell it how to get to the state.
ja: Ansible モジュールは、リソースの観点から動作します。たとえば、:ref:`file module <file_module>` は、特定のファイルを選択し、そのリソースの属性が特定のモデルと一致することを確認します。たとえば、:file:`/etc/motd` の所有者が ``root`` に設定されていなければ ``root`` に変更し、そのモードが ``0644`` に設定されていなければ ``0644`` に設定したいとします。リソースモデルは :term:`idempotent <idempotency>`、つまり変更コマンドは必要な時以外は実行されず、Ansibl eは、実際の状態に関わらず、システムを望ましい状態に戻してくれますが、その状態になるための方法を指示する必要はありません。

en: Roles
ja: ロール

en: Roles are units of organization in Ansible.  Assigning a role to a group of :term:`hosts <Host>` (or a set of :term:`groups <group>`, or :term:`host patterns <Globbing>`, and so on) implies that they should implement a specific behavior.  A role may include applying certain variable values, certain :term:`tasks`, and certain :term:`handlers` -- or just one or more of these things.  Because of the file structure associated with a role, roles become redistributable units that allow you to share behavior among :term:`playbooks` -- or even with other users.
ja: ロールは Ansible における組織単位です。ロールを :term:`ホスト <Host>` のグループ (もしくは :term:`グループ <group>` または :term:`ホストパターン <Globbing>` のセットなど) に割り当てることは、ホストのグループが特定の動作を実装することを意味します。ロールには特定の変数の値、特定の :term:`タスク`、特定の :term:`ハンドラー`、またはこれらの 1 つまたは複数を適用することが含まれます。ファイル構造がロールに関連付けられていることから、ロールは再配布可能な単位であり、これを使用して :term:`playbooks` 間または他のユーザーと動作を共有することができます。

en: Rolling Update
ja: ローリング更新

en: The act of addressing a number of nodes in a group N at a time to avoid updating them all at once and bringing the system offline.  For instance, in a web topology of 500 nodes handling very large volume, it may be reasonable to update 10 or 20 machines at a time, moving on to the next 10 or 20 when done.  The ``serial:`` keyword in an Ansible :term:`playbooks` control the size of the rolling update pool.  The default is to address the batch size all at once, so this is something that you must opt-in to.  OS configuration (such as making sure config files are correct) does not typically have to use the rolling update model, but can do so if desired.
ja: 一度にすべてのノードを更新してシステムがオフラインになるのを回避するために、グループ N 内のいくつかのノードに対して一度に処理する行為。たとえば、非常に大きなボリュームを扱う 500 台のノードからなる Web トポロジーでは、一度に 10 台または 20 台のマシンを更新し、更新が完了したら次の 10 台または 20 台に移るのが妥当な場合があります。Ansible :term:`playbook` の ``serial:`` キーワードは、ローリングアップデートプールのサイズを制御します。デフォルトでは、一度にバッチサイズに対応するようになっているため、これを選択する必要があります。OS の設定 (設定ファイルが正しいかどうかの確認など) では、通常、ローリング更新モデルを使用する必要はありませんが、必要に応じて使用することができます。

en: Serial
ja: シリアル

en: Ansible does not require root logins, and since it's daemonless, definitely does not require root level daemons (which can be a security concern in sensitive environments).  Ansible can log in and perform many operations wrapped in a sudo command, and can work with both password-less and password-based sudo.  Some operations that don't normally work with sudo (like scp file transfer) can be achieved with Ansible's :ref:`copy <copy_module>`, :ref:`template <template_module>`, and :ref:`fetch <fetch_module>` modules while running in sudo mode.
ja: Ansible では root ログインが不要であり、デーモンも不要のため、root レベルのデーモンも要求されません (これは機密環境ではセキュリティー上の懸念点となる可能性があります)。Ansible は sudo コマンドでログインでき、このコマンドでラップされた数多くの操作を実行でき、パスワードなしか、またはパスワードを使用する sudo で機能します。通常 sudo で機能しない操作 (scp ファイル転送など) については、sudo モードで実行中の Ansible の :ref:`copy <copy_module>`、:ref:`template <template_module>`、および :ref:`fetch <fetch_module>` モジュールを使用して実行できます。

en: SSH (Native)
ja: SSH (ネイティブ)

en: Native OpenSSH as an Ansible transport is specified with ``-c ssh`` (or a config file, or a directive in the :term:`playbook <playbooks>`) and can be useful if wanting to login via Kerberized SSH or using SSH jump hosts, and so on.  In 1.2.1, ``ssh`` will be used by default if the OpenSSH binary on the control machine is sufficiently new. Previously, Ansible selected ``paramiko`` as a default.  Using a client that supports ``ControlMaster`` and ``ControlPersist`` is recommended for maximum performance -- if you don't have that and don't need Kerberos, jump hosts, or other features, ``paramiko`` is a good choice.  Ansible will warn you if it doesn't detect ControlMaster/ControlPersist capability.
ja: Ansible のトランスポートとしてのネイティブな OpenSSH は、``-c ssh`` (または設定ファイル、あるいは :term:`playbook <playbooks>` のディレクティブ) で指定します。これは Kerberized SSH でログインしたい場合や、SSH ジャンプホストを使用したい場合などに便利です。1.2.1 では、コントロールマシン上の OpenSSH バイナリーが十分に新しい場合は、``ssh`` がデフォルトで使用されます。これまでの Ansible では、デフォルトで ``paramiko`` が選択されていました。最大限のパフォーマンスを得るためには、``ControlMaster`` および ``ControlPersist`` をサポートしているクライアントを使用することが推奨されています。もしそれがなく、Kerberos やジャンプホストなどの機能が不要な場合は、``paramiko`` を使用することが推奨されます。Ansible は、ControlMaster/ControlPersist 機能を検出できないと警告を発します。

en: Tags
ja: タグ

en: Ansible allows tagging resources in a :term:`playbook <playbooks>` with arbitrary keywords, and then running only the parts of the playbook that correspond to those keywords.  For instance, it is possible to have an entire OS configuration, and have certain steps labeled ``ntp``, and then run just the ``ntp`` steps to reconfigure the time server information on a remote host.
ja: Ansible では、:term:`playbook <playbooks>` 内のリソースに任意のキーワードをタグ付けし、そのキーワードに対応する Playbook の部分のみを実行することができます。たとえば、OS 全体の設定を行い、特定のステップにラベル ``ntp`` を付け、``ntp`` のステップだけを実行して、リモートホストのタイムサーバー情報を再設定することができます。

en: Task
ja: タスク

en: :term:`Playbooks` exist to run tasks.  Tasks combine an :term:`action` (a module and its arguments) with a name and optionally some other keywords (like :term:`looping directives <loops>`).   :term:`Handlers` are also tasks, but they are a special kind of task that do not run unless they are notified by name when a task reports an underlying change on a remote system.
ja: :term:`Playbooks` はタスクを実行するために存在します。タスクは、:term:`action` (モジュールとその引数) と名前、そして (:term:`looping directives <loops>` のような) その他の任意のキーワードを組み合わせたものです。:term:`Handlers` もタスクですが、これは特別な種類のタスクで、タスクがリモートシステム上で根本的な変更を報告したときに名前で通知されない限り実行されません。

en: Tasks
ja: タスク

en: A list of :term:`Task`.
ja: :term:`タスク` の一覧です。

en: Templates
ja: テンプレート

en: Ansible can easily transfer files to remote systems but often it is desirable to substitute variables in other files.  Variables may come from the :term:`inventory` file, :term:`Host Vars`, :term:`Group Vars`, or :term:`Facts`. Templates use the :term:`Jinja2` template engine and can also include logical constructs like loops and if statements.
ja: Ansible は、ファイルをリモートシステムに簡単に転送できますが、他のファイルの変数を置き換えることが望ましい場合があります。変数は、:term:`inventory` ファイル、:term:`Host Vars`、:term:`Group Vars`、または :term:`Facts` から設定できます。テンプレートは、:term:`Jinja2` テンプレートエンジンを使用し、ループや if ステートメントなどの論理構造を含めることもできます。

en: Transport
ja: トランスポート

en: Ansible uses :term:``Connection Plugins`` to define types of available transports.  These are simply how Ansible will reach out to managed systems.  Transports included are :term:`paramiko`, :term:`ssh <SSH (Native)>` (using OpenSSH), and :term:`local <Local Connection>`.
ja: Ansible は :term:``Connection Plugins`` を使用して、利用可能なトランスポートの種類を定義します。これらは単に、Ansible が管理されたシステムに到達する方法です。含まれるトランスポートは、:term:`paramiko`、:term:`ssh <SSH (Native)>` (OpenSSH を使用)、および :term:`local <Local Connection>` です。

en: An optional conditional statement attached to a :term:`task <tasks>` that is used to determine if the task should run or not. If the expression following the ``when:`` keyword evaluates to false, the task will be ignored.
ja: :term:`task <tasks>` に付けられた任意の条件文で、タスクが実行されるべきかどうかを判断するために使用されます。``when:`` キーワードに続く式が false と評価された場合、そのタスクは無視されます。

en: Vars (Variables)
ja: 変数

en: As opposed to :term:`Facts`, variables are names of values (they can be simple scalar values -- integers, booleans, strings) or complex ones (dictionaries/hashes, lists) that can be used in templates and :term:`playbooks`.  They are declared things, not things that are inferred from the remote system's current state or nature (which is what Facts are).
ja: :term:`Facts` とは対照的に、変数は、テンプレートや :term:`playbooks` で使用できる値の名前 (整数、ブール値、文字列などの単純なスカラー値など) や複雑な名前 (辞書/ハッシュ、リスト) となります。これらは宣言されたものであり、リモートシステムの現在の状態や性質から推測されるものではありません (これがファクトです)。

en: Ansible does not want to force people to write programming language code to automate infrastructure, so Ansible uses YAML to define :term:`playbook <playbooks>` configuration languages and also variable files.  YAML is nice because it has a minimum of syntax and is very clean and easy for people to skim.  It is a good data format for configuration files and humans, but also machine readable.  Ansible's usage of YAML stemmed from Michael DeHaan's first use of it inside of Cobbler around 2006.  YAML is fairly popular in the dynamic language community and the format has libraries available for serialization in many languages (Python, Perl, Ruby, and so on).
ja: Ansible は、インフラストラクチャーを自動化するためのプログラミング言語コードの記述を強制しないように、YAML を使用して :term:`playbook <playbooks>` 設定言語と変数ファイル定義します。YAML は、最小限の構文しか使用されていないため、非常にわかりやすく、簡単に確認できるため優れています。これは、設定ファイルやユーザーにとって優れたデータ形式ですが、機械でも判別可能です。Ansible での YAML の使用は、2006 年頃に Michael DeHaan が Cobbler 内で最初に使用したことに端を発しています。YAML は動的言語コミュニティーで非常に人気があり、この形式には多くの言語 (Python、Perl、Ruby など) でシリアル化できるライブラリーがあります。

en: Frequently asked questions
ja: よくある質問 (FAQ)

en: `User Mailing List <https://groups.google.com/group/ansible-devel>`_
ja: `メーリングリストの使用 <https://groups.google.com/group/ansible-devel>`_

en: Interpreter Discovery
ja: インタープリターの検出

en: Most Ansible modules that execute under a POSIX environment require a Python interpreter on the target host. Unless configured otherwise, Ansible will attempt to discover a suitable Python interpreter on each target host the first time a Python module is executed for that host.
ja: POSIX 環境で実行されるほとんどの Ansible モジュールには、ターゲットホスト上に Python インタープリターが必要です。特に設定されていない限り、Ansible は、Python モジュールがそのホストに対して最初に実行されるときに、各ターゲットホストで適切な Python インタープリターを検出しようとします。

en: To control the discovery behavior:
ja: 検出動作を制御するには、以下を実行します。

en: for individual hosts and groups, use the ``ansible_python_interpreter`` inventory variable
ja: 個別のホストおよびグループの場合は、``ansible_python_interpreter`` インベントリー変数を使用します。

en: globally, use the ``interpreter_python`` key in the ``[defaults]`` section of ``ansible.cfg``
ja: グローバルに、``interpreter_python`` の ``[defaults]`` セクションに ``ansible.cfg`` キーを使用します。

en: Use one of the following values:
ja: 以下のいずれかの値を使用します。

en: Detects the target OS platform, distribution, and version, then consults a table listing the correct Python interpreter and path for each platform/distribution/version. If an entry is found, and ``/usr/bin/python`` is absent, uses the discovered interpreter (and path). If an entry is found, and ``/usr/bin/python`` is present, uses ``/usr/bin/python`` and issues a warning. This exception provides temporary compatibility with previous versions of Ansible that always defaulted to ``/usr/bin/python``, so if you have installed Python and other dependencies at ``/usr/bin/python`` on some hosts, Ansible will find and use them with this setting. If no entry is found, or the listed Python is not present on the target host, searches a list of common Python interpreter paths and uses the first one found; also issues a warning that future installation of another Python interpreter could alter the one chosen.
ja: ターゲット OS プラットフォーム、ディストリビューション、およびバージョンを検出してから、各プラットフォーム/ディストリビューション/バージョンに適した Python インタープリターとパスを表示するテーブルを参照します。エントリーが見つかり、``/usr/bin/python`` が存在していない場合は、検出されたインタープリター (およびパス) を使用します。エントリーが見つかり、``/usr/bin/python`` が存在する場合は、``/usr/bin/python`` を使用して警告を出力します。この例外は、常に ``/usr/bin/python`` にデフォルトで設定されていた以前のバージョンの Ansible との一時的な互換性を提供されているため、Python や一部のホストの ``/usr/bin/python`` にその他の依存関係である場合は、Ansible はこの設定でそれらを見つけて使用します。エントリーが見つからなかった場合や、リストされた Python がターゲットホストにない場合は、一般的な Python インタープリターパスのリストを検索し、最初に検出したインタープリターを使用します。また、今後別の Python インタープリターをインストールすると、選択したパスが変更する可能性があるという警告が表示されます。

en: Detects the target OS platform, distribution, and version, then consults a table listing the correct Python interpreter and path for each platform/distribution/version. If an entry is found, uses the discovered interpreter. If no entry is found, or the listed Python is not present on the target host, searches a list of common Python interpreter paths and uses the first one found; also issues a warning that future installation of another Python interpreter could alter the one chosen.
ja: ターゲット OS プラットフォーム、ディストリビューション、およびバージョンを検出してから、各プラットフォーム/ディストリビューション/バージョンに適した Python インタープリターとパスを表示するテーブルを参照します。エントリーが見つからなかった場合や、リストされた Python がターゲットホストにない場合は、一般的な Python インタープリターパスのリストを検索し、最初に検出したインタープリターを使用します。また、今後別のインタープリターをインストールすると、選択したパスが変更する可能性があるという警告が表示されます。

en: Same as ``auto_legacy``, but does not issue warnings.
ja: ``auto_legacy`` と同じですが、警告は表示しません。

en: Same as ``auto``, but does not issue warnings.
ja: ``auto`` と同じですが、警告は表示しません。

en: You can still set ``ansible_python_interpreter`` to a specific path at any variable level (for example, in host_vars, in vars files, in playbooks, and so on). Setting a specific path completely disables automatic interpreter discovery; Ansible always uses the path specified.
ja: ``ansible_python_interpreter`` を変数レベルで特定のパスに設定できます (例: host_vars では、vars ファイルでは、Playbook ではなど)。特定のパスを設定すると、自動インタープリターの検出が完全に無効化され、Ansible は常に指定されたパスを使用します。

en: Logging Ansible output
ja: Ansible 出力のロギング

en: By default Ansible sends output about plays, tasks, and module arguments to your screen (STDOUT) on the control node. If you want to capture Ansible output in a log, you have three options:
ja: デフォルトでは、Ansible はプレイ、タスク、およびモジュール引数の出力を、コントロールノードの画面 (STDOUT) に送信します。Ansible 出力をログに記録する場合は、以下の 3 つのオプションを使用することができます。

en: To save Ansible output in a single log on the control node, set the ``log_path`` :ref:`configuration file setting <intro_configuration>`. You may also want to set ``display_args_to_stdout``, which helps to differentiate similar tasks by including variable values in the Ansible output.
ja: コントロールノードの 1 つのログに Ansible 出力を保存するには、``log_path`` の :ref:`設定ファイルオプション <intro_configuration>` を設定します。``display_args_to_stdout`` を設定すると、Ansible の出力に変数の値を追加し、同様のタスクを区別しやすくなります。

en: To save Ansible output in separate logs, one on each managed node, set the ``no_target_syslog`` and ``syslog_facility`` :ref:`configuration file settings <intro_configuration>`.
ja: 各管理ノードごとに異なるログに Ansible 出力を保存するには、``no_target_syslog`` および ``syslog_facility`` の :ref:`構成ファイル設定 <intro_configuration>` を設定します。

en: To save Ansible output to a secure database, use :ref:`Ansible Tower <ansible_tower>`. Tower allows you to review history based on hosts, projects, and particular inventories over time, using graphs and/or a REST API.
ja: Ansible の出力を安全なデータベースに保存するには、:ref:`Ansible Tower <ansible_tower>` を使用します。Tower を使用すると、グラフや REST API を使用して、ホスト、プロジェクト、および特定のインベントリーに基づいて履歴を確認できます。

en: Protecting sensitive data with ``no_log``
ja: ``no_log`` を使用した機密データの保護

en: If you save Ansible output to a log, you expose any secret data in your Ansible output, such as passwords and user names. To keep sensitive values out of your logs, mark tasks that expose them with the ``no_log: True`` attribute. However, the ``no_log`` attribute does not affect debugging output, so be careful not to debug playbooks in a production environment. See :ref:`keep_secret_data` for an example.
ja: Ansible 出力をログに保存すると、パスワードやユーザー名などの秘密データが Ansible 出力に公開されます。機密性の高い値をログに記録しないようにするには、それらを公開するタスクに、``no_log: True`` 属性で印を付けます。ただし、``no_log`` 属性は、デバッグ出力に影響を与えないため、実稼働環境で Playbook をデバッグしないように注意してください。サンプルは、「:ref:`keep_secret_data`」を参照してください。

en: Ansible Reference: Module Utilities
ja: Ansible 参考資料: モジュールユーティリティー

en: This page documents utilities intended to be helpful when writing Ansible modules in Python.
ja: このページでは、Python で Ansible モジュールを記述するときに役立つユーティリティーについてまとめています。

en: To use this functionality, include ``from ansible.module_utils.basic import AnsibleModule`` in your module.
ja: この機能を使用するには、モジュールに ``from ansible.module_utils.basic import AnsibleModule`` を追加します。

en: Common code for quickly building an ansible module in Python (although you can write modules with anything that can return JSON).
ja: Python で Ansible モジュールを迅速に構築するための一般的なコード (ただし、JSON を返すことができるものならなんでもモジュールを作成できます）。

en: See :ref:`developing_modules_general` for a general introduction and :ref:`developing_program_flow_modules` for more detailed explanation.
ja: 全般の概要は「:ref:`developing_modules_general`」を参照してください。詳細な説明は「:ref:`developing_program_flow_modules`」を参照してください。

en: for results that are files, supplement the info about the file in the return path with stats about the file path.
ja: ファイルの結果については、ファイルパスに関する統計で、リターンパスのファイルに関する情報を補完します。

en: atomically move src to dest, copying attributes from dest, returns true on success it uses os.rename to ensure this as it is an atomic operation, rest of the function is to work around limitations, corner cases and ensure selinux context is saved if possible
ja: src を dest にアトミックに移動し、dest から属性をコピーし、成功すると true を返します。これはアトミック操作であるため、os.rename を使用してこれを確認します。残りの関数は、制限や、めったに発生しない厄介なケースを回避し、可能であれば selinux コンテキストが保存されるようにします。

en: make a date-marked backup of the specified file, return True or False on success or failure
ja: 指定されたファイルの日付マーク付きバックアップを作成し、成功した場合は True、失敗した場合は False を返します

en: Convert the argument to a boolean
ja: 引数をブール値に変換します。

en: Return hex digest of local file for a digest_method specified by name, or None if file is not present.
ja: 名前が指定した digest_method のローカルファイルの 16 進数ダイジェストを返します。ファイルが存在しない場合は None を返します。

en: return from the module, without error
ja: モジュールから返します。エラーはありません。

en: return from the module, with an error message
ja: エラーメッセージを含むモジュールから返します。

en: Takes a path and returns it's mount point
ja: パスを取得し、そのマウントポイントを返します。

en: Parameters
ja: パラメーター

en: a string type with a filesystem path
ja: ファイルシステムパスがある文字列のタイプ

en: Returns
ja: 戻り値

en: the path to the mount point as a text type
ja: テキストタイプとしてのマウントポイントへのパス

en: Find system executable in PATH.
ja: PATH でシステムの実行ファイルを検索します。

en: The executable to find.
ja: 検索する実行ファイル。

en: if executable is not found and required is ``True``, fail_json
ja: 実行ファイルが見つからず、required が ``True`` の場合は、fail_json となります。

en: optional list of directories to search in addition to ``PATH``
ja: ``PATH`` と、検索するディレクトリーのオプションの一覧です。

en: if found return full path; otherwise return None
ja: 見つかった場合はフルパスを返します。見つからない場合は None を返します。

en: is the given path executable?
ja: 指定のパスは実行ファイルですか。

en: The path of the file to check.
ja: 確認するファイルのパス。

en: Limitations:
ja: 制限事項:

en: Does not account for FSACLs.
ja: FSACL を考慮しません。

en: Most times we really want to know "Can the current user execute this file".  This function does not tell us that, only if any execute bit is set.
ja: ほとんどの場合は、「現在のユーザーがこのファイルを実行できるかどうか」を本当に知りたいのです。この関数は、実行ビットが設定されているかどうかだけで、それを知ることはできません。

en: Returns a tuple containing (True, selinux_context) if the given path is on a NFS or other 'special' fs  mount point, otherwise the return will be (False, None).
ja: 指定されたパスが NFS またはその他の「特別な」fs マウントポイント上にある場合は (True, selinux_context) を含むタプルを返し、そうでない場合は (False, None) を返します。

en: many modules deal with files, this encapsulates common options that the file module accepts such that it is directly available to all modules and they can share code.
ja: 多くのモジュールがファイルを扱うため、ファイルモジュールが受け付ける共通のオプションをカプセル化して、すべてのモジュールが直接利用できるようにし、コードを共有できるようにしています。

en: Allows to overwrite the path/dest module argument by providing path.
ja: パスを指定して、パス/dest モジュール引数を上書きできるようにします。

en: Return MD5 hex digest of local file using digest_from_file().
ja: digest_from_file() を使用してローカルファイルの MD5 hex ダイジェストを返します。

en: Do not use this function unless you have no other choice for:
ja: 他の選択肢がない場合は、この機能を使用しないでください。

en: Optional backwards compatibility
ja: 任意の下位互換性

en: Compatibility with a third party protocol
ja: サードパーティープロトコルとの互換性

en: This function will not work on systems complying with FIPS-140-2.
ja: この機能は、FIPS-140-2 に準拠するシステムでは機能しません。

en: Most uses of this function can use the module.sha1 function instead.
ja: この機能の大半は、代わりに module.sha1 関数を使用できます。

en: Copy a file with preserved ownership, permissions and context
ja: 保存済みの所有権、パーミッション、およびコンテキストでファイルをコピーします。

en: Execute a command, returns rc, stdout, and stderr.
ja: コマンドを実行して、rc、stdout、および stderr を返します。

en: is the command to run * If args is a list, the command will be run with shell=False. * If args is a string and use_unsafe_shell=False it will split args to a list and run with shell=False * If args is a string and use_unsafe_shell=True it runs with shell=True.
ja: これは実行するコマンドです * 引数がリストの場合、コマンドは shell=False で実行します。 * 引数が文字列で、use_unsafe_shell=False の場合は、引数をリストに分割して shell=False で実行します * 引数が文字列で use_unsafe_shell=True の場合は、shell=True で実行します。

en: Whether to call fail_json in case of non zero RC. Default False
ja: RC がゼロ以外の場合に fail_json を呼び出すかどうか。デフォルトは False です。

en: See documentation for subprocess.Popen(). Default True
ja: subprocess.Popen() のドキュメントを参照してください。デフォルト は True です。

en: See documentation for subprocess.Popen(). Default None
ja: subprocess.Popen() のドキュメントを参照してください。デフォルトは None です。

en: If given, information to write to the stdin of the command
ja: 指定した場合は、コマンドの stdin に書き込む情報

en: If False, append a newline to the data.  Default False
ja: False の場合は、データに新しい行を追加します。デフォルトは False です。

en: If given, additional path to find the command in. This adds to the PATH environment variable so helper commands in the same directory can also be found
ja: 指定されている場合、コマンドを見つけるための追加のパス。これにより、PATH 環境変数が追加されるため、同じディレクトリー内のヘルパーコマンドも見つけることができます。

en: If given, working directory to run the command inside
ja: 指定した場合は、コマンドを実行する作業ディレクトリー

en: See `args` parameter.  Default False
ja: `args` パラメーターを参照してください (デフォルトは False)。

en: Regex string (not a compiled regex) which can be used to detect prompts in the stdout which would otherwise cause the execution to hang (especially if no input data is specified)
ja: 標準出力内のプロンプトを検出するために使用できる Regex 文字列 (コンパイルされた正規表現ではありません)。そうしないと、実行がハングします (特に入力データが指定されていない場合)。

en: dictionary to *update* os.environ with
ja: os.environ を *更新* するディクショナリー

en: Umask to be used when running the command. Default None
ja: コマンドを実行する際に使用される umask です。デフォルトは None。

en: Since we return native strings, on python3 we need to know the encoding to use to transform from bytes to text.  If you want to always get bytes back, use encoding=None.  The default is "utf-8".  This does not affect transformation of strings given as args.
ja: ネイティブ文字列を返すため、python3 では、バイトからテキストに変換するためのエンコーディングを知る必要があります。常にバイトを返したい場合は、encoding=None を使用してください。デフォルトは「utf-8」です。これは引数として与えられた文字列の変換には影響しません。

en: Since we return native strings, on python3 we need to transform stdout and stderr from bytes to text.  If the bytes are undecodable in the ``encoding`` specified, then use this error handler to deal with them.  The default is ``surrogate_or_strict`` which means that the bytes will be decoded using the surrogateescape error handler if available (available on all python3 versions we support) otherwise a UnicodeError traceback will be raised.  This does not affect transformations of strings given as args.
ja: ネイティブ文字列を返すため、python3 では stdout と stderr をバイトからテキストに変換する必要があります。もしバイトが指定された ``encoding`` でデコードできない場合は、このエラーハンドラを使用して処理します。デフォルトは ``surrogate_or_strict`` で、利用可能であれば surrogateescape エラーハンドラーを使ってバイトがデコードされることを意味します (サポートしている python3 バージョンで利用可能)。これは、引数として与えられた文字列の変換には影響しません。

en: When ``use_unsafe_shell=False`` this argument dictates whether ``~`` is expanded in paths and environment variables are expanded before running the command. When ``True`` a string such as ``$SHELL`` will be expanded regardless of escaping. When ``False`` and ``use_unsafe_shell=False`` no path or variable expansion will be done.
ja: ``use_unsafe_shell=False`` の場合、この引数は、コマンドを実行する前に、パスで ``~`` を展開し、環境変数を展開するかどうかを指示します。``True`` の場合、``$SHELL`` のような文字列は、エスケープに関係なく展開されます。``False`` および``use_unsafe_shell=False`` の場合、パスや変数の展開は行われません。

en: When running on Python 3 this argument dictates which file descriptors should be passed to an underlying ``Popen`` constructor. On Python 2, this will set ``close_fds`` to False.
ja: Python 3 で実行する場合、この引数は ``Popen`` の基礎となるコンストラクターにどのファイル記述子を渡すべきかを指示します。Python 2 では、この引数は ``close_fds`` を False に設定します。

en: This function will be called after ``Popen`` object will be created but before communicating to the process. (``Popen`` object will be passed to callback as a first argument)
ja: この関数は、``Popen`` オブジェクトが作成されると呼び出されますが、プロセスに通信する前に呼び出されます (``Popen`` オブジェクトは最初の引数としてコールバックに渡されます)。

en: This flag indicates whether an invalid ``cwd`` (non-existent or not a directory) should be ignored or should raise an exception.
ja: このフラグは、無効な ``cwd`` (存在しないまたはディレクトリーではない) を無視するべきか、例外を発生させるべきかを示します。

en: A 3-tuple of return code (integer), stdout (native string), and stderr (native string).  On python2, stdout and stderr are both byte strings.  On python3, stdout and stderr are text strings converted according to the encoding and errors parameters.  If you want byte strings on python3, use encoding=None to turn decoding to text off.
ja: リターンコード (整数)、stdout (ネイティブ文字列) 、および stderr (ネイティブ文字列) の 3 つのタプルです。python2 では stdout と stderr はどちらもバイト文字列です。python3 では、stdout と stderr は、encoding パラメーターと errors パラメーターに従って変換されたテキスト文字列です。python3 でバイト文字列にしたい場合は、encoding=None を使用してテキストへのデコードをオフにしてください。

en: Return SHA1 hex digest of local file using digest_from_file().
ja: digest_from_file() を使用してローカルファイルの SHA1 hex ダイジェストを返します。

en: Return SHA-256 hex digest of local file using digest_from_file().
ja: digest_from_file() を使用してローカルファイルの SHA-256 hex ダイジェストを返します。

en: Basic
ja: 基本

en: To use this functionality, include ``import ansible.module_utils.basic`` in your module.
ja: この機能を使用するには、モジュールに ``import ansible.module_utils.basic`` を追加します。

en: **Deprecated**: Use ansible.module_utils.common._utils.get_all_subclasses instead
ja: **非推奨**: 代わりに ansible.module_utils.common._utils.get_all_subclasses を使用します。

en: **Deprecated** Use :py:func:`platform.system` directly.
ja: **非推奨** :py:func:`platform.system` を直接使用します。

en: Name of the platform the module is running on in a native string
ja: モジュールがネイティブ文字列で実行されているプラットフォームの名前

en: Returns a native string that labels the platform ("Linux", "Solaris", etc). Currently, this is the result of calling :py:func:`platform.system`.
ja: プラットフォーム (「Linux」、「Solaris」など) にラベルを付けるネイティブ文字列を返します。現在、これは :py:func:`platform.system` を呼び出した結果になります。

en: Remove strings that look like passwords from log messages
ja: ログメッセージからパスワードのように見える文字列を削除

en: **Deprecated**: Use ansible.module_utils.common.sys_info.get_platform_subclass instead
ja: **非推奨**: 代わりに ansible.module_utils.common.sys_info.get_platform_subclass を使用します。

en: Argument Spec
ja: 引数の仕様

en: Classes and functions for validating parameters against an argument spec.
ja: 引数仕様に対してパラメーターを検証するクラスおよび関数。

en: Argument spec validation class
ja: 引数仕様検証クラス

en: Creates a validator based on the ``argument_spec`` that can be used to validate a number of parameters using the :meth:`validate` method.
ja: :meth:`validate` メソッドを使用して多くのパラメーターを検証するために使用できる ``argument_spec`` に基づいてバリデーターを作成します。

en: Specification of valid parameters and their type. May include nested argument specs.
ja: 有効なパラメーターとそのタイプを指定します。ネストされた引数仕様を含めることができます。

en: List or list of lists of terms that should not be provided together.
ja: まとめて提供すべきでない用語のリスト、またはリストのリスト。

en: List of lists of terms that are required together.
ja: 同時に必要となる用語のリストのリスト。

en: List of lists of terms, one of which in each list is required.
ja: 用語のリストのリスト。各リストに 1 つの用語が必要になります。

en: List of lists of ``[parameter, value, [parameters]]`` where one of ``[parameters]`` is required if ``parameter == value``.
ja: ``parameter == value`` の場合に ``[parameters]`` の 1 つが必要になる ``[parameter, value, [parameters]]`` のリストのリストです。

en: Dictionary of parameter names that contain a list of parameters required by each key in the dictionary.
ja: ディクショナリーの各キーに必要なパラメーター名の一覧が含まれるパラメーター名のディクショナリー。

en: Validate ``parameters`` against argument spec.
ja: 引数仕様に対して ``parameters`` を検証します。

en: Error messages in the :class:`ValidationResult` may contain no_log values and should be sanitized with :func:`~ansible.module_utils.common.parameters.sanitize_keys` before logging or displaying.
ja: :class:`ValidationResult` のエラーメッセージに no_log の値が含まれている可能性があり、ログまたは表示の前に :func:`~ansible.module_utils.common.parameters.sanitize_keys` でサニタイズされるはずです。

en: Parameters to validate against the argument spec
ja: 引数仕様に対して検証するパラメーター

en: :class:`ValidationResult` containing validated parameters.
ja: 検証済みパラメーターが含まれる :class:`ValidationResult`。

en: Simple Example
ja: 簡単な例

en: Result of argument spec validation.
ja: 引数の仕様検証の結果。

en: This is the object returned by :func:`ArgumentSpecValidator.validate() <ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate()>` containing the validated parameters and any errors.
ja: これは、検証したパラメーターおよびエラーが含まれる :func:`ArgumentSpecValidator.validate() <ansible.module_utils.common.arg_spec.ArgumentSpecValidator.validate()>` によって返されるオブジェクトです。

en: Terms to be validated and coerced to the correct type.
ja: 検証され、正しいタイプに強制される用語。

en: :class:`set` of values marked as ``no_log`` in the argument spec. This is a temporary holding place for these values and may move in the future.
ja: 引数仕様で ``no_log`` とマークされた値の :class:`set`。これは、これらの値の一時的な保持となり、今後移動する可能性があります。

en: :class:`~ansible.module_utils.errors.AnsibleValidationErrorMultiple` containing all :class:`~ansible.module_utils.errors.AnsibleValidationError` objects if there were any failures during validation.
ja: 検証中に失敗した場合は、すべての :class:`~ansible.module_utils.errors.AnsibleValidationError` オブジェクトを含む :class:`~ansible.module_utils.errors.AnsibleValidationErrorMultiple`。

en: Validated and coerced parameters.
ja: 検証および強制されたパラメーター。

en: :class:`set` of unsupported parameter names.
ja: サポート対象外のパラメーター名の :class:`set`。

en: :class:`list` of all error messages from each exception in :attr:`errors`.
ja: :attr:`errors` の各例外のすべてのエラーメッセージの :class:`list`。

en: :class:`dict` of type names, such as ``'str'``, and the default function used to check that type, :func:`~ansible.module_utils.common.validation.check_type_str` in this case.
ja: ``'str'`` などｍｐタイプ名の :class:`dict` と、そのタイプの確認に使用されるデフォルトの関数。この場合は :func:`~ansible.module_utils.common.validation.check_type_str` になります。

en: Load value from environment variable
ja: 環境変数からの値を読み込む

en: Remove strings in ``no_log_strings`` from value.
ja: ``no_log_strings`` の文字列を値から削除します。

en: If value is a container type, then remove a lot more.
ja: 値がコンテナータイプである場合は、さらにを削除します。

en: Use of ``deferred_removals`` exists, rather than a pure recursive solution, because of the potential to hit the maximum recursion depth when dealing with large amounts of data (see `issue #24560 <https://github.com/ansible/ansible/issues/24560>`_).
ja: 大量のデータを処理する際に最大再帰深度に達する可能性があるため、純粋な再帰的なソリューションではなく、``deferred_removals`` が使用されます (`issue #24560 <https://github.com/ansible/ansible/issues/24560>`_ を参照)。

en: Sanitize the keys in a container object by removing ``no_log`` values from key names.
ja: ``no_log`` の値をキー名から削除して、コンテナーオブジェクトでキーをサニタイズします。

en: This is a companion function to the :func:`remove_values` function. Similar to that function, we make use of ``deferred_removals`` to avoid hitting maximum recursion depth in cases of large data structures.
ja: これは、:func:`remove_values` 関数のコンパニオン関数です。この関数と同様に、``deferred_removals`` を使用して大きなデータ構造の場合に最大再帰深度に到達しないようにします。

en: The container object to sanitize. Non-container objects are returned unmodified.
ja: サニタイズするコンテナーオブジェクト。非コンテナーオブジェクトは変更されずに返されます。

en: A set of string values we do not want logged.
ja: ログに記録したくない文字列値のセット。

en: A set of string values of keys to not sanitize.
ja: サニタイズしないキーの文字列値のセット。

en: An object with sanitized keys.
ja: サニタイズされたキーを持つオブジェクト。

en: Validation
ja: 検証

en: Standalone functions for validating various parameter types.
ja: さまざまなパラメータータイプを検証するスタンドアロン機能。

en: This is for checking for required params when we can not check via argspec because we need more information than is simply given in the argspec.
ja: これは、単に argspec で指定されるよりも多くの情報が必要なため、argspec を介して確認できない場合に必要なパラメーターを確認するためのものです。

en: Raises :class:`TypeError` if any required parameters are missing
ja: 必要なパラメーターがない場合は :class:`TypeError` を発生させます。

en: Dictionary of parameters
ja: パラメーターのディクショナリー

en: List of parameters to look for in the given parameters.
ja: 指定のパラメーターを検索するパラメーターの一覧。

en: Empty list or raises :class:`TypeError` if the check fails.
ja: 空のリスト (確認に失敗した場合は :class:`TypeError` が発生)

en: Check mutually exclusive terms against argument parameters
ja: 引数パラメーターに対して相互排他的な用語を確認します。

en: Accepts a single list or list of lists that are groups of terms that should be mutually exclusive with one another
ja: 相互に排他的な用語のグループである単一のリストまたはリストのリストを受け入れます。

en: List of mutually exclusive parameters
ja: 相互排他的パラメーターのリスト

en: Check all parameters in argument_spec and return a list of parameters that are required but not present in parameters.
ja: argument_spec 内のすべてのパラメーターを確認し、必須ではあるがパラメーターに存在しないパラメーターのリストを返します。

en: Raises :class:`TypeError` if the check fails
ja: 確認に失敗すると :class:`TypeError` を発生させます。

en: Argument spec dictionary containing all parameters and their specification
ja: すべてのパラメーターとそれらの仕様を含む引数仕様ディクショナリー

en: For each key in requirements, check the corresponding list to see if they exist in parameters.
ja: 要件の各キーについて、対応するリストを確認して、それらがパラメーターに存在するかどうかを確認します。

en: Accepts a single string or list of values for each key.
ja: 各キーに単一の文字列または値のリストを受け入れます。

en: Dictionary of requirements
ja: 要件のディクショナリー

en: Empty dictionary or raises :class:`TypeError` if the
ja: 空のディクショナリー (確認に失敗した場合は :class:`TypeError` が発生)

en: Check parameters that are conditionally required
ja: 条件付きで必要なパラメーターを確認します。

en: List of lists specifying a parameter, value, parameters required when the given parameter is the specified value, and optionally a boolean indicating any or all parameters are required.
ja: パラメーター、値、指定されたパラメーターが指定された値である場合に必要なパラメーター、ならびに必要に応じて一部またはすべてのパラメーターが必要であることを示すブール値を指定するリストのリスト。

en: Example
ja: 例

en: Empty list or raises :class:`TypeError` if the check fails. The results attribute of the exception contains a list of dictionaries. Each dictionary is the result of evaluating each item in requirements. Each return dictionary contains the following keys:      :key missing: List of parameters that are required but missing     :key requires: 'any' or 'all'     :key parameter: Parameter name that has the requirement     :key value: Original value of the parameter     :key requirements: Original required parameters  :Example:  .. code-block:: python      [         {             'parameter': 'someint',             'value': 99             'requirements': ('bool_param', 'string_param'),             'missing': ['string_param'],             'requires': 'all',         }     ]
ja: 空のリスト (確認に失敗した場合は :class:`TypeError` が発生)。例外の結果属性には、ディクショナリーのリストが含まれます。各ディクショナリーは、要件内の各項目を評価した結果です。それぞれの戻り値のディクショナリーには、以下のキーが含まれます:      :key missing: 必須であるにもかかわらず、欠落しているパラメーターのリスト     :key requires: 「any」または「all」     :key parameter: 要件を満たすパラメーター名     :key value: パラメーターの元の値     :key requirements: 元の必須パラメーター  :例:  .. code-block:: python      [         {             'parameter': 'someint',             'value': 99             'requirements': ('bool_param', 'string_param'),             'missing': ['string_param'],             'requires': 'all',         }     ]

en: Empty list or raises :class:`TypeError` if the check fails. The results attribute of the exception contains a list of dictionaries. Each dictionary is the result of evaluating each item in requirements. Each return dictionary contains the following keys:
ja: 空のリスト (確認に失敗した場合は :class:`TypeError` が発生)。例外の結果属性には、ディクショナリーのリストが含まれます。各ディクショナリーは、要件内の各項目を評価した結果です。それぞれの戻り値のディクショナリーには、以下のキーが含まれます。

en: List of parameters that are required but missing
ja: 必須であるにもかかわらず、欠落しているパラメーターのリスト

en: 'any' or 'all'
ja: 「any」または「all」

en: Parameter name that has the requirement
ja: 要件を満たすパラメーター名

en: Original value of the parameter
ja: パラメーターの元の値

en: Original required parameters
ja: 元の必須パラメーター

en: Check each list of terms to ensure at least one exists in the given module parameters
ja: 用語の各リストを確認して、指定されたモジュールパラメーターに少なくとも 1 つが存在することを確認してください。

en: Accepts a list of lists or tuples
ja: リストまたはタプルの一覧を受け入れます。

en: List of lists of terms to check. For each list of terms, at least one is required.
ja: 確認する用語リストのリスト。用語の各リストに対して、少なくとも 1 つが必要です。

en: List of strings of parent key names if ``terms`` are in a sub spec.
ja: ``terms`` がサブ仕様にある場合は、親キー名の文字列のリスト。

en: Check each list of terms to ensure every parameter in each list exists in the given parameters.
ja: 用語の各リストを確認して、各リストのすべてのパラメーターが指定されたパラメーターに存在することを確認してください。

en: Accepts a list of lists or tuples.
ja: リストまたはタプルのリストを受け入れます。

en: List of lists of terms to check. Each list should include parameters that are all required when at least one is specified in the parameters.
ja: 確認する用語リストのリスト。各リストには、パラメーターで少なくとも 1 つが指定されている場合に必要なすべてのパラメーターを含める必要があります。

en: Convert a human-readable string bits value to bits in integer.
ja: 人間が判読できる文字列ビットの値を整数のビットに変換します。

en: Example: ``check_type_bits('1Mb')`` returns integer 1048576.
ja: 例: ``check_type_bits('1Mb')`` は整数 1048576 を返します。

en: Raises :class:`TypeError` if unable to covert the value.
ja: 値を非表示にできない場合は :class:`TypeError` を発生させます。

en: Verify that the value is a bool or convert it to a bool and return it.
ja: 値がブール値であることを確認するか、ブールに変換して返します。

en: Raises :class:`TypeError` if unable to convert to a bool
ja: 値をブール値に変換できない場合は :class:`TypeError` を発生させます。

en: String, int, or float to convert to bool. Valid booleans include: '1', 'on', 1, '0', 0, 'n', 'f', 'false', 'true', 'y', 't', 'yes', 'no', 'off'
ja: ブール値に変換する文字列、整数、浮動小数点。有効なブール値には、'1'、'on'、1、'0'、0、'n'、'f'、'false'、'true'、'y'、't'、'yes'、'no'、'off' が含まれます。

en: Boolean True or False
ja: ブール値 True または False

en: Convert a human-readable string value to bytes
ja: 人間が判読できる文字列の値をバイトに変換します。

en: Raises :class:`TypeError` if unable to covert the value
ja: 値を非表示にできない場合は :class:`TypeError` を発生させます。

en: Verify that value is a dict or convert it to a dict and return it.
ja: 値がディクショナリーであることを確認するか、これをディクショナリーに変換して、返します。

en: Raises :class:`TypeError` if unable to convert to a dict
ja: 値をディクショナリーに変換できない場合は :class:`TypeError` を発生させます。

en: Dict or string to convert to a dict. Accepts ``k1=v2, k2=v2``.
ja: ディクショナリーに変換するディクショナリーまたは文字列。``k1=v2, k2=v2`` を使用できます。

en: value converted to a dictionary
ja: ディクショナリーに変換された値

en: Verify that value is a float or convert it to a float and return it
ja: 値が浮動小数点であることを確認するか、これを浮動小数点に変換して、返します。

en: Raises :class:`TypeError` if unable to convert to a float
ja: 値を浮動小数点に変換できない場合は :class:`TypeError` を発生させます。

en: float, int, str, or bytes to verify or convert and return.
ja: 検証または変換して返す浮動小数点、整数、文字列、またはバイト。

en: float of given value.
ja: 指定された値の浮動小数点。

en: Verify that the value is an integer and return it or convert the value to an integer and return it
ja: 値が整数であることを確認して返すか、値を整数に変換して返します。

en: Raises :class:`TypeError` if unable to convert to an int
ja: 値を整数に変換できない場合は :class:`TypeError` を発生させます。

en: String or int to convert of verify
ja: 検証の変換を行う文字列または整数

en: int of given value
ja: 指定された値の int

en: Return a jsonified string. Sometimes the controller turns a json string into a dict/list so transform it back into json here
ja: json 化された文字列を返します。コントローラーが json 文字列をディクショナリーまたはリストに変換する場合があるため、ここで json に変換し直してください。

en: Verify that the value is a list or convert to a list
ja: 値がリストであるか、またはリストに変換されていることを確認します。

en: A comma separated string will be split into a list. Raises a :class:`TypeError` if unable to convert to a list.
ja: コンマ区切りの文字列はリストに分割されます。リストにに変換できない場合は :class:`TypeError` を発生させます。

en: Value to validate or convert to a list
ja: リストを検証または変換する値

en: Original value if it is already a list, single item list if a float, int, or string without commas, or a multi-item list if a comma-delimited string.
ja: すでにリストである場合は元の値。浮動小数点、int、またはコンマのない文字列の場合は単一項目のリスト。コンマ区切りの文字列の場合は複数項目のリスト。

en: Verify the provided value is a string or convert it to a string, then return the expanded path
ja: 指定された値が文字列であることを確認するか、文字列に変換してから、展開されたパスを返します

en: Returns the raw value
ja: 生の値を返します。

en: Verify that the value is a string or convert to a string.
ja: 値が文字列であることを確認するか、これを文字列に変換します。

en: Since unexpected changes can sometimes happen when converting to a string, ``allow_conversion`` controls whether or not the value will be converted or a TypeError will be raised if the value is not a string and would be converted
ja: 文字列への変換時に予期せぬ変更が生じる可能性があるため、``allow_conversion`` は、値が変換されるかどうか、または値が文字列でなければ TypeError が発生させ、変換するかどうかを制御します。

en: Value to validate or convert to a string
ja: 検証または文字列に変換する値

en: Whether to convert the string and return it or raise a TypeError
ja: 文字列を変換して返すか、TypeError を発生させるか

en: Original value if it is a string, the value converted to a string if allow_conversion=True, or raises a TypeError if allow_conversion=False.
ja: 文字列の場合は元の値。allow_conversion=True の場合は値を文字列に変換し、allow_conversion=False の場合は TypeError を発生させます。

en: Count the number of occurrences of a key in a given dictionary
ja: 特定のディクショナリーでキーの発生回数をカウントします。

en: String or iterable of values to check
ja: 確認する値の文字列または反復可能

en: An integer that is the number of occurrences of the terms values in the provided dictionary.
ja: 提供されたディクショナリーでの用語の値の出現回数を表す整数。

en: Errors
ja: エラー

en: Fallback validator was not found
ja: フォールバックバリデーターが見つかりませんでした

en: Single argument spec validation error
ja: 単一の引数の仕様検証エラー

en: The error message passed in when the exception was raised.
ja: 例外が発生したときに渡されたエラーメッセージ。

en: Multiple argument spec validation errors
ja: 複数の引数仕様検証エラー

en: :class:`list` of :class:`AnsibleValidationError` objects
ja: :class:`AnsibleValidationError` オブジェクトの :class:`list`

en: The first message from the first error in ``errors``.
ja: ``errors`` の最初のエラーからの最初のメッセージ。

en: :class:`list` of each error message in ``errors``.
ja: ``errors`` の各エラーメッセージの :class:`list`。

en: Append a new error to ``self.errors``.
ja: ``self.errors`` に新しいエラーを追加します。

en: Only :class:`AnsibleValidationError` should be added.
ja: :class:`AnsibleValidationError` だけを追加する必要があります。

en: Append each item in ``errors`` to ``self.errors``. Only :class:`AnsibleValidationError` should be added.
ja: ``errors`` の各アイテムを ``self.errors`` に追加します。:class:`AnsibleValidationError` のみを追加する必要があります。

en: Error handling aliases
ja: エイリアスの処理中のエラー

en: Error with parameter type
ja: パラメータータイプのエラー

en: Error with parameter value
ja: パラメーター値のエラー

en: Error when validating elements
ja: 要素検証時のエラー

en: Mutually exclusive parameters were supplied
ja: 相互に排他的なパラメーターが指定されています

en: Error converting no_log values
ja: no_log 値の変換エラー

en: Error with parameters that are required by other parameters
ja: 他のパラメーターで必要なパラメーターでエラー

en: A required parameter was assigned a default value
ja: 必須パラメーターにデフォルト値が割り当てられています

en: Missing a required parameter
ja: 必須パラメーターがありません

en: Error with conditionally required parameters
ja: 条件的必須パラメーターのエラー

en: Error with parameters where at least one is required
ja: 最低 1 つは必要なパラメーターに関するエラー

en: Error with parameters that are required together
ja: 同時に必要となるパラメーターに関するエラー

en: Incorrect type for subparameter
ja: サブパラメーターの型が正しくありません

en: Unsupported parameters were supplied
ja: サポートされていないパラメーターが指定されました

en: Playbook Keywords
ja: Playbook キーワード

en: These are the keywords available on common playbook objects. Keywords are one of several sources for configuring Ansible behavior. See :ref:`general_precedence_rules` for details on the relative precedence of each source.
ja: これらのキーワードは、一般的な Playbook オブジェクトで利用できます。キーワードは、Ansible の動作を設定する複数のソースのいずれかです。各ソースの相対優先順位に関する詳細は、「:ref:`general_precedence_rules`」を参照してください。

en: Please note:
ja: 注意:

en: Aliases for the directives are not reflected here, nor are mutable one. For example, :term:`action` in task can be substituted by the name of any Ansible module.
ja: ディレクティブのエイリアスはここでは反映されておらず、変更可能なものでもありません。たとえば、タスクの :term:`action` は、Ansible モジュールの名前に置き換えられます。

en: The keywords do not have ``version_added`` information at this time
ja: 現時点ではキーワードに ``version_added`` 情報がありません

en: Some keywords set defaults for the objects inside of them rather than for the objects themselves
ja: キーワードによっては、オブジェクト自体ではなく、オブジェクト内にデフォルトを設定するものもあります。

en: Play
ja: プレイ

en: Force any un-handled task errors on any host to propagate to all hosts and end the play.
ja: ホストで処理されていないタスクエラーを強制的に実行し、すべてのホストに伝播してプレイを終了します。

en: Boolean that controls if privilege escalation is used or not on :term:`Task` execution. Implemented by the become plugin. See :ref:`become_plugins`.
ja: :term:`Task` 実行時に特権昇格が使用されるかどうかを制御するブール値。become プラグインによって実装されます。「:ref:`become_plugins`」を参照してください。

en: Path to the executable used to elevate privileges. Implemented by the become plugin. See :ref:`become_plugins`.
ja: 権限の昇格に使用する実行可能ファイルへのパス。become プラグインによって実装されます。「:ref:`become_plugins`」を参照してください。

en: A string of flag(s) to pass to the privilege escalation program when :term:`become` is True.
ja: :term:`become` が True の場合に特権昇格プログラムに渡すフラグの文字列。

en: Which method of privilege escalation to use (such as sudo or su).
ja: 使用する権限昇格の方法 (sudo、su など)。

en: User that you 'become' after using privilege escalation. The remote/login user must have permissions to become this user.
ja: 特権昇格を使用した後に「become」となるユーザーです。リモート/ログインユーザーには、このユーザーになる (become) ためのパーミッションが必要です。

en: A boolean that controls if a task is executed in 'check' mode. See :ref:`check_mode_dry`.
ja: 「check」モードでタスクが実行されるかどうかを制御するブール値。「:ref:`check_mode_dry`」を参照してください。

en: List of collection namespaces to search for modules, plugins, and roles. See :ref:`collections_using_playbook`
ja: モジュール、プラグイン、およびロールを検索するコレクション名前空間の一覧。「:ref:`collections_using_playbook`」を参照してください。

en: Tasks within a role do not inherit the value of ``collections`` from the play. To have a role search a list of collections, use the ``collections`` keyword in ``meta/main.yml`` within a role.
ja: ロール内のタスクは、プレイから ``collections`` の値を継承しません。ロール検索でコレクションの一覧を取得するには、ロール内で ``meta/main.yml`` の ``collections`` キーワードを使用します。

en: Allows you to change the connection plugin used for tasks to execute on the target. See :ref:`using_connection`.
ja: ターゲットで実行するタスクに使用される connection プラグインを変更できます。「:ref:`using_connection`」を参照してください。

en: Enable debugging tasks based on state of the task result. See :ref:`playbook_debugger`.
ja: タスク結果の状態に基づいて、デバッグタスクを有効にします。「:ref:`playbook_debugger`」を参照してください。

en: Toggle to make tasks return 'diff' information or not.
ja: タスクが「diff」情報を返すように切り替えます。

en: A dictionary that gets converted into environment vars to be provided for the task upon execution. This can ONLY be used with modules. This isn't supported for any other type of plugins nor Ansible itself nor its configuration, it just sets the variables for the code responsible for executing the task. This is not a recommended way to pass in confidential data.
ja: 実行時に、タスク用に提供された環境変数に変換されるディクショナリー。これは、モジュールでのみ使用できます。これは、他のタイプのプラグインや Ansible 自体、その設定ではサポートされていません。タスクの実行を担当するコードの変数だけを設定します。これは、機密性の高いデータに渡すための推奨方法ではありません。

en: Set the fact path option for the fact gathering plugin controlled by :term:`gather_facts`.
ja: :term:`gather_facts` が制御するファクト収集プラグインのファクトパスオプションを設定します。

en: Will force notified handler execution for hosts even if they failed during the play. Will not trigger if the play itself fails.
ja: プレイ中に失敗した場合でも、ホストの通知ハンドラー実行を強制的に実行します。プレイ自体が失敗した場合は発生しません。

en: A boolean that controls if the play will automatically run the 'setup' task to gather facts for the hosts.
ja: プレイが自動的に「setup」タスクを実行してホストのファクトを収集するかどうかを制御するブール値。

en: Allows you to pass subset options to the  fact gathering plugin controlled by :term:`gather_facts`.
ja: :term:`gather_facts` が制御するファクト収集プラグインにサブセットオプションを渡すことができます。

en: Allows you to set the timeout for the fact gathering plugin controlled by :term:`gather_facts`.
ja: :term:`gather_facts` が制御するファクト収集プラグインのタイムアウトを設定できます。

en: A section with tasks that are treated as handlers, these won't get executed normally, only when notified after each section of tasks is complete. A handler's `listen` field is not templatable.
ja: ハンドラーとして扱われるタスクが含まれるセクションは、タスクの各セクションの完了後に通知される場合にのみ、通常どおり実行されません。ハンドラーの `listen` フィールドはテンプレート化できません。

en: A list of groups, hosts or host pattern that translates into a list of hosts that are the play's target.
ja: プレイのターゲットであるホストの一覧に変換するグループ、ホスト、またはホストパターンの一覧。

en: Boolean that allows you to ignore task failures and continue with play. It does not affect connection errors.
ja: タスクの失敗を無視してプレイを続行できるブール値。接続エラーには影響を及ぼしません。

en: Boolean that allows you to ignore task failures due to an unreachable host and continue with the play. This does not affect other task errors (see :term:`ignore_errors`) but is useful for groups of volatile/ephemeral hosts.
ja: 到達不可能なホストが原因でタスクの失敗を無視し、プレイを続行できるブール値。これは他のタスクエラーには影響を与えません (「:term:`ignore_errors`」参照)。揮発性/一時ホストのグループに役に立ちます。

en: can be used to abort the run after a given percentage of hosts in the current batch has failed. This only wokrs on linear or linear derived strategies.
ja: 現在のバッチ内の特定の割合のホストに障害が発生した後、実行を中止するために使用できます。これは、線形または線形派生戦略にのみ影響します。

en: Specifies default parameter values for modules.
ja: モジュールのデフォルトパラメーター値を指定します。

en: Identifier. Can be used for documentation, or in tasks/handlers.
ja: 識別子。ドキュメントまたはタスク/ハンドラーに使用することができます。

en: Boolean that controls information disclosure.
ja: 情報の公開を制御するブール値。

en: Controls the sorting of hosts as they are used for executing the play. Possible values are inventory (default), sorted, reverse_sorted, reverse_inventory and shuffle.
ja: プレイの実行に使用するホストのソートを制御します。使用できる値は、inventory (デフォルト)、sorted、reverse_sorted、reverse_inventory、および shuffle です。

en: Used to override the default port used in a connection.
ja: 接続で使用されるデフォルトのポートを上書きするのに使用します。

en: A list of tasks to execute after the :term:`tasks` section.
ja: :term:`tasks` セクションの後に実行するタスクの一覧。

en: A list of tasks to execute before :term:`roles`.
ja: :term:`roles` の前に実行するタスクの一覧。

en: User used to log into the target via the connection plugin.
ja: connection プラグインでターゲットにログインするのに使用するユーザー。

en: List of roles to be imported into the play
ja: プレイにインポートするロールの一覧

en: Boolean that will bypass the host loop, forcing the task to attempt to execute on the first host available and afterwards apply any results and facts to all active hosts in the same batch.
ja: ホストループを回避するブール値。タスクは、使用可能な最初のホストで実行を試行し、その後、同じバッチ内のすべてのアクティブなホストに結果とファクトを適用します。

en: Explicitly define how Ansible batches the execution of the current play on the play's target
ja: Ansible が、プレイのターゲットで現在のプレイの実行をバッチ処理する方法を明示的に定義します。

en: Allows you to choose the connection plugin to use for the play.
ja: プレイに使用する connection プラグインを選択できます。

en: Tags applied to the task or included tasks, this allows selecting subsets of tasks from the command line.
ja: タスクまたは含まれるタスクに適用されるタグ。これにより、コマンドラインからタスクのサブセットを選択できます。

en: Main list of tasks to execute in the play, they run after :term:`roles` and before :term:`post_tasks`.
ja: プレイで実行するタスクの主な一覧。:term:`roles` から :term:`post_tasks` の間に実行されます。

en: Limit number of concurrent task runs on task, block and playbook level. This is independent of the forks and serial settings, but cannot be set higher than those limits. For example, if forks is set to 10 and the throttle is set to 15, at most 10 hosts will be operated on in parallel.
ja: タスク、ブロック、および Playbook レベルで実行される同時タスクの数を制限します。これはフォークとシリアル設定とは独立していますが、このような制限よりも高く設定することはできません。たとえば、フォークを 10 に設定し、スロットルが 15 に設定すると、ほぼ 10 台のホストを並行して操作します。

en: Time limit for task to execute in, if exceeded Ansible will interrupt and fail the task.
ja: 実行するタスクの時間制限。これを超えると、Ansible が割り込みし、タスクが失敗します。

en: Dictionary/map of variables
ja: 変数のディクショナリー/マップ

en: List of files that contain vars to include in the play.
ja: プレイに含まれる vars が含まれるファイルの一覧。

en: list of variables to prompt for.
ja: プロンプトする変数の一覧。

en: Role
ja: ロール

en: Boolean that allows you to apply facts to a delegated host instead of inventory_hostname.
ja: inventory_hostname の代わりに委譲されたホストにファクトを適用できるようにするブール値。

en: Host to execute task instead of the target (inventory_hostname). Connection vars from the delegated host will also be used for the task.
ja: ターゲットの代わりにタスクを実行するホスト (inventory_hostname)。委譲されたホストからの接続変数もタスクに使用されます。

en: Conditional expression, determines if an iteration of a task is run or not.
ja: 条件式。タスクの反復を実行するかどうかを決定します。

en: Block
ja: ブロック (Block)

en: List of tasks, in a block, that execute no matter if there is an error in the block or not.
ja: ブロックにエラーがあるかどうかに関係なく実行される、ブロック内のタスクのリスト。

en: List of tasks in a block.
ja: ブロック内のタスクの一覧。

en: List of handlers to notify when the task returns a 'changed=True' status.
ja: タスクが「changed=True」の状態を返す際に通知するハンドラーのリスト。

en: List of tasks in a :term:`block` that run if there is a task error in the main :term:`block` list.
ja: メインの :term:`block` 一覧にタスクエラーがある場合に実行される :term:`block` 内のタスクの一覧。

en: The 'action' to execute for a task, it normally translates into a C(module) or action plugin.
ja: タスクで実行する「アクション」は、通常 C(module) または action プラグインに変換されます。

en: A secondary way to add arguments into a task. Takes a dictionary in which keys map to options and values.
ja: 引数をタスクに追加するセカンダリー方法。キーをオプションおよび値にマップするディクショナリーを作成します。

en: Run a task asynchronously if the C(action) supports this; value is maximum runtime in seconds.
ja: C(action) がこれをサポートする場合はタスクを非同期に実行します。値は、最大ランタイム (秒単位) です。

en: Conditional expression that overrides the task's normal 'changed' status.
ja: タスクの通常の「changed」状態を上書きする条件式。

en: Number of seconds to delay between retries. This setting is only used in combination with :term:`until`.
ja: 再試行の間隔の遅延秒数。この設定は :term:`until` と組み合わせてのみ使用されます。

en: Conditional expression that overrides the task's normal 'failed' status.
ja: タスクの通常の「failed」状態を上書きする条件式。

en: Same as action but also implies ``delegate_to: localhost``
ja: アクションと同じですが、``delegate_to: localhost`` という意味を含みます。

en: Takes a list for the task to iterate over, saving each list element into the ``item`` variable (configurable via loop_control)
ja: タスクのリストを取り、各リスト要素を ``item`` 変数に保存します (loop_control で設定可能)。

en: Several keys here allow you to modify/set loop behaviour in a task.
ja: ここにあるいくつかのキーを使用すると、タスクのループ動作を変更/設定できます。

en: Sets the polling interval in seconds for async tasks (default 10s).
ja: 非同期タスク (デフォルトは 10) のポーリング間隔を秒単位で設定します。

en: Name of variable that will contain task status and module return data.
ja: タスクステータスとモジュールリターンデータが含まれる変数の名前。

en: Number of retries before giving up in a :term:`until` loop. This setting is only used in combination with :term:`until`.
ja: :term:`until` ループで断念するまでの再試行回数。この設定は :term:`until` と組み合わせる場合にのみ使用されます。

en: This keyword implies a ':term:`retries` loop' that will go on until the condition supplied here is met or we hit the :term:`retries` limit.
ja: このキーワードは、ここで提供された条件が満たされるまで、または :term:`retries` の制限に到達するまで実行される ':term:`retries` loop' を意味します。

en: The same as ``loop`` but magically adds the output of any lookup plugin to generate the item list.
ja: ``loop`` と同じですが、アイテム一覧を生成するために lookup プラグインの出力が視覚的に追加されます。

en: Python 3 Support
ja: Python 3 サポート

en: Ansible 2.5 and above work with Python 3. Previous to 2.5, using Python 3 was considered a tech preview.  This topic discusses how to set up your controller and managed machines to use Python 3.
ja: Ansible 2.5 以降では Python 3 を使用しますが、Python 3 を使用する Ansible 2.4 以前のバージョンは、テクノロジープレビューとみなされます。以下のトピックでは、Python 3 を使用できるようにコントローラーと管理マシンを設定する方法を説明します。

en: On the controller we support Python 3.5 or greater and Python 2.7 or greater. Module-side, we support Python 3.5 or greater and Python 2.6 or greater.
ja: コントローラーでは、Python 3.5 以降、および Python 2.7 以降をサポートしています。モジュール側では、Python 3.5 以降、Python 2.6 以降をサポートします。

en: On the controller side
ja: コントローラー側

en: The easiest way to run :command:`/usr/bin/ansible` under Python 3 is to install it with the Python3 version of pip.  This will make the default :command:`/usr/bin/ansible` run with Python3:
ja: Python 3 で :command:`/usr/bin/ansible` を最も簡単に実行するには、pip の Python 3 バージョンをインストールします。これでデフォルトで、Python 3 を使用して :command:`/usr/bin/ansible` を実行できます。

en: If you are running Ansible :ref:`from_source` and want to use Python 3 with your source checkout, run your command via ``python3``.  For example:
ja: Ansible :ref:`from_source` を実行していて、ソースのチェックアウトに Python 3 を使用するには、``python3`` でコマンドを実行します。以下に例を示します。

en: Individual Linux distribution packages may be packaged for Python2 or Python3.  When running from distro packages you'll only be able to use Ansible with the Python version for which it was installed.  Sometimes distros will provide a means of installing for several Python versions (via a separate package or via some commands that are run after install).  You'll need to check with your distro to see if that applies in your case.
ja: 個々の Linux ディストリビューションパッケージは、Python2 または Python3 にパッケージ化されます。ディストリビューションから実行する場合は、インストールされている Python バージョンでのみ Ansible を使用できます。障害により、複数の Python バージョン (別のパッケージ、またはインストール後に実行される一部のコマンドを介して) インストールを行う手段が提供されます。

en: Using Python 3 on the managed machines with commands and playbooks
ja: コマンドおよび Playbook を使用した管理マシンでの Python 3 の使用

en: Ansible will automatically detect and use Python 3 on many platforms that ship with it. To explicitly configure a Python 3 interpreter, set the ``ansible_python_interpreter`` inventory variable at a group or host level to the location of a Python 3 interpreter, such as :command:`/usr/bin/python3`. The default interpreter path may also be set in ``ansible.cfg``.
ja: Ansible は、同梱されている多数のプラットフォームで Python 3 を自動的に検出して使用します。Python 3 インタープリターを明示的に設定するには、グループまたはホストレベルで、:command:`/usr/bin/python3` などのように、``ansible_python_interpreter`` のインベントリー変数を Python 3 インタープリターの場所に指定します。デフォルトのインタープリターパスも、``ansible.cfg`` に設定できます。

en: :ref:`interpreter_discovery` for more information.
ja: 詳細は :ref:`interpreter_discovery`

en: :ref:`intro_inventory` for more information.
ja: 詳細は :ref:`intro_inventory`

en: Run your command or playbook:
ja: コマンドまたは Playbook を実行します。

en: Note that you can also use the `-e` command line option to manually set the python interpreter when you run a command.   This can be useful if you want to test whether a specific module or playbook has any bugs under Python 3.  For example:
ja: コマンドの実行時に、`-e` コマンドラインオプションを指定して、手動で Python インタープリターを設定することもできる点に注意してください。これは、Python 3 で固有のモジュールや Playbook にバグが発生しているかをテストする場合に便利です。

en: What to do if an incompatibility is found
ja: 非互換性が見つかった場合の対処方法

en: We have spent several releases squashing bugs and adding new tests so that Ansible's core feature set runs under both Python 2 and Python 3.  However, bugs may still exist in edge cases and many of the modules shipped with Ansible are maintained by the community and not all of those may be ported yet.
ja: Python 2 および Python 3 の両方で Ansible でコアとなる機能が実行できるように、複数リリースにわたってバグ修正や、新規テストが追加されました。ただし、バグは、エッジケースなどでまだ存在する可能性があります。また、Ansible に同梱されている多くのモジュールは、コミュニティーがメンテナンスを実施しており、すべてが移植されているわけではありません。

en: If you find a bug running under Python 3 you can submit a bug report on `Ansible's GitHub project <https://github.com/ansible/ansible/issues/>`_.  Be sure to mention Python3 in the bug report so that the right people look at it.
ja: Python 3 で実行中にバグを発見した場合には、`Ansible の GitHub プロジェクト <https://github.com/ansible/ansible/issues/>`_ からバグ報告を提出してください。適切な担当者が対応できるように、バグ報告には Python3 と記載するようにしてください。

en: If you would like to fix the code and submit a pull request on github, you can refer to :ref:`developing_python_3` for information on how we fix common Python3 compatibility issues in the Ansible codebase.
ja: コードを修正して github へのプル要求を送信する場合は、Ansible コードベースで一般的な Python 3 の互換性の問題を修正する方法は、「:ref:`developing_python_3`」参照してください。

en: Releases and maintenance
ja: リリースおよびメンテナンス

en: Please go to `the devel release and maintenance page <https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html>`_ for up to date information.
ja: 最新の情報については、`devel 版のリリースおよびメンテナンスページ <https://docs.ansible.com/ansible/devel/reference_appendices/release_and_maintenance.html>`_ にアクセスしてください。

en: This link takes you to a different version of the Ansible documentation. Use the version selection on the left or your browser back button to return to this version of the documentation.
ja: このリンクは、Ansible のドキュメントの別バージョンに移動します。左側またはブラウザーの戻るボタンを使用して、このバージョンのドキュメントに戻ります。

en: Guidelines for Ansible core contributors and maintainers
ja: Ansible で中心となる貢献者およびメンテナー向けガイドライン

en: Testing strategies
ja: ストラテジーのテスト

en: Community information and contributing
ja: コミュニティー情報および貢献

en: `Development Mailing List <https://groups.google.com/group/ansible-devel>`_
ja: `開発メーリングリスト <https://groups.google.com/group/ansible-devel>`_

en: Mailing list for development topics
ja: 開発トピックのメーリングリスト

en: Special Variables
ja: 特別な変数

en: Magic variables
ja: マジック変数

en: These variables cannot be set directly by the user; Ansible will always override them to reflect internal state.
ja: マジック変数は、ユーザーが直接設定できません。Ansible がシステム内の状態を反映してこの変数を常にオーバーライドします。

en: Boolean that indicates if we are in check mode or not
ja: チェックモードかどうかを指定するブール値

en: The full path of used Ansible configuration file
ja: Ansbile 設定ファイルに使用するフルパス

en: The names of the roles currently imported into the current play as dependencies of other plays
ja: 他のプレイの依存関係として現在のプレイに現在インポートされているロールの名前

en: Boolean that indicates if we are in diff mode or not
ja: diff モードかどうかを指定するブール値

en: Integer reflecting the number of maximum forks available to this run
ja: 今回の実行で利用可能な最大フォーク数 (整数)

en: List of sources used as inventory
ja: インベントリーとして使用されるソースの一覧

en: Contents of the ``--limit`` CLI option for the current execution of Ansible
ja: Ansible の現在の実行に対して、CLI オプション ``--limit`` として指定する内容

en: A dictionary/map containing extended loop information when enabled via ``loop_control.extended``
ja: ``loop_control.extended`` で有効にした場合に loop の拡張情報を含むディクショナリー/マップ

en: The name of the value provided to ``loop_control.loop_var``. Added in ``2.8``
ja: ``loop_control.loop_var`` に渡す値の名前。``2.8`` に追加。

en: The name of the value provided to ``loop_control.index_var``. Added in ``2.9``
ja: ``loop_control.index_var`` に渡す値の名前。``2.9`` に追加。

en: When the current role is being executed by means of an :ref:`include_role <include_role_module>` or :ref:`import_role <import_role_module>` action, this variable contains a list of all parent roles, with the most recent role (in other words, the role that included/imported this role) being the first item in the list. When multiple inclusions occur, this list lists the *last* role (in other words, the role that included this role) as the *first* item in the list. It is also possible that a specific role exists more than once in this list.
ja: 現在のロールが、:ref:`include_role <include_role_module>` アクションまたは :ref:`import_role <import_role_module>` アクションによって実行されている場合、この変数にはすべての親ロールのリストが含まれ、最新のロール (つまり、このロールを含む/インポートしたロール) がリストの最初の項目になります。複数の包含が発生する場合、このリストには、*最後の*ロール (つまり、このロールを含むロール) がリストの*最初の*項目として挙げられます。このリストに特定の役割が複数存在する可能性もあります。

en: For example: When role **A** includes role **B**, inside role B, ``ansible_parent_role_names`` will equal to ``['A']``. If role **B** then includes role **C**, the list becomes ``['B', 'A']``.
ja: たとえば、ロール **A** にロール **B** が含まれる場合は、ロール B 内の ``ansible_parent_role_names`` は ``['A']`` と等しくなります。次にロール **B** にロール **C** が含まれると、一覧は ``['B', 'A']`` になります。

en: When the current role is being executed by means of an :ref:`include_role <include_role_module>` or :ref:`import_role <import_role_module>` action, this variable contains a list of all parent roles, with the most recent role (in other words, the role that included/imported this role) being the first item in the list. Please refer to ``ansible_parent_role_names`` for the order of items in this list.
ja: 現在のロールが :ref:`include_role <include_role_module>` アクションまたは :ref:`import_role <import_role_module>` アクションで実行されていると、この変数には親のロールの全一覧と、その一覧の最初の項目である最新のロール (つまり、このロールを追加/インポートしたロール) が含まれます。このリストの項目の順序は、「``ansible_parent_role_names``」を参照してください。

en: List of active hosts in the current play run limited by the serial, aka 'batch'. Failed/Unreachable hosts are not considered 'active'.
ja: シリアルで制限される現在のプレイ実行に含まれるアクティブなホスト一覧 (「バッチ」と呼ばれます)。失敗したホストや到達不可能なホストは、「アクティブ」とはみなされません。

en: List of hosts in the current play run, not limited by the serial. Failed/Unreachable hosts are excluded from this list.
ja: 現在のプレイのホスト一覧は、シリアルによって制限されません。失敗したホストまたは到達不可能なホストはこの一覧から除外されます。

en: List of all the hosts that were targeted by the play
ja: プレイが対象としたホストの一覧

en: The names of the roles currently imported into the current play. This list does **not** contain the role names that are implicitly included via dependencies.
ja: 現在のプレイにインポートされているロール名。この一覧には、依存関係で暗黙的に含まれるロール名は **含まれません**。

en: The path to the python interpreter being used by Ansible on the controller
ja: Ansible が使用する Python インタープリターへのコントローラー上のパス

en: The names of the roles currently imported into the current play, or roles referenced as dependencies of the roles imported into the current play.
ja: 現在のプレイに現在インポートされているロール名、または現在のプレイにインポートされているロールの依存関係として参照されているロール名

en: The fully qualified collection role name, in the format of ``namespace.collection.role_name``
ja: ``namespace.collection.role_name`` の形式である完全修飾コレクションのロール名

en: The name of the collection the task that is executing is a part of. In the format of ``namespace.collection``
ja: 実行しているタスクが一部であるコレクションの名前 (``namespace.collection`` の形式)。

en: Contents of the ``--tags`` CLI option, which specifies which tags will be included for the current run. Note that if ``--tags`` is not passed, this variable will default to ``["all"]``.
ja: CLI オプション ``--tags`` の内容。現在の実行に含まれるタグを指定します。``--tags`` が渡されない場合、この変数はデフォルトで ``["all"]`` になります。

en: Current search path for action plugins and lookups, in other words, where we search for relative paths when you do ``template: src=myfile``
ja: action プラグインとルックアップの現在の検索パス。つまり、``template: src=myfile`` を指定したときに検索する相対パスです。

en: Contents of the ``--skip-tags`` CLI option, which specifies which tags will be skipped for the current run.
ja: 現在の実行で省略するタグを指定する ``--skip-tags`` CLI オプションの内容。

en: Current verbosity setting for Ansible
ja: Ansible の現在の詳細レベル設定

en: Dictionary/map that contains information about the current running version of ansible, it has the following keys: full, major, minor, revision and string.
ja: 現在実行している Ansible のバージョンに関する情報を含むディクショナリー/マップ。full、major、minor、revision、string などのキーが含まれます。

en: List of groups the current host is part of
ja: 現在のホストが所属するグループの一覧

en: A dictionary/map with all the groups in inventory and each group has the list of hosts that belong to it
ja: インベントリー内の全グループを含むディクショナリー/マップ。各グループには、所属するホストの一覧が含まれます。

en: A dictionary/map with all the hosts in inventory and variables assigned to them
ja: インベントリー内の全ホスト、そのホストに割当てられた変数を含むディクショナリー/マップ。

en: The inventory name for the 'current' host being iterated over in the play
ja: プレイで繰り返される「現在」のホストのイベントリー名

en: The short version of `inventory_hostname`
ja: `inventory_hostname` の短縮版

en: The directory of the inventory source in which the `inventory_hostname` was first defined
ja: `inventory_hostname` を最初に定義したインベントリーソースのディレクトリー

en: The file name of the inventory source in which the `inventory_hostname` was first defined
ja: `inventory_hostname` を最初に定義したインベントリーソースのファイル名

en: Special variable that allows you to 'omit' an option in a task, for example ``- user: name=bob home={{ bobs_home|default(omit) }}``
ja: タスクのオプションを「省略」できるようにする特別変数 (つまり ``- user: name=bob home={{ bobs_home|default(omit) }}``)

en: Deprecated, the same as ansible_play_batch
ja: 非推奨。ansible_play_batch と同じです。

en: The name of the currently executed play. Added in ``2.8``. (`name` attribute of the play, not file name of the playbook.)
ja: 現在実行されたプレイの名前です。``2.8`` で追加されました (Playbook のファイル名ではなく、プレイの`name` 属性)。

en: The path to the directory of the playbook that was passed to the ``ansible-playbook`` command line.
ja: ``ansible-playbook`` コマンドラインに渡した Playbook のディレクトリーへのパス

en: The name of the role currently being executed.
ja: 現在実行中のロール名。

en: Deprecated, the same as ansible_play_role_names
ja: 非推奨。ansible_play_role_names と同じです。

en: The path to the dir of the currently running role
ja: 現在実行中のロールのディレクトリーへのパス

en: These are variables that contain information pertinent to the current host (`inventory_hostname`). They are only available if gathered first. See :ref:`vars_and_facts` for more information.
ja: これは、現在のホストに関連する情報を含む変数です (`inventory_hostname`)。この変数は、最初に収集した場合にのみ利用できます。詳細は、「:ref:`vars_and_facts`」を参照してください。

en: Contains any facts gathered or cached for the `inventory_hostname` Facts are normally gathered by the :ref:`setup <setup_module>` module automatically in a play, but any module can return facts.
ja: `inventory_hostname` 向けに収集またはキャッシュしたファクトが含まれます。ファクトは通常、プレイで自動的に :ref:`setup <setup_module>` モジュールにより収集されますが、どのモジュールでもファクトを返すことができます。

en: Contains any 'local facts' gathered or cached for the `inventory_hostname`. The keys available depend on the custom facts created. See the :ref:`setup <setup_module>` module and :ref:`local_facts` for more details.
ja: `inventory_hostname` が収集またはキャッシュする「ローカルファクト」が含まれます。利用可能なキーは、作成したカスタムファクトによって異なります。詳細は、:ref:`setup <setup_module>` モジュールおよび :ref:`local_facts` モジュールを参照してください。

en: Connection variables
ja: 接続変数

en: Connection variables are normally used to set the specifics on how to execute actions on a target. Most of them correspond to connection plugins, but not all are specific to them; other plugins like shell, terminal and become are normally involved. Only the common ones are described as each connection/become/shell/etc plugin can define its own overrides and specific variables. See :ref:`general_precedence_rules` for how connection variables interact with :ref:`configuration settings<ansible_configuration_settings>`, :ref:`command-line options<command_line_tools>`, and :ref:`playbook keywords<playbook_keywords>`.
ja: 接続変数は通常、ターゲットでのアクション実行方法を具体的に設定する時に使用します。接続変数の大半が connection プラグインに対応していますが、connection プラグイン固有のものではなく、通常は shell、terminal、become などの他のプラグインも使用します。各 connection/become/shell/etc プラグインは、自身のオーバーライドや固有の変数を定義するため、一般的なもののみを説明します。接続変数が :ref:`configuration settings<ansible_configuration_settings>`、:ref:`command-line options<command_line_tools>`、および :ref:`playbook keywords<playbook_keywords>` と対話する方法は、「:ref:`general_precedence_rules`」を参照してください。

en: The user Ansible 'becomes' after using privilege escalation. This must be available to the 'login user'.
ja: 特権昇格後に Ansible がなる (become) ユーザー。このユーザーは、「ログインユーザー」が利用できるようになっている必要があります。

en: The connection plugin actually used for the task on the target host.
ja: ターゲットホストでタスクに実際に使用する connection プラグイン

en: The ip/name of the target host to use instead of `inventory_hostname`.
ja: `inventory_hostname` の代わりに使用するターゲットホストの ip/名前

en: The path to the Python executable Ansible should use on the target host.
ja: Ansible がターゲットホストで使用すべき Python 実行ファイルへのパス

en: The user Ansible 'logs in' as.
ja: Ansible がログインするユーザー

en: Testing Strategies
ja: ストラテジーのテスト

en: Integrating Testing With Ansible Playbooks
ja: Ansible Playbook とテストの統合

en: Many times, people ask, "how can I best integrate testing with Ansible playbooks?"  There are many options.  Ansible is actually designed to be a "fail-fast" and ordered system, therefore it makes it easy to embed testing directly in Ansible playbooks.  In this chapter, we'll go into some patterns for integrating tests of infrastructure and discuss the right level of testing that may be appropriate.
ja: 「Ansible Playbook とテストを最適な方法で統合するにはどうしたらいいのか」との質問が多数寄せられます。統合のオプションは、多数あります。Ansible は実際には、「フェイルファースト (Fail fast)」の順番ベースのシステムとなるように設計されているため、Ansible Playbookに直接、テストを簡単に埋め込むことができます。本章では、インフラストラクチャーのテスト統合パターンについて触れ、適切にテストするための正しいレベルについても説明します。

en: This is a chapter about testing the application you are deploying, not the chapter on how to test Ansible modules during development.  For that content, please hop over to the Development section.
ja: 以下の章は、デプロイするアプリケーションをテストする方法を説明しており、開発時に Ansible モジュールをテストする方法は説明していません。Ansible のテスト方法は、開発のセクションで参照してください。

en: By incorporating a degree of testing into your deployment workflow, there will be fewer surprises when code hits production and, in many cases, tests can be leveraged in production to prevent failed updates from migrating across an entire installation.  Since it's push-based, it's also very easy to run the steps on the localhost or testing servers. Ansible lets you insert as many checks and balances into your upgrade workflow as you would like to have.
ja: 開発のワークフローにテストをある程度組み込むことで、実稼働環境でコードを使用時に、慌てることが少なくなります。多くの場合は、実稼働環境でテストを活用して、更新の失敗が、インストール全体に移行されてしまうのを防ぐことができます。また、プッシュベースになっているため、ローカルホストやテストサーバーで手順を非常に簡単に実行することができます。Ansible は、多くのチェックを挿入できるため、アップグレードのワークフローを希望のレベルに調節できます。

en: The Right Level of Testing
ja: 適切なレベルのテスト

en: Ansible resources are models of desired-state.  As such, it should not be necessary to test that services are started, packages are installed, or other such things.  Ansible is the system that will ensure these things are declaratively true.   Instead, assert these things in your playbooks.
ja: Ansible リソースは、任意の状態のモデルです。サービスの起動、パッケージのインストールなどのテストを行う必要はありません。Ansible は、上記の内容が True と宣言されていることを確認するシステムで、代わりに、以下の項目を Playbook にアサートします。

en: If you think the service may not be started, the best thing to do is request it to be started.  If the service fails to start, Ansible will yell appropriately. (This should not be confused with whether the service is doing something functional, which we'll show more about how to do later).
ja: サービスが起動しない可能性があると思われる場合は、サービスの開始を要求するのが最善の方法です。サービスの開始に失敗した場合は、Ansible により随時指示がでます (これは、サービスが機能的なことを行っているかどうかと混同しないでください。これについては、後で詳しく説明します)。

en: Check Mode As A Drift Test
ja: ドリフトテストとしての check モード

en: In the above setup, `--check` mode in Ansible can be used as a layer of testing as well.  If running a deployment playbook against an existing system, using the `--check` flag to the `ansible` command will report if Ansible thinks it would have had to have made any changes to bring the system into a desired state.
ja: 上記の設定では、Ansible の `--check` モードは、テストのレイヤーとしても使用できます。既存のシステムに対してデプロイメントの Playbook を実行する場合に `--check` フラグを `ansible` コマンドに使用すると、変更が加えられてシステムが適切な状態になっていると Ansible が判断しているかどうかをレポートします。

en: This can let you know up front if there is any need to deploy onto the given system.  Ordinarily, scripts and commands don't run in check mode, so if you want certain steps to execute in normal mode even when the `--check` flag is used, such as calls to the script module, disable check mode for those tasks::
ja: このレポートにより、特定のシステムにデプロイメントが必要かどうかを事前に把握できます。check モードでは、一般的なスクリプトやコマンドは実行されないため、スクリプトモジュールへの呼び出しなど、`--check` フラグが使用されていても通常モードで特定の手順を実行する場合は、このようなタスクのチェックモードを無効にしてください::

en: Modules That Are Useful for Testing
ja: テストに便利なモジュール

en: Certain playbook modules are particularly good for testing.  Below is an example that ensures a port is open::
ja: Playbook のモジュールでは、特にテストに適しているものもあります。以下の例は、ポートが開放されていることを確認します。

en: Here's an example of using the URI module to make sure a web service returns::
ja: 以下の例は、URI モジュールを使用して、Web サービスが返されることを確認します。

en: It's easy to push an arbitrary script (in any language) on a remote host and the script will automatically fail if it has a non-zero return code::
ja: リモートホストで任意のスクリプト (言語は問わない) が簡単にプッシュされるため、ゼロ以外のリターンコードが指定されていると、スクリプトは自動的に失敗します。

en: If using roles (you should be, roles are great!), scripts pushed by the script module can live in the 'files/' directory of a role.
ja: ロールを使用する場合 (ロールは便利なので使用を推奨)、スクリプトモジュールがプッシュするスクリプトは、ロールの「files/」ディレクトリーに配置されます。

en: And the assert module makes it very easy to validate various kinds of truth::
ja: また、アサートモジュールを使用すると、さまざまな真偽の検証が非常に簡単にできます。

en: Should you feel the need to test for the existence of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice::
ja: Ansible 設定で設定が宣言されていないファイルの存在をテストする必要がある場合は、「stat」モジュールが最適です。

en: As mentioned above, there's no need to check things like the return codes of commands.  Ansible is checking them automatically. Rather than checking for a user to exist, consider using the user module to make it exist.
ja: 上記のように、コマンドのリターンコードなどをチェックする必要はありません。Ansible がこのようなコードを自動的にチェックします。ユーザーの存在をチェックする代わりに、ユーザーモジュールを使用してユーザーを存在させます。

en: Ansible is a fail-fast system, so when there is an error creating that user, it will stop the playbook run.  You do not have to check up behind it.
ja: Ansible はフェイルファーストシステムであるため、ユーザーの作成時にエラーがあると、Playbook の実行が停止します。バックグラウンドで行われている内容を確認する必要はありません。

en: Testing Lifecycle
ja: ライフサイクルのテスト

en: If writing some degree of basic validation of your application into your playbooks, they will run every time you deploy.
ja: アプリケーションの基本検証を Playbook に記述すると、デプロイ時に必ずこの検証が実行されます。

en: As such, deploying into a local development VM and a staging environment will both validate that things are according to plan ahead of your production deploy.
ja: そのため、ローカルの開発仮想マシンやステージ環境にデプロイするといずれも、実稼働でのデプロイの前に計画通りに作業が進んでいるかどうかを検証します。

en: Your workflow may be something like this::
ja: ワークフローは、次のようになります。

en: Something like an integration test battery should be written by your QA team if you are a production webservice.  This would include things like Selenium tests or automated API tests and would usually not be something embedded into your Ansible playbooks.
ja: 実稼働の Web サービスを使用する場合には、QA チームが同様の統合テストバッテリーを記述するようにしてください。このようなテストには Selenium テストや自動化 API テストなどが含まれ、通常は、Ansible Playbook に組み込まれているものではありません。

en: However, it does make sense to include some basic health checks into your playbooks, and in some cases it may be possible to run a subset of the QA battery against remote nodes.   This is what the next section covers.
ja: ただし、いくつかの基本的なヘルスチェックを Playbook に追加すると便利です。場合によっては、リモートノードに対して QA バッテリーのサブセットを実行することもできます。この点については、次のセクションで説明します。

en: Integrating Testing With Rolling Updates
ja: ローリングアップデートへのテストの統合

en: If you have read into :ref:`playbooks_delegation` it may quickly become apparent that the rolling update pattern can be extended, and you can use the success or failure of the playbook run to decide whether to add a machine into a load balancer or not.
ja: :ref:`playbooks_delegation` を読むと、ローリングアップデートのパターンを拡張でき、また、Playbook 実行の成否でロードバランサーにマシンを 1 台追加するかどうかを決定できることが即座に明確になったことでしょう。

en: This is the great culmination of embedded tests::
ja: これは、組み込みテストの集大成です。

en: Of course in the above, the "take out of the pool" and "add back" steps would be replaced with a call to an Ansible load balancer module or appropriate shell command.  You might also have steps that use a monitoring module to start and end an outage window for the machine.
ja: 上記では当然、「プールから取得する」手順や「追加し直す」手順は、Ansible のロードバランサーモジュールや、適切な shell コマンドの呼び出しに置き換えられます。また、マシンのサービス停止期間を開始/終了するモニタリングモジュールを使用する手順なども含まれている場合がありますが、

en: However, what you can see from the above is that tests are used as a gate -- if the "apply_testing_checks" step is not performed, the machine will not go back into the pool.
ja: 上記で分かるように、テストはゲートとして使用されています。つまり、「apply_testing_checks」の手順が実行されない場合は、マシンがプールに戻らないようになっています。

en: Read the delegation chapter about "max_fail_percentage" and you can also control how many failing tests will stop a rolling update from proceeding.
ja: ローリングアップデートの続行を妨げるテストの失敗回数を制御できます。この点については、「max_fail_percentage」向けの章を参照してください。

en: This above approach can also be modified to run a step from a testing machine remotely against a machine::
ja: 上記のアプローチを変更して、マシンに対してリモートのテストマシンから手順を実行することも可能です。

en: In the above example, a script is run from the testing server against a remote node prior to bringing it back into the pool.
ja: 上記の例では、プールにマシンを戻す前に、リモートのノードに対してテストサーバーからスクリプトを実行します。

en: In the event of a problem, fix the few servers that fail using Ansible's automatically generated retry file to repeat the deploy on just those servers.
ja: 問題が発生した場合には、Ansible が自動で生成した再試行ファイルを使用して、失敗したサーバー数台を修正し、そのサーバーだけにデプロイメントを繰り返し実行します。

en: Achieving Continuous Deployment
ja: 継続的なデプロイメントの実現

en: If desired, the above techniques may be extended to enable continuous deployment practices.
ja: 任意で、上記の手法を拡張して、継続してデプロイメントができるようにします。

en: The workflow may look like this::
ja: ワークフローは、次のようになります。

en: Some Ansible users use the above approach to deploy a half-dozen or dozen times an hour without taking all of their infrastructure offline.  A culture of automated QA is vital if you wish to get to this level.
ja: Ansible ユーザーによっては、上記のアプローチを使用して、すべてのインフラストラクチャーをオフラインにすることなく、1 時間に 6 回、または 12 回デプロイしています。このレベルに到達するには、自動化 QA の文化が必要不可欠です。

en: If you are still doing a large amount of manual QA, you should still make the decision on whether to deploy manually as well, but it can still help to work in the rolling update patterns of the previous section and incorporate some basic health checks using modules like 'script', 'stat', 'uri', and 'assert'.
ja: 大量の QA を手動で続けている場合には、手動でデプロイするべきかどうか決定する必要がありますが、前項のようにローリングアップデートのパターンを使用して作業をし、「script」、「stat」、「uri」、「assert」などのモジュールで基本的なヘルスチェックを組み込むだけでも役立つ場合があります。

en: Conclusion
ja: まとめ

en: Ansible believes you should not need another framework to validate basic things of your infrastructure is true.  This is the case because Ansible is an order-based system that will fail immediately on unhandled errors for a host, and prevent further configuration of that host.  This forces errors to the top and shows them in a summary at the end of the Ansible run.
ja: Ansible では、インフラストラクチャーの基本的な内容が正しいかを検証するフレームワークを別に用意する必要はないと考えます。これは、Ansible は順序ベースのシステムで、ホストに未処理のエラーがあると即座に失敗し、そのホストの設定がこれ以上進まないようにします。こうすることで、エラーが表面化し、Ansible の実行の最後にまとめとして、エラーが表示されます。

en: However, as Ansible is designed as a multi-tier orchestration system, it makes it very easy to incorporate tests into the end of a playbook run, either using loose tasks or roles.  When used with rolling updates, testing steps can decide whether to put a machine back into a load balanced pool or not.
ja: ただし、Ansible は、複数階層のオーケストレーションシステムとして設計されているため、非常に簡単にタスクまたはロールを使用して Playbook 実行の最後にテストを組み込むことができます。ローリングアップデートで使用する場合は、テストの手順で、ロードバランサーのプールにマシンを戻すかどうかを判断できます。

en: Finally, because Ansible errors propagate all the way up to the return code of the Ansible program itself, and Ansible by default runs in an easy push-based mode, Ansible is a great step to put into a build environment if you wish to use it to roll out systems as part of a Continuous Integration/Continuous Delivery pipeline, as is covered in sections above.
ja: 最後に、Ansible のエラーは、Ansible のプログラム自体のリターンコードにまで伝搬され、また Ansible はデフォルトで簡単なプッシュベースモードで実行されるため、上記のセクションで説明されているように、これを使用して継続的な統合/継続的なデリバリーパイプラインの一部としてシステムを展開する場合に Ansible をビルド環境に活用すると大きな一歩になります。

en: The focus should not be on infrastructure testing, but on application testing, so we strongly encourage getting together with your QA team and ask what sort of tests would make sense to run every time you deploy development VMs, and which sort of tests they would like to run against the staging environment on every deploy.  Obviously at the development stage, unit tests are great too.  But don't unit test your playbook.  Ansible describes states of resources declaratively, so you don't have to.  If there are cases where you want to be sure of something though, that's great, and things like stat/assert are great go-to modules for that purpose.
ja: インフラストラクチャーテストではなく、アプリケーションのテストに焦点を当てるため、QA チームと連携して、どのようなテストを、開発仮想マシンのデプロイメント時に毎回実行すると便利か、またデプロイメント時に毎回、ステージ環境にどのようなテストを実行するかを確認してください。明らかに、開発段階では、単体テストも素晴らしいですが、Playbook を単体テストにはしないでください。Ansibl eはリソースの状態を宣言的に記述するため、その必要はありません。ただし、何かを確認したい場合は、stat/assert のようなモジュールを使用すると良いでしょう。

en: In all, testing is a very organizational and site-specific thing.  Everybody should be doing it, but what makes the most sense for your environment will vary with what you are deploying and who is using it -- but everyone benefits from a more robust and reliable deployment system.
ja: 結局、テストは非常に組織的で、サイト固有の内容となっています。テストは必ず行うべきですが、貴社の環境に最も有用なテストは、デプロイメントの内容や、誰が使用するかにより異なります。しかし、誰もが、強力で信頼性の高いデプロイメントシステムから恩恵を受けることができます。

en: Delegation, useful for working with load balancers, clouds, and locally executed steps.
ja: 委譲 (ロードバランサー、クラウド、およびローカルで実行した手順を使用する際に役に立ちます)

en: `Red Hat Ansible Tower <https://www.ansible.com/products/tower>`_ is a web console and REST API for operationalizing Ansible across your team, organization, and enterprise. It's designed to be the hub for all of your automation tasks.
ja: `Red Hat Ansible Tower <https://www.ansible.com/products/tower>`_ は、チーム、組織、企業全体で Ansible を操作する Web コンソールおよび REST API です。Red Hat Ansible Tower は、すべての自動化タスクのハブとなるように設計されています。

en: Ansible Tower gives you role-based access control, including control over the use of securely stored credentials for SSH and other services. You can sync your Ansible Tower inventory with a wide variety of cloud sources, and powerful multi-playbook workflows allow you to model complex processes.
ja: Ansible Tower には、セキュアに保存されている SSH や他のサービスの認証情報の使用時に制御するなど、ロールベースのアクセス制御が含まれています。Ansible Tower インベントリーは、幅広いクラウドソースと同期でき、強力な Playbook ワークフローを複数使用することで、複雑なプロセスをモデル化できます。

en: It logs all of your jobs, integrates well with LDAP, SAML, and other authentication sources, and has an amazing browsable REST API. Command line tools are available for easy integration with Jenkins as well.
ja: すべてのジョブをログ記録し、LDAP、SAML、他の認証ソースと統合の相性がよく、ブラウザーで使用可能な素晴らしい REST API が含まれます。また、Jenkins と簡単に統合できるように、コマンドラインも利用できます。

en: Ansible Tower is the downstream Red-Hat supported product version of Ansible AWX. Find out more about Ansible Tower features and how to download it on the `Ansible Tower webpage <https://www.ansible.com/products/tower>`_. Ansible Tower is part of the Red Hat Ansible Automation subscription, and comes bundled with amazing support from Red Hat, Inc.
ja: Ansible Tower は、Red Hat がサポートする Ansible AWX の製品のバージョン (ダウンストリーム) です。Ansible Tower の機能とそのダウンロード方法の詳細は、`Ansible Tower web ページ <https://www.ansible.com/products/tower>`_ を参照してください。Ansible Tower は、Red Hat Ansible Automation サブスクリプションに含まれ、Red Hat, Inc のサポートが利用できます。
