diff options
Diffstat (limited to 'docs/docsite/rst/locales/ja/LC_MESSAGES/user_guide.po')
| -rw-r--r-- | docs/docsite/rst/locales/ja/LC_MESSAGES/user_guide.po | 14087 |
1 files changed, 14087 insertions, 0 deletions
diff --git a/docs/docsite/rst/locales/ja/LC_MESSAGES/user_guide.po b/docs/docsite/rst/locales/ja/LC_MESSAGES/user_guide.po new file mode 100644 index 0000000000..03fca233c1 --- /dev/null +++ b/docs/docsite/rst/locales/ja/LC_MESSAGES/user_guide.po @@ -0,0 +1,14087 @@ +# SOME DESCRIPTIVE TITLE. +# Copyright (C) Ansible project contributors +# This file is distributed under the same license as the Ansible package. +# FIRST AUTHOR <EMAIL@ADDRESS>, 2022. +# +msgid "" +msgstr "" +"Project-Id-Version: Ansible devel\n" +"Report-Msgid-Bugs-To: \n" +"POT-Creation-Date: 2022-06-27 15:07+0200\n" +"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" +"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" +"Language-Team: LANGUAGE <LL@li.org>\n" +"MIME-Version: 1.0\n" +"Content-Type: text/plain; charset=utf-8\n" +"Content-Transfer-Encoding: 8bit\n" +"Generated-By: Babel 2.9.0\n" + +#: ../../rst/user_guide/basic_concepts.rst:5 +msgid "Ansible concepts" +msgstr "Ansible の概念" + +#: ../../rst/user_guide/basic_concepts.rst:7 +msgid "These concepts are common to all uses of Ansible. You need to understand them to use Ansible for any kind of automation. This basic introduction provides the background you need to follow the rest of the User Guide." +msgstr "この概念は、Ansible のすべての用途に共通しています。あらゆる種類の自動化のために Ansible を使用するには、これらを理解する必要があります。この基本的な紹介は、本ガイドの内容を理解するのに必要な背景を説明します。" + +#: ../../rst/shared_snippets/basic_concepts.txt:2 +msgid "Control node" +msgstr "コントロールノード" + +#: ../../rst/shared_snippets/basic_concepts.txt:3 +msgid "The machine from which you run the Ansible CLI tools (``ansible-playbook`` , ``ansible``, ``ansible-vault`` and others). You can use any computer that meets the software requirements as a control node - laptops, shared desktops, and servers can all run Ansible. Multiple control nodes are possible, but Ansible itself does not coordinate across them, see ``AAP`` for such features." +msgstr "Ansible CLI ツールを実行するマシン (``ansible-playbook``、``ansible``、``ansible-vault``、その他)。ソフトウェア要件を満たす任意のコンピューターをコントロールノードとして使用できます。ラップトップ、共有デスクトップ、サーバーはすべて Ansible を実行できます。複数のコントロールノードが可能ですが、Ansible 自体はそれらの間で調整されません。この機能については ``AAP`` を参照してください。" + +#: ../../rst/shared_snippets/basic_concepts.txt:9 +msgid "Managed nodes" +msgstr "管理ノード" + +#: ../../rst/shared_snippets/basic_concepts.txt:10 +msgid "Also referred to as 'hosts', these are the target devices (servers, network appliances or any computer) you aim to manage with Ansible. Ansible is not normally installed on managed nodes, unless you are using ``ansible-pull``, but this is rare and not the recommended setup." +msgstr "ホストとも呼ばれ、Ansible で管理することを目的としたターゲットデバイス (サーバー、ネットワークアプライアンス、または任意のコンピューター) です。通常 Ansible は管理ノードにインストールされません。``ansible-pull`` を使用している場合は除きますが、それは稀なケースであり、推奨される設定ではありません。" + +#: ../../rst/shared_snippets/basic_concepts.txt:15 +msgid "Inventory" +msgstr "インベントリー" + +#: ../../rst/shared_snippets/basic_concepts.txt:16 +msgid "A list of managed nodes provided by one or more 'inventory sources'. Your inventory can specify information specific to each node, like IP address. It is also used for assigning groups, that both allow for node selection in the Play and bulk variable assignment. To learn more about inventory, see :ref:`the Working with Inventory<intro_inventory>` section. Sometimes an inventory source file is also referred to as a 'hostfile'." +msgstr "1 つ以上の「インベントリーソース」で提供される管理ノードの一覧。インベントリーは、IP アドレスなどの各ノードに固有の情報を指定できます。また、プレイおよび一括変数割り当てでノードの選択を可能にするグループの割り当てにも使用されます。インベントリーの詳細は、:ref:`the Working with Inventory<intro_inventory>` セクションを参照してください。インベントリーソースファイルは「hostfile」と呼ばれる場合もあります。" + +#: ../../rst/shared_snippets/basic_concepts.txt:22 +msgid "Playbooks" +msgstr "Playbook" + +#: ../../rst/shared_snippets/basic_concepts.txt:23 +msgid "They contain Plays (which are the basic unit of Ansible execution). this is both an 'execution concept' and how we describe the files on which ``ansible-playbook`` operates on. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`." +msgstr "プレイ (Ansible 実行の基本単位) が含まれています。これは「実行の概念」であり、``ansible-playbook`` が動作するファイルの記述方法でもあります。Playbook は YAML で書かれており、簡単に読み、書き、共有、理解できます。Playbook の詳細については、:ref:`about_playbooks` を参照してください。" + +#: ../../rst/shared_snippets/basic_concepts.txt:27 +msgid "Plays" +msgstr "プレイ" + +#: ../../rst/shared_snippets/basic_concepts.txt:28 +msgid "The main context for Ansible execution, this playbook object maps managed nodes (hosts) to tasks. The Play contains variables, roles and an ordered lists of tasks and can be run repeatedly. It basically consists of an implicit loop over the mapped hosts and tasks and defines how to iterate over them." +msgstr "Ansible 実行のメインコンテキストであるこの Playbook オブジェクトは、管理ノード (ホスト) をタスクにマップします。プレイには、変数、ロール、およびタスクの順序付きリストが含まれており、繰り返し実行できます。これは基本的に、マップされたホストとタスクの暗黙的なループで設定され、それらを反復処理する方法を定義します。" + +#: ../../rst/shared_snippets/basic_concepts.txt:33 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:5 +msgid "Roles" +msgstr "ロール" + +#: ../../rst/shared_snippets/basic_concepts.txt:34 +msgid "A limited distribution of reusable ansible content (tasks, handlers, variables, plugins, templates and files) for use inside of a Play. To use any Role resource, the Role itself must be imported into the Play." +msgstr "プレイ内で使用するための再利用可能な Ansible コンテンツ (タスク、ハンドラー、変数、プラグイン、テンプレート、およびファイル) の限定ディストリビューション。ロールリソースを使用するには、ロール自体をプレイにインポートする必要があります。" + +#: ../../rst/shared_snippets/basic_concepts.txt:38 +msgid "Tasks" +msgstr "タスク" + +#: ../../rst/shared_snippets/basic_concepts.txt:39 +msgid "The definition of an 'action' to be applied to the managed host. Tasks must always be contained in a Play, directly or indirectly (Role, or imported/included task list file). You can execute a single task once with an ad hoc command ``ansible`` or ``ansible-console`` (both create a virtual Play)." +msgstr "管理ホストに適用される「アクション」の定義。タスクは、常に直接または間接的にプレイに含まれている必要があります (ロール、またはインポート/インクルードされたタスクリストファイル)。アドホックコマンド ``ansible`` または ``ansible-console`` (どちらも仮想プレイを作成) を使用して、1 つのタスクを 1 回実行できます。" + +#: ../../rst/shared_snippets/basic_concepts.txt:43 +msgid "Handlers" +msgstr "ハンドラー" + +#: ../../rst/shared_snippets/basic_concepts.txt:44 +msgid "Special form of a Task, that only execute when notified by a previous task which resulted in a 'changed' status." +msgstr "特別な形式のタスク。前のタスクから通知されたときにのみ実行され、'changed' ステータスになります。" + +#: ../../rst/shared_snippets/basic_concepts.txt:48 +msgid "Modules" +msgstr "モジュール" + +#: ../../rst/shared_snippets/basic_concepts.txt:49 +msgid "The code or binaries that Ansible copies and executes on each managed node (when needed) to accomplish the action defined in each Task. Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. You can invoke a single module with a task, or invoke several different modules in a playbook. Ansible modules are grouped in collections. For an idea of how many collections Ansible includes, see the :ref:`list_of_collections`." +msgstr "Ansible が、各タスクで定義されたアクションを実行するために、各管理ノードで (必要に応じて) コピーおよび実行するコードまたはバイナリー。各モジュールは、特定タイプのデータベースのユーザーを管理したり、特定タイプのネットワークデバイスの VLAN インターフェースを管理するなど、特定の用途に使用されます。タスクで 1 つのモジュールを起動したり、Playbook で複数のモジュールを起動したりすることができます。Ansible モジュールはコレクションとしてまとめられています。Ansible に含まれるコレクションの数は、:ref:`list_of_collections` を参照してください。" + +#: ../../rst/shared_snippets/basic_concepts.txt:56 +msgid "Plugins" +msgstr "プラグイン" + +#: ../../rst/shared_snippets/basic_concepts.txt:57 +msgid "Pieces of code that expand Ansible's core capabilities, they can control how you connect to a managed node (connection plugins), manipulate data (filter plugins) and even control what is displayed in the console (callback plugins). See :ref:`working_with_plugins` for details." +msgstr "Ansible のコア機能を拡張するコードの一部であり、管理ノードへの接続方法 (接続プラグイン)、データの操作 (フィルタープラグイン)、さらにはコンソールに表示される内容 (コールバックプラグイン) を制御できます。詳細は :ref:`working_with_plugins` を参照してください。" + +#: ../../rst/shared_snippets/basic_concepts.txt:63 +msgid "Collections" +msgstr "コレクション" + +#: ../../rst/shared_snippets/basic_concepts.txt:64 +msgid "Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_. To learn more about collections, see :ref:`collections`. Collection resources can be used independently and discretely from each other." +msgstr "コレクションは、Playbook、ロール、モジュール、プラグインを含む Ansible コンテンツのディストリビューション形式です。`Ansible Galaxy <https://galaxy.ansible.com>`_ でコレクションをインストールして使用することができます。コレクションの詳細は、:ref:`collections` を参照してください。コレクションリソースは、互いに依存せず、個別に使用できます。" + +#: ../../rst/shared_snippets/basic_concepts.txt:68 +msgid "AAP" +msgstr "AAP" + +#: ../../rst/shared_snippets/basic_concepts.txt:69 +msgid "Short for 'Ansible Automation Platform'. This is a product that includes enterprise level features and integrates many tools of the Ansible ecosystem: ansible-core, awx, galaxyNG, and so on." +msgstr "Ansible Automation Platform の略です。これは、エンタープライズレベルの機能が含まれ、Ansible エコシステムの多くツール (ansible-core、awx、galaxyNG など) を統合する製品です。" + +#: ../../rst/user_guide/become.rst:5 +msgid "Understanding privilege escalation: become" +msgstr "権限昇格の理解: become" + +#: ../../rst/user_guide/become.rst:7 +msgid "Ansible uses existing privilege escalation systems to execute tasks with root privileges or with another user's permissions. Because this feature allows you to 'become' another user, different from the user that logged into the machine (remote user), we call it ``become``. The ``become`` keyword uses existing privilege escalation tools like `sudo`, `su`, `pfexec`, `doas`, `pbrun`, `dzdo`, `ksu`, `runas`, `machinectl` and others." +msgstr "Ansible は既存の権限昇格システムを使用して、root 権限または別のユーザーのパーミッションでタスクを実行します。この機能を使用すると、このマシンにログインしたユーザー (リモートユーザー) とは別のユーザー「になる (become)」ことができるため、この機能は ``become`` と呼ばれています。``become`` キーワードは、`sudo`、`su`、`pfexec`、`doas`、`pbrun`、`dzdo`、`ksu`、`runas`、`machinectl` などの既存の特権昇格ツールを使用します。" + +#: ../../rst/user_guide/become.rst:13 +msgid "Using become" +msgstr "become の使用" + +#: ../../rst/user_guide/become.rst:15 +msgid "You can control the use of ``become`` with play or task directives, connection variables, or at the command line. If you set privilege escalation properties in multiple ways, review the :ref:`general precedence rules<general_precedence_rules>` to understand which settings will be used." +msgstr "play ディレクティブまたは task ディレクティブ、接続変数、またはコマンドラインでの ``become`` の使用を制御できます。複数の方法で権限昇格プロパティーを設定する場合は、:ref:`一般的な優先順位ルール<general_precedence_rules>` を確認し、使用する設定を確認します。" + +#: ../../rst/user_guide/become.rst:17 +msgid "A full list of all become plugins that are included in Ansible can be found in the :ref:`become_plugin_list`." +msgstr "Ansible に含まれる全 become プラグインの完全リストは、:ref:`become_plugin_list` にあります。" + +#: ../../rst/user_guide/become.rst:20 +msgid "Become directives" +msgstr "Become ディレクティブ" + +#: ../../rst/user_guide/become.rst:22 +msgid "You can set the directives that control ``become`` at the play or task level. You can override these by setting connection variables, which often differ from one host to another. These variables and directives are independent. For example, setting ``become_user`` does not set ``become``." +msgstr "プレイまたはタスクレベルで、``become`` を制御するディレクティブを設定できます。多くの場合は、ホストごとに異なる接続変数を設定することで、これらをオーバーライドできます。これらの変数とディレクティブは独立しています。たとえば、``become_user`` に設定しても ``become`` に設定されません。" + +#: ../../rst/user_guide/become.rst:25 +msgid "become" +msgstr "become" + +#: ../../rst/user_guide/become.rst:25 +msgid "set to ``yes`` to activate privilege escalation." +msgstr "権限昇格をアクティブにするには、``yes`` に設定します。" + +#: ../../rst/user_guide/become.rst:28 +msgid "become_user" +msgstr "become_user" + +#: ../../rst/user_guide/become.rst:28 +msgid "set to user with desired privileges — the user you `become`, NOT the user you login as. Does NOT imply ``become: yes``, to allow it to be set at host level. Default value is ``root``." +msgstr "希望する権限を持つユーザーに設定します。ログインしたユーザーではなく、`become` を行ったユーザーになります。ホストレベルで設定できるようにする ``become: yes`` を意味するものではありません。デフォルト値は ``root`` です。" + +#: ../../rst/user_guide/become.rst:31 +msgid "become_method" +msgstr "become_method" + +#: ../../rst/user_guide/become.rst:31 +msgid "(at play or task level) overrides the default method set in ansible.cfg, set to use any of the :ref:`become_plugins`." +msgstr "(play レベルまたは task レベルで)、ansible.cfg に設定されたデフォルトのメソッドをオーバーライドし、:ref:`become_plugins` を使用するよう設定します。" + +#: ../../rst/user_guide/become.rst:34 +msgid "become_flags" +msgstr "become_flags" + +#: ../../rst/user_guide/become.rst:34 +msgid "(at play or task level) permit the use of specific flags for the tasks or role. One common use is to change the user to nobody when the shell is set to nologin. Added in Ansible 2.2." +msgstr "(play レベルまたは task レベルで) タスクまたはロールに特定のフラグの使用を許可します。一般的な使い方としては、シェルが nologin に設定されているときに、ユーザーを nobody に変更するのが一般的な方法です。Ansible 2.2 で追加されました。" + +#: ../../rst/user_guide/become.rst:36 +msgid "For example, to manage a system service (which requires ``root`` privileges) when connected as a non-``root`` user, you can use the default value of ``become_user`` (``root``):" +msgstr "たとえば、``root`` 以外のユーザーとして接続する際にシステムサービスを管理する (``root`` 権限が必要) には、``become_user`` (``root``) のデフォルト値を使用できます。" + +#: ../../rst/user_guide/become.rst:46 +msgid "To run a command as the ``apache`` user:" +msgstr "``apache`` ユーザーとしてコマンドを実行するには、次を実行します。" + +#: ../../rst/user_guide/become.rst:55 +msgid "To do something as the ``nobody`` user when the shell is nologin:" +msgstr "シェルが nologin の場合に ``nobody`` ユーザーとして操作を行う場合は、次を実行します。" + +#: ../../rst/user_guide/become.rst:66 +msgid "To specify a password for sudo, run ``ansible-playbook`` with ``--ask-become-pass`` (``-K`` for short). If you run a playbook utilizing ``become`` and the playbook seems to hang, most likely it is stuck at the privilege escalation prompt. Stop it with `CTRL-c`, then execute the playbook with ``-K`` and the appropriate password." +msgstr "sudo のパスワードを指定するには、``ansible-playbook`` を ``--ask-become-pass`` (略して ``-K``) と一緒に実行します。``become`` を使用して Playbook を実行し、Playbook がハングしているように見える場合は、ほとんどの場合、特権昇格のプロンプトで止まっています。`CTRL-c` で停止させてから、``-K`` と適切なパスワードで Playbook を実行してください。" + +#: ../../rst/user_guide/become.rst:70 +msgid "Become connection variables" +msgstr "Become 接続変数" + +#: ../../rst/user_guide/become.rst:72 +msgid "You can define different ``become`` options for each managed node or group. You can define these variables in inventory or use them as normal variables." +msgstr "管理対象ノードまたはグループごとに異なる ``become`` オプションを定義できます。これらの変数はインベントリーで定義するか、通常の変数として使用できます。" + +#: ../../rst/user_guide/become.rst:75 +#: ../../rst/user_guide/intro_inventory.rst:577 +#: ../../rst/user_guide/intro_inventory.rst:652 +msgid "ansible_become" +msgstr "ansible_become" + +#: ../../rst/user_guide/become.rst:75 +msgid "overrides the ``become`` directive, decides if privilege escalation is used or not." +msgstr "``become`` ディレクティブを上書きします。権限のエスカレーションが使用されるかどうかを指定します。" + +#: ../../rst/user_guide/become.rst:78 +#: ../../rst/user_guide/intro_inventory.rst:579 +msgid "ansible_become_method" +msgstr "ansible_become_method" + +#: ../../rst/user_guide/become.rst:78 +msgid "which privilege escalation method should be used" +msgstr "使用する権限昇格方法です。" + +#: ../../rst/user_guide/become.rst:81 +#: ../../rst/user_guide/intro_inventory.rst:581 +msgid "ansible_become_user" +msgstr "ansible_become_user" + +#: ../../rst/user_guide/become.rst:81 +msgid "set the user you become through privilege escalation; does not imply ``ansible_become: yes``" +msgstr "権限昇格で become を行うユーザーを設定します。``ansible_become: yes`` を意味するものではありません。" + +#: ../../rst/user_guide/become.rst:84 +#: ../../rst/user_guide/intro_inventory.rst:583 +msgid "ansible_become_password" +msgstr "ansible_become_password" + +#: ../../rst/user_guide/become.rst:84 +msgid "set the privilege escalation password. See :ref:`playbooks_vault` for details on how to avoid having secrets in plain text" +msgstr "権限昇格パスワードを設定します。平文での秘密の使用を回避する方法は、「:ref:`playbooks_vault`」を参照してください。" + +#: ../../rst/user_guide/become.rst:87 +msgid "ansible_common_remote_group" +msgstr "ansible_common_remote_group" + +#: ../../rst/user_guide/become.rst:87 +msgid "determines if Ansible should try to ``chgrp`` its temporary files to a group if ``setfacl`` and ``chown`` both fail. See `Risks of becoming an unprivileged user`_ for more information. Added in version 2.10." +msgstr "``setfacl`` と ``chown`` の両方が失敗した場合に、Ansible が一時ファイルをグループに ``chgrp`` しようとするかどうかを決定します。詳細は「`非特権ユーザーになるリスク`_」を参照してください。バージョン 2.10 で追加されました。" + +#: ../../rst/user_guide/become.rst:89 +msgid "For example, if you want to run all tasks as ``root`` on a server named ``webserver``, but you can only connect as the ``manager`` user, you could use an inventory entry like this:" +msgstr "たとえば、すべてのタスクを ``webserver`` という名前のサーバーで ``root`` として実行することを望み、``manager`` ユーザーとしてのみ接続できる場合は、以下のようなインベントリーエントリーを使用できます。" + +#: ../../rst/user_guide/become.rst:96 +msgid "The variables defined above are generic for all become plugins but plugin specific ones can also be set instead. Please see the documentation for each plugin for a list of all options the plugin has and how they can be defined. A full list of become plugins in Ansible can be found at :ref:`become_plugins`." +msgstr "上記の変数はすべての become プラグインに汎用的なものですが、代わりにプラグイン固有の変数を設定することもできます。そのプラグインが持つすべてのオプションとその定義方法の一覧は、各プラグインのドキュメントを参照してください。Ansible における become プラグインの完全なリストは :ref:`become_plugins` を参照してください。" + +#: ../../rst/user_guide/become.rst:101 +msgid "Become command-line options" +msgstr "Become コマンドラインオプション" + +#: ../../rst/user_guide/become.rst:104 +msgid "ask for privilege escalation password; does not imply become will be used. Note that this password will be used for all hosts." +msgstr "権限昇格パスワードを要求します。これは。必ずしも become が使用されるとは限りません。このパスワードはすべてのホストで使用されることに注意してください。" + +#: ../../rst/user_guide/become.rst:107 +msgid "run operations with become (no password implied)" +msgstr "become で操作を実行します (パスワードがないことを示しています)。" + +#: ../../rst/user_guide/become.rst:110 +msgid "privilege escalation method to use (default=sudo), valid choices: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ]" +msgstr "使用する特権昇格方法 (デフォルトは sudo)。有効な選択肢は、[ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ] となります。" + +#: ../../rst/user_guide/become.rst:114 +msgid "run operations as this user (default=root), does not imply --become/-b" +msgstr "このユーザー (デフォルトは root) として操作を実行します。--become/-b を意味するものではありません。" + +#: ../../rst/user_guide/become.rst:117 +msgid "Risks and limitations of become" +msgstr "become のリスクおよび制限" + +#: ../../rst/user_guide/become.rst:119 +msgid "Although privilege escalation is mostly intuitive, there are a few limitations on how it works. Users should be aware of these to avoid surprises." +msgstr "特権の昇格はほとんど直感的ですが、それがどのように機能するかについては、いくつかの制限があります。問題が発生しないように、これらの点に注意する必要があります。" + +#: ../../rst/user_guide/become.rst:123 +msgid "Risks of becoming an unprivileged user" +msgstr "非特権ユーザーになる (become) リスク" + +#: ../../rst/user_guide/become.rst:125 +msgid "Ansible modules are executed on the remote machine by first substituting the parameters into the module file, then copying the file to the remote machine, and finally executing it there." +msgstr "Ansible モジュールは、まずモジュールファイルにパラメーターを代入し、次にそのファイルをリモートマシンにコピーし、最後にそこで実行することで、リモートマシン上で実行されます。" + +#: ../../rst/user_guide/become.rst:129 +msgid "Everything is fine if the module file is executed without using ``become``, when the ``become_user`` is root, or when the connection to the remote machine is made as root. In these cases Ansible creates the module file with permissions that only allow reading by the user and root, or only allow reading by the unprivileged user being switched to." +msgstr "モジュールファイルが ``become`` を使用せずに、``become_user`` が root の場合や、リモートマシンへの接続が root として行われる場合、すべてのことは問題ありません。このような場合、Ansible は、ユーザーおよび root による読み取りのみを許可するパーミッション、または切り替え先の非特権ユーザーの読み取りのみを許可するパーミッションを持つモジュールファイルを作成します。" + +#: ../../rst/user_guide/become.rst:135 +msgid "However, when both the connection user and the ``become_user`` are unprivileged, the module file is written as the user that Ansible connects as (the ``remote_user``), but the file needs to be readable by the user Ansible is set to ``become``. The details of how Ansible solves this can vary based on platform. However, on POSIX systems, Ansible solves this problem in the following way:" +msgstr "ただし、接続ユーザーと ``become_user`` の両方が特権を持たない場合、モジュールファイルは Ansible が接続するユーザー (``remote_user``) として記述されますが、Ansible が ``become`` に設定されているユーザーがファイルを読み取れる必要があります。Ansible がこれをプラットフォーム別に解決する方法の詳細は次のとおりですが、POSIX システムでは、Ansible がこの問題を解決します。" + +#: ../../rst/user_guide/become.rst:141 +msgid "First, if :command:`setfacl` is installed and available in the remote ``PATH``, and the temporary directory on the remote host is mounted with POSIX.1e filesystem ACL support, Ansible will use POSIX ACLs to share the module file with the second unprivileged user." +msgstr "まず、リモート ``PATH`` に :command:`setfacl` がインストールされ、利用可能な場合は、リモートホストの一時ディレクトリーが POSIX.1e ファイルシステム ACL サポートでマウントされている場合、Ansible は POSIX ACL を使用して 2 つの非特権ユーザーとモジュールファイルを共有します。" + +#: ../../rst/user_guide/become.rst:146 +msgid "Next, if POSIX ACLs are **not** available or :command:`setfacl` could not be run, Ansible will attempt to change ownership of the module file using :command:`chown` for systems which support doing so as an unprivileged user." +msgstr "次に、POSIX ACL が利用 **できない** か、:command:`setfacl` を実行できない場合、Ansible は、特権のないユーザーとして対応するシステムの :command:`chown` を使用してモジュールファイルの所有権を変更しようとします。" + +#: ../../rst/user_guide/become.rst:150 +msgid "New in Ansible 2.11, at this point, Ansible will try :command:`chmod +a` which is a macOS-specific way of setting ACLs on files." +msgstr "Ansible 2.11 の新機能として、Ansible は、ファイルに ACL を設定する際に macOS 固有の方法で :command:`chmod +a` を試行します。" + +#: ../../rst/user_guide/become.rst:153 +msgid "New in Ansible 2.10, if all of the above fails, Ansible will then check the value of the configuration setting ``ansible_common_remote_group``. Many systems will allow a given user to change the group ownership of a file to a group the user is in. As a result, if the second unprivileged user (the ``become_user``) has a UNIX group in common with the user Ansible is connected as (the ``remote_user``), and if ``ansible_common_remote_group`` is defined to be that group, Ansible can try to change the group ownership of the module file to that group by using :command:`chgrp`, thereby likely making it readable to the ``become_user``." +msgstr "Ansible 2.10 の新機能で、上記のすべてが失敗すると、Ansible は構成設定 ``ansible_common_remote_group`` の値を確認します。多くのシステムでは、特定のユーザーが、ファイルのグループ所有権を、所属するグループに変更できます。その結果、2 番目の非特権ユーザー (``become_user``) に、Ansible が (``remote_user``として) 接続するユーザーに共通する UNIX グループがあり、``ansible_common_remote_group`` がそのグループとして定義されている場合は、 :command:`chgrp` を使用してモジュールファイルのグループ所有権をそのグループに変更しようとすることができます。したがって、``become_user`` が読みるようになる可能性があります。" + +#: ../../rst/user_guide/become.rst:163 +msgid "At this point, if ``ansible_common_remote_group`` was defined and a :command:`chgrp` was attempted and returned successfully, Ansible assumes (but, importantly, does not check) that the new group ownership is enough and does not fall back further. That is, Ansible **does not check** that the ``become_user`` does in fact share a group with the ``remote_user``; so long as the command exits successfully, Ansible considers the result successful and does not proceed to check ``allow_world_readable_tmpfiles`` per below." +msgstr "この時点で、``ansible_common_remote_group`` が定義され、 :command:`chgrp` が試行されて正常に返された場合、Ansible は新しいグループの所有権で十分であると仮定し (ただし、重要なことですが、確認はしません)、それ以上はフォールバックしません。つまり、``become_user`` が実際に ``remote_user`` とグループを共有しているかどうかは **確認しません**。コマンドが正常に終了する限り、Ansible はその結果を成功とみなし、以下の ``allow_world_readable_tmpfiles`` のチェックには進みません。" + +#: ../../rst/user_guide/become.rst:171 +msgid "If ``ansible_common_remote_group`` is **not** set and the chown above it failed, or if ``ansible_common_remote_group`` *is* set but the :command:`chgrp` (or following group-permissions :command:`chmod`) returned a non-successful exit code, Ansible will lastly check the value of ``allow_world_readable_tmpfiles``. If this is set, Ansible will place the module file in a world-readable temporary directory, with world-readable permissions to allow the ``become_user`` (and incidentally any other user on the system) to read the contents of the file. **If any of the parameters passed to the module are sensitive in nature, and you do not trust the remote machines, then this is a potential security risk.**" +msgstr "``ansible_common_remote_group`` が **設定されておらず**、そこでの chown が失敗した場合、または ``ansible_common_remote_group`` *が* 設定されているが :command:`chgrp` (またはそれに続くグループパーミッションの :command:`chmod`) が成功しない終了コードを返した場合、Ansible は最後に ``allow_world_readable_tmpfiles`` の値を確認します。この値が設定されていると、Ansible はモジュールファイルを誰もが読める一時ディレクトリーに置き、``become_user`` (およびシステム上の他のユーザー) がファイルの内容を読めるように、誰もが読み取り可能なパーミッションを設定します。**モジュールに渡されるパラメーターに機密性があり、リモートマシンを信用していない場合、これは潜在的なセキュリティーリスクとなります。**" + +#: ../../rst/user_guide/become.rst:182 +msgid "Once the module is done executing, Ansible deletes the temporary file." +msgstr "モジュールの実行が完了すると、Ansible は一時ファイルを削除します。" + +#: ../../rst/user_guide/become.rst:184 +msgid "Several ways exist to avoid the above logic flow entirely:" +msgstr "上記のロジックフローを完全に回避する方法はいくつかあります。" + +#: ../../rst/user_guide/become.rst:186 +msgid "Use `pipelining`. When pipelining is enabled, Ansible does not save the module to a temporary file on the client. Instead it pipes the module to the remote python interpreter's stdin. Pipelining does not work for python modules involving file transfer (for example: :ref:`copy <copy_module>`, :ref:`fetch <fetch_module>`, :ref:`template <template_module>`), or for non-python modules." +msgstr "`pipelining` を使用します。パイプラインを有効にすると、Ansible はモジュールをクライアント上の一時ファイルに保存しません。代わりに、モジュールをリモートの python インタープリターの標準入力にパイプします。パイプラインは、ファイル転送を伴う python モジュール (例: :ref:`copy <copy_module>`、:ref:`fetch <fetch_module>`、:ref:`template <template_module>`) や、python 以外のモジュールでは機能しません。" + +#: ../../rst/user_guide/become.rst:192 +msgid "Avoid becoming an unprivileged user. Temporary files are protected by UNIX file permissions when you ``become`` root or do not use ``become``. In Ansible 2.1 and above, UNIX file permissions are also secure if you make the connection to the managed machine as root and then use ``become`` to access an unprivileged account." +msgstr "非特権ユーザーは使用しないでください。root に ``become`` した場合、または ``become`` を使用しない場合は、UNIX ファイルの権限で保護されます。Ansible 2.1 以降では、UNIX ファイルのパーミッションは、root として管理マシンに接続し、権限のないアカウントにアクセスするには、``become`` を使用しても保護されます。" + +#: ../../rst/user_guide/become.rst:198 +msgid "Although the Solaris ZFS filesystem has filesystem ACLs, the ACLs are not POSIX.1e filesystem acls (they are NFSv4 ACLs instead). Ansible cannot use these ACLs to manage its temp file permissions so you may have to resort to ``allow_world_readable_tmpfiles`` if the remote machines use ZFS." +msgstr "Solaris ZFS ファイルシステムにはファイルシステム ACL がありますが、ACL は POSIX.1e ファイルシステムの acl ではありません (正しくは NFSv4 ACL)。Ansible はこれらの ACL を使用してその一時ファイルのパーミッションを管理できないため、リモートマシンが ZFS を使用している場合は ``allow_world_readable_tmpfiles`` を再処理しないといけない場合があります。" + +#: ../../rst/user_guide/become.rst:205 +msgid "Ansible makes it hard to unknowingly use ``become`` insecurely. Starting in Ansible 2.1, Ansible defaults to issuing an error if it cannot execute securely with ``become``. If you cannot use pipelining or POSIX ACLs, must connect as an unprivileged user, must use ``become`` to execute as a different unprivileged user, and decide that your managed nodes are secure enough for the modules you want to run there to be world readable, you can turn on ``allow_world_readable_tmpfiles`` in the :file:`ansible.cfg` file. Setting ``allow_world_readable_tmpfiles`` will change this from an error into a warning and allow the task to run as it did prior to 2.1." +msgstr "Ansible では、知らずに ``become`` を安全でない状態で使用することは困難です。Ansible 2.1 以降、Ansible は ``become`` で安全に実行できない場合は、デフォルトでエラーを発行するようになっています。パイプラインや POSIX ACL を使用できず、非特権ユーザーとして接続しなければならず、``become`` を使用して別の非特権ユーザーとして実行しなければならず、管理対象のノードが、そこで実行したいモジュールが誰でも読むことができる程度に安全であると判断した場合は、:file:`ansible.cfg` ファイルで ``allow_world_readable_tmpfiles`` を有効にすることができます。``allow_world_readable_tmpfiles`` を設定すると、これがエラーから警告に変わり、2.1 以前のようにタスクを実行できるようになります。" + +#: ../../rst/user_guide/become.rst:217 +msgid "Ansible 2.10 introduces the above-mentioned ``ansible_common_remote_group`` fallback. As mentioned above, if enabled, it is used when ``remote_user`` and ``become_user`` are both unprivileged users. Refer to the text above for details on when this fallback happens." +msgstr "Ansible 2.10 では、上記の ``ansible_common_remote_group`` フォールバックが導入されました。上記のように、有効になっていると、``remote_user`` と ``become_user`` の両方が非特権ユーザーである場合に使用されます。このフォールバックが発生するときの詳細は、上記のテキストを参照してください。" + +#: ../../rst/user_guide/become.rst:222 +msgid "As mentioned above, if ``ansible_common_remote_group`` and ``allow_world_readable_tmpfiles`` are both enabled, it is unlikely that the world-readable fallback will ever trigger, and yet Ansible might still be unable to access the module file. This is because after the group ownership change is successful, Ansible does not fall back any further, and also does not do any check to ensure that the ``become_user`` is actually a member of the \"common group\". This is a design decision made by the fact that doing such a check would require another round-trip connection to the remote machine, which is a time-expensive operation. Ansible does, however, emit a warning in this case." +msgstr "上記のように、``ansible_common_remote_group`` と ``allow_world_readable_tmpfiles`` の両方が有効になると、誰でも読み取り可能なフォールバックがトリガーされず、Ansible がまだモジュールファイルにアクセスできない可能性があります。これは、グループの所有権変更が成功した後に、Ansible はこれ以上フォールバックせず、``become_user`` が実際には「共通グループ」のメンバーであることを確認するためのチェックが行われないためですこれは、このようなチェックを行うと、リモートマシンへの別のラウンドトリップ接続が必要になり、時間のかかる操作になってしまうことを考慮した設計上の決定です。しかし、Ansible はこの場合、警告を発します。" + +#: ../../rst/user_guide/become.rst:234 +msgid "Not supported by all connection plugins" +msgstr "すべての connection プラグインでサポートされない" + +#: ../../rst/user_guide/become.rst:236 +msgid "Privilege escalation methods must also be supported by the connection plugin used. Most connection plugins will warn if they do not support become. Some will just ignore it as they always run as root (jail, chroot, and so on)." +msgstr "特権昇格の方法は、使用する connection プラグインがサポートしている必要があります。ほとんどの connection プラグインは、become をサポートしていないと警告を表示します。一部の connection プラグインでは、常に root として実行されるため (jail、chroot など)、無視されます。" + +#: ../../rst/user_guide/become.rst:241 +msgid "Only one method may be enabled per host" +msgstr "ホストごとに有効にできる方法は 1 つだけ" + +#: ../../rst/user_guide/become.rst:243 +msgid "Methods cannot be chained. You cannot use ``sudo /bin/su -`` to become a user, you need to have privileges to run the command as that user in sudo or be able to su directly to it (the same for pbrun, pfexec or other supported methods)." +msgstr "メソッドを連鎖させることはできません。``sudo /bin/su -`` を使用してユーザーになる (become) ことはできません。そのユーザーとして sudo でコマンドを実行するか、直接 su できるような権限が必要です (pbrun、pfexec、その他のサポートされている方法も同様です)。" + +#: ../../rst/user_guide/become.rst:248 +msgid "Privilege escalation must be general" +msgstr "特権昇格は一般的なものにすること" + +#: ../../rst/user_guide/become.rst:250 +msgid "You cannot limit privilege escalation permissions to certain commands. Ansible does not always use a specific command to do something but runs modules (code) from a temporary file name which changes every time. If you have '/sbin/service' or '/bin/chmod' as the allowed commands this will fail with ansible as those paths won't match with the temporary file that Ansible creates to run the module. If you have security rules that constrain your sudo/pbrun/doas environment to running specific command paths only, use Ansible from a special account that does not have this constraint, or use AWX or the :ref:`ansible_platform` to manage indirect access to SSH credentials." +msgstr "特権昇格の許可を特定のコマンドに限定することはできません。Ansible は常に特定のコマンドを使用して何かを行うわけではなく、毎回変更される一時ファイル名からモジュール (コード) を実行します。許可されるコマンドとして「/sbin/service」や「/bin/chmod」を指定した場合、これらのパスは Ansible がモジュールを実行するために作成する一時ファイルと一致しないため、Ansible では失敗します。sudo/pbrun/doas 環境で特定のコマンドパスしか実行できないようなセキュリティールールがある場合は、この制約を受けない特別なアカウントで Ansible を使用するか、AWX または :ref:`ansible_platform` を使用して SSH 認証情報への間接的なアクセスを管理してください。" + +#: ../../rst/user_guide/become.rst:261 +msgid "May not access environment variables populated by pamd_systemd" +msgstr "pamd_systemd が設定する環境変数にアクセスできない場合" + +#: ../../rst/user_guide/become.rst:263 +msgid "For most Linux distributions using ``systemd`` as their init, the default methods used by ``become`` do not open a new \"session\", in the sense of systemd. Because the ``pam_systemd`` module will not fully initialize a new session, you might have surprises compared to a normal session opened through ssh: some environment variables set by ``pam_systemd``, most notably ``XDG_RUNTIME_DIR``, are not populated for the new user and instead inherited or just emptied." +msgstr "``systemd`` を init として使用しているほとんどの Linux ディストリビューションでは、``become`` が使用するデフォルトの方法では、systemd の意味での新しい「セッション」を開くことができません。``pam_systemd`` モジュールは新しいセッションを完全には初期化しないため、ssh で開いた通常のセッションと比べて驚くことがあるかもしれません。``pam_systemd`` によって設定されたいくつかの環境変数、特に ``XDG_RUNTIME_DIR`` は新しいユーザーには設定されず、代わりに継承されたり、単に空になったりします。" + +#: ../../rst/user_guide/become.rst:271 +msgid "This might cause trouble when trying to invoke systemd commands that depend on ``XDG_RUNTIME_DIR`` to access the bus:" +msgstr "このため、バスへのアクセスを ``XDG_RUNTIME_DIR`` に依存する systemd コマンドを呼び出す際に問題が発生する可能性があります。" + +#: ../../rst/user_guide/become.rst:281 +msgid "To force ``become`` to open a new systemd session that goes through ``pam_systemd``, you can use ``become_method: machinectl``." +msgstr "``become`` に、``pam_systemd`` を通して新しい systemd セッションを開くために、``become_method: machinectl`` を使用することができます。" + +#: ../../rst/user_guide/become.rst:284 +msgid "For more information, see `this systemd issue <https://github.com/systemd/systemd/issues/825#issuecomment-127917622>`_." +msgstr "詳細情報は、「`this systemd issue <https://github.com/systemd/systemd/issues/825#issuecomment-127917622>`_」を参照してください。" + +#: ../../rst/user_guide/become.rst:288 +msgid "Resolving Temporary File Error Messsages" +msgstr "一時的なファイルエラーメッセージの解決" + +#: ../../rst/user_guide/become.rst:290 +msgid "Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user\"" +msgstr "非特権ユーザーになる場合に Ansible が作成する必要のある一時ファイルに権限を設定できませんでした" + +#: ../../rst/user_guide/become.rst:291 +msgid "This error can be resolved by installing the package that provides the ``setfacl`` command. (This is frequently the ``acl`` package but check your OS documentation.)" +msgstr "このエラーは、``setfacl`` コマンドを提供するパッケージをインストールすることで解決できます (多くの場合、これは``acl``パッケージ ですが、OS ドキュメントを確認してください)。" + +#: ../../rst/user_guide/become.rst:296 +msgid "Become and network automation" +msgstr "become およびネットワーク自動化" + +#: ../../rst/user_guide/become.rst:298 +msgid "As of version 2.6, Ansible supports ``become`` for privilege escalation (entering ``enable`` mode or privileged EXEC mode) on all Ansible-maintained network platforms that support ``enable`` mode. Using ``become`` replaces the ``authorize`` and ``auth_pass`` options in a ``provider`` dictionary." +msgstr "バージョン 2.6 以降、Ansible は、``enable`` モードをサポートするすべての Ansible が保守するネットワークプラットフォームにおいて、特権昇格 (``enable`` モードまたは特権 EXEC モードへの移行) のために ``become`` をサポートしています。``become`` を使用すると、``provider`` ディクショナリーの ``authorize`` オプションおよび ``auth_pass`` のオプションが置き換えられます。" + +#: ../../rst/user_guide/become.rst:300 +msgid "You must set the connection type to either ``connection: ansible.netcommon.network_cli`` or ``connection: ansible.netcommon.httpapi`` to use ``become`` for privilege escalation on network devices. Check the :ref:`platform_options` documentation for details." +msgstr "ネットワークデバイスの特権昇格に ``become`` を使用するには、接続タイプを ``connection: ansible.netcommon.network_cli`` または ``connection: ansible.netcommon.httpapi`` のいずれかに設定する必要があります。詳細については、「:ref:`platform_options`」を確認してください。" + +#: ../../rst/user_guide/become.rst:302 +msgid "You can use escalated privileges on only the specific tasks that need them, on an entire play, or on all plays. Adding ``become: yes`` and ``become_method: enable`` instructs Ansible to enter ``enable`` mode before executing the task, play, or playbook where those parameters are set." +msgstr "昇格した権限は、それを必要とする特定のタスクのみ、プレイ全体でのみ、またはすべてのプレイで使用することができます。``become: yes`` と ``become_method: enable`` を追加すると、これらのパラメーターが設定されているタスク、プレイ、または Playbook を実行する前に、``enable`` モードに入るよう Ansible に指示します。" + +#: ../../rst/user_guide/become.rst:304 +msgid "If you see this error message, the task that generated it requires ``enable`` mode to succeed:" +msgstr "このエラーメッセージが表示された場合に、エラーメッセージを生成したタスクを成功させるには、``enable`` モードが必要になります。" + +#: ../../rst/user_guide/become.rst:310 +msgid "To set ``enable`` mode for a specific task, add ``become`` at the task level:" +msgstr "特定のタスクに ``enable`` モードを設定するには、タスクレベルで ``become`` を追加します。" + +#: ../../rst/user_guide/become.rst:321 +msgid "To set enable mode for all tasks in a single play, add ``become`` at the play level:" +msgstr "1 つのプレイのすべてのタスクに enable モードを設定するには、プレイレベルに ``become`` を追加します。" + +#: ../../rst/user_guide/become.rst:335 +msgid "Setting enable mode for all tasks" +msgstr "すべてのタスクに enable モードの設定" + +#: ../../rst/user_guide/become.rst:337 +msgid "Often you wish for all tasks in all plays to run using privilege mode, that is best achieved by using ``group_vars``:" +msgstr "すべてのプレイのすべてのタスクを特権モードで実行させたいと思うことがよくありますが、そのような場合には、``group_vars`` を使用することが最適です。" + +#: ../../rst/user_guide/become.rst:339 +msgid "**group_vars/eos.yml**" +msgstr "**group_vars/eos.yml**" + +#: ../../rst/user_guide/become.rst:350 +msgid "Passwords for enable mode" +msgstr "enable モードのパスワード" + +#: ../../rst/user_guide/become.rst:352 +msgid "If you need a password to enter ``enable`` mode, you can specify it in one of two ways:" +msgstr "``enable`` モードに入るパスワードが必要な場合は、以下のいずれかの方法で指定できます。" + +#: ../../rst/user_guide/become.rst:354 +msgid "providing the :option:`--ask-become-pass <ansible-playbook --ask-become-pass>` command line option" +msgstr ":option:`--ask-become-pass <ansible-playbook --ask-become-pass>` コマンドラインオプションの指定" + +#: ../../rst/user_guide/become.rst:355 +msgid "setting the ``ansible_become_password`` connection variable" +msgstr "``ansible_become_password`` 接続変数の設定" + +#: ../../rst/user_guide/become.rst:359 +msgid "As a reminder passwords should never be stored in plain text. For information on encrypting your passwords and other secrets with Ansible Vault, see :ref:`vault`." +msgstr "通知パスワードは平文で保存しないでください。Ansible Vault でパスワードやその他の秘密を暗号化する方法は、「:ref:`vault`」を参照してください。" + +#: ../../rst/user_guide/become.rst:362 +msgid "authorize and auth_pass" +msgstr "authorize および auth_pass" + +#: ../../rst/user_guide/become.rst:364 +msgid "Ansible still supports ``enable`` mode with ``connection: local`` for legacy network playbooks. To enter ``enable`` mode with ``connection: local``, use the module options ``authorize`` and ``auth_pass``:" +msgstr "Ansible では、従来のネットワークの Playbook について、``connection: local`` を使用した ``enable`` モードを引き続きサポートしています。``connection: local`` で ``enable`` モードに入るには、モジュールオプション ``authorize`` および ``auth_pass`` を使用します。" + +#: ../../rst/user_guide/become.rst:379 +msgid "We recommend updating your playbooks to use ``become`` for network-device ``enable`` mode consistently. The use of ``authorize`` and of ``provider`` dictionaries will be deprecated in future. Check the :ref:`platform_options` and :ref:`network_modules` documentation for details." +msgstr "ネットワークデバイスの ``enable`` モードに ``become`` を一貫して使用するように Playbook を更新することが推奨されます。``authorize`` および ``provider`` ディクショナリーの使用は、今後は推奨されません。詳細は、「:ref:`platform_options`」および「:ref:`network_modules`」のドキュメントを参照してください。" + +#: ../../rst/user_guide/become.rst:384 +msgid "Become and Windows" +msgstr "Become および Windows" + +#: ../../rst/user_guide/become.rst:386 +msgid "Since Ansible 2.3, ``become`` can be used on Windows hosts through the ``runas`` method. Become on Windows uses the same inventory setup and invocation arguments as ``become`` on a non-Windows host, so the setup and variable names are the same as what is defined in this document." +msgstr "Ansible 2.3 以降、``become`` は ``runas`` メソッドを通じて Windows ホストでも使用できるようになりました。Windows 上の Become は、非 Windows ホスト上の ``become`` と同じインベントリー設定と起動引数を使用するため、設定と変数名はこのドキュメントで定義されているものと同じになります。" + +#: ../../rst/user_guide/become.rst:391 +msgid "While ``become`` can be used to assume the identity of another user, there are other uses for it with Windows hosts. One important use is to bypass some of the limitations that are imposed when running on WinRM, such as constrained network delegation or accessing forbidden system calls like the WUA API. You can use ``become`` with the same user as ``ansible_user`` to bypass these limitations and run commands that are not normally accessible in a WinRM session." +msgstr "``become`` は、別のユーザーの ID を装うために使用することができますが、Windows ホストではそれ以外にも使用方法があります。重要な用途の 1 つは、ネットワーク委譲の制約や、WUA API のような禁止されたシステムコールへのアクセスなど、WinRM 上で実行する際に課される制限の一部を回避することです。``become`` を ``ansible_user`` と同じユーザーで使用すると、これらの制限を回避して、WinRM セッションでは通常アクセスできないコマンドを実行することができます。" + +#: ../../rst/user_guide/become.rst:399 +msgid "On Windows you cannot connect with an underprivileged account and use become to elevate your rights. Become can only be used if your connection account is already an Administrator of the target host." +msgstr "Windows では、権限のないアカウントで接続できず、become を使用して権限を昇格することはできません。become は、接続アカウントがすでにターゲットホストの管理者である場合にのみ使用できます。" + +#: ../../rst/user_guide/become.rst:404 +msgid "Administrative rights" +msgstr "管理者権限" + +#: ../../rst/user_guide/become.rst:406 +msgid "Many tasks in Windows require administrative privileges to complete. When using the ``runas`` become method, Ansible will attempt to run the module with the full privileges that are available to the become user. If it fails to elevate the user token, it will continue to use the limited token during execution." +msgstr "Windows の多くのタスクを完了するには、管理者権限が必要です。``runas`` の become メソッドを使用すると、Ansible は become ユーザーが使用できる全権限でモジュールの実行を試みます。ユーザートークンの昇格に失敗すると、実行中に制限されたトークンを引き続き使用します。" + +#: ../../rst/user_guide/become.rst:411 +msgid "A user must have the ``SeDebugPrivilege`` to run a become process with elevated privileges. This privilege is assigned to Administrators by default. If the debug privilege is not available, the become process will run with a limited set of privileges and groups." +msgstr "ユーザーは、昇格された権限で become プロセスを実行するには、``SeDebugPrivilege`` が必要です。この権限はデフォルトで管理者に割り当てられます。デバッグ権限が利用できない場合、become プロセスは、限られた一連の特権およびグループで実行されます。" + +#: ../../rst/user_guide/become.rst:416 +msgid "To determine the type of token that Ansible was able to get, run the following task:" +msgstr "Ansible が取得できたトークンの種類を確認するには、以下のタスクを実行します。" + +#: ../../rst/user_guide/become.rst:425 +msgid "The output will look something similar to the below:" +msgstr "出力は以下のようになります。" + +#: ../../rst/user_guide/become.rst:513 +msgid "Under the ``label`` key, the ``account_name`` entry determines whether the user has Administrative rights. Here are the labels that can be returned and what they represent:" +msgstr "``label`` キーにおいて、``account_name`` エントリーは、ユーザーに管理権限があるかどうかを判断します。ここでは、返すことができるラベルと、そのラベルが表す内容を紹介します。" + +#: ../../rst/user_guide/become.rst:517 +msgid "``Medium``: Ansible failed to get an elevated token and ran under a limited token. Only a subset of the privileges assigned to user are available during the module execution and the user does not have administrative rights." +msgstr "``Medium``: Ansible が昇格したトークンの取得に失敗し、制限付きのトークンで実行されました。モジュールの実行中に、ユーザーに割り当てられた特権のサブセットのみが利用可能で、ユーザーは管理者権限を持っていません。" + +#: ../../rst/user_guide/become.rst:521 +msgid "``High``: An elevated token was used and all the privileges assigned to the user are available during the module execution." +msgstr "``High``: 昇格されたトークンが使用され、ユーザーに割り当てられたすべての特権は、モジュールの実行時に利用できます。" + +#: ../../rst/user_guide/become.rst:524 +msgid "``System``: The ``NT AUTHORITY\\System`` account is used and has the highest level of privileges available." +msgstr "``System``: ``NT AUTHORITY\\System`` アカウントが使用され、利用可能な最高レベルの特権が付与されます。" + +#: ../../rst/user_guide/become.rst:527 +msgid "The output will also show the list of privileges that have been granted to the user. When the privilege value is ``disabled``, the privilege is assigned to the logon token but has not been enabled. In most scenarios these privileges are automatically enabled when required." +msgstr "出力には、ユーザーに付与される権限の一覧が表示されます。権限の値が ``disabled`` の場合、特権はログオントークンに割り当てられますが、有効になっていません。ほとんどのシナリオでは、これらの特権は必要に応じて自動的に有効になります。" + +#: ../../rst/user_guide/become.rst:532 +msgid "If running on a version of Ansible that is older than 2.5 or the normal ``runas`` escalation process fails, an elevated token can be retrieved by:" +msgstr "Ansible のバージョンが 2.5 よりも古い場合や、通常の ``runas`` のエスカレーションプロセスが失敗した場合は、昇格したトークンを以下の方法で取得できます。" + +#: ../../rst/user_guide/become.rst:535 +msgid "Set the ``become_user`` to ``System`` which has full control over the operating system." +msgstr "``become_user`` を、オペレーティングシステムを完全にコントロールする ``System`` に設定します。" + +#: ../../rst/user_guide/become.rst:538 +msgid "Grant ``SeTcbPrivilege`` to the user Ansible connects with on WinRM. ``SeTcbPrivilege`` is a high-level privilege that grants full control over the operating system. No user is given this privilege by default, and care should be taken if you grant this privilege to a user or group. For more information on this privilege, please see `Act as part of the operating system <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn221957(v=ws.11)>`_. You can use the below task to set this privilege on a Windows host:" +msgstr "Ansible が WinRM で接続するユーザーに ``SeTcbPrivilege`` を付与します。``SeTcbPrivilege`` は、オペレーティングシステムに対する完全な制御を付与する高レベルの特権です。デフォルトでは、この特権は指定されていません。この特権をユーザーまたはグループに付与する場合は注意が必要です。この特権の詳細は、「`Act as part of the operating system <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn221957(v=ws.11)>`_」を参照してください。以下のタスクを使用して、Windows ホストでこの特権を設定できます。" + +#: ../../rst/user_guide/become.rst:554 +msgid "Turn UAC off on the host and reboot before trying to become the user. UAC is a security protocol that is designed to run accounts with the ``least privilege`` principle. You can turn UAC off by running the following tasks:" +msgstr "そのユーザーになる (become) 前に、ホストで UAC をオフにし、再起動します。UAC は、``least privilege`` プリンシパルでアカウントを実行するように設計されたセキュリティープロトコルです。以下のタスクを実行して UAC をオフにすることができます。" + +#: ../../rst/user_guide/become.rst:574 +msgid "Granting the ``SeTcbPrivilege`` or turning UAC off can cause Windows security vulnerabilities and care should be given if these steps are taken." +msgstr "``SeTcbPrivilege`` を付与するか UAC をオフにすると、Windows のセキュリティー上の脆弱性を引き起こす可能性があるため、このような手順を実行する場合は注意が必要です。" + +#: ../../rst/user_guide/become.rst:578 +msgid "Local service accounts" +msgstr "ローカルサービスアカウント" + +#: ../../rst/user_guide/become.rst:580 +msgid "Prior to Ansible version 2.5, ``become`` only worked on Windows with a local or domain user account. Local service accounts like ``System`` or ``NetworkService`` could not be used as ``become_user`` in these older versions. This restriction has been lifted since the 2.5 release of Ansible. The three service accounts that can be set under ``become_user`` are:" +msgstr "Ansible バージョン 2.5 より前のバージョンでは、``become`` は、Windows でローカルまたはドメインのユーザーアカウントでのみ動作していました。``System`` や ``NetworkService`` などのローカルサービスアカウントは、これらの旧バージョンでは ``become_user`` として使用できません。この制限は、Ansible 2.5 のリリース以降は解除されました。``become_user`` に設定できる 3 つのサービスアカウントは以下のとおりです。" + +#: ../../rst/user_guide/become.rst:586 +msgid "System" +msgstr "システム" + +#: ../../rst/user_guide/become.rst:587 +msgid "NetworkService" +msgstr "NetworkService" + +#: ../../rst/user_guide/become.rst:588 +msgid "LocalService" +msgstr "LocalService" + +#: ../../rst/user_guide/become.rst:590 +msgid "Because local service accounts do not have passwords, the ``ansible_become_password`` parameter is not required and is ignored if specified." +msgstr "ローカルサービスアカウントはパスワードを持たないため、``ansible_become_password`` パラメーターは必須ではなく、指定しても無視されます。" + +#: ../../rst/user_guide/become.rst:595 +msgid "Become without setting a password" +msgstr "パスワードを設定しない Become" + +#: ../../rst/user_guide/become.rst:597 +msgid "As of Ansible 2.8, ``become`` can be used to become a Windows local or domain account without requiring a password for that account. For this method to work, the following requirements must be met:" +msgstr "Ansible 2.8 では、Windows のローカルまたはドメインアカウントになるために、そのアカウントのパスワードがなくても ``become`` を使用することができます。この方法を行うには、以下の要件を満たす必要があります。" + +#: ../../rst/user_guide/become.rst:601 +msgid "The connection user has the ``SeDebugPrivilege`` privilege assigned" +msgstr "接続ユーザーに ``SeDebugPrivilege`` 権限が割り当てられている" + +#: ../../rst/user_guide/become.rst:602 +msgid "The connection user is part of the ``BUILTIN\\Administrators`` group" +msgstr "接続ユーザーが ``BUILTIN\\Administrators`` グループに属している" + +#: ../../rst/user_guide/become.rst:603 +msgid "The ``become_user`` has either the ``SeBatchLogonRight`` or ``SeNetworkLogonRight`` user right" +msgstr "``become_user`` に、``SeBatchLogonRight`` または ``SeNetworkLogonRight`` のユーザー権限がある" + +#: ../../rst/user_guide/become.rst:605 +msgid "Using become without a password is achieved in one of two different methods:" +msgstr "パスワードなしの become は、次のいずれかの方法で使用できます。" + +#: ../../rst/user_guide/become.rst:607 +msgid "Duplicating an existing logon session's token if the account is already logged on" +msgstr "アカウントがすでにログオンしている場合は、既存のログオンセッションのトークンを複製する" + +#: ../../rst/user_guide/become.rst:608 +msgid "Using S4U to generate a logon token that is valid on the remote host only" +msgstr "S4U を使用してリモートホストでのみ有効なログイントークンを生成する" + +#: ../../rst/user_guide/become.rst:610 +msgid "In the first scenario, the become process is spawned from another logon of that user account. This could be an existing RDP logon, console logon, but this is not guaranteed to occur all the time. This is similar to the ``Run only when user is logged on`` option for a Scheduled Task." +msgstr "最初のシナリオでは、そのユーザーアカウントの別のログオンから become プロセスを起動します。これは既存の RDP ログイン、コンソールログオンですが、これは常に発生するとは限りません。これは、スケジュール済みタスクの ``Run only when user is logged on`` オプションと類似しています。" + +#: ../../rst/user_guide/become.rst:615 +msgid "In the case where another logon of the become account does not exist, S4U is used to create a new logon and run the module through that. This is similar to the ``Run whether user is logged on or not`` with the ``Do not store password`` option for a Scheduled Task. In this scenario, the become process will not be able to access any network resources like a normal WinRM process." +msgstr "become アカウントの別のログオンが存在しない場合は、S4U を使用して新しいログオンを作成し、それを介してモジュールを実行します。これは、スケジュール済みタスクの ``Do not store password`` オプションを持つ ``Run whether user is logged on or not`` と似ています。このシナリオでは、become プロセスは通常の WinRM プロセスなどのネットワークリソースにアクセスできません。" + +#: ../../rst/user_guide/become.rst:621 +msgid "To make a distinction between using become with no password and becoming an account that has no password make sure to keep ``ansible_become_password`` as undefined or set ``ansible_become_password:``." +msgstr "パスワードなしで become を使用することと、パスワードがないアカウントになる (become) ことを区別するには、``ansible_become_password`` を undefined にしておくか、``ansible_become_password:`` を設定してください。" + +#: ../../rst/user_guide/become.rst:625 +msgid "Because there are no guarantees an existing token will exist for a user when Ansible runs, there's a high change the become process will only have access to local resources. Use become with a password if the task needs to access network resources" +msgstr "Ansible の実行時に既存のトークンがユーザーに存在するという保証がないため、become プロセスがローカルリソースにのみアクセスできます。タスクがネットワークリソースにアクセスする必要がある場合は、パスワードで become を使用します。" + +#: ../../rst/user_guide/become.rst:631 +msgid "Accounts without a password" +msgstr "パスワードのないアカウント" + +#: ../../rst/user_guide/become.rst:633 +msgid "As a general security best practice, you should avoid allowing accounts without passwords." +msgstr "セキュリティーに関する一般的なベストプラクティスとして、パスワードのないアカウントを許可しないでください。" + +#: ../../rst/user_guide/become.rst:635 +msgid "Ansible can be used to become a Windows account that does not have a password (like the ``Guest`` account). To become an account without a password, set up the variables like normal but set ``ansible_become_password: ''``." +msgstr "Ansible を使用して、パスワードがない Windows アカウントになります (``Guest`` アカウントなど)。パスワードのないアカウントになるには、通常どおり変数を設定しますが、``ansible_become_password: ''`` を設定します。" + +#: ../../rst/user_guide/become.rst:639 +msgid "Before become can work on an account like this, the local policy `Accounts: Limit local account use of blank passwords to console logon only <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj852174(v=ws.11)>`_ must be disabled. This can either be done through a Group Policy Object (GPO) or with this Ansible task:" +msgstr "このようなアカウントで become を有効にする前に、ローカルポリシー `Accounts: Limit local account use of blank passwords to console logon only <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj852174(v=ws.11)>`_ を無効にする必要があります。これは Group Policy Object (GPO) またはこの Ansible タスクで実行できます。" + +#: ../../rst/user_guide/become.rst:654 +msgid "This is only for accounts that do not have a password. You still need to set the account's password under ``ansible_become_password`` if the become_user has a password." +msgstr "これは、パスワードがないアカウント専用です。become_user にパスワードがある場合は、``ansible_become_password`` でアカウントのパスワードを設定する必要があります。" + +#: ../../rst/user_guide/become.rst:659 +msgid "Become flags for Windows" +msgstr "Windows での Become フラグ" + +#: ../../rst/user_guide/become.rst:661 +msgid "Ansible 2.5 added the ``become_flags`` parameter to the ``runas`` become method. This parameter can be set using the ``become_flags`` task directive or set in Ansible's configuration using ``ansible_become_flags``. The two valid values that are initially supported for this parameter are ``logon_type`` and ``logon_flags``." +msgstr "Ansible 2.5 では、``become_flags`` パラメーターを become メソッド ``runas`` に追加しました。このパラメーターは、``become_flags`` タスクディレクティブを使用するか、``ansible_become_flags`` を使用して Ansible の設定で設定できます。このパラメーターで最初にサポートされる 2 つの有効な値は ``logon_type`` と ``logon_flags`` です。" + +#: ../../rst/user_guide/become.rst:667 +msgid "These flags should only be set when becoming a normal user account, not a local service account like LocalSystem." +msgstr "これらのフラグは、LocalSystem などのローカルサービスアカウントではなく、通常のユーザーアカウントになる (become) 場合にのみ設定する必要があります。" + +#: ../../rst/user_guide/become.rst:669 +msgid "The key ``logon_type`` sets the type of logon operation to perform. The value can be set to one of the following:" +msgstr "鍵 ``logon_type`` は、実行するログオン操作のタイプを設定します。値は以下のいずれかに設定できます。" + +#: ../../rst/user_guide/become.rst:672 +msgid "``interactive``: The default logon type. The process will be run under a context that is the same as when running a process locally. This bypasses all WinRM restrictions and is the recommended method to use." +msgstr "``interactive``: デフォルトのログオンタイプ。プロセスは、ローカルでプロセスを実行するときと同じコンテキストで実行されます。これにより、すべての WinRM 制限が回避され、推奨される方法です。" + +#: ../../rst/user_guide/become.rst:676 +msgid "``batch``: Runs the process under a batch context that is similar to a scheduled task with a password set. This should bypass most WinRM restrictions and is useful if the ``become_user`` is not allowed to log on interactively." +msgstr "``batch``: パスワードセットを使用してスケジュールされたタスクに似たバッチコンテキストでプロセスを実行します。これにより、ほとんどの WinRM 制限を回避する必要があり、``become_user`` が対話的にログインできない場合に役立ちます。" + +#: ../../rst/user_guide/become.rst:681 +msgid "``new_credentials``: Runs under the same credentials as the calling user, but outbound connections are run under the context of the ``become_user`` and ``become_password``, similar to ``runas.exe /netonly``. The ``logon_flags`` flag should also be set to ``netcredentials_only``. Use this flag if the process needs to access a network resource (like an SMB share) using a different set of credentials." +msgstr "``new_credentials``: 呼び出し元ユーザーと同じ認証情報の下で実行されますが、発信側の接続は ``runas.exe /netonly`` と同様に ``become_user`` と ``become_password`` のコンテキストの下で実行されます。``logon_flags`` フラグは、``netcredentials_only`` にも設定する必要があります。このフラグは、プロセスが異なる認証情報セットを使用してネットワークリソース (SMB 共有など) にアクセスする必要がある場合に使用します。" + +#: ../../rst/user_guide/become.rst:688 +msgid "``network``: Runs the process under a network context without any cached credentials. This results in the same type of logon session as running a normal WinRM process without credential delegation, and operates under the same restrictions." +msgstr "``network``: キャッシュされた認証情報なしで、ネットワークコンテキストでプロセスを実行します。これにより、認証情報の委譲を使用せずに通常の WinRM プロセスを実行するのと同じ種類のログオンセッションが実行され、同じ制限で動作します。" + +#: ../../rst/user_guide/become.rst:693 +msgid "``network_cleartext``: Like the ``network`` logon type, but instead caches the credentials so it can access network resources. This is the same type of logon session as running a normal WinRM process with credential delegation." +msgstr "``network_cleartext``: ``network`` ログオンタイプなのですが、代わりに認証情報をキャッシュするため、ネットワークリソースにアクセスできます。これは、認証情報の委譲を使用して通常の WinRM プロセスを実行するのと同じタイプのログオンセッションです。" + +#: ../../rst/user_guide/become.rst:697 +msgid "For more information, see `dwLogonType <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-logonusera>`_." +msgstr "詳細情報は、「`dwLogonType <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-logonusera>`_」を参照してください。" + +#: ../../rst/user_guide/become.rst:700 +msgid "The ``logon_flags`` key specifies how Windows will log the user on when creating the new process. The value can be set to none or multiple of the following:" +msgstr "``logon_flags`` キーは、新規プロセスの作成時に Windows がユーザーをログに記録する方法を指定します。この値は、以下の複数の値に設定でき、値を設定しないこともできます。" + +#: ../../rst/user_guide/become.rst:703 +msgid "``with_profile``: The default logon flag set. The process will load the user's profile in the ``HKEY_USERS`` registry key to ``HKEY_CURRENT_USER``." +msgstr "``with_profile``: デフォルトのログオンフラグセット。このプロセスは、``HKEY_USERS`` レジストリーキーのユーザーのプロファイルを ``HKEY_CURRENT_USER`` に読み込みます。" + +#: ../../rst/user_guide/become.rst:706 +msgid "``netcredentials_only``: The process will use the same token as the caller but will use the ``become_user`` and ``become_password`` when accessing a remote resource. This is useful in inter-domain scenarios where there is no trust relationship, and should be used with the ``new_credentials`` ``logon_type``." +msgstr "``netcredentials_only``: プロセスは呼び出し元と同じトークンを使用しますが、リモートリソースにアクセスする際には ``become_user`` と ``become_password`` を使用します。これは、信頼関係がないドメイン間シナリオで便利です。また、``new_credentials`` ``logon_type`` と共に使用する必要があります。" + +#: ../../rst/user_guide/become.rst:711 +msgid "By default ``logon_flags=with_profile`` is set, if the profile should not be loaded set ``logon_flags=`` or if the profile should be loaded with ``netcredentials_only``, set ``logon_flags=with_profile,netcredentials_only``." +msgstr "デフォルトでは ``logon_flags=with_profile`` が設定されていますが、プロファイルを読み込む必要がない場合は ``logon_flags=`` を設定するか、``netcredentials_only`` でプロファイルを読み込む必要がある場合は``logon_flags=with_profile,netcredentials_only`` を設定してください。" + +#: ../../rst/user_guide/become.rst:715 +msgid "For more information, see `dwLogonFlags <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-createprocesswithtokenw>`_." +msgstr "詳細情報は、「`dwLogonFlags <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-createprocesswithtokenw>`_」を参照してください。" + +#: ../../rst/user_guide/become.rst:717 +msgid "Here are some examples of how to use ``become_flags`` with Windows tasks:" +msgstr "Windows タスクで ``become_flags`` を使用する例を以下に示します。" + +#: ../../rst/user_guide/become.rst:745 +msgid "Limitations of become on Windows" +msgstr "Windows における become 制限" + +#: ../../rst/user_guide/become.rst:747 +msgid "Running a task with ``async`` and ``become`` on Windows Server 2008, 2008 R2 and Windows 7 only works when using Ansible 2.7 or newer." +msgstr "Windows Server 2008、2008 R2、Windows 7 で ``async`` および ``become`` を使用してタスクを実行できるのは、Ansible 2.7 以降を使用している場合のみです。" + +#: ../../rst/user_guide/become.rst:750 +msgid "By default, the become user logs on with an interactive session, so it must have the right to do so on the Windows host. If it does not inherit the ``SeAllowLogOnLocally`` privilege or inherits the ``SeDenyLogOnLocally`` privilege, the become process will fail. Either add the privilege or set the ``logon_type`` flag to change the logon type used." +msgstr "デフォルトでは、become ユーザーは対話型セッションでログオンするため、Windows ホストでこの権限を設定する必要があります。``SeAllowLogOnLocally`` 特権を継承しない場合、または ``SeDenyLogOnLocally`` 特権を継承する場合は become プロセスに失敗します。特権を追加するか、``logon_type`` フラグを設定して使用するログオンタイプを変更してください。" + +#: ../../rst/user_guide/become.rst:756 +msgid "Prior to Ansible version 2.3, become only worked when ``ansible_winrm_transport`` was either ``basic`` or ``credssp``. This restriction has been lifted since the 2.4 release of Ansible for all hosts except Windows Server 2008 (non R2 version)." +msgstr "Ansible バージョン 2.3 よりも前のバージョンでは、``ansible_winrm_transport`` が ``basic`` または ``credssp`` のいずれかでのみ機能していました。この制限は、Windows Server 2008 (R2 バージョン以外) を除くすべてのホストで 2.4 リリース以降に取り込まれました。" + +#: ../../rst/user_guide/become.rst:761 +msgid "The Secondary Logon service ``seclogon`` must be running to use ``ansible_become_method: runas``" +msgstr "``ansible_become_method: runas`` を使用するには、セカンダリーログオンサービス ``seclogon`` が実行している必要があります。" + +#: ../../rst/user_guide/become.rst:763 +msgid "The connection user must already be an Administrator on the Windows host to use ``runas``. The target become user does not need to be an Administrator though." +msgstr "``runas`` を使用するには、接続ユーザーがすでに Windows ホストの管理者である必要があります。ターゲット become ユーザーは管理者である必要はありません。" + +#: ../../rst/user_guide/become.rst:770 +msgid "`Mailing List <https://groups.google.com/forum/#!forum/ansible-project>`_" +msgstr "`Mailing List <https://groups.google.com/forum/#!forum/ansible-project>`_" + +#: ../../rst/user_guide/become.rst:771 ../../rst/user_guide/intro_adhoc.rst:210 +#: ../../rst/user_guide/intro_bsd.rst:276 +#: ../../rst/user_guide/intro_dynamic_inventory.rst:251 +#: ../../rst/user_guide/intro_inventory.rst:795 +#: ../../rst/user_guide/intro_patterns.rst:225 +#: ../../rst/user_guide/modules.rst:34 +#: ../../rst/user_guide/modules_intro.rst:60 +#: ../../rst/user_guide/modules_support.rst:68 +#: ../../rst/user_guide/playbooks_best_practices.rst:181 +#: ../../rst/user_guide/playbooks_intro.rst:159 +#: ../../rst/user_guide/playbooks_reuse.rst:226 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:32 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:611 +#: ../../rst/user_guide/sample_setup.rst:297 +msgid "Questions? Help? Ideas? Stop by the list on Google Groups" +msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" + +#: ../../rst/user_guide/become.rst:772 +#: ../../rst/user_guide/collections_using.rst:433 +#: ../../rst/user_guide/intro_adhoc.rst:211 +#: ../../rst/user_guide/intro_bsd.rst:277 +#: ../../rst/user_guide/intro_dynamic_inventory.rst:252 +#: ../../rst/user_guide/intro_inventory.rst:796 +#: ../../rst/user_guide/intro_patterns.rst:226 +#: ../../rst/user_guide/modules.rst:35 +#: ../../rst/user_guide/modules_intro.rst:61 +#: ../../rst/user_guide/modules_support.rst:69 +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:123 +#: ../../rst/user_guide/playbooks_async.rst:188 +#: ../../rst/user_guide/playbooks_blocks.rst:188 +#: ../../rst/user_guide/playbooks_conditionals.rst:535 +#: ../../rst/user_guide/playbooks_debugger.rst:341 +#: ../../rst/user_guide/playbooks_delegation.rst:173 +#: ../../rst/user_guide/playbooks_environment.rst:152 +#: ../../rst/user_guide/playbooks_error_handling.rst:278 +#: ../../rst/user_guide/playbooks_filters.rst:2191 +#: ../../rst/user_guide/playbooks_lookups.rst:38 +#: ../../rst/user_guide/playbooks_loops.rst:488 +#: ../../rst/user_guide/playbooks_prompts.rst:123 +#: ../../rst/user_guide/playbooks_strategies.rst:253 +#: ../../rst/user_guide/playbooks_tags.rst:431 +#: ../../rst/user_guide/playbooks_templating.rst:60 +#: ../../rst/user_guide/playbooks_tests.rst:523 +#: ../../rst/user_guide/playbooks_variables.rst:511 +#: ../../rst/user_guide/windows_dsc.rst:505 +#: ../../rst/user_guide/windows_faq.rst:256 +#: ../../rst/user_guide/windows_setup.rst:577 +#: ../../rst/user_guide/windows_usage.rst:516 +#: ../../rst/user_guide/windows_winrm.rst:1008 +msgid ":ref:`communication_irc`" +msgstr ":ref:`communication_irc`" + +#: ../../rst/user_guide/become.rst:773 +#: ../../rst/user_guide/collections_using.rst:434 +#: ../../rst/user_guide/intro_adhoc.rst:212 +#: ../../rst/user_guide/intro_bsd.rst:278 +#: ../../rst/user_guide/intro_dynamic_inventory.rst:253 +#: ../../rst/user_guide/intro_inventory.rst:797 +#: ../../rst/user_guide/intro_patterns.rst:227 +#: ../../rst/user_guide/modules.rst:36 +#: ../../rst/user_guide/modules_intro.rst:62 +#: ../../rst/user_guide/modules_support.rst:70 +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:124 +#: ../../rst/user_guide/playbooks_async.rst:189 +#: ../../rst/user_guide/playbooks_blocks.rst:189 +#: ../../rst/user_guide/playbooks_conditionals.rst:536 +#: ../../rst/user_guide/playbooks_debugger.rst:342 +#: ../../rst/user_guide/playbooks_delegation.rst:174 +#: ../../rst/user_guide/playbooks_environment.rst:153 +#: ../../rst/user_guide/playbooks_error_handling.rst:279 +#: ../../rst/user_guide/playbooks_filters.rst:2192 +#: ../../rst/user_guide/playbooks_lookups.rst:39 +#: ../../rst/user_guide/playbooks_loops.rst:489 +#: ../../rst/user_guide/playbooks_prompts.rst:124 +#: ../../rst/user_guide/playbooks_strategies.rst:254 +#: ../../rst/user_guide/playbooks_tags.rst:432 +#: ../../rst/user_guide/playbooks_templating.rst:61 +#: ../../rst/user_guide/playbooks_tests.rst:524 +#: ../../rst/user_guide/playbooks_variables.rst:512 +#: ../../rst/user_guide/windows_dsc.rst:506 +#: ../../rst/user_guide/windows_faq.rst:257 +#: ../../rst/user_guide/windows_setup.rst:578 +#: ../../rst/user_guide/windows_usage.rst:517 +#: ../../rst/user_guide/windows_winrm.rst:1009 +msgid "How to join Ansible chat channels" +msgstr "Ansible チャットチャンネルへの参加方法" + +#: ../../rst/user_guide/cheatsheet.rst:5 +msgid "Ansible CLI cheatsheet" +msgstr "Ansible CLI のチートシート" + +#: ../../rst/user_guide/cheatsheet.rst:7 +msgid "This page shows one or more examples of each Ansible command line utility with some common flags added and a link to the full documentation for the command. This page offers a quick reminder of some common use cases only - it may be out of date or incomplete or both. For canonical documentation, follow the links to the CLI pages." +msgstr "このページには、一般的なフラグが追加された各 Ansible コマンドラインユーティリティーの 1 つ以上の例と、コマンドの完全なドキュメントへのリンクが表示されます。このページでは、いくつかの一般的なユースケースのクイックリマインダーだけを提供します。このページの情報は、古かったり、不完全だったり、あるいはその両方である可能性があります。正規のドキュメントについては、CLI ページへのリンクに従ってください。" + +#: ../../rst/user_guide/cheatsheet.rst:13 +msgid "ansible-playbook" +msgstr "ansible-playbook" + +#: ../../rst/user_guide/cheatsheet.rst:28 +msgid "Loads ``my_playbook.yml`` from the current working directory and:" +msgstr "現在の作業ディレクトリーから``my_playbook.yml``を読み込みます。ここで、" + +#: ../../rst/user_guide/cheatsheet.rst:20 +msgid "``-i`` - uses ``my_inventory_file`` in the path provided for :ref:`inventory <intro_inventory>` to match the :ref:`pattern <intro_patterns>`." +msgstr "``-i`` - :ref:`インベントリー <intro_inventory>` に指定されるパスの``my_inventory_file`` を使用して、:ref:`パターン <intro_patterns>` を照合します。" + +#: ../../rst/user_guide/cheatsheet.rst:21 +msgid "``-u`` - connects :ref:`over SSH <connections>` as ``my_connection_user``." +msgstr "``-u`` - ``my_connection_user`` として :ref:`SSH 経由で <connections>` 接続します。" + +#: ../../rst/user_guide/cheatsheet.rst:22 +msgid "``-k`` - uses ``my_ssh_key`` in the path provided for SSH authentication." +msgstr "``-k`` - SSH 認証に指定されるパスの ``my_ssh_key`` を使用します。" + +#: ../../rst/user_guide/cheatsheet.rst:23 +msgid "``-f`` - allocates 3 :ref:`forks <playbooks_strategies>`." +msgstr "``-f`` - 3 つの:ref:`フォーク <playbooks_strategies>` を割り当てます。" + +#: ../../rst/user_guide/cheatsheet.rst:24 +msgid "``-T`` - sets a 30-second timeout." +msgstr "``-T`` - 30 秒のタイムアウトを設定します。" + +#: ../../rst/user_guide/cheatsheet.rst:25 +msgid "``-t`` - runs only tasks marked with the :ref:`tag <tags>` ``my_tag``." +msgstr "``-t`` - :ref:`タグ <tags>` ``my_tag`` でマークされたタスクのみを実行します。" + +#: ../../rst/user_guide/cheatsheet.rst:26 +msgid "``-m`` - loads :ref:`local modules <developing_locally>` from ``/path/to/my/modules``." +msgstr "``-m`` - ``/path/to/my/modules``から:ref:`ローカルモジュール <developing_locally>` を読み込みます。" + +#: ../../rst/user_guide/cheatsheet.rst:27 +msgid "``-b`` - executes with elevated privileges (uses :ref:`become <become>`)." +msgstr "``-b`` - 権限が昇格された状態で実行します（:ref:`become <become>`を使用）。" + +#: ../../rst/user_guide/cheatsheet.rst:28 +msgid "``-K`` - prompts the user for the become password." +msgstr "``-K`` - ユーザーに対し、become パスワードを要求します。" + +#: ../../rst/user_guide/cheatsheet.rst:30 +msgid "See :ref:`ansible-playbook` for detailed documentation." +msgstr "詳細なドキュメントは、「:ref:`ansible-playbook`」を参照してください。" + +#: ../../rst/user_guide/collections_using.rst:6 +msgid "Using collections" +msgstr "コレクションの使用" + +#: ../../rst/user_guide/collections_using.rst:8 +msgid "Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. As modules move from the core Ansible repository into collections, the module documentation will move to the :ref:`collections pages <list_of_collections>`." +msgstr "コレクションは、Playbook、ロール、モジュール、プラグインなどの Ansible コンテンツの配布形式です。モジュールがコアの Ansible リポジトリーからコレクションに移動したため、モジュールのドキュメントも :ref:`コレクションページ <list_of_collections>` に移動します。" + +#: ../../rst/user_guide/collections_using.rst:10 +msgid "You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_." +msgstr "`Ansible Galaxy <https://galaxy.ansible.com>`_ を使用してコレクションをインストールして使用できます。" + +#: ../../rst/user_guide/collections_using.rst:12 +msgid "For details on how to *develop* collections see :ref:`developing_collections`." +msgstr "*develop* コレクションの使用方法は、「:ref:`developing_collections`」を参照してください。" + +#: ../../rst/user_guide/collections_using.rst:13 +msgid "For the current development status of Collections and FAQ see `Ansible Collections Community Guide <https://github.com/ansible-collections/overview/blob/main/README.rst>`_." +msgstr "コレクションおよび FAQ の現在の開発ステータスは、「`Ansible コレクションのコミュニティーガイド <https://github.com/ansible-collections/overview/blob/main/README.rst>`_」を参照してください。" + +#: ../../rst/user_guide/collections_using.rst:22 +msgid "Installing collections" +msgstr "コレクションのインストール" + +#: ../../rst/user_guide/collections_using.rst:26 +msgid "If you install a collection manually as described in this paragraph, the collection will not be upgraded automatically when you upgrade the ``ansible`` package or ``ansible-core``." +msgstr "この段落で説明されているように、コレクションを手動でインストールした場合には、``ansible`` パッケージまたは ``ansible-core`` をアップグレードしたときに、コレクションが自動的にアップグレードされません。" + +#: ../../rst/user_guide/collections_using.rst:29 +msgid "Installing collections with ``ansible-galaxy``" +msgstr "``ansible-galaxy`` でコレクションのインストール" + +#: ../../rst/shared_snippets/installing_collections.txt:3 +msgid "By default, ``ansible-galaxy collection install`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`). You do not need any further configuration." +msgstr "デフォルトでは、``ansible-galaxy collection install`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。追加設定は必要ありません。" + +#: ../../rst/shared_snippets/installing_collections.txt:7 +msgid "See :ref:`Configuring the ansible-galaxy client <galaxy_server_config>` if you are using any other Galaxy server, such as Red Hat Automation Hub." +msgstr "Red Hat Automation Hub などの他の Galaxy サーバーを使用している場合は、「:ref:`ansible-galaxy クライアントの設定 <galaxy_server_config>`」を参照してください。" + +#: ../../rst/shared_snippets/installing_collections.txt:9 +msgid "To install a collection hosted in Galaxy:" +msgstr "Galaxy でホストされるコレクションをインストールするには、以下を実行します。" + +#: ../../rst/shared_snippets/installing_collections.txt:15 +msgid "To upgrade a collection to the latest available version from the Galaxy server you can use the ``--upgrade`` option:" +msgstr "コレクションを Galaxy サーバーから利用可能な最新バージョンにアップグレードするには、``--upgrade`` オプションを使用します。" + +#: ../../rst/shared_snippets/installing_collections.txt:21 +msgid "You can also directly use the tarball from your build:" +msgstr "ビルドから tarball を直接使用することもできます。" + +#: ../../rst/shared_snippets/installing_collections.txt:27 +msgid "You can build and install a collection from a local source directory. The ``ansible-galaxy`` utility builds the collection using the ``MANIFEST.json`` or ``galaxy.yml`` metadata in the directory." +msgstr "ローカルソースディレクトリーからコレクションを構築してインストールできます。``ansible-galaxy`` ユーティリティーは、ディレクトリー内の ``MANIFEST.json`` または ``galaxy.yml`` メタデータを使用してコレクションを構築します。" + +#: ../../rst/shared_snippets/installing_collections.txt:34 +msgid "You can also install multiple collections in a namespace directory." +msgstr "名前空間ディレクトリーに複数のコレクションをインストールすることもできます。" + +#: ../../rst/shared_snippets/installing_collections.txt:51 +msgid "The install command automatically appends the path ``ansible_collections`` to the one specified with the ``-p`` option unless the parent directory is already in a folder called ``ansible_collections``." +msgstr "install コマンドは、親ディレクトリーが ``ansible_collections`` ディレクトリーに含まれている場合を除き、``-p`` オプションで指定したものに、パス ``ansible_collections`` を自動的に追加します。" + +#: ../../rst/shared_snippets/installing_collections.txt:55 +msgid "When using the ``-p`` option to specify the install path, use one of the values configured in :ref:`COLLECTIONS_PATHS`, as this is where Ansible itself will expect to find collections. If you don't specify a path, ``ansible-galaxy collection install`` installs the collection to the first path defined in :ref:`COLLECTIONS_PATHS`, which by default is ``~/.ansible/collections``" +msgstr "``-p`` オプションを使用してインストールパスを指定する場合は、Ansible 自体がコレクションを見つけることが予想される場所であるため、:ref:`COLLECTIONS_PATHS` に設定された値のいずれかを使用します。パスを指定しないと、``ansible-galaxy collection install`` は、:ref:`COLLECTIONS_PATHS` で定義されている最初のパスにコレクションをインストールします。これは、デフォルトでは ``~/.ansible/collections`` です。" + +#: ../../rst/shared_snippets/installing_collections.txt:59 +msgid "You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure." +msgstr "また、``collections/ansible_collections/`` ディレクトリー構造の下で、コレクションを現在の Playbook の横に維持することもできます。" + +#: ../../rst/shared_snippets/installing_collections.txt:71 +msgid "See :ref:`collection_structure` for details on the collection directory structure." +msgstr "コレクションディレクトリー構造の詳細は、「:ref:`collection_structure`」を参照してください。" + +#: ../../rst/shared_snippets/installing_collections.txt:73 +msgid "Collections signed by a Galaxy server can be verified during installation with GnuPG. To opt into signature verification, configure a keyring for ``ansible-galaxy`` with native GnuPG tooling and provide the file path with the ``--keyring`` CLI option or ref:`GALAXY_GPG_KEYRING`. Signatures provided by the Galaxy server will be used to verify the collection's ``MANIFEST.json``." +msgstr "Galaxy サーバーによって署名されたコレクションは、GnuPG を使用したインストール時に検証できます。署名の検証を選択するには、ネイティブの GnuPG ツールで ``ansible-galaxy`` のキーリングを設定し、``--keyring`` CLI オプションまたは ref:`GALAXY_GPG_KEYRING` でファイルパスを指定します。Galaxy サーバーによって提供される署名は、コレクションの ``MANIFEST.json`` を検証するために使用されます。" + +#: ../../rst/shared_snippets/installing_collections.txt:75 +msgid "Use the ``--signature`` option to verify the collection's ``MANIFEST.json`` with additional signatures to those provided by the Galaxy server. Supplemental signatures should be provided as URIs." +msgstr "``--signature`` オプションを使用して、Galaxy サーバーが提供する追加の署名と共にコレクションの ``MANIFEST.json`` を検証します。追加の署名は URI として指定する必要があります。" + +#: ../../rst/shared_snippets/installing_collections.txt:81 +msgid "GnuPG verification only occurs for collections installed from a Galaxy server. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files." +msgstr "GnuPG 検証は、Galaxy サーバーからインストールされたコレクションでのみ発生します。ユーザーが提供した署名は、git リポジトリー、ソースディレクトリー、または URL/tar.gzファイルへのパスからインストールされたコレクションの検証には使用されません。" + +#: ../../rst/shared_snippets/installing_collections.txt:83 +msgid "By default, verification is considered successful if a minimum of 1 signature successfully verifies the collection. The number of required signatures can be configured with ``--required-valid-signature-count`` or :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`. All signatures can be required by setting the option to ``all``. To fail signature verification if no valid signatures are found, prepend the value with ``+``, such as ``+all`` or ``+1``." +msgstr "デフォルトでは、1 つ以上の署名がコレクションを正常に検証した場合に、検証が成功したとみなされます。必要な署名の数は、``--required-valid-signature-count`` または :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` で設定できます。オプションを ``all`` に設定して、すべての署名を要求できます。有効な署名が見つからない場合に、署名の検証に失敗するには、``+all`` や ``+1`` のように値の前に ``+`` を追加します。" + +#: ../../rst/shared_snippets/installing_collections.txt:91 +msgid "Certain GnuPG errors can be ignored with ``--ignore-signature-status-code`` or :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT`. :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` should be a list, and ``--ignore-signature-status-code`` can be provided multiple times to ignore multiple additional error status codes." +msgstr "特定の GnuPG エラーは ``--ignore-signature-status-code`` または :ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` により無視できます。:ref:`GALAXY_REQUIRED_VALID_SIGNATURE_COUNT` は一覧である必要があり、``--ignore-signature-status-code`` を複数回指定して複数の追加エラーステータスコードを無視することができます。" + +#: ../../rst/shared_snippets/installing_collections.txt:93 +msgid "This example requires any signatures provided by the Galaxy server to verify the collection except if they fail due to NO_PUBKEY:" +msgstr "NO_PUBKEY が原因で失敗しない限り、この例では、コレクションを検証するために Galaxy サーバーが提供する署名が必要です。" + +#: ../../rst/shared_snippets/installing_collections.txt:101 +msgid "If verification fails for the example above, only errors other than NO_PUBKEY will be displayed." +msgstr "上記の例で検証に失敗すると、NO_PUBKEY 以外のエラーのみが表示されます。" + +#: ../../rst/shared_snippets/installing_collections.txt:103 +msgid "If verification is unsuccessful, the collection will not be installed. GnuPG signature verification can be disabled with ``--disable-gpg-verify`` or by configuring :ref:`GALAXY_DISABLE_GPG_VERIFY`." +msgstr "検証に失敗した場合は、コレクションはインストールされません。GnuPG の署名検証は ``--disable-gpg-verify`` で、あるいは :ref:`GALAXY_DISABLE_GPG_VERIFY` を設定して無効にすることができます。" + +#: ../../rst/user_guide/collections_using.rst:36 +msgid "Installing an older version of a collection" +msgstr "古いバージョンのコレクションのインストール" + +#: ../../rst/shared_snippets/installing_older_collection.txt:2 +msgid "You can only have one version of a collection installed at a time. By default ``ansible-galaxy`` installs the latest available version. If you want to install a specific version, you can add a version range identifier. For example, to install the 1.0.0-beta.1 version of the collection:" +msgstr "一度にインストールするコレクションのバージョンは 1 つだけです。デフォルトでは、``ansible-galaxy`` により利用可能な最新バージョンがインストールされます。特定のバージョンをインストールする場合は、バージョン範囲識別子を追加できます。たとえば、コレクションの 1.0.0-beta.1 バージョンをインストールするには、以下を実行します。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:8 +msgid "You can specify multiple range identifiers separated by ``,``. Use single quotes so the shell passes the entire command, including ``>``, ``!``, and other operators, along. For example, to install the most recent version that is greater than or equal to 1.0.0 and less than 2.0.0:" +msgstr "``,`` で区切って複数の範囲識別子を指定できます。シェルが、``>``、``!``、およびその他の演算子を含むコマンド全体を渡すように、一重引用符を使用します。たとえば、1.0.0 以上 2.0.0 未満の最新バージョンをインストールするには、次を実行します。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:14 +msgid "Ansible will always install the most recent version that meets the range identifiers you specify. You can use the following range identifiers:" +msgstr "Ansible は、指定する範囲識別子を満たす最新バージョンを常にインストールします。以下の範囲識別子を使用できます。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:16 +msgid "``*``: The most recent version. This is the default." +msgstr "``*``: 最新バージョンです。これがデフォルトです。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:17 +msgid "``!=``: Not equal to the version specified." +msgstr "``!=``: 指定されたバージョンと同等ではありません。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:18 +msgid "``==``: Exactly the version specified." +msgstr "``==``: 指定されたバージョンそのものになります。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:19 +msgid "``>=``: Greater than or equal to the version specified." +msgstr "``>=``: 指定されたバージョン以上になります。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:20 +msgid "``>``: Greater than the version specified." +msgstr "``>``: 指定されたバージョンよりも大きくなります。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:21 +msgid "``<=``: Less than or equal to the version specified." +msgstr "``<=``: 指定されたバージョン以下になります。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:22 +msgid "``<``: Less than the version specified." +msgstr "``<``: 指定されたバージョンよりも小さくなります。" + +#: ../../rst/shared_snippets/installing_older_collection.txt:25 +msgid "By default ``ansible-galaxy`` ignores pre-release versions. To install a pre-release version, you must use the ``==`` range identifier to require it explicitly." +msgstr "デフォルトでは、``ansible-galaxy`` はリリース前のバージョンを無視します。リリース前のバージョンをインストールするには、``==`` 範囲識別子を使用して明示的に要求する必要があります。" + +#: ../../rst/user_guide/collections_using.rst:43 +msgid "Install multiple collections with a requirements file" +msgstr "要件ファイルを使用した複数のコレクションのインストール" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:2 +msgid "You can set up a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format:" +msgstr "``requirements.yml`` ファイルを設定して、1 つのコマンドで複数のコレクションをインストールできます。このファイルは、以下の形式の YAML ファイルです。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:16 +msgid "You can specify the following keys for each collection entry:" +msgstr "各コレクションエントリーに以下のキーを指定できます。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:18 +msgid "``name``" +msgstr "``name``" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:19 +msgid "``version``" +msgstr "``version``" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:20 +msgid "``signatures``" +msgstr "``signatures``" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:21 +msgid "``source``" +msgstr "``source``" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:22 +msgid "``type``" +msgstr "``type``" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:24 +msgid "The ``version`` key uses the same range identifier format documented in :ref:`collections_older_version`." +msgstr "``version`` キーは、:ref:`collections_older_version` に記載されているものと同じ範囲識別子形式を使用します。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:26 +msgid "The ``signatures`` key accepts a list of signature sources that are used to supplement those found on the Galaxy server during collection installation and ``ansible-galaxy collection verify``. Signature sources should be URIs that contain the detached signature. The ``--keyring`` CLI option must be provided if signatures are specified." +msgstr "``signatures`` キーは、コレクションのインストール時および``ansible-galaxy collection verify``時に Galaxy サーバーで見つけられたものを補足するために使用される署名ソースの一覧を受け入れます。署名ソースは、デタッチされた署名が含まれる URI である必要があります。署名が指定されている場合は、``--keyring`` CLI オプションを指定する必要があります。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:28 +msgid "Signatures are only used to verify collections on Galaxy servers. User-provided signatures are not used to verify collections installed from git repositories, source directories, or URLs/paths to tar.gz files." +msgstr "署名は、Galaxy サーバーのコレクションを検証するためにのみ使用されます。ユーザーが提供した署名は、git リポジトリー、ソースディレクトリー、または URL/tar.gzファイルへのパスからインストールされたコレクションの検証には使用されません。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:40 +msgid "The ``type`` key can be set to ``file``, ``galaxy``, ``git``, ``url``, ``dir``, or ``subdirs``. If ``type`` is omitted, the ``name`` key is used to implicitly determine the source of the collection." +msgstr "``type`` キーは ``file``、``galaxy``、``git``、``url``、``dir``、または ``subdirs`` に設定できます。``type`` を省略すると、``name`` キーを使用してコレクションのソースを暗黙的に決定します。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:42 +msgid "When you install a collection with ``type: git``, the ``version`` key can refer to a branch or to a `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ object (commit or tag). For example:" +msgstr "``type: git`` でコレクションをインストールする場合、``version`` キーはブランチまたは `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ オブジェクト（コミットまたはタグ）を参照できます。以下に例を示します。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:51 +msgid "You can also add roles to a ``requirements.yml`` file, under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases." +msgstr "``roles``キーの下にある``requirements.yml``ファイルにロールを追加することもできます。この値は、古い Ansible リリースで使用される要件ファイルと同じ形式に従います。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:67 +msgid "To install both roles and collections at the same time with one command, run the following:" +msgstr "1 つのコマンドで、ロールとコレクションを同時にインストールするには、以下のコマンドを実行します。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:73 +msgid "Running ``ansible-galaxy collection install -r`` or ``ansible-galaxy role install -r`` will only install collections, or roles respectively." +msgstr "``ansible-galaxy collection install -r`` または ``ansible-galaxy role install -r`` を実行すると、それぞれコレクションまたはロールがインストールされます。" + +#: ../../rst/shared_snippets/installing_multiple_collections.txt:76 +msgid "Installing both roles and collections from the same requirements file will not work when specifying a custom collection or role install path. In this scenario the collections will be skipped and the command will process each like ``ansible-galaxy role install`` would." +msgstr "カスタムコレクションまたはロールインストールパスを指定する場合、同じ要件ファイルからロールとコレクションの両方をインストールすることはできません。今回の例では、コレクションは省略され、コマンドは ``ansible-galaxy role install`` のように処理されます。" + +#: ../../rst/user_guide/collections_using.rst:50 +msgid "Downloading a collection for offline use" +msgstr "オフラインで使用するコレクションのダウンロード" + +#: ../../rst/shared_snippets/download_tarball_collections.txt:3 +msgid "To download the collection tarball from Galaxy for offline use:" +msgstr "オフラインで使用するために、コレクション tarball を Galaxy からダウンロードするには、以下を行います。" + +#: ../../rst/shared_snippets/download_tarball_collections.txt:5 +msgid "Navigate to the collection page." +msgstr "コレクションページに移動します。" + +#: ../../rst/shared_snippets/download_tarball_collections.txt:6 +msgid "Click on :guilabel:`Download tarball`." +msgstr ":guilabel:`Download tarball` をクリックします。" + +#: ../../rst/shared_snippets/download_tarball_collections.txt:8 +msgid "You may also need to manually download any dependent collections." +msgstr "また、依存するコレクションを手動でダウンロードする必要がある場合があります。" + +#: ../../rst/user_guide/collections_using.rst:55 +msgid "Installing a collection from source files" +msgstr "ソースファイルからのコレクションのインストール" + +#: ../../rst/shared_snippets/installing_collections_file.rst:1 +msgid "Ansible can also install from a source directory in several ways:" +msgstr "Ansible は、複数の方法でソースディレクトリーからインストールすることもできます。" + +#: ../../rst/shared_snippets/installing_collections_file.rst:14 +msgid "Ansible can also install a collection collected with ``ansible-galaxy collection build`` or downloaded from Galaxy for offline use by specifying the output file directly:" +msgstr "出力ファイルを直接指定して、Ansible は``ansible-galaxy collection build`` で収集したコレクションまたは Galaxy からダウンロードしたコレクションをオフライン用にインストールすることもできます。" + +#: ../../rst/shared_snippets/installing_collections_file.rst:24 +msgid "Relative paths are calculated from the current working directory (where you are invoking ``ansible-galaxy install -r`` from). They are not taken relative to the ``requirements.yml`` file." +msgstr "相対パスは、現在の作業ディレクトリー（``ansible-galaxy install -r`` を呼び出しているディレクトリー）から計算されます。これは、``requirements.yml`` ファイルからの相対パスではありません。" + +#: ../../rst/user_guide/collections_using.rst:60 +msgid "Installing a collection from a git repository" +msgstr "git リポジトリーからのコレクションのインストール" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:1 +msgid "You can install a collection from a git repository instead of from Galaxy or Automation Hub. As a developer, installing from a git repository lets you review your collection before you create the tarball and publish the collection. As a user, installing from a git repository lets you use collections or versions that are not in Galaxy or Automation Hub yet." +msgstr "コレクションは、Galaxy または Automation Hub の代わりに git リポジトリーからインストールできます。開発者は、git リポジトリーからインストールし、tarball を作成してコレクションを公開する前にコレクションを確認できます。ユーザーとして git リポジトリーからインストールすることで、Galaxy または Automation Hub にないコレクションまたはバージョンを使用できます。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:3 +msgid "The repository must contain a ``galaxy.yml`` or ``MANIFEST.json`` file. This file provides metadata such as the version number and namespace of the collection." +msgstr "リポジトリーには ``galaxy.yml`` または ``MANIFEST.json`` ファイルが含まれている必要があります。このファイルは、コレクションのバージョン番号、namespace などのメタデータを提供します。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:6 +msgid "Installing a collection from a git repository at the command line" +msgstr "コマンドガイドで git リポジトリーからのコレクションのインストール" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:8 +msgid "To install a collection from a git repository at the command line, use the URI of the repository instead of a collection name or path to a ``tar.gz`` file. Use the prefix ``git+``, unless you're using SSH authentication with the user ``git`` (for example, ``git@github.com:ansible-collections/ansible.windows.git``). You can specify a branch, commit, or tag using the comma-separated `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ syntax." +msgstr "git リポジトリーからコレクションをインストールするには、コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーの URI を使用します。ユーザー``git``でSSH認証を使用していない限り、プレフィックス``git+``を使用します(例: ``git@github.com:ansible-collections/ansible.windows.git``)。コンマ区切りの `git コミットのような <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ 構文を使用して、ブランチ、コミット、またはタグを指定できます。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:10 +#: ../../rst/user_guide/intro_patterns.rst:20 +#: ../../rst/user_guide/intro_patterns.rst:33 +#: ../../rst/user_guide/playbooks_checkmode.rst:33 +#: ../../rst/user_guide/playbooks_filters.rst:809 +#: ../../rst/user_guide/playbooks_tags.rst:285 +#: ../../rst/user_guide/playbooks_tags.rst:315 +msgid "For example:" +msgstr "例:" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:25 +msgid "Embedding credentials into a git URI is not secure. Use safe authentication options to prevent your credentials from being exposed in logs or elsewhere." +msgstr "認証情報を git URI に埋め込むことは安全ではありません。安全な認証オプションを使用して、認証情報がログに公開されないようにします。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:27 +msgid "Use `SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_ authentication" +msgstr "`SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_ 認証を使用する" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:28 +msgid "Use `netrc <https://linux.die.net/man/5/netrc>`_ authentication" +msgstr "`netrc <https://linux.die.net/man/5/netrc>`_ 認証を使用する" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:29 +msgid "Use `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_ in your git configuration" +msgstr "お使いの git 設定で `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_ を使用する" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:30 +msgid "Use `url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ in your git configuration" +msgstr "お使いの git 設定で `url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ を使用する" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:33 +msgid "Specifying the collection location within the git repository" +msgstr "git リポジトリー内でのコレクションの場所の指定" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:35 +msgid "When you install a collection from a git repository, Ansible uses the collection ``galaxy.yml`` or ``MANIFEST.json`` metadata file to build the collection. By default, Ansible searches two paths for collection ``galaxy.yml`` or ``MANIFEST.json`` metadata files:" +msgstr "git リポジトリーからコレクションをインストールする場合、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルを使用してコレクションを構築します。デフォルトでは、Ansible はコレクション ``galaxy.yml`` または ``MANIFEST.json`` メタデータファイルの 2 つのパスを検索します。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:37 +msgid "The top level of the repository." +msgstr "リポジトリーのトップレベル。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:38 +msgid "Each directory in the repository path (one level deep)." +msgstr "リポジトリーパス内の各ディレクトリー（1 レベルの深さ）" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:40 +msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in the top level of the repository, Ansible uses the collection metadata in that file to install an individual collection." +msgstr "``galaxy.yml`` または ``MANIFEST.json`` ファイルがリポジトリーのトップレベルにある場合、Ansible はそのファイル内のコレクションメタデータを使用して個別のコレクションをインストールします。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:51 +msgid "If a ``galaxy.yml`` or ``MANIFEST.json`` file exists in one or more directories in the repository path (one level deep), Ansible installs each directory with a metadata file as a collection. For example, Ansible installs both collection1 and collection2 from this repository structure by default:" +msgstr "リポジトリーパス内の 1 つ以上のディレクトリーに ``galaxy.yml`` または ``MANIFEST.json`` ファイルが存在する場合は、Ansible はメタデータファイルを持つ各ディレクトリーをコレクションとしてインストールします。たとえば、Ansible は、デフォルトで、このリポジトリー構造から collection1 と collection2 の両方をインストールします。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:69 +msgid "If you have a different repository structure or only want to install a subset of collections, you can add a fragment to the end of your URI (before the optional comma-separated version) to indicate the location of the metadata file or files. The path should be a directory, not the metadata file itself. For example, to install only collection2 from the example repository with two collections:" +msgstr "リポジトリ構造が異なる場合、またはコレクションのサブセットのみをインストールする場合は、URI の末尾（オプションのコンマ区切りバージョンの前）にフラグメントを追加して、メタデータファイルの場所を示すことができます。パスは、メタデータファイル自体ではなく、ディレクトリである必要があります。たとえば、2つのコレクションを持つサンプルリポジトリからcollection2のみをインストールするには、次のようにします。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:75 +msgid "In some repositories, the main directory corresponds to the namespace:" +msgstr "リポジトリーによっては、メインのディレクトリーは名前空間に対応します。" + +#: ../../rst/shared_snippets/installing_collections_git_repo.txt:97 +msgid "You can install all collections in this repository, or install one collection from a specific commit:" +msgstr "このリポジトリーのすべてのコレクションをインストールするか、特定のコミットから 1 つのコレクションをインストールできます。" + +#: ../../rst/user_guide/collections_using.rst:67 +msgid "Configuring the ``ansible-galaxy`` client" +msgstr "``ansible-galaxy`` クライアントの設定" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:3 +msgid "By default, ``ansible-galaxy`` uses https://galaxy.ansible.com as the Galaxy server (as listed in the :file:`ansible.cfg` file under :ref:`galaxy_server`)." +msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:5 +msgid "You can use either option below to configure ``ansible-galaxy collection`` to use other servers (such as a custom Galaxy server):" +msgstr "以下のオプションを使用して、他のサーバー (カスタムの Galaxy サーバーなど) を使用するように ``ansible-galaxy collection`` を設定できます。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:7 +msgid "Set the server list in the :ref:`galaxy_server_list` configuration option in :ref:`ansible_configuration_settings_locations`." +msgstr ":ref:`ansible_configuration_settings_locations` の :ref:`galaxy_server_list` 設定オプションにサーバーリストを設定します。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:8 +msgid "Use the ``--server`` command line argument to limit to an individual server." +msgstr "``--server`` コマンドライン引数を使用して、個々のサーバーに制限します。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:10 +msgid "To configure a Galaxy server list in ``ansible.cfg``:" +msgstr "``ansible.cfg`` で Galaxy サーバー一覧を設定するには、以下を行います。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:13 +msgid "Add the ``server_list`` option under the ``[galaxy]`` section to one or more server names." +msgstr "``server_list`` セクションの ``[galaxy]`` オプションを 1 つ以上のサーバー名に追加します。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:14 +msgid "Create a new section for each server name." +msgstr "各サーバー名に新しいセクションを作成します。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:15 +msgid "Set the ``url`` option for each server name." +msgstr "各サーバー名に ``url`` オプションを設定します。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:16 +msgid "Optionally, set the API token for each server name. Go to https://galaxy.ansible.com/me/preferences and click :guilabel:`Show API key`." +msgstr "必要に応じて、各サーバー名の API トークンを設定します。https://galaxy.ansible.com/me/preferences に移動し、guilabel:`Show API key` をクリックします。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:19 +msgid "The ``url`` option for each server name must end with a forward slash ``/``. If you do not set the API token in your Galaxy server list, use the ``--api-key`` argument to pass in the token to the ``ansible-galaxy collection publish`` command." +msgstr "各サーバー名の ``url`` オプションは、スラッシュ ``/`` で終了する必要があります。Galaxy サーバー一覧の API トークンを設定しない場合は、``--api-key`` 引数を使用してトークンを ``ansible-galaxy collection publish`` コマンドに渡します。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:22 +msgid "The following example shows how to configure multiple servers:" +msgstr "以下の例は、複数のサーバーを設定する方法を示しています。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:49 +msgid "You can use the ``--server`` command line argument to select an explicit Galaxy server in the ``server_list`` and the value of this argument should match the name of the server. To use a server not in the server list, set the value to the URL to access that server (all servers in the server list will be ignored). Also you cannot use the ``--api-key`` argument for any of the predefined servers. You can only use the ``api_key`` argument if you did not define a server list or if you specify a URL in the ``--server`` argument." +msgstr "``--server`` コマンドライン引数を使用して ``server_list`` で明示的な Galaxy サーバーを選択し、この引数の値はサーバー名と一致する必要があります。サーバー一覧にないサーバーを使用する場合は、そのサーバーにアクセスする URL に値を設定します (サーバーリスト内のすべてのサーバーは無視されます)。また、事前定義されたサーバーのいずれかに ``--api-key`` 引数を使用することはできません。サーバーの一覧を定義していない場合、または ``--server`` に URL を指定した場合限り、``api_key`` 引数を使用できます。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:53 +msgid "**Galaxy server list configuration options**" +msgstr "**Galaxy サーバー一覧設定オプション**" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:55 +msgid "The :ref:`galaxy_server_list` option is a list of server identifiers in a prioritized order. When searching for a collection, the install process will search in that order, for example, ``automation_hub`` first, then ``my_org_hub``, ``release_galaxy``, and finally ``test_galaxy`` until the collection is found. The actual Galaxy instance is then defined under the section ``[galaxy_server.{{ id }}]`` where ``{{ id }}`` is the server identifier defined in the list. This section can then define the following keys:" +msgstr ":ref:`galaxy_server_list` オプションは、優先順位が付けられたサーバー識別子の一覧です。コレクションを検索する場合、インストールプロセスは次の順序で検索します。たとえば、``automation_hub`` を検索してから、``my_org_hub``、``release_galaxy``、最後に ``test_galaxy`` で、コレクションが見つかるまで行います。次に、実際の Galaxy インスタンスが ``[galaxy_server.{{ id }}]`` セクションで定義されます。``{{ id }}`` は、一覧で定義されているサーバー識別子です。このセクションでは、次のキーを定義できます。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:61 +msgid "``url``: The URL of the Galaxy instance to connect to. Required." +msgstr "``url``: 接続する Galaxy インスタンスの URL。必須。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:62 +msgid "``token``: An API token key to use for authentication against the Galaxy instance. Mutually exclusive with ``username``." +msgstr "``token``: Galaxy インスタンスに対する認証に使用する API トークンキー。``username`` と相互に排他的です。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:63 +msgid "``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``." +msgstr "``username``: Galaxy インスタンスに対する Basic 認証に使用するユーザー名。``token`` と相互に排他的です。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:64 +msgid "``password``: The password to use, in conjunction with ``username``, for basic authentication." +msgstr "``password``: Basic 認証に使用するパスワード。``username`` と併用します。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:65 +msgid "``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, galaxyNG). Mutually exclusive with ``username``. Requires ``token``." +msgstr "``auth_url``: SSO 認証 (例: galaxyNG) を使用する場合は Keycloak サーバー「token_endpoint」の URL です。``username`` と相互に排他的です。``token`` が必要です。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:66 +msgid "``validate_certs``: Whether or not to verify TLS certificates for the Galaxy server. This defaults to True unless the ``--ignore-certs`` option is provided or ``GALAXY_IGNORE_CERTS`` is configured to True." +msgstr "``validate_certs``: Galaxy サーバーの TLS 証明書を検証するかどうか。これは、``--ignore-certs`` オプションが提供されるか、``GALAXY_IGNORE_CERTS`` が True に設定されている場合を除き、デフォルトで True に設定されます。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:67 +msgid "``client_id``: The Keycloak token's client_id to use for authentication. Requires ``auth_url`` and ``token``. The default ``client_id`` is cloud-services to work with Red Hat SSO." +msgstr "``client_id``: 認証に使用する Keycloak トークンの client_id。``auth_url`` および ``token`` が必要です。デフォルトの ``client_id`` は、Red Hat SSO と連携するクラウドサービスです。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:69 +msgid "As well as defining these server options in the ``ansible.cfg`` file, you can also define them as environment variables. The environment variable is in the form ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` where ``{{ id }}`` is the upper case form of the server identifier and ``{{ key }}`` is the key to define. For example I can define ``token`` for ``release_galaxy`` by setting ``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token``." +msgstr "これらのサーバーオプションを ``ansible.cfg`` ファイルで定義するだけでなく、それらを環境変数として定義することもできます。環境変数は ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` の形式です。``{{ id }}`` はサーバー識別子の大文字形式であり、``{{ key }}`` は定義するキーです。たとえば、``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token`` を設定することで、``release_galaxy`` に ``token`` を定義することができます。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:74 +msgid "For operations that use only one Galaxy server (for example, the ``publish``, ``info``, or ``install`` commands). the ``ansible-galaxy collection`` command uses the first entry in the ``server_list``, unless you pass in an explicit server with the ``--server`` argument." +msgstr "Galaxy サーバー 1 つだけを使用する操作 (例: ``publish`` コマンド、``info`` コマンド、または ``install`` コマンド) の場合、``ansible-galaxy collection`` コマンドは、``--server`` 引数を使用して明示的なサーバーに渡しない限り、``server_list`` の最初のエントリーを使用します。" + +#: ../../rst/shared_snippets/galaxy_server_list.txt:78 +msgid "Once a collection is found, any of its requirements are only searched within the same Galaxy instance as the parent collection. The install process will not search for a collection requirement in a different Galaxy instance." +msgstr "コレクションが見つかると、その要件は親コレクションと同じ Galaxy インスタンス内でのみ検索されます。インストールプロセスでは、別の Galaxy インスタンスでコレクション要件を検索しません。" + +#: ../../rst/user_guide/collections_using.rst:74 +msgid "Downloading collections" +msgstr "コレクションのダウンロード" + +#: ../../rst/user_guide/collections_using.rst:76 +msgid "To download a collection and its dependencies for an offline install, run ``ansible-galaxy collection download``. This downloads the collections specified and their dependencies to the specified folder and creates a ``requirements.yml`` file which can be used to install those collections on a host without access to a Galaxy server. All the collections are downloaded by default to the ``./collections`` folder." +msgstr "オフラインインストール用のコレクションとその依存関係をダウンロードするには、``ansible-galaxy collection download`` を実行します。これにより、指定されたコレクションとその依存関係を指定のディレクトリーにダウンロードして、Galaxy サーバーにアクセスせずに、ホストにこれらのコレクションをインストールするのに使用できる ``requirements.yml`` ファイルを作成します。すべてのコレクションは、デフォルトで ``./collections`` ディレクトリーにダウンロードされます。" + +#: ../../rst/user_guide/collections_using.rst:81 +msgid "Just like the ``install`` command, the collections are sourced based on the :ref:`configured galaxy server config <galaxy_server_config>`. Even if a collection to download was specified by a URL or path to a tarball, the collection will be redownloaded from the configured Galaxy server." +msgstr "``install`` コマンドと同様、コレクションは :ref:`configured galaxy server config <galaxy_server_config>` に基づいて取得されます。ダウンロードするコレクションが URL や tarball へのパスで指定されていた場合でも、設定された Galaxy サーバーからコレクションが再ダウンロードされます。" + +#: ../../rst/user_guide/collections_using.rst:85 +msgid "Collections can be specified as one or multiple collections or with a ``requirements.yml`` file just like ``ansible-galaxy collection install``." +msgstr "コレクションは、1 つまたは複数のコレクションとして、または ``ansible-galaxy collection install`` のように ``requirements.yml`` ファイルで指定できます。" + +#: ../../rst/user_guide/collections_using.rst:88 +msgid "To download a single collection and its dependencies:" +msgstr "1 つのコレクションとその依存関係をダウンロードするには、以下を行います。" + +#: ../../rst/user_guide/collections_using.rst:94 +msgid "To download a single collection at a specific version:" +msgstr "特定のバージョンで単一のコレクションをダウンロードするには、以下を実行します。" + +#: ../../rst/user_guide/collections_using.rst:100 +msgid "To download multiple collections either specify multiple collections as command line arguments as shown above or use a requirements file in the format documented with :ref:`collection_requirements_file`." +msgstr "複数のコレクションをダウンロードするには、上記のように複数のコレクションをコマンドライン引数として指定するか、:ref:`collection_requirements_file` に記載されている形式で要件ファイルを使用します。" + +#: ../../rst/user_guide/collections_using.rst:107 +msgid "You can also download a source collection directory. The collection is built with the mandatory ``galaxy.yml`` file." +msgstr "ソースコレクションディレクトリーをダウンロードすることもできます。コレクションは必須の ``galaxy.yml`` ファイルでビルドされます。" + +#: ../../rst/user_guide/collections_using.rst:115 +msgid "You can download multiple source collections from a single namespace by providing the path to the namespace." +msgstr "名前空間へのパスを指定すると、単一の名前空間から複数のソースコレクションをダウンロードできます。" + +#: ../../rst/user_guide/collections_using.rst:131 +msgid "All the collections are downloaded by default to the ``./collections`` folder but you can use ``-p`` or ``--download-path`` to specify another path:" +msgstr "コレクションはすべて、デフォルトで ``./collections`` ディレクトリーにダウンロードされますが、``-p`` または ``--download-path`` を使用して別のパスを指定することもできます。" + +#: ../../rst/user_guide/collections_using.rst:138 +msgid "Once you have downloaded the collections, the folder contains the collections specified, their dependencies, and a ``requirements.yml`` file. You can use this folder as is with ``ansible-galaxy collection install`` to install the collections on a host without access to a Galaxy server." +msgstr "コレクションをダウンロードした後、ディレクトリーには指定されたコレクション、その依存関係、および ``requirements.yml`` ファイルが含まれます。このディレクトリーは、``ansible-galaxy collection install`` と同じように、Galaxy サーバーにアクセスせずにホストにコレクションをインストールできます。" + +#: ../../rst/user_guide/collections_using.rst:152 +msgid "Listing collections" +msgstr "コレクション一覧の表示" + +#: ../../rst/user_guide/collections_using.rst:154 +msgid "To list installed collections, run ``ansible-galaxy collection list``. This shows all of the installed collections found in the configured collections search paths. It will also show collections under development which contain a galaxy.yml file instead of a MANIFEST.json. The path where the collections are located are displayed as well as version information. If no version information is available, a ``*`` is displayed for the version number." +msgstr "インストールされたコレクションを一覧表示するには、``ansible-galaxy collection list`` を実行します。これは、設定されたコレクションの検索パスにあるインストールされたコレクションをすべて表示します。これは、MANIFEST.json ではなく galaxy.yml ファイルが含まれる開発中のコレクションも表示します。コレクションが配置されているパスとバージョン情報が表示されます。バージョン情報がない場合は、``*`` がバージョン番号に表示されます。" + +#: ../../rst/user_guide/collections_using.rst:173 +msgid "Run with ``-vvv`` to display more detailed information." +msgstr "詳細情報を表示するには、``-vvv`` を付けて実行します。" + +#: ../../rst/user_guide/collections_using.rst:175 +msgid "To list a specific collection, pass a valid fully qualified collection name (FQCN) to the command ``ansible-galaxy collection list``. All instances of the collection will be listed." +msgstr "特定のコレクションを一覧表示するには、有効な完全修飾コレクション名 (FQCN) を ``ansible-galaxy collection list`` コマンドに渡します。コレクションのインスタンス一覧が表示されます。" + +#: ../../rst/user_guide/collections_using.rst:191 +msgid "To search other paths for collections, use the ``-p`` option. Specify multiple search paths by separating them with a ``:``. The list of paths specified on the command line will be added to the beginning of the configured collections search paths." +msgstr "他のパスのコレクションを検索するには、``-p`` オプションを使用します。複数の検索パスを指定する場合は、``:`` で区切って指定します。コマンドラインで指定されたパスのリストは、設定されたコレクションの検索パスの先頭に追加されます。" + +#: ../../rst/user_guide/collections_using.rst:227 +msgid "Verifying collections" +msgstr "コレクションの検証" + +#: ../../rst/user_guide/collections_using.rst:230 +msgid "Verifying collections with ``ansible-galaxy``" +msgstr "``ansible-galaxy`` でコレクションを検証" + +#: ../../rst/user_guide/collections_using.rst:232 +msgid "Once installed, you can verify that the content of the installed collection matches the content of the collection on the server. This feature expects that the collection is installed in one of the configured collection paths and that the collection exists on one of the configured galaxy servers." +msgstr "インストールすると、インストールしたコレクションの内容が、サーバー上のコレクションの内容と一致することを確認できます。この機能は、設定されたコレクションパスのいずれかにコレクションがインストールされ、設定された galaxy サーバーのいずれかにコレクションが存在することを想定します。" + +#: ../../rst/user_guide/collections_using.rst:238 +msgid "The output of the ``ansible-galaxy collection verify`` command is quiet if it is successful. If a collection has been modified, the altered files are listed under the collection name." +msgstr "``ansible-galaxy collection verify`` コマンドの出力は、成功すると何も表示されません。コレクションを変更すると、変更したファイルがコレクション名の下に表示されます。" + +#: ../../rst/user_guide/collections_using.rst:248 +msgid "You can use the ``-vvv`` flag to display additional information, such as the version and path of the installed collection, the URL of the remote collection used for validation, and successful verification output." +msgstr "``-vvv`` フラグを使用すると、インストールされたコレクションのバージョンとパス、検証に使用されるリモートコレクションの URL、正常な確認出力などの追加情報を表示できます。" + +#: ../../rst/user_guide/collections_using.rst:259 +msgid "If you have a pre-release or non-latest version of a collection installed you should include the specific version to verify. If the version is omitted, the installed collection is verified against the latest version available on the server." +msgstr "プレリリースまたは最新でないバージョンのコレクションをインストールしている場合は、検証する特定のバージョンを含める必要があります。バージョンが省略された場合、インストールされたコレクションは、サーバーで利用可能な最新バージョンと比較して検証されます。" + +#: ../../rst/user_guide/collections_using.rst:265 +msgid "In addition to the ``namespace.collection_name:version`` format, you can provide the collections to verify in a ``requirements.yml`` file. Dependencies listed in ``requirements.yml`` are not included in the verify process and should be verified separately." +msgstr "``namespace.collection_name:version`` 形式に加えて、``requirements.yml`` ファイルで検証するコレクションを提供することができます。``requirements.yml`` に記載されている依存関係は、検証プロセスに含まれないため、別途検証する必要があります。" + +#: ../../rst/user_guide/collections_using.rst:271 +msgid "Verifying against ``tar.gz`` files is not supported. If your ``requirements.yml`` contains paths to tar files or URLs for installation, you can use the ``--ignore-errors`` flag to ensure that all collections using the ``namespace.name`` format in the file are processed." +msgstr "``tar.gz`` ファイルに対する検証はサポートされていません。``requirements.yml`` にインストール用の tar ファイルや URL へのパスが含まれている場合は、``--ignore-errors`` フラグを使用して、ファイル内で ``namespace.name`` 形式を使用しているすべてのコレクションが処理されるようにすることができます。" + +#: ../../rst/user_guide/collections_using.rst:274 +msgid "Signature verification" +msgstr "署名の検証" + +#: ../../rst/user_guide/collections_using.rst:276 +msgid "If a collection has been signed by the Galaxy server, the server will provide ASCII armored, detached signatures to verify the authenticity of the MANIFEST.json before using it to verify the collection's contents. You must opt into signature verification by configuring a keyring for ``ansible-galaxy`` to use and providing the path with the ``--keyring`` option." +msgstr "コレクションが Galaxy サーバーで署名されている場合、サーバーは ASCII 調整されたデタッチされた署名を提供し、 MANIFEST.json を使用してコレクションのコンテンツを検証する前にその信憑性を検証します。使用する``ansible-galaxy`` のキーリングを設定し、``--keyring`` オプションでパスを提供することで、署名の検証を選択する必要があります。" + +#: ../../rst/user_guide/collections_using.rst:278 +msgid "In addition to any signatures provided by the Galaxy server, signature sources can also be provided in the requirements file and on the command line. Signature sources should be URIs." +msgstr "Galaxy サーバーによって提供される署名の他に、署名ソースは、要件ファイルおよびコマンドラインで提供することもできます。署名ソースは URI である必要があります。" + +#: ../../rst/user_guide/collections_using.rst:280 +msgid "Use the ``--signature`` option to verify collection name(s) provided on the CLI with an additional signature. This option can be used multiple times to provide multiple signatures." +msgstr "``--signature`` オプションを使用して、追加の署名と共に CLI で提供されるコレクション名を検証します。このオプションを複数回使用して、複数の署名を提供することができます。" + +#: ../../rst/user_guide/collections_using.rst:286 +msgid "Collections in a requirements file should list any additional signature sources following the collection's \"signatures\" key." +msgstr "要件ファイルのコレクションは、コレクションの「signature」キーの後に追加の署名ソースを一覧表示する必要があります。" + +#: ../../rst/user_guide/collections_using.rst:302 +msgid "When a collection is installed from a Galaxy server, the signatures provided by the server to verify the collection's authenticity are saved alongside the installed collections. This data is used to verify the internal consistency of the collection without querying the Galaxy server again when the ``--offline`` option is provided." +msgstr "コレクションが Galaxy サーバーからインストールされる場合、コレクションの信憑性を検証するためにサーバーが提供する署名は、インストールされたコレクションとともに保存されます。``--offline`` オプションが指定されている場合に、このデータを使用して、再度 Galaxy サーバーへのクエリーを行わずにコレクションの内部整合性を検証します。" + +#: ../../rst/user_guide/collections_using.rst:311 +msgid "Using collections in a Playbook" +msgstr "Playbook でのコレクションの使用" + +#: ../../rst/user_guide/collections_using.rst:313 +msgid "Once installed, you can reference a collection content by its fully qualified collection name (FQCN):" +msgstr "インストールが完了すると、完全修飾コレクション名 (FQCN) でコレクションコンテンツを参照できます。" + +#: ../../rst/user_guide/collections_using.rst:322 +msgid "This works for roles or any type of plugin distributed within the collection:" +msgstr "これは、コレクションで配布されるロールまたはすべてのタイプのプラグインで機能します。" + +#: ../../rst/user_guide/collections_using.rst:338 +msgid "Simplifying module names with the ``collections`` keyword" +msgstr "``collections`` キーワードを使用したモジュール名の簡素化" + +#: ../../rst/user_guide/collections_using.rst:340 +msgid "The ``collections`` keyword lets you define a list of collections that your role or playbook should search for unqualified module and action names. So you can use the ``collections`` keyword, then simply refer to modules and action plugins by their short-form names throughout that role or playbook." +msgstr "``collections`` キーワードを使用すると、ロールまたは Playbook が非修飾モジュールおよびアクション名を検索する必要のあるコレクションの一覧を定義できます。つまり、``collections`` キーワードを使用すると、そのロールまたは Playbook 全体で、モジュールおよびアクションプラグインを短縮名で参照できます。" + +#: ../../rst/user_guide/collections_using.rst:343 +msgid "If your playbook uses both the ``collections`` keyword and one or more roles, the roles do not inherit the collections set by the playbook. This is one of the reasons we recommend you always use FQCN. See below for roles details." +msgstr "Playbook で ``collections`` キーワードと 1 つ以上のロールの両方を使用している場合、ロールは Playbook で設定されたコレクションを継承しません。これが、常に FQCN を使用することが推奨される理由の 1 つです。ロールの詳細については、以下を参照してください。" + +#: ../../rst/user_guide/collections_using.rst:346 +msgid "Using ``collections`` in roles" +msgstr "ロールでの ``collections`` の使用" + +#: ../../rst/user_guide/collections_using.rst:348 +msgid "Within a role, you can control which collections Ansible searches for the tasks inside the role using the ``collections`` keyword in the role's ``meta/main.yml``. Ansible will use the collections list defined inside the role even if the playbook that calls the role defines different collections in a separate ``collections`` keyword entry. Roles defined inside a collection always implicitly search their own collection first, so you don't need to use the ``collections`` keyword to access modules, actions, or other roles contained in the same collection." +msgstr "ロール内で、Ansible がロールの ``meta/main.yml`` の ``collections`` キーワードを使用して、ロール内のタスクを検索するコレクションを制御できます。Ansible は、ロールを呼び出す Playbook が別の ``collections`` キーワードエントリーで異なるコレクションを定義する場合でも、ロール内に定義されたコレクションリストを使用します。コレクション内で定義されたロールは、常に暗黙的に自身のコレクションを最初に検索するため、同じコレクションに含まれるモジュール、アクション、または他のロールにアクセスするために ``collections`` キーワードを使用する必要はありません。" + +#: ../../rst/user_guide/collections_using.rst:359 +msgid "Using ``collections`` in playbooks" +msgstr "Playbook での ``collections`` の使用" + +#: ../../rst/user_guide/collections_using.rst:361 +msgid "In a playbook, you can control the collections Ansible searches for modules and action plugins to execute. However, any roles you call in your playbook define their own collections search order; they do not inherit the calling playbook's settings. This is true even if the role does not define its own ``collections`` keyword." +msgstr "Playbook では、Ansible が実行するモジュールやアクションプラグインを検索するコレクションを制御することができます。ただし、Playbook で呼び出したロールは、独自のコレクション検索順序を定義し、呼び出した Playbook の設定を継承しません。これは、ロールが独自の ``collections`` キーワードを定義していない場合でも同様です。" + +#: ../../rst/user_guide/collections_using.rst:379 +msgid "The ``collections`` keyword merely creates an ordered 'search path' for non-namespaced plugin and role references. It does not install content or otherwise change Ansible's behavior around the loading of plugins or roles. Note that an FQCN is still required for non-action or module plugins (for example, lookups, filters, tests)." +msgstr "``collections`` キーワードは、名前空間以外のプラグインおよびロール参照に対して、順序付けされた「検索パス」を作成します。コンテンツのインストールや、プラグインやロールの読み込みに関する Ansible の動作は変更されません。非アクションやモジュールプラグイン (ルックアップ、フィルター、テストなど) が必要なことに注意してください。" + +#: ../../rst/user_guide/collections_using.rst:381 +msgid "When using the ``collections`` keyword, it is not necessary to add in ``ansible.builtin`` as part of the search list. When left omitted, the following content is available by default:" +msgstr "``collections`` キーワードを使用する場合は、検索リストの一部として ``ansible.builtin`` に追加する必要はありません。省略したままにすると、以下のコンテンツがデフォルトで利用できます。" + +#: ../../rst/user_guide/collections_using.rst:383 +msgid "Standard ansible modules and plugins available through ``ansible-base``/``ansible-core``" +msgstr "``ansible-base``/``ansible-core`` で利用できる標準の Ansible モジュールおよびプラグイン" + +#: ../../rst/user_guide/collections_using.rst:385 +msgid "Support for older 3rd party plugin paths" +msgstr "古いサードパーティープラグインパスのサポート" + +#: ../../rst/user_guide/collections_using.rst:387 +msgid "In general, it is preferable to use a module or plugin's FQCN over the ``collections`` keyword and the short name for all content in ``ansible-core``" +msgstr "一般に、``ansible-core``のすべてのコンテンツに関して、``collections``のキーワードや短い名前よりも、モジュールやプラグインの FQCN を使用することが推奨されます。" + +#: ../../rst/user_guide/collections_using.rst:390 +msgid "Using a playbook from a collection" +msgstr "コレクションからの Playbook の使用" + +#: ../../rst/user_guide/collections_using.rst:394 +msgid "You can also distribute playbooks in your collection and invoke them using the same semantics you use for plugins:" +msgstr "コレクションに Playbook を分散し、プラグインに使用するのと同じセマンティクスを使用して Playbook を呼び出すこともできます。" + +#: ../../rst/user_guide/collections_using.rst:400 +msgid "From inside a playbook:" +msgstr "Playbook 内から、以下を実行します。" + +#: ../../rst/user_guide/collections_using.rst:407 +msgid "A few recommendations when creating such playbooks, ``hosts:`` should be generic or at least have a variable input." +msgstr "このような Playbook を作成する際のいくつかの推奨事項として、``hosts:`` は一般的なものにするか、少なくとも変数入力にする必要があります。" + +#: ../../rst/user_guide/collections_using.rst:418 +msgid "This will have an implied entry in the ``collections:`` keyword of ``my_namespace.my_collection`` just as with roles." +msgstr "これは、ロールと同様に、``my_namespace.my_collection`` の ``collections:`` キーワードに暗黙的なエントリーを持ちます。" + +#: ../../rst/user_guide/collections_using.rst:421 +msgid "Playbook names, like other collection resources, have a restricted set of valid characters. Names can contain only lowercase alphanumeric characters, plus _ and must start with an alpha character. The dash ``-`` character is not valid for playbook names in collections. Playbooks whose names contain invalid characters are not addressable: this is a limitation of the Python importer that is used to load collection resources." +msgstr "他のコレクションリソースなどの Playbook 名では、有効な文字のセットが制限されています。名前には、小文字の英数字と _ のみを含めることができ、アルファベット記号で開始する必要があります。ダッシュ ``-`` は、コレクション内の Playbook 名には有効ではありません。名前に無効な文字が含まれるPlaybookにアドレスを指定することはできません。これは、コレクションリソースの読み込みに使用される Python インポーターの制限です。" + +#: ../../rst/user_guide/collections_using.rst:427 +msgid ":ref:`developing_collections`" +msgstr ":ref:`developing_collections`" + +#: ../../rst/user_guide/collections_using.rst:428 +msgid "Develop or modify a collection." +msgstr "コレクションを開発するか、または変更します。" + +#: ../../rst/user_guide/collections_using.rst:429 +msgid ":ref:`collections_galaxy_meta`" +msgstr ":ref:`collections_galaxy_meta`" + +#: ../../rst/user_guide/collections_using.rst:430 +msgid "Understand the collections metadata structure." +msgstr "コレクションのメタデータ構造を理解します。" + +#: ../../rst/user_guide/collections_using.rst:431 +msgid "`Mailing List <https://groups.google.com/group/ansible-devel>`_" +msgstr "`メーリングリスト <https://groups.google.com/group/ansible-devel>`_" + +#: ../../rst/user_guide/collections_using.rst:432 +msgid "The development mailing list" +msgstr "開発メーリングリスト" + +#: ../../rst/user_guide/collections_using.rst:435 +msgid "`Automation Hub <https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/>`_" +msgstr "`Automation Hub <https://access.redhat.com/documentation/en-us/red_hat_ansible_automation_platform/>`_" + +#: ../../rst/user_guide/collections_using.rst:436 +msgid "Learn how to use collections with Red Hat Automation Hub" +msgstr "Red Hat Automation Hub でコレクションを使用する方法を説明します。" + +#: ../../rst/user_guide/command_line_tools.rst:4 +msgid "Working with command line tools" +msgstr "コマンドラインツールの使用" + +#: ../../rst/user_guide/command_line_tools.rst:6 +msgid "Most users are familiar with `ansible` and `ansible-playbook`, but those are not the only utilities Ansible provides. Below is a complete list of Ansible utilities. Each page contains a description of the utility and a listing of supported parameters." +msgstr "ほとんどのユーザーは、`ansible` および `ansible-playbook` に精通していますが、これらは、Ansible が提供する唯一のユーティリティーではありません。以下は、Ansible ユーティリティーの完全なリストです。各ページには、ユーティリティーの説明と、サポートされるパラメーター一覧が含まれています。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:4 +msgid "Data manipulation" +msgstr "データ操作" + +#: ../../rst/user_guide/complex_data_manipulation.rst:6 +msgid "In many cases, you need to do some complex operation with your variables, while Ansible is not recommended as a data processing/manipulation tool, you can use the existing Jinja2 templating in conjunction with the many added Ansible filters, lookups and tests to do some very complex transformations." +msgstr "多くの場合あ、変数を使用して複雑な操作を行う必要がありますが、Ansible はデータ処理/操作ツールとしてはお勧めできませんが、既存の Jinja2 テンプレートと、追加された多くの Ansible フィルター、ルックアップ、テストを併用することで、非常に複雑な変換を行うことができます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:11 +msgid "Let's start with a quick definition of each type of plugin:" +msgstr "各プラグイン定義の概要:" + +#: ../../rst/user_guide/complex_data_manipulation.rst:9 +msgid "lookups: Mainly used to query 'external data', in Ansible these were the primary part of loops using the ``with_<lookup>`` construct, but they can be used independently to return data for processing. They normally return a list due to their primary function in loops as mentioned previously. Used with the ``lookup`` or ``query`` Jinja2 operators." +msgstr "lookups: 主に「外部データ」を照会するために使用されます。Ansible では、``with_<lookup>`` 構成を使用したループの主要部分でしたが、処理するデータを返すために独立して使用することもできます。前述のようにループでの主な機能であるため、通常はリストを返します。Jinja2 の演算子 ``lookup`` または ``query`` と一緒に使用します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:10 +msgid "filters: used to change/transform data, used with the ``|`` Jinja2 operator." +msgstr "filters: Jinja2 演算子 ``|`` で使用される、データの変更/変換に使用します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:11 +msgid "tests: used to validate data, used with the ``is`` Jinja2 operator." +msgstr "tests: Jinja2 演算子 ``is`` で使用されるデータの検証に使用されます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:19 +msgid "Loops and list comprehensions" +msgstr "ループおよびリストの競合" + +#: ../../rst/user_guide/complex_data_manipulation.rst:21 +msgid "Most programming languages have loops (``for``, ``while``, and so on) and list comprehensions to do transformations on lists including lists of objects. Jinja2 has a few filters that provide this functionality: ``map``, ``select``, ``reject``, ``selectattr``, ``rejectattr``." +msgstr "ほとんどのプログラミング言語にはループ (``for``、``while`` など) やリスト内包があり、オブジェクトのリストを含むリストの変換を行うことができます。Jinja2 には、このような機能を提供するフィルターがいくつかあります (``map``、``select``、``reject``、``selectattr``、``rejectattr``)。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:23 +msgid "map: this is a basic for loop that just allows you to change every item in a list, using the 'attribute' keyword you can do the transformation based on attributes of the list elements." +msgstr "map: これは基本的な for ループで、リストのすべての項目を変更することができます。「attribute」キーワードを使用すると、リスト要素の属性に基づいて変換を行うことができます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:24 +msgid "select/reject: this is a for loop with a condition, that allows you to create a subset of a list that matches (or not) based on the result of the condition." +msgstr "select/reject: これは、条件のあるループ用であり、条件の結果に基づいて一致する (または一致しない) リストのサブセットを作成できます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:25 +msgid "selectattr/rejectattr: very similar to the above but it uses a specific attribute of the list elements for the conditional statement." +msgstr "selectattr/rejectattr: 上記と非常に似ていますが、条件文に対して list 要素の特定の属性を使用します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:30 +msgid "Use a loop to create exponential backoff for retries/until." +msgstr "ループを使用して再試行/一時停止の指数関数的なバックオフを作成します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:44 +msgid "Extract keys from a dictionary matching elements from a list" +msgstr "リストから一致するディクショナリー要素からのキー抽出" + +#: ../../rst/user_guide/complex_data_manipulation.rst:46 +msgid "The Python equivalent code would be:" +msgstr "Python と同等のコードは以下のとおりです。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:55 +msgid "There are several ways to do it in Ansible, this is just one example:" +msgstr "Ansible で実行する方法はいくつかあります。以下は一例です。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:57 +msgid "Way to extract matching keys from a list of dictionaries" +msgstr "ディクショナリーのリストから一致するキーを抽出する方法" + +#: ../../rst/user_guide/complex_data_manipulation.rst:84 +msgid "Results of debug task, a list with the extracted keys" +msgstr "デバッグタスクの結果 (展開した鍵を含むリスト)" + +#: ../../rst/user_guide/complex_data_manipulation.rst:97 +msgid "Get the unique list of values of a variable that vary per host" +msgstr "ホストごとに異なる変数の値の一意のリストを取得" + +#: ../../rst/user_guide/complex_data_manipulation.rst:107 +msgid "Find mount point" +msgstr "マウントポイントの検索" + +#: ../../rst/user_guide/complex_data_manipulation.rst:109 +msgid "In this case, we want to find the mount point for a given path across our machines, since we already collect mount facts, we can use the following:" +msgstr "今回のケースでは、マシン間で指定されたパスのマウントポイントを検索したいのですが、すでにマウントファクトを収集しているため、次のように使用できます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:111 +msgid "Use selectattr to filter mounts into list I can then sort and select the last from" +msgstr "selectattr を使用してマウントにフィルターを設定してリストにし、ソートして最後のものを選択します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:128 +msgid "Omit elements from a list" +msgstr "リストからの要素を省略" + +#: ../../rst/user_guide/complex_data_manipulation.rst:130 +msgid "The special ``omit`` variable ONLY works with module options, but we can still use it in other ways as an identifier to tailor a list of elements:" +msgstr "特別な ``omit`` 変数は、モジュールオプションでのみ機能しますが、要素のリストを調整するための識別子として、他の方法でも使用することができます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:132 +msgid "Inline list filtering when feeding a module option" +msgstr "モジュールオプションのフィード時のインラインリストのフィルタリング" + +#: ../../rst/user_guide/complex_data_manipulation.rst:146 +msgid "Another way is to avoid adding elements to the list in the first place, so you can just use it directly:" +msgstr "もう 1 つの方法は、そもそもリストに要素を追加しないようにして、直接利用することです。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:148 +msgid "Using set_fact in a loop to increment a list conditionally" +msgstr "ループで set_fact を使用してリストを条件付きで増分する" + +#: ../../rst/user_guide/complex_data_manipulation.rst:166 +msgid "Combine values from same list of dicts" +msgstr "同じリストのディクショナリーの値を結合する" + +#: ../../rst/user_guide/complex_data_manipulation.rst:167 +msgid "Combining positive and negative filters from examples above, you can get a 'value when it exists' and a 'fallback' when it doesn't." +msgstr "上記の例から正のフィルターと負のフィルターを組み合わせると、「存在する場合の値」と存在しない場合の「フォールバック」を得ることができます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:169 +msgid "Use selectattr and rejectattr to get the ansible_host or inventory_hostname as needed" +msgstr "必要に応じて、selectattr および rejectattr を使用して ansible_host または inventory_hostname を取得" + +#: ../../rst/user_guide/complex_data_manipulation.rst:187 +msgid "Custom Fileglob Based on a Variable" +msgstr "変数に基づくカスタムファイルグロブ" + +#: ../../rst/user_guide/complex_data_manipulation.rst:189 +msgid "This example uses `Python argument list unpacking <https://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists>`_ to create a custom list of fileglobs based on a variable." +msgstr "この例では、`Python argument list unpacking <https://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists>`_ を使用して、変数に基づいてファイルグロブのカスタムリストを作成します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:191 +msgid "Using fileglob with a list based on a variable." +msgstr "変数に基づくリストでファイルグロブの使用" + +#: ../../rst/user_guide/complex_data_manipulation.rst:212 +msgid "Complex Type transformations" +msgstr "複雑なタイプ変換" + +#: ../../rst/user_guide/complex_data_manipulation.rst:214 +msgid "Jinja provides filters for simple data type transformations (``int``, ``bool``, and so on), but when you want to transform data structures things are not as easy. You can use loops and list comprehensions as shown above to help, also other filters and lookups can be chained and used to achieve more complex transformations." +msgstr "Jinja には単純なデータ型変換のためのフィルターが用意されていますが (``int``、``bool`` など)、データ構造を変換したい場合はそう簡単ではありません。上記のようにループやリスト内包を利用することもできますし、他のフィルターやルックアップを連鎖させて使用することで、より複雑な変換を行うことができます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:221 +msgid "Create dictionary from list" +msgstr "リストからディクショナリーを作成" + +#: ../../rst/user_guide/complex_data_manipulation.rst:223 +msgid "In most languages it is easy to create a dictionary (a.k.a. map/associative array/hash and so on) from a list of pairs, in Ansible there are a couple of ways to do it and the best one for you might depend on the source of your data." +msgstr "ほとんどの言語では、ペアのリストからディクショナリー (マップ、連想配列、ハッシュなど) を簡単に作成できますが、Ansible ではいくつかの方法があり、データのソースによって最適な方法が異なります。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:226 +msgid "These example produces ``{\"a\": \"b\", \"c\": \"d\"}``" +msgstr "これらの例では、``{\"a\": \"b\", \"c\": \"d\"}`` を生成します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:228 +msgid "Simple list to dict by assuming the list is [key, value , key, value, ...]" +msgstr "リストが [key, value , key, value, ...] であることを前提とする、ディクショナリーへの単純なリスト" + +#: ../../rst/user_guide/complex_data_manipulation.rst:236 +msgid "It is simpler when we have a list of pairs:" +msgstr "ペアのリストがある場合はより簡単にできる" + +#: ../../rst/user_guide/complex_data_manipulation.rst:243 +msgid "Both end up being the same thing, with ``slice(2)`` transforming ``single_list`` to a ``list_of_pairs`` generator." +msgstr "``slice(2)`` が ``single_list`` を ``list_of_pairs`` ジェネレーターに変換することで、両方とも同じ内容になります。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:247 +msgid "A bit more complex, using ``set_fact`` and a ``loop`` to create/update a dictionary with key value pairs from 2 lists:" +msgstr "``set_fact`` と ``loop`` を使用して、2 つのリストからキーと値のペアを持つ、もう少し複雑なディクショナリーを作成/更新します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:249 +msgid "Using set_fact to create a dictionary from a set of lists" +msgstr "set_fact を使用してリストのセットからのディクショナリーの作成" + +#: ../../rst/user_guide/complex_data_manipulation.rst:267 +msgid "This results in ``{\"foo\": \"a\", \"var\": \"b\", \"bar\": \"c\"}``." +msgstr "その結果、``{\"foo\": \"a\", \"var\": \"b\", \"bar\": \"c\"}`` になります。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:270 +msgid "You can even combine these simple examples with other filters and lookups to create a dictionary dynamically by matching patterns to variable names:" +msgstr "これらの簡単な例を他のフィルターやルックアップと組み合わせて、変数名にパターンを一致させて動的にディクショナリーを作成することもできます。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:272 +msgid "Using 'vars' to define dictionary from a set of lists without needing a task" +msgstr "「vars」を使用して、タスクを必要とせずにリストのセットからディクショナリーを定義" + +#: ../../rst/user_guide/complex_data_manipulation.rst:281 +msgid "A quick explanation, since there is a lot to unpack from these two lines:" +msgstr "以下の 2 つの行から展開するため、簡単な説明があります。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:283 +msgid "The ``varnames`` lookup returns a list of variables that match \"begin with ``xyz_``\"." +msgstr "``varnames`` ルックアップは、「begin with ``xyz_``」にマッチする変数の一覧を返します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:284 +msgid "Then feeding the list from the previous step into the ``vars`` lookup to get the list of values. The ``*`` is used to 'dereference the list' (a pythonism that works in Jinja), otherwise it would take the list as a single argument." +msgstr "そして、前のステップのリストを ``vars`` ルックアップに送り、値のリストを取得します。``*`` は「リストを参照解除する」ために使用されます (Jinja でも通用する python の手法です)。そうでなければ、リストを 1 つの引数として受け取ることになります。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:286 +msgid "Both lists get passed to the ``zip`` filter to pair them off into a unified list (key, value, key2, value2, ...)." +msgstr "両方のリストは、``zip`` フィルターに渡され、それらをペアにして統一されたリスト (key, value, key2, value2, ...) にします。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:287 +msgid "The dict function then takes this 'list of pairs' to create the dictionary." +msgstr "その後、dict 関数はこの「ペアのリスト」を取得し、ディクショナリーを作成します。" + +#: ../../rst/user_guide/complex_data_manipulation.rst:290 +msgid "An example on how to use facts to find a host's data that meets condition X:" +msgstr "ファクトを使用して、条件 X を満たすホストのデータを検索する例:" + +#: ../../rst/user_guide/complex_data_manipulation.rst:298 +msgid "An example to show a host uptime in days/hours/minutes/seconds (assumes facts where gathered)." +msgstr "ホストのアップタイムを日数/時間/分/秒で表示する例（収集されるファクトを想定）" + +#: ../../rst/user_guide/complex_data_manipulation.rst:309 +#: ../../rst/user_guide/playbooks_variables.rst:499 +msgid ":ref:`playbooks_filters`" +msgstr ":ref:`playbooks_filters`" + +#: ../../rst/user_guide/complex_data_manipulation.rst:310 +msgid "Jinja2 filters included with Ansible" +msgstr "Ansible に含まれる Jinja2 フィルター" + +#: ../../rst/user_guide/complex_data_manipulation.rst:311 +msgid ":ref:`playbooks_tests`" +msgstr ":ref:`playbooks_tests`" + +#: ../../rst/user_guide/complex_data_manipulation.rst:312 +msgid "Jinja2 tests included with Ansible" +msgstr "Ansible に含まれる Jinja2 テスト" + +#: ../../rst/user_guide/complex_data_manipulation.rst:313 +msgid "`Jinja2 Docs <https://jinja.palletsprojects.com/>`_" +msgstr "`Jinja2 Docs <https://jinja.palletsprojects.com/>`_" + +#: ../../rst/user_guide/complex_data_manipulation.rst:314 +msgid "Jinja2 documentation, includes lists for core filters and tests" +msgstr "Jinja2 ドキュメント。コアフィルターおよびテストの一覧が含まれます。" + +#: ../../rst/user_guide/connection_details.rst:5 +msgid "Connection methods and details" +msgstr "接続方法および詳細" + +#: ../../rst/user_guide/connection_details.rst:7 +msgid "This section shows you how to expand and refine the connection methods Ansible uses for your inventory." +msgstr "このセクションでは、Ansible がインベントリーに使用する接続方法を拡張および改良する方法を示します。" + +#: ../../rst/user_guide/connection_details.rst:10 +msgid "ControlPersist and paramiko" +msgstr "ControlPersist および paramiko" + +#: ../../rst/user_guide/connection_details.rst:12 +msgid "By default, Ansible uses native OpenSSH, because it supports ControlPersist (a performance feature), Kerberos, and options in ``~/.ssh/config`` such as Jump Host setup. If your control machine uses an older version of OpenSSH that does not support ControlPersist, Ansible will fallback to a Python implementation of OpenSSH called 'paramiko'." +msgstr "デフォルトでは、Ansible はネイティブの OpenSSH を使用します。これは、ControlPersist (パフォーマンス機能)、Kerberos、および Jump Host 設定などの ``~/.ssh/config`` のオプションをサポートしているためです。コントロールマシンが ControlPersist をサポートしていない古いバージョンの OpenSSH を使用している場合、Ansible は「paramiko」と呼ばれる Python による OpenSSH の実装にフォールバックします。" + +#: ../../rst/user_guide/connection_details.rst:17 +msgid "Setting a remote user" +msgstr "リモートユーザーの設定" + +#: ../../rst/user_guide/connection_details.rst:19 +msgid "By default, Ansible connects to all remote devices with the user name you are using on the control node. If that user name does not exist on a remote device, you can set a different user name for the connection. If you just need to do some tasks as a different user, look at :ref:`become`. You can set the connection user in a playbook:" +msgstr "デフォルトでは、Ansible はすべてのリモートデバイスに、コントロールノードで使用しているユーザー名で接続します。リモートデバイスにそのユーザー名が存在しない場合は、接続に別のユーザー名を設定することができます。別のユーザーとしていくつかのタスクを実行するだけの場合は、「:ref:`become`」を参照してください。Playbookで接続ユーザーを設定することができます。" + +#: ../../rst/user_guide/connection_details.rst:32 +msgid "as a host variable in inventory:" +msgstr "インベントリーのホスト変数では、以下のようになります。" + +#: ../../rst/user_guide/connection_details.rst:39 +msgid "or as a group variable in inventory:" +msgstr "また、インベントリーのグローバル変数では、以下のようになります。" + +#: ../../rst/user_guide/connection_details.rst:52 +msgid ":ref:`ssh_connection`" +msgstr ":ref:`ssh_connection`" + +#: ../../rst/user_guide/connection_details.rst:53 +msgid "Details on the ``remote_user`` keyword and ``ansible_user`` variable." +msgstr "``remote_user`` キーワードおよび ``ansible_user`` 変数の詳細。" + +#: ../../rst/user_guide/connection_details.rst:54 +msgid ":ref:`general_precedence_rules`" +msgstr ":ref:`general_precedence_rules`" + +#: ../../rst/user_guide/connection_details.rst:55 +msgid "Details on Ansible precedence rules." +msgstr "Ansible の優先度ルールの詳細。" + +#: ../../rst/user_guide/connection_details.rst:58 +msgid "Setting up SSH keys" +msgstr "SSH キーの設定" + +#: ../../rst/user_guide/connection_details.rst:60 +msgid "By default, Ansible assumes you are using SSH keys to connect to remote machines. SSH keys are encouraged, but you can use password authentication if needed with the ``--ask-pass`` option. If you need to provide a password for :ref:`privilege escalation <become>` (sudo, pbrun, and so on), use ``--ask-become-pass``." +msgstr "デフォルトでは、Ansible は SSH 鍵を使用してリモートマシンに接続することを想定しています。SSH キーが推奨されますが、必要に応じて ``--ask-pass`` オプションを使用してパスワード認証を使用できます。:ref:`privilege escalation <become>` (sudo、pbrun など) のパスワードを提供する必要がある場合は、``--ask-become-pass`` を使用します。" + +#: ../../rst/user_guide/shared_snippets/SSH_password_prompt.txt:2 +msgid "Ansible does not expose a channel to allow communication between the user and the ssh process to accept a password manually to decrypt an ssh key when using the ssh connection plugin (which is the default). The use of ``ssh-agent`` is highly recommended." +msgstr "Ansible は、ssh connection プラグインを使用している場合 (これがデフォルトです)は、ユーザーと ssh プロセスの間の通信を可能にするチャンネルを公開しておらず、ssh 鍵を復号するためのパスワードを手動で受け入れることができません。``ssh-agent`` を使用することが強く推奨されます。" + +#: ../../rst/user_guide/connection_details.rst:64 +msgid "To set up SSH agent to avoid retyping passwords, you can do:" +msgstr "パスワードを再入力しないように SSH エージェントをセットアップするには、次のようにします。" + +#: ../../rst/user_guide/connection_details.rst:71 +msgid "Depending on your setup, you may wish to use Ansible's ``--private-key`` command line option to specify a pem file instead. You can also add the private key file:" +msgstr "セットアップによっては、代わりに Ansible の ``--private-key`` コマンドラインオプションを使用して pem ファイルを指定することもできます。秘密鍵ファイルを追加することもできます。" + +#: ../../rst/user_guide/connection_details.rst:78 +msgid "Another way to add private key files without using ssh-agent is using ``ansible_ssh_private_key_file`` in an inventory file as explained here: :ref:`intro_inventory`." +msgstr "ssh-agent を使用せずに秘密鍵ファイルを追加する別の方法は、「:ref:`intro_inventory`」で説明するように、インベントリーファイルで ``ansible_ssh_private_key_file`` を使用することです。" + +#: ../../rst/user_guide/connection_details.rst:81 +msgid "Running against localhost" +msgstr "ローカルホストに対して実行" + +#: ../../rst/user_guide/connection_details.rst:83 +msgid "You can run commands against the control node by using \"localhost\" or \"127.0.0.1\" for the server name:" +msgstr "サーバー名に「localhost」または「127.0.0.1」を使用して、コントロールノードにコマンドを実行できます。" + +#: ../../rst/user_guide/connection_details.rst:89 +msgid "You can specify localhost explicitly by adding this to your inventory file:" +msgstr "これをインベントリーファイルに追加して、localhost を明示的に指定できます。" + +#: ../../rst/user_guide/connection_details.rst:98 +msgid "Managing host key checking" +msgstr "ホスト鍵の確認の管理" + +#: ../../rst/user_guide/connection_details.rst:100 +msgid "Ansible enables host key checking by default. Checking host keys guards against server spoofing and man-in-the-middle attacks, but it does require some maintenance." +msgstr "Ansible は、デフォルトでホスト鍵の確認を有効にします。ホスト鍵を確認すると、サーバーのなりすましや中間者攻撃から保護されますが、メンテナンスが必要です。" + +#: ../../rst/user_guide/connection_details.rst:102 +msgid "If a host is reinstalled and has a different key in 'known_hosts', this will result in an error message until corrected. If a new host is not in 'known_hosts' your control node may prompt for confirmation of the key, which results in an interactive experience if using Ansible, from say, cron. You might not want this." +msgstr "ホストが再インストールされ、「known_hosts」に異なるキーがある場合は、修正されるまでエラーメッセージが表示されます。新しいホストが「known_hosts」にない場合、コントロールノードはキーの確認を求めるかもしれませんが、これは Ansible を cron などから使用している場合は、インタラクティブな操作になります。このように動作しないようにしたい場合があります。" + +#: ../../rst/user_guide/connection_details.rst:104 +msgid "If you understand the implications and wish to disable this behavior, you can do so by editing ``/etc/ansible/ansible.cfg`` or ``~/.ansible.cfg``:" +msgstr "この動作を無効にした場合の影響を理解し、無効にする場合は、``/etc/ansible/ansible.cfg`` または ``~/.ansible.cfg`` 編集します。" + +#: ../../rst/user_guide/connection_details.rst:111 +msgid "Alternatively this can be set by the :envvar:`ANSIBLE_HOST_KEY_CHECKING` environment variable:" +msgstr "また、これは、:envvar:`ANSIBLE_HOST_KEY_CHECKING` 環境変数により設定できます。" + +#: ../../rst/user_guide/connection_details.rst:117 +msgid "Also note that host key checking in paramiko mode is reasonably slow, therefore switching to 'ssh' is also recommended when using this feature." +msgstr "また、paramiko モードでのホストキーチェックはかなり遅いため、この機能を使用する場合は「ssh」に切り替えることも推奨されます。" + +#: ../../rst/user_guide/connection_details.rst:120 +msgid "Other connection methods" +msgstr "その他の接続方法" + +#: ../../rst/user_guide/connection_details.rst:122 +msgid "Ansible can use a variety of connection methods beyond SSH. You can select any connection plugin, including managing things locally and managing chroot, lxc, and jail containers. A mode called 'ansible-pull' can also invert the system and have systems 'phone home' via scheduled git checkouts to pull configuration directives from a central repository." +msgstr "Ansible では、SSH 以外にもさまざまな接続方法を利用することができます。ローカルでの管理、chroot コンテナー、lxc コンテナー、および jail コンテナーの管理など、任意の connection プラグインを選択できます。「ansible-pull」と呼ばれるモードでは、システムを反転させて、スケジュールされた git チェックアウトを介してシステムを「phone home」させ、中央のリポジトリーから設定ディレクティブを引き出すこともできます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:3 +msgid "Playbook Example: Continuous Delivery and Rolling Upgrades" +msgstr "Playbook の例: 継続的デリバリーおよびローリングアップグレード" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:11 +msgid "What is continuous delivery?" +msgstr "継続的デリバリーとは" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:13 +msgid "Continuous delivery (CD) means frequently delivering updates to your software application." +msgstr "継続的デリバリー (CD) は、ソフトウェアアプリケーションに更新を頻繁に配信することを意味します。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:15 +msgid "The idea is that by updating more often, you do not have to wait for a specific timed period, and your organization gets better at the process of responding to change." +msgstr "更新の頻度を上げることで、特定の期間を待つ必要がなくなり、組織は変化に対応するプロセスを改善できるという考え方です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:18 +msgid "Some Ansible users are deploying updates to their end users on an hourly or even more frequent basis -- sometimes every time there is an approved code change. To achieve this, you need tools to be able to quickly apply those updates in a zero-downtime way." +msgstr "Ansible のユーザーの中には、エンドユーザーにアップデートを毎時またはそれ以上の頻度で配布している人がいます。承認されたコード変更があるたびに配布している場合もあります。そのためには、ダウンタイムなしで更新を迅速に適用できるツールが必要です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:21 +msgid "This document describes in detail how to achieve this goal, using one of Ansible's most complete example playbooks as a template: lamp_haproxy. This example uses a lot of Ansible features: roles, templates, and group variables, and it also comes with an orchestration playbook that can do zero-downtime rolling upgrades of the web application stack." +msgstr "本ガイドでは、Ansible の最も完成度の高いサンプル Playbook の 1 つである lamp_haproxy をテンプレートとして、この目標を達成する方法を詳細に説明します。この例では、ロール、テンプレート、グループ変数などの Ansible の機能が数多く使用されており、Web アプリケーションスタックのローリングアップグレードをダウンタイムなしで行うことができるオーケストレーション Playbook も付属しています。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:28 +msgid "`Click here for the latest playbooks for this example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_." +msgstr "このサンプルに使用する Playbook を取得するには、`こちら <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_ をクリックします。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:31 +msgid "The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers." +msgstr "Playbook は Apache、PHP、MySQL、Nagios、および HAProxy を CentOS ベースのサーバーセットにデプロイします。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:33 +msgid "We're not going to cover how to run these playbooks here. Read the included README in the github project along with the example for that information. Instead, we're going to take a close look at every part of the playbook and describe what it does." +msgstr "ここでは、これらの Playbook を実行する方法については説明しません。その情報については、github プロジェクトに含まれる README をサンプルと一緒に読んでください。その代わり、Playbook の各部分をよく見て、それが何をするのかを説明します。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:39 +msgid "Site deployment" +msgstr "サイトのデプロイメント" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:41 +msgid "Let's start with ``site.yml``. This is our site-wide deployment playbook. It can be used to initially deploy the site, as well as push updates to all of the servers:" +msgstr "まず、``site.yml`` から始めましょう。これは、サイト全体のデプロイメント Playbook です。この Playbook を使用して、サイトの初期デプロイメントと、すべてのサーバーへの更新のプッシュを行うことができます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:86 +msgid "If you're not familiar with terms like playbooks and plays, you should review :ref:`working_with_playbooks`." +msgstr "Playbook やプレイなどの用語に慣れていない場合は、:ref:`working_with_playbooks` を確認してください。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:88 +msgid "In this playbook we have 5 plays. The first one targets ``all`` hosts and applies the ``common`` role to all of the hosts. This is for site-wide things like yum repository configuration, firewall configuration, and anything else that needs to apply to all of the servers." +msgstr "この Playbook では 5 つのプレイを紹介します。最初の Playbook は ``all`` のホストを対象とし、``common`` のロールをすべてのホストに適用します。これは、yum リポジトリーの設定やファイアウォールの設定など、サイト全体ですべてのサーバーに適用する必要があるものを対象としています。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:91 +msgid "The next four plays run against specific host groups and apply specific roles to those servers. Along with the roles for Nagios monitoring, the database, and the web application, we've implemented a ``base-apache`` role that installs and configures a basic Apache setup. This is used by both the sample web application and the Nagios hosts." +msgstr "次の 4 つのプレイは、特定のホストグループに対して実行し、それらのサーバーに特定のロールを適用します。Nagios 監視、データベース、Web アプリケーションのロールと一緒に、基本的な Apache セットアップをインストールして設定する ``base-apache`` ロールを実装しました。これは、サンプルの Web アプリケーションと Nagios ホストの両方で使用されます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:99 +msgid "Reusable content: roles" +msgstr "再利用可能なコンテンツ: ロール" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:101 +msgid "By now you should have a bit of understanding about roles and how they work in Ansible. Roles are a way to organize content: tasks, handlers, templates, and files, into reusable components." +msgstr "その結果、ロールおよび Ansible での動作についてある程度理解できるはずです。ロールは、タスク、ハンドラー、テンプレート、ファイルなどのコンテンツを再利用可能なコンポーネントに整理する方法です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:104 +msgid "This example has six roles: ``common``, ``base-apache``, ``db``, ``haproxy``, ``nagios``, and ``web``. How you organize your roles is up to you and your application, but most sites will have one or more common roles that are applied to all systems, and then a series of application-specific roles that install and configure particular parts of the site." +msgstr "この例では、``common``、``base-apache``、``db``、``haproxy``、``nagios``、および ``web`` の 6 つのロールがあります。ロールをどのように編成するかは、ニーズおよび使用するアプリケーション次第ですが、ほとんどのサイトでは、すべてのシステムに適用される 1 つまたは複数の共通ロールと、サイトの特定の部分をインストールおよび設定する一連のアプリケーション固有のロールがあります。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:108 +msgid "Roles can have variables and dependencies, and you can pass in parameters to roles to modify their behavior. You can read more about roles in the :ref:`playbooks_reuse_roles` section." +msgstr "ロールは変数と依存関係を持つことができ、パラメーターをロールに渡すことでその動作を変更できます。ロールについては、「:ref:`playbooks_reuse_roles`」セクションで詳しく説明しています。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:114 +msgid "Configuration: group variables" +msgstr "設定: グループ変数" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:116 +msgid "Group variables are variables that are applied to groups of servers. They can be used in templates and in playbooks to customize behavior and to provide easily-changed settings and parameters. They are stored in a directory called ``group_vars`` in the same location as your inventory. Here is lamp_haproxy's ``group_vars/all`` file. As you might expect, these variables are applied to all of the machines in your inventory:" +msgstr "グループ変数は、サーバーのグループに適用される変数です。テンプレートや Playbook で使用することで、動作をカスタマイズしたり、簡単に変更できる設定やパラメーターを提供することができます。グループ変数は、インベントリーと同じ場所にある ``group_vars`` ディレクトリーに保存されます。以下は lamp_haproxy の ``group_vars/all`` ファイルです。ご想像のとおり、これらの変数はインベントリー内のすべてのマシンに適用されます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:127 +msgid "This is a YAML file, and you can create lists and dictionaries for more complex variable structures. In this case, we are just setting two variables, one for the port for the web server, and one for the NTP server that our machines should use for time synchronization." +msgstr "これは YAML ファイルですが、リストやディクショナリーを作成することで、より複雑な変数構造にすることができます。ここでは 2 つの変数を設定しています。1 つは Web サーバーのポート用、もう 1 つはマシンが時刻同期に使用する NTP サーバーのポート用です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:131 +msgid "Here's another group variables file. This is ``group_vars/dbservers`` which applies to the hosts in the ``dbservers`` group:" +msgstr "次は、別のグループ変数ファイルです。これは、``dbservers`` グループのホストに適用される ``group_vars/dbservers`` です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:142 +msgid "If you look in the example, there are group variables for the ``webservers`` group and the ``lbservers`` group, similarly." +msgstr "上記の例を参照すると、同様に ``webservers`` グループと ``lbservers`` グループのグループ変数も存在します。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:144 +msgid "These variables are used in a variety of places. You can use them in playbooks, like this, in ``roles/db/tasks/main.yml``:" +msgstr "これらの変数はさまざまな場所で使用され、``roles/db/tasks/main.yml`` のように Playbook でも使用できます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:161 +msgid "You can also use these variables in templates, like this, in ``roles/common/templates/ntp.conf.j2``:" +msgstr "これらの変数は、``roles/common/templates/ntp.conf.j2`` で、テンプレートで使用することもできます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:176 +msgid "You can see that the variable substitution syntax of {{ and }} is the same for both templates and variables. The syntax inside the curly braces is Jinja2, and you can do all sorts of operations and apply different filters to the data inside. In templates, you can also use for loops and if statements to handle more complex situations, like this, in ``roles/common/templates/iptables.j2``:" +msgstr "{{ および }} の変数置換構文は、テンプレートでも変数でも同じであることがわかります。中括弧の中の構文は Jinja2 のもので、中のデータに対してあらゆる種類の操作やさまざまなフィルターを適用することができます。テンプレートでは、for ループや if 文を使用して、以下のように、``roles/common/templates/iptables.j2`` でより複雑な状況を処理することもできます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:187 +msgid "This is testing to see if the inventory name of the machine we're currently operating on (``inventory_hostname``) exists in the inventory group ``dbservers``. If so, that machine will get an iptables ACCEPT line for port 3306." +msgstr "これは、現在操作しているマシンのインベントリー名 (``inventory_hostname``) が、インベントリーグループ ``dbservers`` に存在するかどうかをテストしています。存在する場合、そのマシンはポート 3306 に対して iptables の ACCEPT 行を取得します。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:190 +msgid "Here's another example, from the same template:" +msgstr "以下は、同じテンプレートの別の例です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:198 +msgid "This loops over all of the hosts in the group called ``monitoring``, and adds an ACCEPT line for each monitoring hosts' default IPv4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts." +msgstr "これは、``monitoring`` というグループのすべてのホストをループし、現在のマシンの iptables 設定に、各監視ホストのデフォルトの IPv4 アドレスに ACCEPT 行を追加し、Nagios がそれらのホストを監視できるようにします。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:201 +msgid "You can learn a lot more about Jinja2 and its capabilities `here <https://jinja.palletsprojects.com/>`_, and you can read more about Ansible variables in general in the :ref:`playbooks_variables` section." +msgstr "Jinja2 とその機能については `こちら <https://jinja.palletsprojects.com/>`_ で、また Ansible の変数全般については :ref:`playbooks_variables` で詳しく説明しています。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:207 +msgid "The rolling upgrade" +msgstr "ローリングアップグレード" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:209 +msgid "Now you have a fully-deployed site with web servers, a load balancer, and monitoring. How do you update it? This is where Ansible's orchestration features come into play. While some applications use the term 'orchestration' to mean basic ordering or command-blasting, Ansible refers to orchestration as 'conducting machines like an orchestra', and has a pretty sophisticated engine for it." +msgstr "これで、Web サーバー、ロードバランサー、および監視機能を備えた完全なサイトが展開されました。これをどうやって更新しますか。ここで、Ansible のオーケストレーション機能が活躍します。アプリケーションの中には、「オーケストレーション」という言葉を、基本的な命令やコマンドブラストの意味で使用しているものもありますが、Ansible ではオーケストレーションを「オーケストラのようにマシンを指揮すること」と呼んでおり、そのためにかなり高度なエンジンを備えています。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:213 +msgid "Ansible has the capability to do operations on multi-tier applications in a coordinated way, making it easy to orchestrate a sophisticated zero-downtime rolling upgrade of our web application. This is implemented in a separate playbook, called ``rolling_update.yml``." +msgstr "Ansible には、多層アプリケーションの操作を連携して行う機能があり、Web アプリケーションのダウンタイムなしのローリングアップグレードを簡単に編成 (オーケストレーション) することができます。これは、``rolling_update.yml`` という名前の別の Playbook に実装されています。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:215 +msgid "Looking at the playbook, you can see it is made up of two plays. The first play is very simple and looks like this:" +msgstr "Playbook を確認すると、2 つのプレイで構成されていることがわかります。1 つ目のプレイはとてもシンプルで、次のようになります。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:222 +msgid "What's going on here, and why are there no tasks? You might know that Ansible gathers \"facts\" from the servers before operating upon them. These facts are useful for all sorts of things: networking information, OS/distribution versions, and so on. In our case, we need to know something about all of the monitoring servers in our environment before we perform the update, so this simple play forces a fact-gathering step on our monitoring servers. You will see this pattern sometimes, and it's a useful trick to know." +msgstr "どうなっているのでしょうか。なぜタスクが存在しないのでしょうか。Ansible は、サーバーを操作する前に、サーバーから「ファクト」を収集することはご存知かもしれません。これらのファクトは、ネットワーク情報、OS/ディストリビューションのバージョンなど、あらゆる種類のものに役立ちます。今回のケースでは、更新を実行する前に、環境内のすべての監視サーバーについて何かを知る必要があるため、この単純なプレイによって、監視サーバーのファクト収集ステップが強制的に実行されます。このパターンは時々見かけますが、知っておくと便利なワザです。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:224 +msgid "The next part is the update play. The first part looks like this:" +msgstr "次の部分は、更新プレイです。最初の部分は以下のようになっています。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:232 +msgid "This is just a normal play definition, operating on the ``webservers`` group. The ``serial`` keyword tells Ansible how many servers to operate on at once. If it's not specified, Ansible will parallelize these operations up to the default \"forks\" limit specified in the configuration file. But for a zero-downtime rolling upgrade, you may not want to operate on that many hosts at once. If you had just a handful of webservers, you may want to set ``serial`` to 1, for one host at a time. If you have 100, maybe you could set ``serial`` to 10, for ten at a time." +msgstr "これは通常のプレイ定義で、``webservers`` グループで動作します。``serial`` キーワードは、一度に操作するサーバーの数を Ansible に伝えます。このキーワードが指定されていない場合、Ansible は設定ファイルで指定されているデフォルトの「フォーク」制限まで、これらの操作を並列化します。しかし、ダウンタイムなしのローリングアップグレードでは、それほど多くのホストを一度に操作する必要はないでしょう。Web サーバーがほんの一握りしかない場合には、``serial`` を 1 に設定して、一度に 1 つのホストに対して行うのがよいでしょう。100 台ある場合は、``serial`` を 10 に設定して、一度に 10 台のホストを操作することもできます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:234 +msgid "Here is the next part of the update play:" +msgstr "以下は更新プレイの次の部分です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:253 +msgid "The ``serial`` keyword forces the play to be executed in 'batches'. Each batch counts as a full play with a subselection of hosts. This has some consequences on play behavior. For example, if all hosts in a batch fails, the play fails, which in turn fails the entire run. You should consider this when combining with ``max_fail_percentage``." +msgstr "``serial`` キーワードを使用すると、プレイが「バッチ」で実行されます。各バッチは、ホストのサブセレクションを使用した完全なプレイとしてカウントされます。これは、プレイの動作にいくつかの影響を与えます。たとえば、バッチ内のすべてのホストが失敗した場合、そのプレイは失敗し、その結果、全体の実行も失敗します。``max_fail_percentage`` と組み合わせる場合は、この点を考慮する必要があります。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:256 +msgid "The ``pre_tasks`` keyword just lets you list tasks to run before the roles are called. This will make more sense in a minute. If you look at the names of these tasks, you can see that we are disabling Nagios alerts and then removing the webserver that we are currently updating from the HAProxy load balancing pool." +msgstr "``pre_tasks`` キーワードでは、ロールが呼び出される前に実行するタスクをリストアップすることができます。これはすぐに意味をなします。これらのタスクの名前を見ると、Nagios のアラートを無効にして、現在更新中の Web サーバーを HAProxy 負荷分散プールから削除していることがわかります。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:258 +msgid "The ``delegate_to`` and ``loop`` arguments, used together, cause Ansible to loop over each monitoring server and load balancer, and perform that operation (delegate that operation) on the monitoring or load balancing server, \"on behalf\" of the webserver. In programming terms, the outer loop is the list of web servers, and the inner loop is the list of monitoring servers." +msgstr "``delegate_to`` 引数および ``loop`` 引数を一緒に使用すると、Ansible が各監視サーバーとロードバランサーをループし、Web サーバーに「代わって」監視サーバーまたは負荷分散サーバーでその操作を実行 (操作を委譲) することになります。プログラミング用語では、外部ループは Web サーバーのリスト、内部ループは監視サーバーのリストになります。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:260 +msgid "Note that the HAProxy step looks a little complicated. We're using HAProxy in this example because it's freely available, though if you have (for instance) an F5 or Netscaler in your infrastructure (or maybe you have an AWS Elastic IP setup?), you can use Ansible modules to communicate with them instead. You might also wish to use other monitoring modules instead of nagios, but this just shows the main goal of the 'pre tasks' section -- take the server out of monitoring, and take it out of rotation." +msgstr "HAProxy のステップは少し複雑に見えることに注意してください。この例では HAProxy を使用していますが、これは自由に利用できるからです。しかし、(たとえば) F5 や Netscaler がインフラストラクチャーにある場合 (あるいは AWS の Elastic IP を設定している場合) は、代わりに Ansible モジュールを使用してそれらと通信することができます。nagios の代わりに他の監視モジュールを使用することもできますが、これは「事前タスク」セクションの主な目的、つまり、サーバーを監視から外し、ローテーションから外すことを示しています。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:262 +msgid "The next step simply re-applies the proper roles to the web servers. This will cause any configuration management declarations in ``web`` and ``base-apache`` roles to be applied to the web servers, including an update of the web application code itself. We don't have to do it this way--we could instead just purely update the web application, but this is a good example of how roles can be used to reuse tasks:" +msgstr "次の手順では、適切なロールを Web サーバーに再適用するだけです。これにより、``web`` と ``base-apache`` のロールにおける構成管理宣言が Web サーバーに適用され、Web アプリケーションコード自体の更新も行われます。このようにしなくても、純粋に Web アプリケーションを更新するだけでもよいのですが、これはロールを使用してタスクを再利用する方法のよい例です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:271 +msgid "Finally, in the ``post_tasks`` section, we reverse the changes to the Nagios configuration and put the web server back in the load balancing pool:" +msgstr "最後に、``post_tasks`` セクションで、Nuppet 設定への変更を元に戻し、Web サーバーを負荷分散プールに戻します。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:289 +msgid "Again, if you were using a Netscaler or F5 or Elastic Load Balancer, you would just substitute in the appropriate modules instead." +msgstr "NetScaler、F5、または Elastic Load Balancer を使用する場合は、代わりに適切なモジュールに置き換えてください。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:294 +msgid "Managing other load balancers" +msgstr "その他のロードバランサーの管理" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:296 +msgid "In this example, we use the simple HAProxy load balancer to front-end the web servers. It's easy to configure and easy to manage. As we have mentioned, Ansible has support for a variety of other load balancers like Citrix NetScaler, F5 BigIP, Amazon Elastic Load Balancers, and more. See the :ref:`working_with_modules` documentation for more information." +msgstr "この例では、シンプルな HAProxy ロードバランサーを Web サーバーのフロントエンドに使用しています。設定が簡単で、管理も容易です。これまで述べてきたように、Ansible は Citrix NetScaler、F5 BigIP、Amazon Elastic Load Balancer など、他のさまざまなロードバランサーをサポートしています。詳細は、「:ref:`working_with_modules`」のドキュメントをご覧ください。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:298 +msgid "For other load balancers, you may need to send shell commands to them (like we do for HAProxy above), or call an API, if your load balancer exposes one. For the load balancers for which Ansible has modules, you may want to run them as a ``local_action`` if they contact an API. You can read more about local actions in the :ref:`playbooks_delegation` section. Should you develop anything interesting for some hardware where there is not a module, it might make for a good contribution!" +msgstr "その他のロードバランサーの場合は、シェルコマンドを送信するか (上記の HAProxy の場合と同様)、ロードバランサーが API を公開している場合は API を呼び出す必要があるかもしれません。Ansible にモジュールが用意されているロードバランサーについては、API を呼び出す場合には、``local_action`` として実行することもできます。ローカルアクションについては、:ref:`playbooks_delegation` セクションで詳しく説明しています。モジュールがないハードウェアで何か面白いものを開発したら、良い貢献になるかもしれません。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:303 +msgid "Continuous delivery end-to-end" +msgstr "継続的デリバリーのエンドツーエンド" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:305 +msgid "Now that you have an automated way to deploy updates to your application, how do you tie it all together? A lot of organizations use a continuous integration tool like `Jenkins <https://jenkins.io/>`_ or `Atlassian Bamboo <https://www.atlassian.com/software/bamboo>`_ to tie the development, test, release, and deploy steps together. You may also want to use a tool like `Gerrit <https://www.gerritcodereview.com/>`_ to add a code review step to commits to either the application code itself, or to your Ansible playbooks, or both." +msgstr "アプリケーションの更新を自動的にデプロイする方法が確立されましたが、これらをどのようにまとめたらよいでしょうか。多くの組織では、`Jenkins <https://jenkins.io/>`_ や `Atlassian Bamboo <https://www.atlassian.com/software/bamboo>`_ のような継続的統合ツールを使用して、開発、テスト、リリース、デプロイの各ステップを関連付けています。また、`Gerrit <https://www.gerritcodereview.com/>`_ のようなツールを使用して、アプリケーションコード自体か、Ansible Playbook のいずれか、または両方のコミットにコードレビューのステップを追加することもできます。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:307 +msgid "Depending on your environment, you might be deploying continuously to a test environment, running an integration test battery against that environment, and then deploying automatically into production. Or you could keep it simple and just use the rolling-update for on-demand deployment into test or production specifically. This is all up to you." +msgstr "環境によっては、テスト環境に継続的にデプロイし、その環境に対して統合テストバッテリーを実行してから、実稼働環境に自動的にデプロイする場合があります。または、シンプルに保ち、ローリングアップデートを使用して、特にテスト環境または実稼働環境にオンデマンドでデプロイすることもできます。これはすべてあなた次第です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:309 +msgid "For integration with Continuous Integration systems, you can easily trigger playbook runs using the ``ansible-playbook`` command line tool, or, if you're using AWX, the ``tower-cli`` command or the built-in REST API. (The tower-cli command 'joblaunch' will spawn a remote job over the REST API and is pretty slick)." +msgstr "継続的統合システムとの連携では、``ansible-playbook`` コマンドラインツール (AWX を使用している場合は、``tower-cli`` コマンドや組み込み REST API) を使用して簡単に Playbook の実行をトリガーすることができます (tower-cli コマンドの「joblaunch」は、REST API を介してリモートジョブを生成し、非常に洗練されています)。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:311 +msgid "This should give you a good idea of how to structure a multi-tier application with Ansible, and orchestrate operations upon that app, with the eventual goal of continuous delivery to your customers. You could extend the idea of the rolling upgrade to lots of different parts of the app; maybe add front-end web servers along with application servers, for instance, or replace the SQL database with something like MongoDB or Riak. Ansible gives you the capability to easily manage complicated environments and automate common operations." +msgstr "ここでは、Ansible を使用して多層アプリケーションを構築し、そのアプリケーションの操作を調整して、最終的に顧客に継続的に提供する方法を紹介しています。ローリングアップグレードの概念は、アプリケーションのさまざまな部分に広げることができます。たとえば、アプリケーションサーバーと一緒にフロントエンドの Web サーバーを追加したり、SQL データベースを MongoDB や Riak のようなものに置き換えたりすることができます。Ansible は、複雑な環境を簡単に管理し、一般的な操作を自動化する機能を提供します。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:315 +msgid "`lamp_haproxy example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_" +msgstr "`lamp_haproxy example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:316 +msgid "The lamp_haproxy example discussed here." +msgstr "ここで説明した lamp_haproxy の例です。" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:317 +#: ../../rst/user_guide/intro_adhoc.rst:207 +#: ../../rst/user_guide/intro_bsd.rst:271 +#: ../../rst/user_guide/intro_inventory.rst:792 +#: ../../rst/user_guide/intro_patterns.rst:222 +#: ../../rst/user_guide/modules_intro.rst:53 +#: ../../rst/user_guide/modules_support.rst:65 +#: ../../rst/user_guide/playbooks_best_practices.rst:170 +#: ../../rst/user_guide/playbooks_conditionals.rst:525 +#: ../../rst/user_guide/playbooks_lookups.rst:28 +#: ../../rst/user_guide/playbooks_reuse.rst:211 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:15 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:592 +#: ../../rst/user_guide/playbooks_roles.rst:15 +#: ../../rst/user_guide/sample_setup.rst:286 +msgid ":ref:`working_with_playbooks`" +msgstr ":ref:`working_with_playbooks`" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:318 +#: ../../rst/user_guide/playbooks_async.rst:185 +#: ../../rst/user_guide/playbooks_blocks.rst:183 +#: ../../rst/user_guide/playbooks_conditionals.rst:526 +#: ../../rst/user_guide/playbooks_debugger.rst:338 +#: ../../rst/user_guide/playbooks_delegation.rst:166 +#: ../../rst/user_guide/playbooks_environment.rst:149 +#: ../../rst/user_guide/playbooks_error_handling.rst:269 +#: ../../rst/user_guide/playbooks_filters.rst:2178 +#: ../../rst/user_guide/playbooks_lookups.rst:29 +#: ../../rst/user_guide/playbooks_loops.rst:477 +#: ../../rst/user_guide/playbooks_prompts.rst:116 +#: ../../rst/user_guide/playbooks_startnstep.rst:44 +#: ../../rst/user_guide/playbooks_strategies.rst:246 +#: ../../rst/user_guide/playbooks_tags.rst:426 +#: ../../rst/user_guide/playbooks_templating.rst:47 +#: ../../rst/user_guide/playbooks_tests.rst:510 +#: ../../rst/user_guide/playbooks_variables.rst:496 +#: ../../rst/user_guide/windows_dsc.rst:498 +#: ../../rst/user_guide/windows_faq.rst:251 +#: ../../rst/user_guide/windows_setup.rst:570 +#: ../../rst/user_guide/windows_usage.rst:509 +#: ../../rst/user_guide/windows_winrm.rst:1001 +msgid "An introduction to playbooks" +msgstr "Playbook の概要" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:319 +#: ../../rst/user_guide/playbooks_blocks.rst:184 +#: ../../rst/user_guide/playbooks_conditionals.rst:527 +#: ../../rst/user_guide/playbooks_filters.rst:2185 +#: ../../rst/user_guide/playbooks_loops.rst:478 +#: ../../rst/user_guide/playbooks_strategies.rst:249 +#: ../../rst/user_guide/playbooks_tags.rst:427 +#: ../../rst/user_guide/playbooks_templating.rst:52 +#: ../../rst/user_guide/playbooks_tests.rst:517 +#: ../../rst/user_guide/playbooks_variables.rst:503 +msgid ":ref:`playbooks_reuse_roles`" +msgstr ":ref:`playbooks_reuse_roles`" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:320 +msgid "An introduction to playbook roles" +msgstr "Playbook のロールの概要" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:321 +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:117 +#: ../../rst/user_guide/playbooks_conditionals.rst:531 +#: ../../rst/user_guide/playbooks_error_handling.rst:274 +#: ../../rst/user_guide/playbooks_filters.rst:2181 +#: ../../rst/user_guide/playbooks_lookups.rst:32 +#: ../../rst/user_guide/playbooks_loops.rst:484 +#: ../../rst/user_guide/playbooks_prompts.rst:119 +#: ../../rst/user_guide/playbooks_reuse.rst:213 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:19 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:596 +#: ../../rst/user_guide/playbooks_tests.rst:513 +msgid ":ref:`playbooks_variables`" +msgstr ":ref:`playbooks_variables`" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:322 +msgid "An introduction to Ansible variables" +msgstr "Ansible 変数の概要" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:323 +msgid "`Ansible.com: Continuous Delivery <https://www.ansible.com/use-cases/continuous-delivery>`_" +msgstr "`Ansible.com: Continuous Delivery <https://www.ansible.com/use-cases/continuous-delivery>`_" + +#: ../../rst/user_guide/guide_rolling_upgrade.rst:324 +msgid "An introduction to Continuous Delivery with Ansible" +msgstr "Ansible を使用した継続的デリバリーの概要" + +#: ../../rst/user_guide/index.rst:5 +msgid "User Guide" +msgstr "ユーザーガイド" + +#: ../../rst/user_guide/index.rst:9 +msgid "**Making Open Source More Inclusive**" +msgstr "**多様性を受け入れるオープンソースの強化**" + +#: ../../rst/user_guide/index.rst:11 +msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_." +msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_ を参照してください。" + +#: ../../rst/user_guide/index.rst:13 +msgid "Welcome to the Ansible User Guide! This guide covers how to work with Ansible, including using the command line, working with inventory, interacting with data, writing tasks, plays, and playbooks; executing playbooks, and reference materials. Quickly find answers in the following sections or expand the table of contents below to scroll through all resources." +msgstr "Ansible ユーザーガイドへようこそ! 本ガイドでは、コマンドラインの使用、インベントリーの操作、データの操作、タスク、プレイ、Playbook の作成、Playbook 実行、参考資料など、Ansible の使用方法について説明しています。次のセクションで回答をすばやく確認するか、下のコンテンツ表を拡張してすべてのリソースをスクロールします。" + +#: ../../rst/user_guide/index.rst:17 +msgid "Writing tasks, plays, and playbooks" +msgstr "タスク、プレイ、および Playbook の作成" + +#: ../../rst/user_guide/index.rst:19 +msgid "I'm writing my first playbook. What should I :ref:`know before I begin <playbooks_tips_and_tricks>`?" +msgstr "最初の Playbook を作成します。:ref:`開始する前に学ぶ <playbooks_tips_and_tricks>` にはどうすれば良いですか。" + +#: ../../rst/user_guide/index.rst:20 +msgid "I have a specific use case for a task or play:" +msgstr "タスクまたはプレイに特定のユースケースがあります。" + +#: ../../rst/user_guide/index.rst:22 +msgid "Executing tasks with elevated privileges or as a different user with :ref:`become <become>`" +msgstr ":ref:`become <become>` を使用して、権限が昇格されたタスク、または別のユーザーとしてタスクを実行する" + +#: ../../rst/user_guide/index.rst:23 +msgid "Repeating a task once for each item in a list with :ref:`loops <playbooks_loops>`" +msgstr ":ref:`ループ <playbooks_loops>` を使用してリスト内の項目ごとにタスクを 1 度繰り返す" + +#: ../../rst/user_guide/index.rst:24 +msgid "Executing tasks on a different machine with :ref:`delegation <playbooks_delegation>`" +msgstr ":ref:`delegation <playbooks_delegation>` を使用して別のマシンでタスクを実行する" + +#: ../../rst/user_guide/index.rst:25 +msgid "Running tasks only when certain conditions apply with :ref:`conditionals <playbooks_conditionals>` and evaluating conditions with :ref:`tests <playbooks_tests>`" +msgstr ":ref:`conditionals <playbooks_conditionals>` で特定の条件が適用された場合にのみタスクを実行し、:ref:`tests <playbooks_tests>` で条件を評価する" + +#: ../../rst/user_guide/index.rst:26 +msgid "Grouping a set of tasks together with :ref:`blocks <playbooks_blocks>`" +msgstr ":ref:`blocks <playbooks_blocks>` を使用してタスクのセットをまとめる" + +#: ../../rst/user_guide/index.rst:27 +msgid "Running tasks only when something has changed with :ref:`handlers <handlers>`" +msgstr ":ref:`handlers <handlers>` を使用して変更があった場合に限りタスクを実行する" + +#: ../../rst/user_guide/index.rst:28 +msgid "Changing the way Ansible :ref:`handles failures <playbooks_error_handling>`" +msgstr "Ansible が :ref:`失敗を処理する <playbooks_error_handling>` 方法を変更する" + +#: ../../rst/user_guide/index.rst:29 +msgid "Setting remote :ref:`environment values <playbooks_environment>`" +msgstr "リモートの :ref:`環境値 <playbooks_environment>` を設定する" + +#: ../../rst/user_guide/index.rst:31 +msgid "I want to take advantage of the power of re-usable Ansible artifacts. How do I create re-usable :ref:`files <playbooks_reuse>` and :ref:`roles <playbooks_reuse_roles>`?" +msgstr "再利用可能な Ansible アーティファクトの電源を活用するには、再利用可能な :ref:`files <playbooks_reuse>` および :ref:`roles <playbooks_reuse_roles>` をどのように作成すればいいですか。" + +#: ../../rst/user_guide/index.rst:32 +msgid "I need to incorporate one file or playbook inside another. What is the difference between :ref:`including and importing <dynamic_vs_static>`?" +msgstr "あるファイルまたは Playbook を別のファイルに組み込む必要があります。:ref:`インクルードとインポート <dynamic_vs_static>` の違いは何ですか。" + +#: ../../rst/user_guide/index.rst:33 +msgid "I want to run selected parts of my playbook. How do I add and use :ref:`tags <tags>`?" +msgstr "Playbook の選択した部分を実行する場合は、:ref:`タグ <tags>` をどのように追加して使用すればいいですか。" + +#: ../../rst/user_guide/index.rst:36 +msgid "Working with inventory" +msgstr "インベントリーの使用" + +#: ../../rst/user_guide/index.rst:38 +msgid "I have a list of servers and devices I want to automate. How do I create :ref:`inventory <intro_inventory>` to track them?" +msgstr "自動化するサーバーおよびデバイスの一覧があります。:ref:`インベントリー <intro_inventory>` を作成して追跡するにはどうすればいいですか。" + +#: ../../rst/user_guide/index.rst:39 +msgid "I use cloud services and constantly have servers and devices starting and stopping. How do I track them using :ref:`dynamic inventory <intro_dynamic_inventory>`?" +msgstr "クラウドサービスを使用し、サーバーおよびデバイスの開始および停止が常にあります。:ref:`動的インベントリー <intro_dynamic_inventory>` を使用してこれらを追跡するにはどうすればいいですか。" + +#: ../../rst/user_guide/index.rst:40 +msgid "I want to automate specific sub-sets of my inventory. How do I use :ref:`patterns <intro_patterns>`?" +msgstr "インベントリーの特定のサブセットを自動化したいです。:ref:`パターン <intro_patterns>` をどのように使用すればいいですか。" + +#: ../../rst/user_guide/index.rst:43 +msgid "Interacting with data" +msgstr "データとの対話" + +#: ../../rst/user_guide/index.rst:45 +msgid "I want to use a single playbook against multiple systems with different attributes. How do I use :ref:`variables <playbooks_variables>` to handle the differences?" +msgstr "異なる属性を持つ複数のシステムに対して Playbook を 1 つ使用します。:ref:`変数 <playbooks_variables>` を使用して違いを処理するにはどうしたらいいですか。" + +#: ../../rst/user_guide/index.rst:46 +msgid "I want to retrieve data about my systems. How do I access :ref:`Ansible facts <vars_and_facts>`?" +msgstr "システムに関するデータを取得したいです。:ref:`Ansible ファクト <vars_and_facts>` にアクセスするにはどうすればいいですか。" + +#: ../../rst/user_guide/index.rst:47 +msgid "I need to access sensitive data like passwords with Ansible. How can I protect that data with :ref:`Ansible vault <vault>`?" +msgstr "Ansible でパスワードなどの機密データにアクセスする必要があります。:ref:`Ansible vault <vault>` でそのデータを保護するにはどうすればいいですか。" + +#: ../../rst/user_guide/index.rst:48 +msgid "I want to change the data I have, so I can use it in a task. How do I use :ref:`filters <playbooks_filters>` to transform my data?" +msgstr "データに変更を加えて、タスクで使用できるようにします。:ref:`フィルター <playbooks_filters>` を使用してデータを変換するにはどうすればよいですか。" + +#: ../../rst/user_guide/index.rst:49 +msgid "I need to retrieve data from an external datastore. How do I use :ref:`lookups <playbooks_lookups>` to access databases and APIs?" +msgstr "外部データストアからデータを取得する必要があります。:ref:`検索 <playbooks_lookups>` を使用してデータベースおよび API にアクセスするにはどうすればいいですか。" + +#: ../../rst/user_guide/index.rst:50 +msgid "I want to ask playbook users to supply data. How do I get user input with :ref:`prompts <playbooks_prompts>`?" +msgstr "Playbook ユーザーにデータを提供するよう依頼したいです。:ref:`プロンプト <playbooks_prompts>` でユーザー入力を取得するにはどうすれば良いですか。" + +#: ../../rst/user_guide/index.rst:51 +msgid "I use certain modules frequently. How do I streamline my inventory and playbooks by :ref:`setting default values for module parameters <module_defaults>`?" +msgstr "特定のモジュールを頻繁に使用します。:ref:`モジュールパラメーターにデフォルト値を設定 <module_defaults>` によるインベントリーと Playbook をストリーミングするにはどうすれば良いですか。" + +#: ../../rst/user_guide/index.rst:54 +msgid "Executing playbooks" +msgstr "Playbook の実行" + +#: ../../rst/user_guide/index.rst:56 +msgid "Once your playbook is ready to run, you may need to use these topics:" +msgstr "Playbook の実行準備ができたら、以下のトピックを使用する必要があります。" + +#: ../../rst/user_guide/index.rst:58 +msgid "Executing \"dry run\" playbooks with :ref:`check mode and diff <check_mode_dry>`" +msgstr ":ref:`確認モードおよび差異モード <check_mode_dry>` で「ドライラン」Playbook の実行" + +#: ../../rst/user_guide/index.rst:59 +msgid "Running playbooks while troubleshooting with :ref:`start and step <playbooks_start_and_step>`" +msgstr ":ref:`start および step <playbooks_start_and_step>` を使用したトラブルシューティング時の Playbook の実行" + +#: ../../rst/user_guide/index.rst:60 +msgid "Correcting tasks during execution with the :ref:`Ansible debugger <playbook_debugger>`" +msgstr ":ref:`Ansible デバッガ― <playbook_debugger>` で実行時のタスクの修正" + +#: ../../rst/user_guide/index.rst:61 +msgid "Controlling how my playbook executes with :ref:`strategies and more <playbooks_strategies>`" +msgstr ":ref:`ストラテジーなど <playbooks_strategies>` を使用した Playbook の実行方法の制御" + +#: ../../rst/user_guide/index.rst:62 +msgid "Running tasks, plays, and playbooks :ref:`asynchronously <playbooks_async>`" +msgstr "タスク、プレイ、および Playbook を :ref:`非同期に <playbooks_async>` 実行" + +#: ../../rst/user_guide/index.rst:65 +msgid "Advanced features and reference" +msgstr "高度な機能および参照" + +#: ../../rst/user_guide/index.rst:67 +msgid "Using :ref:`advanced syntax <playbooks_advanced_syntax>`" +msgstr ":ref:`高度な構文 <playbooks_advanced_syntax>` の使用" + +#: ../../rst/user_guide/index.rst:68 +msgid "Manipulating :ref:`complex data <complex_data_manipulation>`" +msgstr ":ref:`複雑なデータ <complex_data_manipulation>` の処理" + +#: ../../rst/user_guide/index.rst:69 +msgid "Using :ref:`plugins <plugins_lookup>`" +msgstr ":ref:`プラグイン <plugins_lookup>` の使用" + +#: ../../rst/user_guide/index.rst:70 +msgid "Using :ref:`playbook keywords <playbook_keywords>`" +msgstr ":ref:`Playbook キーワード <playbook_keywords>` の使用" + +#: ../../rst/user_guide/index.rst:71 +msgid "Using :ref:`command-line tools <command_line_tools>`" +msgstr ":ref:`コマンドラインツール <command_line_tools>` の使用" + +#: ../../rst/user_guide/index.rst:72 +msgid "Rejecting :ref:`specific modules <plugin_filtering_config>`" +msgstr ":ref:`特定モジュール <plugin_filtering_config>` の拒否" + +#: ../../rst/user_guide/index.rst:73 +msgid "Module :ref:`maintenance <modules_support>`" +msgstr "モジュールの :ref:`保守 <modules_support>`" + +#: ../../rst/user_guide/index.rst:76 +msgid "Table of contents" +msgstr "目次" + +#: ../../rst/user_guide/index.rst:78 +msgid "Here is the complete list of resources in the Ansible User Guide:" +msgstr "以下は、Ansible ユーザーガイドのリソースの完全なリストです。" + +#: ../../rst/user_guide/intro.rst:4 +msgid "Introduction" +msgstr "はじめに" + +#: ../../rst/user_guide/intro.rst:6 +msgid "Before we start exploring the main components of Ansible -- playbooks, configuration management, deployment, and orchestration -- we'll learn how to get Ansible installed and cover some basic concepts. We'll also go over how to execute ad hoc commands in parallel across your nodes using /usr/bin/ansible, and see what modules are available in Ansible's core (you can also write your own, which is covered later)." +msgstr "ここでは、Ansible の主なコンポーネントである Playbook、構成管理、デプロイメント、オーケストレーションについて説明しますが、その前に、Ansible のインストール方法と基本的な概念について説明します。また、/usr/bin/ansible を使用してノード間でアドホックコマンドを並列実行する方法や、Ansible のコアにはどのようなモジュールが用意されているかを見ていきます (自分で作成することもできますが、これは後で説明します)。" + +#: ../../rst/user_guide/intro_adhoc.rst:5 +msgid "Introduction to ad hoc commands" +msgstr "アドホックコマンドの概要" + +#: ../../rst/user_guide/intro_adhoc.rst:7 +msgid "An Ansible ad hoc command uses the `/usr/bin/ansible` command-line tool to automate a single task on one or more managed nodes. ad hoc commands are quick and easy, but they are not reusable. So why learn about ad hoc commands first? ad hoc commands demonstrate the simplicity and power of Ansible. The concepts you learn here will port over directly to the playbook language. Before reading and executing these examples, please read :ref:`intro_inventory`." +msgstr "Ansible アドホックコマンドは、`/usr/bin/ansible` コマンドラインツールを使用して、1 つまたは複数の管理ノード上の単一タスクを自動化します。アドホックコマンドは素早く簡単に実行できますが、再利用はできません。では、なぜ最初にアドホックコマンドを学ぶのかというと、アドホックコマンドは Ansible の簡易さと性能を実証するものだからです。ここで学んだ概念は、そのまま Playbook 言語に移植されます。これらの例を読んで実行する前に、「:ref:`intro_inventory`」を参照してください。" + +#: ../../rst/user_guide/intro_adhoc.rst:13 +msgid "Why use ad hoc commands?" +msgstr "アドホックコマンドを使用する理由" + +#: ../../rst/user_guide/intro_adhoc.rst:15 +msgid "ad hoc commands are great for tasks you repeat rarely. For example, if you want to power off all the machines in your lab for Christmas vacation, you could execute a quick one-liner in Ansible without writing a playbook. An ad hoc command looks like this:" +msgstr "アドホックコマンドは、めったに繰り返さないタスクに最適です。たとえば、クリスマス休暇中に研究室のすべてのマシンの電源を切りたい場合は、Playbook を作成せず、Ansible で 1 行の簡単なコマンドを実行できます。アドホックコマンドは次のようなものです。" + +#: ../../rst/user_guide/intro_adhoc.rst:21 +msgid "You can learn more about :ref:`patterns<intro_patterns>` and :ref:`modules<working_with_modules>` on other pages." +msgstr "他のページで、:ref:`パターン<intro_patterns>` や :ref:`モジュール<working_with_modules>` の詳細を確認できます。" + +#: ../../rst/user_guide/intro_adhoc.rst:24 +msgid "Use cases for ad hoc tasks" +msgstr "アドホックタスクのユースケース" + +#: ../../rst/user_guide/intro_adhoc.rst:26 +msgid "ad hoc tasks can be used to reboot servers, copy files, manage packages and users, and much more. You can use any Ansible module in an ad hoc task. ad hoc tasks, like playbooks, use a declarative model, calculating and executing the actions required to reach a specified final state. They achieve a form of idempotence by checking the current state before they begin and doing nothing unless the current state is different from the specified final state." +msgstr "アドホックタスクは、サーバーの再起動、ファイルのコピー、パッケージやユーザーの管理など、さまざまな用途に使用できます。Ansible モジュールはアドホックタスクで使用できます。アドホックタスクは、Playbook と同様に、宣言型モデルを使用し、指定された最終状態に到達するために必要なアクションを計算して実行します。アドホックタスクは、開始前に現在の状態をチェックし、現在の状態が指定された最終状態と異なる場合を除いて何もしないことで、一種の冪等性を実現しています。" + +#: ../../rst/user_guide/intro_adhoc.rst:31 +msgid "Rebooting servers" +msgstr "サーバーの再起動" + +#: ../../rst/user_guide/intro_adhoc.rst:33 +msgid "The default module for the ``ansible`` command-line utility is the :ref:`ansible.builtin.command module<command_module>`. You can use an ad hoc task to call the command module and reboot all web servers in Atlanta, 10 at a time. Before Ansible can do this, you must have all servers in Atlanta listed in a group called [atlanta] in your inventory, and you must have working SSH credentials for each machine in that group. To reboot all the servers in the [atlanta] group:" +msgstr "``ansible`` コマンドラインユーティリティーのデフォルトモジュールは、:ref:`ansible.builtin.command モジュール<command_module>` です。アドホックタスクを使用してコマンドモジュールを呼び出し、Atlanta のすべての Web サーバを一度に 10 台ずつ再起動することができます。Ansible がこれを行う前に、インベントリー内の [atlanta] というグループに Atlanta にあるすべてのサーバーが記載されている必要があり、そのグループ内の各マシンの SSH 認証情報が有効でなければなりません。[atlanta] グループのすべてのサーバーを再起動するには、次のようにします。" + +#: ../../rst/user_guide/intro_adhoc.rst:39 +msgid "By default Ansible uses only 5 simultaneous processes. If you have more hosts than the value set for the fork count, Ansible will talk to them, but it will take a little longer. To reboot the [atlanta] servers with 10 parallel forks:" +msgstr "デフォルトでは、Ansible は 5 つの同時プロセスのみを使用します。フォーク数に設定された値よりも多くのホストがある場合、Ansible はそれらのホストと対話しますが、少し時間がかかります。10 個の並列フォークで [atlanta] サーバーを再起動する場合は、以下のようにします。" + +#: ../../rst/user_guide/intro_adhoc.rst:45 +msgid "/usr/bin/ansible will default to running from your user account. To connect as a different user:" +msgstr "usr/bin/ansible はデフォルトで自身のユーザーアカウントから実行されます。別のユーザーとして接続するには、以下を行います。" + +#: ../../rst/user_guide/intro_adhoc.rst:51 +msgid "Rebooting probably requires privilege escalation. You can connect to the server as ``username`` and run the command as the ``root`` user by using the :ref:`become <become>` keyword:" +msgstr "再起動には、おそらく権限昇格が必要です。``username`` としてサーバーに接続し、:ref:`become <become>` キーワードを使用して ``root`` ユーザーとしてコマンドを実行できます。" + +#: ../../rst/user_guide/intro_adhoc.rst:57 +msgid "If you add ``--ask-become-pass`` or ``-K``, Ansible prompts you for the password to use for privilege escalation (sudo/su/pfexec/doas/etc)." +msgstr "``--ask-become-pass`` または ``-K`` を追加します。Ansible により、権限昇格に使用するパスワード (sudo/su/pfexec/doas など) の入力が求められます。" + +#: ../../rst/user_guide/intro_adhoc.rst:60 +msgid "The :ref:`command module <command_module>` does not support extended shell syntax like piping and redirects (although shell variables will always work). If your command requires shell-specific syntax, use the `shell` module instead. Read more about the differences on the :ref:`working_with_modules` page." +msgstr ":ref:`command モジュール <command_module>` は、piping や redirects のような拡張シェル構文をサポートしていません (ただし、シェル変数は常に動作します)。シェル特有の構文を必要とするコマンドの場合は、代わりに `shell` モジュールを使用してください。その違いについては「:ref:`working_with_modules`」のページをご覧ください。" + +#: ../../rst/user_guide/intro_adhoc.rst:65 +msgid "So far all our examples have used the default 'command' module. To use a different module, pass ``-m`` for module name. For example, to use the :ref:`ansible.builtin.shell module <shell_module>`:" +msgstr "この例では、デフォルトの「command」モジュールを使用しています。別のモジュールを使用するには、モジュール名に ``-m`` を渡します。たとえば、:ref:`ansible.builtin.shell モジュール <shell_module>` を使用します。" + +#: ../../rst/user_guide/intro_adhoc.rst:71 +msgid "When running any command with the Ansible *ad hoc* CLI (as opposed to :ref:`Playbooks <working_with_playbooks>`), pay particular attention to shell quoting rules, so the local shell retains the variable and passes it to Ansible. For example, using double rather than single quotes in the above example would evaluate the variable on the box you were on." +msgstr "(:ref:`Playbooks <working_with_playbooks>` とは異なり) Ansible の *アドホック* CLI を使用してコマンドを実行する場合は、ローカルシェルが変数を保持して Ansible に渡すように、シェルの引用規則に特に注意してください。たとえば、上記の例で一重引用符ではなく二重引用符を使用すると、指定しているそのボックスの変数が評価されます。" + +#: ../../rst/user_guide/intro_adhoc.rst:80 +msgid "Managing files" +msgstr "ファイルの管理" + +#: ../../rst/user_guide/intro_adhoc.rst:82 +msgid "An ad hoc task can harness the power of Ansible and SCP to transfer many files to multiple machines in parallel. To transfer a file directly to all servers in the [atlanta] group:" +msgstr "アドホックタスクでは、Ansible と SCP の力を利用して、多数のファイルを複数のマシンに並行して転送することができます。[atlanta] グループのすべてのサーバーに直接ファイルを転送するには、次のようにします。" + +#: ../../rst/user_guide/intro_adhoc.rst:88 +msgid "If you plan to repeat a task like this, use the :ref:`ansible.builtin.template<template_module>` module in a playbook." +msgstr "このようなタスクを繰り返す場合は、Playbook で :ref:`ansible.builtin.template<template_module>` モジュールを使用します。" + +#: ../../rst/user_guide/intro_adhoc.rst:90 +msgid "The :ref:`ansible.builtin.file<file_module>` module allows changing ownership and permissions on files. These same options can be passed directly to the ``copy`` module as well:" +msgstr ":ref:`ansible.builtin.file<file_module>` モジュールにより、ファイルの所有権およびパーミッションを変更できます。同じオプションを ``copy`` モジュールに直接渡すことができます。" + +#: ../../rst/user_guide/intro_adhoc.rst:98 +msgid "The ``file`` module can also create directories, similar to ``mkdir -p``:" +msgstr "``file`` モジュールは、``mkdir -p`` と同様、ディレクトリーも作成できます。" + +#: ../../rst/user_guide/intro_adhoc.rst:104 +msgid "As well as delete directories (recursively) and delete files:" +msgstr "ディレクトリーを (再帰的に) 削除し、ファイルを削除します。" + +#: ../../rst/user_guide/intro_adhoc.rst:113 +msgid "Managing packages" +msgstr "パッケージの管理" + +#: ../../rst/user_guide/intro_adhoc.rst:115 +msgid "You might also use an ad hoc task to install, update, or remove packages on managed nodes using a package management module like yum. To ensure a package is installed without updating it:" +msgstr "また、yum などのパッケージ管理モジュールを使用して、管理対象のノードにパッケージをインストール、アップデート、または削除するアドホックタスクを使用することもあります。パッケージを更新せずに確実にインストールするには、以下を行います。" + +#: ../../rst/user_guide/intro_adhoc.rst:121 +msgid "To ensure a specific version of a package is installed:" +msgstr "パッケージの特定バージョンがインストールされていることを確認するには、次のコマンドを実行します。" + +#: ../../rst/user_guide/intro_adhoc.rst:127 +msgid "To ensure a package is at the latest version:" +msgstr "パッケージが最新バージョンであることを確認するには、次のコマンドを実行します。" + +#: ../../rst/user_guide/intro_adhoc.rst:133 +msgid "To ensure a package is not installed:" +msgstr "パッケージがインストールされていないことを確認するには、次のコマンドを実行します。" + +#: ../../rst/user_guide/intro_adhoc.rst:139 +msgid "Ansible has modules for managing packages under many platforms. If there is no module for your package manager, you can install packages using the command module or create a module for your package manager." +msgstr "Ansible には、多くのプラットフォームでパッケージを管理するためのモジュールが用意されています。お使いのパッケージマネージャー用のモジュールがない場合は、コマンドモジュールを使用してパッケージをインストールするか、パッケージマネージャー用のモジュールを作成してください。" + +#: ../../rst/user_guide/intro_adhoc.rst:144 +msgid "Managing users and groups" +msgstr "ユーザーおよびグループの管理" + +#: ../../rst/user_guide/intro_adhoc.rst:146 +msgid "You can create, manage, and remove user accounts on your managed nodes with ad hoc tasks:" +msgstr "アドホックタスクを使用すると、管理ノードでユーザーアカウントを作成、管理、および削除できます。" + +#: ../../rst/user_guide/intro_adhoc.rst:154 +msgid "See the :ref:`ansible.builtin.user <user_module>` module documentation for details on all of the available options, including how to manipulate groups and group membership." +msgstr "グループやグループメンバーシップの操作方法など、利用可能なすべてのオプションの詳細は、:ref:`ansible.builtin.user <user_module>` モジュールのドキュメントを参照してください。" + +#: ../../rst/user_guide/intro_adhoc.rst:160 +msgid "Managing services" +msgstr "サービスの管理" + +#: ../../rst/user_guide/intro_adhoc.rst:162 +msgid "Ensure a service is started on all webservers:" +msgstr "サービスがすべての Web サーバーで起動していることを確認します。" + +#: ../../rst/user_guide/intro_adhoc.rst:168 +msgid "Alternatively, restart a service on all webservers:" +msgstr "または、すべての Web サーバーでサービスを再起動します。" + +#: ../../rst/user_guide/intro_adhoc.rst:174 +msgid "Ensure a service is stopped:" +msgstr "サービスが停止していることを確認します。" + +#: ../../rst/user_guide/intro_adhoc.rst:183 +msgid "Gathering facts" +msgstr "ファクトの収集" + +#: ../../rst/user_guide/intro_adhoc.rst:185 +msgid "Facts represent discovered variables about a system. You can use facts to implement conditional execution of tasks but also just to get ad hoc information about your systems. To see all facts:" +msgstr "ファクトは、検出されたシステムに関する変数を表します。ファクトを使用して、タスクの条件付き実行を実装することもできますが、システムに関するアドホック情報を取得することもできます。すべてのファクトを表示するには、以下を実行します。" + +#: ../../rst/user_guide/intro_adhoc.rst:191 +msgid "You can also filter this output to display only certain facts, see the :ref:`ansible.builtin.setup <setup_module>` module documentation for details." +msgstr "この出力をフィルターで絞り込んで、特定のファクトのみを表示することもできます。詳細は :ref:`ansible.builtin.setup <setup_module>` モジュールのドキュメントを参照してください。" + +#: ../../rst/user_guide/intro_adhoc.rst:194 +#: ../../rst/user_guide/intro_patterns.rst:168 +msgid "Patterns and ad-hoc commands" +msgstr "パターンおよびアドホックコマンド" + +#: ../../rst/user_guide/intro_adhoc.rst:196 +msgid "See the :ref:`patterns <intro_patterns>` documentation for details on all of the available options, including how to limit using patterns in ad-hoc commands." +msgstr "アドホックコマンドでパターンの使用を制限する方法など、利用可能なすべてのオプションの詳細は、:ref:`patterns <intro_patterns>` のドキュメントを参照してください。" + +#: ../../rst/user_guide/intro_adhoc.rst:199 +msgid "Now that you understand the basic elements of Ansible execution, you are ready to learn to automate repetitive tasks using :ref:`Ansible Playbooks <playbooks_intro>`." +msgstr "これで、Ansible を実行する基本要素を理解し、:ref:`Ansible Playbook <playbooks_intro>` を使用して反復タスクを自動化する方法を学ぶ準備が整いました。" + +#: ../../rst/user_guide/intro_adhoc.rst:203 +msgid ":ref:`intro_configuration`" +msgstr ":ref:`intro_configuration`" + +#: ../../rst/user_guide/intro_adhoc.rst:204 +msgid "All about the Ansible config file" +msgstr "Ansible 設定ファイルの詳細" + +#: ../../rst/user_guide/intro_adhoc.rst:205 +#: ../../rst/user_guide/playbooks_best_practices.rst:172 +#: ../../rst/user_guide/playbooks_intro.rst:150 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:25 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:604 +#: ../../rst/user_guide/sample_setup.rst:288 +msgid ":ref:`list_of_collections`" +msgstr ":ref:`list_of_collections`" + +#: ../../rst/user_guide/intro_adhoc.rst:206 +#: ../../rst/user_guide/playbooks_best_practices.rst:173 +#: ../../rst/user_guide/playbooks_intro.rst:151 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:26 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:605 +#: ../../rst/user_guide/sample_setup.rst:289 +msgid "Browse existing collections, modules, and plugins" +msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" + +#: ../../rst/user_guide/intro_adhoc.rst:208 +msgid "Using Ansible for configuration management & deployment" +msgstr "設定管理およびデプロイメントに Ansible の使用" + +#: ../../rst/user_guide/intro_adhoc.rst:209 +#: ../../rst/user_guide/intro_bsd.rst:275 +#: ../../rst/user_guide/intro_dynamic_inventory.rst:250 +#: ../../rst/user_guide/intro_inventory.rst:794 +#: ../../rst/user_guide/intro_patterns.rst:224 +#: ../../rst/user_guide/modules.rst:33 +#: ../../rst/user_guide/modules_intro.rst:59 +#: ../../rst/user_guide/modules_support.rst:67 +#: ../../rst/user_guide/playbooks_best_practices.rst:180 +#: ../../rst/user_guide/playbooks_intro.rst:158 +#: ../../rst/user_guide/playbooks_reuse.rst:225 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:31 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:610 +#: ../../rst/user_guide/sample_setup.rst:296 +msgid "`Mailing List <https://groups.google.com/group/ansible-project>`_" +msgstr "`メーリングリスト <https://groups.google.com/group/ansible-project>`_" + +#: ../../rst/user_guide/intro_bsd.rst:4 +msgid "Ansible and BSD" +msgstr "Ansible および BSD" + +#: ../../rst/user_guide/intro_bsd.rst:6 +msgid "Managing BSD machines is different from managing other Unix-like machines. If you have managed nodes running BSD, review these topics." +msgstr "BSD マシンの管理は、他の Unix 系マシンの管理とは異なります。BSD を実行している管理ノードを使用している場合は、以下のトピックを確認してください。" + +#: ../../rst/user_guide/intro_bsd.rst:12 +msgid "Connecting to BSD nodes" +msgstr "BSD ノードへの接続" + +#: ../../rst/user_guide/intro_bsd.rst:14 +msgid "Ansible connects to managed nodes using OpenSSH by default. This works on BSD if you use SSH keys for authentication. However, if you use SSH passwords for authentication, Ansible relies on sshpass. Most versions of sshpass do not deal well with BSD login prompts, so when using SSH passwords against BSD machines, use ``paramiko`` to connect instead of OpenSSH. You can do this in ansible.cfg globally or you can set it as an inventory/group/host variable. For example:" +msgstr "Ansible はデフォルトで OpenSSH を使用して管理ノードに接続します。これは、認証に SSH 鍵を使用している場合は BSD で動作します。ただし、認証に SSH パスワードを使用する場合、Ansible は sshpass に依存します。sshpass のほとんどのバージョンは BSD のログインプロンプトに適切に対応できません。したがって、BSD マシンに対して SSH パスワードを使用する場合は、OpenSSH の代わりに ``paramiko`` を使用して接続してください。これは ansible.cfg でグローバルに行うこともできますし、inventory/group/host 変数として設定することもできます。以下に例を示します。" + +#: ../../rst/user_guide/intro_bsd.rst:25 +msgid "Bootstrapping BSD" +msgstr "BSD のブートストラップ" + +#: ../../rst/user_guide/intro_bsd.rst:27 +msgid "Ansible is agentless by default, however, it requires Python on managed nodes. Only the :ref:`raw <raw_module>` module will operate without Python. Although this module can be used to bootstrap Ansible and install Python on BSD variants (see below), it is very limited and the use of Python is required to make full use of Ansible's features." +msgstr "Ansible はデフォルトでエージェントレスですが、管理ノードで Python が必要になります。:ref:`raw <raw_module>` モジュールのみが Python なしで動作します。このモジュールを使用して Ansible をブートストラップして BSD バリアントに Python をインストールできます (下記参照) が、Python は非常に制限されており、Ansible の機能を完全に活用するには Python を使用する必要があります。" + +#: ../../rst/user_guide/intro_bsd.rst:29 +msgid "The following example installs Python which includes the json library required for full functionality of Ansible. On your control machine you can execute the following for most versions of FreeBSD:" +msgstr "次の例では、Ansible の完全な機能に必要な json ライブラリーを含む Python をインストールしています。コントロールマシンでは、ほとんどのバージョンの FreeBSD で次のように実行できます。" + +#: ../../rst/user_guide/intro_bsd.rst:36 +msgid "Or for OpenBSD:" +msgstr "OpenBSD の場合は、次のコマンドを使用します。" + +#: ../../rst/user_guide/intro_bsd.rst:42 +msgid "Once this is done you can now use other Ansible modules apart from the ``raw`` module." +msgstr "これが完了すると、``raw`` モジュール以外の他の Ansible モジュールを使用できるようになります。" + +#: ../../rst/user_guide/intro_bsd.rst:45 +msgid "This example demonstrated using pkg on FreeBSD and pkg_add on OpenBSD, however you should be able to substitute the appropriate package tool for your BSD; the package name may also differ. Refer to the package list or documentation of the BSD variant you are using for the exact Python package name you intend to install." +msgstr "この例では、FreeBSD では pkg を、OpenBSD では pkg_add を使用していますが、お使いの BSD に合わせて適切なパッケージツールを選択してください。また、パッケージ名も異なる場合があります。インストールする Python パッケージ名については、使用している BSD のパッケージリストやドキュメントを参照してください。" + +#: ../../rst/user_guide/intro_bsd.rst:50 +msgid "Setting the Python interpreter" +msgstr "Python インタープリターの設定" + +#: ../../rst/user_guide/intro_bsd.rst:52 +msgid "To support a variety of Unix-like operating systems and distributions, Ansible cannot always rely on the existing environment or ``env`` variables to locate the correct Python binary. By default, modules point at ``/usr/bin/python`` as this is the most common location. On BSD variants, this path may differ, so it is advised to inform Ansible of the binary's location. See :ref:`INTERPRETER_PYTHON`. For example, set ``ansible_python_interpreter`` inventory variable:" +msgstr "さまざまな Unix 系オペレーティングシステムやディストリビューションをサポートするために、Ansible は常に既存の環境変数や ``env`` 変数を頼りに正しい Python バイナリーを探すことはできません。デフォルトでは、モジュールは最も一般的な場所である ``/usr/bin/python`` を指します。BSD 系では、このパスが異なる場合があるので、バイナリーの場所を Ansible に知らせることが推奨されます。:ref:`INTERPRETER_PYTHON` を参照してください。たとえば、``ansible_python_interpreter`` インベントリー変数を設定します。" + +#: ../../rst/user_guide/intro_bsd.rst:63 +msgid "FreeBSD packages and ports" +msgstr "FreeBSD パッケージおよびポート" + +#: ../../rst/user_guide/intro_bsd.rst:65 +msgid "In FreeBSD, there is no guarantee that either ``/usr/local/bin/python`` executable file or a link to an executable file is installed by default. The best practice for a remote host, with respect to Ansible, is to install at least the Python version supported by Ansible, for example, ``lang/python38``, and both meta ports ``lang/python3`` and ``lang/python``. Quoting from */usr/ports/lang/python3/pkg-descr*:" +msgstr "FreeBSD では、``/usr/local/bin/python`` 実行可能ファイルまたは実行可能ファイルへのリンクのいずれかがデフォルトでインストールされる保証はありません。Ansible に関連してリモートホストのベストプラクティスは、少なくともAnsible がサポートする Python バージョン（例：``lang/python38`` および ``lang/python3`` と ``lang/python`` 両方のメタポート）をインストールすることです。*/usr/ports/lang/python3/pkg-descr* からの引用:" + +#: ../../rst/user_guide/intro_bsd.rst:73 +msgid "Quoting from */usr/ports/lang/python/pkg-descr*:" +msgstr "*/usr/ports/lang/python/pkg-descr* からの引用：" + +#: ../../rst/user_guide/intro_bsd.rst:81 +msgid "As a result, the following packages are installed:" +msgstr "これにより、以下のパッケージがインストールされます。" + +#: ../../rst/user_guide/intro_bsd.rst:90 +msgid "and the following executables and links" +msgstr "さらに、以下の実行ファイルとリンクがインストールされます。" + +#: ../../rst/user_guide/intro_bsd.rst:104 +msgid "INTERPRETER_PYTHON_FALLBACK" +msgstr "INTERPRETER_PYTHON_FALLBACK" + +#: ../../rst/user_guide/intro_bsd.rst:106 +msgid "Since version 2.8 Ansible provides a useful variable ``ansible_interpreter_python_fallback`` to specify a list of paths to search for Python. See :ref:`INTERPRETER_PYTHON_FALLBACK`. This list will be searched and the first item found will be used. For example, the configuration below would make the installation of the meta-ports in the previous section redundant, that is, if you don't install the Python meta ports the first two items in the list will be skipped and ``/usr/local/bin/python3.8`` will be discovered." +msgstr "バージョン 2.8 以降、Ansible には、Python を検索するパスの一覧を指定するための便利な変数 ``ansible_interpreter_python_fallback`` が用意されています。「:ref:`INTERPRETER_PYTHON_FALLBACK`」を参照してください。この一覧を検索し、見つかった最初の項目が使用されます。たとえば、以下の設定では、前のセクションのメタポートのインストールが冗長になります。つまり、Python メタポートをインストールしないと、リストの最初の 2 つの項目が省略され、``/usr/local/bin/python3.8`` が検出されます。" + +#: ../../rst/user_guide/intro_bsd.rst:113 +msgid "You can use this variable, prolonged by the lower versions of Python, and put it, for example, into the ``group_vars/all``. Then, override it for specific groups in ``group_vars/{group1, group2, ...}`` and for specific hosts in ``host_vars/{host1, host2, ...}`` if needed. See :ref:`ansible_variable_precedence`." +msgstr "Python の下位バージョンで延ばされているこの変数を使い、例えば``group_vars/all``に入れます。そして、必要に応じて``group_vars/{group1, group2, ...}``の特定グループに対して、また``host_vars/{host1, host2, ...}``の特定ホストに対して、オーバーライドします。:ref:`ansible_variable_precedence`を参照してください。" + +#: ../../rst/user_guide/intro_bsd.rst:117 +msgid "Debug the discovery of Python" +msgstr "Python の検出のデバッグ" + +#: ../../rst/user_guide/intro_bsd.rst:119 +msgid "For example, given the inventory" +msgstr "たとえば、以下のインベントリーを想定します。" + +#: ../../rst/user_guide/intro_bsd.rst:138 +msgid "The playbook below" +msgstr "以下のPlaybook により、" + +#: ../../rst/user_guide/intro_bsd.rst:159 +msgid "displays the details" +msgstr "詳細が表示されます。" + +#: ../../rst/user_guide/intro_bsd.rst:192 +msgid "You can see that the first item from the list ``ansible_interpreter_python_fallback`` was discovered at the FreeBSD remote host. The variable ``ansible_playbook_python`` keeps the path to Python at the Linux controller that ran the playbook." +msgstr "リストの最初のアイテム ``ansible_interpreter_python_fallback`` が FreeBSD リモートホストで検出されていることが分かります。変数 ``ansible_playbook_python`` は、Playbook を実行した Linux コントローラーで Python へのパスを保持します。" + +#: ../../rst/user_guide/intro_bsd.rst:194 +msgid "Regarding the warning, quoting from :ref:`INTERPRETER_PYTHON`" +msgstr "警告に関して、:ref:`INTERPRETER_PYTHON`からの引用" + +#: ../../rst/user_guide/intro_bsd.rst:203 +msgid "You can either ignore it or get rid of it by setting the variable ``ansible_python_interpreter=auto_silent`` because this is, actually, what you want by using ``/usr/local/bin/python`` (*\"interpreters installed later may change which one is used\"*). For example" +msgstr "変数 ``ansible_python_interpreter=auto_silent`` を設定することで、これを無視するか、または取り除くことができます。これは、実際に ``/usr/local/bin/python`` を使用して希望するものだからです（*「後でインストールされるインタープリターにより、使用されるものが変わる場合があります」*）。以下に例を示します。" + +#: ../../rst/user_guide/intro_bsd.rst:226 ../../rst/user_guide/modules.rst:31 +msgid ":ref:`interpreter_discovery`" +msgstr ":ref:`interpreter_discovery`" + +#: ../../rst/user_guide/intro_bsd.rst:227 +msgid "`FreeBSD Wiki: Ports/DEFAULT_VERSIONS <https://wiki.freebsd.org/Ports/DEFAULT_VERSIONS>`_" +msgstr "`FreeBSD Wiki: Ports/DEFAULT_VERSIONS <https://wiki.freebsd.org/Ports/DEFAULT_VERSIONS>`_" + +#: ../../rst/user_guide/intro_bsd.rst:231 +msgid "Additional variables" +msgstr "追加の変数" + +#: ../../rst/user_guide/intro_bsd.rst:233 +msgid "If you use additional plugins beyond those bundled with Ansible, you can set similar variables for ``bash``, ``perl`` or ``ruby``, depending on how the plugin is written. For example:" +msgstr "Ansible でバンドルされているプラグイン以外のプラグインを使用する場合は、プラグインの記述方法に応じて ``bash``、``perl``、または ``ruby`` に同様の変数を設定できます。" + +#: ../../rst/user_guide/intro_bsd.rst:243 +msgid "Which modules are available?" +msgstr "利用可能なモジュール" + +#: ../../rst/user_guide/intro_bsd.rst:245 +msgid "The majority of the core Ansible modules are written for a combination of Unix-like machines and other generic services, so most should function well on the BSDs with the obvious exception of those that are aimed at Linux-only technologies (such as LVG)." +msgstr "Ansible のコアモジュールの大半は、Unix 系マシンと他の汎用サービスを組み合わせて記述されているため、Linux に限定したテクノロジー (LVG など) を対象とするものを除き、その大半が BSD 上で正常に機能します。" + +#: ../../rst/user_guide/intro_bsd.rst:248 +msgid "Using BSD as the control node" +msgstr "コントロールノードとしての BSD の使用" + +#: ../../rst/user_guide/intro_bsd.rst:250 +msgid "Using BSD as the control machine is as simple as installing the Ansible package for your BSD variant or by following the ``pip`` or 'from source' instructions." +msgstr "BSD をコントロールマシンとして使用することは、BSD バリアントの Ansible パッケージをインストールするか、``pip`` または「from source」の指示に従うのと同じくらい簡単です。" + +#: ../../rst/user_guide/intro_bsd.rst:255 +msgid "BSD facts" +msgstr "BSD ファクト" + +#: ../../rst/user_guide/intro_bsd.rst:257 +msgid "Ansible gathers facts from the BSDs in a similar manner to Linux machines, but since the data, names and structures can vary for network, disks and other devices, one should expect the output to be slightly different yet still familiar to a BSD administrator." +msgstr "Ansible は、Linux マシンと同様の方法で BSD からファクトを収集しますが、データ、名前、構造は、ネットワーク、ディスク、およびその他のデバイスにより異なる可能性があるため、BSD 管理者にとっては出力が多少異なるもののまだ馴染みがあることが期待できます。" + +#: ../../rst/user_guide/intro_bsd.rst:262 +msgid "BSD efforts and contributions" +msgstr "BSD の取り組みおよび貢献" + +#: ../../rst/user_guide/intro_bsd.rst:264 +msgid "BSD support is important to us at Ansible. Even though the majority of our contributors use and target Linux we have an active BSD community and strive to be as BSD-friendly as possible. Please feel free to report any issues or incompatibilities you discover with BSD; pull requests with an included fix are also welcome!" +msgstr "BSD サポートは Ansible にとって重要です。貢献者の大半は Linux を使用していますが、Ansible には活発な BSD コミュニティーがあり、可能な限り BSD フレンドリーであるように努めています。BSD に関する問題や非互換性を発見した場合は、遠慮なくご報告ください。" + +#: ../../rst/user_guide/intro_bsd.rst:269 +#: ../../rst/user_guide/intro_inventory.rst:790 +#: ../../rst/user_guide/intro_patterns.rst:220 +#: ../../rst/user_guide/modules.rst:23 +#: ../../rst/user_guide/modules_intro.rst:51 +#: ../../rst/user_guide/modules_support.rst:63 +msgid ":ref:`intro_adhoc`" +msgstr ":ref:`intro_adhoc`" + +#: ../../rst/user_guide/intro_bsd.rst:270 +#: ../../rst/user_guide/intro_inventory.rst:791 +#: ../../rst/user_guide/intro_patterns.rst:221 +msgid "Examples of basic commands" +msgstr "基本コマンドの例" + +#: ../../rst/user_guide/intro_bsd.rst:272 +msgid "Learning ansible's configuration management language" +msgstr "Ansible の設定管理言語の概要" + +#: ../../rst/user_guide/intro_bsd.rst:273 +#: ../../rst/user_guide/modules_intro.rst:55 +#: ../../rst/user_guide/playbooks_best_practices.rst:174 +#: ../../rst/user_guide/playbooks_intro.rst:152 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:27 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:606 +#: ../../rst/user_guide/sample_setup.rst:290 +msgid ":ref:`developing_modules`" +msgstr ":ref:`developing_modules`" + +#: ../../rst/user_guide/intro_bsd.rst:274 +msgid "How to write modules" +msgstr "モジュールの書き方" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:6 +msgid "Working with dynamic inventory" +msgstr "動的インベントリーの使用" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:11 +msgid "If your Ansible inventory fluctuates over time, with hosts spinning up and shutting down in response to business demands, the static inventory solutions described in :ref:`inventory` will not serve your needs. You may need to track hosts from multiple sources: cloud providers, LDAP, `Cobbler <https://cobbler.github.io>`_, and/or enterprise CMDB systems." +msgstr "Ansible のインベントリーが、ビジネス上の要求に応じてホストの回転や停止など、時間とともに変動する場合は、「:ref:`inventory`」で説明している静的なインベントリーソリューションではニーズに応えられません。クラウドプロバイダー、LDAP、`Cobbler <https://cobbler.github.io>`_、エンタープライズ CMDB システムなど、複数のソースからのホストの追跡が必要になる場合があります。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:13 +msgid "Ansible integrates all of these options through a dynamic external inventory system. Ansible supports two ways to connect with external inventory: :ref:`inventory_plugins` and `inventory scripts`." +msgstr "Ansible は、動的な外部インベントリーシステムを通じて、これらのオプションをすべて統合します。Ansible は、外部インベントリーに接続する 2 つの方法 (:ref:`inventory_plugins` および `inventory scripts`) をサポートしています。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:15 +msgid "Inventory plugins take advantage of the most recent updates to the Ansible core code. We recommend plugins over scripts for dynamic inventory. You can :ref:`write your own plugin <developing_inventory>` to connect to additional dynamic inventory sources." +msgstr "インベントリープラグインは、Ansible コアコードの最新の更新を利用しています。動的インベントリーには、スクリプトよりもプラグインが推奨されます。:ref:`独自のプラグインを記述 <developing_inventory>` して、追加の動的インベントリーソースに接続することができます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:17 +msgid "You can still use inventory scripts if you choose. When we implemented inventory plugins, we ensured backwards compatibility through the script inventory plugin. The examples below illustrate how to use inventory scripts." +msgstr "また、インベントリースクリプトを使用することもできます。インベントリープラグインを実装する際に、スクリプトインベントリープラグインによる後方互換性を確保しました。以下の例では、インベントリースクリプトの使用方法を説明しています。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:19 +msgid "If you prefer a GUI for handling dynamic inventory, the inventory database on AWX or :ref:`ansible_platform` syncs with all your dynamic inventory sources, provides web and REST access to the results, and offers a graphical inventory editor. With a database record of all of your hosts, you can correlate past event history and see which hosts have had failures on their last playbook runs." +msgstr "動的インベントリーを GUI で操作したい場合は、AWX または :ref:`ansible_platform` のインベントリーデータベースがすべての動的インベントリーソースと同期し、その結果に Web および REST アクセスを提供し、グラフィカルインベントリーエディターを提供します。すべてのホストのデータベースレコードを使用して、過去のイベント履歴を関連付け、最後の Playbook の実行でどのホストに障害が発生したかを確認できます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:24 +msgid "Inventory script example: Cobbler" +msgstr "インベントリースクリプトの例: Cobbler" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:26 +msgid "Ansible integrates seamlessly with `Cobbler <https://cobbler.github.io>`_, a Linux installation server originally written by Michael DeHaan and now led by James Cammarata, who works for Ansible." +msgstr "Ansible は、Linux インストールサーバー `Cobbler <https://cobbler.github.io>`_ (最初に Michael DeHaan 氏が作成し、現在は Ansible に所属する James Cammarata が率いています) とシームレスに統合されます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:28 +msgid "While primarily used to kickoff OS installations and manage DHCP and DNS, Cobbler has a generic layer that can represent data for multiple configuration management systems (even at the same time) and serve as a 'lightweight CMDB'." +msgstr "Cobbler は主に OS のインストールを開始し、DHCP と DNS を管理するために使用されますが、複数の構成管理システムのデータを (同時にでも) 表現し、「軽量CMDB」として機能する汎用レイヤーがあります。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:31 +msgid "To tie your Ansible inventory to Cobbler, copy `this script <https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/cobbler.py>`_ to ``/etc/ansible`` and ``chmod +x`` the file. Run ``cobblerd`` any time you use Ansible and use the ``-i`` command line option (for example, ``-i /etc/ansible/cobbler.py``) to communicate with Cobbler using Cobbler's XMLRPC API." +msgstr "Ansible インベントリーを Cobbler に関連付けるには、`このスクリプト <https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/cobbler.py>`_ を ``/etc/ansible`` にコピーして、コピーしたファイルに ``chmod +x`` を付与します。Ansible を使用して ``cobblerd`` を実行し、``-i`` コマンドラインオプション (例: ``-i /etc/ansible/cobbler.py``) を付けて、Cobbler の XMLRPC API 使用して Cobbler と通信します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:33 +msgid "Add a ``cobbler.ini`` file in ``/etc/ansible`` so Ansible knows where the Cobbler server is and some cache improvements can be used. For example:" +msgstr "Ansible が Cobbler サーバーの場所とキャッシュの改良に使用できるものを認識できるように、``/etc/ansible`` に ``cobbler.ini`` ファイルを追加します。以下に例を示します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:56 +msgid "First test the script by running ``/etc/ansible/cobbler.py`` directly. You should see some JSON data output, but it may not have anything in it just yet." +msgstr "まず ``/etc/ansible/cobbler.py`` を直接実行してスクリプトをテストします。JSON データ出力が表示されますが、まだ何も含まれていない場合もあります。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:58 +msgid "Let's explore what this does. In Cobbler, assume a scenario somewhat like the following:" +msgstr "これで何ができるのか見てみましょう。Cobbler で、次のようなシナリオを想定します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:67 +msgid "In the example above, the system 'foo.example.com' is addressable by ansible directly, but is also addressable when using the group names 'webserver' or 'atlanta'. Since Ansible uses SSH, it contacts system foo over 'foo.example.com', only, never just 'foo'. Similarly, if you tried \"ansible foo\", it would not find the system... but \"ansible 'foo*'\" would do, because the system DNS name starts with 'foo'." +msgstr "上の例では、システム「foo.example.com」は、ansible が直接アドレスを指定できるだけでなく、グループ名「webserver」や「atlanta」を使用してもアドレスを指定できます。Ansible は SSH を使用しているため、「foo.example.com」を経由してシステム foo に接続しますが、決して「foo」だけではありません。同様に、「ansible foo」と入力しても、システムを見つけることはできませんが、「ansible 'foo'*」と入力すると、システムの DNS 名が 'foo' で始まるため、システムを見つけることができます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:69 +msgid "The script provides more than host and group info. In addition, as a bonus, when the 'setup' module is run (which happens automatically when using playbooks), the variables 'a', 'b', and 'c' will all be auto-populated in the templates:" +msgstr "このスクリプトは、ホストとグループの情報以外にもさまざまな情報を提供します。さらに、(Playbook を使用する際に自動的に実行される)「setup」モジュールを実行すると、変数「a」、「b」、および「c」はすべてテンプレートに自動入力されるようになります。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:76 +msgid "Which could be executed just like this:" +msgstr "これは以下のように実行できます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:84 +msgid "The name 'webserver' came from Cobbler, as did the variables for the config file. You can still pass in your own variables like normal in Ansible, but variables from the external inventory script will override any that have the same name." +msgstr "「webserver」という名前は、設定ファイルの変数と同様に、Cobbler から来ています。Ansible では通常のように独自の変数を渡すことができますが、外部のインベントリースクリプトからの変数は、同じ名前のものを上書きします。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:89 +msgid "So, with the template above (``motd.j2``), this results in the following data being written to ``/etc/motd`` for system 'foo':" +msgstr "そのため、上記のテンプレート (``motd.j2``) を使用すると、以下のデータがシステム「foo」用に ``/etc/motd`` に書き込まれます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:95 +msgid "And on system 'bar' (bar.example.com):" +msgstr "システム「bar」(bar.example.com) は、以下のようになります。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:101 +msgid "And technically, though there is no major good reason to do it, this also works:" +msgstr "技術的には、これを行う大きな正当な理由はありませんが、これも機能します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:107 +msgid "So, in other words, you can use those variables in arguments/actions as well." +msgstr "つまり、引数やアクションでこの変数を使用することもできます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:112 +msgid "Inventory script example: OpenStack" +msgstr "インベントリースクリプトの例: OpenStack" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:114 +msgid "If you use an OpenStack-based cloud, instead of manually maintaining your own inventory file, you can use the ``openstack_inventory.py`` dynamic inventory to pull information about your compute instances directly from OpenStack." +msgstr "独自のインベントリーファイルを手動で管理する代わりに、OpenStack ベースのクラウドを使用する場合は、動的インベントリー ``openstack_inventory.py`` を使用して、OpenStack から直接 Compute インスタンスに関する情報を取得できます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:116 +msgid "You can download the latest version of the OpenStack inventory script `here <https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py>`_." +msgstr "最新バージョンの OpenStack インベントリースクリプトは、`こちら <https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py>`_ からダウンロードできます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:118 +msgid "You can use the inventory script explicitly (by passing the `-i openstack_inventory.py` argument to Ansible) or implicitly (by placing the script at `/etc/ansible/hosts`)." +msgstr "(`-i openstack_inventory.py` 引数を Ansible に渡すことで) インベントリースクリプトを明示的に使用するか、(スクリプトを `/etc/ansible/hosts` において) 暗黙的に使用できます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:121 +msgid "Explicit use of OpenStack inventory script" +msgstr "OpenStack インベントリースクリプトの明示的な使用" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:123 +msgid "Download the latest version of the OpenStack dynamic inventory script and make it executable." +msgstr "最新バージョンの OpenStack の動的インベントリースクリプトをダウンロードし、実行可能にします。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:131 +msgid "Do not name it `openstack.py`. This name will conflict with imports from openstacksdk." +msgstr "`openstack.py` という名前はつけないでください。この名前は、openstacksdk からのインポートと競合します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:133 +msgid "Source an OpenStack RC file:" +msgstr "OpenStack RC ファイルを読み込みます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:141 +msgid "An OpenStack RC file contains the environment variables required by the client tools to establish a connection with the cloud provider, such as the authentication URL, user name, password and region name. For more information on how to download, create or source an OpenStack RC file, please refer to `Set environment variables using the OpenStack RC file <https://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html>`_." +msgstr "OpenStack RC ファイルには、認証 URL、ユーザー名、パスワード、リージョン名など、クラウドプロバイダーとの接続を確立するためにクライアントツールで必要な環境変数が含まれています。OpenStack RC ファイルのダウンロード、作成、またはソースに関する詳細は、「`Set environment variables using the OpenStack RC file <https://docs.openstack.org/user-guide/common/cli_set_environment_variables_using_openstack_rc.html>`_」を参照してください。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:143 +msgid "You can confirm the file has been successfully sourced by running a simple command, such as `nova list` and ensuring it returns no errors." +msgstr "`nova list` などの単純なコマンドを実行してエラーを返さないようにすることで、ファイルが正常に読み込まれたことを確認できます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:147 +msgid "The OpenStack command line clients are required to run the `nova list` command. For more information on how to install them, please refer to `Install the OpenStack command-line clients <https://docs.openstack.org/user-guide/common/cli_install_openstack_command_line_clients.html>`_." +msgstr "`nova list` コマンドを実行するには、OpenStack コマンドラインクライアントが必要です。インストール方法の詳細は、「`Install the OpenStack command-line clients <https://docs.openstack.org/user-guide/common/cli_install_openstack_command_line_clients.html>`_」を参照してください。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:149 +#: ../../rst/user_guide/intro_dynamic_inventory.rst:182 +msgid "You can test the OpenStack dynamic inventory script manually to confirm it is working as expected:" +msgstr "OpenStack 動的インベントリースクリプトを手動でテストして、想定どおりに機能していることを確認します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:155 +#: ../../rst/user_guide/intro_dynamic_inventory.rst:188 +msgid "After a few moments you should see some JSON output with information about your compute instances." +msgstr "しばらくすると、Compute インスタンスに関する情報が含まれる JSON 出力が表示されます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:157 +msgid "Once you confirm the dynamic inventory script is working as expected, you can tell Ansible to use the `openstack_inventory.py` script as an inventory file, as illustrated below:" +msgstr "動的インベントリースクリプトが想定どおりに機能していることを確認したら、以下のように Ansible が `openstack_inventory.py` スクリプトをインベントリーファイルとして使用するように指定します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:164 +msgid "Implicit use of OpenStack inventory script" +msgstr "OpenStack インベントリースクリプトの暗黙的な使用" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:166 +msgid "Download the latest version of the OpenStack dynamic inventory script, make it executable and copy it to `/etc/ansible/hosts`:" +msgstr "最新バージョンの OpenStack 動的インベントリースクリプトをダウンロードし、実行可能にし、これを `/etc/ansible/hosts` にコピーします。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:174 +msgid "Download the sample configuration file, modify it to suit your needs and copy it to `/etc/ansible/openstack.yml`:" +msgstr "サンプル設定ファイルをダウンロードし、必要に応じて変更し、これを `/etc/ansible/openstack.yml` にコピーします。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:191 +msgid "Refreshing the cache" +msgstr "キャッシュの更新" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:193 +msgid "Note that the OpenStack dynamic inventory script will cache results to avoid repeated API calls. To explicitly clear the cache, you can run the openstack_inventory.py (or hosts) script with the ``--refresh`` parameter:" +msgstr "OpenStack 動的インベントリースクリプトは、API 呼び出しが繰り返し行われるのを防ぐために、結果をキャッシュすることに注意してください。キャッシュを明示的に消去するには、``--refresh`` パラメーターを使用して openstack_inventory.py (または hosts) スクリプトを実行します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:202 +msgid "Other inventory scripts" +msgstr "その他のインベントリースクリプト" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:204 +msgid "In Ansible 2.10 and later, inventory scripts moved to their associated collections. Many are now in the `community.general scripts/inventory directory <https://github.com/ansible-collections/community.general/tree/main/scripts/inventory>`_. We recommend you use :ref:`inventory_plugins` instead." +msgstr "Ansible 2.10 以降では、インベントリースクリプトは関連するコレクションに移動しました。現在、多くのスクリプトは `community.general scripts/inventory directory <https://github.com/ansible-collections/community.general/tree/main/scripts/inventory>`_ にあります。代わりに :ref:`inventory_plugins` を使用することが推奨されます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:209 +msgid "Using inventory directories and multiple inventory sources" +msgstr "インベントリーディレクトリーおよび複数のインベントリーソースの使用" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:211 +msgid "If the location given to ``-i`` in Ansible is a directory (or as so configured in ``ansible.cfg``), Ansible can use multiple inventory sources at the same time. When doing so, it is possible to mix both dynamic and statically managed inventory sources in the same ansible run. Instant hybrid cloud!" +msgstr "Ansible で ``-i`` に指定される場所がディレクトリーの場合 (または ``ansible.cfg`` でそのように設定されている場合)、Ansible は複数のインベントリーソースを同時に使用できます。これを実行する場合は、同じ Ansible 実行で動的および静的に管理されているインベントリーソースを混在させることができます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:215 +msgid "In an inventory directory, executable files are treated as dynamic inventory sources and most other files as static sources. Files which end with any of the following are ignored:" +msgstr "インベントリーディレクトリでは、実行ファイルは動的インベントリーソースとして、その他のほとんどのファイルは静的ソースとして扱われます。以下のいずれかで終わるファイルは無視されます。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:221 +msgid "You can replace this list with your own selection by configuring an ``inventory_ignore_extensions`` list in ``ansible.cfg``, or setting the :envvar:`ANSIBLE_INVENTORY_IGNORE` environment variable. The value in either case must be a comma-separated list of patterns, as shown above." +msgstr "この一覧は、``ansible.cfg`` で ``inventory_ignore_extensions`` 一覧を設定するか、:envvar:`ANSIBLE_INVENTORY_IGNORE` 環境変数を設定して独自の選択に置き換えることができます。いずれの値も、上記のようにパターンのコンマ区切りの一覧である必要があります。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:223 +msgid "Any ``group_vars`` and ``host_vars`` subdirectories in an inventory directory are interpreted as expected, making inventory directories a powerful way to organize different sets of configurations. See :ref:`using_multiple_inventory_sources` for more information." +msgstr "インベントリーディレクトリーの ``group_vars`` サブディレクトリーおよび ``host_vars`` サブディレクトリーは想定どおりに解釈されるため、インベントリーディレクトリーはさまざまな構成セットを整理するための強力な方法になります。詳細は、「:ref:`using_multiple_inventory_sources`」を参照してください。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:228 +msgid "Static groups of dynamic groups" +msgstr "動的グループの静的グループ" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:230 +msgid "When defining groups of groups in the static inventory file, the child groups must also be defined in the static inventory file, otherwise ansible returns an error. If you want to define a static group of dynamic child groups, define the dynamic groups as empty in the static inventory file. For example:" +msgstr "静的インベントリーファイルでグループのグループを定義する場合は、子グループも静的インベントリーファイルで定義されていなければ、Ansible はエラーを返します。動的な子グループの静的グループを定義する場合は、静的インベントリーファイルで動的グループを空に定義してください。以下に例を示します。" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:248 +msgid ":ref:`intro_inventory`" +msgstr ":ref:`intro_inventory`" + +#: ../../rst/user_guide/intro_dynamic_inventory.rst:249 +msgid "All about static inventory files" +msgstr "静的インベントリーファイルの詳細" + +#: ../../rst/user_guide/intro_inventory.rst:6 +msgid "How to build your inventory" +msgstr "インベントリーの構築方法" + +#: ../../rst/user_guide/intro_inventory.rst:8 +msgid "Ansible works against multiple managed nodes or \"hosts\" in your infrastructure at the same time, using a list or group of lists known as inventory. Once your inventory is defined, you use :ref:`patterns <intro_patterns>` to select the hosts or groups you want Ansible to run against." +msgstr "Ansible は、インベントリーと呼ばれるリスト、またはリストのグループを使用して、インフラストラクチャーにある複数の管理ノードまたは「ホスト」に対して同時に機能します。インベントリーが定義されたら、:ref:`パターン <intro_patterns>` を使用して Ansible で実行するホストまたはグループを選択します。" + +#: ../../rst/user_guide/intro_inventory.rst:10 +msgid "The default location for inventory is a file called ``/etc/ansible/hosts``. You can specify a different inventory file at the command line using the ``-i <path>`` option. You can also use multiple inventory files at the same time as described in :ref:`using_multiple_inventory_sources`, and/or pull inventory from dynamic or cloud sources or different formats (YAML, ini, and so on), as described in :ref:`intro_dynamic_inventory`. Introduced in version 2.4, Ansible has :ref:`inventory_plugins` to make this flexible and customizable." +msgstr "インベントリーのデフォルトの場所は、``/etc/ansible/hosts`` と呼ばれるファイルです。``-i <path>`` オプションを使用して、コマンドラインで別のインベントリーファイルを指定できます。「:ref:`intro_dynamic_inventory`」で説明されているように、:ref:`using_multiple_inventory_sources` で説明されている複数のインベントリーファイルを同時に使用したり、動的またはクラウドソースまたは異なる形式 (YAML、ini など) からインベントリーをプルしたりすることもできます。バージョン 2.4 で導入された Ansible には、この柔軟でカスタマイズ可能な :ref:`inventory_plugins` があります。" + +#: ../../rst/user_guide/intro_inventory.rst:19 +msgid "Inventory basics: formats, hosts, and groups" +msgstr "インベントリーの基本: 形式、ホスト、およびグループ" + +#: ../../rst/user_guide/intro_inventory.rst:21 +msgid "The inventory file can be in one of many formats, depending on the inventory plugins you have. The most common formats are INI and YAML. A basic INI ``/etc/ansible/hosts`` might look like this:" +msgstr "インベントリーファイルは、所有するインベントリープラグインに応じて、多くの形式のいずれかになります。最も一般的な形式は INI および YAML です。基本的な INI ``/etc/ansible/hosts`` は以下のようになります。" + +#: ../../rst/user_guide/intro_inventory.rst:37 +msgid "The headings in brackets are group names, which are used in classifying hosts and deciding what hosts you are controlling at what times and for what purpose. Group names should follow the same guidelines as :ref:`valid_variable_names`." +msgstr "括弧内の見出しはグループ名で、ホストを分類し、どの時点で、どのような目的で、どのホストを制御するかを決定するのに使用されます。グループ名は、:ref:`valid_variable_names` と同じガイドラインに従ってください。" + +#: ../../rst/user_guide/intro_inventory.rst:41 +msgid "Here's that same basic inventory file in YAML format:" +msgstr "以下は、同じ基本的なインベントリーファイルの YAML 形式です。" + +#: ../../rst/user_guide/intro_inventory.rst:62 +msgid "Default groups" +msgstr "デフォルトのグループ" + +#: ../../rst/user_guide/intro_inventory.rst:64 +msgid "There are two default groups: ``all`` and ``ungrouped``. The ``all`` group contains every host. The ``ungrouped`` group contains all hosts that don't have another group aside from ``all``. Every host will always belong to at least 2 groups (``all`` and ``ungrouped`` or ``all`` and some other group). Though ``all`` and ``ungrouped`` are always present, they can be implicit and not appear in group listings like ``group_names``." +msgstr "デフォルトグループが 2 つ (``all`` および ``ungrouped``) あります。``all`` グループには、すべてのホストが含まれています。``ungrouped`` グループは、``all`` 以外のグループを持たないすべてのホストを含みます。すべてのホストは、常に少なくとも 2 つのグループ (``all`` と ``ungrouped``、または ``all`` と他のグループ) に属しています。``all`` と ``ungrouped`` は常に存在していますが、``group_names`` のようにグループ一覧に表示されない暗黙的なものもあります。" + +#: ../../rst/user_guide/intro_inventory.rst:71 +msgid "Hosts in multiple groups" +msgstr "複数グループ内のホスト" + +#: ../../rst/user_guide/intro_inventory.rst:73 +msgid "You can (and probably will) put each host in more than one group. For example a production webserver in a datacenter in Atlanta might be included in groups called [prod] and [atlanta] and [webservers]. You can create groups that track:" +msgstr "各ホストを複数のグループに配置できます。たとえば、Atlanta のデータセンターの実稼働 Web サーバーは、[prod]、[atlanta]、および [webservers] と呼ばれるグループに追加できます。以下を追跡するグループを作成できます。" + +#: ../../rst/user_guide/intro_inventory.rst:75 +msgid "What - An application, stack or microservice (for example, database servers, web servers, and so on)." +msgstr "なにを - アプリケーション、スタック、またはマイクロサービス (たとえば、データベースサーバー、Web サーバーなど)。" + +#: ../../rst/user_guide/intro_inventory.rst:76 +msgid "Where - A datacenter or region, to talk to local DNS, storage, and so on (for example, east, west)." +msgstr "どこで - データセンターまたはリージョンで、ローカルの DNS やストレージなどと通信します (例: east、west)。" + +#: ../../rst/user_guide/intro_inventory.rst:77 +msgid "When - The development stage, to avoid testing on production resources (for example, prod, test)." +msgstr "いつ - 開発段階で、実稼働リソースでのテストを回避するため (例: prod、test)。" + +#: ../../rst/user_guide/intro_inventory.rst:79 +msgid "Extending the previous YAML inventory to include what, when, and where would look like:" +msgstr "以前の YAML インベントリーを拡張して、上述の「いつ、どこで、なにを」が含まれるようにします。" + +#: ../../rst/user_guide/intro_inventory.rst:115 +msgid "You can see that ``one.example.com`` exists in the ``dbservers``, ``east``, and ``prod`` groups." +msgstr "``one.example.com`` が ``dbservers``、``east``、および ``prod`` グループに存在することを確認できます。" + +#: ../../rst/user_guide/intro_inventory.rst:117 +msgid "You can also use nested groups to simplify ``prod`` and ``test`` in this inventory, for the same result:" +msgstr "また、入れ子になったグループを使用して、このインベントリーで ``prod`` と ``test`` を簡素化しても、同じ結果になります。" + +#: ../../rst/user_guide/intro_inventory.rst:150 +msgid "You can find more examples on how to organize your inventories and group your hosts in :ref:`inventory_setup_examples`." +msgstr "インベントリーを整理し、ホストをグループ化する方法は、「:ref:`inventory_setup_examples`」を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:153 +msgid "Adding ranges of hosts" +msgstr "ホスト範囲の追加" + +#: ../../rst/user_guide/intro_inventory.rst:155 +msgid "If you have a lot of hosts with a similar pattern, you can add them as a range rather than listing each hostname separately:" +msgstr "同様のパターンを持つホストが多数ある場合は、各ホスト名を個別に表示するのではなく、ホストを範囲として追加できます。" + +#: ../../rst/user_guide/intro_inventory.rst:157 +#: ../../rst/user_guide/intro_inventory.rst:175 +#: ../../rst/user_guide/intro_inventory.rst:258 +#: ../../rst/user_guide/intro_inventory.rst:330 +msgid "In INI:" +msgstr "INI の場合は、以下のようになります。" + +#: ../../rst/user_guide/intro_inventory.rst:164 +#: ../../rst/user_guide/intro_inventory.rst:182 +#: ../../rst/user_guide/intro_inventory.rst:220 +#: ../../rst/user_guide/intro_inventory.rst:264 +#: ../../rst/user_guide/intro_inventory.rst:308 +#: ../../rst/user_guide/intro_inventory.rst:358 +msgid "In YAML:" +msgstr "YAML の場合は、以下のようになります。" + +#: ../../rst/user_guide/intro_inventory.rst:173 +msgid "You can specify a stride (increments between sequence numbers) when defining a numeric range of hosts:" +msgstr "ホストの数値範囲を定義する際に、stride (シーケンス番号間の増分) を指定することができます。" + +#: ../../rst/user_guide/intro_inventory.rst:191 +msgid "The example above would make the subdomains www01, www03, www05, ..., www49 match, but not www00, www02, www50 and so on, because the stride (increment) is 2 units each step." +msgstr "上記の例では、stride (増分) はステップごとに 2 ユニットであるため、サブドメイン www01、www03、www05、..、www49 は一致しますが、www00、www02、www50 などは一致しません。" + +#: ../../rst/user_guide/intro_inventory.rst:193 +msgid "For numeric patterns, leading zeros can be included or removed, as desired. Ranges are inclusive. You can also define alphabetic ranges:" +msgstr "数値のパターンでは、必要に応じて先頭にゼロを含めるか、または削除できます。範囲は包含的範囲も定義できます。また、アルファベットの範囲も定義できます。" + +#: ../../rst/user_guide/intro_inventory.rst:203 +msgid "Adding variables to inventory" +msgstr "インベントリーへの変数の追加" + +#: ../../rst/user_guide/intro_inventory.rst:205 +msgid "You can store variable values that relate to a specific host or group in inventory. To start with, you may add variables directly to the hosts and groups in your main inventory file. As you add more and more managed nodes to your Ansible inventory, however, you will likely want to store variables in separate host and group variable files. See :ref:`define_variables_in_inventory` for details." +msgstr "インベントリー内の特定のホストやグループに関連する変数値を保存することができます。最初のうちは、メインのインベントリーファイルのホストやグループに直接変数を追加することができます。しかし、Ansible インベントリーに管理ノードをどんどん追加していくと、変数をホストやグループの変数ファイルに分けて保存したくなることがあります。詳細は「:ref:`define_variables_in_inventory`」を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:210 +msgid "Assigning a variable to one machine: host variables" +msgstr "あるマシンへの変数の割り当て: ホスト変数" + +#: ../../rst/user_guide/intro_inventory.rst:212 +msgid "You can easily assign a variable to a single host, then use it later in playbooks. In INI:" +msgstr "1 台のホストに変数を簡単に割り当てると、後で Playbook で使用できます。INI では、以下のようになります。" + +#: ../../rst/user_guide/intro_inventory.rst:233 +msgid "Unique values like non-standard SSH ports work well as host variables. You can add them to your Ansible inventory by adding the port number after the hostname with a colon:" +msgstr "非標準の SSH ポートのような一意な値は、ホスト変数としてうまく機能します。ホスト名の後にコロンを付けてポート番号を追加することで、Ansible インベントリーに追加することができます。" + +#: ../../rst/user_guide/intro_inventory.rst:239 +msgid "Connection variables also work well as host variables:" +msgstr "接続変数もホスト変数として機能します。" + +#: ../../rst/user_guide/intro_inventory.rst:249 +msgid "If you list non-standard SSH ports in your SSH config file, the ``openssh`` connection will find and use them, but the ``paramiko`` connection will not." +msgstr "SSH 設定ファイル内に非標準の SSH ポートの一覧を表示した場合、``openssh`` 接続はそのポートを見つけて使用しますが、``paramiko`` 接続は行われません。" + +#: ../../rst/user_guide/intro_inventory.rst:254 +msgid "Inventory aliases" +msgstr "インベントリーエイリアス" + +#: ../../rst/user_guide/intro_inventory.rst:256 +msgid "You can also define aliases in your inventory:" +msgstr "エイリアスをインベントリーに定義することもできます。" + +#: ../../rst/user_guide/intro_inventory.rst:274 +msgid "In the above example, running Ansible against the host alias \"jumper\" will connect to 192.0.2.50 on port 5555. See :ref:`behavioral inventory parameters <behavioral_parameters>` to further customize the connection to hosts." +msgstr "上記の例では、ホストの別名「jumper」に対して Ansible を実行すると、ポート 5555 の 192.0.2.50 に接続されます。ホストへの接続をさらにカスタマイズするには、「:ref:`動作用のインベントリーパラメーター <behavioral_parameters>`」を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:277 +msgid "Values passed in the INI format using the ``key=value`` syntax are interpreted differently depending on where they are declared:" +msgstr "``key=value`` 構文を使用して INI 形式で渡される値が解釈される方法は、宣言される場所に応じて異なります。" + +#: ../../rst/user_guide/intro_inventory.rst:279 +msgid "When declared inline with the host, INI values are interpreted as Python literal structures (strings, numbers, tuples, lists, dicts, booleans, None). Host lines accept multiple ``key=value`` parameters per line. Therefore they need a way to indicate that a space is part of a value rather than a separator. Values that contain whitespace can be quoted (single or double). See the `Python shlex parsing rules`_ for details." +msgstr "ホストのインラインで宣言すると、INI 値は Pythonの リテラル構造 (文字列、数値、タプル、リスト、ディクショナリー、ブール値、なし) として解釈されます。ホストの行は、1 行につき複数の ``key=value`` パラメーターを受け付けます。そのため、スペースが区切り文字ではなく値の一部であることを示す方法が必要です。スペースが含まれる値を引用符(一重または二重)で囲むことができます。詳細は、 `Python shlex 解析ルール`_を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:281 +msgid "When declared in a ``:vars`` section, INI values are interpreted as strings. For example ``var=FALSE`` would create a string equal to 'FALSE'. Unlike host lines, ``:vars`` sections accept only a single entry per line, so everything after the ``=`` must be the value for the entry." +msgstr "``:vars`` セクションで宣言すると、INI の値は文字列として解釈されます。たとえば、``var=FALSE`` は FALSE と等しい文字列を作成します。ホスト行とは異なり、``:vars`` セクションは行ごとに 1 つのエントリーのみを許可するため、``=`` の後に続くすべてのものがエントリーの値である必要があります。" + +#: ../../rst/user_guide/intro_inventory.rst:283 +msgid "If a variable value set in an INI inventory must be a certain type (for example, a string or a boolean value), always specify the type with a filter in your task. Do not rely on types set in INI inventories when consuming variables." +msgstr "INI インベントリーに設定されている変数の値が特定の型 (文字列やブール値など) でなければならない場合は、必ずタスクのフィルターで型を指定してください。変数を使用する際に、INI インベントリーに設定されている型に頼らないでください。" + +#: ../../rst/user_guide/intro_inventory.rst:285 +msgid "Consider using YAML format for inventory sources to avoid confusion on the actual type of a variable. The YAML inventory plugin processes variable values consistently and correctly." +msgstr "変数の実際のタイプに関する混乱を回避するために、インベントリーソースに YAML 形式を使用することを検討してください。YAML インベントリープラグインは変数の値を一貫して、正しく処理します。" + +#: ../../rst/user_guide/intro_inventory.rst:287 +msgid "Generally speaking, this is not the best way to define variables that describe your system policy. Setting variables in the main inventory file is only a shorthand. See :ref:`splitting_out_vars` for guidelines on storing variable values in individual files in the 'host_vars' directory." +msgstr "一般的には、システムポリシーを記述する変数を定義するのに、この方法は最適ではありません。メインのインベントリーファイルに変数を設定することは、単なる省略にすぎません。変数の値を「host_vars」ディレクトリー内の個々のファイルに保存する際のガイドラインについては、「:ref:`splitting_out_vars`」を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:294 +msgid "Assigning a variable to many machines: group variables" +msgstr "多くのマシンへの変数の割り当て: グループ変数" + +#: ../../rst/user_guide/intro_inventory.rst:296 +msgid "If all hosts in a group share a variable value, you can apply that variable to an entire group at once. In INI:" +msgstr "グループ内のすべてのホストが変数の値を共有している場合は、その変数をグループ全体に一度に適用することができます。INI の場合は以下のようになります。" + +#: ../../rst/user_guide/intro_inventory.rst:320 +msgid "Group variables are a convenient way to apply variables to multiple hosts at once. Before executing, however, Ansible always flattens variables, including inventory variables, to the host level. If a host is a member of multiple groups, Ansible reads variable values from all of those groups. If you assign different values to the same variable in different groups, Ansible chooses which value to use based on internal :ref:`rules for merging <how_we_merge>`." +msgstr "グループ変数は、複数のホストに一度に変数を適用する便利な方法です。しかし、Ansible は実行前に、インベントリー変数を含む変数を常にホストレベルにフラット化します。ホストが複数のグループに属している場合、Ansible はそれらのグループのすべてから変数の値を読み取ります。異なるグループで同じ変数に異なる値を割り当てた場合、Ansible は内部 :ref:`マージのルール <how_we_merge>` に基づいてどの値を使用するかを選択します。" + +#: ../../rst/user_guide/intro_inventory.rst:325 +msgid "Inheriting variable values: group variables for groups of groups" +msgstr "変数値の継承: グループのグループ用グループ変数" + +#: ../../rst/user_guide/intro_inventory.rst:327 +msgid "You can make groups of groups using the ``:children`` suffix in INI or the ``children:`` entry in YAML. You can apply variables to these groups of groups using ``:vars`` or ``vars:``:" +msgstr "INI の ``:children`` サフィックスまたは YAML の ``children:`` エントリーを使用して、グループのグループを作成できます。``:vars`` または ``vars:`` を使用して、変数をそれらのグループのグループに適用できます。" + +#: ../../rst/user_guide/intro_inventory.rst:385 +msgid "If you need to store lists or hash data, or prefer to keep host and group specific variables separate from the inventory file, see :ref:`splitting_out_vars`." +msgstr "リストまたはハッシュデータを保存する必要がある場合や、インベントリーファイルとは別にホストおよびグループ固有の変数を保持する必要がある場合は、「:ref:`splitting_out_vars`」を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:387 +msgid "Child groups have a couple of properties to note:" +msgstr "子グループには、注意すべき以下のプロパティーがあります。" + +#: ../../rst/user_guide/intro_inventory.rst:389 +msgid "Any host that is member of a child group is automatically a member of the parent group." +msgstr "子グループのメンバーであるホストは、自動的に親グループのメンバーになります。" + +#: ../../rst/user_guide/intro_inventory.rst:390 +msgid "A child group's variables will have higher precedence (override) a parent group's variables." +msgstr "子グループの変数は、親グループの変数よりも優先度が高くなります (オーバライド)。" + +#: ../../rst/user_guide/intro_inventory.rst:391 +msgid "Groups can have multiple parents and children, but not circular relationships." +msgstr "グループに複数の親と子を追加することはできますが、循環関係は設定できません。" + +#: ../../rst/user_guide/intro_inventory.rst:392 +msgid "Hosts can also be in multiple groups, but there will only be **one** instance of a host, merging the data from the multiple groups." +msgstr "ホストは複数のグループに属することもできますが、ホストのインスタンスは **1 つ** だけであり、複数のグループからのデータをマージします。" + +#: ../../rst/user_guide/intro_inventory.rst:397 +msgid "Organizing host and group variables" +msgstr "ホスト変数とグループ変数の整理" + +#: ../../rst/user_guide/intro_inventory.rst:399 +msgid "Although you can store variables in the main inventory file, storing separate host and group variables files may help you organize your variable values more easily. Host and group variable files must use YAML syntax. Valid file extensions include '.yml', '.yaml', '.json', or no file extension. See :ref:`yaml_syntax` if you are new to YAML." +msgstr "メインのインベントリーファイルに変数を格納できますが、ホスト変数ファイルとグループ変数ファイルを別々に格納することで、変数の値をより簡単に整理できる場合があります。ホストとグループの変数ファイルは、YAML 構文を使用する必要があります。有効なファイル拡張子は、「.yml」、「.yaml」、または「.json」です。ファイル拡張子を付けなくても有効です。YAML を初めて使用する場合は、「:ref:`yaml_syntax`」を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:402 +msgid "Ansible loads host and group variable files by searching paths relative to the inventory file or the playbook file. If your inventory file at ``/etc/ansible/hosts`` contains a host named 'foosball' that belongs to two groups, 'raleigh' and 'webservers', that host will use variables in YAML files at the following locations:" +msgstr "Ansible は、インベントリーファイルまたは Playbook ファイルからの相対パスを検索して、ホストおよびグループ変数ファイルを読み込みます。``/etc/ansible/hosts`` のインベントリーファイルに「foosball」という名前のホストがあり、それが「raleigh」と「webservers」という 2 つのグループに所属している場合、そのホストは以下の場所にある YAML ファイルの変数を使用します。" + +#: ../../rst/user_guide/intro_inventory.rst:410 +msgid "For example, if you group hosts in your inventory by datacenter, and each datacenter uses its own NTP server and database server, you can create a file called ``/etc/ansible/group_vars/raleigh`` to store the variables for the ``raleigh`` group:" +msgstr "たとえば、インベントリー内のホストをデータセンターごとにまとめ、各データセンターが独自の NTP サーバーおよびデータベースサーバーを使用する場合は、``/etc/ansible/group_vars/raleigh`` という名前のファイルを作成して、``raleigh`` グループの変数を保存できます。" + +#: ../../rst/user_guide/intro_inventory.rst:418 +msgid "You can also create *directories* named after your groups or hosts. Ansible will read all the files in these directories in lexicographical order. An example with the 'raleigh' group:" +msgstr "また、グループまたはホストの名前が付けられた *ディレクトリー* も作成できます。Ansible は、これらのディレクトリーに含まれるすべてのファイルをディクショナリーの順に読み込みます。例では、「raleigh」グループを使用しています。" + +#: ../../rst/user_guide/intro_inventory.rst:425 +msgid "All hosts in the 'raleigh' group will have the variables defined in these files available to them. This can be very useful to keep your variables organized when a single file gets too big, or when you want to use :ref:`Ansible Vault<playbooks_vault>` on some group variables." +msgstr "「raleigh」グループのすべてのホストは、これらのファイルで定義された変数を利用できるようになります。これは、1 つのファイルが大きくなりすぎたときに、変数を整理しておくのに非常に便利です。また、いくつかのグループ変数に :ref:`Ansible Vault<playbooks_vault>` を使用したい場合にも便利です。" + +#: ../../rst/user_guide/intro_inventory.rst:429 +msgid "For ``ansible-playbook`` you can also add ``group_vars/`` and ``host_vars/`` directories to your playbook directory. Other Ansible commands (for example, ``ansible``, ``ansible-console``, and so on) will only look for ``group_vars/`` and ``host_vars/`` in the inventory directory. If you want other commands to load group and host variables from a playbook directory, you must provide the ``--playbook-dir`` option on the command line. If you load inventory files from both the playbook directory and the inventory directory, variables in the playbook directory will override variables set in the inventory directory." +msgstr "``ansible-playbook`` に関して、ディレクトリー ``group_vars/``および ``host_vars/`` を Playbook ディレクトリーに追加することもできます。他の Ansible コマンド (たとえば、``ansible``、``ansible-console`` など) は、インベントリーディレクトリー内の ``group_vars/`` と ``host_vars/`` のみを探します。他のコマンドで Playbook ディレクトリーからグループ変数やホスト変数を読み込む場合は、コマンドラインで ``--playbook-dir`` オプションを指定する必要があります。Playbook ディレクトリーと inventory ディレクトリーの両方からインベントリーファイルを読み込んだ場合、Playbook ディレクトリーの変数はインベントリーディレクトリーで設定された変数よりも優先されます。" + +#: ../../rst/user_guide/intro_inventory.rst:432 +msgid "Keeping your inventory file and variables in a git repo (or other version control) is an excellent way to track changes to your inventory and host variables." +msgstr "git リポジトリー (または他のバージョン管理) でインベントリーファイルおよび変数を維持することは、インベントリーおよびホスト変数への変更を追跡する優れた方法です。" + +#: ../../rst/user_guide/intro_inventory.rst:438 +msgid "How variables are merged" +msgstr "変数をマージする方法" + +#: ../../rst/user_guide/intro_inventory.rst:440 +msgid "By default variables are merged/flattened to the specific host before a play is run. This keeps Ansible focused on the Host and Task, so groups don't really survive outside of inventory and host matching. By default, Ansible overwrites variables including the ones defined for a group and/or host (see :ref:`DEFAULT_HASH_BEHAVIOUR<DEFAULT_HASH_BEHAVIOUR>`). The order/precedence is (from lowest to highest):" +msgstr "デフォルトでは、プレイが実行される前に、変数が特定のホストにマージ/フラット化されます。これにより、Ansible はホストとタスクに焦点を当てているため、グループはインベントリーとホストの一致以外では実際には存続しません。デフォルトでは、Ansible はグループやホストに定義されたものを含む変数を上書きします (「:ref:`DEFAULT_HASH_BEHAVIOUR<DEFAULT_HASH_BEHAVIOUR>`」を参照)。その順序/優先順位は (低いものから高いものへ) となっています。" + +#: ../../rst/user_guide/intro_inventory.rst:442 +msgid "all group (because it is the 'parent' of all other groups)" +msgstr "すべてのグループ (他のすべてのグループの「親」であるため)" + +#: ../../rst/user_guide/intro_inventory.rst:443 +msgid "parent group" +msgstr "親グループ" + +#: ../../rst/user_guide/intro_inventory.rst:444 +msgid "child group" +msgstr "子グループ" + +#: ../../rst/user_guide/intro_inventory.rst:445 +msgid "host" +msgstr "host" + +#: ../../rst/user_guide/intro_inventory.rst:447 +msgid "By default Ansible merges groups at the same parent/child level in ASCII order, and the last group loaded overwrites the previous groups. For example, an a_group will be merged with b_group and b_group vars that match will overwrite the ones in a_group." +msgstr "デフォルトでは、Ansible は同じ親子レベルのグループを ASCII 順にマージし、最後に読み込まれたグループがそれ以前のグループを上書きします。たとえば、a_group は b_group にマージされ、一致する b_group の変数が a_group の変数を上書きします。" + +#: ../../rst/user_guide/intro_inventory.rst:449 +msgid "You can change this behavior by setting the group variable ``ansible_group_priority`` to change the merge order for groups of the same level (after the parent/child order is resolved). The larger the number, the later it will be merged, giving it higher priority. This variable defaults to ``1`` if not set. For example:" +msgstr "この動作を変更するには、グループ変数 ``ansible_group_priority`` を設定して、同じレベルのグループのマージ順序を変更することができます (親子の順序が解決された後)。数字が大きいほど後にマージされ、優先順位が高くなります。この変数が設定されていない場合のデフォルトは ``1`` です。たとえば、以下のようになります。" + +#: ../../rst/user_guide/intro_inventory.rst:461 +msgid "In this example, if both groups have the same priority, the result would normally have been ``testvar == b``, but since we are giving the ``a_group`` a higher priority the result will be ``testvar == a``." +msgstr "この例では、両方のグループの優先順位が同じ場合、結果は通常 ``testvar == b`` になりますが、``a_group`` の優先度が高いため、結果は ``testvar == a`` になります。" + +#: ../../rst/user_guide/intro_inventory.rst:463 +msgid "``ansible_group_priority`` can only be set in the inventory source and not in group_vars/, as the variable is used in the loading of group_vars." +msgstr "``ansible_group_priority`` は、group_vars の読み込みでこの変数が使用されるため、インベントリーソースでのみ設定でき、group_vars/ では設定できません。" + +#: ../../rst/user_guide/intro_inventory.rst:468 +msgid "Using multiple inventory sources" +msgstr "複数のインベントリーソースの使用" + +#: ../../rst/user_guide/intro_inventory.rst:470 +msgid "You can target multiple inventory sources (directories, dynamic inventory scripts or files supported by inventory plugins) at the same time by giving multiple inventory parameters from the command line or by configuring :envvar:`ANSIBLE_INVENTORY`. This can be useful when you want to target normally separate environments, like staging and production, at the same time for a specific action." +msgstr "コマンドラインから複数のインベントリーパラメーターを指定するか、:envvar:`ANSIBLE_INVENTORY` を設定することで、複数のインベントリーリソース (ディレクトリー、動的インベントリースクリプト、またはインベントリープラグインによりサポートされるファイル) を同時に対象に指定できます。これは、ステージ環境や実稼働環境など、通常は異なる環境を同時に対象に指定にして特定のアクションを実行したい場合に便利です。" + +#: ../../rst/user_guide/intro_inventory.rst:475 +msgid "Target two sources from the command line like this:" +msgstr "以下のようなコマンドラインから 2 つのソースを対象とします。" + +#: ../../rst/user_guide/intro_inventory.rst:481 +msgid "Keep in mind that if there are variable conflicts in the inventories, they are resolved according to the rules described in :ref:`how_we_merge` and :ref:`ansible_variable_precedence`. The merging order is controlled by the order of the inventory source parameters. If ``[all:vars]`` in staging inventory defines ``myvar = 1``, but production inventory defines ``myvar = 2``, the playbook will be run with ``myvar = 2``. The result would be reversed if the playbook was run with ``-i production -i staging``." +msgstr "インベントリーに変数の競合がある場合は、:ref:`how_we_merge` および :ref:`ansible_variable_precedence` で説明されているルールに従って解決されることを覚えておいてください。マージの順序は、インベントリーのソースパラメーターの順序によって制御されます。ステージングインベントリーの ``[all:vars]`` が ``myvar = 1`` を定義していて、実稼働インベントリーが ``myvar = 2`` を定義している場合、Playbook は ``myvar = 2`` で実行されます。Playbook が ``-i production -i staging`` で実行された場合は、結果が逆になります。" + +#: ../../rst/user_guide/intro_inventory.rst:488 +msgid "**Aggregating inventory sources with a directory**" +msgstr "**インベントリーソースをディレクトリーに集約**" + +#: ../../rst/user_guide/intro_inventory.rst:490 +msgid "You can also create an inventory by combining multiple inventory sources and source types under a directory. This can be useful for combining static and dynamic hosts and managing them as one inventory. The following inventory combines an inventory plugin source, a dynamic inventory script, and a file with static hosts:" +msgstr "また、複数のインベントリーソースやソースタイプを 1 つのディレクトリー下にまとめてインベントリーを作成することもできます。これは、静的ホストと動的ホストを組み合わせて、1 つのインベントリーとして管理するのに便利です。次のインベントリーは、インベントリープラグインソース、動的インベントリースクリプト、および静的ホストのファイルを組み合わせたものです。" + +#: ../../rst/user_guide/intro_inventory.rst:504 +msgid "You can target this inventory directory simply like this:" +msgstr "このインベントリーディレクトリーは、次のように簡単に対象に設定できます。" + +#: ../../rst/user_guide/intro_inventory.rst:510 +msgid "It can be useful to control the merging order of the inventory sources if there's variable conflicts or group of groups dependencies to the other inventory sources. The inventories are merged in ASCII order according to the filenames so the result can be controlled by adding prefixes to the files:" +msgstr "他のインベントリーソースに対する変数の競合やグループのグループの依存関係がある場合は、インベントリーソースのマージ順序を制御すると便利です。インベントリーはファイル名に応じて ASCII 順にマージされるため、ファイルにプレフィックスを追加することで結果をコントロールすることができます。" + +#: ../../rst/user_guide/intro_inventory.rst:524 +msgid "If ``01-openstack.yml`` defines ``myvar = 1`` for the group ``all``, ``02-dynamic-inventory.py`` defines ``myvar = 2``, and ``03-static-inventory`` defines ``myvar = 3``, the playbook will be run with ``myvar = 3``." +msgstr "``01-openstack.yml`` がグループ ``all`` に対して ``myvar = 1`` を定義し、``02-dynamic-inventory.py`` が ``myvar = 2`` を定義し、``03-static-inventory`` が ``myvar = 3`` を定義した場合は、Playbook が ``myvar = 3`` で実行します。" + +#: ../../rst/user_guide/intro_inventory.rst:527 +msgid "For more details on inventory plugins and dynamic inventory scripts see :ref:`inventory_plugins` and :ref:`intro_dynamic_inventory`." +msgstr "インベントリープラグインおよび動的インベントリースクリプトの詳細は、「:ref:`inventory_plugins`」および「:ref:`intro_dynamic_inventory`」を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:532 +msgid "Connecting to hosts: behavioral inventory parameters" +msgstr "ホストへの接続: 動作用インベントリーパラメーター" + +#: ../../rst/user_guide/intro_inventory.rst:534 +msgid "As described above, setting the following variables control how Ansible interacts with remote hosts." +msgstr "上記のように、以下の変数を設定して、Ansible がリモートホストと対話する方法を制御します。" + +#: ../../rst/user_guide/intro_inventory.rst:536 +msgid "Host connection:" +msgstr "ホスト接続:" + +#: ../../rst/user_guide/intro_inventory.rst:541 +msgid "ansible_connection" +msgstr "ansible_connection" + +#: ../../rst/user_guide/intro_inventory.rst:541 +msgid "Connection type to the host. This can be the name of any of ansible's connection plugins. SSH protocol types are ``smart``, ``ssh`` or ``paramiko``. The default is smart. Non-SSH based types are described in the next section." +msgstr "ホストへの接続タイプ。これは、Ansible の connection プラグインの名前です。SSH プロトコルタイプは ``smart``、``ssh``、または ``paramiko`` です。デフォルトは smart です。SSH ベース以外のタイプは次のセクションで説明します。" + +#: ../../rst/user_guide/intro_inventory.rst:543 +msgid "General for all connections:" +msgstr "すべての接続に対する一般的な設定:" + +#: ../../rst/user_guide/intro_inventory.rst:545 +#: ../../rst/user_guide/intro_inventory.rst:648 +msgid "ansible_host" +msgstr "ansible_host" + +#: ../../rst/user_guide/intro_inventory.rst:546 +msgid "The name of the host to connect to, if different from the alias you wish to give to it." +msgstr "接続するホストの名前 (割り当てたいエイリアスと異なる場合)。" + +#: ../../rst/user_guide/intro_inventory.rst:547 +msgid "ansible_port" +msgstr "ansible_port" + +#: ../../rst/user_guide/intro_inventory.rst:548 +msgid "The connection port number, if not the default (22 for ssh)" +msgstr "デフォルトではない場合 (ssh の場合は 22) は、接続ポート番号。" + +#: ../../rst/user_guide/intro_inventory.rst:549 +#: ../../rst/user_guide/intro_inventory.rst:650 +msgid "ansible_user" +msgstr "ansible_user" + +#: ../../rst/user_guide/intro_inventory.rst:550 +msgid "The user name to use when connecting to the host" +msgstr "ホストに接続する際に使用するユーザー名。" + +#: ../../rst/user_guide/intro_inventory.rst:553 +msgid "ansible_password" +msgstr "ansible_password" + +#: ../../rst/user_guide/intro_inventory.rst:552 +msgid "The password to use to authenticate to the host (never store this variable in plain text; always use a vault. See :ref:`tip_for_variables_and_vaults`)" +msgstr "ホストへの認証に使用するパスワード (この変数を平文で保存しないでください。常に Valut を使用してください。「:ref:`tip_for_variables_and_vaults`」を参照)。" + +#: ../../rst/user_guide/intro_inventory.rst:555 +msgid "Specific to the SSH connection:" +msgstr "SSH 接続に固有:" + +#: ../../rst/user_guide/intro_inventory.rst:557 +msgid "ansible_ssh_private_key_file" +msgstr "ansible_ssh_private_key_file" + +#: ../../rst/user_guide/intro_inventory.rst:558 +msgid "Private key file used by ssh. Useful if using multiple keys and you don't want to use SSH agent." +msgstr "ssh が使用する秘密鍵ファイル。複数の鍵を使用し、SSH エージェントを使用したくない場合に便利です。" + +#: ../../rst/user_guide/intro_inventory.rst:561 +msgid "ansible_ssh_common_args" +msgstr "ansible_ssh_common_args" + +#: ../../rst/user_guide/intro_inventory.rst:560 +msgid "This setting is always appended to the default command line for :command:`sftp`, :command:`scp`, and :command:`ssh`. Useful to configure a ``ProxyCommand`` for a certain host (or group)." +msgstr "この設定は、常に :command:`sftp`、:command:`scp`、および :command:`ssh` のデフォルトのコマンドラインに追加されます。特定のホスト (またはグループ) に ``ProxyCommand`` を設定してください。" + +#: ../../rst/user_guide/intro_inventory.rst:563 +msgid "ansible_sftp_extra_args" +msgstr "ansible_sftp_extra_args" + +#: ../../rst/user_guide/intro_inventory.rst:564 +msgid "This setting is always appended to the default :command:`sftp` command line." +msgstr "この設定は、デフォルトの :command:`sftp` コマンドラインに常に付加されます。" + +#: ../../rst/user_guide/intro_inventory.rst:565 +msgid "ansible_scp_extra_args" +msgstr "ansible_scp_extra_args" + +#: ../../rst/user_guide/intro_inventory.rst:566 +msgid "This setting is always appended to the default :command:`scp` command line." +msgstr "この設定は、デフォルトの :command:`scp` コマンドラインに常に付加されます。" + +#: ../../rst/user_guide/intro_inventory.rst:567 +msgid "ansible_ssh_extra_args" +msgstr "ansible_ssh_extra_args" + +#: ../../rst/user_guide/intro_inventory.rst:568 +msgid "This setting is always appended to the default :command:`ssh` command line." +msgstr "この設定は、デフォルトの :command:`ssh` コマンドラインに常に付加されます。" + +#: ../../rst/user_guide/intro_inventory.rst:569 +msgid "ansible_ssh_pipelining" +msgstr "ansible_ssh_pipelining" + +#: ../../rst/user_guide/intro_inventory.rst:570 +msgid "Determines whether or not to use SSH pipelining. This can override the ``pipelining`` setting in :file:`ansible.cfg`." +msgstr "SSH パイプラインを使用するかどうかを決定します。これは :file:`ansible.cfg` の ``pipelining`` の設定を上書きすることができます。" + +#: ../../rst/user_guide/intro_inventory.rst:573 +msgid "ansible_ssh_executable (added in version 2.2)" +msgstr "ansible_ssh_executable (バージョン 2.2 で追加)" + +#: ../../rst/user_guide/intro_inventory.rst:572 +msgid "This setting overrides the default behavior to use the system :command:`ssh`. This can override the ``ssh_executable`` setting in :file:`ansible.cfg`." +msgstr "この設定により、システムの :command:`ssh` を使用するようにデフォルトの動作が上書きされます。これにより、:file:`ansible.cfg` の ``ssh_executable`` 設定を上書きできます。" + +#: ../../rst/user_guide/intro_inventory.rst:575 +msgid "Privilege escalation (see :ref:`Ansible Privilege Escalation<become>` for further details):" +msgstr "権限の昇格 (詳細は「:ref:`Ansible 権限昇格<become>`」を参照):" + +#: ../../rst/user_guide/intro_inventory.rst:578 +msgid "Equivalent to ``ansible_sudo`` or ``ansible_su``, allows to force privilege escalation" +msgstr "``ansible_sudo`` または ``ansible_su`` と同等です。これにより、権限昇格を強制できます。" + +#: ../../rst/user_guide/intro_inventory.rst:580 +msgid "Allows to set privilege escalation method" +msgstr "権限昇格メソッドの設定を許可します。" + +#: ../../rst/user_guide/intro_inventory.rst:582 +msgid "Equivalent to ``ansible_sudo_user`` or ``ansible_su_user``, allows to set the user you become through privilege escalation" +msgstr "``ansible_sudo_user`` または ``ansible_su_user`` と同等で、権限昇格により become を行うユーザーを設定できます。" + +#: ../../rst/user_guide/intro_inventory.rst:584 +msgid "Equivalent to ``ansible_sudo_password`` or ``ansible_su_password``, allows you to set the privilege escalation password (never store this variable in plain text; always use a vault. See :ref:`tip_for_variables_and_vaults`)" +msgstr "``ansible_sudo_password`` または ``ansible_su_password`` と同等で、特権昇格パスワードを設定できます (この変数を平文で保存せず、常に vault を使用してください。「:ref:`tip_for_variables_and_vaults`」を参照してください)。" + +#: ../../rst/user_guide/intro_inventory.rst:585 +msgid "ansible_become_exe" +msgstr "ansible_become_exe" + +#: ../../rst/user_guide/intro_inventory.rst:586 +msgid "Equivalent to ``ansible_sudo_exe`` or ``ansible_su_exe``, allows you to set the executable for the escalation method selected" +msgstr "``ansible_sudo_exe`` または ``ansible_su_exe`` と同等で、選択した昇格メソッドの実行ファイルを設定できます。" + +#: ../../rst/user_guide/intro_inventory.rst:588 +msgid "ansible_become_flags" +msgstr "ansible_become_flags" + +#: ../../rst/user_guide/intro_inventory.rst:588 +msgid "Equivalent to ``ansible_sudo_flags`` or ``ansible_su_flags``, allows you to set the flags passed to the selected escalation method. This can be also set globally in :file:`ansible.cfg` in the ``sudo_flags`` option" +msgstr "``ansible_sudo_flags`` または ``ansible_su_flags`` と同等で、選択された昇格方法に渡されるフラグを設定することができます。これは ``sudo_flags`` オプションの :file:`ansible.cfg` でもグローバルに設定できます。" + +#: ../../rst/user_guide/intro_inventory.rst:590 +msgid "Remote host environment parameters:" +msgstr "リモートホスト環境パラメーター:" + +#: ../../rst/user_guide/intro_inventory.rst:598 +msgid "ansible_shell_type" +msgstr "ansible_shell_type" + +#: ../../rst/user_guide/intro_inventory.rst:595 +msgid "The shell type of the target system. You should not use this setting unless you have set the :ref:`ansible_shell_executable<ansible_shell_executable>` to a non-Bourne (sh) compatible shell. By default commands are formatted using ``sh``-style syntax. Setting this to ``csh`` or ``fish`` will cause commands executed on target systems to follow those shell's syntax instead." +msgstr "ターゲットシステムのシェルタイプ。:ref:`ansible_shell_executable<ansible_shell_executable>` を Bourne (sh) 以外の互換シェルに設定しない限り、この設定は使用しないでください。デフォルトでは、コマンドは ``sh`` スタイルの構文を使用してフォーマットされます。これを ``csh`` または ``fish`` に設定すると、ターゲットシステムで実行するコマンドがシェルの構文に従います。" + +#: ../../rst/user_guide/intro_inventory.rst:607 +msgid "ansible_python_interpreter" +msgstr "ansible_python_interpreter" + +#: ../../rst/user_guide/intro_inventory.rst:603 +msgid "The target host python path. This is useful for systems with more than one Python or not located at :command:`/usr/bin/python` such as \\*BSD, or where :command:`/usr/bin/python` is not a 2.X series Python. We do not use the :command:`/usr/bin/env` mechanism as that requires the remote user's path to be set right and also assumes the :program:`python` executable is named python, where the executable might be named something like :program:`python2.6`." +msgstr "ターゲットホストの Python パス。これは、複数の Python があるシステム、\\*BSD などの :command:`/usr/bin/python` にないシステム、:command:`/usr/bin/python` が 2.X シリーズの Python 以外のシステムに役立ちます。リモートユーザーのパスを正しく設定する必要があり、:program:`python` 実行ファイルの名前が python であると想定するため、:command:`/usr/bin/env` メカニズムは使用しません。実行ファイルの名前は :program:`python2.6` のようになります。" + +#: ../../rst/user_guide/intro_inventory.rst:611 +msgid "ansible_*_interpreter" +msgstr "ansible_*_interpreter" + +#: ../../rst/user_guide/intro_inventory.rst:610 +msgid "Works for anything such as ruby or perl and works just like :ref:`ansible_python_interpreter<ansible_python_interpreter>`. This replaces shebang of modules which will run on that host." +msgstr "ruby や perl などのあらゆるもので動作し、:ref:`ansible_python_interpreter<ansible_python_interpreter>` のように機能します。これは、そのホストで実行されるモジュールのシバンに代わるものです。" + +#: ../../rst/user_guide/intro_inventory.rst:622 +msgid "ansible_shell_executable" +msgstr "ansible_shell_executable" + +#: ../../rst/user_guide/intro_inventory.rst:618 +msgid "This sets the shell the ansible controller will use on the target machine, overrides ``executable`` in :file:`ansible.cfg` which defaults to :command:`/bin/sh`. You should really only change it if is not possible to use :command:`/bin/sh` (in other words, if :command:`/bin/sh` is not installed on the target machine or cannot be run from sudo.)." +msgstr "これにより、Ansible コントローラーがターゲットマシンで使用するシェルを設定し、:file:`ansible.cfg` の ``executable`` を上書きします。デフォルトは :command:`/bin/sh` です。:command:`/bin/sh` を使用できない場合にのみ変更する必要があります (つまり、:command:`/bin/sh` がターゲットマシンにインストールされていない場合、または sudo から実行できない場合)。" + +#: ../../rst/user_guide/intro_inventory.rst:624 +msgid "Examples from an Ansible-INI host file:" +msgstr "Ansible-INI ホストファイルの例:" + +#: ../../rst/user_guide/intro_inventory.rst:634 +msgid "Non-SSH connection types" +msgstr "SSH 以外の接続タイプ" + +#: ../../rst/user_guide/intro_inventory.rst:636 +msgid "As stated in the previous section, Ansible executes playbooks over SSH but it is not limited to this connection type. With the host specific parameter ``ansible_connection=<connector>``, the connection type can be changed. The following non-SSH based connectors are available:" +msgstr "前のセクションで説明したように、Ansible は SSH で Playbook を実行しますが、この接続タイプは制限されていません。ホスト固有のパラメーター ``ansible_connection=<connector>`` では、接続タイプを変更できます。次の SSH 以外のコネクターを利用できます。" + +#: ../../rst/user_guide/intro_inventory.rst:640 +msgid "**local**" +msgstr "**local**" + +#: ../../rst/user_guide/intro_inventory.rst:642 +msgid "This connector can be used to deploy the playbook to the control machine itself." +msgstr "このコネクターは、Playbook をコントロールマシン自体にデプロイするために使用できます。" + +#: ../../rst/user_guide/intro_inventory.rst:644 +msgid "**docker**" +msgstr "**docker**" + +#: ../../rst/user_guide/intro_inventory.rst:646 +msgid "This connector deploys the playbook directly into Docker containers using the local Docker client. The following parameters are processed by this connector:" +msgstr "このコネクターは、ローカルの Docker クライアントを使用して Playbook を直接 Docker コンテナーにデプロイします。以下のパラメーターはこのコネクターによって処理されます。" + +#: ../../rst/user_guide/intro_inventory.rst:649 +msgid "The name of the Docker container to connect to." +msgstr "接続先の Docker コンテナーの名前。" + +#: ../../rst/user_guide/intro_inventory.rst:651 +msgid "The user name to operate within the container. The user must exist inside the container." +msgstr "コンテナー内で操作するためのユーザ名。ユーザーはコンテナー内に存在している必要があります。" + +#: ../../rst/user_guide/intro_inventory.rst:653 +msgid "If set to ``true`` the ``become_user`` will be used to operate within the container." +msgstr "``true`` に設定すると、``become_user`` はコンテナー内で動作するために使用されます。" + +#: ../../rst/user_guide/intro_inventory.rst:655 +msgid "ansible_docker_extra_args" +msgstr "ansible_docker_extra_args" + +#: ../../rst/user_guide/intro_inventory.rst:655 +msgid "Could be a string with any additional arguments understood by Docker, which are not command specific. This parameter is mainly used to configure a remote Docker daemon to use." +msgstr "Docker が認識する追加の引数を持つ文字列を指定できますが、これはコマンド固有ではありません。このパラメーターは主に、使用するリモート Docker デーモンを設定するために使用されます。" + +#: ../../rst/user_guide/intro_inventory.rst:657 +msgid "Here is an example of how to instantly deploy to created containers:" +msgstr "以下は、作成されたコンテナーに即時にデプロイする例を示しています。" + +#: ../../rst/user_guide/intro_inventory.rst:681 +msgid "For a full list with available plugins and examples, see :ref:`connection_plugin_list`." +msgstr "利用可能なプラグインとサンプルの一覧は、「:ref:`connection_plugin_list`」を参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:683 +msgid "If you're reading the docs from the beginning, this may be the first example you've seen of an Ansible playbook. This is not an inventory file. Playbooks will be covered in great detail later in the docs." +msgstr "ドキュメントを最初から読んでいる場合、これは Ansible Playbook を初めて確認した例です。これはインベントリーファイルではありません。Playbook は、ドキュメントで後ほど詳細に説明しています。" + +#: ../../rst/user_guide/intro_inventory.rst:689 +msgid "Inventory setup examples" +msgstr "インベントリーの設定例" + +#: ../../rst/user_guide/intro_inventory.rst:691 +msgid "See also :ref:`sample_setup`, which shows inventory along with playbooks and other Ansible artifacts." +msgstr "Playbook およびその他の Ansible アーティファクトとともにインベントリーを表示する「:ref:`sample_setup`」も参照してください。" + +#: ../../rst/user_guide/intro_inventory.rst:696 +msgid "Example: One inventory per environment" +msgstr "例: 各環境に 1 つのインベントリー" + +#: ../../rst/user_guide/intro_inventory.rst:698 +msgid "If you need to manage multiple environments it's sometimes prudent to have only hosts of a single environment defined per inventory. This way, it is harder to, for instance, accidentally change the state of nodes inside the \"test\" environment when you actually wanted to update some \"staging\" servers." +msgstr "複数の環境を管理する必要がある場合、インベントリーごとに 1 つの環境のホストのみを定義することが賢明な場合があります。こうすることで、たとえば、実際には「ステージング」サーバーを更新したいのに、誤って「テスト」環境内のノードの状態を変更してしまうことが起こりにくくなります。" + +#: ../../rst/user_guide/intro_inventory.rst:704 +msgid "For the example mentioned above you could have an :file:`inventory_test` file:" +msgstr "前述の例では、:file:`inventory_test` というファイルがあります。" + +#: ../../rst/user_guide/intro_inventory.rst:718 +msgid "That file only includes hosts that are part of the \"test\" environment. Define the \"staging\" machines in another file called :file:`inventory_staging`:" +msgstr "このファイルには、「テスト」環境に含まれるホストのみが含まれます。:file:`inventory_staging` と呼ばれる別のファイルの「ステージング」マシンを定義します。" + +#: ../../rst/user_guide/intro_inventory.rst:733 +msgid "To apply a playbook called :file:`site.yml` to all the app servers in the test environment, use the following command:" +msgstr "`site.yml` という名前の Playbook をテスト環境のすべてのアプリケーションサーバーに適用するには、次のコマンドを使用します。" + +#: ../../rst/user_guide/intro_inventory.rst:744 +msgid "Example: Group by function" +msgstr "例: 機能別にグループ化" + +#: ../../rst/user_guide/intro_inventory.rst:746 +msgid "In the previous section you already saw an example for using groups in order to cluster hosts that have the same function. This allows you, for instance, to define firewall rules inside a playbook or role affecting only database servers:" +msgstr "前セクションでは、同じ機能を持つホストをクラスター化するために、グループを使用する例をすでに提示しています。これにより、データベースサーバーだけに影響する Playbook またはロール内でファイアウォールルールを定義できます。" + +#: ../../rst/user_guide/intro_inventory.rst:764 +msgid "Example: Group by location" +msgstr "例: 場所別にグループ化" + +#: ../../rst/user_guide/intro_inventory.rst:766 +msgid "Other tasks might be focused on where a certain host is located. Let's say that ``db01.test.example.com`` and ``app01.test.example.com`` are located in DC1 while ``db02.test.example.com`` is in DC2:" +msgstr "また、特定のホストがどこにあるかに焦点を当てたタスクもあります。たとえば、``db01.test.example.com`` と ``app01.test.example.com`` が DC1 にあり、``db02.test.example.com`` が DC2 にあるとします。" + +#: ../../rst/user_guide/intro_inventory.rst:779 +msgid "In practice, you might even end up mixing all these setups as you might need to, on one day, update all nodes in a specific data center while, on another day, update all the application servers no matter their location." +msgstr "実際には、たとえば特定のデータセンター内のすべてのノードを更新する日と、置かれている場所に関係なくすべてのアプリケーションサーバーを更新する日が必要になるため、これらすべての設定を組み合わせて使用することがあります。" + +#: ../../rst/user_guide/intro_inventory.rst:786 +msgid ":ref:`inventory_plugins`" +msgstr ":ref:`inventory_plugins`" + +#: ../../rst/user_guide/intro_inventory.rst:787 +msgid "Pulling inventory from dynamic or static sources" +msgstr "動的ソースまたは静的ソースからのインベントリーのプル" + +#: ../../rst/user_guide/intro_inventory.rst:788 +msgid ":ref:`intro_dynamic_inventory`" +msgstr ":ref:`intro_dynamic_inventory`" + +#: ../../rst/user_guide/intro_inventory.rst:789 +msgid "Pulling inventory from dynamic sources, such as cloud providers" +msgstr "クラウドプロバイダーなどの動的ソースからのインベントリーのプル" + +#: ../../rst/user_guide/intro_inventory.rst:793 +msgid "Learning Ansible's configuration, deployment, and orchestration language." +msgstr "Ansible の設定、デプロイメント、およびオーケストレーション言語について" + +#: ../../rst/user_guide/intro_patterns.rst:4 +msgid "Patterns: targeting hosts and groups" +msgstr "パターン: ホストおよびグループを対象とする" + +#: ../../rst/user_guide/intro_patterns.rst:6 +msgid "When you execute Ansible through an ad hoc command or by running a playbook, you must choose which managed nodes or groups you want to execute against. Patterns let you run commands and playbooks against specific hosts and/or groups in your inventory. An Ansible pattern can refer to a single host, an IP address, an inventory group, a set of groups, or all hosts in your inventory. Patterns are highly flexible - you can exclude or require subsets of hosts, use wildcards or regular expressions, and more. Ansible executes on all inventory hosts included in the pattern." +msgstr "アドホックコマンドまたは Playbook から Ansible を実行する場合は、実行する管理ノードまたはグループを選択する必要があります。パターンにより、インベントリー内の特定のホストやグループに対してコマンドと Playbook を実行できます。Ansible パターンは、1 台のホスト、IP アドレス、インベントリーグループ、グループセット、またはインベントリー内のすべてのホストを参照できます。パターンは柔軟性が高く、ホストのサブセットを除外または要求したり、ワイルドカードや正規表現を使用したりできます。Ansible は、パターンに含まれるすべてのインベントリーホストで実行します。" + +#: ../../rst/user_guide/intro_patterns.rst:12 +msgid "Using patterns" +msgstr "パターンの使用" + +#: ../../rst/user_guide/intro_patterns.rst:14 +msgid "You use a pattern almost any time you execute an ad hoc command or a playbook. The pattern is the only element of an :ref:`ad hoc command<intro_adhoc>` that has no flag. It is usually the second element:" +msgstr "アドホックコマンドまたは Playbook を実行する際は、ほぼ常にパターンを使用します。パターンは、フラグのない :ref:`アドホックコマンド<intro_adhoc>` の唯一の要素です。通常は 2 番目の要素になります。" + +#: ../../rst/user_guide/intro_patterns.rst:26 +msgid "In a playbook the pattern is the content of the ``hosts:`` line for each play:" +msgstr "Playbook では、パターンは各プレイの ``hosts:`` 行の内容になります。" + +#: ../../rst/user_guide/intro_patterns.rst:40 +msgid "Since you often want to run a command or playbook against multiple hosts at once, patterns often refer to inventory groups. Both the ad hoc command and the playbook above will execute against all machines in the ``webservers`` group." +msgstr "多くの場合は、コマンドまたは Playbook を複数のホストに対して一度に実行するため、パターンは多くの場合インベントリーグループを参照します。アドホックコマンドと上記の Playbook は、``webservers`` グループのすべてのマシンに対して実行されます。" + +#: ../../rst/user_guide/intro_patterns.rst:45 +msgid "Common patterns" +msgstr "一般的なパターン" + +#: ../../rst/user_guide/intro_patterns.rst:47 +msgid "This table lists common patterns for targeting inventory hosts and groups." +msgstr "以下の表は、インベントリーホストおよびグループを対象に設定する一般的なパターンを示しています。" + +#: ../../rst/user_guide/intro_patterns.rst:53 +#: ../../rst/user_guide/playbooks_loops.rst:434 +msgid "Description" +msgstr "説明" + +#: ../../rst/user_guide/intro_patterns.rst:53 +msgid "Pattern(s)" +msgstr "パターン" + +#: ../../rst/user_guide/intro_patterns.rst:53 +msgid "Targets" +msgstr "ターゲット" + +#: ../../rst/user_guide/intro_patterns.rst:55 +msgid "All hosts" +msgstr "すべてのホスト" + +#: ../../rst/user_guide/intro_patterns.rst:55 +msgid "all (or \\*)" +msgstr "all (または \\*)" + +#: ../../rst/user_guide/intro_patterns.rst:57 +msgid "One host" +msgstr "1 台のホスト" + +#: ../../rst/user_guide/intro_patterns.rst:57 +msgid "host1" +msgstr "host1" + +#: ../../rst/user_guide/intro_patterns.rst:59 +msgid "Multiple hosts" +msgstr "複数のホスト" + +#: ../../rst/user_guide/intro_patterns.rst:59 +msgid "host1:host2 (or host1,host2)" +msgstr "host1:host2 (または host1,host2)" + +#: ../../rst/user_guide/intro_patterns.rst:61 +msgid "One group" +msgstr "1 つのグループ" + +#: ../../rst/user_guide/intro_patterns.rst:61 +msgid "webservers" +msgstr "webservers" + +#: ../../rst/user_guide/intro_patterns.rst:63 +msgid "Multiple groups" +msgstr "複数グループ" + +#: ../../rst/user_guide/intro_patterns.rst:63 +msgid "webservers:dbservers" +msgstr "webservers:dbservers" + +#: ../../rst/user_guide/intro_patterns.rst:63 +msgid "all hosts in webservers plus all hosts in dbservers" +msgstr "webservers 上のすべてのホストと、dbservers 上のすべてのホスト" + +#: ../../rst/user_guide/intro_patterns.rst:65 +msgid "Excluding groups" +msgstr "グループの除外" + +#: ../../rst/user_guide/intro_patterns.rst:65 +msgid "webservers:!atlanta" +msgstr "webservers:!atlanta" + +#: ../../rst/user_guide/intro_patterns.rst:65 +msgid "all hosts in webservers except those in atlanta" +msgstr "atlanta 上のホストを除く webservers のすべてのホスト" + +#: ../../rst/user_guide/intro_patterns.rst:67 +msgid "Intersection of groups" +msgstr "グループの交差部分" + +#: ../../rst/user_guide/intro_patterns.rst:67 +msgid "webservers:&staging" +msgstr "webservers:&staging" + +#: ../../rst/user_guide/intro_patterns.rst:67 +msgid "any hosts in webservers that are also in staging" +msgstr "ステージ状態にある webservers のすべてのホスト" + +#: ../../rst/user_guide/intro_patterns.rst:70 +msgid "You can use either a comma (``,``) or a colon (``:``) to separate a list of hosts. The comma is preferred when dealing with ranges and IPv6 addresses." +msgstr "ホストのリストを分離するには、コンマ (``,``) またはコロン (``:``) のいずれかを使用できます。コンマは、範囲および IPv6 アドレスを処理する場合に推奨されます。" + +#: ../../rst/user_guide/intro_patterns.rst:72 +msgid "Once you know the basic patterns, you can combine them. This example:" +msgstr "基本的なパターンを把握したら、それを組み合わせることができます。以下に例を示します。" + +#: ../../rst/user_guide/intro_patterns.rst:78 +msgid "targets all machines in the groups 'webservers' and 'dbservers' that are also in the group 'staging', except any machines in the group 'phoenix'." +msgstr "「phoenix」グループのマシンを除き、「staging」グループにある「webservers」グループおよび「dbservers」グループにあるすべてのマシンを対象とします。" + +#: ../../rst/user_guide/intro_patterns.rst:81 +msgid "You can use wildcard patterns with FQDNs or IP addresses, as long as the hosts are named in your inventory by FQDN or IP address:" +msgstr "ホストがインベントリーで FQDN または IP アドレスにより名前が付けられている限り、FQDN または IP アドレスでワイルドカードパターンを使用できます。" + +#: ../../rst/user_guide/intro_patterns.rst:89 +msgid "You can mix wildcard patterns and groups at the same time:" +msgstr "ワイルドカードパターンおよびグループを同時に組み合わせることができます。" + +#: ../../rst/user_guide/intro_patterns.rst:96 +msgid "Limitations of patterns" +msgstr "パターンの制限" + +#: ../../rst/user_guide/intro_patterns.rst:98 +msgid "Patterns depend on inventory. If a host or group is not listed in your inventory, you cannot use a pattern to target it. If your pattern includes an IP address or hostname that does not appear in your inventory, you will see an error like this:" +msgstr "パターンはインベントリーによって異なります。ホストまたはグループがインベントリーに記載されていない場合は、ターゲットにパターンを使用することはできません。インベントリーに表示されない IP アドレスまたはホスト名がパターンに含まれている場合は、以下のようなエラーが表示されます。" + +#: ../../rst/user_guide/intro_patterns.rst:105 +msgid "Your pattern must match your inventory syntax. If you define a host as an :ref:`alias<inventory_aliases>`:" +msgstr "お使いのパターンはインベントリー構文に一致する必要があります。ホストを :ref:`エイリアス<inventory_aliases>` として定義する場合は、以下を指定します。" + +#: ../../rst/user_guide/intro_patterns.rst:115 +msgid "you must use the alias in your pattern. In the example above, you must use ``host1`` in your pattern. If you use the IP address, you will once again get the error:" +msgstr "パターンでエイリアスを使用する必要があります。上記の例では、パターンで ``host1`` を使用する必要があります。IP アドレスを使用する場合は、エラーが再度表示されます。" + +#: ../../rst/user_guide/intro_patterns.rst:122 +msgid "Advanced pattern options" +msgstr "詳細なパターンオプション" + +#: ../../rst/user_guide/intro_patterns.rst:124 +msgid "The common patterns described above will meet most of your needs, but Ansible offers several other ways to define the hosts and groups you want to target." +msgstr "上記の一般的なパターンはほとんどのニーズに対応しますが、Ansible では、対象とするホストおよびグループを定義する他の方法もいくつか提供します。" + +#: ../../rst/user_guide/intro_patterns.rst:127 +msgid "Using variables in patterns" +msgstr "パターンにおける変数の使用" + +#: ../../rst/user_guide/intro_patterns.rst:129 +msgid "You can use variables to enable passing group specifiers via the ``-e`` argument to ansible-playbook:" +msgstr "変数を使うと、ansible-playbook の ``-e`` 引数でグループ指定子を渡せるようになります。" + +#: ../../rst/user_guide/intro_patterns.rst:136 +msgid "Using group position in patterns" +msgstr "パターンにおけるグループの位置の使用" + +#: ../../rst/user_guide/intro_patterns.rst:138 +msgid "You can define a host or subset of hosts by its position in a group. For example, given the following group:" +msgstr "グループ内の位置によって、ホストやホストのサブセットを定義することができます。たとえば、次のようなグループが指定された場合です。" + +#: ../../rst/user_guide/intro_patterns.rst:147 +msgid "you can use subscripts to select individual hosts or ranges within the webservers group:" +msgstr "subscripts を使用して、webservers グループ内のホストまたは範囲を個別に選択できます。" + +#: ../../rst/user_guide/intro_patterns.rst:159 +msgid "Using regexes in patterns" +msgstr "パターンで正規表現の使用" + +#: ../../rst/user_guide/intro_patterns.rst:161 +msgid "You can specify a pattern as a regular expression by starting the pattern with ``~``:" +msgstr "パターンを正規表現として指定するには、``~`` でパターンを開始します。" + +#: ../../rst/user_guide/intro_patterns.rst:170 +msgid "You can change the behavior of the patterns defined in ad-hoc commands using command-line options. You can also limit the hosts you target on a particular run with the ``--limit`` flag." +msgstr "コマンドラインオプションを使用して、アドホックコマンドで定義されたパターンの動作を変更できます。また、``--limit`` フラグを使用して、特定の実行で対象とするホストを制限することもできます。" + +#: ../../rst/user_guide/intro_patterns.rst:173 +msgid "Limit to one host" +msgstr "1 台のホストに制限する" + +#: ../../rst/user_guide/intro_patterns.rst:179 +msgid "Limit to multiple hosts" +msgstr "複数のホストに制限する" + +#: ../../rst/user_guide/intro_patterns.rst:185 +msgid "Negated limit. Note that single quotes MUST be used to prevent bash interpolation." +msgstr "否定的な制限。bash の補間を防ぐために、一重引用符を使用する必要があります。" + +#: ../../rst/user_guide/intro_patterns.rst:191 +msgid "Limit to host group" +msgstr "ホストグループに制限する" + +#: ../../rst/user_guide/intro_patterns.rst:198 +msgid "Patterns and ansible-playbook flags" +msgstr "パターンおよび ansible-playbook フラグ" + +#: ../../rst/user_guide/intro_patterns.rst:200 +msgid "You can change the behavior of the patterns defined in playbooks using command-line options. For example, you can run a playbook that defines ``hosts: all`` on a single host by specifying ``-i 127.0.0.2,`` (note the trailing comma). This works even if the host you target is not defined in your inventory, but this method will NOT read your inventory for variables tied to this host and any variables required by the playbook will need to be specified manually at the command line. You can also limit the hosts you target on a particular run with the ``--limit`` flag, which will reference your inventory:" +msgstr "コマンドラインオプションを使用して Playbook で定義したパターンの動作を変更できます。たとえば、``-i 127.0.0.2,`` (末尾のコンマ) を指定して、単一のホストで ``hosts: all`` を定義する Playbook を実行することができます。これは、対象とするホストがインベントリーに定義されていない場合でも有効です。ただし、この手法ではこのホストに結び付けられた変数のインベントリーが読み取られず、Playbookが必要とするすべての変数をコマンドラインで手動で指定する必要があります。また、``--limit`` フラグを使用して、特定の実行で対象とするホストを制限することもできます。これにより、インベントリーが参照されます。" + +#: ../../rst/user_guide/intro_patterns.rst:206 +msgid "Finally, you can use ``--limit`` to read the list of hosts from a file by prefixing the file name with ``@``:" +msgstr "最後に ``--limit`` を使用して、ファイル名の前に ``@`` を付けることで、ファイルからホストのリストを読み込むことができます。" + +#: ../../rst/user_guide/intro_patterns.rst:212 +msgid "If :ref:`RETRY_FILES_ENABLED` is set to ``True``, a ``.retry`` file will be created after the ``ansible-playbook`` run containing a list of failed hosts from all plays. This file is overwritten each time ``ansible-playbook`` finishes running." +msgstr ":ref:`RETRY_FILES_ENABLED` が ``True`` に設定されている場合は、``ansible-playbook`` の実行後に、すべてのプレイで失敗したホストのリストを含む ``.retry`` ファイルが作成されます。このファイルは、``ansible-playbook`` の実行が終了するたびに上書きされます。" + +#: ../../rst/user_guide/intro_patterns.rst:214 +msgid "ansible-playbook site.yml --limit @site.retry" +msgstr "ansible-playbook site.yml --limit @site.retry" + +#: ../../rst/user_guide/intro_patterns.rst:216 +msgid "To apply your knowledge of patterns with Ansible commands and playbooks, read :ref:`intro_adhoc` and :ref:`playbooks_intro`." +msgstr "Ansible コマンドおよび Playbook でパターンに関する知識を活用するには、「:ref:`intro_adhoc`」および「:ref:`playbooks_intro`」を参照してください。" + +#: ../../rst/user_guide/intro_patterns.rst:223 +msgid "Learning the Ansible configuration management language" +msgstr "Ansible の設定管理言語について" + +#: ../../rst/user_guide/intro_windows.rst:2 +msgid "Windows Support" +msgstr "Windows サポート" + +#: ../../rst/user_guide/intro_windows.rst:4 +msgid "This page has been split up and moved to the new section :ref:`windows`." +msgstr "本ページは分割し、新しいセクション :ref:`windows` に移動しました。" + +#: ../../rst/user_guide/modules.rst:4 +msgid "Working With Modules" +msgstr "モジュールの使用" + +#: ../../rst/user_guide/modules.rst:14 +msgid "Ansible ships with a number of modules (called the 'module library') that can be executed directly on remote hosts or through :ref:`Playbooks <working_with_playbooks>`." +msgstr "Ansible には、リモートホスト上または :ref:`Playbooks <working_with_playbooks>` を介して直接実行できる多数のモジュール (「モジュールライブラリー」と呼ばれている) が同梱されています。" + +#: ../../rst/user_guide/modules.rst:17 +msgid "Users can also write their own modules. These modules can control system resources, like services, packages, or files (anything really), or handle executing system commands." +msgstr "ユーザーは自分でモジュールを書くこともできます。これらのモジュールは、サービス、パッケージ、ファイルなど (実際にはどんなものでも) のシステムリソースを制御したり、システムコマンドを実行することができます。" + +#: ../../rst/user_guide/modules.rst:24 +#: ../../rst/user_guide/modules_intro.rst:52 +#: ../../rst/user_guide/modules_support.rst:64 +msgid "Examples of using modules in /usr/bin/ansible" +msgstr "/usr/bin/ansible におけるモジュールの使用例" + +#: ../../rst/user_guide/modules.rst:25 +#: ../../rst/user_guide/playbooks_async.rst:184 +#: ../../rst/user_guide/playbooks_blocks.rst:182 +#: ../../rst/user_guide/playbooks_debugger.rst:337 +#: ../../rst/user_guide/playbooks_delegation.rst:165 +#: ../../rst/user_guide/playbooks_environment.rst:148 +#: ../../rst/user_guide/playbooks_error_handling.rst:268 +#: ../../rst/user_guide/playbooks_prompts.rst:115 +#: ../../rst/user_guide/playbooks_startnstep.rst:43 +#: ../../rst/user_guide/playbooks_tags.rst:425 +#: ../../rst/user_guide/playbooks_templating.rst:46 +#: ../../rst/user_guide/playbooks_tests.rst:509 +#: ../../rst/user_guide/windows_dsc.rst:497 +#: ../../rst/user_guide/windows_usage.rst:508 +#: ../../rst/user_guide/windows_winrm.rst:1000 +msgid ":ref:`playbooks_intro`" +msgstr ":ref:`playbooks_intro`" + +#: ../../rst/user_guide/modules.rst:26 +msgid "Introduction to using modules with /usr/bin/ansible-playbook" +msgstr "/usr/bin/ansible-playbook におけるモジュール使用の概要" + +#: ../../rst/user_guide/modules.rst:27 +msgid ":ref:`developing_modules_general`" +msgstr ":ref:`developing_modules_general`" + +#: ../../rst/user_guide/modules.rst:28 +#: ../../rst/user_guide/modules_intro.rst:56 +msgid "How to write your own modules" +msgstr "独自のモジュールの作成方法" + +#: ../../rst/user_guide/modules.rst:29 +#: ../../rst/user_guide/modules_intro.rst:57 +msgid ":ref:`developing_api`" +msgstr ":ref:`developing_api`" + +#: ../../rst/user_guide/modules.rst:30 +#: ../../rst/user_guide/modules_intro.rst:58 +msgid "Examples of using modules with the Python API" +msgstr "Python API でモジュールを使用する例" + +#: ../../rst/user_guide/modules.rst:32 +msgid "Configuring the right Python interpreter on target hosts" +msgstr "ターゲットホストでの適切な Python インタープリターの設定" + +#: ../../rst/user_guide/modules_intro.rst:4 +msgid "Introduction to modules" +msgstr "モジュールの概要" + +#: ../../rst/user_guide/modules_intro.rst:6 +msgid "Modules (also referred to as \"task plugins\" or \"library plugins\") are discrete units of code that can be used from the command line or in a playbook task. Ansible executes each module, usually on the remote managed node, and collects return values. In Ansible 2.10 and later, most modules are hosted in collections." +msgstr "モジュール (「タスクプラグイン」または「ライブラリープラグイン」とも呼ばれる) は、コマンドラインまたは Playbook タスクで使用可能なコードの個別単位です。Ansible は、各モジュールを実行し、通常のリモート管理ノードで実行し、戻り値を収集します。Ansible 2.10 以降では、ほとんどのモジュールはコレクションでホストされます。" + +#: ../../rst/user_guide/modules_intro.rst:8 +msgid "You can execute modules from the command line." +msgstr "コマンドラインからモジュールを実行できます。" + +#: ../../rst/user_guide/modules_intro.rst:16 +msgid "Each module supports taking arguments. Nearly all modules take ``key=value`` arguments, space delimited. Some modules take no arguments, and the command/shell modules simply take the string of the command you want to run." +msgstr "各モジュールは、引数を取ることをサポートしています。ほぼすべてのモジュールは、スペースで区切られた ``key=value`` の引数を取ります。一部のモジュールは引数を取らず、コマンド/シェルモジュールは単に実行したいコマンドの文字列を取ります。" + +#: ../../rst/user_guide/modules_intro.rst:18 +msgid "From playbooks, Ansible modules are executed in a very similar way." +msgstr "Playbook から、Ansible モジュールは同じような方法で実行されます。" + +#: ../../rst/user_guide/modules_intro.rst:25 +msgid "Another way to pass arguments to a module is using YAML syntax, also called 'complex args'." +msgstr "もしくは、「complex args」とも呼ばれる YAML 構文を使用して、モジュールに引数を渡します。" + +#: ../../rst/user_guide/modules_intro.rst:34 +msgid "All modules return JSON format data. This means modules can be written in any programming language. Modules should be idempotent, and should avoid making any changes if they detect that the current state matches the desired final state. When used in an Ansible playbook, modules can trigger 'change events' in the form of notifying :ref:`handlers <handlers>` to run additional tasks." +msgstr "すべてのモジュールは JSON 形式のデータを返します。これは、どのプログラミング言語でもモジュールを作成できます。モジュールは冪等であり、現在の状態が必要な最終状態と一致することを検知すると、変更は回避する必要があります。Ansible Playbook で使用すると、モジュールは :ref:`handlers <handlers>` に通知する形式で「変更イベント」をトリガーして追加のタスクを実行できます。" + +#: ../../rst/user_guide/modules_intro.rst:36 +msgid "You can access the documentation for each module from the command line with the ansible-doc tool." +msgstr "各モジュールのドキュメントは、ansible-doc ツールを使用してコマンドラインからアクセスできます。" + +#: ../../rst/user_guide/modules_intro.rst:42 +msgid "For a list of all available modules, see the :ref:`Collection docs <list_of_collections>`, or run the following at a command prompt." +msgstr "利用可能なモジュールの一覧は、「:ref:`Collection docs <list_of_collections>`」を参照してください。または、コマンドプロンプトで次のコマンドを実行します。" + +#: ../../rst/user_guide/modules_intro.rst:54 +#: ../../rst/user_guide/modules_support.rst:66 +msgid "Examples of using modules with /usr/bin/ansible-playbook" +msgstr "/usr/bin/ansible-playbook でモジュールを使用する例" + +#: ../../rst/user_guide/modules_support.rst:5 +msgid "Module Maintenance & Support" +msgstr "モジュールのメンテナンスおよびサポート" + +#: ../../rst/user_guide/modules_support.rst:7 +msgid "If you are using a module and you discover a bug, you may want to know where to report that bug, who is responsible for fixing it, and how you can track changes to the module. If you are a Red Hat subscriber, you may want to know whether you can get support for the issue you are facing." +msgstr "モジュールを使用し、バグを発見した場合は、そのバグの報告場所、修正を行う担当者、およびモジュールへの変更を追跡する方法を把握することが推奨されます。Red Hat のサブスクリプションをお持ちの場合は、アクセスする問題のサポートを取得できるかどうかを認識できます。" + +#: ../../rst/user_guide/modules_support.rst:9 +msgid "Starting in Ansible 2.10, most modules live in collections. The distribution method for each collection reflects the maintenance and support for the modules in that collection." +msgstr "Ansible 2.10 以降、ほとんどのモジュールはコレクションに存在します。各コレクションのディストリビューション方法は、そのコレクションのモジュールに対するメンテナンスとサポートを反映しています。" + +#: ../../rst/user_guide/modules_support.rst:15 +msgid "Maintenance" +msgstr "メンテナンス" + +#: ../../rst/user_guide/modules_support.rst:21 +msgid "Collection" +msgstr "コレクション" + +#: ../../rst/user_guide/modules_support.rst:21 +msgid "Code location" +msgstr "コードの場所" + +#: ../../rst/user_guide/modules_support.rst:21 +msgid "Maintained by" +msgstr "メンテナンス担当" + +#: ../../rst/user_guide/modules_support.rst:23 +msgid "ansible.builtin" +msgstr "ansible.builtin" + +#: ../../rst/user_guide/modules_support.rst:23 +msgid "`ansible/ansible repo`_ on GitHub" +msgstr "GitHub の `ansible/ansible repo`_" + +#: ../../rst/user_guide/modules_support.rst:23 +msgid "core team" +msgstr "core チーム" + +#: ../../rst/user_guide/modules_support.rst:25 +msgid "distributed on Galaxy" +msgstr "Galaxy への配布" + +#: ../../rst/user_guide/modules_support.rst:25 +#: ../../rst/user_guide/modules_support.rst:27 +msgid "various; follow ``repo`` link" +msgstr "さまざま。``repo`` リンクに従ってください。" + +#: ../../rst/user_guide/modules_support.rst:25 +msgid "community or partners" +msgstr "コミュニティーまたはパートナー" + +#: ../../rst/user_guide/modules_support.rst:27 +msgid "distributed on Automation Hub" +msgstr "Automation Hub への配布" + +#: ../../rst/user_guide/modules_support.rst:27 +msgid "content team or partners" +msgstr "コンテンツチームまたはパートナー" + +#: ../../rst/user_guide/modules_support.rst:33 +msgid "Issue Reporting" +msgstr "問題の報告" + +#: ../../rst/user_guide/modules_support.rst:35 +msgid "If you find a bug that affects a plugin in the main Ansible repo, also known as ``ansible-core``:" +msgstr "Ansible メインリポジトリー (``ansible-core`` とも知られている) のプラグインに影響するバグを見つけた場合は、以下を行います。" + +#: ../../rst/user_guide/modules_support.rst:37 +msgid "Confirm that you are running the latest stable version of Ansible or the devel branch." +msgstr "Ansible の最新の安定版または devel ブランチを実行していることを確認します。" + +#: ../../rst/user_guide/modules_support.rst:38 +msgid "Look at the `issue tracker in the Ansible repo <https://github.com/ansible/ansible/issues>`_ to see if an issue has already been filed." +msgstr "`Ansible リポジトリーの問題トラッカー <https://github.com/ansible/ansible/issues>`_ を確認して、問題がすでに報告されているかどうかを確認します。" + +#: ../../rst/user_guide/modules_support.rst:39 +#: ../../rst/user_guide/modules_support.rst:46 +msgid "Create an issue if one does not already exist. Include as much detail as you can about the behavior you discovered." +msgstr "問題が存在しない場合は、問題を作成してください。発見した動作について、できる限り詳細に記述してください。" + +#: ../../rst/user_guide/modules_support.rst:41 +msgid "If you find a bug that affects a plugin in a Galaxy collection:" +msgstr "Galaxy コレクションでプラグインに影響を与えるバグを見つけた場合は、以下を行います。" + +#: ../../rst/user_guide/modules_support.rst:43 +msgid "Find the collection on Galaxy." +msgstr "Galaxy のコレクションを見つけます。" + +#: ../../rst/user_guide/modules_support.rst:44 +msgid "Find the issue tracker for the collection." +msgstr "コレクションの問題トラッカーの検索" + +#: ../../rst/user_guide/modules_support.rst:45 +msgid "Look there to see if an issue has already been filed." +msgstr "問題がすでに報告されているかどうかを確認します。" + +#: ../../rst/user_guide/modules_support.rst:48 +msgid "Some partner collections may be hosted in private repositories." +msgstr "一部のパートナーコレクションは、プライベートリポジトリーでホストされる場合があります。" + +#: ../../rst/user_guide/modules_support.rst:50 +msgid "If you are not sure whether the behavior you see is a bug, if you have questions, if you want to discuss development-oriented topics, or if you just want to get in touch, use one of our Google mailing lists or chat channels (using Matrix at ansible.im or using IRC at `irc.libera.chat <https://libera.chat/>`_) to :ref:`communicate with Ansiblers <communication>`." +msgstr "ご覧になった動作がバグなのかどうかわからない場合、質問がある場合、開発関連のトピックについて議論したい場合、または単に連絡を取りたい場合は、Google メーリングリストまたはチャットチャンネル (ansible.im の Matrix または `irc.libera.chat <https://libera.chat/>`_ の IRC を使用) のいずれかを使用して :ref:`Ansible のメンバーにご連絡ください <communication>` ください。" + +#: ../../rst/user_guide/modules_support.rst:52 +msgid "If you find a bug that affects a module in an Automation Hub collection:" +msgstr "Automation Hub コレクションでモジュールに影響するバグを見つけた場合は、以下を行います。" + +#: ../../rst/user_guide/modules_support.rst:54 +msgid "If the collection offers an Issue Tracker link on Automation Hub, click there and open an issue on the collection repository. If it does not, follow the standard process for reporting issues on the `Red Hat Customer Portal <https://access.redhat.com/>`_. You must have a subscription to the Red Hat Ansible Automation Platform to create an issue on the portal." +msgstr "コレクションで Automation Hub 上の Issue Tracker リンクが提供されている場合、そこをクリックして、コレクションのリポジトリーに問題を作成します。指定していない場合は、`Red Hat カスタマーポータル <https://access.redhat.com/>`_ で問題を報告するための標準的なプロセスに従ってください。ポータルで問題を作成するには、Red Hat Ansible Automation Platform のサブスクリプションが必要です。" + +#: ../../rst/user_guide/modules_support.rst:57 +msgid "Support" +msgstr "サポート" + +#: ../../rst/user_guide/modules_support.rst:59 +msgid "All plugins that remain in ``ansible-core`` and all collections hosted in Automation Hub are supported by Red Hat. No other plugins or collections are supported by Red Hat. If you have a subscription to the Red Hat Ansible Automation Platform, you can find more information and resources on the `Red Hat Customer Portal. <https://access.redhat.com/>`_" +msgstr "``ansible-core`` にあるすべてのプラグインと、Automation Hub でホストされるすべてのプラグインは Red Hat によってサポートされます。その他のプラグインまたはコレクションは Red Hat ではサポートされません。Red Hat Ansible Automation Platform にサブスクリプションがある場合は、`Red Hat カスタマーポータル <https://access.redhat.com/>`_ に関する詳細情報とリソースを確認できます。" + +#: ../../rst/user_guide/playbook_pathing.rst:5 +msgid "Search paths in Ansible" +msgstr "Ansible でパスの検索" + +#: ../../rst/user_guide/playbook_pathing.rst:7 +msgid "You can control the paths Ansible searches to find resources on your control node (including configuration, modules, roles, ssh keys, and more) as well as resources on the remote nodes you are managing. Use absolute paths to tell Ansible where to find resources whenever you can. However, absolute paths are not always practical. This page covers how Ansible interprets relative search paths, along with ways to troubleshoot when Ansible cannot find the resource you need." +msgstr "Ansible がコントロールノード上のリソース (構成、モジュール、ロール、ssh キーなど) や、管理しているリモートノード上のリソースを検索する際のパスを制御できます。リソースを検索する場所を Ansible に伝えるには、可能な限り絶対パスを使用します。しかし、絶対パスは必ずしも実用的ではありません。このページでは、Ansible が相対検索パスをどのように解釈するか、また Ansible が必要なリソースを見つけられない場合のトラブルシューティングの方法について説明します。" + +#: ../../rst/user_guide/playbook_pathing.rst:13 +msgid "Config paths" +msgstr "設定パス" + +#: ../../rst/user_guide/playbook_pathing.rst:15 +msgid "By default these should be relative to the config file, some are specifically relative to the current working directory or the playbook and should have this noted in their description. Things like ssh keys are left to use the current working directory because it mirrors how the underlying tools would use it." +msgstr "デフォルトでは、これらは設定ファイルからの相対的なものですが、中には特に現在の作業ディレクトリーや Playbook からの相対的なものもあるため、説明にその旨を記載してください。ssh キーのようなものは、基本的なツールが使用する方法を反映するため、現在の作業ディレクトリーを使用するようになっています。" + +#: ../../rst/user_guide/playbook_pathing.rst:19 +msgid "Task paths" +msgstr "タスクパス" + +#: ../../rst/user_guide/playbook_pathing.rst:21 +msgid "Relative paths used in a task typically refer to remote files and directories on the managed nodes. However, paths passed to lookup plugins and some paths used in action plugins such as the \"src\" path for the :ref:`template <ansible_collections.ansible.builtin.template_module>` and :ref:`copy <ansible_collections.ansible.builtin.copy_module>` modules refer to local files and directories on the control node." +msgstr "タスクで使用される相対パスは通常、管理ノードのリモートファイルおよびディレクトリーを参照します。ただし、lookup プラグインに渡されるパスや、:ref:`template <ansible_collections.ansible.builtin.template_module>` モジュールおよび :ref:`copy <ansible_collections.ansible.builtin.copy_module>` モジュールの「src」パス等のアクションプラグインで使用される一部のパスは、コントロールノードのローカルファイルおよびディレクトリーを参照します。" + +#: ../../rst/user_guide/playbook_pathing.rst:24 +msgid "Resolving local relative paths" +msgstr "ローカル相対パスの解決" + +#: ../../rst/user_guide/playbook_pathing.rst:26 +msgid "When you specify a relative path for a local file, Ansible will try to find that file first in the current task's role, then in other roles that included or depend on the current role, then relative to the file in which the task is defined, and finally relative to the current play. It will take the first matching file that it finds. This way, if multiple files with the same filename exist, Ansible will find the file that is closest to the current task and that is most likely to be file you wanted." +msgstr "ローカルファイルの相対パスを指定する場合、Ansible は現在のタスクのロールでまずそのファイルを見つけようとします。次に、現在のロールに含まれる、または依存する他のロールで、次にタスクが定義されているファイルに相対的に、最後に現在のプレイに相対的に見つけようとします。これにより、最初に見つかったマッチするファイルが使用されます。したがって、同じファイル名を持つ複数のファイルが存在する場合、Ansible は現在のタスクにもっとも近く、希望のファイルである可能性が高いファイルを検索します。" + +#: ../../rst/user_guide/playbook_pathing.rst:28 +msgid "Specifically, Ansible tries to find the file" +msgstr "具体的には、Ansible は以下のようにファイルを検索しようとします" + +#: ../../rst/user_guide/playbook_pathing.rst:30 +msgid "In the current role." +msgstr "現在のロールで" + +#: ../../rst/user_guide/playbook_pathing.rst:32 +msgid "In its appropriate subdirectory—\"files\", \"vars\", \"templates\" or \"tasks\", depending on the kind of file Ansible is searching for." +msgstr "Ansible が検索するファイルの種類に応じて、適切なサブディレクトリー(「files」、「vars」、「templates」、または「tasks」)で" + +#: ../../rst/user_guide/playbook_pathing.rst:33 +msgid "Directly in its directory." +msgstr "そのディレクトリーに直接" + +#: ../../rst/user_guide/playbook_pathing.rst:35 +msgid "Like 1, in the parent role that called into this current role with `include_role`, `import_role`, or with a role dependency. If the parent role has its own parent role, Ansible will repeat this step with that role." +msgstr "1 と同様に、`include_role`、`import_role` またはロールの依存関係でこの現在のロールに呼び出される親ロールで。親ロールに独自の親ロールがある場合は、Ansible はそのロールでこの手順を繰り返します。" + +#: ../../rst/user_guide/playbook_pathing.rst:36 +msgid "Like 1, in the current task file's directory." +msgstr "1 と同様に、現在のタスクファイルのディレクトリーで" + +#: ../../rst/user_guide/playbook_pathing.rst:37 +msgid "Like 1, in the current play file's directory." +msgstr "1 と同様に、現在の play ファイルのディレクトリーで" + +#: ../../rst/user_guide/playbook_pathing.rst:39 +msgid "Ansible does not search the current working directory. (The directory you're in when you execute Ansible.) Also, Ansible will only search within a role if you actually included it with an `include_role` or `import_role` task or a dependency. If you instead use `include`, `include_task` or `import_task` to include just the tasks from a specific file but not the full role, Ansible will not search that role in steps 1 and 2." +msgstr "Ansible は、現在の作業ディレクトリー(Ansibleを実行する時のディレクトリー)を検索しません。また、`include_role` または `import_role` タスクまたは依存関係で実際に含めた場合、Ansible はロール内のみ検索します。代わりに、`include`、`include_task`、または `import_task` を使用して、完全なロールではなく特定のファイルからのタスクだけを含める場合、Ansible はステップ1および2でそのロールを検索しません。" + +#: ../../rst/user_guide/playbook_pathing.rst:41 +msgid "When you execute Ansible, the variable `ansible_search_path` will contain the paths searched, in the order they were searched in but without listing their subdirectories. If you run Ansible in verbosity level 5 by passing the `-vvvvv` argument, Ansible will report each directory as it searches, except when it searches for a tasks file." +msgstr "Ansible を実行すると、変数 `ansible_search_path` には、検索されたパスが検索された順に含まれますが、そのサブディレクトリーは一覧表示されません。`-vvvvv` 引数を渡して詳細レベル5でAnsible を実行すると、タスクファイルを検索した場合を除き、Ansible は検索した順に各ディレクトリーを報告します。" + +#: ../../rst/user_guide/playbook_pathing.rst:44 +msgid "The current working directory might vary depending on the connection plugin and if the action is local or remote. For the remote it is normally the directory on which the login shell puts the user. For local it is either the directory you executed ansible from or in some cases the playbook directory." +msgstr "現在の作業ディレクトリは、接続プラグインと、アクションがローカルかリモートかによって異なる場合があります。リモートの場合、通常、ログインシェルがユーザーを配置するディレクトリになります。ローカルの場合は、ansibleを実行したディレクトリか、場合によってはPlaybokディレクトリになります。" + +#: ../../rst/user_guide/playbooks.rst:4 +msgid "Working with playbooks" +msgstr "Playbook の操作" + +#: ../../rst/user_guide/playbooks.rst:6 +msgid "Playbooks record and execute Ansible's configuration, deployment, and orchestration functions. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process." +msgstr "Playbook は、Ansible の設定、デプロイメント、オーケストレーション機能を記録して実行します。リモートシステムを強制するポリシーや、一般的な IT プロセスで一連の手順を説明することができます。" + +#: ../../rst/user_guide/playbooks.rst:8 +msgid "If Ansible modules are the tools in your workshop, playbooks are your instruction manuals, and your inventory of hosts are your raw material." +msgstr "Ansible モジュールがワークショップのツールである場合、Playbook は手順のマニュアルにあり、ホストのインベントリーは実際のマテリアルになります。" + +#: ../../rst/user_guide/playbooks.rst:10 +msgid "At a basic level, playbooks can be used to manage configurations of and deployments to remote machines. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way." +msgstr "基本的なレベルでは、Playbook を使用して、リモートマシンの設定およびリモートマシンへのデプロイメントを管理できます。より高度なレベルでは、ローリングアップデートに関連する複数層のロールアウトを分類し、他のホストにアクションを委譲して、監視サーバーやロードバランサーと対話できます。" + +#: ../../rst/user_guide/playbooks.rst:12 +msgid "Playbooks are designed to be human-readable and are developed in a basic text language. There are multiple ways to organize playbooks and the files they include, and we'll offer up some suggestions on that and making the most out of Ansible." +msgstr "Playbook は人間が判読可能で、基本的なテキスト言語で開発されるように設計されています。Playbook と、Playbook に含まれるファイルを整理する方法は複数あり、その方法と、Ansible を最大限に活用するための提案を行います。" + +#: ../../rst/user_guide/playbooks.rst:14 +msgid "You should look at `Example Playbooks <https://github.com/ansible/ansible-examples>`_ while reading along with the playbook documentation. These illustrate best practices as well as how to put many of the various concepts together." +msgstr "Playbook ドキュメントと一緒に、「`Example Playbooks <https://github.com/ansible/ansible-examples>`_」を参照してください。ここでは、ベストプラクティスや、さまざまな概念をまとめて配置する方法を説明します。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:5 +msgid "Advanced Syntax" +msgstr "高度な構文" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:7 +msgid "The advanced YAML syntax examples on this page give you more control over the data placed in YAML files used by Ansible. You can find additional information about Python-specific YAML in the official `PyYAML Documentation <https://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes>`_." +msgstr "このページの高度な YAML 構文の例では、Ansible が使用する YAML ファイルに配置されるデータをより細かく制御できます。Python 固有の YAML に関する追加情報は、公式の `PyYAML ドキュメント <https://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes>`_ でご覧いただけます。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:15 +msgid "Unsafe or raw strings" +msgstr "安全でない文字列または生の文字列" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:17 +#, python-format +msgid "When handling values returned by lookup plugins, Ansible uses a data type called ``unsafe`` to block templating. Marking data as unsafe prevents malicious users from abusing Jinja2 templates to execute arbitrary code on target machines. The Ansible implementation ensures that unsafe values are never templated. It is more comprehensive than escaping Jinja2 with ``{% raw %} ... {% endraw %}`` tags." +msgstr "lookup プラグインから返される値を処理する際、Ansible は ``unsafe`` というデータタイプを使用してテンプレートをブロックします。データを安全ではないとマークすることで、悪意のあるユーザーが Jinja2 のテンプレートを悪用してターゲットマシンで任意のコードを実行することを防ぎます。Ansible の実装では、安全でない値が決してテンプレート化されないようにしています。``{% raw %} ... {% endraw %}`` タグで Jinja2 をエスケープするよりも包括的です。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:19 +msgid "You can use the same ``unsafe`` data type in variables you define, to prevent templating errors and information disclosure. You can mark values supplied by :ref:`vars_prompts<unsafe_prompts>` as unsafe. You can also use ``unsafe`` in playbooks. The most common use cases include passwords that allow special characters like ``{`` or ``%``, and JSON arguments that look like templates but should not be templated. For example:" +msgstr "定義した変数に同じ ``unsafe`` データ型を使用すると、テンプレートエラーや情報の漏えいを防ぐことができます。:ref:`vars_prompts<unsafe_prompts>` により提供された値を安全でないものとしてマーク付けできます。Playbook で ``unsafe`` を使用することもできます。最も一般的なユースケースには、テンプレートのような ``{`` や ``%`` などの特殊文字を許可するパスワードが含まれていますが、テンプレート化すべきではありません。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:26 +msgid "In a playbook:" +msgstr "Playbook の場合は、以下のようになります。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:37 +msgid "For complex variables such as hashes or arrays, use ``!unsafe`` on the individual elements:" +msgstr "ハッシュや配列などの複雑な変数の場合は、個々の要素で ``!unsafe`` を使用します。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:52 +msgid "YAML anchors and aliases: sharing variable values" +msgstr "YAML アンカーおよびエイリアス: 変数値の共有" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:54 +msgid "`YAML anchors and aliases <https://yaml.org/spec/1.2/spec.html#id2765878>`_ help you define, maintain, and use shared variable values in a flexible way. You define an anchor with ``&``, then refer to it using an alias, denoted with ``*``. Here's an example that sets three values with an anchor, uses two of those values with an alias, and overrides the third value:" +msgstr "`YAML アンカーおよびエイリアス <https://yaml.org/spec/1.2/spec.html#id2765878>`_ は、柔軟な方法で共有変数の値を定義、維持、および使用するのに役立ちます。``&`` でアンカーを定義し、``*`` で示すエイリアスを使用して参照します。ここでは、アンカーで 3 つの値を設定し、エイリアスでこれらの値を 2 つ使用し、3 番目の値を上書きする例を以下に示します。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:73 +msgid "Here, ``app1`` and ``app2`` share the values for ``opts`` and ``port`` using the anchor ``&jvm_opts`` and the alias ``*jvm_opts``. The value for ``path`` is merged by ``<<`` or `merge operator <https://yaml.org/type/merge.html>`_." +msgstr "ここで、``app1`` および ``app2`` は、アンカー ``&jvm_opts`` およびエイリアス ``*jvm_opts`` を使用して、``opts`` と ``port`` の値を共有します。``path`` の値は、``<<`` または `merge operator <https://yaml.org/type/merge.html>`_ によってマージされます。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:76 +msgid "Anchors and aliases also let you share complex sets of variable values, including nested variables. If you have one variable value that includes another variable value, you can define them separately:" +msgstr "アンカーおよびエイリアスを使用すると、入れ子になった変数など、複雑な変数値のセットを共有することもできます。ある変数値に別の変数値が含まれている場合は、その変数値を別々に定義することができます。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:84 +msgid "This is inefficient and, at scale, means more maintenance. To incorporate the version value in the name, you can use an anchor in ``app_version`` and an alias in ``custom_name``:" +msgstr "これは非効率的であり、大規模な場合には、より多くのメンテナンスが行われます。名前に version の値を組み込むには、``app_version`` にアンカーと、``custom_name`` のエイリアスを使用できます。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:95 +msgid "Now, you can re-use the value of ``app_version`` within the value of ``custom_name`` and use the output in a template:" +msgstr "これで、``custom_name`` の値の ``app_version`` の値を再利用し、テンプレートで出力を使用できます。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:113 +msgid "You've anchored the value of ``version`` with the ``&my_version`` anchor, and re-used it with the ``*my_version`` alias. Anchors and aliases let you access nested values inside dictionaries." +msgstr "``version`` の値を ``&my_version`` というアンカーで固定し、``*my_version`` というエイリアスで再利用しています。アンカーとエイリアスを使用することで、ディクショナリー内のネストした値にアクセスすることができます。" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:118 +#: ../../rst/user_guide/playbooks_conditionals.rst:532 +#: ../../rst/user_guide/playbooks_error_handling.rst:275 +#: ../../rst/user_guide/playbooks_filters.rst:2182 +#: ../../rst/user_guide/playbooks_lookups.rst:33 +#: ../../rst/user_guide/playbooks_loops.rst:485 +#: ../../rst/user_guide/playbooks_prompts.rst:120 +#: ../../rst/user_guide/playbooks_tests.rst:514 +msgid "All about variables" +msgstr "変数の詳細" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:119 +msgid ":ref:`complex_data_manipulation`" +msgstr ":ref:`complex_data_manipulation`" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:120 +msgid "Doing complex data manipulation in Ansible" +msgstr "Ansible での複雑なデータ操作の実行" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:121 +#: ../../rst/user_guide/windows_dsc.rst:503 +#: ../../rst/user_guide/windows_faq.rst:254 +#: ../../rst/user_guide/windows_setup.rst:575 +#: ../../rst/user_guide/windows_usage.rst:514 +#: ../../rst/user_guide/windows_winrm.rst:1006 +msgid "`User Mailing List <https://groups.google.com/group/ansible-project>`_" +msgstr "`メーリングリストの使用 <https://groups.google.com/group/ansible-project>`_" + +#: ../../rst/user_guide/playbooks_advanced_syntax.rst:122 +#: ../../rst/user_guide/playbooks_async.rst:187 +#: ../../rst/user_guide/playbooks_blocks.rst:187 +#: ../../rst/user_guide/playbooks_conditionals.rst:534 +#: ../../rst/user_guide/playbooks_debugger.rst:340 +#: ../../rst/user_guide/playbooks_delegation.rst:172 +#: ../../rst/user_guide/playbooks_environment.rst:151 +#: ../../rst/user_guide/playbooks_error_handling.rst:277 +#: ../../rst/user_guide/playbooks_filters.rst:2190 +#: ../../rst/user_guide/playbooks_lookups.rst:37 +#: ../../rst/user_guide/playbooks_loops.rst:487 +#: ../../rst/user_guide/playbooks_prompts.rst:122 +#: ../../rst/user_guide/playbooks_strategies.rst:252 +#: ../../rst/user_guide/playbooks_tags.rst:430 +#: ../../rst/user_guide/playbooks_templating.rst:59 +#: ../../rst/user_guide/playbooks_tests.rst:522 +#: ../../rst/user_guide/playbooks_variables.rst:510 +#: ../../rst/user_guide/windows_dsc.rst:504 +#: ../../rst/user_guide/windows_faq.rst:255 +#: ../../rst/user_guide/windows_setup.rst:576 +#: ../../rst/user_guide/windows_usage.rst:515 +#: ../../rst/user_guide/windows_winrm.rst:1007 +msgid "Have a question? Stop by the google group!" +msgstr "ご質問はございますか。Google Group をご覧ください。" + +#: ../../rst/user_guide/playbooks_async.rst:4 +msgid "Asynchronous actions and polling" +msgstr "非同期アクションおよびポーリング" + +#: ../../rst/user_guide/playbooks_async.rst:6 +msgid "By default Ansible runs tasks synchronously, holding the connection to the remote node open until the action is completed. This means within a playbook, each task blocks the next task by default, meaning subsequent tasks will not run until the current task completes. This behavior can create challenges. For example, a task may take longer to complete than the SSH session allows for, causing a timeout. Or you may want a long-running process to execute in the background while you perform other tasks concurrently. Asynchronous mode lets you control how long-running tasks execute." +msgstr "デフォルトでは、Ansible はタスクを同期的に実行し、アクションが完了するまでリモートノードへの接続を維持します。つまり、Playbook 内では、デフォルトでは各タスクが次のタスクをブロックし、現在のタスクが完了するまで後続のタスクが実行されないことになります。この動作には課題があります。たとえば、あるタスクが SSH セッションの許容範囲を超えて完了するのに時間がかかり、タイムアウトが発生する場合があります。また、他のタスクを同時に実行している間、長時間実行するプロセスをバックグラウンドで実行したい場合もあります。非同期モードでは、長時間実行するタスクの実行方法を制御することができます。" + +#: ../../rst/user_guide/playbooks_async.rst:12 +msgid "Asynchronous ad hoc tasks" +msgstr "非同期アドホックタスク" + +#: ../../rst/user_guide/playbooks_async.rst:14 +msgid "You can execute long-running operations in the background with :ref:`ad hoc tasks <intro_adhoc>`. For example, to execute ``long_running_operation`` asynchronously in the background, with a timeout (``-B``) of 3600 seconds, and without polling (``-P``):" +msgstr ":ref:`アドホックタスク <intro_adhoc>` を使用すると、バックグラウンドで長時間実行される操作を実行することができます。たとえば、``long_running_operation`` をバックグラウンドで非同期的に実行し、タイムアウト (``-B``) を 3600 秒に設定し、ポーリング (``-P``) を行わない場合は次のようになります。" + +#: ../../rst/user_guide/playbooks_async.rst:20 +msgid "To check on the job status later, use the ``async_status`` module, passing it the job ID that was returned when you ran the original job in the background:" +msgstr "後でジョブステータスを確認するには、``async_status`` モジュールを使用し、バックグラウンドで元のジョブの実行時に返されたジョブ ID を渡します。" + +#: ../../rst/user_guide/playbooks_async.rst:26 +msgid "Ansible can also check on the status of your long-running job automatically with polling. In most cases, Ansible will keep the connection to your remote node open between polls. To run for 30 minutes and poll for status every 60 seconds:" +msgstr "Ansible は、ポーリングによって長時間実行するジョブの状態を自動的に確認することもできます。ほとんどの場合、Ansible はポーリングの間もリモートノードへの接続を維持します。30 分間実行し、60 秒ごとにステータスをポーリングするには次のようにします。" + +#: ../../rst/user_guide/playbooks_async.rst:32 +msgid "Poll mode is smart so all jobs will be started before polling begins on any machine. Be sure to use a high enough ``--forks`` value if you want to get all of your jobs started very quickly. After the time limit (in seconds) runs out (``-B``), the process on the remote nodes will be terminated." +msgstr "ポーリングモードは高性能であるため、どのマシンでもポーリングが開始する前にすべてのジョブが開始します。すべてのジョブを非常に迅速に開始したい場合は ``--forks`` を十分な高さにしてください。制限時間 (秒単位) がなくなると (``-B``)、リモートノードのプロセスは終了します。" + +#: ../../rst/user_guide/playbooks_async.rst:34 +msgid "Asynchronous mode is best suited to long-running shell commands or software upgrades. Running the copy module asynchronously, for example, does not do a background file transfer." +msgstr "非同期モードは、長時間実行するシェルコマンドやソフトウェアのアップグレードに最適です。たとえば、copy モジュールを非同期で実行しても、バックグラウンドでのファイル転送は行われません。" + +#: ../../rst/user_guide/playbooks_async.rst:37 +msgid "Asynchronous playbook tasks" +msgstr "非同期 Playbook タスク" + +#: ../../rst/user_guide/playbooks_async.rst:39 +msgid ":ref:`Playbooks <working_with_playbooks>` also support asynchronous mode and polling, with a simplified syntax. You can use asynchronous mode in playbooks to avoid connection timeouts or to avoid blocking subsequent tasks. The behavior of asynchronous mode in a playbook depends on the value of `poll`." +msgstr ":ref:`Playbook <working_with_playbooks>` は、非同期モードとポーリングもサポートしており、構文も簡素化されています。非同期モードを Playbook で使用すると、接続のタイムアウトや、後続タスクのブロックを回避できます。Playbook での非同期モードの動作は、`poll` の値に依存します。" + +#: ../../rst/user_guide/playbooks_async.rst:42 +msgid "Avoid connection timeouts: poll > 0" +msgstr "接続のタイムアウトの回避: poll > 0" + +#: ../../rst/user_guide/playbooks_async.rst:44 +msgid "If you want to set a longer timeout limit for a certain task in your playbook, use ``async`` with ``poll`` set to a positive value. Ansible will still block the next task in your playbook, waiting until the async task either completes, fails or times out. However, the task will only time out if it exceeds the timeout limit you set with the ``async`` parameter." +msgstr "Playbook 内の特定のタスクにより長いタイムアウト制限を設定する場合は、``async`` を使用し、``poll`` を正の値に設定します。Ansible は、Playbook 内に記載される次のタスクをブロックし、非同期タスクが完了するか、失敗するか、タイムアウトになるまで待機します。ただし、タスクがタイムアウトになるのは、``async`` パラメーターで設定したタイムアウト制限を超えた場合のみです。" + +#: ../../rst/user_guide/playbooks_async.rst:46 +msgid "To avoid timeouts on a task, specify its maximum runtime and how frequently you would like to poll for status:" +msgstr "タスクでタイムアウトを回避するには、最大ランタイムとステータスをポーリングする頻度を指定します。" + +#: ../../rst/user_guide/playbooks_async.rst:63 +msgid "The default poll value is set by the :ref:`DEFAULT_POLL_INTERVAL` setting. There is no default for the async time limit. If you leave off the 'async' keyword, the task runs synchronously, which is Ansible's default." +msgstr "デフォルトのポール値は、:ref:`DEFAULT_POLL_INTERVAL` の設定で設定されます。非同期時間制限のデフォルトはありません。「async」キーワードを省略すると、タスクは同期的に実行されます。これが Ansible のデフォルトです。" + +#: ../../rst/user_guide/playbooks_async.rst:69 +msgid "As of Ansible 2.3, async does not support check mode and will fail the task when run in check mode. See :ref:`check_mode_dry` on how to skip a task in check mode." +msgstr "Ansible 2.3 の時点では、非同期はチェックモードをサポートしておらず、チェックモードで実行するとタスクが失敗します。チェックモードでタスクをスキップする方法は、「:ref:`check_mode_dry`」を参照してください。" + +#: ../../rst/user_guide/playbooks_async.rst:74 +msgid "When an async task completes with polling enabled, the temporary async job cache file (by default in ~/.ansible_async/) is automatically removed." +msgstr "ポーリングを有効にして非同期タスクが完了すると、一時的な非同期ジョブキャッシュファイル (デフォルトでは ~/.ansible_async/ にある) が自動的に削除されます。" + +#: ../../rst/user_guide/playbooks_async.rst:78 +msgid "Run tasks concurrently: poll = 0" +msgstr "タスクの同時実行: poll = 0" + +#: ../../rst/user_guide/playbooks_async.rst:80 +msgid "If you want to run multiple tasks in a playbook concurrently, use ``async`` with ``poll`` set to 0. When you set ``poll: 0``, Ansible starts the task and immediately moves on to the next task without waiting for a result. Each async task runs until it either completes, fails or times out (runs longer than its ``async`` value). The playbook run ends without checking back on async tasks." +msgstr "Playbook 内の複数のタスクを同時に実行する場合は、``async`` を使用し、``poll`` を 0 に設定します。``poll: 0`` を設定すると、Ansible はタスクを開始し、結果を待たずに直ちに次のタスクに移ります。各非同期タスクは、完了するか、失敗するか、タイムアウトにする (``async`` の値よりも長く実行される) まで実行されます。Playbook の実行は、非同期タスクを再度チェックせずに終了します。" + +#: ../../rst/user_guide/playbooks_async.rst:82 +msgid "To run a playbook task asynchronously:" +msgstr "Playbook タスクを非同期的に実行するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_async.rst:99 +msgid "Do not specify a poll value of 0 with operations that require exclusive locks (such as yum transactions) if you expect to run other commands later in the playbook against those same resources." +msgstr "排他的ロックを必要とする操作 (yum トランザクションなど) では、同じリソースに対して Playbook の後半で他のコマンドを実行することを想定して、poll 値に 0 を指定しないでください。" + +#: ../../rst/user_guide/playbooks_async.rst:102 +msgid "Using a higher value for ``--forks`` will result in kicking off asynchronous tasks even faster. This also increases the efficiency of polling." +msgstr "``--forks`` の値を増やすと、非同期タスクの開始が速くなります。これにより、ポーリングの効率が高まります。" + +#: ../../rst/user_guide/playbooks_async.rst:105 +msgid "When running with ``poll: 0``, Ansible will not automatically cleanup the async job cache file. You will need to manually clean this up with the :ref:`async_status <async_status_module>` module with ``mode: cleanup``." +msgstr "``poll: 0`` で実行すると、Ansible は非同期ジョブキャッシュファイルを自動的にクリーンアップしません。``mode: cleanup`` で :ref:`async_status <async_status_module>` モジュールを使用して手動でクリーンアップする必要があります。" + +#: ../../rst/user_guide/playbooks_async.rst:109 +msgid "If you need a synchronization point with an async task, you can register it to obtain its job ID and use the :ref:`async_status <async_status_module>` module to observe it in a later task. For example:" +msgstr "非同期タスクとの同期ポイントが必要な場合は、これを登録してジョブ ID を取得し、:ref:`async_status <async_status_module>` モジュールを使用して後続のタスクで確認することができます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_async.rst:130 +msgid "If the value of ``async:`` is not high enough, this will cause the \"check on it later\" task to fail because the temporary status file that the ``async_status:`` is looking for will not have been written or no longer exist" +msgstr "``async:`` の値が十分に高くない場合は、``async_status:`` が探している一時的なステータスファイルが書き込まれていないか、存在しなくなったため、「後で確認する」タスクが失敗することになります。" + +#: ../../rst/user_guide/playbooks_async.rst:135 +msgid "Asynchronous playbook tasks always return changed. If the task is using a module that requires the user to annotate changes with ``changed_when``, ``creates``, and so on, then those should be added to the following ``async_status`` task." +msgstr "非同期 Playbook タスクは常に変更を返します。タスクが、ユーザーが ``changed_when`` および ``creates`` を使用して変更にアノテーションを付ける必要があるモジュールを使用している場合は、それらのタスクを以下の ``async_status`` タスクに追加する必要があります。" + +#: ../../rst/user_guide/playbooks_async.rst:139 +msgid "To run multiple asynchronous tasks while limiting the number of tasks running concurrently:" +msgstr "複数の非同期タスクを実行しながら、同時に実行するタスクの数を制限するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_async.rst:182 +#: ../../rst/user_guide/playbooks_delegation.rst:167 +msgid ":ref:`playbooks_strategies`" +msgstr ":ref:`playbooks_strategies`" + +#: ../../rst/user_guide/playbooks_async.rst:183 +msgid "Options for controlling playbook execution" +msgstr "Playbook の実行を制御するオプション" + +#: ../../rst/user_guide/playbooks_async.rst:186 +#: ../../rst/user_guide/playbooks_blocks.rst:186 +#: ../../rst/user_guide/playbooks_conditionals.rst:533 +#: ../../rst/user_guide/playbooks_debugger.rst:339 +#: ../../rst/user_guide/playbooks_delegation.rst:171 +#: ../../rst/user_guide/playbooks_environment.rst:150 +#: ../../rst/user_guide/playbooks_error_handling.rst:276 +#: ../../rst/user_guide/playbooks_filters.rst:2189 +#: ../../rst/user_guide/playbooks_lookups.rst:36 +#: ../../rst/user_guide/playbooks_loops.rst:486 +#: ../../rst/user_guide/playbooks_prompts.rst:121 +#: ../../rst/user_guide/playbooks_strategies.rst:251 +#: ../../rst/user_guide/playbooks_tags.rst:429 +#: ../../rst/user_guide/playbooks_templating.rst:58 +#: ../../rst/user_guide/playbooks_tests.rst:521 +#: ../../rst/user_guide/playbooks_variables.rst:509 +msgid "`User Mailing List <https://groups.google.com/group/ansible-devel>`_" +msgstr "`メーリングリストの使用 <https://groups.google.com/group/ansible-devel>`_" + +#: ../../rst/user_guide/playbooks_best_practices.rst:6 +msgid "Tips and tricks" +msgstr "ヒントと裏技" + +#: ../../rst/user_guide/playbooks_best_practices.rst:8 +msgid "These tips and tricks have helped us optimize our Ansible usage, and we offer them here as suggestions. We hope they will help you organize content, write playbooks, maintain inventory, and execute Ansible. Ultimately, though, you should use Ansible in the way that makes most sense for your organization and your goals." +msgstr "これらのヒントとコツは、Ansible の使用法を最適化するのに役に立ったため、提案としてここに示します。コンテンツの整理、Playbook の作成、インベントリーの維持、Ansible の実行に役立つことを願っています。ただし、最終的には、自身の組織と目標に最も適した方法で Ansible を使用する必要があります。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:14 +msgid "General tips" +msgstr "一般的なヒント" + +#: ../../rst/user_guide/playbooks_best_practices.rst:16 +msgid "These concepts apply to all Ansible activities and artifacts." +msgstr "この概念は、すべての Ansible アクティビティーおよびアーティファクトに適用されます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:19 +msgid "Keep it simple" +msgstr "シンプルのままにする" + +#: ../../rst/user_guide/playbooks_best_practices.rst:21 +msgid "Whenever you can, do things simply. Use advanced features only when necessary, and select the feature that best matches your use case. For example, you will probably not need ``vars``, ``vars_files``, ``vars_prompt`` and ``--extra-vars`` all at once, while also using an external inventory file. If something feels complicated, it probably is. Take the time to look for a simpler solution." +msgstr "できる限りシンプルに。高度な機能は必要な場合にのみ使用し、自身のユースケースに最も一致した機能を選択してください。たとえば、外部のインベントリーファイルを使用しながら、``vars``、``vars_files``、``vars_prompt``、および ``--extra-vars`` を一度に使用することはないでしょう。何かが複雑に感じられる場合は、おそらく複雑なのです。時間をかけて、よりシンプルなソリューションを探してみてください。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:24 +msgid "Use version control" +msgstr "バージョン制御を使用する" + +#: ../../rst/user_guide/playbooks_best_practices.rst:26 +msgid "Keep your playbooks, roles, inventory, and variables files in git or another version control system and make commits to the repository when you make changes. Version control gives you an audit trail describing when and why you changed the rules that automate your infrastructure." +msgstr "Playbook、ロール、インベントリー、変数などのファイルを git などのバージョン管理システムで管理し、変更があった場合はリポジトリーにコミットします。バージョン管理は、インフラストラクチャーを自動化するルールをいつ、なぜ変更したかを示す監査証跡となります。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:29 +msgid "Customize the CLI output" +msgstr "CLI 出力のカスタマイズ" + +#: ../../rst/user_guide/playbooks_best_practices.rst:31 +msgid "You can change the output from Ansible CLI commands using :ref:`callback_plugins`." +msgstr ":ref:`callback_plugins` を使用して、Ansible CLI コマンドからの出力を変更できます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:35 +msgid "Playbook tips" +msgstr "Playbook のヒント" + +#: ../../rst/user_guide/playbooks_best_practices.rst:37 +msgid "These tips help make playbooks and roles easier to read, maintain, and debug." +msgstr "このヒントは、Playbook とロールの読み取り、維持、およびデバッグを容易にするのに役立ちます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:40 +msgid "Use whitespace" +msgstr "空白を使用する" + +#: ../../rst/user_guide/playbooks_best_practices.rst:42 +msgid "Generous use of whitespace, for example, a blank line before each block or task, makes a playbook easy to scan." +msgstr "各ブロックやタスクの前に空の行など、空白を使用すると Playbook を簡単にスキャンできます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:45 +msgid "Always name tasks" +msgstr "常にタスクに名前を付ける" + +#: ../../rst/user_guide/playbooks_best_practices.rst:47 +msgid "Task names are optional, but extremely useful. In its output, Ansible shows you the name of each task it runs. Choose names that describe what each task does and why." +msgstr "タスク名は任意ですが、非常に便利なものになります。その出力で、Ansible では、実行する各タスクの名前が記載されます。各タスクの機能や理由を説明する名前を選択します。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:50 +msgid "Always mention the state" +msgstr "状態について常に言及する" + +#: ../../rst/user_guide/playbooks_best_practices.rst:52 +msgid "For many modules, the 'state' parameter is optional. Different modules have different default settings for 'state', and some modules support several 'state' settings. Explicitly setting 'state=present' or 'state=absent' makes playbooks and roles clearer." +msgstr "多くのモジュールでは、「state」パラメーターは任意です。モジュールによって「state」のデフォルト設定は異なり、複数の「state」設定をサポートしているモジュールもあります。「state=present」や「state=absent」を明示的に設定することで、Playbook やロールがより明確になります。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:55 +msgid "Use comments" +msgstr "コマンドを使用する" + +#: ../../rst/user_guide/playbooks_best_practices.rst:57 +msgid "Even with task names and explicit state, sometimes a part of a playbook or role (or inventory/variable file) needs more explanation. Adding a comment (any line starting with '#') helps others (and possibly yourself in future) understand what a play or task (or variable setting) does, how it does it, and why." +msgstr "タスク名や状態が明示されていても、Playbook やロール (またはインベントリー/変数ファイル) の一部にさらに説明が必要な場合があります。コメント (「#」で始まる行) を追加することで、プレイやタスク (または変数設定) が何をどのように行うのか、またその理由を他のユーザー (そして将来的には自分自身) が理解するのに役立ちます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:60 +msgid "Inventory tips" +msgstr "インベントリーのヒント" + +#: ../../rst/user_guide/playbooks_best_practices.rst:62 +msgid "These tips help keep your inventory well organized." +msgstr "これらのヒントは、インベントリーを十分に整理するのに役に立ちます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:65 +msgid "Use dynamic inventory with clouds" +msgstr "クラウドでの動的インベントリーの使用" + +#: ../../rst/user_guide/playbooks_best_practices.rst:67 +msgid "With cloud providers and other systems that maintain canonical lists of your infrastructure, use :ref:`dynamic inventory <intro_dynamic_inventory>` to retrieve those lists instead of manually updating static inventory files. With cloud resources, you can use tags to differentiate production and staging environments." +msgstr "クラウドプロバイダーやその他のシステムがインフラストラクチャーの正規のリストを管理している場合は、静的なインベントリーファイルを手動で更新する代わりに、:ref:`動的インベントリー <intro_dynamic_inventory>` を使用してこれらのリストを取得します。クラウドリソースでは、タグを使用して本番環境とステージング環境を区別することができます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:70 +msgid "Group inventory by function" +msgstr "機能別にインベントリーのグループ化" + +#: ../../rst/user_guide/playbooks_best_practices.rst:72 +msgid "A system can be in multiple groups. See :ref:`intro_inventory` and :ref:`intro_patterns`. If you create groups named for the function of the nodes in the group, for example *webservers* or *dbservers*, your playbooks can target machines based on function. You can assign function-specific variables using the group variable system, and design Ansible roles to handle function-specific use cases. See :ref:`playbooks_reuse_roles`." +msgstr "1 つのシステムは複数のグループに属することができます。「:ref:`intro_inventory`」および「:ref:`intro_patterns`」を参照してください。*webservers*、*dbservers* など、グループ内のノードの機能に応じた名前のグループを作成すると、Playbook で機能に応じてマシンをターゲットにすることができます。グループ変数システムを使用して機能固有の変数を割り当て、機能固有のユースケースを処理するために Ansible ロールを設計することができます。「:ref:`playbooks_reuse_roles`」を参照してください。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:75 +msgid "Separate production and staging inventory" +msgstr "別個の実稼働およびステージングのインベントリー" + +#: ../../rst/user_guide/playbooks_best_practices.rst:77 +msgid "You can keep your production environment separate from development, test, and staging environments by using separate inventory files or directories for each environment. This way you pick with -i what you are targeting. Keeping all your environments in one file can lead to surprises! For example, all vault passwords used in an inventory need to be available when using that inventory. If an inventory contains both production and development environments, developers using that inventory would be able to access production secrets." +msgstr "実稼働を開発環境、テスト環境、ステージング環境から分離するには、それぞれの環境に個別のインベントリーファイルまたはディレクトリーを使用します。この方法では、-i で対象となるものを選ぶことができます。すべての環境を 1 つのファイルにまとめておくと、驚くようなことが起こります。たとえば、インベントリーで使用するすべての Vault パスワードは、そのインベントリーの使用時に利用可能でなければなりません。インベントリーに実稼働環境と開発環境の両方が含まれる場合、そのインベントリーを使用する開発者は実稼働シークレットにアクセスできます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:82 +msgid "Keep vaulted variables safely visible" +msgstr "Vault 処理された変数を安全に表示" + +#: ../../rst/user_guide/playbooks_best_practices.rst:84 +msgid "You should encrypt sensitive or secret variables with Ansible Vault. However, encrypting the variable names as well as the variable values makes it hard to find the source of the values. To circumvent this, you can encrypt the variables individually using ``ansible-vault encrypt_string``, or add the following layer of indirection to keep the names of your variables accessible (by ``grep``, for example) without exposing any secrets:" +msgstr "機密性の高い変数や秘密の変数は、Ansible Vault で暗号化する必要があります。しかし、変数名だけでなく変数の値も暗号化すると、どこから値を取得しているかを見つけるのが難しくなります。これを回避するには、``ansible-vault encrypt_string``を使用して変数を個別に暗号化するか、以下の間接層を追加して、秘密を公開することなく、変数の名前を (たとえば ``grep`` で) アクセスできる状態に維持することができます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:86 +msgid "Create a ``group_vars/`` subdirectory named after the group." +msgstr "グループの名前が付けられた ``group_vars/`` サブディレクトリーを作成します。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:87 +msgid "Inside this subdirectory, create two files named ``vars`` and ``vault``." +msgstr "このサブディレクトリー内に、``vars`` と ``vault`` という名前のファイルを作成します。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:88 +msgid "In the ``vars`` file, define all of the variables needed, including any sensitive ones." +msgstr "``vars`` ファイルで、機密性の高い変数など、必要な変数をすべて定義します。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:89 +msgid "Copy all of the sensitive variables over to the ``vault`` file and prefix these variables with ``vault_``." +msgstr "すべての機密変数を ``vault`` ファイルにコピーし、この変数の前に ``vault_`` を付けます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:90 +msgid "Adjust the variables in the ``vars`` file to point to the matching ``vault_`` variables using jinja2 syntax: ``db_password: {{ vault_db_password }}``." +msgstr "jinja2 構文を使用して一致する ``vault_`` 変数を参照するように、``vars`` ファイルの変数を調整します (``db_password: {{ vault_db_password }}``)。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:91 +msgid "Encrypt the ``vault`` file to protect its contents." +msgstr "``vault`` ファイルを暗号化することで、そのコンテンツを保護します。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:92 +msgid "Use the variable name from the ``vars`` file in your playbooks." +msgstr "Playbook の ``vars`` ファイルの変数名を使用します。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:94 +msgid "When running a playbook, Ansible finds the variables in the unencrypted file, which pulls the sensitive variable values from the encrypted file. There is no limit to the number of variable and vault files or their names." +msgstr "Playbook を実行する際、Ansible は暗号化されていないファイルの変数を見つけ、暗号化されたファイルから機密性の高い変数の値を引き出します。変数ファイルと Vault ファイルの数や名前に制限はありません。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:96 +msgid "Note that using this strategy in your inventory still requires *all vault passwords to be available* (for example for ``ansible-playbook`` or `AWX/Ansible Tower <https://github.com/ansible/awx/issues/223#issuecomment-768386089>`_) when run with that inventory." +msgstr "インベントリーでこのストラテジーを使用するには、そのインベントリーで実行する場合は *すべての Vault パスワードが利用可能でなければなりません*（例：``ansible-playbook`` または `AWX/Ansible Tower <https://github.com/ansible/awx/issues/223#issuecomment-768386089>`_）。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:99 +msgid "Execution tricks" +msgstr "実行トリック" + +#: ../../rst/user_guide/playbooks_best_practices.rst:101 +msgid "These tips apply to using Ansible, rather than to Ansible artifacts." +msgstr "このヒントは、Ansible アーティファクトではなく Ansible の使用に適用されます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:104 +msgid "Try it in staging first" +msgstr "最初にステージングで試す" + +#: ../../rst/user_guide/playbooks_best_practices.rst:106 +msgid "Testing changes in a staging environment before rolling them out in production is always a great idea. Your environments need not be the same size and you can use group variables to control the differences between those environments." +msgstr "変更を実稼働環境に展開する前にステージング環境でテストすることは、常に素晴らしい考えです。環境は同じ大きさである必要はなく、グループ変数を使用して環境間の違いを制御することができます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:109 +msgid "Update in batches" +msgstr "バッチの更新" + +#: ../../rst/user_guide/playbooks_best_practices.rst:111 +msgid "Use the 'serial' keyword to control how many machines you update at once in the batch. See :ref:`playbooks_delegation`." +msgstr "「serial」キーワードを使用して、バッチで一度にアップデートするマシンの数を制御します。「:ref:`playbooks_delegation`」を参照してください。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:116 +msgid "Handling OS and distro differences" +msgstr "OS とディストリビューションの相違点の処理" + +#: ../../rst/user_guide/playbooks_best_practices.rst:118 +msgid "Group variables files and the ``group_by`` module work together to help Ansible execute across a range of operating systems and distributions that require different settings, packages, and tools. The ``group_by`` module creates a dynamic group of hosts matching certain criteria. This group does not need to be defined in the inventory file. This approach lets you execute different tasks on different operating systems or distributions. For example:" +msgstr "グループ変数ファイルと ``group_by`` モジュールが連携することで、Ansible は、異なる設定、パッケージ、ツールを必要とするさまざまなオペレーティングシステムやディストリビューションに対応して実行することができます。``group_by`` モジュールは、特定の条件に一致するホストの動的グループを作成します。このグループは、インベントリーファイルで定義する必要はありません。この方法では、異なるオペレーティングシステムやディストリビューション上で異なるタスクを実行することができます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:138 +msgid "The first play categorizes all systems into dynamic groups based on the operating system name. Later plays can use these groups as patterns on the ``hosts`` line. You can also add group-specific settings in group vars files. All three names must match: the name created by the ``group_by`` task, the name of the pattern in subsequent plays, and the name of the group vars file. For example:" +msgstr "最初のプレイでは、すべてのシステムをオペレーティングシステムの名前に基づいて動的なグループに分類します。後のプレイでは、これらのグループを ``hosts`` 行のパターンとして使用できます。また、グループの変数ファイルでグループ固有の設定を追加することもできます。``group_by`` タスクで作成された名前、後続のプレイでのパターンの名前、グループの変数ファイルの名前の 3 つの名前がすべて一致する必要があります。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:150 +msgid "In this example, CentOS machines get the value of '42' for asdf, but other machines get '10'. This can be used not only to set variables, but also to apply certain roles to only certain systems." +msgstr "この例では、CentOS マシンでは asdf に「42」という値が設定されますが、その他のマシンでは「10」が設定されます。これは、変数の設定だけでなく、特定のシステムだけに特定のロールを適用するためにも使用できます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:153 +msgid "You can use the same setup with ``include_vars`` when you only need OS-specific variables, not tasks:" +msgstr "タスクではなく、OS 固有の変数のみを必要とする場合は、``include_vars`` で同じ設定を使用できます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:164 +msgid "This pulls in variables from the group_vars/os_CentOS.yml file." +msgstr "これにより、group_vars/os_CentOS.yml ファイルから変数がプルされます。" + +#: ../../rst/user_guide/playbooks_best_practices.rst:168 +#: ../../rst/user_guide/playbooks_intro.rst:146 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:13 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:590 +#: ../../rst/user_guide/sample_setup.rst:284 +msgid ":ref:`yaml_syntax`" +msgstr ":ref:`yaml_syntax`" + +#: ../../rst/user_guide/playbooks_best_practices.rst:169 +#: ../../rst/user_guide/playbooks_intro.rst:147 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:14 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:591 +#: ../../rst/user_guide/sample_setup.rst:285 +msgid "Learn about YAML syntax" +msgstr "YAML 構文について" + +#: ../../rst/user_guide/playbooks_best_practices.rst:171 +#: ../../rst/user_guide/sample_setup.rst:287 +msgid "Review the basic playbook features" +msgstr "基本的な Playbook 機能の確認" + +#: ../../rst/user_guide/playbooks_best_practices.rst:175 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:28 +#: ../../rst/user_guide/sample_setup.rst:291 +msgid "Learn how to extend Ansible by writing your own modules" +msgstr "独自のモジュールを作成して Ansible を拡張する方法について" + +#: ../../rst/user_guide/playbooks_best_practices.rst:176 +#: ../../rst/user_guide/playbooks_intro.rst:154 +#: ../../rst/user_guide/sample_setup.rst:292 +msgid ":ref:`intro_patterns`" +msgstr ":ref:`intro_patterns`" + +#: ../../rst/user_guide/playbooks_best_practices.rst:177 +#: ../../rst/user_guide/playbooks_intro.rst:155 +#: ../../rst/user_guide/sample_setup.rst:293 +msgid "Learn about how to select hosts" +msgstr "ホストの選択方法について" + +#: ../../rst/user_guide/playbooks_best_practices.rst:178 +#: ../../rst/user_guide/playbooks_intro.rst:156 +#: ../../rst/user_guide/sample_setup.rst:294 +msgid "`GitHub examples directory <https://github.com/ansible/ansible-examples>`_" +msgstr "`GitHub examples ディレクトリー <https://github.com/ansible/ansible-examples>`_" + +#: ../../rst/user_guide/playbooks_best_practices.rst:179 +#: ../../rst/user_guide/sample_setup.rst:295 +msgid "Complete playbook files from the github project source" +msgstr "Github プロジェクトソースの完全な Playbook ファイル" + +#: ../../rst/user_guide/playbooks_blocks.rst:5 +msgid "Blocks" +msgstr "ブロック" + +#: ../../rst/user_guide/playbooks_blocks.rst:7 +msgid "Blocks create logical groups of tasks. Blocks also offer ways to handle task errors, similar to exception handling in many programming languages." +msgstr "ブロックは、タスクの論理的なグループを作ります。また、ブロックにはタスクのエラーを処理する方法があり、多くのプログラミング言語の例外処理に似ています。" + +#: ../../rst/user_guide/playbooks_blocks.rst:13 +msgid "Grouping tasks with blocks" +msgstr "ブロックを使用したタスクのグループ化" + +#: ../../rst/user_guide/playbooks_blocks.rst:15 +msgid "All tasks in a block inherit directives applied at the block level. Most of what you can apply to a single task (with the exception of loops) can be applied at the block level, so blocks make it much easier to set data or directives common to the tasks. The directive does not affect the block itself, it is only inherited by the tasks enclosed by a block. For example, a `when` statement is applied to the tasks within a block, not to the block itself." +msgstr "ブロック内のすべてのタスクは、ブロックレベルで適用されるディレクティブを継承します。単一のタスクに適用できるもの (ループを除く) のほとんどは、ブロックレベルで適用できるため、ブロックを使用すると、タスクに共通するデータやディレクティブを設定することが非常に簡単になります。ディレクティブはブロック自体には影響せず、ブロックで囲まれたタスクにのみ継承されます。たとえば、`when` 文は、ブロック自体にではなく、ブロック内のタスクに適用されます。" + +#: ../../rst/user_guide/playbooks_blocks.rst:17 +msgid "Block example with named tasks inside the block" +msgstr "内部に名前付きタスクを含むブロックの例" + +#: ../../rst/user_guide/playbooks_blocks.rst:46 +msgid "In the example above, the 'when' condition will be evaluated before Ansible runs each of the three tasks in the block. All three tasks also inherit the privilege escalation directives, running as the root user. Finally, ``ignore_errors: yes`` ensures that Ansible continues to execute the playbook even if some of the tasks fail." +msgstr "上の例では、Ansible がブロック内の 3 つのタスクをそれぞれ実行する前に、「when」条件が評価されます。また、3 つのタスクはすべて、特権昇格ディレクティブを継承し、root ユーザーとして実行します。最後に、``ignore_errors: yes`` は、一部のタスクが失敗しても、Ansible が Playbook の実行を継続することを保証します。" + +#: ../../rst/user_guide/playbooks_blocks.rst:48 +msgid "Names for blocks have been available since Ansible 2.3. We recommend using names in all tasks, within blocks or elsewhere, for better visibility into the tasks being executed when you run the playbook." +msgstr "ブロックの名前は、Ansible 2.3 から利用できるようになりました。Playbook の実行時に実行されているタスクの可視性を高めるために、ブロック内やその他の場所で、すべてのタスクに名前を使用することが推奨されます。" + +#: ../../rst/user_guide/playbooks_blocks.rst:53 +msgid "Handling errors with blocks" +msgstr "ブロックを使用したエラーの処理" + +#: ../../rst/user_guide/playbooks_blocks.rst:55 +msgid "You can control how Ansible responds to task errors using blocks with ``rescue`` and ``always`` sections." +msgstr "``rescue`` セクションおよび ``always`` セクションのブロックを使用して、Ansible がタスクエラーに対応する方法を制御できます。" + +#: ../../rst/user_guide/playbooks_blocks.rst:57 +msgid "Rescue blocks specify tasks to run when an earlier task in a block fails. This approach is similar to exception handling in many programming languages. Ansible only runs rescue blocks after a task returns a 'failed' state. Bad task definitions and unreachable hosts will not trigger the rescue block." +msgstr "レスキューブロックは、ブロック内の先行タスクが失敗したときに実行するタスクを指定します。このアプローチは、多くのプログラミング言語における例外処理に似ています。Ansible は、タスクが「失敗」状態を返した後にのみレスキューブロックを実行します。誤ったタスク定義や到達不可能なホストでは、レスキューブロックは実行しません。" + +#: ../../rst/user_guide/playbooks_blocks.rst:60 +msgid "Block error handling example" +msgstr "ブロックエラー処理例" + +#: ../../rst/user_guide/playbooks_blocks.rst:82 +msgid "You can also add an ``always`` section to a block. Tasks in the ``always`` section run no matter what the task status of the previous block is." +msgstr "``always`` セクションをブロックに追加することもできます。前のブロックのタスクステータスに関係なく、``always`` セクションのタスクは実行します。" + +#: ../../rst/user_guide/playbooks_blocks.rst:85 +msgid "Block with always section" +msgstr "always セクションのあるブロック" + +#: ../../rst/user_guide/playbooks_blocks.rst:106 +msgid "Together, these elements offer complex error handling." +msgstr "この要素をまとめると、複雑なエラー処理を行います。" + +#: ../../rst/user_guide/playbooks_blocks.rst:108 +msgid "Block with all sections" +msgstr "すべてのセクションのブロック" + +#: ../../rst/user_guide/playbooks_blocks.rst:140 +msgid "The tasks in the ``block`` execute normally. If any tasks in the block return ``failed``, the ``rescue`` section executes tasks to recover from the error. The ``always`` section runs regardless of the results of the ``block`` and ``rescue`` sections." +msgstr "``block`` のタスクは正常に実行されます。ブロック内のいずれかのタスクが ``failed`` を返すと、``rescue`` セクションはエラーから回復するためのタスクを実行します。``always`` セクションは、``block`` セクションと ``rescue`` セクションの結果に関わらず実行されます。" + +#: ../../rst/user_guide/playbooks_blocks.rst:142 +msgid "If an error occurs in the block and the rescue task succeeds, Ansible reverts the failed status of the original task for the run and continues to run the play as if the original task had succeeded. The rescued task is considered successful, and does not trigger ``max_fail_percentage`` or ``any_errors_fatal`` configurations. However, Ansible still reports a failure in the playbook statistics." +msgstr "ブロック内でエラーが発生し、レスキュータスクが成功した場合、Ansible は実行中の元のタスクの失敗ステータスを元に戻し、元のタスクが成功したかのようにプレイの実行を継続します。レスキューとなったタスクは成功したとみなされ、``max_fail_percentage`` や ``any_errors_fatal`` の設定は発生しません。ただし、Ansible は Playbook の統計で失敗を報告します。" + +#: ../../rst/user_guide/playbooks_blocks.rst:144 +msgid "You can use blocks with ``flush_handlers`` in a rescue task to ensure that all handlers run even if an error occurs:" +msgstr "レスキュータスクにおいて ``flush_handlers`` でブロックを使用し、エラーが発生した場合でもすべてのハンドラーが実行されるようにします。" + +#: ../../rst/user_guide/playbooks_blocks.rst:146 +msgid "Block run handlers in error handling" +msgstr "エラー処理におけるブロック実行ハンドラー" + +#: ../../rst/user_guide/playbooks_blocks.rst:172 +msgid "Ansible provides a couple of variables for tasks in the ``rescue`` portion of a block:" +msgstr "Ansible は、ブロックの ``rescue`` の部分にタスクの変数をいくつか提供します。" + +#: ../../rst/user_guide/playbooks_blocks.rst:175 +msgid "ansible_failed_task" +msgstr "ansible_failed_task" + +#: ../../rst/user_guide/playbooks_blocks.rst:175 +msgid "The task that returned 'failed' and triggered the rescue. For example, to get the name use ``ansible_failed_task.name``." +msgstr "「失敗した」と返され、レスキューのきっかけとなったタスクです。たとえば、名前を取得するには ``ansible_failed_task.name`` を使用します。" + +#: ../../rst/user_guide/playbooks_blocks.rst:178 +msgid "ansible_failed_result" +msgstr "ansible_failed_result" + +#: ../../rst/user_guide/playbooks_blocks.rst:178 +msgid "The captured return result of the failed task that triggered the rescue. This would equate to having used this var in the ``register`` keyword." +msgstr "レスキューをトリガーした失敗したタスクの戻り値。これは、``register`` キーワードでこの変数を使用するのと同じです。" + +#: ../../rst/user_guide/playbooks_blocks.rst:185 +#: ../../rst/user_guide/playbooks_conditionals.rst:528 +#: ../../rst/user_guide/playbooks_filters.rst:2186 +#: ../../rst/user_guide/playbooks_loops.rst:479 +#: ../../rst/user_guide/playbooks_strategies.rst:250 +#: ../../rst/user_guide/playbooks_tags.rst:428 +#: ../../rst/user_guide/playbooks_templating.rst:53 +#: ../../rst/user_guide/playbooks_tests.rst:518 +#: ../../rst/user_guide/playbooks_variables.rst:504 +msgid "Playbook organization by roles" +msgstr "ロール別の Playbook の組織" + +#: ../../rst/user_guide/playbooks_checkmode.rst:5 +msgid "Validating tasks: check mode and diff mode" +msgstr "タスクの検証: チェックモードと差分モード" + +#: ../../rst/user_guide/playbooks_checkmode.rst:7 +msgid "Ansible provides two modes of execution that validate tasks: check mode and diff mode. These modes can be used separately or together. They are useful when you are creating or editing a playbook or role and you want to know what it will do. In check mode, Ansible runs without making any changes on remote systems. Modules that support check mode report the changes they would have made. Modules that do not support check mode report nothing and do nothing. In diff mode, Ansible provides before-and-after comparisons. Modules that support diff mode display detailed information. You can combine check mode and diff mode for detailed validation of your playbook or role." +msgstr "Ansible には、タスクを検証するために、チェックモードと差分モードという 2 つの実行モードが用意されています。これらのモードは、別々に使用することも、一緒に使用することもできます。これらのモードは、Playbook やロールを作成または編集する際に、その実行内容を知りたい場合に便利です。チェックモードでは、Ansible はリモートシステムに変更を加えずに実行します。チェックモードをサポートするモジュールは、自身が行った変更を報告します。チェックモードをサポートしていないモジュールは、何も報告せず、何も行いません。差分モードでは、Ansible は事前と事後の比較を行います。差分モードをサポートするモジュールは、詳細情報を表示します。チェックモードと差分モードを組み合わせて、Playbook やロールの詳細な検証を行うことができます。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:13 +msgid "Using check mode" +msgstr "チェックモードの使用" + +#: ../../rst/user_guide/playbooks_checkmode.rst:15 +msgid "Check mode is just a simulation. It will not generate output for tasks that use :ref:`conditionals based on registered variables <conditionals_registered_vars>` (results of prior tasks). However, it is great for validating configuration management playbooks that run on one node at a time. To run a playbook in check mode:" +msgstr "チェックモードはあくまでもシミュレーションです。:ref:`conditionals based on registered variables <conditionals_registered_vars>` (先行タスクの結果) を使用するタスクの出力は生成されません。しかし、一度に 1 つのノードで実行する構成管理の Playbook を検証するには最適です。Playbook をチェックモードで実行するには以下を行います。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:24 +msgid "Enforcing or preventing check mode on tasks" +msgstr "タスクでのチェックモードの強制または禁止" + +#: ../../rst/user_guide/playbooks_checkmode.rst:28 +msgid "If you want certain tasks to run in check mode always, or never, regardless of whether you run the playbook with or without ``--check``, you can add the ``check_mode`` option to those tasks:" +msgstr "Playbook を実行する際に ``--check`` を付けるかどうかに関わらず、特定のタスクを常にチェックモードで実行する場合は、それらのタスクに ``check_mode`` オプションを追加します。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:30 +msgid "To force a task to run in check mode, even when the playbook is called without ``--check``, set ``check_mode: yes``." +msgstr "``--check`` を使用せずに Playbook が呼び出された場合でも、タスクを強制的にチェックモードで実行するには、``check_mode: yes`` を設定します。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:31 +msgid "To force a task to run in normal mode and make changes to the system, even when the playbook is called with ``--check``, set ``check_mode: no``." +msgstr "Playbook が ``--check`` で呼び出された場合でも、タスクを強制的に通常モードで実行し、システムに変更を加えるには、``check_mode: no`` を設定します。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:50 +msgid "Running single tasks with ``check_mode: yes`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes." +msgstr "``check_mode: yes`` を使用してシングルタスクを実行すると、Ansible モジュールをテストする際に便利です。モジュール自体をテストしたり、モジュールが変更を行う条件をテストしたりすることができます。これらのタスクに変数 (:ref:`playbooks_conditionals` を参照) を登録すると、潜在的な変更についてさらに詳しく知ることができます。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:52 +msgid "Prior to version 2.2 only the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``." +msgstr "バージョン 2.2 以前では、``check_mode: no`` に相当するものだけが存在していました。その表記法は ``always_run: yes`` でした。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:55 +msgid "Skipping tasks or ignoring errors in check mode" +msgstr "タスクをスキップまたはチェックモードでエラーを無視する" + +#: ../../rst/user_guide/playbooks_checkmode.rst:59 +msgid "If you want to skip a task or ignore errors on a task when you run Ansible in check mode, you can use a boolean magic variable ``ansible_check_mode``, which is set to ``True`` when Ansible runs in check mode. For example:" +msgstr "Ansible をチェックモードで実行する際に、タスクをスキップしたり、タスクのエラーを無視したりする場合は、ブール型のマジック変数 ``ansible_check_mode`` を使用することができます。この変数は、Ansible をチェックモードで実行すると、``True`` に設定されます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:80 +msgid "Using diff mode" +msgstr "差分モードの使用" + +#: ../../rst/user_guide/playbooks_checkmode.rst:82 +msgid "The ``--diff`` option for ansible-playbook can be used alone or with ``--check``. When you run in diff mode, any module that supports diff mode reports the changes made or, if used with ``--check``, the changes that would have been made. Diff mode is most common in modules that manipulate files (for example, the template module) but other modules might also show 'before and after' information (for example, the user module)." +msgstr "ansible-playbook の ``--diff`` オプションは、単独でも ``--check`` と併用しても構いません。差分モードで実行すると、差分モードをサポートしているすべてのモジュールが、行われた変更を報告します (``--check`` と併用する場合は、行われたであろう変更を報告します)。差分モードは、ファイルを操作するモジュール (template モジュールなど) で最も一般的ですが、その他のモジュールでも「変更前と変更後」の情報を表示することがあります (user モジュールなど)。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:84 +msgid "Diff mode produces a large amount of output, so it is best used when checking a single host at a time. For example:" +msgstr "差分モードは大量の出力を生成するため、一度に 1 つのホストを確認するときに使うのが最適です。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_checkmode.rst:93 +msgid "Enforcing or preventing diff mode on tasks" +msgstr "タスクでの差分モードの強制または禁止" + +#: ../../rst/user_guide/playbooks_checkmode.rst:95 +msgid "Because the ``--diff`` option can reveal sensitive information, you can disable it for a task by specifying ``diff: no``. For example:" +msgstr "``--diff`` オプションは機密情報を表示する可能性があるため、``diff: no`` を指定してタスクに対してこれを無効にすることができます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:5 +msgid "Conditionals" +msgstr "条件分岐 (Conditional)" + +#: ../../rst/user_guide/playbooks_conditionals.rst:7 +msgid "In a playbook, you may want to execute different tasks, or have different goals, depending on the value of a fact (data about the remote system), a variable, or the result of a previous task. You may want the value of some variables to depend on the value of other variables. Or you may want to create additional groups of hosts based on whether the hosts match other criteria. You can do all of these things with conditionals." +msgstr "Playbook では、ファクト (リモートシステムに関するデータ)、変数、または以前のタスクの結果の値に応じて、異なるタスクを実行したり、異なるゴールを設定したりすることができます。また、ある変数の値に応じて別の変数の値を変更したい場合もあります。また、ホストが他の基準に一致するかどうかに基づいて、ホストの追加グループを作成することもできます。これらのことはすべて、条件分岐で実現できます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:9 +msgid "Ansible uses Jinja2 :ref:`tests <playbooks_tests>` and :ref:`filters <playbooks_filters>` in conditionals. Ansible supports all the standard tests and filters, and adds some unique ones as well." +msgstr "Ansible は Jinja2 の :ref:`テスト <playbooks_tests>` および :ref:`フィルター <playbooks_filters>` を条件分岐で使用しています。Ansible は標準的なテストやフィルターをすべてサポートしており、独自のものもいくつか追加されています。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:13 +msgid "There are many options to control execution flow in Ansible. You can find more examples of supported conditionals at `<https://jinja.palletsprojects.com/en/latest/templates/#comparisons>`_." +msgstr "Ansible で実行フローを制御するオプションは多数あります。サポートされている条件分岐の例は、`<https://jinja.palletsprojects.com/en/latest/templates/#comparisons>`_ で確認できます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:21 +msgid "Basic conditionals with ``when``" +msgstr "``when`` を使用する基本的な条件分岐" + +#: ../../rst/user_guide/playbooks_conditionals.rst:23 +msgid "The simplest conditional statement applies to a single task. Create the task, then add a ``when`` statement that applies a test. The ``when`` clause is a raw Jinja2 expression without double curly braces (see :ref:`group_by_module`). When you run the task or playbook, Ansible evaluates the test for all hosts. On any host where the test passes (returns a value of True), Ansible runs that task. For example, if you are installing mysql on multiple machines, some of which have SELinux enabled, you might have a task to configure SELinux to allow mysql to run. You would only want that task to run on machines that have SELinux enabled:" +msgstr "最も簡単な条件文は、1 つのタスクに適用されるものです。タスクを作成し、テストを適用する ``when`` の文を追加します。``when`` 句は、二重中括弧のない生の Jinja2 式です (:ref:`group_by_module` 参照)。タスクや Playbook を実行すると、Ansible はすべてのホストに対してテストを評価します。テストにパスする (True の値を返す) ホストでは、Ansible はそのタスクを実行します。たとえば、複数のマシンに mysql をインストールし、そのうちのいくつかのマシンでは SELinux が有効になっている場合は、mysql の実行を許可するように SELinux を設定するタスクがあります。このタスクは、SELinux が有効になっているマシンでのみ実行されるようにします。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:37 +msgid "Conditionals based on ansible_facts" +msgstr "ansible_facts に基づく条件分岐" + +#: ../../rst/user_guide/playbooks_conditionals.rst:39 +msgid "Often you want to execute or skip a task based on facts. Facts are attributes of individual hosts, including IP address, operating system, the status of a filesystem, and many more. With conditionals based on facts:" +msgstr "ファクトに基づいてタスクを実行したりスキップしたりしたい場合がよくあります。ファクトとは、IP アドレス、オペレーティングシステム、ファイルシステムの状態など、個々のホストの属性のことです。ファクトに基づく条件分岐で、以下を行います。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:41 +msgid "You can install a certain package only when the operating system is a particular version." +msgstr "特定のパッケージは、オペレーティングシステムが特定のバージョンの場合にのみインストールできます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:42 +msgid "You can skip configuring a firewall on hosts with internal IP addresses." +msgstr "内部 IP アドレスを持つホストでファイアウォールの設定を省略できます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:43 +msgid "You can perform cleanup tasks only when a filesystem is getting full." +msgstr "ファイルシステムが満杯になった場合にのみ、クリーンアップタスクを実行することができます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:45 +msgid "See :ref:`commonly_used_facts` for a list of facts that frequently appear in conditional statements. Not all facts exist for all hosts. For example, the 'lsb_major_release' fact used in an example below only exists when the lsb_release package is installed on the target host. To see what facts are available on your systems, add a debug task to your playbook:" +msgstr "条件文に頻繁に現れるファクトの一覧は、:ref:`commonly_used_facts` を参照してください。すべてのファクトがすべてのホストに存在するわけではありません。たとえば、以下の例で使用されている「lsb_major_release」ファクトは、ターゲットホストに lsb_release パッケージがインストールされている場合にのみ存在します。システム上で利用可能なファクトを確認するには、Playbook にデバッグタスクを追加します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:53 +msgid "Here is a sample conditional based on a fact:" +msgstr "以下は、ファクトに基づく条件分岐の例です。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:62 +msgid "If you have multiple conditions, you can group them with parentheses:" +msgstr "複数の条件がある場合は、括弧でグループ化できます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:72 +msgid "You can use `logical operators <https://jinja.palletsprojects.com/en/latest/templates/#logic>`_ to combine conditions. When you have multiple conditions that all need to be true (that is, a logical ``and``), you can specify them as a list:" +msgstr "`logical operators <https://jinja.palletsprojects.com/en/latest/templates/#logic>`_ を使用して条件を組み合わせることができます。すべてが True である必要がある複数の条件がある場合 (つまり、論理的な ``and``)、それらをリストとして指定することができます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:83 +msgid "If a fact or variable is a string, and you need to run a mathematical comparison on it, use a filter to ensure that Ansible reads the value as an integer:" +msgstr "ファクトまたは変数が文字列で、それに対して数学比較を実行する必要がある場合は、フィルターを使用して Ansible が値を整数として読み取るようにします。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:94 +msgid "Conditions based on registered variables" +msgstr "登録済みの変数に基づく条件" + +#: ../../rst/user_guide/playbooks_conditionals.rst:96 +msgid "Often in a playbook you want to execute or skip a task based on the outcome of an earlier task. For example, you might want to configure a service after it is upgraded by an earlier task. To create a conditional based on a registered variable:" +msgstr "Playbook では、以前のタスクの結果に基づいてタスクを実行またはスキップしたい場合がよくあります。たとえば、以前のタスクによってサービスがアップグレードされた後に、そのサービスを設定したい場合などです。登録された変数に基づいて条件分岐を作成するには、次のようにします。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:98 +msgid "Register the outcome of the earlier task as a variable." +msgstr "以前のタスクの結果を変数として登録します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:99 +msgid "Create a conditional test based on the registered variable." +msgstr "登録した変数に基づいて条件分岐テストを作成します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:101 +msgid "You create the name of the registered variable using the ``register`` keyword. A registered variable always contains the status of the task that created it as well as any output that task generated. You can use registered variables in templates and action lines as well as in conditional ``when`` statements. You can access the string contents of the registered variable using ``variable.stdout``. For example:" +msgstr "登録された変数の名前は、``register`` キーワードを使用して作成します。登録された変数には、そのキーワードを作成したタスクのステータスと、そのタスクが生成した出力が常に含まれています。登録された変数は、テンプレートやアクション行、および条件付きの ``when`` 文で使用できます。登録された変数の文字列内容にアクセスするには、``variable.stdout`` を使用します。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:118 +msgid "You can use registered results in the loop of a task if the variable is a list. If the variable is not a list, you can convert it into a list, with either ``stdout_lines`` or with ``variable.stdout.split()``. You can also split the lines by other fields:" +msgstr "登録された結果は、変数がリストの場合、タスクのループ内で使用できます。変数がリストでない場合は、``stdout_lines`` または ``variable.stdout.split()`` でリストに変換できます。また、他のフィールドで行を分割することもできます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:138 +msgid "The string content of a registered variable can be empty. If you want to run another task only on hosts where the stdout of your registered variable is empty, check the registered variable's string contents for emptiness:" +msgstr "登録された変数の文字列内容は空になることがあります。登録された変数の標準出力が空のホストでのみ別のタスクを実行したい場合は、登録された変数の文字列内容が空であるかどうかをチェックします。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:156 +msgid "Ansible always registers something in a registered variable for every host, even on hosts where a task fails or Ansible skips a task because a condition is not met. To run a follow-up task on these hosts, query the registered variable for ``is skipped`` (not for \"undefined\" or \"default\"). See :ref:`registered_variables` for more information. Here are sample conditionals based on the success or failure of a task. Remember to ignore errors if you want Ansible to continue executing on a host when a failure occurs:" +msgstr "タスクが失敗したホストや、条件が満たされずに Ansible がタスクをスキップしたホストであっても、Ansible は常にすべてのホストの登録変数に何かを登録します。これらのホストでフォローアップタスクを実行するには、登録済みの変数に ``is skipped`` を照会します (「undefined」や「default」ではありません)。詳細は、「:ref:`registered_variables`」を参照してください。以下は、タスクの成功または失敗に基づく条件分岐のサンプルです。失敗したときにホスト上で Ansible の実行を継続させたい場合は、エラーを無視することを忘れないでください。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:178 +msgid "Older versions of Ansible used ``success`` and ``fail``, but ``succeeded`` and ``failed`` use the correct tense. All of these options are now valid." +msgstr "古いバージョンの Ansible では、``success`` および ``fail`` が使用されていましたが、``succeeded`` および ``failed`` は正しい時制を使用します。このオプションはすべて有効になりました。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:182 +msgid "Conditionals based on variables" +msgstr "変数に基づく条件分岐" + +#: ../../rst/user_guide/playbooks_conditionals.rst:184 +msgid "You can also create conditionals based on variables defined in the playbooks or inventory. Because conditionals require boolean input (a test must evaluate as True to trigger the condition), you must apply the ``| bool`` filter to non boolean variables, such as string variables with content like 'yes', 'on', '1', or 'true'. You can define variables like this:" +msgstr "また、Playbook やインベントリーで定義された変数に基づいて、条件分岐を作成することもできます。条件分岐にはブール値の入力が必要なため (条件を成立させるためには、テストが True と評価されなければなりません)、「yes」、「on」、「1」、「true」などの内容を持つ文字列変数など、ブール値以外の変数には、``| bool`` フィルターを適用する必要があります。変数は次のように定義できます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:192 +msgid "With the variables above, Ansible would run one of these tasks and skip the other:" +msgstr "上記の変数を使用すると、Ansible はこれらのタスクのいずれかを実行し、他のタスクを省略します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:205 +msgid "If a required variable has not been set, you can skip or fail using Jinja2's `defined` test. For example:" +msgstr "必要な変数が設定されていない場合は、省略するか、Jinja2 の `定義済み` テストを使用して失敗します。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:218 +msgid "This is especially useful in combination with the conditional import of vars files (see below). As the examples show, you do not need to use `{{ }}` to use variables inside conditionals, as these are already implied." +msgstr "これは、変数ファイルの条件分岐インポートとの組み合わせで特に有効です (以下参照)。これらの例が示すように、条件分岐の中で変数を使用するために `{{ }}` を使用する必要はありません。それらはすでに暗示されているためです。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:224 +msgid "Using conditionals in loops" +msgstr "ループでの条件分岐の使用" + +#: ../../rst/user_guide/playbooks_conditionals.rst:226 +msgid "If you combine a ``when`` statement with a :ref:`loop <playbooks_loops>`, Ansible processes the condition separately for each item. This is by design, so you can execute the task on some items in the loop and skip it on other items. For example:" +msgstr "``when`` 文と :ref:`loop <playbooks_loops>` を組み合わせた場合、Ansible は各アイテムに対して個別に条件を処理します。これは意図的なもので、ループ内の一部のアイテムでタスクを実行し、他のアイテムではスキップすることができます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:236 +msgid "If you need to skip the whole task when the loop variable is undefined, use the `|default` filter to provide an empty iterator. For example, when looping over a list:" +msgstr "ループ変数が未定義のときにタスク全体を省略する必要がある場合は、`|default` フィルターを使用して空のイテレーターを指定します。たとえば、リストをループする場合は、以下を行います。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:245 +msgid "You can do the same thing when looping over a dict:" +msgstr "同じことが、ディクショナリーをループするときにもできます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:257 +msgid "Loading custom facts" +msgstr "カスタムファクトの読み込み中" + +#: ../../rst/user_guide/playbooks_conditionals.rst:259 +msgid "You can provide your own facts, as described in :ref:`developing_modules`. To run them, just make a call to your own custom fact gathering module at the top of your list of tasks, and variables returned there will be accessible to future tasks:" +msgstr ":ref:`developing_modules` で説明しているように、独自のファクトを提供することができます。それらを実行するには、タスクリストの先頭にある独自のカスタムファクト収集モジュールを呼び出すだけで、そこから返された変数は将来のタスクにアクセスできるようになります。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:274 +msgid "Conditionals with re-use" +msgstr "再利用による条件分岐" + +#: ../../rst/user_guide/playbooks_conditionals.rst:276 +msgid "You can use conditionals with re-usable tasks files, playbooks, or roles. Ansible executes these conditional statements differently for dynamic re-use (includes) and for static re-use (imports). See :ref:`playbooks_reuse` for more information on re-use in Ansible." +msgstr "条件分岐は、再利用可能なタスクファイル、Playbook、またはロールで使用できます。Ansible はこれらの条件文を、動的再利用 (インクルード) および静的再利用 (インポート) で異なる方法で実行します。Ansible での再利用の詳細は、「:ref:`playbooks_reuse`」を参照してください。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:281 +msgid "Conditionals with imports" +msgstr "インポートのある条件分岐" + +#: ../../rst/user_guide/playbooks_conditionals.rst:283 +msgid "When you add a conditional to an import statement, Ansible applies the condition to all tasks within the imported file. This behavior is the equivalent of :ref:`tag_inheritance`. Ansible applies the condition to every task, and evaluates each task separately. For example, you might have a playbook called ``main.yml`` and a tasks file called ``other_tasks.yml``:" +msgstr "インポートステートメントに条件分岐を追加すると、Ansible はインポートされたファイル内のすべてのタスクにその条件を適用します。この動作は、:ref:`tag_inheritance` と同等です。Ansible は、すべてのタスクに条件を適用し、各タスクを個別に評価します。たとえば、``main.yml`` という Playbookと、``other_tasks.yml`` というタスクファイルがあるとします。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:301 +#: ../../rst/user_guide/playbooks_conditionals.rst:345 +msgid "Ansible expands this at execution time to the equivalent of:" +msgstr "Ansible は、実行時にこれを以下に相当するものに拡張します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:317 +msgid "Thus if ``x`` is initially undefined, the ``debug`` task will be skipped. If this is not the behavior you want, use an ``include_*`` statement to apply a condition only to that statement itself." +msgstr "したがって、``x`` が最初に未定義であれば、``debug`` のタスクはスキップされます。このような動作を望まない場合は、``include_*`` 文を使用して、その文自体にのみ条件を適用します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:319 +msgid "You can apply conditions to ``import_playbook`` as well as to the other ``import_*`` statements. When you use this approach, Ansible returns a 'skipped' message for every task on every host that does not match the criteria, creating repetitive output. In many cases the :ref:`group_by module <group_by_module>` can be a more streamlined way to accomplish the same objective; see :ref:`os_variance`." +msgstr "``import_playbook`` には、他の ``import_*`` 文と同様に条件を適用できます。この方法を使用すると、Ansible は基準に一致しないすべてのホスト上のすべてのタスクに対して「skipped」メッセージを返し、反復的な出力を作成します。多くの場合、:ref:`group_by モジュール <group_by_module>` は、同じ目的を達成するためのより合理的な方法となります。「:ref:`os_variance`」を参照してください。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:324 +msgid "Conditionals with includes" +msgstr "includes を持つ条件分岐" + +#: ../../rst/user_guide/playbooks_conditionals.rst:326 +msgid "When you use a conditional on an ``include_*`` statement, the condition is applied only to the include task itself and not to any other tasks within the included file(s). To contrast with the example used for conditionals on imports above, look at the same playbook and tasks file, but using an include instead of an import:" +msgstr "``include_*`` 文に条件分岐を使用すると、その条件はインクルードタスク自体にのみ適用され、インクルードファイル内の他のタスクには適用されません。上記のインポートに対する条件分岐の例と対比するために、同じ Playbook とタスクファイルを見てください。ただし、インポートの代わりにインクルードを使用しています。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:365 +msgid "By using ``include_tasks`` instead of ``import_tasks``, both tasks from ``other_tasks.yml`` will be executed as expected. For more information on the differences between ``include`` v ``import`` see :ref:`playbooks_reuse`." +msgstr "``import_tasks`` の代わりに ``include_tasks`` を使用すると、``other_tasks.yml`` からの両方のタスクが想定どおりに実行されます。``include`` と ``import`` の相違点は、「:ref:`playbooks_reuse`」を参照してください。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:368 +msgid "Conditionals with roles" +msgstr "ロールを含む条件分岐" + +#: ../../rst/user_guide/playbooks_conditionals.rst:370 +msgid "There are three ways to apply conditions to roles:" +msgstr "状態をロールに適用する方法は 3 つあります。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:372 +msgid "Add the same condition or conditions to all tasks in the role by placing your ``when`` statement under the ``roles`` keyword. See the example in this section." +msgstr "``when`` 文を ``roles`` キーワードの下に置くことで、ロール内のすべてのタスクに同じ条件を追加します。このセクションの例を参照してください。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:373 +msgid "Add the same condition or conditions to all tasks in the role by placing your ``when`` statement on a static ``import_role`` in your playbook." +msgstr "Playbook の静的 ``import_role`` に ``when`` 文を配置して、ロール内のすべてのタスクに同じ条件を追加します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:374 +msgid "Add a condition or conditions to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role based on your ``when`` statement. To select or skip tasks within the role, you must have conditions set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the condition or conditions to the include. When you use this approach, Ansible applies the condition to the include itself plus any tasks in the role that also have that ``when`` statement." +msgstr "ロール自体の中の個々のタスクまたはブロックに条件を追加します。これは、``when`` 文に基づいてロール内の一部のタスクを選択またはスキップすることができる唯一の方法です。ロール内のタスクを選択またはスキップするには、個々のタスクまたはブロックに条件を設定し、Playbook で動的 ``include_role`` を使用し、条件をインクルードに追加する必要があります。この方法を使用すると、Ansible は条件をインクルード自体に加えて、``when`` の文を持つロール内のすべてのタスクに適用します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:376 +msgid "When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds the conditions you define to all the tasks in the role. For example:" +msgstr "``roles`` キーワードを使用して Playbook にロールを静的に組み込むと、Ansible は定義した条件をロール内のすべてのタスクに追加します。たとえば、以下のようになります。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:388 +msgid "Selecting variables, files, or templates based on facts" +msgstr "ファクトに基づいた変数、ファイル、またはテンプレートの選択" + +#: ../../rst/user_guide/playbooks_conditionals.rst:390 +msgid "Sometimes the facts about a host determine the values you want to use for certain variables or even the file or template you want to select for that host. For example, the names of packages are different on CentOS and on Debian. The configuration files for common services are also different on different OS flavors and versions. To load different variables file, templates, or other files based on a fact about the hosts:" +msgstr "ホストに関するファクトによって、特定の変数に使用する値や、そのホスト用に選択するファイルやテンプレートが決定することがあります。たとえば、パッケージの名前は CentOS と Debian では異なります。また、一般的なサービスの設定ファイルも、OS のフレーバーやバージョンごとに異なります。ホストに関するファクトに基づいて、異なる変数ファイルやテンプレートなどを読み込むには、以下を行います。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:392 +msgid "name your vars files, templates, or files to match the Ansible fact that differentiates them" +msgstr "変数ファイル、テンプレート、またはファイルを区別する Ansible ファクトに合わせて名前を付ける" + +#: ../../rst/user_guide/playbooks_conditionals.rst:394 +msgid "select the correct vars file, template, or file for each host with a variable based on that Ansible fact" +msgstr "Ansible ファクトに基づいて変数を使用して、各ホストの正しい変数ファイル、テンプレート、またはファイルを選択します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:396 +msgid "Ansible separates variables from tasks, keeping your playbooks from turning into arbitrary code with nested conditionals. This approach results in more streamlined and auditable configuration rules because there are fewer decision points to track." +msgstr "Ansible は、変数とタスクを分離することで、Playbook がネストされた条件分岐による任意のコードにならないようにしています。このアプローチでは、追跡すべき決定ポイントが少なくなるため、より合理的で監査可能な設定ルールになります。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:399 +msgid "Selecting variables files based on facts" +msgstr "ファクトに基づく変数ファイルの選択" + +#: ../../rst/user_guide/playbooks_conditionals.rst:401 +msgid "You can create a playbook that works on multiple platforms and OS versions with a minimum of syntax by placing your variable values in vars files and conditionally importing them. If you want to install Apache on some CentOS and some Debian servers, create variables files with YAML keys and values. For example:" +msgstr "変数の値を vars ファイルに置き、条件付きでインポートすることで、最小限の構文で複数のプラットフォームや OS バージョンで動作する Playbook を作成することができます。一部の CentOS と一部の Debian サーバーに Apache をインストールする場合は、YAML のキーと値で変数ファイルを作成します。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:410 +msgid "Then import those variables files based on the facts you gather on the hosts in your playbook:" +msgstr "次に、Playbook のホストに収集するファクトに基づいて、これらの変数ファイルをインポートします。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:426 +msgid "Ansible gathers facts on the hosts in the webservers group, then interpolates the variable \"ansible_facts['os_family']\" into a list of filenames. If you have hosts with Red Hat operating systems (CentOS, for example), Ansible looks for 'vars/RedHat.yml'. If that file does not exist, Ansible attempts to load 'vars/os_defaults.yml'. For Debian hosts, Ansible first looks for 'vars/Debian.yml', before falling back on 'vars/os_defaults.yml'. If no files in the list are found, Ansible raises an error." +msgstr "Ansible は webservers グループに属するホストのファクトを収集し、変数「ansible_facts['os_family']」をファイル名のリストに補間します。Red Hat オペレーティングシステムを搭載したホスト (CentOS など) がある場合、Ansible は「vars/RedHat.yml」を探します。このファイルが存在しない場合、Ansibleは「vars/os_defaults.yml」の読み込みを試みます。Debian ホストの場合、Ansible はまず「vars/Debian.yml」を探し、その後で「vars/os_defaults.yml」にフォールバックします。リスト内のファイルが見つからない場合は、Ansible がエラーを出力します。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:429 +msgid "Selecting files and templates based on facts" +msgstr "ファクトに基づくファイルとテンプレートの選択" + +#: ../../rst/user_guide/playbooks_conditionals.rst:431 +msgid "You can use the same approach when different OS flavors or versions require different configuration files or templates. Select the appropriate file or template based on the variables assigned to each host. This approach is often much cleaner than putting a lot of conditionals into a single template to cover multiple OS or package versions." +msgstr "OS のフレーバーやバージョンによって、設定ファイルやテンプレートが異なる場合も同様の方法で対応できます。各ホストに割り当てられた変数に基づいて、適切なファイルやテンプレートを選択します。この方法は、複数の OS やパッケージのバージョンに対応するために 1 つのテンプレートに多くの条件分岐を入れるよりも、はるかにすっきりすることが多いです。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:433 +msgid "For example, you can template out a configuration file that is very different between, say, CentOS and Debian:" +msgstr "例えば、CentOS と Debian の間で大きく異なる設定ファイルをテンプレート化することができます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:451 +msgid "Commonly-used facts" +msgstr "一般的に使用されるファクト" + +#: ../../rst/user_guide/playbooks_conditionals.rst:453 +msgid "The following Ansible facts are frequently used in conditionals." +msgstr "以下の Ansible ファクトは、条件分岐で頻繁に使用されます。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:458 +msgid "ansible_facts['distribution']" +msgstr "ansible_facts['distribution']" + +#: ../../rst/user_guide/playbooks_conditionals.rst:460 +#: ../../rst/user_guide/playbooks_conditionals.rst:500 +msgid "Possible values (sample, not complete list):" +msgstr "使用できる値 (完全リストではなく一部です):" + +#: ../../rst/user_guide/playbooks_conditionals.rst:491 +msgid "ansible_facts['distribution_major_version']" +msgstr "ansible_facts['distribution_major_version']" + +#: ../../rst/user_guide/playbooks_conditionals.rst:493 +msgid "The major version of the operating system. For example, the value is `16` for Ubuntu 16.04." +msgstr "オペレーティングシステムのメジャーバージョンです。たとえば、Ubuntu 16.04 の場合は `16` となります。" + +#: ../../rst/user_guide/playbooks_conditionals.rst:498 +msgid "ansible_facts['os_family']" +msgstr "ansible_facts['os_family']" + +#: ../../rst/user_guide/playbooks_conditionals.rst:529 +#: ../../rst/user_guide/playbooks_error_handling.rst:270 +#: ../../rst/user_guide/playbooks_filters.rst:2187 +#: ../../rst/user_guide/playbooks_intro.rst:148 +#: ../../rst/user_guide/playbooks_loops.rst:480 +#: ../../rst/user_guide/playbooks_reuse.rst:219 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:17 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:594 +#: ../../rst/user_guide/playbooks_templating.rst:54 +#: ../../rst/user_guide/playbooks_tests.rst:519 +#: ../../rst/user_guide/playbooks_variables.rst:505 +#: ../../rst/user_guide/windows_dsc.rst:499 +#: ../../rst/user_guide/windows_faq.rst:252 +#: ../../rst/user_guide/windows_setup.rst:571 +#: ../../rst/user_guide/windows_usage.rst:510 +#: ../../rst/user_guide/windows_winrm.rst:1002 +msgid ":ref:`playbooks_best_practices`" +msgstr ":ref:`playbooks_best_practices`" + +#: ../../rst/user_guide/playbooks_conditionals.rst:530 +#: ../../rst/user_guide/playbooks_error_handling.rst:271 +#: ../../rst/user_guide/playbooks_filters.rst:2188 +#: ../../rst/user_guide/playbooks_loops.rst:481 +#: ../../rst/user_guide/playbooks_reuse.rst:220 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:18 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:595 +#: ../../rst/user_guide/playbooks_templating.rst:55 +#: ../../rst/user_guide/playbooks_tests.rst:520 +#: ../../rst/user_guide/playbooks_variables.rst:506 +#: ../../rst/user_guide/windows_dsc.rst:500 +#: ../../rst/user_guide/windows_faq.rst:253 +#: ../../rst/user_guide/windows_setup.rst:572 +#: ../../rst/user_guide/windows_usage.rst:511 +#: ../../rst/user_guide/windows_winrm.rst:1003 +msgid "Tips and tricks for playbooks" +msgstr "Playbook のヒントと裏技" + +#: ../../rst/user_guide/playbooks_debugger.rst:5 +msgid "Debugging tasks" +msgstr "タスクのデバッグ" + +#: ../../rst/user_guide/playbooks_debugger.rst:7 +msgid "Ansible offers a task debugger so you can fix errors during execution instead of editing your playbook and running it again to see if your change worked. You have access to all of the features of the debugger in the context of the task. You can check or set the value of variables, update module arguments, and re-run the task with the new variables and arguments. The debugger lets you resolve the cause of the failure and continue with playbook execution." +msgstr "Ansible にはタスクデバッガーがあり、変更が成功したかどうかを確認するために Playbook を編集して再度実行するのではなく、実行中にエラーを修正することができます。タスクのコンテキスト内で、デバッガーのすべての機能にアクセスできます。変数の値をチェックしたり設定したり、モジュールの引数を更新したり、新しい変数や引数を使用してタスクを再実行したりできます。デバッガーは、失敗の原因を解決し、Playbook の実行を続行することができます。" + +#: ../../rst/user_guide/playbooks_debugger.rst:13 +msgid "Enabling the debugger" +msgstr "デバッガーの有効化" + +#: ../../rst/user_guide/playbooks_debugger.rst:15 +msgid "The debugger is not enabled by default. If you want to invoke the debugger during playbook execution, you must enable it first." +msgstr "デバッガーはデフォルトでは有効になっていません。Playbook の実行中にデバッガーを呼び出す場合は、最初に有効にする必要があります。" + +#: ../../rst/user_guide/playbooks_debugger.rst:17 +msgid "Use one of these three methods to enable the debugger:" +msgstr "以下の 3 つの方法のいずれかを使用してデバッガーを有効にします。" + +#: ../../rst/user_guide/playbooks_debugger.rst:19 +msgid "with the debugger keyword" +msgstr "デバッガーキーワードの使用" + +#: ../../rst/user_guide/playbooks_debugger.rst:20 +msgid "in configuration or an environment variable, or" +msgstr "設定または環境変数で" + +#: ../../rst/user_guide/playbooks_debugger.rst:21 +msgid "as a strategy" +msgstr "ストラテジーとして" + +#: ../../rst/user_guide/playbooks_debugger.rst:24 +msgid "Enabling the debugger with the ``debugger`` keyword" +msgstr "``debugger`` キーワードでデバッガーを有効にする" + +#: ../../rst/user_guide/playbooks_debugger.rst:28 +msgid "You can use the ``debugger`` keyword to enable (or disable) the debugger for a specific play, role, block, or task. This option is especially useful when developing or extending playbooks, plays, and roles. You can enable the debugger on new or updated tasks. If they fail, you can fix the errors efficiently. The ``debugger`` keyword accepts five values:" +msgstr "``debugger`` キーワードを使用すると、特定のプレイ、ロール、ブロック、またはタスクに対してデバッガーを有効 (または無効) にすることができます。このオプションは、Playbook、プレイ、およびロールを開発または拡張する際に特に役立ちます。新規または更新されたタスクでデバッガーを有効にすることができます。失敗しても、効率的にエラーを修正することができます。``debugger`` キーワードは 5 つの値を受け入れます。" + +#: ../../rst/user_guide/playbooks_debugger.rst:34 +msgid "Value" +msgstr "値" + +#: ../../rst/user_guide/playbooks_debugger.rst:34 +msgid "Result" +msgstr "結果" + +#: ../../rst/user_guide/playbooks_debugger.rst:36 +msgid "always" +msgstr "always" + +#: ../../rst/user_guide/playbooks_debugger.rst:36 +msgid "Always invoke the debugger, regardless of the outcome" +msgstr "結果に関係なく、常にデバッガーを呼び出します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:38 +msgid "never" +msgstr "never" + +#: ../../rst/user_guide/playbooks_debugger.rst:38 +msgid "Never invoke the debugger, regardless of the outcome" +msgstr "結果に関係なく、デバッガーを呼び出しません。" + +#: ../../rst/user_guide/playbooks_debugger.rst:40 +msgid "on_failed" +msgstr "on_failed" + +#: ../../rst/user_guide/playbooks_debugger.rst:40 +msgid "Only invoke the debugger if a task fails" +msgstr "タスクが失敗した場合に限りデバッガーを呼び出します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:42 +msgid "on_unreachable" +msgstr "on_unreachable" + +#: ../../rst/user_guide/playbooks_debugger.rst:42 +msgid "Only invoke the debugger if a host is unreachable" +msgstr "ホストが到達できない場合に限りデバッガーを呼び出します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:44 +msgid "on_skipped" +msgstr "on_skipped" + +#: ../../rst/user_guide/playbooks_debugger.rst:44 +msgid "Only invoke the debugger if the task is skipped" +msgstr "タスクがスキップされた場合に限りデバッガーを呼び出します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:48 +msgid "When you use the ``debugger`` keyword, the value you specify overrides any global configuration to enable or disable the debugger. If you define ``debugger`` at multiple levels, such as in a role and in a task, Ansible honors the most granular definition. The definition at the play or role level applies to all blocks and tasks within that play or role, unless they specify a different value. The definition at the block level overrides the definition at the play or role level, and applies to all tasks within that block, unless they specify a different value. The definition at the task level always applies to the task; it overrides the definitions at the block, play, or role level." +msgstr "``debugger`` キーワードを使用すると、指定した値が、デバッガ―を有効または無効にするグローバル構成よりも優先されます。``debugger`` をロールやタスクなどの複数のレベルで定義した場合、Ansible は最も詳細な定義を尊重します。プレイまたはロールのレベルでの定義は、異なる値を指定しない限り、そのプレイまたはロール内のすべてのブロックおよびタスクに適用されます。ブロックレベルの定義は、プレイまたはロールレベルの定義よりも優先され、異なる値が指定されていない限り、そのブロック内のすべてのタスクに適用されます。タスクレベルでの定義は、常にタスクに適用され、ブロック、プレイ、またはロールレベルでの定義よりも優先されます。" + +#: ../../rst/user_guide/playbooks_debugger.rst:51 +msgid "Examples of using the ``debugger`` keyword" +msgstr "``debugger`` キーワードの使用例" + +#: ../../rst/user_guide/playbooks_debugger.rst:53 +msgid "Example of setting the ``debugger`` keyword on a task:" +msgstr "タスクに ``debugger`` キーワードを設定する例:" + +#: ../../rst/user_guide/playbooks_debugger.rst:61 +msgid "Example of setting the ``debugger`` keyword on a play:" +msgstr "プレイに ``debugger`` キーワードを設定する例:" + +#: ../../rst/user_guide/playbooks_debugger.rst:73 +msgid "Example of setting the ``debugger`` keyword at multiple levels:" +msgstr "複数のレベルで ``debugger`` キーワードを設定する例:" + +#: ../../rst/user_guide/playbooks_debugger.rst:85 +msgid "In this example, the debugger is set to ``never`` at the play level and to ``on_failed`` at the task level. If the task fails, Ansible invokes the debugger, because the definition on the task overrides the definition on its parent play." +msgstr "この例では、デバッガーは、プレイレベルでは ``never`` に、タスクレベルでは ``on_failed`` に設定されています。タスクが失敗した場合、タスクの定義が親プレイの定義を上書きするため、Ansible はデバッガーを起動します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:88 +msgid "Enabling the debugger in configuration or an environment variable" +msgstr "設定または環境変数でのデバッガーの有効化" + +#: ../../rst/user_guide/playbooks_debugger.rst:92 +msgid "You can enable the task debugger globally with a setting in ansible.cfg or with an environment variable. The only options are ``True`` or ``False``. If you set the configuration option or environment variable to ``True``, Ansible runs the debugger on failed tasks by default." +msgstr "タスクデバッガーをグローバルに有効にするには、ansible.cfg 内の設定または環境変数を使用します。オプションは ``True`` または ``False`` のみです。設定オプションまたは環境変数を ``True`` に設定した場合、Ansible はデフォルトで失敗したタスクに対してデバッガーを実行します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:94 +msgid "To enable the task debugger from ansible.cfg, add this setting to the defaults section:" +msgstr "ansible.cfg からタスクデバッガーを有効にするには、以下の設定を defaults セクションに追加します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:101 +msgid "To enable the task debugger with an environment variable, pass the variable when you run your playbook:" +msgstr "環境変数でタスクデバッガーを有効にするには、Playbook の実行時に変数を渡します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:107 +msgid "When you enable the debugger globally, every failed task invokes the debugger, unless the role, play, block, or task explicitly disables the debugger. If you need more granular control over what conditions trigger the debugger, use the ``debugger`` keyword." +msgstr "グローバルにデバッガを有効にすると、ロール、プレイ、ブロック、またはタスクが明示的にデバッガ―を無効にしていない限り、失敗したタスクはすべてデバッガ―を起動します。どのような条件でデバッガーが起動するかをより詳細に制御する必要がある場合は、``debugger`` キーワードを使用します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:110 +msgid "Enabling the debugger as a strategy" +msgstr "ストラテジーとしてのデバッガーの有効化" + +#: ../../rst/user_guide/playbooks_debugger.rst:112 +msgid "If you are running legacy playbooks or roles, you may see the debugger enabled as a :ref:`strategy <strategy_plugins>`. You can do this at the play level, in ansible.cfg, or with the environment variable ``ANSIBLE_STRATEGY=debug``. For example:" +msgstr "レガシーの Playbook やロールを実行している場合は、:ref:`strategy <strategy_plugins>` としてデバッガーが有効になっていることがあります。この設定は、プレイレベル、ansible.cfg、または環境変数 ``ANSIBLE_STRATEGY=debug`` で行うことができます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:121 +msgid "Or in ansible.cfg:" +msgstr "または ansible.cfg で以下を行います。" + +#: ../../rst/user_guide/playbooks_debugger.rst:130 +msgid "This backwards-compatible method, which matches Ansible versions before 2.5, may be removed in a future release." +msgstr "この後方互換性のある方法は、Ansible の 2.5 以前のバージョンに対応していますが、将来のリリースでは削除される可能性があります。" + +#: ../../rst/user_guide/playbooks_debugger.rst:133 +msgid "Resolving errors in the debugger" +msgstr "デバッガーでエラーの解決" + +#: ../../rst/user_guide/playbooks_debugger.rst:135 +msgid "After Ansible invokes the debugger, you can use the seven :ref:`debugger commands <available_commands>` to resolve the error that Ansible encountered. Consider this example playbook, which defines the ``var1`` variable but uses the undefined ``wrong_var`` variable in a task by mistake." +msgstr "Ansible がデバッガーを起動した後、7 つの :ref:`debugger コマンド <available_commands>` を使用して、Ansibleが遭遇したエラーを解決することができます。この Playbook の例では ``var1`` 変数を定義していますが、未定義の ``wrong_var`` 変数を誤ってタスクで使用します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:148 +msgid "If you run this playbook, Ansible invokes the debugger when the task fails. From the debug prompt, you can change the module arguments or the variables and run the task again." +msgstr "この Playbook を実行すると、Ansible はタスクの失敗時にデバッガーを呼び出します。デバッグプロンプトから、モジュール引数または変数を変更して、タスクを再度実行できます。" + +#: ../../rst/user_guide/playbooks_debugger.rst:183 +msgid "Changing the task arguments in the debugger to use ``var1`` instead of ``wrong_var`` makes the task run successfully." +msgstr "デバッガでタスクの引数 ``wrong_var`` の代わりに ``var1`` を使用するように変更すると、タスクが正常に実行されます。" + +#: ../../rst/user_guide/playbooks_debugger.rst:188 +msgid "Available debug commands" +msgstr "利用可能なデバッグコマンド" + +#: ../../rst/user_guide/playbooks_debugger.rst:190 +msgid "You can use these seven commands at the debug prompt:" +msgstr "これらの 7 つのコマンドは、デバッグプロンプトで使用できます。" + +#: ../../rst/user_guide/playbooks_debugger.rst:196 +msgid "Command" +msgstr "コマンド" + +#: ../../rst/user_guide/playbooks_debugger.rst:196 +msgid "Shortcut" +msgstr "ショートカット" + +#: ../../rst/user_guide/playbooks_debugger.rst:196 +msgid "Action" +msgstr "アクション" + +#: ../../rst/user_guide/playbooks_debugger.rst:198 +msgid "print" +msgstr "print" + +#: ../../rst/user_guide/playbooks_debugger.rst:198 +msgid "p" +msgstr "p" + +#: ../../rst/user_guide/playbooks_debugger.rst:198 +msgid "Print information about the task" +msgstr "タスクに関する情報を出力する" + +#: ../../rst/user_guide/playbooks_debugger.rst:200 +msgid "task.args[*key*] = *value*" +msgstr "task.args[*key*] = *value*" + +#: ../../rst/user_guide/playbooks_debugger.rst:200 +#: ../../rst/user_guide/playbooks_debugger.rst:202 +msgid "no shortcut" +msgstr "ショートカットなし" + +#: ../../rst/user_guide/playbooks_debugger.rst:200 +msgid "Update module arguments" +msgstr "モジュール引数を更新する" + +#: ../../rst/user_guide/playbooks_debugger.rst:202 +msgid "task_vars[*key*] = *value*" +msgstr "task_vars[*key*] = *value*" + +#: ../../rst/user_guide/playbooks_debugger.rst:202 +msgid "Update task variables (you must ``update_task`` next)" +msgstr "タスク変数を更新する (次回 ``update_task`` する必要があります)" + +#: ../../rst/user_guide/playbooks_debugger.rst:204 +msgid "update_task" +msgstr "update_task" + +#: ../../rst/user_guide/playbooks_debugger.rst:204 +msgid "u" +msgstr "u" + +#: ../../rst/user_guide/playbooks_debugger.rst:204 +msgid "Recreate a task with updated task variables" +msgstr "更新されたタスク変数でタスクを再作成する" + +#: ../../rst/user_guide/playbooks_debugger.rst:206 +msgid "redo" +msgstr "redo" + +#: ../../rst/user_guide/playbooks_debugger.rst:206 +msgid "r" +msgstr "r" + +#: ../../rst/user_guide/playbooks_debugger.rst:206 +msgid "Run the task again" +msgstr "タスクを再度実行する" + +#: ../../rst/user_guide/playbooks_debugger.rst:208 +msgid "continue" +msgstr "continue" + +#: ../../rst/user_guide/playbooks_debugger.rst:208 +msgid "c" +msgstr "c" + +#: ../../rst/user_guide/playbooks_debugger.rst:208 +msgid "Continue executing, starting with the next task" +msgstr "実行を継続する (次のタスクから開始)" + +#: ../../rst/user_guide/playbooks_debugger.rst:210 +msgid "quit" +msgstr "quit" + +#: ../../rst/user_guide/playbooks_debugger.rst:210 +msgid "q" +msgstr "q" + +#: ../../rst/user_guide/playbooks_debugger.rst:210 +msgid "Quit the debugger" +msgstr "デバッガーを終了する" + +#: ../../rst/user_guide/playbooks_debugger.rst:214 +msgid "For more details, see the individual descriptions and examples below." +msgstr "詳細は、以下の個別の説明および例を参照してください。" + +#: ../../rst/user_guide/playbooks_debugger.rst:219 +msgid "Print command" +msgstr "コマンドを出力する" + +#: ../../rst/user_guide/playbooks_debugger.rst:221 +msgid "``print *task/task.args/task_vars/host/result*`` prints information about the task." +msgstr "``print *task/task.args/task_vars/host/result*`` は、タスクに関する情報を出力します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:248 +msgid "Update args command" +msgstr "args コマンドを更新する" + +#: ../../rst/user_guide/playbooks_debugger.rst:250 +msgid "``task.args[*key*] = *value*`` updates a module argument. This sample playbook has an invalid package name." +msgstr "``task.args[*key*] = *value*`` モジュール引数を更新します。このサンプル Playbook には無効なパッケージ名があります。" + +#: ../../rst/user_guide/playbooks_debugger.rst:263 +msgid "When you run the playbook, the invalid package name triggers an error, and Ansible invokes the debugger. You can fix the package name by viewing, then updating the module argument." +msgstr "Playbook を実行すると、パッケージ名が無効であるためにエラーが発生し、Ansible がデバッガーを起動します。パッケージ名を修正するには、モジュールの引数を表示してから更新します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:274 +msgid "After you update the module argument, use ``redo`` to run the task again with the new args." +msgstr "モジュール引数を更新したら、``redo`` を使用して、新しい引数でタスクを再度実行します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:279 +msgid "Update vars command" +msgstr "vars コマンドの更新" + +#: ../../rst/user_guide/playbooks_debugger.rst:281 +msgid "``task_vars[*key*] = *value*`` updates the ``task_vars``. You could fix the playbook above by viewing, then updating the task variables instead of the module args." +msgstr "``task_vars[*key*] = *value*`` は、``task_vars`` を更新します。モジュール引数ではなくタスク変数を表示してから更新して、上記の Playbook を修正できます。" + +#: ../../rst/user_guide/playbooks_debugger.rst:293 +msgid "After you update the task variables, you must use ``update_task`` to load the new variables before using ``redo`` to run the task again." +msgstr "タスク変数を更新したら、``redo`` を使用してタスクを再実行する前に、``update_task`` を使用して新しい変数を読み込む必要があります。" + +#: ../../rst/user_guide/playbooks_debugger.rst:296 +msgid "In 2.5 this was updated from ``vars`` to ``task_vars`` to avoid conflicts with the ``vars()`` python function." +msgstr "これは、python 関数 ``vars()`` と競合しないように、2.5 で ``vars`` から ``task_vars`` に更新されました。" + +#: ../../rst/user_guide/playbooks_debugger.rst:301 +msgid "Update task command" +msgstr "task コマンドの更新" + +#: ../../rst/user_guide/playbooks_debugger.rst:305 +msgid "``u`` or ``update_task`` recreates the task from the original task data structure and templates with updated task variables. See the entry :ref:`update_vars_command` for an example of use." +msgstr "``u`` または ``update_task`` は、更新されたタスク変数を持つ元のタスクデータ構造とテンプレートからタスクを再作成します。使用例は、エントリー:ref:`update_vars_command` を参照してください。" + +#: ../../rst/user_guide/playbooks_debugger.rst:310 +msgid "Redo command" +msgstr "コマンドのやり直し" + +#: ../../rst/user_guide/playbooks_debugger.rst:312 +msgid "``r`` or ``redo`` runs the task again." +msgstr "``r`` または ``redo`` はタスクを再実行します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:317 +msgid "Continue command" +msgstr "コマンドの続行" + +#: ../../rst/user_guide/playbooks_debugger.rst:319 +msgid "``c`` or ``continue`` continues executing, starting with the next task." +msgstr "``c`` または ``continue`` は、次のタスクから開始して実行を継続します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:324 +msgid "Quit command" +msgstr "Quit コマンド" + +#: ../../rst/user_guide/playbooks_debugger.rst:326 +msgid "``q`` or ``quit`` quits the debugger. The playbook execution is aborted." +msgstr "``q`` または ``quit`` はデバッガーを終了します。Playbook の実行は中止します。" + +#: ../../rst/user_guide/playbooks_debugger.rst:329 +msgid "How the debugger interacts with the free strategy" +msgstr "デバッガーがフリーストラテジーとどのように相互作用するか" + +#: ../../rst/user_guide/playbooks_debugger.rst:331 +msgid "With the default ``linear`` strategy enabled, Ansible halts execution while the debugger is active, and runs the debugged task immediately after you enter the ``redo`` command. With the ``free`` strategy enabled, however, Ansible does not wait for all hosts, and may queue later tasks on one host before a task fails on another host. With the ``free`` strategy, Ansible does not queue or execute any tasks while the debugger is active. However, all queued tasks remain in the queue and run as soon as you exit the debugger. If you use ``redo`` to reschedule a task from the debugger, other queued tasks may execute before your rescheduled task. For more information about strategies, see :ref:`playbooks_strategies`." +msgstr "デフォルトの ``linear`` ストラテジーを有効にすると、Ansible はデバッガ―がアクティブな間は実行を停止し、``redo`` コマンドを入力した直後にデバッグされたタスクを実行します。しかし、``free`` ストラテジーを有効にすると、Ansible はすべてのホストを待たずに、別のホストでタスクが失敗する前に、あるホストで後のタスクをキューに入れることがあります。``free`` ストラテジーを使用すると、デバッガーがアクティブな間、Ansible は、タスクの照会や実行を行いません。ただし、キューに入れられたタスクはすべてキューに残り、デバッガーを終了するとすぐに実行されます。``redo`` を使用してデバッガーからタスクを再スケジュールすると、再スケジュールされたタスクの前にキューに入れられた他のタスクが実行する場合があります。ストラテジーの詳細については「:ref:`playbooks_strategies`」を参照してください。" + +#: ../../rst/user_guide/playbooks_debugger.rst:335 +msgid ":ref:`playbooks_start_and_step`" +msgstr ":ref:`playbooks_start_and_step`" + +#: ../../rst/user_guide/playbooks_debugger.rst:336 +msgid "Running playbooks while debugging or testing" +msgstr "デバッグ時またはテスト時の Playbook の実行" + +#: ../../rst/user_guide/playbooks_delegation.rst:4 +msgid "Controlling where tasks run: delegation and local actions" +msgstr "タスクの実行場所の制御: 委譲およびローカルアクション" + +#: ../../rst/user_guide/playbooks_delegation.rst:6 +msgid "By default Ansible gathers facts and executes all tasks on the machines that match the ``hosts`` line of your playbook. This page shows you how to delegate tasks to a different machine or group, delegate facts to specific machines or groups, or run an entire playbook locally. Using these approaches, you can manage inter-related environments precisely and efficiently. For example, when updating your webservers, you might need to remove them from a load-balanced pool temporarily. You cannot perform this task on the webservers themselves. By delegating the task to localhost, you keep all the tasks within the same play." +msgstr "デフォルトでは、Ansible はファクトを収集し、Playbook の ``hosts`` 行に一致するマシン上ですべてのタスクを実行します。このページでは、タスクを別のマシンやグループに委譲したり、ファクトを特定のマシンやグループに委譲したり、Playbook 全体をローカルで実行する方法を紹介します。これらの方法を用いることで、相互に関連する環境を正確かつ効率的に管理することができます。たとえば、Web サーバーを更新する際に、負荷分散したプールから一時的に Web サーバーを削除しないといけない場合があります。このタスクは、Web サーバー自身では実行できません。このタスクを localhost に委譲することで、すべてのタスクを同じプレイに収めることができます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:12 +msgid "Tasks that cannot be delegated" +msgstr "委譲できないタスク" + +#: ../../rst/user_guide/playbooks_delegation.rst:14 +msgid "Some tasks always execute on the controller. These tasks, including ``include``, ``add_host``, and ``debug``, cannot be delegated." +msgstr "一部のタスクは常にコントローラーで実行します。これらのタスクには、``include``、``add_host``、および ``debug`` を含むタスクを委譲できません。" + +#: ../../rst/user_guide/playbooks_delegation.rst:19 +msgid "Delegating tasks" +msgstr "タスクの委譲" + +#: ../../rst/user_guide/playbooks_delegation.rst:21 +msgid "If you want to perform a task on one host with reference to other hosts, use the ``delegate_to`` keyword on a task. This is ideal for managing nodes in a load balanced pool or for controlling outage windows. You can use delegation with the :ref:`serial <rolling_update_batch_size>` keyword to control the number of hosts executing at one time:" +msgstr "あるホストで他のホストを参照しながらタスクを実行したい場合は、タスクに ``delegate_to`` キーワードを使用します。これは、負荷分散されたプールのノードを管理したり、障害発生時のウィンドウを制御するのに最適です。:ref:`serial <rolling_update_batch_size>` キーワードで委譲を使用すると、一度に実行するホストの数を制御することができます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:43 +msgid "The first and third tasks in this play run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that you can use on a per-task basis: ``local_action``. Here is the same playbook as above, but using the shorthand syntax for delegating to 127.0.0.1:" +msgstr "ここでは、1 番目と 3 番目のタスクを 127.0.0.1 で実行していますが、これは Ansible を実行しているマシンです。また、タスクごとに使用できる簡略化された構文があります (``local_action``)。以下は、上記と同じ Playbook ですが、127.0.0.1 に委譲するための短縮構文を使用します。" + +#: ../../rst/user_guide/playbooks_delegation.rst:59 +msgid "You can use a local action to call 'rsync' to recursively copy files to the managed servers:" +msgstr "ローカルアクションを使用して「rsync」を呼び出し、管理対象のサーバーにファイルを再帰的にコピーすることができます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:70 +msgid "Note that you must have passphrase-less SSH keys or an ssh-agent configured for this to work, otherwise rsync asks for a passphrase." +msgstr "これが機能するためには、パスフレーズなしの SSH 鍵または ssh-agent が設定されていなければならないことに注意してください。そうでなければ、rsync はパスフレーズを要求します。" + +#: ../../rst/user_guide/playbooks_delegation.rst:72 +msgid "To specify more arguments, use the following syntax:" +msgstr "引数をさらに指定する必要がある場合は、以下の構文を使用できます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:89 +msgid "The `ansible_host` variable and other connection variables, if present, reflects information about the host a task is delegated to, not the inventory_hostname." +msgstr "`ansible_host` 変数と他の接続変数がある場合は、inventory_hostname ではなく、タスクが委譲されるホストに関する情報を反映します。" + +#: ../../rst/user_guide/playbooks_delegation.rst:93 +msgid "Although you can ``delegate_to`` a host that does not exist in inventory (by adding IP address, DNS name or whatever requirement the connection plugin has), doing so does not add the host to your inventory and might cause issues. Hosts delegated to in this way do not inherit variables from the \"all\" group', so variables like connection user and key are missing. If you must ``delegate_to`` a non-inventory host, use the :ref:`add host module <add_host_module>`." +msgstr "（IP アドレス、DNS 名、または接続プラグインの要件を追加することにより）インベントリーに存在しないホストを ``delegate_to`` にすることができますが、これを行うと、インベントリーにホストを追加せず、問題が発生する可能性があります。このように委譲されたホストは「すべて」グループから変数を継承しないため、接続ユーザーとキーなどの変数がありません。インベントリーホスト以外をのホストを ``delegate_to`` にする必要がある場合は、:ref:`add host module <add_host_module>` を使用します。" + +#: ../../rst/user_guide/playbooks_delegation.rst:99 +msgid "Delegation and parallel execution" +msgstr "委譲と並列実行" + +#: ../../rst/user_guide/playbooks_delegation.rst:100 +msgid "By default Ansible tasks are executed in parallel. Delegating a task does not change this and does not handle concurrency issues (multiple forks writing to the same file). Most commonly, users are affected by this when updating a single file on a single delegated to host for all hosts (using the ``copy``, ``template``, or ``lineinfile`` modules, for example). They will still operate in parallel forks (default 5) and overwrite each other." +msgstr "デフォルトでは、Ansible タスクは並行して実行されます。タスクを委譲してもこれは変更されず、同時実行の問題（複数のフォークが同じファイルに書き込む）は処理されません。最も一般的には、すべてのホストのホストに委任された単一のファイルを更新するときに、ユーザーはこれの影響を受けます（``copy``、``template``、 または``lineinfile`` モジュールなど）。それらは引き続き並列フォーク（デフォルトは 5）で動作し、相互に上書きします。" + +#: ../../rst/user_guide/playbooks_delegation.rst:103 +msgid "This can be handled in several ways:" +msgstr "これは複数の方法で処理できます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:112 +msgid "By using an intermediate play with `serial: 1` or using `throttle: 1` at task level, for more detail see :ref:`playbooks_strategies`" +msgstr "`serial: 1` で中間プレイを使用するか、タスクレベルで `throttle: 1` を使用します。詳細は、:ref:`playbooks_strategies`を参照してください。" + +#: ../../rst/user_guide/playbooks_delegation.rst:117 +msgid "Delegating facts" +msgstr "ファクトの委譲" + +#: ../../rst/user_guide/playbooks_delegation.rst:119 +msgid "Delegating Ansible tasks is like delegating tasks in the real world - your groceries belong to you, even if someone else delivers them to your home. Similarly, any facts gathered by a delegated task are assigned by default to the `inventory_hostname` (the current host), not to the host which produced the facts (the delegated to host). To assign gathered facts to the delegated host instead of the current host, set ``delegate_facts`` to ``true``:" +msgstr "Ansible のタスクを委譲することは、現実世界でタスクを委譲することと同じです。たとえ他の誰かがあなたの家に食料品を届けたとしても、あなたの食料品はあなたのものです。同様に、委譲されたタスクによって収集されたファクトは、デフォルトでは、ファクトを生成したホスト (委譲されたホスト) ではなく、`inventory_hostname` (現在のホスト) に割り当てられます。集めたファクトを現在のホストではなく委譲されたホストに割り当てるには、``delegate_facts`` を ``true`` に設定します。" + +#: ../../rst/user_guide/playbooks_delegation.rst:133 +msgid "This task gathers facts for the machines in the dbservers group and assigns the facts to those machines, even though the play targets the app_servers group. This way you can lookup `hostvars['dbhost1']['ansible_default_ipv4']['address']` even though dbservers were not part of the play, or left out by using `--limit`." +msgstr "このタスクは、プレイが app_servers グループを対象としているにもかかわらず、dbservers グループのマシンのファクトを収集し、それらのマシンにファクトを割り当てます。このようにして、たとえ dbservers がプレイの一部でなくても、あるいは `--limit` を使用して除外されていても、`hostvars['dbhost1']['ansible_default_ipv4']['address']` を調べることができます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:138 +msgid "Local playbooks" +msgstr "ローカルの Playbook" + +#: ../../rst/user_guide/playbooks_delegation.rst:140 +msgid "It may be useful to use a playbook locally on a remote host, rather than by connecting over SSH. This can be useful for assuring the configuration of a system by putting a playbook in a crontab. This may also be used to run a playbook inside an OS installer, such as an Anaconda kickstart." +msgstr "SSH で接続するのではなく、リモートホスト上でローカルに Playbook を使用することが便利な場合があります。これは、crontab に Playbook を置くことで、システムの構成を保証するのに役立ちます。また、Anaconda のキックスタートなど、OS インストーラー内で Playbook を実行する場合にも使用できます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:143 +msgid "To run an entire playbook locally, just set the ``hosts:`` line to ``hosts: 127.0.0.1`` and then run the playbook like so:" +msgstr "Playbook 全体をローカルで実行するには、``hosts:`` 行を ``hosts: 127.0.0.1`` に設定し、次のように Playbook を実行します。" + +#: ../../rst/user_guide/playbooks_delegation.rst:149 +msgid "Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook use the default remote connection type:" +msgstr "また、Playbook 内の他のプレイがデフォルトのリモート接続タイプを使用していても、1 つの Playbook のプレイでローカル接続を使用することもできます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:159 +msgid "If you set the connection to local and there is no ansible_python_interpreter set, modules will run under /usr/bin/python and not under {{ ansible_playbook_python }}. Be sure to set ansible_python_interpreter: \"{{ ansible_playbook_python }}\" in host_vars/localhost.yml, for example. You can avoid this issue by using ``local_action`` or ``delegate_to: localhost`` instead." +msgstr "接続先をローカルに設定し、ansible_python_interpreter が設定されていないと、モジュールは、{{ ansible_playbook_python }} ではなく /usr/bin/python で実行します。ansible_python_interpreter を必ず設定してください (host_vars/localhost.yml の「{{ ansible_playbook_python }}」など)。代わりに ``local_action`` または ``delegate_to: localhost`` を使用することで、この問題を回避できます。" + +#: ../../rst/user_guide/playbooks_delegation.rst:168 +msgid "More ways to control how and where Ansible executes" +msgstr "Ansible の実行方法および場所を制御する方法" + +#: ../../rst/user_guide/playbooks_delegation.rst:169 +msgid "`Ansible Examples on GitHub <https://github.com/ansible/ansible-examples>`_" +msgstr "`Ansible Examples on GitHub <https://github.com/ansible/ansible-examples>`_" + +#: ../../rst/user_guide/playbooks_delegation.rst:170 +msgid "Many examples of full-stack deployments" +msgstr "フルスタックデプロイメントの例が多数あります。" + +#: ../../rst/user_guide/playbooks_environment.rst:4 +msgid "Setting the remote environment" +msgstr "リモート環境の設定" + +#: ../../rst/user_guide/playbooks_environment.rst:8 +msgid "You can use the ``environment`` keyword at the play, block, or task level to set an environment variable for an action on a remote host. With this keyword, you can enable using a proxy for a task that does http requests, set the required environment variables for language-specific version managers, and more." +msgstr "プレイ、ブロック、またはタスクのレベルで ``environment`` キーワードを使用して、リモートホスト上のアクションに環境変数を設定することができます。このキーワードを使用すると、http リクエストを行うタスクでプロキシーの使用を有効にしたり、言語固有のバージョンマネージャーに必要な環境変数を設定したりすることができます。" + +#: ../../rst/user_guide/playbooks_environment.rst:10 +msgid "When you set a value with ``environment:`` at the play or block level, it is available only to tasks within the play or block that are executed by the same user. The ``environment:`` keyword does not affect Ansible itself, Ansible configuration settings, the environment for other users, or the execution of other plugins like lookups and filters. Variables set with ``environment:`` do not automatically become Ansible facts, even when you set them at the play level. You must include an explicit ``gather_facts`` task in your playbook and set the ``environment`` keyword on that task to turn these values into Ansible facts." +msgstr "プレイまたはブロックレベルで ``environment:`` を使用して値を設定すると、同じユーザーによって実行されるプレイまたはブロック内のタスクでのみ使用できます。``environment:`` キーワードは、Ansible 自体、Ansible の構成設定、他のユーザーの環境、ルックアップやフィルターなどの他のプラグインの実行には影響しません。``environment:`` で設定した変数は、プレイレベルで設定しても、自動的に Ansible のファクトにはなりません。これらの値を Ansible のファクトにするには、Playbook に明示的な ``gather_facts`` タスクを含め、そのタスクに ``environment`` キーワードを設定する必要があります。" + +#: ../../rst/user_guide/playbooks_environment.rst:16 +msgid "Setting the remote environment in a task" +msgstr "タスクへのリモート環境の設定" + +#: ../../rst/user_guide/playbooks_environment.rst:18 +msgid "You can set the environment directly at the task level." +msgstr "タスクレベルで環境を直接指定することもできます。" + +#: ../../rst/user_guide/playbooks_environment.rst:34 +msgid "You can re-use environment settings by defining them as variables in your play and accessing them in a task as you would access any stored Ansible variable." +msgstr "環境変数をプレイの変数として定義し、保存した Ansible 変数にアクセスするときにタスクからアクセスできることで、環境変数を再利用できます。" + +#: ../../rst/user_guide/playbooks_environment.rst:54 +msgid "You can store environment settings for re-use in multiple playbooks by defining them in a group_vars file." +msgstr "複数の Playbook に再使用する環境設定は、group_vars ファイルに定義することで保存できます。" + +#: ../../rst/user_guide/playbooks_environment.rst:67 +msgid "You can set the remote environment at the play level." +msgstr "プレイレベルでリモート環境を設定できます。" + +#: ../../rst/user_guide/playbooks_environment.rst:80 +msgid "These examples show proxy settings, but you can provide any number of settings this way." +msgstr "これらの例ではプロキシー設定を示していますが、この設定をいくつでも提供できます。" + +#: ../../rst/user_guide/playbooks_environment.rst:83 +msgid "Working with language-specific version managers" +msgstr "言語固有のバージョンマネージャーの使用" + +#: ../../rst/user_guide/playbooks_environment.rst:85 +msgid "Some language-specific version managers (such as rbenv and nvm) require you to set environment variables while these tools are in use. When using these tools manually, you usually source some environment variables from a script or from lines added to your shell configuration file. In Ansible, you can do this with the environment keyword at the play level." +msgstr "言語固有のバージョンマネージャー (rbenv や nvmなど) の中には、これらのツールを使用する際に環境変数を設定する必要があります。これらのツールを手動で使用する場合、通常はスクリプトやシェル構成ファイルに追加した行から環境変数を設定します。Ansible では、プレイレベルで環境キーワードを使用してこれを行うことができます。" + +#: ../../rst/user_guide/playbooks_environment.rst:124 +msgid "The example above uses ``ansible_env`` as part of the PATH. Basing variables on ``ansible_env`` is risky. Ansible populates ``ansible_env`` values by gathering facts, so the value of the variables depends on the remote_user or become_user Ansible used when gathering those facts. If you change remote_user/become_user the values in ``ansible_env`` may not be the ones you expect." +msgstr "上の例では、``ansible_env`` を PATH の一部として使用しています。変数を ``ansible_env`` に基づかせるのはリスクがあります。Ansible はファクトを収集して ``ansible_env`` の値を生成するため、変数の値はファクトの収集時に Ansible が使用した remote_user や become_user に依存します。remote_user/become_user を変更した場合、``ansible_env`` の値は期待したものとは異なる可能性があります。" + +#: ../../rst/user_guide/playbooks_environment.rst:127 +msgid "Environment variables are normally passed in clear text (shell plugin dependent) so they are not a recommended way of passing secrets to the module being executed." +msgstr "環境変数は、通常、(シェルプラグインに依存する) クリアテキストに渡されます。したがって、実行するモジュールにシークレットを渡す方法は推奨されません。" + +#: ../../rst/user_guide/playbooks_environment.rst:129 +msgid "You can also specify the environment at the task level." +msgstr "タスクレベルで環境を指定することもできます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:5 +msgid "Error handling in playbooks" +msgstr "Playbook でのエラー処理" + +#: ../../rst/user_guide/playbooks_error_handling.rst:7 +msgid "When Ansible receives a non-zero return code from a command or a failure from a module, by default it stops executing on that host and continues on other hosts. However, in some circumstances you may want different behavior. Sometimes a non-zero return code indicates success. Sometimes you want a failure on one host to stop execution on all hosts. Ansible provides tools and settings to handle these situations and help you get the behavior, output, and reporting you want." +msgstr "Ansible は、コマンドからゼロ以外の戻りコードを受け取った場合や、モジュールから失敗を受け取った場合、デフォルトでは、そのホストでの実行を停止し、他のホストで継続します。しかし、状況によっては異なる動作をさせたい場合があります。ゼロ以外の戻りコードが成功を示す場合もあります。あるホストで失敗したら、すべてのホストで実行を停止させたい場合もあります。Ansible には、このような状況に対応するためのツールや設定が用意されており、必要な動作、出力、レポートを得ることができます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:15 +msgid "Ignoring failed commands" +msgstr "失敗したコマンドの無視" + +#: ../../rst/user_guide/playbooks_error_handling.rst:17 +msgid "By default Ansible stops executing tasks on a host when a task fails on that host. You can use ``ignore_errors`` to continue on in spite of the failure." +msgstr "デフォルトでは、Ansible は、ホストでタスクが失敗すると、ホストでタスクの実行を停止します。``ignore_errors`` を使用すると、障害が発生しても続行されます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:25 +msgid "The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It does not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors." +msgstr "``ignore_errors`` ディレクティブは、タスクが実行可能で、「failed」という値を返す場合にのみ機能します。未定義の変数のエラー、接続の失敗、実行時の問題 (パッケージの欠落など)、構文エラーなどを Ansible に無視させるものではありません。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:30 +msgid "Ignoring unreachable host errors" +msgstr "到達不能なホストエラーを無視" + +#: ../../rst/user_guide/playbooks_error_handling.rst:34 +msgid "You can ignore a task failure due to the host instance being 'UNREACHABLE' with the ``ignore_unreachable`` keyword. Ansible ignores the task errors, but continues to execute future tasks against the unreachable host. For example, at the task level:" +msgstr "``ignore_unreachable`` キーワードで、ホストインスタンスが「UNREACHABLE」であることによるタスクの失敗を無視することができます。Ansible はタスクのエラーを無視しますが、到達不可能なホストに対して今後のタスクを実行し続けます。たとえば、タスクレベルでは以下のようになります。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:45 +msgid "And at the playbook level:" +msgstr "また、Playbook レベルでは以下を行います。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:62 +msgid "Resetting unreachable hosts" +msgstr "到達できないホストのリセット" + +#: ../../rst/user_guide/playbooks_error_handling.rst:64 +msgid "If Ansible cannot connect to a host, it marks that host as 'UNREACHABLE' and removes it from the list of active hosts for the run. You can use `meta: clear_host_errors` to reactivate all hosts, so subsequent tasks can try to reach them again." +msgstr "Ansible はホストに接続できない場合、そのホストを「UNREACHABLE」とマークし、実行時にアクティブなホストのリストから削除します。`meta: clear_host_errors` を使用してすべてのホストを再有効化することで、後続のタスクが再びホストに到達しようとすることができます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:70 +msgid "Handlers and failure" +msgstr "ハンドラーおよび失敗" + +#: ../../rst/user_guide/playbooks_error_handling.rst:72 +msgid "Ansible runs :ref:`handlers <handlers>` at the end of each play. If a task notifies a handler but another task fails later in the play, by default the handler does *not* run on that host, which may leave the host in an unexpected state. For example, a task could update a configuration file and notify a handler to restart some service. If a task later in the same play fails, the configuration file might be changed but the service will not be restarted." +msgstr "Ansible は、各プレイの最後に :ref:`handlers <handlers>` を実行します。タスクがハンドラーに通知しても、プレイの後半で別のタスクが失敗すると、デフォルトではハンドラーはそのホスト上で **実行されず**、ホストが予期せぬ状態になる可能性があります。たとえば、タスクが設定ファイルを更新し、ハンドラーにサービスの再起動を通知したとします。同じプレイの後半でタスクが失敗した場合、設定ファイルは変更するかもしれませんが、サービスは再起動しません。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:79 +msgid "You can change this behavior with the ``--force-handlers`` command-line option, by including ``force_handlers: True`` in a play, or by adding ``force_handlers = True`` to ansible.cfg. When handlers are forced, Ansible will run all notified handlers on all hosts, even hosts with failed tasks. (Note that certain errors could still prevent the handler from running, such as a host becoming unreachable.)" +msgstr "この動作は、``force_handlers: True`` をプレイに含めるか、``force_handlers = True`` を ansible.cfg に追加して、``--force-handlers`` コマンドラインオプションで変更できます。ハンドラーが強制的に実行すると、Ansible は通知されたすべてのハンドラーを、タスクが失敗したホストも含めてすべてのホストで実行します (ホストが到達不能になるなど、特定のエラーによってハンドラーの実行が妨げられる可能性があることに注意してください)。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:88 +msgid "Defining failure" +msgstr "障害の定義" + +#: ../../rst/user_guide/playbooks_error_handling.rst:90 +msgid "Ansible lets you define what \"failure\" means in each task using the ``failed_when`` conditional. As with all conditionals in Ansible, lists of multiple ``failed_when`` conditions are joined with an implicit ``and``, meaning the task only fails when *all* conditions are met. If you want to trigger a failure when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator." +msgstr "Ansible では、``failed_when`` 条件分岐を使用して、各タスクで「失敗」の意味を定義することができます。Ansible のすべての条件分岐と同様に、複数の ``failed_when`` 条件のリストは暗黙の ``and`` で結合されており、これは *すべての* 条件が満たされたときにのみタスクが失敗することを意味します。いずれかの条件が満たされたときに失敗をトリガーしたい場合は、明示的な ``or`` 演算子を使用して文字列で条件を定義する必要があります。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:92 +msgid "You may check for failure by searching for a word or phrase in the output of a command" +msgstr "コマンドの出力で単語またはフレーズを検索して、障害の有無を確認できます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:101 +msgid "or based on the return code" +msgstr "または、戻りコードに基いて確認できます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:110 +msgid "You can also combine multiple conditions for failure. This task will fail if both conditions are true:" +msgstr "複数の条件を組み合わせて失敗させることもできます。このタスクは、両方の条件が真であれば失敗します。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:121 +msgid "If you want the task to fail when only one condition is satisfied, change the ``failed_when`` definition to" +msgstr "条件が満たされたときにのみタスクが失敗する場合は、``failed_when`` 定義を以下のように変更します。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:127 +msgid "If you have too many conditions to fit neatly into one line, you can split it into a multi-line YAML value with ``>``." +msgstr "条件が多すぎて 1 行にうまく収まらない場合は、``>`` を使用して、これを複数行の YAML 値に分割できます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:142 +msgid "Defining \"changed\"" +msgstr "「変更済み」の定義" + +#: ../../rst/user_guide/playbooks_error_handling.rst:144 +msgid "Ansible lets you define when a particular task has \"changed\" a remote node using the ``changed_when`` conditional. This lets you determine, based on return codes or output, whether a change should be reported in Ansible statistics and whether a handler should be triggered or not. As with all conditionals in Ansible, lists of multiple ``changed_when`` conditions are joined with an implicit ``and``, meaning the task only reports a change when *all* conditions are met. If you want to report a change when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator. For example:" +msgstr "Ansible では、``changed_when`` 条件式を使用して、特定のタスクがリモートノードを「変更」したときを定義することができます。これにより、戻りコードや出力に基づいて、変更を Ansible の統計で報告するかどうか、ハンドラーをトリガーするかどうかを決定することができます。Ansible のすべての条件式と同様に、複数の ``changed_when`` 条件のリストは暗黙の ``and`` で結合されており、タスクは *すべての* 条件が満たされたときにのみ変更を報告することを意味します。いずれかの条件が満たされたときに変更を報告したい場合は、明示的な ``or`` 演算子を使用して文字列で条件を定義する必要があります。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:159 +msgid "You can also combine multiple conditions to override \"changed\" result." +msgstr "複数の条件を組み合わせて「変更」の結果を上書きすることもできます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:173 +msgid "Just like ``when`` these two conditionals do not require templating delimiters (``{{ }}``) as they are implied." +msgstr "``when`` と同様に、これら 2 つの条件には、暗黙の了解として、テンプレート化の区切り文字(``{{ }}``)は必要ありません。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:175 +msgid "See :ref:`controlling_what_defines_failure` for more conditional syntax examples." +msgstr "その他の条件付き構文例については、「:ref:`controlling_what_defines_failure`」を参照してください。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:178 +msgid "Ensuring success for command and shell" +msgstr "コマンドとシェルの成功の確認" + +#: ../../rst/user_guide/playbooks_error_handling.rst:180 +msgid "The :ref:`command <command_module>` and :ref:`shell <shell_module>` modules care about return codes, so if you have a command whose successful exit code is not zero, you can do this:" +msgstr ":ref:`command <command_module>` モジュールおよび :ref:`shell <shell_module>` モジュールは戻りコードを処理するため、正常な終了コードがゼロではないコマンドがある場合は、以下を行うことができます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:190 +msgid "Aborting a play on all hosts" +msgstr "すべてのホストでプレイを中止" + +#: ../../rst/user_guide/playbooks_error_handling.rst:192 +msgid "Sometimes you want a failure on a single host, or failures on a certain percentage of hosts, to abort the entire play on all hosts. You can stop play execution after the first failure happens with ``any_errors_fatal``. For finer-grained control, you can use ``max_fail_percentage`` to abort the run after a given percentage of hosts has failed." +msgstr "時には、1 つのホストでの失敗や、ある割合のホストでの失敗により、すべてのホストでのプレイ全体を中止させたいことがあります。``any_errors_fatal`` を使用すると、最初の失敗が発生した後にプレイの実行を停止することができます。より細かく制御するには、``max_fail_percentage`` を使用して、特定の割合のホストで失敗した後に実行を中止することができます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:195 +msgid "Aborting on the first error: any_errors_fatal" +msgstr "最初のエラーで強制終了: any_errors_fatal" + +#: ../../rst/user_guide/playbooks_error_handling.rst:197 +msgid "If you set ``any_errors_fatal`` and a task returns an error, Ansible finishes the fatal task on all hosts in the current batch, then stops executing the play on all hosts. Subsequent tasks and plays are not executed. You can recover from fatal errors by adding a :ref:`rescue section <block_error_handling>` to the block. You can set ``any_errors_fatal`` at the play or block level." +msgstr "``any_errors_fatal`` を設定し、タスクがエラーを返した場合、Ansible は現在のバッチ内のすべてのホストで致命的なタスクを終了し、すべてのホストでプレイの実行を停止します。後続のタスクやプレイは実行されません。致命的なエラーから回復するには、ブロックに :ref:`rescue section <block_error_handling>` を追加します。``any_errors_fatal`` は、プレイまたはブロックレベルで設定できます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:212 +#, python-format +msgid "You can use this feature when all tasks must be 100% successful to continue playbook execution. For example, if you run a service on machines in multiple data centers with load balancers to pass traffic from users to the service, you want all load balancers to be disabled before you stop the service for maintenance. To ensure that any failure in the task that disables the load balancers will stop all other tasks:" +msgstr "この機能は、Playbook の実行を継続するために、すべてのタスクが 100％ 成功する必要がある場合に使用できます。たとえば、複数のデータセンターにあるマシンでサービスを実行し、ユーザーからのトラフィックをサービスに渡すためにロードバランサーを使用している場合は、メンテナンスのためにサービスを停止する前に、すべてのロードバランサーを無効にします。ロードバランサーを無効にするタスクに障害が発生しても、他のすべてのタスクを停止させるには、次のようにします。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:239 +msgid "In this example Ansible starts the software upgrade on the front ends only if all of the load balancers are successfully disabled." +msgstr "この例では、すべてのロードバランサーが正常に無効になっている場合にのみ、Ansible が、フロントエンドでソフトウェアのアップグレードを開始します。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:244 +msgid "Setting a maximum failure percentage" +msgstr "最大失敗率の設定" + +#: ../../rst/user_guide/playbooks_error_handling.rst:246 +msgid "By default, Ansible continues to execute tasks as long as there are hosts that have not yet failed. In some situations, such as when executing a rolling update, you may want to abort the play when a certain threshold of failures has been reached. To achieve this, you can set a maximum failure percentage on a play:" +msgstr "デフォルトでは、Ansible はまだ失敗していないホストがある限り、タスクを実行し続けます。ローリングアップデートを実行する場合など、ある一定の失敗率に達したときにプレイを中断したい場合があります。これを可能にするには、プレイの最大失敗率を設定することができます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:255 +msgid "The ``max_fail_percentage`` setting applies to each batch when you use it with :ref:`serial <rolling_update_batch_size>`. In the example above, if more than 3 of the 10 servers in the first (or any) batch of servers failed, the rest of the play would be aborted." +msgstr "``max_fail_percentage`` の設定は、:ref:`serial <rolling_update_batch_size>` と一緒に使用すると、各バッチに適用されます。上の例では、最初の (あるいは任意の) バッチに含まれる 10 台のサーバーのうち 3 台以上が故障した場合、残りのプレイは中止されます。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:259 +msgid "The percentage set must be exceeded, not equaled. For example, if serial were set to 4 and you wanted the task to abort the play when 2 of the systems failed, set the max_fail_percentage at 49 rather than 50." +msgstr "設定されたパーセンテージは、同等ではなく、超えなければなりません。たとえば、serialが 4 に設定されていて、2 つのシステムが故障したときにプレイを中止するタスクにしたい場合は、max_fail_percentage を 50 ではなく 49 に設定します。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:262 +msgid "Controlling errors in blocks" +msgstr "ブロックのエラーを制御" + +#: ../../rst/user_guide/playbooks_error_handling.rst:264 +msgid "You can also use blocks to define responses to task errors. This approach is similar to exception handling in many programming languages. See :ref:`block_error_handling` for details and examples." +msgstr "ブロックを使用してタスクエラーへの応答を定義することもできます。この方法は、多くのプログラミング言語での例外処理に似ています。詳細と例は、「:ref:`block_error_handling`」を参照してください。" + +#: ../../rst/user_guide/playbooks_error_handling.rst:272 +#: ../../rst/user_guide/playbooks_filters.rst:2179 +#: ../../rst/user_guide/playbooks_lookups.rst:30 +#: ../../rst/user_guide/playbooks_loops.rst:482 +#: ../../rst/user_guide/playbooks_prompts.rst:117 +#: ../../rst/user_guide/playbooks_reuse.rst:215 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:21 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:598 +#: ../../rst/user_guide/playbooks_templating.rst:48 +#: ../../rst/user_guide/playbooks_tests.rst:511 +#: ../../rst/user_guide/playbooks_variables.rst:497 +msgid ":ref:`playbooks_conditionals`" +msgstr ":ref:`playbooks_conditionals`" + +#: ../../rst/user_guide/playbooks_error_handling.rst:273 +#: ../../rst/user_guide/playbooks_filters.rst:2180 +#: ../../rst/user_guide/playbooks_lookups.rst:31 +#: ../../rst/user_guide/playbooks_loops.rst:483 +#: ../../rst/user_guide/playbooks_prompts.rst:118 +#: ../../rst/user_guide/playbooks_templating.rst:49 +#: ../../rst/user_guide/playbooks_tests.rst:512 +#: ../../rst/user_guide/playbooks_variables.rst:498 +msgid "Conditional statements in playbooks" +msgstr "Playbook の条件分岐文" + +#: ../../rst/user_guide/playbooks_filters.rst:5 +msgid "Using filters to manipulate data" +msgstr "フィルターを使用したデータの操作" + +#: ../../rst/user_guide/playbooks_filters.rst:7 +msgid "Filters let you transform JSON data into YAML data, split a URL to extract the hostname, get the SHA1 hash of a string, add or multiply integers, and much more. You can use the Ansible-specific filters documented here to manipulate your data, or use any of the standard filters shipped with Jinja2 - see the list of :ref:`built-in filters <jinja2:builtin-filters>` in the official Jinja2 template documentation. You can also use :ref:`Python methods <jinja2:python-methods>` to transform data. You can :ref:`create custom Ansible filters as plugins <developing_filter_plugins>`, though we generally welcome new filters into the ansible-core repo so everyone can use them." +msgstr "フィルターを使用すると、JSON データを YAML データに変換したり、URL を分割してホスト名を抽出したり、文字列の SHA1 ハッシュを取得したり、整数を加算または乗算したりなど、さまざまなことができます。ここで紹介している Ansible 固有のフィルターを使用してデータを操作することもできますし、Jinja2 に同梱されている標準的なフィルターを使用することもできます。Jinja2 の公式テンプレートドキュメントの :ref:`組み込みフィルター <jinja2:builtin-filters>` のリストを参照してださい。また、:ref:`Python メソッド <jinja2:python-methods>` を使用してデータを変換することもできます。:ref:`カスタム Ansible フィルターをプラグインとして作成 <developing_filter_plugins>` することもできますが、通常は、誰もが使用できるように新しいフィルターを ansible-core リポジトリーに追加することが歓迎されています。" + +#: ../../rst/user_guide/playbooks_filters.rst:9 +msgid "Because templating happens on the Ansible controller, **not** on the target host, filters execute on the controller and transform data locally." +msgstr "テンプレート化はターゲットホスト上 **ではなく**、Ansible コントローラー上で行われるため、フィルターはコントローラ上で実行し、データはローカルに変換されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:15 +msgid "Handling undefined variables" +msgstr "未定義変数の処理" + +#: ../../rst/user_guide/playbooks_filters.rst:17 +msgid "Filters can help you manage missing or undefined variables by providing defaults or making some variables optional. If you configure Ansible to ignore most undefined variables, you can mark some variables as requiring values with the ``mandatory`` filter." +msgstr "フィルターは、デフォルトを指定したり、一部の変数を任意にしたりすることで、欠落している変数や未定義の変数を管理するのに役立ちます。ほとんどの未定義の変数を無視するように Ansibl eを設定した場合は、``mandatory`` フィルターを使用して、いくつかの変数を必要な値としてマークすることができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:22 +msgid "Providing default values" +msgstr "デフォルト値の指定" + +#: ../../rst/user_guide/playbooks_filters.rst:24 +msgid "You can provide default values for variables directly in your templates using the Jinja2 'default' filter. This is often a better approach than failing if a variable is not defined:" +msgstr "Jinja2 の「default」フィルターを使用すれば、テンプレートの中で直接、変数のデフォルト値を指定することができます。変数が定義されていない場合に失敗するよりも優れたアプローチであることがよくあります。" + +#: ../../rst/user_guide/playbooks_filters.rst:30 +msgid "In the above example, if the variable 'some_variable' is not defined, Ansible uses the default value 5, rather than raising an \"undefined variable\" error and failing. If you are working within a role, you can also add a ``defaults/main.yml`` to define the default values for variables in your role." +msgstr "上記の例では、変数「some_variable」が定義されていない場合、Ansible は「undefined variable」エラーを発生させて失敗するのではなく、デフォルト値 5 を使用します。ロール内で作業している場合は、``defaults/main.yml`` を追加して、ロール内の変数のデフォルト値を定義することもできます。" + +#: ../../rst/user_guide/playbooks_filters.rst:32 +msgid "Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use a default with a value in a nested data structure (in other words, :code:`{{ foo.bar.baz | default('DEFAULT') }}`) when you do not know if the intermediate values are defined." +msgstr "バージョン 2.8 から、Jinja で Undefined の値の属性にアクセスしようとすると、すぐにエラーが発生するのではなく、別の Undefined の値が返されます。これにより、中間値が定義されているかどうかわからない場合に、ネストされたデータ構造の中の値でデフォルトを簡単に使用することができるようになりました (つまり :code:`{{ foo.bar.baz | default('DEFAULT') }}`)。" + +#: ../../rst/user_guide/playbooks_filters.rst:35 +msgid "If you want to use the default value when variables evaluate to false or an empty string you have to set the second parameter to ``true``:" +msgstr "変数が false または空の文字列に評価されるときにデフォルト値を使用する場合は、2 番目のパラメーターを ``true`` に設定する必要があります。" + +#: ../../rst/user_guide/playbooks_filters.rst:44 +msgid "Making variables optional" +msgstr "変数の任意設定" + +#: ../../rst/user_guide/playbooks_filters.rst:46 +msgid "By default Ansible requires values for all variables in a templated expression. However, you can make specific variables optional. For example, you might want to use a system default for some items and control the value for others. To make a variable optional, set the default value to the special variable ``omit``:" +msgstr "デフォルトでは、Ansible はテンプレート式のすべての変数に値を要求します。しかし、特定の変数を任意にすることができます。たとえば、一部の項目ではシステムのデフォルト値を使用し、他の項目では値を制御することができます。変数を任意にするには、特殊変数 ``omit`` にデフォルト値を設定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:61 +msgid "In this example, the default mode for the files ``/tmp/foo`` and ``/tmp/bar`` is determined by the umask of the system. Ansible does not send a value for ``mode``. Only the third file, ``/tmp/baz``, receives the `mode=0444` option." +msgstr "この例では、``/tmp/foo`` ファイルおよび ``/tmp/bar`` ファイルのデフォルトモードはシステムの umask により決定されます。Ansible は ``mode`` の値を送信しません。3 番目のファイルである ``/tmp/baz`` だけが `mode=0444` オプションを受け取ります。" + +#: ../../rst/user_guide/playbooks_filters.rst:63 +msgid "If you are \"chaining\" additional filters after the ``default(omit)`` filter, you should instead do something like this: ``\"{{ foo | default(None) | some_filter or omit }}\"``. In this example, the default ``None`` (Python null) value will cause the later filters to fail, which will trigger the ``or omit`` portion of the logic. Using ``omit`` in this manner is very specific to the later filters you are chaining though, so be prepared for some trial and error if you do this." +msgstr "``default(omit)`` フィルターの後に追加のフィルターを「連鎖」させる場合は、代わりに ``\"{{ foo | default(None) | some_filter or omit }}\"`` のようにしてください。この例では、デフォルトの ``None`` (Python null) の値により、後続のフィルターが失敗し、ロジックの ``or omit`` 部分が誘発されます。``omit`` をこのように使用することは、連鎖させる後続のフィルターに非常に依存するため、試行錯誤が必要になります。" + +#: ../../rst/user_guide/playbooks_filters.rst:69 +msgid "Defining mandatory values" +msgstr "必須値の定義" + +#: ../../rst/user_guide/playbooks_filters.rst:71 +msgid "If you configure Ansible to ignore undefined variables, you may want to define some values as mandatory. By default, Ansible fails if a variable in your playbook or command is undefined. You can configure Ansible to allow undefined variables by setting :ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` to ``false``. In that case, you may want to require some variables to be defined. You can do this with:" +msgstr "未定義の変数を無視するように Ansible を設定する場合は、一部の値を必須として定義したい場合があります。デフォルトでは、Playbook またはコマンドの変数が未定義の場合、Ansible は失敗します。:ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` を ``false`` に設定することで、未定義の変数を許可するように Ansible を設定することができます。その場合は、一部の変数の定義を必須にしたい場合があります。これには次の方法があります。" + +#: ../../rst/user_guide/playbooks_filters.rst:77 +msgid "The variable value will be used as is, but the template evaluation will raise an error if it is undefined." +msgstr "変数の値はそのまま使用されますが、定義されていない場合は、テンプレートの評価でエラーが発生します。" + +#: ../../rst/user_guide/playbooks_filters.rst:79 +msgid "A convenient way of requiring a variable to be overridden is to give it an undefined value using the ``undef`` keyword. This can be useful in a role's defaults." +msgstr "変数の上書きを要求する便利な方法は、``undef`` キーワードを使用して未定義値を提供することです。これは、ロールのデフォルトで役に立ちます。" + +#: ../../rst/user_guide/playbooks_filters.rst:87 +msgid "Defining different values for true/false/null (ternary)" +msgstr "true/false/null (三項) に異なる値を定義する" + +#: ../../rst/user_guide/playbooks_filters.rst:89 +msgid "You can create a test, then define one value to use when the test returns true and another when the test returns false (new in version 1.9):" +msgstr "テストを作成し、そのテストが true を返したときに使用する値と、false を返したときに使用する値を定義することができます (バージョン 1.9 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:95 +msgid "In addition, you can define a one value to use on true, one value on false and a third value on null (new in version 2.8):" +msgstr "さらに、true に使用する値を 1 つ定義し、false で 1 つの値、null で 3 番目の値を定義できます (バージョン 2.8 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:102 +msgid "Managing data types" +msgstr "データ型の管理" + +#: ../../rst/user_guide/playbooks_filters.rst:104 +msgid "You might need to know, change, or set the data type on a variable. For example, a registered variable might contain a dictionary when your next task needs a list, or a user :ref:`prompt <playbooks_prompts>` might return a string when your playbook needs a boolean value. Use the ``type_debug``, ``dict2items``, and ``items2dict`` filters to manage data types. You can also use the data type itself to cast a value as a specific data type." +msgstr "変数のデータ型の確認、変更、または設定を行う必要がある場合があります。たとえば、次のタスクでリストが必要なときに、登録済みの変数にディクショナリーが含まれていたり、Playbook でブール値が必要なときに、ユーザーの :ref:`prompt <playbooks_prompts>` が文字列を返したりすることがあります。データタイプの管理には、``type_debug``、``dict2items``、および ``items2dict`` の各フィルターを使用します。また、データ型自体を使用して、値を特定のデータ型としてキャストすることもできます。" + +#: ../../rst/user_guide/playbooks_filters.rst:107 +msgid "Discovering the data type" +msgstr "データ型の検出" + +#: ../../rst/user_guide/playbooks_filters.rst:111 +msgid "If you are unsure of the underlying Python type of a variable, you can use the ``type_debug`` filter to display it. This is useful in debugging when you need a particular type of variable:" +msgstr "変数の基礎となる Python の型がわからない場合は、``type_debug`` フィルターを使用して表示することができます。これはデバッグ時に特定の型の変数が必要になったときに便利です。" + +#: ../../rst/user_guide/playbooks_filters.rst:117 +msgid "You should note that, while this may seem like a useful filter for checking that you have the right type of data in a variable, you should often prefer :ref:`type tests <type_tests>`, which will allow you to test for specific data types." +msgstr "このフィルターは、変数のデータ型が正しいかどうかをチェックするのに便利なように思えますが、特定のデータ型をテストできる:ref:`type tests <type_tests>`の方が良い場合が多いことに注意してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:122 +msgid "Transforming dictionaries into lists" +msgstr "ディクショナリーのリストへの変換" + +#: ../../rst/user_guide/playbooks_filters.rst:127 +msgid "Use the ``dict2items`` filter to transform a dictionary into a list of items suitable for :ref:`looping <playbooks_loops>`:" +msgstr "``dict2items`` フィルターを使用して、ディクショナリーを :ref:`looping <playbooks_loops>` に適した項目のリストに変換します。" + +#: ../../rst/user_guide/playbooks_filters.rst:133 +#: ../../rst/user_guide/playbooks_filters.rst:160 +msgid "Dictionary data (before applying the ``dict2items`` filter):" +msgstr "ディクショナリーデータ (``dict2items`` フィルターを適用する前):" + +#: ../../rst/user_guide/playbooks_filters.rst:141 +#: ../../rst/user_guide/playbooks_filters.rst:168 +msgid "List data (after applying the ``dict2items`` filter):" +msgstr "データを一覧表示 (``dict2items`` フィルターを適用した後):" + +#: ../../rst/user_guide/playbooks_filters.rst:152 +msgid "The ``dict2items`` filter is the reverse of the ``items2dict`` filter." +msgstr "``dict2items`` フィルターは、``items2dict`` フィルターの逆の効果があります。" + +#: ../../rst/user_guide/playbooks_filters.rst:154 +msgid "If you want to configure the names of the keys, the ``dict2items`` filter accepts 2 keyword arguments. Pass the ``key_name`` and ``value_name`` arguments to configure the names of the keys in the list output:" +msgstr "キー名を設定する場合は、``dict2items`` フィルターは 2 つのキーワード引数を受け入れます。``key_name`` 引数および ``value_name`` 引数を渡すと、リスト出力のキーの名前を設定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:179 +msgid "Transforming lists into dictionaries" +msgstr "リストのディクショナリーへの変換" + +#: ../../rst/user_guide/playbooks_filters.rst:183 +msgid "Use the ``items2dict`` filter to transform a list into a dictionary, mapping the content into ``key: value`` pairs:" +msgstr "``items2dict`` フィルターを使用してリストをディクショナリーに変換し、コンテンツを ``key: value`` のペアにマッピングします。" + +#: ../../rst/user_guide/playbooks_filters.rst:189 +msgid "List data (before applying the ``items2dict`` filter):" +msgstr "リストデータ (``items2dict`` フィルターを適用する前):" + +#: ../../rst/user_guide/playbooks_filters.rst:199 +msgid "Dictionary data (after applying the ``items2dict`` filter):" +msgstr "ディクショナリーデータ (``items2dict`` フィルターを適用した後):" + +#: ../../rst/user_guide/playbooks_filters.rst:206 +msgid "The ``items2dict`` filter is the reverse of the ``dict2items`` filter." +msgstr "``items2dict`` フィルターは、``dict2items`` フィルターの逆の効果があります。" + +#: ../../rst/user_guide/playbooks_filters.rst:208 +msgid "Not all lists use ``key`` to designate keys and ``value`` to designate values. For example:" +msgstr "すべてのリストで、キーの指定に ``key`` を使用し、値の指定に ``value`` を使用しているわけではありません。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_filters.rst:220 +msgid "In this example, you must pass the ``key_name`` and ``value_name`` arguments to configure the transformation. For example:" +msgstr "この例では、``key_name`` 引数と ``value_name`` 引数を渡すと、変換を設定する必要があります。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_filters.rst:226 +msgid "If you do not pass these arguments, or do not pass the correct values for your list, you will see ``KeyError: key`` or ``KeyError: my_typo``." +msgstr "これらの引数、またはリストに適した値を渡さない場合は、``KeyError: key`` または ``KeyError: my_typo`` が表示されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:229 +msgid "Forcing the data type" +msgstr "データ型を強制" + +#: ../../rst/user_guide/playbooks_filters.rst:231 +msgid "You can cast values as certain types. For example, if you expect the input \"True\" from a :ref:`vars_prompt <playbooks_prompts>` and you want Ansible to recognize it as a boolean value instead of a string:" +msgstr "値を特定の型にキャストすることができます。たとえば、:ref:`vars_prompt <playbooks_prompts>` から「True」という入力を期待していて、Ansible にそれを文字列ではなくブール値として認識させたい場合は、次のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:239 +msgid "If you want to perform a mathematical comparison on a fact and you want Ansible to recognize it as an integer instead of a string:" +msgstr "ファクトに対して数学的な比較を実行し、Ansible が文字列ではなく整数として認識する場合は、以下を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:252 +msgid "Formatting data: YAML and JSON" +msgstr "データのフォーマット: YAML および JSON" + +#: ../../rst/user_guide/playbooks_filters.rst:254 +msgid "You can switch a data structure in a template from or to JSON or YAML format, with options for formatting, indenting, and loading data. The basic filters are occasionally useful for debugging:" +msgstr "テンプレート内のデータ構造を JSON 形式と YAML 形式との間で切り替えることができ、フォーマット化やインデント付け、データの読み込みなどのオプションも用意されています。基本的なフィルターは、時折、デバッグに役立ちます。" + +#: ../../rst/user_guide/playbooks_filters.rst:261 +msgid "For human readable output, you can use:" +msgstr "人が判読できる出力にするには、以下を使用できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:268 +msgid "You can change the indentation of either format:" +msgstr "いずれかの形式のインデントを変更できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:275 +msgid "The ``to_yaml`` and ``to_nice_yaml`` filters use the `PyYAML library`_ which has a default 80 symbol string length limit. That causes unexpected line break after 80th symbol (if there is a space after 80th symbol) To avoid such behavior and generate long lines, use the ``width`` option. You must use a hardcoded number to define the width, instead of a construction like ``float(\"inf\")``, because the filter does not support proxying Python functions. For example:" +msgstr "``to_yaml`` フィルターおよび ``to_nice_yaml`` フィルターは、デフォルトで 80 記号の文字列長制限を持つ `PyYAML library`_ を使用しています。このため、80 番目の記号の後に予期せぬ改行が発生します (80 番目のシンボルの後に空白がある場合)。このような動作を回避し、長い行を生成するには、``width`` オプションを使用します。フィルターは Python 関数のプロキシーをサポートしていないため、``float(\"inf\")`` のような構文ではなく、ハードコードされた数値を使用して幅を定義する必要があります。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_filters.rst:283 +msgid "The filter does support passing through other YAML parameters. For a full list, see the `PyYAML documentation`_ for ``dump()``." +msgstr "フィルターは他の YAML パラメーターのパススルーをサポートします。完全な一覧は、``dump()``の「`PyYAML ドキュメント`_」を参照してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:285 +msgid "If you are reading in some already formatted data:" +msgstr "すでにフォーマットされている一部のデータで読み取る場合:" + +#: ../../rst/user_guide/playbooks_filters.rst:292 +#: ../../rst/user_guide/playbooks_filters.rst:334 +msgid "for example:" +msgstr "以下に例を示します。" + +#: ../../rst/user_guide/playbooks_filters.rst:307 +msgid "Filter `to_json` and Unicode support" +msgstr "`to_json` と Unicode サポートをフィルタリング" + +#: ../../rst/user_guide/playbooks_filters.rst:309 +msgid "By default `to_json` and `to_nice_json` will convert data received to ASCII, so:" +msgstr "デフォルトでは、`to_json` および `to_nice_json` は、受診したデータを ASCII に変換するため、次のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:315 +msgid "will return:" +msgstr "以下が返されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:321 +msgid "To keep Unicode characters, pass the parameter `ensure_ascii=False` to the filter:" +msgstr "Unicode 文字を保持するには、パラメーター `ensure_ascii=False` をフィルターに渡します。" + +#: ../../rst/user_guide/playbooks_filters.rst:331 +msgid "To parse multi-document YAML strings, the ``from_yaml_all`` filter is provided. The ``from_yaml_all`` filter will return a generator of parsed YAML documents." +msgstr "複数ドキュメントの YAML 文字列を解析するために、``from_yaml_all`` フィルターが提供されます。``from_yaml_all`` フィルターは解析された YAML ドキュメントのジェネレーターを返します。" + +#: ../../rst/user_guide/playbooks_filters.rst:349 +msgid "Combining and selecting data" +msgstr "データの統合および選択" + +#: ../../rst/user_guide/playbooks_filters.rst:351 +msgid "You can combine data from multiple sources and types, and select values from large data structures, giving you precise control over complex data." +msgstr "複数のソースやタイプのデータを組み合わせたり、大規模なデータ構造から値を選択したりすることで、複雑なデータを正確に制御することができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:356 +msgid "Combining items from multiple lists: zip and zip_longest" +msgstr "複数のリストからの項目の組み合わせ: zip および zip_longest" + +#: ../../rst/user_guide/playbooks_filters.rst:360 +msgid "To get a list combining the elements of other lists use ``zip``:" +msgstr "他のリストの要素を組み合わせたリストを取得するには、``zip`` を使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:376 +msgid "To always exhaust all lists use ``zip_longest``:" +msgstr "すべての一覧を常に使い切るには、``zip_longest`` を使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:386 +msgid "Similarly to the output of the ``items2dict`` filter mentioned above, these filters can be used to construct a ``dict``:" +msgstr "上記の ``items2dict`` フィルターの出力と同様に、これらのフィルターを使用して ``dict`` を作成できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:392 +msgid "List data (before applying the ``zip`` filter):" +msgstr "リストデータ (``zip`` フィルターを適用する前):" + +#: ../../rst/user_guide/playbooks_filters.rst:403 +msgid "Dictionary data (after applying the ``zip`` filter):" +msgstr "ディクショナリーデータ (``zip`` フィルターを適用した後):" + +#: ../../rst/user_guide/playbooks_filters.rst:411 +msgid "Combining objects and subelements" +msgstr "オブジェクトとサブ要素の統合" + +#: ../../rst/user_guide/playbooks_filters.rst:415 +msgid "The ``subelements`` filter produces a product of an object and the subelement values of that object, similar to the ``subelements`` lookup. This lets you specify individual subelements to use in a template. For example, this expression:" +msgstr "``subelements`` フィルターは、``subelements`` ルックアップと同様に、オブジェクトとそのオブジェクトのサブエレメントの値の積を生成します。これにより、テンプレートで使用する個々のサブエレメントを指定することができます。たとえば、以下のような式になります。" + +#: ../../rst/user_guide/playbooks_filters.rst:421 +msgid "Data before applying the ``subelements`` filter:" +msgstr "``subelements`` フィルターの適用前のデータ:" + +#: ../../rst/user_guide/playbooks_filters.rst:439 +msgid "Data after applying the ``subelements`` filter:" +msgstr "``subelements`` フィルターの適用後のデータ:" + +#: ../../rst/user_guide/playbooks_filters.rst:469 +msgid "You can use the transformed data with ``loop`` to iterate over the same subelement for multiple objects:" +msgstr "変換したデータを ``loop`` とともに使用して、複数のオブジェクトに対して同じサブ要素を繰り返すことができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:482 +msgid "Combining hashes/dictionaries" +msgstr "ハッシュ/ディクショナリーの統合" + +#: ../../rst/user_guide/playbooks_filters.rst:486 +msgid "The ``combine`` filter allows hashes to be merged. For example, the following would override keys in one hash:" +msgstr "``combine`` フィルターはハッシュをマージできます。たとえば、以下は 1 つのハッシュ内のキーをオーバーライドします。" + +#: ../../rst/user_guide/playbooks_filters.rst:492 +msgid "The resulting hash would be:" +msgstr "生成されるハッシュは、以下のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:498 +msgid "The filter can also take multiple arguments to merge:" +msgstr "フィルターは複数の引数を使用してマージすることもできます。" + +#: ../../rst/user_guide/playbooks_filters.rst:505 +msgid "In this case, keys in ``d`` would override those in ``c``, which would override those in ``b``, and so on." +msgstr "この場合、``d`` のキーは ``c`` のキーを上書きし、``b`` のキーも同様に上書きされます。" + +#: ../../rst/user_guide/playbooks_filters.rst:507 +msgid "The filter also accepts two optional parameters: ``recursive`` and ``list_merge``." +msgstr "フィルターは、``recursive`` および ``list_merge`` の 2 つの任意のパラメーターも使用できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:512 +msgid "recursive" +msgstr "再帰" + +#: ../../rst/user_guide/playbooks_filters.rst:510 +msgid "Is a boolean, default to ``False``. Should the ``combine`` recursively merge nested hashes. Note: It does **not** depend on the value of the ``hash_behaviour`` setting in ``ansible.cfg``." +msgstr "ブール値で、デフォルトは ``False`` です。``combine`` が入れ子になったハッシュを再帰的にマージするかどうかを指定します。注: ``ansible.cfg`` の ``hash_behaviour`` 設定の値には **依存しません** 。" + +#: ../../rst/user_guide/playbooks_filters.rst:516 +msgid "list_merge" +msgstr "list_merge" + +#: ../../rst/user_guide/playbooks_filters.rst:515 +msgid "Is a string, its possible values are ``replace`` (default), ``keep``, ``append``, ``prepend``, ``append_rp`` or ``prepend_rp``. It modifies the behaviour of ``combine`` when the hashes to merge contain arrays/lists." +msgstr "使用できる値は ``replace`` (デフォルト)、``keep``、``append``、``prepend``、``append_rp``、または ``prepend_rp`` です。ハッシュに配列/リストをマージする際に ``combine`` の動作を変更します。" + +#: ../../rst/user_guide/playbooks_filters.rst:532 +msgid "If ``recursive=False`` (the default), nested hash aren't merged:" +msgstr "``recursive=False`` (デフォルト) の場合は、ネストされたハッシュがマージされません。" + +#: ../../rst/user_guide/playbooks_filters.rst:538 +#: ../../rst/user_guide/playbooks_filters.rst:554 +#: ../../rst/user_guide/playbooks_filters.rst:580 +#: ../../rst/user_guide/playbooks_filters.rst:593 +#: ../../rst/user_guide/playbooks_filters.rst:606 +#: ../../rst/user_guide/playbooks_filters.rst:620 +#: ../../rst/user_guide/playbooks_filters.rst:649 +#: ../../rst/user_guide/playbooks_filters.rst:668 +#: ../../rst/user_guide/playbooks_filters.rst:714 +#: ../../rst/user_guide/playbooks_filters.rst:817 +msgid "This would result in:" +msgstr "これにより、以下のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:548 +msgid "If ``recursive=True``, recurse into nested hash and merge their keys:" +msgstr "``recursive=True`` の場合は、ネストされたハッシュを再帰的に使用して、鍵をマージします。" + +#: ../../rst/user_guide/playbooks_filters.rst:565 +msgid "If ``list_merge='replace'`` (the default), arrays from the right hash will \"replace\" the ones in the left hash:" +msgstr "``list_merge='replace'`` (デフォルト) の場合、右ハッシュの配列は左ハッシュの配列を「置き換え」ます。" + +#: ../../rst/user_guide/playbooks_filters.rst:587 +msgid "If ``list_merge='keep'``, arrays from the left hash will be kept:" +msgstr "``list_merge='keep'`` の場合は、左のハッシュからの配列が保持されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:600 +msgid "If ``list_merge='append'``, arrays from the right hash will be appended to the ones in the left hash:" +msgstr "``list_merge='append'`` の場合は、右のハッシュからの配列が左のハッシュ内の配列に追加されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:614 +msgid "If ``list_merge='prepend'``, arrays from the right hash will be prepended to the ones in the left hash:" +msgstr "``list_merge='prepend'`` の場合は、右のハッシュからの配列が左のハッシュ内の配列の前に追加されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:628 +msgid "If ``list_merge='append_rp'``, arrays from the right hash will be appended to the ones in the left hash. Elements of arrays in the left hash that are also in the corresponding array of the right hash will be removed (\"rp\" stands for \"remove present\"). Duplicate elements that aren't in both hashes are kept:" +msgstr "``list_merge='append_rp'`` の場合は、右ハッシュの配列が、左ハッシュの配列に追加されます。左ハッシュの配列のうち、右ハッシュの対応する配列にもある要素は削除されます (「rp」は「remove present」の略)。両方のハッシュに存在しない重複した要素は保持されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:662 +msgid "If ``list_merge='prepend_rp'``, the behavior is similar to the one for ``append_rp``, but elements of arrays in the right hash are prepended:" +msgstr "``list_merge='prepend_rp'`` の場合、動作は ``append_rp`` のものと似ていますが、右のハッシュ内の配列の要素の前に追加されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:681 +msgid "``recursive`` and ``list_merge`` can be used together:" +msgstr "``recursive`` および ``list_merge`` は一緒に使用できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:739 +msgid "Selecting values from arrays or hashtables" +msgstr "配列またはハッシュテーブルからの値の選択" + +#: ../../rst/user_guide/playbooks_filters.rst:743 +msgid "The `extract` filter is used to map from a list of indices to a list of values from a container (hash or array):" +msgstr "`extract` フィルターは、インデックスのリストから、コンテナー (ハッシュまたは配列) の値のリストへのマッピングに使用されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:750 +msgid "The results of the above expressions would be:" +msgstr "上記の式の結果は、以下のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:757 +msgid "The filter can take another argument:" +msgstr "フィルターは別の引数を取ることができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:763 +msgid "This takes the list of hosts in group 'x', looks them up in `hostvars`, and then looks up the `ec2_ip_address` of the result. The final result is a list of IP addresses for the hosts in group 'x'." +msgstr "これにより、グループ「x」のホスト一覧が `hostvars` で検索され、結果の `ec2_ip_address` を探します。最終結果は、グループ「x」のホストの IP アドレス一覧になります。" + +#: ../../rst/user_guide/playbooks_filters.rst:765 +msgid "The third argument to the filter can also be a list, for a recursive lookup inside the container:" +msgstr "フィルターの第 3 引数にはリストを指定することもでき、コンテナー内の再帰的なルックアップが可能です。" + +#: ../../rst/user_guide/playbooks_filters.rst:771 +msgid "This would return a list containing the value of `b['a']['x']['y']`." +msgstr "これにより、`b['a']['x']['y']` の値が含まれるリストが返されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:774 +msgid "Combining lists" +msgstr "リストの統合" + +#: ../../rst/user_guide/playbooks_filters.rst:776 +msgid "This set of filters returns a list of combined lists." +msgstr "このフィルターセットは、組み合わせたリストを返します。" + +#: ../../rst/user_guide/playbooks_filters.rst:780 +msgid "permutations" +msgstr "置換" + +#: ../../rst/user_guide/playbooks_filters.rst:781 +msgid "To get permutations of a list:" +msgstr "リストの置換を取得するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:794 +msgid "combinations" +msgstr "組み合わせ" + +#: ../../rst/user_guide/playbooks_filters.rst:795 +msgid "Combinations always require a set size:" +msgstr "組み合わせには常にセットサイズが必要です。" + +#: ../../rst/user_guide/playbooks_filters.rst:803 +msgid "Also see the :ref:`zip_filter`" +msgstr "また、「:ref:`zip_filter`」を参照してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:806 +msgid "products" +msgstr "製品" + +#: ../../rst/user_guide/playbooks_filters.rst:807 +msgid "The product filter returns the `cartesian product <https://docs.python.org/3/library/itertools.html#itertools.product>`_ of the input iterables. This is roughly equivalent to nested for-loops in a generator expression." +msgstr "製品フィルターは、入力されたイテラブルの `cartesian product <https://docs.python.org/3/library/itertools.html#itertools.product>`_ を返します。これはジェネレータ式の入れ子になった for-loop とほぼ同じです。" + +#: ../../rst/user_guide/playbooks_filters.rst:826 +msgid "Selecting JSON data: JSON queries" +msgstr "JSON データの選択: JSON クエリー" + +#: ../../rst/user_guide/playbooks_filters.rst:828 +msgid "To select a single element or a data subset from a complex data structure in JSON format (for example, Ansible facts), use the ``json_query`` filter. The ``json_query`` filter lets you query a complex JSON structure and iterate over it using a loop structure." +msgstr "JSON 形式の複雑なデータ構造 (Ansible ファクトなど) から単一の要素やデータサブセットを選択するには、``json_query`` フィルターを使用します。``json_query`` フィルターを使用すると、複雑な JSON 構造を照会し、ループ構造を使用して反復処理することができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:832 +#: ../../rst/user_guide/playbooks_filters.rst:991 +msgid "This filter has migrated to the `community.general <https://galaxy.ansible.com/community/general>`_ collection. Follow the installation instructions to install that collection." +msgstr "`community.general <https://galaxy.ansible.com/community/general>`_ フィルターはコレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" + +#: ../../rst/user_guide/playbooks_filters.rst:835 +msgid "You must manually install the **jmespath** dependency on the Ansible controller before using this filter. This filter is built upon **jmespath**, and you can use the same syntax. For examples, see `jmespath examples <https://jmespath.org/examples.html>`_." +msgstr "このフィルターを使用する前に、Ansible コントローラーに **jmespath** 依存関係を手動でインストールする必要があります。このフィルターは **jmespath** をベースに作られており、同じ構文を使用することができます。例については、`jmespath examples <https://jmespath.org/examples.html>`_ を参照してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:837 +msgid "Consider this data structure:" +msgstr "このデータ構造を考えてみましょう。" + +#: ../../rst/user_guide/playbooks_filters.rst:888 +msgid "To extract all clusters from this structure, you can use the following query:" +msgstr "この構造からすべてのクラスターを抽出するには、以下のクエリーを使用できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:897 +msgid "To extract all server names:" +msgstr "すべてのサーバー名を抽出するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:906 +msgid "To extract ports from cluster1:" +msgstr "cluster1 からポートを抽出するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:917 +msgid "You can use a variable to make the query more readable." +msgstr "変数を使用すると、クエリーの読み取りがより容易になります。" + +#: ../../rst/user_guide/playbooks_filters.rst:919 +msgid "To print out the ports from cluster1 in a comma separated string:" +msgstr "cluster1 のポートをコンマ区切りの文字列で表示するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:927 +msgid "In the example above, quoting literals using backticks avoids escaping quotes and maintains readability." +msgstr "上の例では、リテラルを backtick で引用することで、引用符のエスケープを避け、読みやすさを維持しています。" + +#: ../../rst/user_guide/playbooks_filters.rst:929 +msgid "You can use YAML `single quote escaping <https://yaml.org/spec/current.html#id2534365>`_:" +msgstr "YAML の `single quote escaping <https://yaml.org/spec/current.html#id2534365>`_ を使用できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:938 +msgid "Escaping single quotes within single quotes in YAML is done by doubling the single quote." +msgstr "YAML の一重引用符内で一重引用符をエスケープする場合は、一重引用符を二重にします。" + +#: ../../rst/user_guide/playbooks_filters.rst:940 +msgid "To get a hash map with all ports and names of a cluster:" +msgstr "クラスターのすべてのポートおよび名前を持つハッシュマップを取得するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:951 +msgid "To extract ports from all clusters with name starting with 'server1':" +msgstr "「server1」で始まる名前の全クラスターからポートを抽出するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:961 +msgid "To extract ports from all clusters with name containing 'server1':" +msgstr "「server1」を含む名前の全クラスターからポートを抽出するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:971 +msgid "while using ``starts_with`` and ``contains``, you have to use `` to_json | from_json `` filter for correct parsing of data structure." +msgstr "``starts_with`` および ``contains`` を使用する場合は、データ構造を正しく解析するために ``to_json | from_json`` フィルターを使用する必要があります。" + +#: ../../rst/user_guide/playbooks_filters.rst:975 +msgid "Randomizing data" +msgstr "データのランダム化" + +#: ../../rst/user_guide/playbooks_filters.rst:977 +msgid "When you need a randomly generated value, use one of these filters." +msgstr "ランダムに生成された値が必要な場合は、これらのフィルターのいずれかを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:983 +msgid "Random MAC addresses" +msgstr "ランダムな MAC アドレス" + +#: ../../rst/user_guide/playbooks_filters.rst:987 +msgid "This filter can be used to generate a random MAC address from a string prefix." +msgstr "このフィルターは、文字列プレフィックスからランダムな MAC アドレスを生成するために使用できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:993 +msgid "To get a random MAC address from a string prefix starting with '52:54:00':" +msgstr "'52:54:00' で始まる文字列プレフィックスからランダムな MAC アドレスを取得するには、次のコマンドを実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1000 +msgid "Note that if anything is wrong with the prefix string, the filter will issue an error." +msgstr "プレフィックスの文字列で不具合が生じた場合は、フィルターによりエラーが生じることに注意してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:1004 +msgid "As of Ansible version 2.9, you can also initialize the random number generator from a seed to create random-but-idempotent MAC addresses:" +msgstr "Ansible バージョン 2.9 以降では、シードから乱数ジェネレーターを初期化し、ランダムで冪等な MAC アドレスを作成することもできます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1014 +msgid "Random items or numbers" +msgstr "ランダムな項目または数字" + +#: ../../rst/user_guide/playbooks_filters.rst:1016 +msgid "The ``random`` filter in Ansible is an extension of the default Jinja2 random filter, and can be used to return a random item from a sequence of items or to generate a random number based on a range." +msgstr "Ansible の``random`` フィルターは、デフォルトの Jinja2 ランダムフィルターを拡張したもので、一連のアイテムからランダムな項目を返したり、範囲に基づいてランダムな数値を生成したりするのに使用できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1018 +msgid "To get a random item from a list:" +msgstr "リストからランダムなアイテムを取得するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1025 +msgid "To get a random number between 0 (inclusive) and a specified integer (exclusive):" +msgstr "0 (含む) から指定した整数 (除く) の間の乱数を取得するには、次のようにします。" + +#: ../../rst/user_guide/playbooks_filters.rst:1032 +msgid "To get a random number from 0 to 100 but in steps of 10:" +msgstr "0 から 100 までの 10 のステップで乱数を取得するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:1039 +msgid "To get a random number from 1 to 100 but in steps of 10:" +msgstr "1 から 100 までの 10 のステップで乱数を取得するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:1048 +msgid "You can initialize the random number generator from a seed to create random-but-idempotent numbers:" +msgstr "シードから乱数ジェネレーターを初期化し、ランダムで冪等な数字を作成できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1055 +msgid "Shuffling a list" +msgstr "リストのシャッフル" + +#: ../../rst/user_guide/playbooks_filters.rst:1057 +msgid "The ``shuffle`` filter randomizes an existing list, giving a different order every invocation." +msgstr "``shuffle`` フィルターは、既存のリストをランダム化し、呼び出しごとに異なる順序を提供します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1059 +msgid "To get a random list from an existing list:" +msgstr "既存のリストからランダムなリストを取得するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1068 +msgid "You can initialize the shuffle generator from a seed to generate a random-but-idempotent order:" +msgstr "シャッフルジェネレーターをシードから初期化して、ランダムで冪等な順序を生成することができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1075 +msgid "The shuffle filter returns a list whenever possible. If you use it with a non 'listable' item, the filter does nothing." +msgstr "シャッフルフィルターは可能な場合常にリストを返します。「リスト可能」ではない項目で使用すると、フィルターは何も行いません。" + +#: ../../rst/user_guide/playbooks_filters.rst:1081 +msgid "Managing list variables" +msgstr "リスト変数の管理" + +#: ../../rst/user_guide/playbooks_filters.rst:1083 +msgid "You can search for the minimum or maximum value in a list, or flatten a multi-level list." +msgstr "リストの最小値や最大値を検索したり、複数レベルのリストをフラットにすることができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1085 +msgid "To get the minimum value from list of numbers:" +msgstr "数値リストから最小値を取得するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1093 +msgid "To get the minimum value in a list of objects:" +msgstr "オブジェクトのリストで最小値を取得するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1099 +msgid "To get the maximum value from a list of numbers:" +msgstr "数値リストから最大値を取得するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1107 +msgid "To get the maximum value in a list of objects:" +msgstr "オブジェクトのリストで最大値を取得するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1115 +msgid "Flatten a list (same thing the `flatten` lookup does):" +msgstr "リストをフラット化します (`flatten` ルックアップと同等)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1122 +msgid "Flatten only the first level of a list (akin to the `items` lookup):" +msgstr "リストの最初のレベルのみをフラット化します (`items` ルックアップと同等)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1132 +msgid "Preserve nulls in a list, by default flatten removes them. :" +msgstr "リストに null を保持します。デフォルトでは、フラット化はこれらを削除します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1143 +msgid "Selecting from sets or lists (set theory)" +msgstr "セットまたはリストの中から選択 (理論の設定)" + +#: ../../rst/user_guide/playbooks_filters.rst:1145 +msgid "You can select or combine items from sets or lists." +msgstr "セットまたはリストから項目を選択または組み合わせることができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1149 +msgid "To get a unique set from a list:" +msgstr "リストから一意のセットを取得するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1157 +msgid "To get a union of two lists:" +msgstr "2 つのリストを組み合わせて取得するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1166 +msgid "To get the intersection of 2 lists (unique list of all items in both):" +msgstr "2 つのリスト (両方の全項目の一意のリスト) で構成されるものを取得するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1175 +msgid "To get the difference of 2 lists (items in 1 that don't exist in 2):" +msgstr "2 つのリストの相違点を取得するには (2 に存在しない 1 の項目)、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1184 +msgid "To get the symmetric difference of 2 lists (items exclusive to each list):" +msgstr "2 つのリストの対称的な違いを取得する (各リストへの除外) には、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1196 +msgid "Calculating numbers (math)" +msgstr "数字の計算 (数学)" + +#: ../../rst/user_guide/playbooks_filters.rst:1200 +msgid "You can calculate logs, powers, and roots of numbers with Ansible filters. Jinja2 provides other mathematical functions like abs() and round()." +msgstr "Ansible のフィルターを使用して、対数、累乗、おより根を計算することができます。また、Jinja2 には abs() や round() などの数学関数も用意されています。" + +#: ../../rst/user_guide/playbooks_filters.rst:1202 +msgid "Get the logarithm (default is e):" +msgstr "対数を取得します (デフォルトは e)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1209 +msgid "Get the base 10 logarithm:" +msgstr "底が 10 の対数を取得します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1216 +msgid "Give me the power of 2! (or 5):" +msgstr "2 の累乗 (または 5)を取得します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1223 +msgid "Square root, or the 5th:" +msgstr "平方根または 5 乗根を取得します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1235 +msgid "Managing network interactions" +msgstr "ネットワーク対話の管理" + +#: ../../rst/user_guide/playbooks_filters.rst:1237 +msgid "These filters help you with common network tasks." +msgstr "これらのフィルターは、一般的なネットワークタスクの使用に役立ちます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1241 +msgid "These filters have migrated to the `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ collection. Follow the installation instructions to install that collection." +msgstr "これらのフィルターは `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" + +#: ../../rst/user_guide/playbooks_filters.rst:1246 +msgid "IP address filters" +msgstr "IP アドレスフィルター" + +#: ../../rst/user_guide/playbooks_filters.rst:1250 +msgid "To test if a string is a valid IP address:" +msgstr "文字列が有効な IP アドレスかどうかをテストするには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1256 +msgid "You can also require a specific IP protocol version:" +msgstr "さらに、特定の IP プロトコルバージョンが必要です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1263 +msgid "IP address filter can also be used to extract specific information from an IP address. For example, to get the IP address itself from a CIDR, you can use:" +msgstr "IP アドレスフィルターを使用して、IP アドレスから特定の情報を抽出することもできます。たとえば、CIDR から IP アドレス自体を取得するには、以下を使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1271 +msgid "More information about ``ipaddr`` filter and complete usage guide can be found in :ref:`playbooks_filters_ipaddr`." +msgstr "``ipaddr`` フィルターの詳細と完全な使用ガイドは、「:ref:`playbooks_filters_ipaddr`」にあります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1277 +msgid "Network CLI filters" +msgstr "ネットワーク CLI フィルター" + +#: ../../rst/user_guide/playbooks_filters.rst:1281 +msgid "To convert the output of a network device CLI command into structured JSON output, use the ``parse_cli`` filter:" +msgstr "ネットワーク機器の CLI コマンドの出力を構造化された JSON 出力に変換するには、``parse_cli`` フィルターを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1288 +msgid "The ``parse_cli`` filter will load the spec file and pass the command output through it, returning JSON output. The YAML spec file defines how to parse the CLI output." +msgstr "``parse_cli`` フィルターは、spec ファイルを読み込み、コマンド出力を通して JSON 出力を返します。YAML の spec ファイルは、CLI 出力をどのように解析するかを定義します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1291 +msgid "The spec file should be valid formatted YAML. It defines how to parse the CLI output and return JSON data. Below is an example of a valid spec file that will parse the output from the ``show vlan`` command." +msgstr "spec ファイルは有効な形式の YAML でなければなりません。CLI の出力をどのように解析し、JSON データを返すかを定義します。以下は、``show vlan`` コマンドからの出力を解析する有効な spec ファイルの例です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1313 +#: ../../rst/user_guide/playbooks_filters.rst:1419 +msgid "The spec file above will return a JSON data structure that is a list of hashes with the parsed VLAN information." +msgstr "上記の spec ファイルは、解析された VLAN 情報を持つハッシュのリストである JSON データ構造を返します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1316 +msgid "The same command could be parsed into a hash by using the key and values directives. Here is an example of how to parse the output into a hash value using the same ``show vlan`` command." +msgstr "同じコマンドでも、鍵と値のディレクティブを使用することで、ハッシュに解析することができます。以下は、同じ ``show vlan`` コマンドを使用して出力をハッシュ値に解析する例です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1339 +msgid "Another common use case for parsing CLI commands is to break a large command into blocks that can be parsed. This can be done using the ``start_block`` and ``end_block`` directives to break the command into blocks that can be parsed." +msgstr "CLI コマンドを解析するもう一つの一般的なユースケースは、大きなコマンドを解析可能なブロックに分割することです。これは、``start_block`` ディレクティブと ``end_block`` ディレクティブを使用して、コマンドを解析可能なブロックに分割することで行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:1363 +msgid "The example above will parse the output of ``show interface`` into a list of hashes." +msgstr "上の例では、``show interface`` の出力を解析して、ハッシュのリストを作成します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1366 +msgid "The network filters also support parsing the output of a CLI command using the TextFSM library. To parse the CLI output with TextFSM use the following filter:" +msgstr "ネットワークフィルターは、TextFSM ライブラリーを使用して CLI コマンドの出力の解析もサポートします。TextFSM で CLI 出力を解析するには、以下のフィルターを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1374 +msgid "Use of the TextFSM filter requires the TextFSM library to be installed." +msgstr "TextFSM フィルターを使用するには、TextFSM ライブラリーをインストールする必要があります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1377 +msgid "Network XML filters" +msgstr "ネットワーク XML フィルター" + +#: ../../rst/user_guide/playbooks_filters.rst:1381 +msgid "To convert the XML output of a network device command into structured JSON output, use the ``parse_xml`` filter:" +msgstr "ネットワークデバイスコマンドの XML 出力を構造化された JSON 出力に変換するには、``parse_xml`` フィルターを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1388 +msgid "The ``parse_xml`` filter will load the spec file and pass the command output through formatted as JSON." +msgstr "``parse_xml`` フィルターは、spec ファイルを読み込み、JSON としてフォーマットされたコマンド出力を渡します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1391 +msgid "The spec file should be valid formatted YAML. It defines how to parse the XML output and return JSON data." +msgstr "仕様ファイルは有効な YAML 形式である必要があります。XML 出力を解析し、JSON データを返す方法を定義します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1394 +msgid "Below is an example of a valid spec file that will parse the output from the ``show vlan | display xml`` command." +msgstr "以下は、``show vlan | display xml`` コマンドの出力を解析するための有効な spec ファイルの例です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1422 +msgid "The same command could be parsed into a hash by using the key and values directives. Here is an example of how to parse the output into a hash value using the same ``show vlan | display xml`` command." +msgstr "同じコマンドでも、鍵と値のディレクティブを使用することで、ハッシュに解析することができます。以下は、同じ ``show vlan | display xml`` コマンドを使用して出力をハッシュ値に解析する例です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1450 +msgid "The value of ``top`` is the XPath relative to the XML root node. In the example XML output given below, the value of ``top`` is ``configuration/vlans/vlan``, which is an XPath expression relative to the root node (<rpc-reply>). ``configuration`` in the value of ``top`` is the outer most container node, and ``vlan`` is the inner-most container node." +msgstr "``top`` の値は、XML ルートノードに対する相対的な XPath です。以下の XML 出力例では、``top`` の値は ``configuration/vlans/vlan`` であり、これはルートノード (<rpc-reply>) に対する相対的な XPath 式です。``top`` の値の ``configuration`` は最も外側のコンテナーノードであり、``vlan`` は最も内側のコンテナーノードです。" + +#: ../../rst/user_guide/playbooks_filters.rst:1456 +msgid "``items`` is a dictionary of key-value pairs that map user-defined names to XPath expressions that select elements. The Xpath expression is relative to the value of the XPath value contained in ``top``. For example, the ``vlan_id`` in the spec file is a user defined name and its value ``vlan-id`` is the relative to the value of XPath in ``top``" +msgstr "``items`` は、ユーザー定義の名前を、要素を選択する XPath 式にマッピングするキーと値のペアのディクショナリーです。Xpath 式は、``top`` に含まれる XPath 値の値に対する相対値です。たとえば、spec ファイルの ``vlan_id`` はユーザー定義の名前で、その値 ``vlan-id`` は、``top`` に含まれる XPath の値に対する相対値です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1461 +msgid "Attributes of XML tags can be extracted using XPath expressions. The value of ``state`` in the spec is an XPath expression used to get the attributes of the ``vlan`` tag in output XML.:" +msgstr "XML タグの属性は、XPath 式を用いて抽出することができます。仕様書の ``state`` の値は、出力された XML の ``vlan`` タグの属性を取得するために使用される XPath 式です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1479 +msgid "For more information on supported XPath expressions, see `XPath Support <https://docs.python.org/3/library/xml.etree.elementtree.html#xpath-support>`_." +msgstr "サポートされる XPath 式の詳細は、「`XPath Support <https://docs.python.org/3/library/xml.etree.elementtree.html#xpath-support>`_」を参照してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:1482 +msgid "Network VLAN filters" +msgstr "ネットワーク VLAN フィルター" + +#: ../../rst/user_guide/playbooks_filters.rst:1486 +msgid "Use the ``vlan_parser`` filter to transform an unsorted list of VLAN integers into a sorted string list of integers according to IOS-like VLAN list rules. This list has the following properties:" +msgstr "``vlan_parser`` フィルターを使用して、ソートされていない VLAN 整数のリストを、IOS のような VLAN リストのルールに従ってソートされた整数の文字列リストに変換します。このリストには以下のプロパティーがあります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1489 +msgid "Vlans are listed in ascending order." +msgstr "VLAN は昇順でリストされます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1490 +msgid "Three or more consecutive VLANs are listed with a dash." +msgstr "3 つ以上の連続した VLAN はダッシュ付きでリストされます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1491 +msgid "The first line of the list can be first_line_len characters long." +msgstr "リストの最初の行は、first_line_len 文字の長さになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1492 +msgid "Subsequent list lines can be other_line_len characters." +msgstr "後続のリスト行は、other_line_len 文字になります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1494 +msgid "To sort a VLAN list:" +msgstr "VLAN リストをソートするには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1500 +msgid "This example renders the following sorted list:" +msgstr "この例では、以下のソートリストを示しています。" + +#: ../../rst/user_guide/playbooks_filters.rst:1507 +msgid "Another example Jinja template:" +msgstr "Jinja テンプレートの他の例:" + +#: ../../rst/user_guide/playbooks_filters.rst:1517 +msgid "This allows for dynamic generation of VLAN lists on a Cisco IOS tagged interface. You can store an exhaustive raw list of the exact VLANs required for an interface and then compare that to the parsed IOS output that would actually be generated for the configuration." +msgstr "これにより、Cisco IOS タグ付きインターフェース上の VLAN リストを動的に生成することができます。インターフェースに必要な正確な VLAN の網羅的な生のリストを保存し、それを設定のために実際に生成されるであろう解析された IOS 出力と比較することができます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1523 +msgid "Hashing and encrypting strings and passwords" +msgstr "文字列およびパスワードのハッシュ処理および暗号化" + +#: ../../rst/user_guide/playbooks_filters.rst:1527 +msgid "To get the sha1 hash of a string:" +msgstr "文字列の sha1 ハッシュを取得するには、次のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1534 +msgid "To get the md5 hash of a string:" +msgstr "文字列の md5 ハッシュを取得するには、次のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1541 +msgid "Get a string checksum:" +msgstr "文字列のチェックサムを取得します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1548 +msgid "Other hashes (platform dependent):" +msgstr "その他のハッシュ (プラットフォームに依存):" + +#: ../../rst/user_guide/playbooks_filters.rst:1554 +msgid "To get a sha512 password hash (random salt):" +msgstr "sha512 パスワードハッシュ (任意の salt) を取得するには、次のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1561 +msgid "To get a sha256 password hash with a specific salt:" +msgstr "特定の salt を持つ sha256 パスワードハッシュを取得するには、次のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1568 +msgid "An idempotent method to generate unique hashes per system is to use a salt that is consistent between runs:" +msgstr "システムごとに一意のハッシュを生成する冪等な方法は、実行間で一貫性のある salt を使用することです。" + +#: ../../rst/user_guide/playbooks_filters.rst:1575 +msgid "Hash types available depend on the control system running Ansible, 'hash' depends on `hashlib <https://docs.python.org/3.8/library/hashlib.html>`_, password_hash depends on `passlib <https://passlib.readthedocs.io/en/stable/lib/passlib.hash.html>`_. The `crypt <https://docs.python.org/3.8/library/crypt.html>`_ is used as a fallback if ``passlib`` is not installed." +msgstr "利用可能なハッシュタイプは、Ansible を実行している制御システムに依存しており、「hash」は `hashlib <https://docs.python.org/3.8/library/hashlib.html>`_ に、「password_hash」は `passlib <https://passlib.readthedocs.io/en/stable/lib/passlib.hash.html>`_ に依存しています。`crypt <https://docs.python.org/3.8/library/crypt.html>`_ は ``passlib`` がインストールされていない場合のフォールバックとして使用されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1579 +msgid "Some hash types allow providing a rounds parameter:" +msgstr "ハッシュタイプによっては、rounds パラメーターを指定できるものもあります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1586 +msgid "The filter `password_hash` produces different results depending on whether you installed `passlib` or not." +msgstr "フィルター `password_hash` は、`passlib` をインストールしたかどうかによって異なる結果を生成します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1588 +msgid "To ensure idempotency, specify `rounds` to be neither `crypt`'s nor `passlib`'s default, which is `5000` for `crypt` and a variable value (`535000` for sha256, `656000` for sha512) for `passlib`:" +msgstr "冪等性を確保するには、`rounds` を `crypt` または `passlib`のデフォルトにならないように指定します。これは、`crypt` の場合は `5000`、`passlib` の場合は変数値 (sha256 の場合は `535000`、sha512 の場合は`656000`) です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1595 +msgid "Hash type 'blowfish' (BCrypt) provides the facility to specify the version of the BCrypt algorithm." +msgstr "ハッシュタイプ 'blowfish' (BCrypt) は、BCrypt アルゴリズムのバージョンを指定する機能を提供します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1603 +msgid "The parameter is only available for `blowfish (BCrypt) <https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt.html#passlib.hash.bcrypt>`_. Other hash types will simply ignore this parameter. Valid values for this parameter are: ['2', '2a', '2y', '2b']" +msgstr "このパラメーターは、`blowfish (BCrypt) <https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt.html#passlib.hash.bcrypt>`_ でのみ利用できます。他のハッシュタイプは、このパラメーターを無視します。このパラメーターに対する有効な値は ['2', '2a', '2y', '2b'] です。" + +#: ../../rst/user_guide/playbooks_filters.rst:1609 +msgid "You can also use the Ansible :ref:`vault <vault>` filter to encrypt data:" +msgstr "Ansible の :ref:`vault <vault>` フィルターを使用してデータを暗号化することもできます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1624 +msgid "And then decrypt it using the unvault filter:" +msgstr "その後、unvault フィルターを使用して復号します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1641 +msgid "Manipulating text" +msgstr "テキストの操作" + +#: ../../rst/user_guide/playbooks_filters.rst:1643 +msgid "Several filters work with text, including URLs, file names, and path names." +msgstr "いくつかのフィルターは、URL、ファイル名、パス名などのテキストを扱います。" + +#: ../../rst/user_guide/playbooks_filters.rst:1648 +msgid "Adding comments to files" +msgstr "ファイルへのコメントの追加" + +#: ../../rst/user_guide/playbooks_filters.rst:1650 +msgid "The ``comment`` filter lets you create comments in a file from text in a template, with a variety of comment styles. By default Ansible uses ``#`` to start a comment line and adds a blank comment line above and below your comment text. For example the following:" +msgstr "``comment`` フィルターを使用すると、テンプレート内のテキストから、さまざまなコメントスタイルでファイル内にコメントを作成することができます。Ansible のデフォルトでは、``#`` を使用してコメント行を開始し、コメントテキストの上下に空白のコメント行を追加します。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1656 +msgid "produces this output:" +msgstr "次の出力を生成します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1664 +msgid "Ansible offers styles for comments in C (``//...``), C block (``/*...*/``), Erlang (``%...``) and XML (``<!--...-->``):" +msgstr "Ansibleでは、C (``//...``)、C ブロック (``/*...*/``)、Erlang (``%...``)、および XML (``<!--...-->``) のコメント用スタイルを提供しています。" + +#: ../../rst/user_guide/playbooks_filters.rst:1674 +msgid "You can define a custom comment character. This filter:" +msgstr "カスタムのコメント文字を定義できます。このフィルターは、以下のようになります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1680 +msgid "produces:" +msgstr "生成:" + +#: ../../rst/user_guide/playbooks_filters.rst:1688 +msgid "You can fully customize the comment style:" +msgstr "コメントスタイルを完全にカスタマイズすることもできます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1694 +msgid "That creates the following output:" +msgstr "これにより、以下の出力が作成されます。" + +#: ../../rst/user_guide/playbooks_filters.rst:1706 +msgid "The filter can also be applied to any Ansible variable. For example to make the output of the ``ansible_managed`` variable more readable, we can change the definition in the ``ansible.cfg`` file to this:" +msgstr "フィルターは、Ansible 変数にも適用することもできます。たとえば、``ansible_managed`` 変数の出力をより読みやすくするために、``ansible.cfg`` ファイルの定義を以下のように変更します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1720 +msgid "and then use the variable with the `comment` filter:" +msgstr "次に、`comment` フィルターで変数を使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1726 +msgid "which produces this output:" +msgstr "これは、次の出力を生成します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1740 +msgid "URLEncode Variables" +msgstr "URLEncode 変数" + +#: ../../rst/user_guide/playbooks_filters.rst:1742 +msgid "The ``urlencode`` filter quotes data for use in a URL path or query using UTF-8:" +msgstr "``urlencode`` フィルターは、URL パスを使用、または UTF-8 を使用したクエリーで使用するデータを引用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1750 +msgid "Splitting URLs" +msgstr "URL の分割" + +#: ../../rst/user_guide/playbooks_filters.rst:1754 +msgid "The ``urlsplit`` filter extracts the fragment, hostname, netloc, password, path, port, query, scheme, and username from an URL. With no arguments, returns a dictionary of all the fields:" +msgstr "``urlsplit`` フィルターは、URL からフラグメント、ホスト名、netloc、パスワード、パス、ポート、クエリー、スキーム、およびユーザー名を抽出します。引数がない場合は、すべてのフィールドのディクショナリーを返します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1800 +msgid "Searching strings with regular expressions" +msgstr "正規表現を使用した文字列の検索" + +#: ../../rst/user_guide/playbooks_filters.rst:1802 +msgid "To search in a string or extract parts of a string with a regular expression, use the ``regex_search`` filter:" +msgstr "文字列の検索または正規表現で文字列の部分を抽出するには、``regex_search`` フィルターを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1822 +msgid "The ``regex_search`` filter returns an empty string if it cannot find a match:" +msgstr "``regex_search`` フィルターは、一致するものが見つからない場合に空の文字列を返します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1833 +msgid "The ``regex_search`` filter returns ``None`` when used in a Jinja expression (for example in conjunction with operators, other filters, and so on). See the two examples below." +msgstr "Jinja 式で使用されると、``regex_search`` フィルターは ``None`` を返します )たとえば演算子、他のフィルターなど)。以下の 2 例を参照してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:1842 +msgid "This is due to historic behavior and the custom re-implementation of some of the Jinja internals in Ansible. Enable the ``jinja2_native`` setting if you want the ``regex_search`` filter to always return ``None`` if it cannot find a match. See :ref:`jinja2_faqs` for details." +msgstr "これは、Ansible の Jinja 内部のいくつかの歴史的な動作とカスタムの再実装によるものです。一致するものがみつからない場合に ``regex_search`` フィルターが常に ``None`` を返すようにするには、``jinja2_native`` 設定を有効にします。詳細は :ref:`jinja2_faqs` を参照してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:1844 +msgid "To extract all occurrences of regex matches in a string, use the ``regex_findall`` filter:" +msgstr "文字列の中にある正規表現の一致のすべての出現箇所を抽出するには、``regex_findall`` フィルターを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1857 +msgid "To replace text in a string with regex, use the ``regex_replace`` filter:" +msgstr "文字列のテキストを正規表現に置き換えるには、``regex_replace`` フィルターを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1882 +msgid "If you want to match the whole string and you are using ``*`` make sure to always wraparound your regular expression with the start/end anchors. For example ``^(.*)$`` will always match only one result, while ``(.*)`` on some Python versions will match the whole string and an empty string at the end, which means it will make two replacements:" +msgstr "文字列全体に一致させたい場合に ``*`` を使用する場合は、必ず開始/終了アンカーで正規表現を折り返すようにしてください。たとえば、``^(.*)$`` は常に 1 つの結果のみに一致しますが、``(.*)`` はいくつかの Python バージョンでは文字列全体と最後に空の文字列に一致します。つまり 2 つの置換を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:1905 +msgid "Prior to ansible 2.0, if ``regex_replace`` filter was used with variables inside YAML arguments (as opposed to simpler 'key=value' arguments), then you needed to escape backreferences (for example, ``\\\\1``) with 4 backslashes (``\\\\\\\\``) instead of 2 (``\\\\``)." +msgstr "ansible 2.0 より前のバージョンでは、(単純な「key=value」引数ではなく) ``regex_replace`` フィルターを YAML 引数内の変数に使用する場合は、後方参照 (たとえば ``\\\\1``) をバックスラッシュ 2 つ (``\\\\``) ではなく 4 つ (``\\\\\\\\``) でエスケープする必要がありました。" + +#: ../../rst/user_guide/playbooks_filters.rst:1909 +msgid "To escape special characters within a standard Python regex, use the ``regex_escape`` filter (using the default ``re_type='python'`` option):" +msgstr "標準の Python 正規表現内で特殊文字をエスケープするには、``regex_escape`` フィルターを使用します (デフォルトの ``re_type='python'`` オプションを使用)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1918 +msgid "To escape special characters within a POSIX basic regex, use the ``regex_escape`` filter with the ``re_type='posix_basic'`` option:" +msgstr "POSIX 基本正規表現内で特殊文字をエスケープするには、``regex_escape`` フィルターを ``re_type='posix_basic'`` オプションを付けて使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1927 +msgid "Managing file names and path names" +msgstr "ファイル名とパス名の管理" + +#: ../../rst/user_guide/playbooks_filters.rst:1929 +msgid "To get the last name of a file path, like 'foo.txt' out of '/etc/asdf/foo.txt':" +msgstr "「/etc/asdf/foo.txt」の「foo.txt」のように、ファイルパスの最後の名前を取得するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1935 +msgid "To get the last name of a windows style file path (new in version 2.0):" +msgstr "ウィンドウスタイルのファイルパスの最後の名前を取得するには、以下を指定します (バージョン 2.0 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1941 +msgid "To separate the windows drive letter from the rest of a file path (new in version 2.0):" +msgstr "Windows ドライブの文字を残りのファイルパスから分離するには、以下を指定します (バージョン 2.0 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1947 +msgid "To get only the windows drive letter:" +msgstr "Windows ドライブの文字のみを取得するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1953 +msgid "To get the rest of the path without the drive letter:" +msgstr "ドライブ文字なしで残りのパスを取得するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1959 +msgid "To get the directory from a path:" +msgstr "パスからディレクトリーを取得するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1965 +msgid "To get the directory from a windows path (new version 2.0):" +msgstr "Windows パスからディレクトリーを取得するには、以下を指定します (バージョン 2.0 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1971 +msgid "To expand a path containing a tilde (`~`) character (new in version 1.5):" +msgstr "チルド (`~`) 文字を含むパスを拡張するには、以下を指定します (バージョン 1.5 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1977 +msgid "To expand a path containing environment variables:" +msgstr "環境変数を含むパスを拡張するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:1983 +msgid "`expandvars` expands local variables; using it on remote paths can lead to errors." +msgstr "`expandvars` は、ローカル変数を拡張します。リモートパスで使用するとエラーが発生する可能性があります。" + +#: ../../rst/user_guide/playbooks_filters.rst:1987 +msgid "To get the real path of a link (new in version 1.8):" +msgstr "リンクの実際のパスを取得するには、以下を指定します (バージョン 1.8 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1993 +msgid "To get the relative path of a link, from a start point (new in version 1.7):" +msgstr "リンクの相対パスを取得するには、開始点から以下を行います (バージョン 1.7 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:1999 +msgid "To get the root and extension of a path or file name (new in version 2.0):" +msgstr "パスまたはファイル名のルートおよび拡張を取得するには、以下を指定します (バージョン 2.0 の新機能)。" + +#: ../../rst/user_guide/playbooks_filters.rst:2006 +msgid "The ``splitext`` filter always returns a pair of strings. The individual components can be accessed by using the ``first`` and ``last`` filters:" +msgstr "``splitext`` フィルターは、常に文字列のペアを返します。個々のコンポーネントは、``first`` フィルターおよび ``last`` フィルターを使用してアクセスできます。" + +#: ../../rst/user_guide/playbooks_filters.rst:2016 +msgid "To join one or more path components:" +msgstr "1 つ以上のパスコンポーネントを結合するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2025 +msgid "Manipulating strings" +msgstr "文字列の操作" + +#: ../../rst/user_guide/playbooks_filters.rst:2027 +msgid "To add quotes for shell usage:" +msgstr "シェルの使用に引用符を追加するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_filters.rst:2034 +msgid "To concatenate a list into a string:" +msgstr "リストを文字列に連結するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2040 +msgid "To split a string into a list:" +msgstr "文字列をリストに分割するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2048 +msgid "To work with Base64 encoded strings:" +msgstr "Base64 でエンコードされた文字列を使用するには、以下を指定します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2055 +msgid "As of version 2.6, you can define the type of encoding to use, the default is ``utf-8``:" +msgstr "バージョン 2.6 以降では、使用するエンコーディングのタイプを定義できます。デフォルトは ``utf-8`` です。" + +#: ../../rst/user_guide/playbooks_filters.rst:2062 +msgid "The ``string`` filter is only required for Python 2 and ensures that text to encode is a unicode string. Without that filter before b64encode the wrong value will be encoded." +msgstr "``string`` フィルターは Python 2 でのみ必要です。エンコードするテキストがユニコード文字列であることを確認します。b64encode より前のフィルターを使用しないと、誤った値がエンコードされます。" + +#: ../../rst/user_guide/playbooks_filters.rst:2067 +msgid "Managing UUIDs" +msgstr "UUID の管理" + +#: ../../rst/user_guide/playbooks_filters.rst:2069 +msgid "To create a namespaced UUIDv5:" +msgstr "namespace を使用した UUIDv5 を作成するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2077 +msgid "To create a namespaced UUIDv5 using the default Ansible namespace '361E6D51-FAEC-444A-9079-341386DA8E2E':" +msgstr "デフォルトの Ansible 名前空間「361E6D51-FAEC-444A-9079-341386DA8E2E2E」を使用して名前空間を指定した UUIDv5 を作成するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2085 +msgid "To make use of one attribute from each item in a list of complex variables, use the :func:`Jinja2 map filter <jinja2:jinja-filters.map>`:" +msgstr "複雑な変数のリストで、各項目から 1 つの属性を使用するには、:func:`Jinja2 map filter <jinja2:jinja-filters.map>` を使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2093 +msgid "Handling dates and times" +msgstr "日付と時刻の処理" + +#: ../../rst/user_guide/playbooks_filters.rst:2095 +msgid "To get a date object from a string use the `to_datetime` filter:" +msgstr "文字列から日付オブジェクトを取得するには、`to_datetime` フィルターを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2109 +msgid "For a full list of format codes for working with python date format strings, see https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior." +msgstr "Python 日付形式の文字列を使用する形式コードの全一覧は、https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior を参照してください。" + +#: ../../rst/user_guide/playbooks_filters.rst:2113 +msgid "To format a date using a string (like with the shell date command), use the \"strftime\" filter:" +msgstr "文字列 (shell date コマンドの場合のように) を使用して日付をフォーマットするには、「strftime」フィルターを使用します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2133 +msgid "To get all string possibilities, check https://docs.python.org/3/library/time.html#time.strftime" +msgstr "すべての文字列の可能性を取得するには、https://docs.python.org/3/library/time.html#time.strftime を確認します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2136 +msgid "Getting Kubernetes resource names" +msgstr "Kubernetes リソース名の取得" + +#: ../../rst/user_guide/playbooks_filters.rst:2140 +msgid "These filters have migrated to the `kubernetes.core <https://galaxy.ansible.com/kubernetes/core>`_ collection. Follow the installation instructions to install that collection." +msgstr "これらのフィルターは `kubernetes.core <https://galaxy.ansible.com/kubernetes/core>`_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" + +#: ../../rst/user_guide/playbooks_filters.rst:2142 +msgid "Use the \"k8s_config_resource_name\" filter to obtain the name of a Kubernetes ConfigMap or Secret, including its hash:" +msgstr "「k8s_config_resource_name」フィルターを使用して、Kubernetes ConfigMap または Secret の名前を、そのハッシュを含めて取得します。" + +#: ../../rst/user_guide/playbooks_filters.rst:2149 +msgid "This can then be used to reference hashes in Pod specifications:" +msgstr "これは、Pod 仕様のハッシュを参照するために使用できます。" + +#: ../../rst/user_guide/playbooks_filters.rst:2177 +#: ../../rst/user_guide/playbooks_loops.rst:476 +#: ../../rst/user_guide/playbooks_strategies.rst:245 +#: ../../rst/user_guide/playbooks_variables.rst:495 +#: ../../rst/user_guide/windows_faq.rst:250 +#: ../../rst/user_guide/windows_setup.rst:569 +msgid ":ref:`about_playbooks`" +msgstr ":ref:`about_playbooks`" + +#: ../../rst/user_guide/playbooks_filters.rst:2183 +#: ../../rst/user_guide/playbooks_lookups.rst:34 +#: ../../rst/user_guide/playbooks_reuse.rst:217 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:23 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:600 +#: ../../rst/user_guide/playbooks_templating.rst:50 +#: ../../rst/user_guide/playbooks_tests.rst:515 +#: ../../rst/user_guide/playbooks_variables.rst:501 +msgid ":ref:`playbooks_loops`" +msgstr ":ref:`playbooks_loops`" + +#: ../../rst/user_guide/playbooks_filters.rst:2184 +#: ../../rst/user_guide/playbooks_lookups.rst:35 +#: ../../rst/user_guide/playbooks_templating.rst:51 +#: ../../rst/user_guide/playbooks_tests.rst:516 +#: ../../rst/user_guide/playbooks_variables.rst:502 +msgid "Looping in playbooks" +msgstr "Playbook でのループ" + +#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:6 +msgid "ipaddr filter" +msgstr "ipaddr フィルター" + +#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:8 +msgid "This document has moved to :ref:`plugins_in_ansible.utils`." +msgstr "このドキュメントは :ref:`plugins_in_ansible.utils` に移動しました。" + +#: ../../rst/user_guide/playbooks_handlers.rst:4 +msgid "Handlers: running operations on change" +msgstr "ハンドラー: 変更時に実行する操作" + +#: ../../rst/user_guide/playbooks_handlers.rst:6 +msgid "Sometimes you want a task to run only when a change is made on a machine. For example, you may want to restart a service if a task updates the configuration of that service, but not if the configuration is unchanged. Ansible uses handlers to address this use case. Handlers are tasks that only run when notified." +msgstr "マシンに変更が加えられたときにのみ、タスクを実行したい場合があります。たとえば、タスクがサービスの設定を更新した場合はサービスを再起動し、設定が変更していない場合には再起動しないようにしたい場合があります。Ansible では、このようなユースケースに対応するためにハンドラーを使用しています。ハンドラーは、通知されたときにのみ実行するタスクです。" + +#: ../../rst/user_guide/playbooks_handlers.rst:12 +msgid "Handler example" +msgstr "ハンドラーの例" + +#: ../../rst/user_guide/playbooks_handlers.rst:14 +msgid "This playbook, ``verify-apache.yml``, contains a single play with a handler." +msgstr "この Playbook ``verify-apache.yml`` には、ハンドラーを使用した 1 つのプレイが含まれます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:49 +msgid "In this example playbook, the Apache server is restarted by the handler after all tasks complete in the play." +msgstr "この Playbook の例では、プレイのすべてのタスクが完了した後、Apache サーバーはハンドラーによって再起動されます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:53 +#: ../../rst/user_guide/playbooks_reuse.rst:136 +msgid "Notifying handlers" +msgstr "ハンドラーの通知" + +#: ../../rst/user_guide/playbooks_handlers.rst:55 +msgid "Tasks can instruct one or more handlers to execute using the ``notify`` keyword. The ``notify`` keyword can be applied to a task and accepts a list of handler names that are notified on a task change. Alternately, a string containing a single handler name can be supplied as well. The following example demonstrates how multiple handlers can be notified by a single task:" +msgstr "タスクは、``notify`` キーワードを使用して実行するハンドラーを 1 つまたは複数指示できます。``notify`` キーワードはタスクに適用され、タスクの変更時に通知されるハンドラー名の一覧を受け入れることができます。あるいは、1 つのハンドラー名が含まれる文字列を指定することもできます。以下の例は、1 つのタスクで複数のハンドラーに通知する方法を示しています。" + +#: ../../rst/user_guide/playbooks_handlers.rst:79 +msgid "In the above example the handlers are executed on task change in the following order: ``Restart memcached``, ``Restart apache``. Handlers are executed in the order they are defined in the ``handlers`` section, not in the order listed in the ``notify`` statement. Notifying the same handler multiple times will result in executing the handler only once regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts." +msgstr "上記の例では、ハンドラーはタスクの変更時に ``Restart memcached``、``Restart apache`` の順で実行されます。ハンドラーは、``notify`` ステートメントにリストされている順番ではなく、``handlers`` セクションで定義された順序で実行されます。同じハンドラーを複数回指定しても、通知するタスクの数に関係なくハンドラーは 1 回しか実行されません。たとえば、複数のタスクが設定ファイルを更新し、Apache を再起動するようにハンドラーに通知した場合、Ansible は不要な再起動を防ぐために Apache に 1 度だけバウンスします。" + +#: ../../rst/user_guide/playbooks_handlers.rst:83 +msgid "Naming handlers" +msgstr "ハンドラーの命名" + +#: ../../rst/user_guide/playbooks_handlers.rst:85 +msgid "Handlers must be named in order for tasks to be able to notify them using the ``notify`` keyword." +msgstr "タスクが``notify`` キーワードを使用して通知できるように、ハンドラーに名前を付ける必要があります。" + +#: ../../rst/user_guide/playbooks_handlers.rst:87 +msgid "Alternately, handlers can utilize the ``listen`` keyword. Using this handler keyword, handlers can listen on topics that can group multiple handlers as follows:" +msgstr "あるいは、ハンドラーは ``listen`` キーワードを使用できます。このハンドラーキーワードを使用すると、ハンドラーは以下のように複数のハンドラーをグループ化できるトピックをリッスンできます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:109 +msgid "Notifying the ``restart web services`` topic results in executing all handlers listening to that topic regardless of how those handlers are named." +msgstr "``restart web services`` トピックに通知すると、ハンドラーの名前が何であるかに関わらず、そのトピックをリッスンするすべてのハンドラーが実行されます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:111 +msgid "This use makes it much easier to trigger multiple handlers. It also decouples handlers from their names, making it easier to share handlers among playbooks and roles (especially when using third-party roles from a shared source such as Ansible Galaxy)." +msgstr "これにより、複数のハンドラーを簡単に発生させることができます。また、ハンドラーを名前から切り離すことで、Playbook やロール間でのハンドラーの共有が容易になります (特に Ansible Galaxy のような共有ソースからサードパーティーのロールを使用する場合)。" + +#: ../../rst/user_guide/playbooks_handlers.rst:113 +msgid "Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one defined is notified with ``notify``, effectively shadowing all of the previous handlers with the same name. Alternately handlers sharing the same name can all be notified and executed if they listen on the same topic by notifying that topic." +msgstr "各ハンドラーにはグローバルに一意な名前を付ける必要があります。複数のハンドラーが同じ名前で定義されている場合、最後に定義されたハンドラーのみが ``notify`` で通知され、実質的に同じ名前のそれまでのすべてのハンドラーは保護されます。あるいは、同じ名前を共有するハンドラーが同じトピックをリッスンする場合は、そのトピックに通知することですべてのハンドラーが通知され、実行されます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:115 +msgid "There is only one global scope for handlers (handler names and listen topics) regardless of where the handlers are defined. This also includes handlers defined in roles." +msgstr "ハンドラーが定義されている場所に関係なく、ハンドラー（ハンドラー名およびリッスントピック）には 1 つのグローバルスコープがあります。これには、ロールで定義されたハンドラーも含まれます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:119 +msgid "Controlling when handlers run" +msgstr "ハンドラーの実行時の制御" + +#: ../../rst/user_guide/playbooks_handlers.rst:121 +msgid "By default, handlers run after all the tasks in a particular play have been completed. Notified handlers are executed automatically after each of the following sections, in the following order: ``pre_tasks``, ``roles``/``tasks`` and ``post_tasks``. This approach is efficient, because the handler only runs once, regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts." +msgstr "デフォルトでは、ハンドラーは、特定のプレイのすべてのタスクが完了した後に実行されます。通知されたハンドラーは、``pre_tasks``、``roles``/``tasks``、および ``post_tasks``のセクションの順に自動的に実行されます。ハンドラーは、いくつのタスクが通知したかに関わらず、一度だけ実行するため、このアプローチは効率的です。たとえば、複数のタスクが設定ファイルを更新し、ハンドラーに Apache の再起動を通知した場合、Ansible は Apache に 1 回だけバウンスさせ、不要な再起動を回避します。" + +#: ../../rst/user_guide/playbooks_handlers.rst:123 +msgid "If you need handlers to run before the end of the play, add a task to flush them using the :ref:`meta module <meta_module>`, which executes Ansible actions:" +msgstr "プレイの終了前にハンドラーを実行する必要がある場合は、Ansible アクションを実行する :ref:`meta module <meta_module>` を使用して、タスクをフラッシュします。" + +#: ../../rst/user_guide/playbooks_handlers.rst:137 +msgid "The ``meta: flush_handlers`` task triggers any handlers that have been notified at that point in the play." +msgstr "``meta: flush_handlers`` タスクは、プレイのその時点で通知されたハンドラーを発生させます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:139 +msgid "Once handlers are executed, either automatically after each mentioned section or manually by the ``flush_handlers`` meta task, they can be notified and run again in later sections of the play." +msgstr "指定された各セクションの後に自動的に、または ``flush_handlers`` メタタスクで手動でハンドラーが実行されると、プレイの後のセクションで再度通知して実行することができます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:143 +msgid "Using variables with handlers" +msgstr "ハンドラーでの変数の使用" + +#: ../../rst/user_guide/playbooks_handlers.rst:145 +msgid "You may want your Ansible handlers to use variables. For example, if the name of a service varies slightly by distribution, you want your output to show the exact name of the restarted service for each target machine. Avoid placing variables in the name of the handler. Since handler names are templated early on, Ansible may not have a value available for a handler name like this:" +msgstr "Ansible ハンドラーで変数を使用したい場合があります。たとえば、サービスの名前がディストリビューションによってわずかに異なる場合に、ターゲットマシンごとに再起動したサービスの正確な名前を出力するとします。ハンドラーの名前に変数を入れないでください。ハンドラー名は初期段階でテンプレート化されているため、Ansible では次のようなハンドラー名に利用できる値がない場合があります。" + +#: ../../rst/user_guide/playbooks_handlers.rst:153 +msgid "If the variable used in the handler name is not available, the entire play fails. Changing that variable mid-play **will not** result in newly created handler." +msgstr "ハンドラー名で使用される変数が利用できない場合は、プレイ全体が失敗します。変数 mid-play を変更すると、新しく作成されたハンドラーが **作成されません**。" + +#: ../../rst/user_guide/playbooks_handlers.rst:155 +msgid "Instead, place variables in the task parameters of your handler. You can load the values using ``include_vars`` like this:" +msgstr "代わりに、ハンドラーのタスクパラメーターに変数を配置します。以下のように ``include_vars`` を使用して、値を読み込むことができます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:169 +msgid "While handler names can contain a template, ``listen`` topics cannot." +msgstr "ハンドラー名にはテンプレートを含めることができますが、``listen`` トピックにはテンプレートを含めることはできません。" + +#: ../../rst/user_guide/playbooks_handlers.rst:173 +msgid "Handlers in roles" +msgstr "ロールのハンドラー" + +#: ../../rst/user_guide/playbooks_handlers.rst:175 +msgid "Handlers from roles are not just contained in their roles but rather inserted into global scope with all other handlers from a play. As such they can be used outside of the role they are defined in. It also means that their name can conflict with handlers from outside the role. To ensure that a handler from a role is notified as opposed to one from outside the role with the same name, notify the handler by using its name in the following form: ``role_name : handler_name``." +msgstr "ロールからのハンドラーはそのロール内に含まれるだけでなく、プレイからの他のすべてのハンドラーと共にグローバルスコープに挿入されます。したがって、ハンドラーは定義されたロール外で使用できます。また、ハンドラーの名前がロール外からのハンドラーと競合する可能性があることも意味します。同じ名前を持つロール外からのハンドラーではなく、ロールからのハンドラーが通知されるようにするには、``role_name : handler_name`` のフォームで名前を使用してハンドラーに通知します。" + +#: ../../rst/user_guide/playbooks_handlers.rst:177 +msgid "Handlers notified within the ``roles`` section are automatically flushed at the end of the ``tasks`` section, but before any ``tasks`` handlers." +msgstr "``roles``セクション内で通知されるハンドラーは、``tasks`` セクションの最後に、ただし ``tasks`` ハンドラーの前に自動的にフラッシュされます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:181 +msgid "Includes and imports in handlers" +msgstr "ハンドラーのインクルードおよびインポート" + +#: ../../rst/user_guide/playbooks_handlers.rst:182 +msgid "Notifying a dynamic include such as ``include_task`` as a handler results in executing all tasks from within the include. It is not possible to notify a handler defined inside a dynamic include." +msgstr "ハンドラーとして ``include_task`` などの動的インクルードに通知すると、インクルード内からのすべてのタスクが実行されます。動的インクルード内で定義されたハンドラーに通知することはできません。" + +#: ../../rst/user_guide/playbooks_handlers.rst:184 +msgid "Having a static include such as ``import_task`` as a handler results in that handler being effectively rewritten by handlers from within that import before the play execution. A static include itself cannot be notified, the tasks from withing that include, on the other hand, can be notified individually." +msgstr "ハンドラーとして ``import_task`` などの静的インクルードを指定すると、実質的にそのハンドラーはプレイの実行前にそのインポート内からのハンドラーにより書き換えられます。静インクルード自体には通知できず、一方、そのインクルード内からのタスクには個別に通知できます。" + +#: ../../rst/user_guide/playbooks_handlers.rst:188 +#: ../../rst/user_guide/windows_usage.rst:490 +msgid "Limitations" +msgstr "制限事項" + +#: ../../rst/user_guide/playbooks_handlers.rst:190 +msgid "A handler cannot run ``import_role`` or ``include_role``." +msgstr "ハンドラーは ``import_role`` または ``include_role`` を実行できません。" + +#: ../../rst/user_guide/playbooks_intro.rst:6 +msgid "Intro to playbooks" +msgstr "Playbook の概要" + +#: ../../rst/user_guide/playbooks_intro.rst:8 +msgid "Ansible Playbooks offer a repeatable, re-usable, simple configuration management and multi-machine deployment system, one that is well suited to deploying complex applications. If you need to execute a task with Ansible more than once, write a playbook and put it under source control. Then you can use the playbook to push out new configuration or confirm the configuration of remote systems. The playbooks in the `ansible-examples repository <https://github.com/ansible/ansible-examples>`_ illustrate many useful techniques. You may want to look at these in another tab as you read the documentation." +msgstr "Ansible Playbook は、繰り返し使用可能で、再利用可能なシンプルな構成管理および複数マシンのデプロイメントシステムであり、複雑なアプリケーションのデプロイメントに適しています。Ansible で複数回タスクを実行する必要がある場合は、Playbook を作成してソースコントロール下に置きます。その後、Playbook を使用して、新しい設定をプッシュアウトしたり、リモートシステムの設定を確認したりすることができます。`ansible-examples リポジトリー <https://github.com/ansible/ansible-examples>`_ の Playbook には、多くの便利なテクニックが紹介されています。ドキュメントを読みながら、これらを別のタブで見てみるのもいいかもしれません。" + +#: ../../rst/user_guide/playbooks_intro.rst:10 +msgid "Playbooks can:" +msgstr "Playbook は、以下のことができます。" + +#: ../../rst/user_guide/playbooks_intro.rst:12 +msgid "declare configurations" +msgstr "宣言設定" + +#: ../../rst/user_guide/playbooks_intro.rst:13 +msgid "orchestrate steps of any manual ordered process, on multiple sets of machines, in a defined order" +msgstr "複数のマシンセットで、手動で順序付けされたプロセスの手順を定義された順序で編成します。" + +#: ../../rst/user_guide/playbooks_intro.rst:14 +msgid "launch tasks synchronously or :ref:`asynchronously <playbooks_async>`" +msgstr "タスクを同期または :ref:`非同期 <playbooks_async>` で起動" + +#: ../../rst/user_guide/playbooks_intro.rst:22 +msgid "Playbook syntax" +msgstr "Playbook 構文" + +#: ../../rst/user_guide/playbooks_intro.rst:24 +msgid "Playbooks are expressed in YAML format with a minimum of syntax. If you are not familiar with YAML, look at our overview of :ref:`yaml_syntax` and consider installing an add-on for your text editor (see :ref:`other_tools_and_programs`) to help you write clean YAML syntax in your playbooks." +msgstr "Playbook は最小限の構文で YAML 形式で表現されます。YAML に慣れていない方は、:ref:`yaml_syntax` の概要を参照してください。また、Playbook にきれいな YAML 構文を書くために、テキストエディター用のアドオンのインストールを検討してください (「:ref:`other_tools_and_programs`」を参照)。" + +#: ../../rst/user_guide/playbooks_intro.rst:26 +msgid "A playbook is composed of one or more 'plays' in an ordered list. The terms 'playbook' and 'play' are sports analogies. Each play executes part of the overall goal of the playbook, running one or more tasks. Each task calls an Ansible module." +msgstr "Playbook は、1 つまたは複数の「プレイ」を順番に並べたものです。「Playbook」と「プレイ」という言葉は、スポーツに例えられています。各プレイは、Playbook の全体的な目標の一部を実行し、1 つまたは複数のタスクを実行します。各タスクは、Ansible モジュールを呼び出します。" + +#: ../../rst/user_guide/playbooks_intro.rst:29 +msgid "Playbook execution" +msgstr "Playbook 実行" + +#: ../../rst/user_guide/playbooks_intro.rst:31 +msgid "A playbook runs in order from top to bottom. Within each play, tasks also run in order from top to bottom. Playbooks with multiple 'plays' can orchestrate multi-machine deployments, running one play on your webservers, then another play on your database servers, then a third play on your network infrastructure, and so on. At a minimum, each play defines two things:" +msgstr "Playbook は、上から下に向かって順番に実行されます。各プレイの中では、タスクも上から下の順に実行されます。複数の「プレイ」を持つ Playbook では、複数のマシンのデプロイメントを編成することができます。あるプレイを Web サーバーで実行した後、別のプレイをデータベースサーバーで実行し、さらに 3 つ目のプレイをネットワークインフラストラクチャーで実行するといった具合です。最低限、各プレイは 2 つのことを定義します。" + +#: ../../rst/user_guide/playbooks_intro.rst:33 +msgid "the managed nodes to target, using a :ref:`pattern <intro_patterns>`" +msgstr ":ref:`pattern <intro_patterns>` を使用する管理ノードが対象である" + +#: ../../rst/user_guide/playbooks_intro.rst:34 +msgid "at least one task to execute" +msgstr "実行すべき 1 つ以上のタスク" + +#: ../../rst/user_guide/playbooks_intro.rst:38 +msgid "In Ansible 2.10 and later, we recommend you use the fully-qualified collection name in your playbooks to ensure the correct module is selected, because multiple collections can contain modules with the same name (for example, ``user``). See :ref:`collections_using_playbook`." +msgstr "Ansible 2.10 以降では、複数のコレクションに同じ名前のモジュールが含まれていることがあるため (例: ``user``)、正しいモジュールが選択されるように、Playbook で完全修飾コレクション名を使用することが推奨されます。「:ref:`collections_using_playbook`」を参照してください。" + +#: ../../rst/user_guide/playbooks_intro.rst:40 +msgid "In this example, the first play targets the web servers; the second play targets the database servers." +msgstr "この例では、第 1 のプレイは Web サーバーを対象とし、第 2 のプレイはデータベースサーバーを対象としています。" + +#: ../../rst/user_guide/playbooks_intro.rst:73 +msgid "Your playbook can include more than just a hosts line and tasks. For example, the playbook above sets a ``remote_user`` for each play. This is the user account for the SSH connection. You can add other :ref:`playbook_keywords` at the playbook, play, or task level to influence how Ansible behaves. Playbook keywords can control the :ref:`connection plugin <connection_plugins>`, whether to use :ref:`privilege escalation <become>`, how to handle errors, and more. To support a variety of environments, Ansible lets you set many of these parameters as command-line flags, in your Ansible configuration, or in your inventory. Learning the :ref:`precedence rules <general_precedence_rules>` for these sources of data will help you as you expand your Ansible ecosystem." +msgstr "Playbook には、ホストラインとタスク以外の情報も含めることができます。たとえば、上記の Playbook では、各プレイに ``remote_user`` を設定しています。これは、SSH 接続用のユーザーアカウントです。Playbook、プレイ、またはタスクレベルで他の :ref:`playbook_keywords` を追加して、Ansible の動作に影響を与えることができます。Playbook のキーワードでは、:ref:`connection プラグイン <connection_plugins>` で、:ref:`特権昇格 <become>` を使用するかどうか、エラーをどのように処理するかなどを制御できます。さまざまな環境に対応するため、Ansible では、これらのパラメーターの多くをコマンドラインフラグ、Ansible の構成、またはインベントリーで設定することができます。これらのデータソースの :ref:`優先順位のルール <general_precedence_rules>` を学ぶことは、Ansible のエコシステムを拡張する際に役立ちます。" + +#: ../../rst/user_guide/playbooks_intro.rst:78 +msgid "Task execution" +msgstr "タスクの実行" + +#: ../../rst/user_guide/playbooks_intro.rst:80 +msgid "By default, Ansible executes each task in order, one at a time, against all machines matched by the host pattern. Each task executes a module with specific arguments. When a task has executed on all target machines, Ansible moves on to the next task. You can use :ref:`strategies <playbooks_strategies>` to change this default behavior. Within each play, Ansible applies the same task directives to all hosts. If a task fails on a host, Ansible takes that host out of the rotation for the rest of the playbook." +msgstr "デフォルトでは、Ansible は、ホストパターンに一致するすべてのマシンに対して、各タスクを 1 つずつ順番に実行します。各タスクは、特定の引数を持つモジュールを実行します。タスクがすべてのターゲットマシンで実行すると、Ansible は次のタスクに移ります。このデフォルトの動作を変更するには、:ref:`ストラテジー <playbooks_strategies>` を使用します。各プレイの中で、Ansible は同じタスクディレクティブをすべてのホストに適用します。あるホストでタスクが失敗した場合、Ansible はそのホストを Playbook の残りの部分のローテーションから外します。" + +#: ../../rst/user_guide/playbooks_intro.rst:82 +msgid "When you run a playbook, Ansible returns information about connections, the ``name`` lines of all your plays and tasks, whether each task has succeeded or failed on each machine, and whether each task has made a change on each machine. At the bottom of the playbook execution, Ansible provides a summary of the nodes that were targeted and how they performed. General failures and fatal \"unreachable\" communication attempts are kept separate in the counts." +msgstr "Playbook を実行すると、Ansible は接続に関する情報、すべてのプレイとタスクの ``name`` 行、各タスクが各マシンで成功したか失敗したか、および各タスクが各マシンで変更を行ったかどうかを返します。Playbook の実行の最後に、Ansible は、対象となったノードとそのパフォーマンスの概要を表示します。一般的な失敗と致命的な「到達不能」の通信試行は、カウントの中で分けて表示されます。" + +#: ../../rst/user_guide/playbooks_intro.rst:87 +msgid "Desired state and 'idempotency'" +msgstr "希望の状態および「冪等性」" + +#: ../../rst/user_guide/playbooks_intro.rst:89 +msgid "Most Ansible modules check whether the desired final state has already been achieved, and exit without performing any actions if that state has been achieved, so that repeating the task does not change the final state. Modules that behave this way are often called 'idempotent.' Whether you run a playbook once, or multiple times, the outcome should be the same. However, not all playbooks and not all modules behave this way. If you are unsure, test your playbooks in a sandbox environment before running them multiple times in production." +msgstr "ほとんどの Ansible モジュールは、目的の最終状態がすでに達成されているかどうかを確認し、その状態が達成されている場合は何も実行せずに終了するため、タスクを繰り返しても最終状態は変わりません。このような動作をするモジュールは、しばしば「冪等性」と呼ばれます。Playbook を 1 回だけ実行しても、複数回実行しても、結果は同じになるはずです。しかし、すべての Playbook やすべてのモジュールがこのように動作するわけではありません。不安な場合は、実稼働環境で Playbook を複数回実行する前に、サンドボックス環境で Playbook をテストしてください。" + +#: ../../rst/user_guide/playbooks_intro.rst:94 +msgid "Running playbooks" +msgstr "Playbook の実行" + +#: ../../rst/user_guide/playbooks_intro.rst:96 +msgid "To run your playbook, use the :ref:`ansible-playbook` command." +msgstr "Playbook を実行するには、:ref:`ansible-playbook` コマンドを使用します。" + +#: ../../rst/user_guide/playbooks_intro.rst:102 +msgid "Use the ``--verbose`` flag when running your playbook to see detailed output from successful modules as well as unsuccessful ones." +msgstr "成功したモジュールと失敗したモジュールの詳細な出力を確認するには、Playbook の実行時に ``--verbose`` フラグを使用します。" + +#: ../../rst/user_guide/playbooks_intro.rst:107 +msgid "Ansible-Pull" +msgstr "ansible-pull" + +#: ../../rst/user_guide/playbooks_intro.rst:109 +msgid "Should you want to invert the architecture of Ansible, so that nodes check in to a central location, instead of pushing configuration out to them, you can." +msgstr "ノードに設定をプッシュするのではなく、Ansible のアーキテクチャーを逆にして、ノードが中央の場所にチェックインするようにしたい場合は、以下を行うことができます。" + +#: ../../rst/user_guide/playbooks_intro.rst:112 +msgid "The ``ansible-pull`` is a small script that will checkout a repo of configuration instructions from git, and then run ``ansible-playbook`` against that content." +msgstr "``ansible-pull`` は小さなスクリプトで、git から設定方法をまとめたリポジトリーをチェックアウトし、その内容に対して ``ansible-playbook`` を実行します。" + +#: ../../rst/user_guide/playbooks_intro.rst:115 +msgid "Assuming you load balance your checkout location, ``ansible-pull`` scales essentially infinitely." +msgstr "チェックアウトの場所を負荷分散する場合、``ansible-pull`` は基本的に無限にスケーリングを行います。" + +#: ../../rst/user_guide/playbooks_intro.rst:117 +msgid "Run ``ansible-pull --help`` for details." +msgstr "詳細は、「``ansible-pull --help``」を参照してください。" + +#: ../../rst/user_guide/playbooks_intro.rst:119 +msgid "There's also a `clever playbook <https://github.com/ansible/ansible-examples/blob/master/language_features/ansible_pull.yml>`_ available to configure ``ansible-pull`` via a crontab from push mode." +msgstr "また、プッシュモードからの crontab で ``ansible-pull`` を設定する際に利用可能な `優れた Playbook <https://github.com/ansible/ansible-examples/blob/master/language_features/ansible_pull.yml>`_ もあります。" + +#: ../../rst/user_guide/playbooks_intro.rst:122 +msgid "Verifying playbooks" +msgstr "Playbook の検証" + +#: ../../rst/user_guide/playbooks_intro.rst:124 +msgid "You may want to verify your playbooks to catch syntax errors and other problems before you run them. The :ref:`ansible-playbook` command offers several options for verification, including ``--check``, ``--diff``, ``--list-hosts``, ``--list-tasks``, and ``--syntax-check``. The :ref:`validate-playbook-tools` describes other tools for validating and testing playbooks." +msgstr "Playbook を実行する前に、構文エラーやその他の問題を検出するために、Playbook を検証したい場合があります。:ref:`ansible-playbook` コマンドには、``--check``、``--diff``、``--list-hosts``、``--list-tasks``、``--syntax-check`` など、検証のためのオプションが用意されています。「:ref:`validate-playbook-tools`」では、Playbook の検証とテストのための他のツールについて説明しています。" + +#: ../../rst/user_guide/playbooks_intro.rst:129 +msgid "ansible-lint" +msgstr "ansible-lint" + +#: ../../rst/user_guide/playbooks_intro.rst:131 +msgid "You can use `ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_ for detailed, Ansible-specific feedback on your playbooks before you execute them. For example, if you run ``ansible-lint`` on the playbook called ``verify-apache.yml`` near the top of this page, you should get the following results:" +msgstr "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_ を使用すると、Playbook を実行する前に、Playbook に対する Ansible 固有の詳細なフィードバックを得ることができます。たとえば、このページの上位にある ``verify-apache.yml`` という Playbook に対して ``ansible-lint`` を実行すると、以下のような結果が得られます。" + +#: ../../rst/user_guide/playbooks_intro.rst:140 +msgid "The `ansible-lint default rules <https://docs.ansible.com/ansible-lint/rules/default_rules.html>`_ page describes each error. For ``[403]``, the recommended fix is to change ``state: latest`` to ``state: present`` in the playbook." +msgstr "`ansible-lint デフォルトルール <https://docs.ansible.com/ansible-lint/rules/default_rules.html>`_ ページには、各エラーについて説明しています。``[403]`` については、Playbook で ``state: latest`` を ``state: present`` に変更することが推奨されます。" + +#: ../../rst/user_guide/playbooks_intro.rst:144 +msgid "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_" +msgstr "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_" + +#: ../../rst/user_guide/playbooks_intro.rst:145 +msgid "Learn how to test Ansible Playbooks syntax" +msgstr "Ansible Playbook 構文のテスト方法について" + +#: ../../rst/user_guide/playbooks_intro.rst:149 +msgid "Tips for managing playbooks in the real world" +msgstr "実際の Playbook の管理に関するさまざまなヒント" + +#: ../../rst/user_guide/playbooks_intro.rst:153 +msgid "Learn to extend Ansible by writing your own modules" +msgstr "独自のモジュールを作成して Ansible を拡張する方法について" + +#: ../../rst/user_guide/playbooks_intro.rst:157 +msgid "Complete end-to-end playbook examples" +msgstr "完全なエンドツーエンド Playbook の例" + +#: ../../rst/user_guide/playbooks_lookups.rst:5 +msgid "Lookups" +msgstr "ルックアップ (lookup)" + +#: ../../rst/user_guide/playbooks_lookups.rst:7 +msgid "Lookup plugins retrieve data from outside sources such as files, databases, key/value stores, APIs, and other services. Like all templating, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. Before Ansible 2.5, lookups were mostly used indirectly in ``with_<lookup>`` constructs for looping. Starting with Ansible 2.5, lookups are used more explicitly as part of Jinja2 expressions fed into the ``loop`` keyword." +msgstr "lookup プラグインは、ファイル、データベース、キー/値ストア、API、その他のサービスなどの外部ソースからデータを取得します。すべてのテンプレート化と同様に、lookup は Ansible のコントロールマシン上で実行され、評価されます。Ansible では、lookup プラグインが返すデータを、標準のテンプレートシステムを使用して利用できるようにします。Ansible 2.5 以前、lookup はほとんどの場合、``with_<lookup>`` のループのための構成で間接的に使用されていました。Ansible 2.5 以降、lookup は Jinja2 の式の一部として、より明示的に使用されるようになり、``loop`` キーワードに供給されるようになりました。" + +#: ../../rst/user_guide/playbooks_lookups.rst:12 +msgid "Using lookups in variables" +msgstr "変数での lookup の使用" + +#: ../../rst/user_guide/playbooks_lookups.rst:14 +msgid "You can populate variables using lookups. Ansible evaluates the value each time it is executed in a task (or template)." +msgstr "lookup を使用して変数を設定することができます。Ansible は、タスク (またはテンプレート) で実行されるたびに値を評価します。" + +#: ../../rst/user_guide/playbooks_lookups.rst:24 +msgid "For more details and a list of lookup plugins in ansible-core, see :ref:`plugins_lookup`. You may also find lookup plugins in collections. You can review a list of lookup plugins installed on your control machine with the command ``ansible-doc -l -t lookup``." +msgstr "ansible-core の lookup プラグインの詳細と一覧は、「:ref:`plugins_lookup`」を参照してください。また、lookup プラグインはコレクションにも含まれています。コントロールマシンにインストールされている lookup プラグインのリストは、``ansible-doc -l -t lookup`` コマンドで確認できます。" + +#: ../../rst/user_guide/playbooks_loops.rst:5 +msgid "Loops" +msgstr "ループ" + +#: ../../rst/user_guide/playbooks_loops.rst:7 +msgid "Ansible offers the ``loop``, ``with_<lookup>``, and ``until`` keywords to execute a task multiple times. Examples of commonly-used loops include changing ownership on several files and/or directories with the :ref:`file module <file_module>`, creating multiple users with the :ref:`user module <user_module>`, and repeating a polling step until a certain result is reached." +msgstr "Ansible には、``loop``、``with_<lookup>``、および ``until`` というキーワードがあり、1 つのタスクを複数回実行することができます。一般的に使用されるループの例としては、:ref:`file module <file_module>` で複数のファイルやディレクトリーの所有権を変更する、:ref:`user module <user_module>` で複数のユーザーを作成する、特定の結果が得られるまでポーリングステップを繰り返すなどがあります。" + +#: ../../rst/user_guide/playbooks_loops.rst:11 +msgid "We added ``loop`` in Ansible 2.5. It is not yet a full replacement for ``with_<lookup>``, but we recommend it for most use cases." +msgstr "Ansible 2.5 で ``loop`` を追加しました。``with_<lookup>`` は完全に置き換えるものではありませんが、ほとんどのユースケースで推奨されています。" + +#: ../../rst/user_guide/playbooks_loops.rst:12 +msgid "We have not deprecated the use of ``with_<lookup>`` - that syntax will still be valid for the foreseeable future." +msgstr "``with_<lookup>`` の使用は非推奨になっていません。この構文は、今後も有効です。" + +#: ../../rst/user_guide/playbooks_loops.rst:13 +msgid "We are looking to improve ``loop`` syntax - watch this page and the `changelog <https://github.com/ansible/ansible/tree/devel/changelogs>`_ for updates." +msgstr "``loop`` 構文を改善する場合は、このページと `changelog <https://github.com/ansible/ansible/tree/devel/changelogs>`_ で更新を確認します。" + +#: ../../rst/user_guide/playbooks_loops.rst:19 +msgid "Comparing ``loop`` and ``with_*``" +msgstr "``loop`` と ``with_*`` の比較" + +#: ../../rst/user_guide/playbooks_loops.rst:21 +msgid "The ``with_<lookup>`` keywords rely on :ref:`lookup_plugins` - even ``items`` is a lookup." +msgstr "``with_<lookup>`` キーワードは :ref:`lookup_plugins` に依存し、``items`` も lookup となります。" + +#: ../../rst/user_guide/playbooks_loops.rst:22 +msgid "The ``loop`` keyword is equivalent to ``with_list``, and is the best choice for simple loops." +msgstr "``loop`` キーワードは ``with_list`` と同等であり、単純なループに最適です。" + +#: ../../rst/user_guide/playbooks_loops.rst:23 +msgid "The ``loop`` keyword will not accept a string as input, see :ref:`query_vs_lookup`." +msgstr "``loop`` キーワードは文字列を入力として受け付けません。「:ref:`query_vs_lookup`」を参照してください。" + +#: ../../rst/user_guide/playbooks_loops.rst:24 +msgid "Generally speaking, any use of ``with_*`` covered in :ref:`migrating_to_loop` can be updated to use ``loop``." +msgstr "通常、「:ref:`migrating_to_loop`」で対応している ``with_*`` を使用すると、``loop`` を使用するように更新できます。" + +#: ../../rst/user_guide/playbooks_loops.rst:25 +msgid "Be careful when changing ``with_items`` to ``loop``, as ``with_items`` performed implicit single-level flattening. You may need to use ``flatten(1)`` with ``loop`` to match the exact outcome. For example, to get the same output as:" +msgstr "``with_items`` を ``loop`` に変更する際には、``with_items`` が暗黙の単一レベルのフラット化を行うため注意が必要です。正確な結果を得るためには、``flatten(1)`` と ``loop`` の併用が必要になる可能性があります。たとえば、次と同じ出力を得るには、" + +#: ../../rst/user_guide/playbooks_loops.rst:34 +msgid "you would need" +msgstr "以下が必要です。" + +#: ../../rst/user_guide/playbooks_loops.rst:40 +msgid "Any ``with_*`` statement that requires using ``lookup`` within a loop should not be converted to use the ``loop`` keyword. For example, instead of doing:" +msgstr "ループ内で ``lookup`` を使用する必要のある ``with_*`` 文は、``loop`` キーワードを使用するように変換しないでください。たとえば、代わりに、以下を行います。" + +#: ../../rst/user_guide/playbooks_loops.rst:46 +msgid "it's cleaner to keep" +msgstr "保持する方が見た目がすっきりします。" + +#: ../../rst/user_guide/playbooks_loops.rst:55 +msgid "Standard loops" +msgstr "標準ループ" + +#: ../../rst/user_guide/playbooks_loops.rst:58 +msgid "Iterating over a simple list" +msgstr "シンプルなリストでの反復" + +#: ../../rst/user_guide/playbooks_loops.rst:60 +msgid "Repeated tasks can be written as standard loops over a simple list of strings. You can define the list directly in the task." +msgstr "繰り返されるタスクは、文字列の単純なリストに対する標準的なループとして記述できます。このリストはタスクの中で直接定義できます。" + +#: ../../rst/user_guide/playbooks_loops.rst:73 +msgid "You can define the list in a variables file, or in the 'vars' section of your play, then refer to the name of the list in the task." +msgstr "変数ファイルでリストを定義するか、プレイの「vars」セクションで、タスク内のリストの名前を参照します。" + +#: ../../rst/user_guide/playbooks_loops.rst:79 +msgid "Either of these examples would be the equivalent of" +msgstr "これらの例のいずれも、以下と同等です。" + +#: ../../rst/user_guide/playbooks_loops.rst:95 +msgid "You can pass a list directly to a parameter for some plugins. Most of the packaging modules, like :ref:`yum <yum_module>` and :ref:`apt <apt_module>`, have this capability. When available, passing the list to a parameter is better than looping over the task. For example" +msgstr "いくつかのプラグインでは、パラメーターにリストを直接渡すことができます。:ref:`yum <yum_module>` や :ref:`apt <apt_module>` など、ほとんどのパッケージングモジュールにこの機能があります。利用できる場合は、リストをパラメーターに渡す方が、タスクをループさせるよりも良いでしょう。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_loops.rst:110 +msgid "Check the :ref:`module documentation <modules_by_category>` to see if you can pass a list to any particular module's parameter(s)." +msgstr ":ref:`モジュールのドキュメント <modules_by_category>` で、特定モジュールのパラメーターにリストを渡すことができるかどうかを確認します。" + +#: ../../rst/user_guide/playbooks_loops.rst:113 +msgid "Iterating over a list of hashes" +msgstr "ハッシュリストでの反復" + +#: ../../rst/user_guide/playbooks_loops.rst:115 +msgid "If you have a list of hashes, you can reference subkeys in a loop. For example:" +msgstr "ハッシュリストがある場合は、ループでサブキーを参照できます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_loops.rst:128 +msgid "When combining :ref:`conditionals <playbooks_conditionals>` with a loop, the ``when:`` statement is processed separately for each item. See :ref:`the_when_statement` for examples." +msgstr ":ref:`conditionals <playbooks_conditionals>` とループを組み合わせると、``when:`` 文は各項目について個別に処理されます。例は「:ref:`the_when_statement`」を参照してください。" + +#: ../../rst/user_guide/playbooks_loops.rst:132 +msgid "Iterating over a dictionary" +msgstr "ディクショナリーでの反復" + +#: ../../rst/user_guide/playbooks_loops.rst:134 +msgid "To loop over a dict, use the :ref:`dict2items <dict_filter>`:" +msgstr "ディクショナリーでループするには、:ref:`dict2items <dict_filter>` を使用します。" + +#: ../../rst/user_guide/playbooks_loops.rst:147 +msgid "Here, we are iterating over `tag_data` and printing the key and the value from it." +msgstr "ここでは、`tag_data` を繰り返し処理し、キーと値を出力します。" + +#: ../../rst/user_guide/playbooks_loops.rst:150 +msgid "Registering variables with a loop" +msgstr "ループによる変数の登録" + +#: ../../rst/user_guide/playbooks_loops.rst:152 +msgid "You can register the output of a loop as a variable. For example" +msgstr "ループの出力を変数として登録できます。たとえば、次のようになります。" + +#: ../../rst/user_guide/playbooks_loops.rst:163 +msgid "When you use ``register`` with a loop, the data structure placed in the variable will contain a ``results`` attribute that is a list of all responses from the module. This differs from the data structure returned when using ``register`` without a loop." +msgstr "``register`` をループで使用すると、変数に配置されるデータ構造には、モジュールからのすべての応答のリストである ``results`` 属性が含まれます。これは、``register`` をループなしで使用したときに返されるデータ構造とは異なります。" + +#: ../../rst/user_guide/playbooks_loops.rst:204 +msgid "Subsequent loops over the registered variable to inspect the results may look like" +msgstr "登録済みの変数で後続のループを実行して結果を検査すると、以下のようになります。" + +#: ../../rst/user_guide/playbooks_loops.rst:214 +msgid "During iteration, the result of the current item will be placed in the variable." +msgstr "反復時に、現在の項目の結果は変数に配置されます。" + +#: ../../rst/user_guide/playbooks_loops.rst:229 +msgid "Complex loops" +msgstr "複雑なループ" + +#: ../../rst/user_guide/playbooks_loops.rst:232 +msgid "Iterating over nested lists" +msgstr "入れ子のリストでの反復" + +#: ../../rst/user_guide/playbooks_loops.rst:234 +msgid "You can use Jinja2 expressions to iterate over complex lists. For example, a loop can combine nested lists." +msgstr "Jinja2 の式を使用して、複雑なリストを繰り返し処理することができます。たとえば、ループは入れ子になったリストを組み合わせることができます。" + +#: ../../rst/user_guide/playbooks_loops.rst:250 +msgid "Retrying a task until a condition is met" +msgstr "条件が満たされるまでタスクの再試行" + +#: ../../rst/user_guide/playbooks_loops.rst:254 +msgid "You can use the ``until`` keyword to retry a task until a certain condition is met. Here's an example:" +msgstr "``until`` キーワードを使用すると、ある条件が満たされるまでタスクを再試行することができます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_loops.rst:265 +msgid "This task runs up to 5 times with a delay of 10 seconds between each attempt. If the result of any attempt has \"all systems go\" in its stdout, the task succeeds. The default value for \"retries\" is 3 and \"delay\" is 5." +msgstr "このタスクは、各試行の間に 10 秒の遅延を置いて最大 5 回実行される。試行の結果、標準出力に「all systems go」と表示されていれば、タスクは成功です。「retries (再試行)」のデフォルト値は 3、「delay (遅延)」は 5 です。" + +#: ../../rst/user_guide/playbooks_loops.rst:267 +msgid "To see the results of individual retries, run the play with ``-vv``." +msgstr "個別の再試行の結果を表示するには、``-vv`` でプレイを実行します。" + +#: ../../rst/user_guide/playbooks_loops.rst:269 +msgid "When you run a task with ``until`` and register the result as a variable, the registered variable will include a key called \"attempts\", which records the number of the retries for the task." +msgstr "``until`` を使用してタスクを実行し、結果を変数として登録する場合は、登録済み変数には「attempts」と呼ばれる鍵が含まれ、タスクの再試行回数を記録します。" + +#: ../../rst/user_guide/playbooks_loops.rst:271 +msgid "You must set the ``until`` parameter if you want a task to retry. If ``until`` is not defined, the value for the ``retries`` parameter is forced to 1." +msgstr "タスクが再試行するには、``until`` パラメーターを設定する必要があります。``until`` が定義されていない場合は、``retries`` パラメーターの値が 1 に強制されます。" + +#: ../../rst/user_guide/playbooks_loops.rst:274 +msgid "Looping over inventory" +msgstr "インベントリーのループ" + +#: ../../rst/user_guide/playbooks_loops.rst:276 +msgid "To loop over your inventory, or just a subset of it, you can use a regular ``loop`` with the ``ansible_play_batch`` or ``groups`` variables." +msgstr "インベントリーやその一部だけをループさせるには、通常の ``loop`` に ``ansible_play_batch`` 変数や ``groups`` 変数を加えたものを使用することができます。" + +#: ../../rst/user_guide/playbooks_loops.rst:290 +msgid "There is also a specific lookup plugin ``inventory_hostnames`` that can be used like this" +msgstr "また、以下のような特定の lookup プラグイン ``inventory_hostnames`` も使用できます。" + +#: ../../rst/user_guide/playbooks_loops.rst:304 +msgid "More information on the patterns can be found in :ref:`intro_patterns`." +msgstr "パターンの詳細は、「:ref:`intro_patterns`」を参照してください。" + +#: ../../rst/user_guide/playbooks_loops.rst:309 +msgid "Ensuring list input for ``loop``: using ``query`` rather than ``lookup``" +msgstr "``loop`` のリスト入力の確保: ``lookup`` の代わりに ``query`` を使用" + +#: ../../rst/user_guide/playbooks_loops.rst:311 +msgid "The ``loop`` keyword requires a list as input, but the ``lookup`` keyword returns a string of comma-separated values by default. Ansible 2.5 introduced a new Jinja2 function named :ref:`query <query>` that always returns a list, offering a simpler interface and more predictable output from lookup plugins when using the ``loop`` keyword." +msgstr "``loop`` キーワードは入力としてリストを必要としますが、``lookup`` キーワードはデフォルトでコンマで区切られた値の文字列を返すようになっています。Ansible 2.5 では、:ref:`query <query>` という名前の新しい Jinja2 関数が導入され、常にリストを返すようになりました。これにより、インターフェースがシンプルになり、``loop`` キーワードを使用した場合の lookup プラグインの出力がより予測しやすくなりました。" + +#: ../../rst/user_guide/playbooks_loops.rst:313 +msgid "You can force ``lookup`` to return a list to ``loop`` by using ``wantlist=True``, or you can use ``query`` instead." +msgstr "``wantlist=True`` を使用すれば、``lookup`` がリストを ``loop`` に返すように強制したり、代わりに ``query`` を使用することもできます。" + +#: ../../rst/user_guide/playbooks_loops.rst:315 +msgid "The following two examples do the same thing." +msgstr "以下の2つの例は、同じことをします。" + +#: ../../rst/user_guide/playbooks_loops.rst:327 +msgid "Adding controls to loops" +msgstr "ループへのコントロールの追加" + +#: ../../rst/user_guide/playbooks_loops.rst:330 +msgid "The ``loop_control`` keyword lets you manage your loops in useful ways." +msgstr "``loop_control`` キーワードを使用すると、ループを便利な方法で管理できます。" + +#: ../../rst/user_guide/playbooks_loops.rst:333 +msgid "Limiting loop output with ``label``" +msgstr "``label`` を使用したループ出力の制限" + +#: ../../rst/user_guide/playbooks_loops.rst:336 +msgid "When looping over complex data structures, the console output of your task can be enormous. To limit the displayed output, use the ``label`` directive with ``loop_control``." +msgstr "複雑なデータ構造をループしていると、タスクのコンソール出力が膨大になることがあります。表示される出力を制限するには、``label`` ディレクティブと ``loop_control`` を使用します。" + +#: ../../rst/user_guide/playbooks_loops.rst:355 +msgid "The output of this task will display just the ``name`` field for each ``item`` instead of the entire contents of the multi-line ``{{ item }}`` variable." +msgstr "このタスクの出力には、複数行の ``{{ item }}`` 変数の内容全体ではなく、各 ``item`` の ``name`` フィールドのみが表示されます。" + +#: ../../rst/user_guide/playbooks_loops.rst:357 +msgid "This is for making console output more readable, not protecting sensitive data. If there is sensitive data in ``loop``, set ``no_log: yes`` on the task to prevent disclosure." +msgstr "これはコンソール出力を読みやすくするためのもので、機密データを保護するものではありません。``loop`` に機密データがある場合は、``no_log: yes`` をタスクに設定して漏洩を防ぎます。" + +#: ../../rst/user_guide/playbooks_loops.rst:360 +msgid "Pausing within a loop" +msgstr "ループ内での一時停止" + +#: ../../rst/user_guide/playbooks_loops.rst:363 +msgid "To control the time (in seconds) between the execution of each item in a task loop, use the ``pause`` directive with ``loop_control``." +msgstr "タスクループの各項目の実行間隔を (秒単位) で制御するには、``pause`` で ``loop_control`` ディレクティブを使用します。" + +#: ../../rst/user_guide/playbooks_loops.rst:379 +msgid "Tracking progress through a loop with ``index_var``" +msgstr "``index_var`` のあるループでの進捗の追跡" + +#: ../../rst/user_guide/playbooks_loops.rst:382 +msgid "To keep track of where you are in a loop, use the ``index_var`` directive with ``loop_control``. This directive specifies a variable name to contain the current loop index." +msgstr "ループ内のどこにいるかを把握するには、``loop_control`` とともに ``index_var`` ディレクティブを使用します。このディレクティブは、現在のループのインデックスを格納する変数名を指定します。" + +#: ../../rst/user_guide/playbooks_loops.rst:396 +msgid "`index_var` is 0 indexed." +msgstr "`index_var` は、0 インデックスです。" + +#: ../../rst/user_guide/playbooks_loops.rst:399 +msgid "Defining inner and outer variable names with ``loop_var``" +msgstr "``loop_var`` を使用した内部変数名および外部変数名の定義" + +#: ../../rst/user_guide/playbooks_loops.rst:402 +msgid "You can nest two looping tasks using ``include_tasks``. However, by default Ansible sets the loop variable ``item`` for each loop. This means the inner, nested loop will overwrite the value of ``item`` from the outer loop. You can specify the name of the variable for each loop using ``loop_var`` with ``loop_control``." +msgstr "``include_tasks`` を使用すると、2 つのループタスクを入れ子にすることができます。ただし、Ansible のデフォルトでは、ループごとにループ変数 ``item`` が設定されます。これは、入れ子になった内側のループが、外側のループの ``item`` の値を上書きすることを意味します。``loop_var`` と ``loop_control`` を使用して、各ループの変数名を指定することができます。" + +#: ../../rst/user_guide/playbooks_loops.rst:425 +msgid "If Ansible detects that the current loop is using a variable which has already been defined, it will raise an error to fail the task." +msgstr "定義されている変数を現在のループが使用していることを Ansible が検出すると、タスクが失敗するためにエラーが発生します。" + +#: ../../rst/user_guide/playbooks_loops.rst:428 +msgid "Extended loop variables" +msgstr "拡張ループ変数" + +#: ../../rst/user_guide/playbooks_loops.rst:431 +msgid "As of Ansible 2.8 you can get extended loop information using the ``extended`` option to loop control. This option will expose the following information." +msgstr "Ansible 2.8 では、ループ制御に ``extended`` オプションを使用することで、拡張されたループ情報を得ることができます。このオプションは、以下の情報を公開します。" + +#: ../../rst/user_guide/playbooks_loops.rst:434 +msgid "Variable" +msgstr "変数" + +#: ../../rst/user_guide/playbooks_loops.rst:436 +msgid "``ansible_loop.allitems``" +msgstr "``ansible_loop.allitems``" + +#: ../../rst/user_guide/playbooks_loops.rst:436 +msgid "The list of all items in the loop" +msgstr "ループ内のすべての項目のリスト" + +#: ../../rst/user_guide/playbooks_loops.rst:437 +msgid "``ansible_loop.index``" +msgstr "``ansible_loop.index``" + +#: ../../rst/user_guide/playbooks_loops.rst:437 +msgid "The current iteration of the loop. (1 indexed)" +msgstr "ループの現在の反復 (1 インデックス化)" + +#: ../../rst/user_guide/playbooks_loops.rst:438 +msgid "``ansible_loop.index0``" +msgstr "``ansible_loop.index0``" + +#: ../../rst/user_guide/playbooks_loops.rst:438 +msgid "The current iteration of the loop. (0 indexed)" +msgstr "ループの現在の反復 (0 インデックス化)" + +#: ../../rst/user_guide/playbooks_loops.rst:439 +msgid "``ansible_loop.revindex``" +msgstr "``ansible_loop.revindex``" + +#: ../../rst/user_guide/playbooks_loops.rst:439 +msgid "The number of iterations from the end of the loop (1 indexed)" +msgstr "ループの最後からの反復回数 (1 インデックス化)" + +#: ../../rst/user_guide/playbooks_loops.rst:440 +msgid "``ansible_loop.revindex0``" +msgstr "``ansible_loop.revindex0``" + +#: ../../rst/user_guide/playbooks_loops.rst:440 +msgid "The number of iterations from the end of the loop (0 indexed)" +msgstr "ループの最後からの反復回数 (0 インデックス化)" + +#: ../../rst/user_guide/playbooks_loops.rst:441 +msgid "``ansible_loop.first``" +msgstr "``ansible_loop.first``" + +#: ../../rst/user_guide/playbooks_loops.rst:441 +msgid "``True`` if first iteration" +msgstr "最初の反復の場合は ``True``" + +#: ../../rst/user_guide/playbooks_loops.rst:442 +msgid "``ansible_loop.last``" +msgstr "``ansible_loop.last``" + +#: ../../rst/user_guide/playbooks_loops.rst:442 +msgid "``True`` if last iteration" +msgstr "最後の反復の場合は ``True``" + +#: ../../rst/user_guide/playbooks_loops.rst:443 +msgid "``ansible_loop.length``" +msgstr "``ansible_loop.length``" + +#: ../../rst/user_guide/playbooks_loops.rst:443 +msgid "The number of items in the loop" +msgstr "ループ内の項目数" + +#: ../../rst/user_guide/playbooks_loops.rst:444 +msgid "``ansible_loop.previtem``" +msgstr "``ansible_loop.previtem``" + +#: ../../rst/user_guide/playbooks_loops.rst:444 +msgid "The item from the previous iteration of the loop. Undefined during the first iteration." +msgstr "ループの前の反復の項目。最初の反復では未定義です。" + +#: ../../rst/user_guide/playbooks_loops.rst:445 +msgid "``ansible_loop.nextitem``" +msgstr "``ansible_loop.nextitem``" + +#: ../../rst/user_guide/playbooks_loops.rst:445 +msgid "The item from the following iteration of the loop. Undefined during the last iteration." +msgstr "ループの次の反復の項目。最初の反復では未定義です。" + +#: ../../rst/user_guide/playbooks_loops.rst:453 +msgid "When using ``loop_control.extended`` more memory will be utilized on the control node. This is a result of ``ansible_loop.allitems`` containing a reference to the full loop data for every loop. When serializing the results for display in callback plugins within the main ansible process, these references may be dereferenced causing memory usage to increase." +msgstr "``loop_control.extended`` を使用すると、制御ノードでより多くのメモリーが使用されます。これは、すべてのループの完全なループデータへの参照が含まれる ``ansible_loop.allitems`` の結果です。メインのAnsibleプロセス内のコールバックプラグインに表示するために結果をシリアル化すると、これらの参照が逆参照され、メモリー使用量が増加する可能性があります。" + +#: ../../rst/user_guide/playbooks_loops.rst:456 +msgid "Accessing the name of your loop_var" +msgstr "loop_var の名前へのアクセス" + +#: ../../rst/user_guide/playbooks_loops.rst:459 +msgid "As of Ansible 2.8 you can get the name of the value provided to ``loop_control.loop_var`` using the ``ansible_loop_var`` variable" +msgstr "Ansible 2.8 では、``ansible_loop_var`` 変数を使用して ``loop_control.loop_var`` に提供された値の名前を取得できます。" + +#: ../../rst/user_guide/playbooks_loops.rst:461 +msgid "For role authors, writing roles that allow loops, instead of dictating the required ``loop_var`` value, you can gather the value via the following" +msgstr "ロールの作成者は、必要な ``loop_var`` 値を指定する代わりに、ループを許可するロールを作成することで、次の方法で値を収集できます。" + +#: ../../rst/user_guide/playbooks_loops.rst:470 +msgid "Migrating from with_X to loop" +msgstr "with_X から loop への移行" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:1 +msgid "In most cases, loops work best with the ``loop`` keyword instead of ``with_X`` style loops. The ``loop`` syntax is usually best expressed using filters instead of more complex use of ``query`` or ``lookup``." +msgstr "ほとんどの場合、ループは、``with_X`` スタイルのループではなく、``loop`` キーワードで最適に機能します。``loop`` 構文は通常、``query`` や ``lookup`` の複雑な使用ではなく、フィルターを使用して表現できます。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:3 +msgid "These examples show how to convert many common ``with_`` style loops to ``loop`` and filters." +msgstr "以下の例では、一般的な ``with_`` スタイルのループを ``loop`` およびフィルターに変換する方法を示しています。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:6 +msgid "with_list" +msgstr "with_list" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:8 +msgid "``with_list`` is directly replaced by ``loop``." +msgstr "``with_list`` は、直接 ``loop`` に置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:27 +msgid "with_items" +msgstr "with_items" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:29 +msgid "``with_items`` is replaced by ``loop`` and the ``flatten`` filter." +msgstr "``with_items`` は、``loop`` フィルターおよび ``flatten`` フィルターに置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:44 +msgid "with_indexed_items" +msgstr "with_indexed_items" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:46 +msgid "``with_indexed_items`` is replaced by ``loop``, the ``flatten`` filter and ``loop_control.index_var``." +msgstr "``with_indexed_items`` は、``loop``、``flatten`` フィルター、および ``loop_control.index_var`` に置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:63 +msgid "with_flattened" +msgstr "with_flattened" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:65 +msgid "``with_flattened`` is replaced by ``loop`` and the ``flatten`` filter." +msgstr "``with_flattened`` は、``loop`` フィルターおよび ``flatten`` フィルターに置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:80 +msgid "with_together" +msgstr "with_together" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:82 +msgid "``with_together`` is replaced by ``loop`` and the ``zip`` filter." +msgstr "``with_together`` は、``loop`` フィルターおよび ``zip`` フィルターに置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:98 +msgid "Another example with complex data" +msgstr "複雑なデータがある別の例" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:113 +msgid "with_dict" +msgstr "with_dict" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:115 +msgid "``with_dict`` can be substituted by ``loop`` and either the ``dictsort`` or ``dict2items`` filters." +msgstr "``with_dict`` は、``loop`` フィルターと、``dictsort`` フィルターまたは ``dict2items`` フィルターのいずれかのフィルターに置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:135 +msgid "with_sequence" +msgstr "with_sequence" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:137 +msgid "``with_sequence`` is replaced by ``loop`` and the ``range`` function, and potentially the ``format`` filter." +msgstr "``with_sequence`` は、``loop`` 関数と ``range`` の関数、そして潜在的には ``format`` フィルターに置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:153 +msgid "with_subelements" +msgstr "with_subelements" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:155 +msgid "``with_subelements`` is replaced by ``loop`` and the ``subelements`` filter." +msgstr "``with_subelements`` は、``loop`` フィルターおよび ``subelements`` フィルターに置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:172 +msgid "with_nested/with_cartesian" +msgstr "with_nested/with_cartesian" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:174 +msgid "``with_nested`` and ``with_cartesian`` are replaced by loop and the ``product`` filter." +msgstr "``with_nested`` と``with_cartesian`` は、ループと ``product`` のフィルターに置き換えられました。" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:191 +msgid "with_random_choice" +msgstr "with_random_choice" + +#: ../../rst/user_guide/shared_snippets/with2loop.txt:193 +msgid "``with_random_choice`` is replaced by just use of the ``random`` filter, without need of ``loop``." +msgstr "``with_random_choice`` は、``random`` フィルターを使用するだけで、``loop`` を必要とせずに置き換えることができます。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:4 +msgid "Module defaults" +msgstr "モジュールのデフォルト" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:6 +msgid "If you frequently call the same module with the same arguments, it can be useful to define default arguments for that particular module using the ``module_defaults`` keyword." +msgstr "同じ引数で同じモジュールを頻繁に呼び出す場合は、``module_defaults`` キーワードを使用して、その特定のモジュールのデフォルト引数を定義すると便利です。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:8 +msgid "Here is a basic example:" +msgstr "以下に基本的な例を示します。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:34 +msgid "The ``module_defaults`` keyword can be used at the play, block, and task level. Any module arguments explicitly specified in a task will override any established default for that module argument." +msgstr "``module_defaults`` キーワードは、プレイ、ブロック、およびタスクレベルで使用できます。タスクで明示的に指定されたモジュール引数は、そのモジュール引数に対して確立されたデフォルトを上書きします。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:46 +msgid "You can remove any previously established defaults for a module by specifying an empty dict." +msgstr "空のディクショナリーを指定することで、それまでに設定されたモジュールのデフォルトを削除することができます。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:58 +msgid "Any module defaults set at the play level (and block/task level when using ``include_role`` or ``import_role``) will apply to any roles used, which may cause unexpected behavior in the role." +msgstr "プレイレベルで設定されるモジュールのデフォルト (``include_role`` または ``import_role`` を使用する際のブロックまたはタスクのレベル) は、使用されるロールに適用されます。これにより、ロールで予期しない動作が発生する可能性があります。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:60 +msgid "Here are some more realistic use cases for this feature." +msgstr "この機能のより実用的なユースケースを以下に示します。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:62 +msgid "Interacting with an API that requires auth." +msgstr "認証をを必要とする API との対話:" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:85 +msgid "Setting a default AWS region for specific EC2-related modules." +msgstr "特定の EC2 関連のモジュールにデフォルトの AWS リージョンを設定します。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:103 +msgid "Module defaults groups" +msgstr "モジュールのデフォルトグループ" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:107 +msgid "Ansible 2.7 adds a preview-status feature to group together modules that share common sets of parameters. This makes it easier to author playbooks making heavy use of API-based modules such as cloud modules." +msgstr "Ansible 2.7 では、共通のパラメーターセットを持つモジュールをまとめて表示するプレビューステータス機能が追加されました。これにより、クラウドモジュールなどの API ベースのモジュールを多用する Playbook の作成が容易になります。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:110 +msgid "Group" +msgstr "グループ" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:110 +msgid "Purpose" +msgstr "目的" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:110 +msgid "Ansible Version" +msgstr "Ansible バージョン" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:112 +msgid "aws" +msgstr "aws" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:112 +msgid "Amazon Web Services" +msgstr "Amazon Web Services" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:112 +#: ../../rst/user_guide/playbooks_module_defaults.rst:114 +#: ../../rst/user_guide/playbooks_module_defaults.rst:116 +msgid "2.7" +msgstr "2.7" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:114 +msgid "azure" +msgstr "azure" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:114 +msgid "Azure" +msgstr "Azure" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:116 +msgid "gcp" +msgstr "gcp" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:116 +msgid "Google Cloud Platform" +msgstr "Google Cloud Platform" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:118 +msgid "k8s" +msgstr "k8s" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:118 +msgid "Kubernetes" +msgstr "Kubernetes" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:118 +#: ../../rst/user_guide/playbooks_module_defaults.rst:120 +msgid "2.8" +msgstr "2.8" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:120 +msgid "os" +msgstr "os" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:120 +msgid "OpenStack" +msgstr "OpenStack" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:122 +msgid "acme" +msgstr "acme" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:122 +msgid "ACME" +msgstr "ACME" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:122 +#: ../../rst/user_guide/playbooks_module_defaults.rst:124 +#: ../../rst/user_guide/playbooks_module_defaults.rst:126 +#: ../../rst/user_guide/playbooks_module_defaults.rst:128 +msgid "2.10" +msgstr "2.10" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:124 +msgid "docker*" +msgstr "docker*" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:124 +msgid "Docker" +msgstr "Docker" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:126 +msgid "ovirt" +msgstr "ovirt" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:126 +msgid "oVirt" +msgstr "oVirt" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:128 +msgid "vmware" +msgstr "vmware" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:128 +msgid "VMware" +msgstr "VMware" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:131 +msgid "The `docker_stack <docker_stack_module>`_ module is not included in the ``docker`` defaults group." +msgstr "`docker_stack <docker_stack_module>`_ モジュールは、``docker`` デフォルトグループには含まれません。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:133 +msgid "Use the groups with ``module_defaults`` by prefixing the group name with ``group/`` - for example ``group/aws``." +msgstr "グループ名の前に ``group/`` を追加して (例: ``group/aws``)、``module_defaults`` でグループを使用します。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:135 +msgid "In a playbook, you can set module defaults for whole groups of modules, such as setting a common AWS region." +msgstr "Playbook では、一般的な AWS リージョンの設定など、モジュールのグループ全体にモジュールのデフォルトを設定できます。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:155 +msgid "In ansible-core 2.12, collections can define their own groups in the ``meta/runtime.yml`` file. ``module_defaults`` does not take the ``collections`` keyword into account, so the fully qualified group name must be used for new groups in ``module_defaults``." +msgstr "ansible-core 2.12 では、コレクションは ``meta/runtime.yml`` ファイルで独自のグループを定義できます。``module_defaults`` は ``collections`` キーワードを考慮に入れないため、完全修飾グループ名を ``module_defaults`` の新規グループに使用する必要があります。" + +#: ../../rst/user_guide/playbooks_module_defaults.rst:157 +msgid "Here is an example ``runtime.yml`` file for a collection and a sample playbook using the group." +msgstr "以下は、グループを使用したコレクションおよびサンプル Playbook の ``runtime.yml`` ファイルの例です。" + +#: ../../rst/user_guide/playbooks_prompts.rst:5 +msgid "Interactive input: prompts" +msgstr "インタラクティブな入力: prompt" + +#: ../../rst/user_guide/playbooks_prompts.rst:7 +msgid "If you want your playbook to prompt the user for certain input, add a 'vars_prompt' section. Prompting the user for variables lets you avoid recording sensitive data like passwords. In addition to security, prompts support flexibility. For example, if you use one playbook across multiple software releases, you could prompt for the particular release version." +msgstr "Playbook でユーザーに特定の入力を促したい場合は、「vars_prompt」セクションを追加します。ユーザーに変数の入力を促すことで、パスワードのような機密データの記録を回避することができます。セキュリティーのほかに、プロンプトは柔軟性をサポートします。たとえば、1 つの Playbook を複数のソフトウェアリリースで使用する場合は、特定のリリースバージョンの入力を促すことができます。" + +#: ../../rst/user_guide/playbooks_prompts.rst:12 +msgid "Here is a most basic example:" +msgstr "以下は最も基本的な例です。" + +#: ../../rst/user_guide/playbooks_prompts.rst:33 +msgid "The user input is hidden by default but it can be made visible by setting ``private: no``." +msgstr "ユーザー入力はデフォルトでは表示されませんが、``private: no`` を設定することで表示できます。" + +#: ../../rst/user_guide/playbooks_prompts.rst:36 +msgid "Prompts for individual ``vars_prompt`` variables will be skipped for any variable that is already defined through the command line ``--extra-vars`` option, or when running from a non-interactive session (such as cron or Ansible AWX). See :ref:`passing_variables_on_the_command_line`." +msgstr "個別の ``vars_prompt`` 変数の入力を求めるプロンプトは、コマンドラインの ``--extra-vars`` オプションですでに定義されている変数や、非対話的なセッション (cron や Ansible AWX など) から実行する場合に省略されます。「:ref:`passing_variables_on_the_command_line`」を参照してください。" + +#: ../../rst/user_guide/playbooks_prompts.rst:38 +msgid "If you have a variable that changes infrequently, you can provide a default value that can be overridden." +msgstr "まれに変更する変数がある場合は、上書きできるデフォルト値を指定できます。" + +#: ../../rst/user_guide/playbooks_prompts.rst:49 +msgid "Hashing values supplied by ``vars_prompt``" +msgstr "``vars_prompt`` により提供される値のハッシュ処理" + +#: ../../rst/user_guide/playbooks_prompts.rst:51 +msgid "You can hash the entered value so you can use it, for instance, with the user module to define a password:" +msgstr "入力された値をハッシュ処理することができます。したがって、たとえばユーザーモジュールで使用してパスワードを定義できます。" + +#: ../../rst/user_guide/playbooks_prompts.rst:64 +msgid "If you have `Passlib <https://passlib.readthedocs.io/en/stable/>`_ installed, you can use any crypt scheme the library supports:" +msgstr "`Passlib <https://passlib.readthedocs.io/en/stable/>`_ をインストールしている場合は、ライブラリーがサポートする任意の crypt スキームを使用できます。" + +#: ../../rst/user_guide/playbooks_prompts.rst:66 +msgid "*des_crypt* - DES Crypt" +msgstr "*des_crypt* - DES Crypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:67 +msgid "*bsdi_crypt* - BSDi Crypt" +msgstr "*bsdi_crypt* - BSDi Crypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:68 +msgid "*bigcrypt* - BigCrypt" +msgstr "*bigcrypt* - BigCrypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:69 +msgid "*crypt16* - Crypt16" +msgstr "*crypt16* - Crypt16" + +#: ../../rst/user_guide/playbooks_prompts.rst:70 +#: ../../rst/user_guide/playbooks_prompts.rst:93 +msgid "*md5_crypt* - MD5 Crypt" +msgstr "*md5_crypt* - MD5 Crypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:71 +#: ../../rst/user_guide/playbooks_prompts.rst:92 +msgid "*bcrypt* - BCrypt" +msgstr "*bcrypt* - BCrypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:72 +msgid "*sha1_crypt* - SHA-1 Crypt" +msgstr "*sha1_crypt* - SHA-1 Crypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:73 +msgid "*sun_md5_crypt* - Sun MD5 Crypt" +msgstr "*sun_md5_crypt* - Sun MD5 Crypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:74 +#: ../../rst/user_guide/playbooks_prompts.rst:94 +msgid "*sha256_crypt* - SHA-256 Crypt" +msgstr "*sha256_crypt* - SHA-256 Crypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:75 +#: ../../rst/user_guide/playbooks_prompts.rst:95 +msgid "*sha512_crypt* - SHA-512 Crypt" +msgstr "*sha512_crypt* - SHA-512 Crypt" + +#: ../../rst/user_guide/playbooks_prompts.rst:76 +msgid "*apr_md5_crypt* - Apache's MD5-Crypt variant" +msgstr "*apr_md5_crypt* - Apache's MD5-Crypt variant" + +#: ../../rst/user_guide/playbooks_prompts.rst:77 +msgid "*phpass* - PHPass' Portable Hash" +msgstr "*phpass* - PHPass' Portable Hash" + +#: ../../rst/user_guide/playbooks_prompts.rst:78 +msgid "*pbkdf2_digest* - Generic PBKDF2 Hashes" +msgstr "*pbkdf2_digest* - Generic PBKDF2 Hashes" + +#: ../../rst/user_guide/playbooks_prompts.rst:79 +msgid "*cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash" +msgstr "*cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash" + +#: ../../rst/user_guide/playbooks_prompts.rst:80 +msgid "*dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash" +msgstr "*dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash" + +#: ../../rst/user_guide/playbooks_prompts.rst:81 +msgid "*scram* - SCRAM Hash" +msgstr "*scram* - SCRAM Hash" + +#: ../../rst/user_guide/playbooks_prompts.rst:82 +msgid "*bsd_nthash* - FreeBSD's MCF-compatible nthash encoding" +msgstr "*bsd_nthash* - FreeBSD's MCF 互換の nthash エンコーディング" + +#: ../../rst/user_guide/playbooks_prompts.rst:84 +msgid "The only parameters accepted are 'salt' or 'salt_size'. You can use your own salt by defining 'salt', or have one generated automatically using 'salt_size'. By default Ansible generates a salt of size 8." +msgstr "使用できるパラメーターは「salt」または「salt_size」のみです。「salt」を定義して独自のソルトを使用することも、「salt_size」を使用して自動的に生成されるソルトを使用することもできます。デフォルトでは、Ansible はサイズ 8 の salt を生成します。" + +#: ../../rst/user_guide/playbooks_prompts.rst:90 +msgid "If you do not have Passlib installed, Ansible uses the `crypt <https://docs.python.org/3/library/crypt.html>`_ library as a fallback. Ansible supports at most four crypt schemes, depending on your platform at most the following crypt schemes are supported:" +msgstr "Passlib がインストールされていない場合、Ansible はフォールバックとして `crypt <https://docs.python.org/3/library/crypt.html>`_ ライブラリーを使用します。Ansible は最大で 4 つの暗号方式をサポートしていますが、プラットフォームによっては最大で以下の暗号方式をサポートしています。" + +#: ../../rst/user_guide/playbooks_prompts.rst:101 +msgid "Allowing special characters in ``vars_prompt`` values" +msgstr "``vars_prompt`` 値での特殊文字の許可" + +#: ../../rst/user_guide/playbooks_prompts.rst:103 +msgid "Some special characters, such as ``{`` and ``%`` can create templating errors. If you need to accept special characters, use the ``unsafe`` option:" +msgstr "``{`` や ``%`` などの特殊文字は、テンプレートエラーの作成が可能です。特殊文字を受け入れる必要がある場合は、``unsafe`` オプションを使用します。" + +#: ../../rst/user_guide/playbooks_python_version.rst:5 +msgid "Python3 in templates" +msgstr "テンプレート内の Python3" + +#: ../../rst/user_guide/playbooks_python_version.rst:7 +msgid "Ansible uses Jinja2 to take advantage of Python data types and standard functions in templates and variables. You can use these data types and standard functions to perform a rich set of operations on your data. However, if you use templates, you must be aware of differences between Python versions." +msgstr "Ansible は Jinja2 を使用して、テンプレートや変数に Python のデータ型や標準関数を活用しています。これらのデータ型や標準関数を利用することで、データに対して豊富な操作を行うことができます。ただし、テンプレートを使用する場合は、Python のバージョンによる違いに注意する必要があります。" + +#: ../../rst/user_guide/playbooks_python_version.rst:11 +msgid "These topics help you design templates that work on both Python2 and Python3. They might also help if you are upgrading from Python2 to Python3. Upgrading within Python2 or Python3 does not usually introduce changes that affect Jinja2 templates." +msgstr "これらのトピックは、Python2 と Python3 の両方で動作するテンプレートをデザインするのに役立ちます。また、Python2 から Python3 へのアップグレードの際にも役立つでしょう。Python2 や Python3 にアップグレードしても、通常は Jinja2 のテンプレートに影響を与えるような変更はありません。" + +#: ../../rst/user_guide/playbooks_python_version.rst:16 +msgid "Dictionary views" +msgstr "ディクショナリービュー" + +#: ../../rst/user_guide/playbooks_python_version.rst:18 +msgid "In Python2, the :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` methods return a list. Jinja2 returns that to Ansible via a string representation that Ansible can turn back into a list." +msgstr "Python2 では、:meth:`dict.keys`、:meth:`dict.values`、および :meth:`dict.items` メソッドはリストを返します。Jinja2 は、Ansible がリストに戻ってきた文字列表現で Ansible に返します。" + +#: ../../rst/user_guide/playbooks_python_version.rst:22 +msgid "In Python3, those methods return a :ref:`dictionary view <python3:dict-views>` object. The string representation that Jinja2 returns for dictionary views cannot be parsed back into a list by Ansible. It is, however, easy to make this portable by using the :func:`list <jinja2:jinja-filters.list>` filter whenever using :meth:`dict.keys`, :meth:`dict.values`, or :meth:`dict.items`." +msgstr "Python3 では、これらのメソッドは :ref:`ディクショナリービュー <python3:dict-views>` オブジェクトを返します。Jinja2 がディクショナリービューに返す文字列表現は、Ansible ではリストに解析し直すことができません。しかし、:meth:`dict.keys`、:meth:`dict.values`、または :meth:`dict.items` を使用する際には必ず :func:`list <jinja2:jinja-filters.list>` フィルターを使用することで、簡単に移植することができます。" + +#: ../../rst/user_guide/playbooks_python_version.rst:45 +msgid "dict.iteritems()" +msgstr "dict.iteritems()" + +#: ../../rst/user_guide/playbooks_python_version.rst:47 +msgid "Python2 dictionaries have :meth:`~dict.iterkeys`, :meth:`~dict.itervalues`, and :meth:`~dict.iteritems` methods." +msgstr "Python2 ディクショナリーには、:meth:`~dict.iterkeys` メソッド、:meth:`~dict.itervalues` メソッド、および :meth:`~dict.iteritems` メソッドがあります。" + +#: ../../rst/user_guide/playbooks_python_version.rst:49 +msgid "Python3 dictionaries do not have these methods. Use :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` to make your playbooks and templates compatible with both Python2 and Python3." +msgstr "Python3 ディクショナリーにはこれらのメソッドがありません。:meth:`dict.keys`、:meth:`dict.values`、および :meth:`dict.items` を使用して、Playbook およびテンプレートを Python2 と Python3 の両方に対応させてください。" + +#: ../../rst/user_guide/playbooks_python_version.rst:66 +msgid "The :ref:`pb-py-compat-dict-views` entry for information on why the :func:`list filter <jinja2:jinja-filters.list>` is necessary here." +msgstr "ここで :func:`list filter <jinja2:jinja-filters.list>` が必要な理由は、:ref:`pb-py-compat-dict-views` エントリーを参照してください。" + +#: ../../rst/user_guide/playbooks_reuse.rst:5 +msgid "Re-using Ansible artifacts" +msgstr "Ansible アーティファクトの再利用" + +#: ../../rst/user_guide/playbooks_reuse.rst:7 +msgid "You can write a simple playbook in one very large file, and most users learn the one-file approach first. However, breaking your automation work up into smaller files is an excellent way to organize complex sets of tasks and reuse them. Smaller, more distributed artifacts let you re-use the same variables, tasks, and plays in multiple playbooks to address different use cases. You can use distributed artifacts across multiple parent playbooks or even multiple times within one playbook. For example, you might want to update your customer database as part of several different playbooks. If you put all the tasks related to updating your database in a tasks file or a role, you can re-use them in many playbooks while only maintaining them in one place." +msgstr "簡単な Playbook を非常に大きな 1 つのファイルに書くことができるため、ほとんどのユーザーはまず 1 つのファイルを使用した方法を学びます。しかし、自動化作業を小さなファイルに分割することは、複雑なタスクのセットを整理して再利用するための優れた方法です。小さく分散されたアーティファクトを使用して、同じ変数、タスク、プレイを複数の Playbook で再利用し、異なるユースケースに対応することができます。分散されたアーティファクトは、複数の親 Playbook にまたがって使用することも、1 つの Playbook 内で複数回使用することもできます。たとえば、複数の Playbook の一部として顧客データベースを更新する場合があります。データベースの更新に関連するすべてのタスクをタスクファイルにまとめておけば、それらを 1 カ所で管理するだけで、多くの Playbook で再利用することができます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:13 +msgid "Creating re-usable files and roles" +msgstr "再利用可能なファイルおよびロールの作成" + +#: ../../rst/user_guide/playbooks_reuse.rst:15 +msgid "Ansible offers four distributed, re-usable artifacts: variables files, task files, playbooks, and roles." +msgstr "Ansible は、変数ファイル、タスクファイル、Playbook、およびロールの 4 つに分散した再利用可能なアーティファクトを提供します。" + +#: ../../rst/user_guide/playbooks_reuse.rst:17 +msgid "A variables file contains only variables." +msgstr "変数ファイルには変数のみが含まれます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:18 +msgid "A task file contains only tasks." +msgstr "タスクファイルにはタスクのみが含まれます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:19 +msgid "A playbook contains at least one play, and may contain variables, tasks, and other content. You can re-use tightly focused playbooks, but you can only re-use them statically, not dynamically." +msgstr "Playbook には、少なくとも 1 つのプレイが含まれており、変数、タスク、その他のコンテンツを含むことができます。厳密に焦点を絞った Playbook は再利用できますが、動的にではなく静的にしか再利用できません。" + +#: ../../rst/user_guide/playbooks_reuse.rst:20 +msgid "A role contains a set of related tasks, variables, defaults, handlers, and even modules or other plugins in a defined file-tree. Unlike variables files, task files, or playbooks, roles can be easily uploaded and shared via Ansible Galaxy. See :ref:`playbooks_reuse_roles` for details about creating and using roles." +msgstr "ロールには、関連するタスク、変数、デフォルト、ハンドラー、さらにはモジュールや他のプラグインのセットが、定義されたファイルツリーに格納されています。変数ファイル、タスクファイル、Playbook とは異なり、ロールは Ansible Galaxy で簡単にアップロードして共有することができます。ロールの作成と使用の詳細については、「:ref:`playbooks_reuse_roles`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse.rst:25 +msgid "Re-using playbooks" +msgstr "Playbook の再利用" + +#: ../../rst/user_guide/playbooks_reuse.rst:27 +msgid "You can incorporate multiple playbooks into a main playbook. However, you can only use imports to re-use playbooks. For example:" +msgstr "複数の Playbook をメインの Playbook に組み込むことができますが、インポートのみを使用して Playbook を再使用できます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_reuse.rst:34 +msgid "Importing incorporates playbooks in other playbooks statically. Ansible runs the plays and tasks in each imported playbook in the order they are listed, just as if they had been defined directly in the main playbook." +msgstr "インポートでは、他の Playbook に静的に Playbook を組み込みます。Ansible は、インポートした各 Playbook 内のプレイやタスクを、メインの Playbook で直接定義した場合と同様に、リストに記載された順に実行します。" + +#: ../../rst/user_guide/playbooks_reuse.rst:36 +msgid "You can select which playbook you want to import at runtime by defining your imported playbook filename with a variable, then passing the variable with either ``--extra-vars`` or the ``vars`` keyword. For example:" +msgstr "変数でインポートされた Playbook ファイルを定義し、``--extra-vars`` または ``vars`` キーワードで変数を渡すことで、ランタイム時にインポートする Playbook を選択できます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_reuse.rst:45 +msgid "If you run this playbook with ``ansible-playbook my_playbook -e import_from_extra_var=other_playbook.yml``, Ansible imports both one_playbook.yml and other_playbook.yml." +msgstr "``ansible-playbook my_playbook -e import_from_extra_var=other_playbook.yml`` を使用してこの Playbook を実行すると、Ansible は one_playbook.yml と other_playbook.yml の両方をインポートします。" + +#: ../../rst/user_guide/playbooks_reuse.rst:48 +msgid "When to turn a playbook into a role" +msgstr "Playbook をロールに変換するタイミング" + +#: ../../rst/user_guide/playbooks_reuse.rst:50 +msgid "For some use cases, simple playbooks work well. However, starting at a certain level of complexity, roles work better than playbooks. A role lets you store your defaults, handlers, variables, and tasks in separate directories, instead of in a single long document. Roles are easy to share on Ansible Galaxy. For complex use cases, most users find roles easier to read, understand, and maintain than all-in-one playbooks." +msgstr "一部のユースケースでは、簡単な Playbook は適切に機能します。ただし、複雑さがあるレベルを超えると、ロールは Playbook よりも優れています。ロールを使用すると、デフォルト、ハンドラー、変数、タスクを、単一の長いドキュメントではなく、個別のディレクトリーに保存できます。ロールは、Ansible Galaxy で簡単に共有できます。複雑なユースケースでは、ほとんどのユーザーは、オールインワンの Playbook よりもロールの方が読んで理解して維持するのが簡単だと感じています。" + +#: ../../rst/user_guide/playbooks_reuse.rst:53 +msgid "Re-using files and roles" +msgstr "ファイルおよびロールの再利用" + +#: ../../rst/user_guide/playbooks_reuse.rst:55 +msgid "Ansible offers two ways to re-use files and roles in a playbook: dynamic and static." +msgstr "Ansible は、Playbook でファイルとロールを再利用する 2 つの方法 (動的および静的) を提供します。" + +#: ../../rst/user_guide/playbooks_reuse.rst:57 +msgid "For dynamic re-use, add an ``include_*`` task in the tasks section of a play:" +msgstr "動的再利用には、プレイの tasks セクションに ``include_*`` タスクを追加します。" + +#: ../../rst/user_guide/playbooks_reuse.rst:59 +msgid ":ref:`include_role <include_role_module>`" +msgstr ":ref:`include_role <include_role_module>`" + +#: ../../rst/user_guide/playbooks_reuse.rst:60 +msgid ":ref:`include_tasks <include_tasks_module>`" +msgstr ":ref:`include_tasks <include_tasks_module>`" + +#: ../../rst/user_guide/playbooks_reuse.rst:61 +msgid ":ref:`include_vars <include_vars_module>`" +msgstr ":ref:`include_vars <include_vars_module>`" + +#: ../../rst/user_guide/playbooks_reuse.rst:63 +msgid "For static re-use, add an ``import_*`` task in the tasks section of a play:" +msgstr "静的な再利用の場合は、プレイの tasks セクションに ``import_*`` タスクを追加します。" + +#: ../../rst/user_guide/playbooks_reuse.rst:65 +msgid ":ref:`import_role <import_role_module>`" +msgstr ":ref:`import_role <import_role_module>`" + +#: ../../rst/user_guide/playbooks_reuse.rst:66 +msgid ":ref:`import_tasks <import_tasks_module>`" +msgstr ":ref:`import_tasks <import_tasks_module>`" + +#: ../../rst/user_guide/playbooks_reuse.rst:68 +msgid "Task include and import statements can be used at arbitrary depth." +msgstr "タスクの include 文および import 文は任意の深さで使用できます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:70 +msgid "You can still use the bare :ref:`roles <roles_keyword>` keyword at the play level to incorporate a role in a playbook statically. However, the bare :ref:`include <include_module>` keyword, once used for both task files and playbook-level includes, is now deprecated." +msgstr "プレイレベルで裸の :ref:`roles <roles_keyword>` キーワードを使用して、ロールを静的に Playbook に組み込むことは可能です。しかし、かつてタスクファイルと Playbook レベルのインクルードの両方に使用されていた裸の :ref:`include <include_module>` キーワードは、現在では非推奨となっています。" + +#: ../../rst/user_guide/playbooks_reuse.rst:73 +msgid "Includes: dynamic re-use" +msgstr "インクルード: 動的再利用" + +#: ../../rst/user_guide/playbooks_reuse.rst:75 +msgid "Including roles, tasks, or variables adds them to a playbook dynamically. Ansible processes included files and roles as they come up in a playbook, so included tasks can be affected by the results of earlier tasks within the top-level playbook. Included roles and tasks are similar to handlers - they may or may not run, depending on the results of other tasks in the top-level playbook." +msgstr "ロール、タスク、または変数をインクルードすると、Playbook に動的に追加されます。Ansible は、Playbook に同梱されるインクルードファイルやロールを処理するため、インクルードタスクは、トップレベルの Playbook 内の以前のタスクの結果によって影響を受ける可能性があります。インクルードされるロールやタスクは、ハンドラーと同様、トップレベルの Playbook 内の他のタスクの結果に応じて、実行されたりされなかったりします。" + +#: ../../rst/user_guide/playbooks_reuse.rst:77 +msgid "The primary advantage of using ``include_*`` statements is looping. When a loop is used with an include, the included tasks or role will be executed once for each item in the loop." +msgstr "``include_*`` 文を使用する主な利点はループです。インクルードでループが使用されると、インクルードされたタスクまたはロールがループの各項目に対して 1 回実行されます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:79 +msgid "The filenames for included roles, tasks, and vars are templated before inclusion." +msgstr "含まれるロール、タスク、および変数のファイル名は、包含前にテンプレート化されます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:81 +msgid "You can pass variables into includes. See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence." +msgstr "変数をインクルードに渡すことができます。変数の継承と優先順位の詳細は、「:ref:`ansible_variable_precedence`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse.rst:84 +msgid "Imports: static re-use" +msgstr "インポート: 静的再利用" + +#: ../../rst/user_guide/playbooks_reuse.rst:86 +msgid "Importing roles, tasks, or playbooks adds them to a playbook statically. Ansible pre-processes imported files and roles before it runs any tasks in a playbook, so imported content is never affected by other tasks within the top-level playbook." +msgstr "ロール、タスク、または Playbook をインポートすると、それらが静的に Playbook に追加されます。Ansible は、インポートされたファイルやロールを Playbook 内のタスクを実行する前に前処理するため、インポートされたコンテンツがトップレベルの Playbook 内の他のタスクの影響を受けることはありません。" + +#: ../../rst/user_guide/playbooks_reuse.rst:88 +msgid "The filenames for imported roles and tasks support templating, but the variables must be available when Ansible is pre-processing the imports. This can be done with the ``vars`` keyword or by using ``--extra-vars``." +msgstr "インポートしたロールおよびタスクのファイル名はテンプレートをサポートしますが、Ansible がインポートの事前処理時に変数が利用できるようにする必要があります。これは、``vars`` キーワードまたは ``--extra-vars`` を使用して実行できます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:90 +msgid "You can pass variables to imports. You must pass variables if you want to run an imported file more than once in a playbook. For example:" +msgstr "インポートには変数を渡すことができます。インポートしたファイルを 1 つの Playbook で複数回実行する場合は、変数を渡す必要があります。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_reuse.rst:107 +msgid "See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence." +msgstr "変数の継承および優先順位に関する詳細は、「:ref:`ansible_variable_precedence`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse.rst:112 +msgid "Comparing includes and imports: dynamic and static re-use" +msgstr "インクルードとインポートの比較: 動的再利用および静的再利用" + +#: ../../rst/user_guide/playbooks_reuse.rst:114 +msgid "Each approach to re-using distributed Ansible artifacts has advantages and limitations. You may choose dynamic re-use for some playbooks and static re-use for others. Although you can use both dynamic and static re-use in a single playbook, it is best to select one approach per playbook. Mixing static and dynamic re-use can introduce difficult-to-diagnose bugs into your playbooks. This table summarizes the main differences so you can choose the best approach for each playbook you create." +msgstr "分散した Ansible のアーティファクトを再利用する方法には、それぞれ利点と制限があります。一部の Playbook では動的再利用を行い、他の Playbook では静的再利用を行うことができます。1 つの Playbook で動的再利用と静的再利用の両方を使用することもできますが、Playbook ごとに 1 つのアプローチを選択するのが最善です。静的再利用と動的再利用を混在させると、診断が困難なバグが Playbook に発生する可能性があります。この表で主な違いをまとめています。作成する Playbook ごとに最適な方法を選択してください。" + +#: ../../rst/user_guide/playbooks_reuse.rst:120 +msgid "Include_*" +msgstr "Include_*" + +#: ../../rst/user_guide/playbooks_reuse.rst:120 +msgid "Import_*" +msgstr "Import_*" + +#: ../../rst/user_guide/playbooks_reuse.rst:122 +msgid "Type of re-use" +msgstr "再利用の種類" + +#: ../../rst/user_guide/playbooks_reuse.rst:122 +msgid "Dynamic" +msgstr "動的" + +#: ../../rst/user_guide/playbooks_reuse.rst:122 +msgid "Static" +msgstr "静的" + +#: ../../rst/user_guide/playbooks_reuse.rst:124 +msgid "When processed" +msgstr "処理時" + +#: ../../rst/user_guide/playbooks_reuse.rst:124 +msgid "At runtime, when encountered" +msgstr "ランタイム時に (発生した場合)" + +#: ../../rst/user_guide/playbooks_reuse.rst:124 +msgid "Pre-processed during playbook parsing" +msgstr "Playbook の解析中に事前処理" + +#: ../../rst/user_guide/playbooks_reuse.rst:126 +msgid "Task or play" +msgstr "タスクまたはプレイ" + +#: ../../rst/user_guide/playbooks_reuse.rst:126 +msgid "All includes are tasks" +msgstr "インクルードはすべてタスク" + +#: ../../rst/user_guide/playbooks_reuse.rst:126 +msgid "``import_playbook`` cannot be a task" +msgstr "``import_playbook`` タスクにすることはできない" + +#: ../../rst/user_guide/playbooks_reuse.rst:128 +msgid "Task options" +msgstr "タスクオプション" + +#: ../../rst/user_guide/playbooks_reuse.rst:128 +msgid "Apply only to include task itself" +msgstr "タスク自体を含める場合にのみ適用" + +#: ../../rst/user_guide/playbooks_reuse.rst:128 +msgid "Apply to all child tasks in import" +msgstr "インポート中のすべての子タスクに適用" + +#: ../../rst/user_guide/playbooks_reuse.rst:130 +msgid "Calling from loops" +msgstr "ループからの呼び出し" + +#: ../../rst/user_guide/playbooks_reuse.rst:130 +msgid "Executed once for each loop item" +msgstr "各ループ項目に対して 1 回実行" + +#: ../../rst/user_guide/playbooks_reuse.rst:130 +msgid "Cannot be used in a loop" +msgstr "ループでは使用できない" + +#: ../../rst/user_guide/playbooks_reuse.rst:132 +msgid "Using ``--list-tags``" +msgstr "``--list-tags`` の使用" + +#: ../../rst/user_guide/playbooks_reuse.rst:132 +msgid "Tags within includes not listed" +msgstr "掲載されていないインクルード内のタグ" + +#: ../../rst/user_guide/playbooks_reuse.rst:132 +msgid "All tags appear with ``--list-tags``" +msgstr "すべてのタグが ``--list-tags`` で表示" + +#: ../../rst/user_guide/playbooks_reuse.rst:134 +msgid "Using ``--list-tasks``" +msgstr "``--list-tasks`` の使用" + +#: ../../rst/user_guide/playbooks_reuse.rst:134 +msgid "Tasks within includes not listed" +msgstr "リストにないインクルード内のタスク" + +#: ../../rst/user_guide/playbooks_reuse.rst:134 +msgid "All tasks appear with ``--list-tasks``" +msgstr "すべてのタスクが ``--list-tasks`` で表示" + +#: ../../rst/user_guide/playbooks_reuse.rst:136 +msgid "Cannot trigger handlers within includes" +msgstr "インクルード内でハンドラーをトリガーできない" + +#: ../../rst/user_guide/playbooks_reuse.rst:136 +msgid "Can trigger individual imported handlers" +msgstr "インポートした個別のハンドラーをトリガーできる" + +#: ../../rst/user_guide/playbooks_reuse.rst:138 +msgid "Using ``--start-at-task``" +msgstr "``--start-at-task`` の使用" + +#: ../../rst/user_guide/playbooks_reuse.rst:138 +msgid "Cannot start at tasks within includes" +msgstr "インクルード内のタスクで開始できない" + +#: ../../rst/user_guide/playbooks_reuse.rst:138 +msgid "Can start at imported tasks" +msgstr "インポートされたタスクから始められる" + +#: ../../rst/user_guide/playbooks_reuse.rst:140 +msgid "Using inventory variables" +msgstr "インベントリー変数の使用" + +#: ../../rst/user_guide/playbooks_reuse.rst:140 +msgid "Can ``include_*: {{ inventory_var }}``" +msgstr "``include_*: {{ inventory_var }}`` が使用できる" + +#: ../../rst/user_guide/playbooks_reuse.rst:140 +msgid "Cannot ``import_*: {{ inventory_var }}``" +msgstr "``import_*: {{ inventory_var }}`` が使用できない" + +#: ../../rst/user_guide/playbooks_reuse.rst:142 +msgid "With playbooks" +msgstr "Playbook の使用" + +#: ../../rst/user_guide/playbooks_reuse.rst:142 +msgid "No ``include_playbook``" +msgstr "``include_playbook`` なし" + +#: ../../rst/user_guide/playbooks_reuse.rst:142 +msgid "Can import full playbooks" +msgstr "完全な Playbook をインポートできる" + +#: ../../rst/user_guide/playbooks_reuse.rst:144 +msgid "With variables files" +msgstr "変数ファイルの使用" + +#: ../../rst/user_guide/playbooks_reuse.rst:144 +msgid "Can include variables files" +msgstr "変数ファイルを含めることができる" + +#: ../../rst/user_guide/playbooks_reuse.rst:144 +msgid "Use ``vars_files:`` to import variables" +msgstr "``vars_files:`` を使用して変数をインポート" + +#: ../../rst/user_guide/playbooks_reuse.rst:150 +msgid "There are also big differences in resource consumption and performance, imports are quite lean and fast, while includes require a lot of management and accounting." +msgstr "また、リソースの消費やパフォーマンスに大きな違いがあり、インポートは非常に柔軟で高速ですが、インクルードには多くの管理と会計が必要になります。" + +#: ../../rst/user_guide/playbooks_reuse.rst:154 +msgid "Re-using tasks as handlers" +msgstr "タスクをハンドラーとして再利用" + +#: ../../rst/user_guide/playbooks_reuse.rst:156 +msgid "You can also use includes and imports in the :ref:`handlers` section of a playbook. For instance, if you want to define how to restart Apache, you only have to do that once for all of your playbooks. You might make a ``restarts.yml`` file that looks like:" +msgstr "Playbook の :ref:`handlers` セクションでインクルードおよびインポートを使用することもできます。たとえば、Apache の再起動方法を定義する場合は、すべての Playbook に対して一度だけ設定する必要があります。``restarts.yml`` ファイルを以下のように行うことができます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:171 +msgid "You can trigger handlers from either an import or an include, but the procedure is different for each method of re-use. If you include the file, you must notify the include itself, which triggers all the tasks in ``restarts.yml``. If you import the file, you must notify the individual task(s) within ``restarts.yml``. You can mix direct tasks and handlers with included or imported tasks and handlers." +msgstr "ハンドラーはインポートとインクルードのどちらからでも起動できますが、その手順は再利用の方法ごとに異なります。ファイルをインクルードする場合は、インクルード自体を通知する必要があり、これにより ``restarts.yml`` のすべてのタスクが発生します。ファイルをインポートする場合は、``restarts.yml`` 内の個々のタスクを通知する必要があります。直接的なタスクやハンドラーと、インクルードまたはインポートされたタスクやハンドラーを混在させることができます。" + +#: ../../rst/user_guide/playbooks_reuse.rst:174 +msgid "Triggering included (dynamic) handlers" +msgstr "インクルード (動的) ハンドラーのトリガー" + +#: ../../rst/user_guide/playbooks_reuse.rst:176 +msgid "Includes are executed at run-time, so the name of the include exists during play execution, but the included tasks do not exist until the include itself is triggered. To use the ``Restart apache`` task with dynamic re-use, refer to the name of the include itself. This approach triggers all tasks in the included file as handlers. For example, with the task file shown above:" +msgstr "インクルードはランタイムに実行されるため、インクルードの名前はプレイの実行中に存在しますが、インクルードされたタスクはインクルード自体がトリガーされるまで存在しません。``Restart apache`` タスクを動的再利用で使用するには、インクルード自体の名前を参照します。この方法では、インクルードファイル内のすべてのタスクがハンドラーとしてトリガーされます。たとえば、上に示したタスクファイルでは、以下のようになります。" + +#: ../../rst/user_guide/playbooks_reuse.rst:190 +msgid "Triggering imported (static) handlers" +msgstr "インポートされた (静的) ハンドラーのトリガー" + +#: ../../rst/user_guide/playbooks_reuse.rst:192 +msgid "Imports are processed before the play begins, so the name of the import no longer exists during play execution, but the names of the individual imported tasks do exist. To use the ``Restart apache`` task with static re-use, refer to the name of each task or tasks within the imported file. For example, with the task file shown above:" +msgstr "インポートは再生開始前に処理されるため、インポートの名前は再生実行中には存在しませんが、インポートされた各タスクの名前は存在します。``Restart apache`` タスクを静的に再利用して使用するには、インポートされたファイル内の各タスクの名前を参照する必要があります。たとえば、上述のタスクファイルであれば、以下のようになります。" + +#: ../../rst/user_guide/playbooks_reuse.rst:209 +msgid ":ref:`utilities_modules`" +msgstr ":ref:`utilities_modules`" + +#: ../../rst/user_guide/playbooks_reuse.rst:210 +msgid "Documentation of the ``include*`` and ``import*`` modules discussed here." +msgstr "ここで説明する ``include*`` モジュールおよび ``import*`` モジュールに関するドキュメント" + +#: ../../rst/user_guide/playbooks_reuse.rst:212 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:16 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:593 +#: ../../rst/user_guide/playbooks_roles.rst:16 +msgid "Review the basic Playbook language features" +msgstr "基本的な Playbook 言語機能の確認" + +#: ../../rst/user_guide/playbooks_reuse.rst:214 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:20 +msgid "All about variables in playbooks" +msgstr "Playbook の変数の詳細のすべて" + +#: ../../rst/user_guide/playbooks_reuse.rst:216 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:22 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:599 +msgid "Conditionals in playbooks" +msgstr "Playbook の条件" + +#: ../../rst/user_guide/playbooks_reuse.rst:218 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:24 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:601 +msgid "Loops in playbooks" +msgstr "Playbook のループ" + +#: ../../rst/user_guide/playbooks_reuse.rst:221 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:588 +#: ../../rst/user_guide/playbooks_roles.rst:13 +msgid ":ref:`ansible_galaxy`" +msgstr ":ref:`ansible_galaxy`" + +#: ../../rst/user_guide/playbooks_reuse.rst:222 +#: ../../rst/user_guide/playbooks_roles.rst:14 +msgid "How to share roles on galaxy, role management" +msgstr "Galaxy (ロール管理) におけるロールの共有方法" + +#: ../../rst/user_guide/playbooks_reuse.rst:223 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:29 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:608 +msgid "`GitHub Ansible examples <https://github.com/ansible/ansible-examples>`_" +msgstr "`GitHub Ansible の例 <https://github.com/ansible/ansible-examples>`_" + +#: ../../rst/user_guide/playbooks_reuse.rst:224 +#: ../../rst/user_guide/playbooks_reuse_includes.rst:30 +#: ../../rst/user_guide/playbooks_reuse_roles.rst:609 +msgid "Complete playbook files from the GitHub project source" +msgstr "Github プロジェクトソースの完全な Playbook ファイル" + +#: ../../rst/user_guide/playbooks_reuse_includes.rst:6 +msgid "Including and importing" +msgstr "インクルードおよびインポート" + +#: ../../rst/user_guide/playbooks_reuse_includes.rst:8 +msgid "The content on this page has been moved to :ref:`playbooks_reuse`." +msgstr "このページのコンテンツは :ref:`playbooks_reuse` に移動しました。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:7 +msgid "Roles let you automatically load related vars, files, tasks, handlers, and other Ansible artifacts based on a known file structure. After you group your content in roles, you can easily reuse them and share them with other users." +msgstr "ロールを使用すると、既知のファイル構造に基づいて、関連の変数、ファイル、タスク、ハンドラー、およびその他の Ansible アーティファクトを自動的に読み込むことができます。ロール内のコンテンツをグループ化した後、簡単に再利用でき、他のユーザーと共有できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:13 +msgid "Role directory structure" +msgstr "ロールのディレクトリー構造" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:15 +msgid "An Ansible role has a defined directory structure with eight main standard directories. You must include at least one of these directories in each role. You can omit any directories the role does not use. For example:" +msgstr "Ansible ロールには、8 つの主要な標準ディレクトリーを持つ定義されたディレクトリー構造があります。各ロールには、ディレクトリーを少なくとも 1 つ含める必要があります。ロールが使用されないディレクトリーは除外できます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:26 +msgid "By default Ansible will look in each directory within a role for a ``main.yml`` file for relevant content (also ``main.yaml`` and ``main``):" +msgstr "デフォルトでは、Ansible はロール内の各ディレクトリーで、関連するコンテンツ (``main.yaml`` および ``main``) について ``main.yml`` ファイルを検索します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:28 +msgid "``tasks/main.yml`` - the main list of tasks that the role executes." +msgstr "``tasks/main.yml`` - ロールが実行するタスクの主なリスト。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:29 +msgid "``handlers/main.yml`` - handlers, which may be used within or outside this role." +msgstr "``handlers/main.yml`` - このロール内外で使用できるハンドラー。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:30 +msgid "``library/my_module.py`` - modules, which may be used within this role (see :ref:`embedding_modules_and_plugins_in_roles` for more information)." +msgstr "``library/my_module.py`` - このロール内で使用できるモジュール (詳細は「:ref:`embedding_modules_and_plugins_in_roles`」を参照)。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:31 +msgid "``defaults/main.yml`` - default variables for the role (see :ref:`playbooks_variables` for more information). These variables have the lowest priority of any variables available, and can be easily overridden by any other variable, including inventory variables." +msgstr "``defaults/main.yml`` - ロールのデフォルト変数 (詳細は「:ref:`playbooks_variables`」を参照)。これらの変数には、利用可能な変数の中で一番低い優先順位があり、インベントリー変数など、他の変数で簡単に上書きできます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:32 +msgid "``vars/main.yml`` - other variables for the role (see :ref:`playbooks_variables` for more information)." +msgstr "``vars/main.yml`` - ロールの他の変数 (詳細は :ref:`playbooks_variables` を参照)。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:33 +msgid "``files/main.yml`` - files that the role deploys." +msgstr "``files/main.yml`` - ロールがデプロイするファイル。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:34 +msgid "``templates/main.yml`` - templates that the role deploys." +msgstr "``templates/main.yml`` - ロールがデプロイするテンプレート。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:35 +msgid "``meta/main.yml`` - metadata for the role, including role dependencies." +msgstr "``meta/main.yml`` - ロールの依存関係を含むロールのメタデータ。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:37 +msgid "You can add other YAML files in some directories. For example, you can place platform-specific tasks in separate files and refer to them in the ``tasks/main.yml`` file:" +msgstr "他の YAML ファイルを一部のディレクトリーに追加できます。たとえば、プラットフォーム固有のタスクを別々のファイルに配置し、それらを ``tasks/main.yml`` ファイルで参照できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:62 +msgid "Roles may also include modules and other plugin types in a directory called ``library``. For more information, please refer to :ref:`embedding_modules_and_plugins_in_roles` below." +msgstr "ロールには、``library`` と呼ばれるディレクトリーにモジュールおよびその他のプラグインタイプが含まれる場合があります。詳細は、以下の「:ref:`embedding_modules_and_plugins_in_roles`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:67 +msgid "Storing and finding roles" +msgstr "ロールの保存および検索" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:69 +msgid "By default, Ansible looks for roles in the following locations:" +msgstr "デフォルトでは、Ansible は以下の場所でロールを検索します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:71 +msgid "in collections, if you are using them" +msgstr "コレクションでそれらを使用している場合" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:72 +msgid "in a directory called ``roles/``, relative to the playbook file" +msgstr "``roles/`` という名前のディレクトリー (Playbook ファイルへの相対パス) で" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:73 +msgid "in the configured :ref:`roles_path <DEFAULT_ROLES_PATH>`. The default search path is ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``." +msgstr "設定された :ref:`roles_path <DEFAULT_ROLES_PATH>` では、デフォルトの検索パスは ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles`` です。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:74 +msgid "in the directory where the playbook file is located" +msgstr "Playbook ファイルが配置されているディレクトリーで" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:76 +msgid "If you store your roles in a different location, set the :ref:`roles_path <DEFAULT_ROLES_PATH>` configuration option so Ansible can find your roles. Checking shared roles into a single location makes them easier to use in multiple playbooks. See :ref:`intro_configuration` for details about managing settings in ansible.cfg." +msgstr "ロールを別の場所に保存する場合は、Ansible がロールを見つけることができるように、:ref:`roles_path <DEFAULT_ROLES_PATH>` 設定オプションを設定します。共有ロールを 1 つの場所にチェックインすることで、複数の Playbook で簡単に使用できます。ansible.cfg の設定に関する詳細は、「:ref:`intro_configuration`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:78 +msgid "Alternatively, you can call a role with a fully qualified path:" +msgstr "または、完全修飾パスでロールを呼び出すことができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:88 +msgid "Using roles" +msgstr "ロールの使用" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:90 +msgid "You can use roles in three ways:" +msgstr "以下の 3 つの方法でロールを使用できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:92 +msgid "at the play level with the ``roles`` option: This is the classic way of using roles in a play." +msgstr "``roles`` オプションを使用してプレイレベルで: プレイでロールを使用する従来の方式です。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:93 +msgid "at the tasks level with ``include_role``: You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``." +msgstr "``include_role`` を使用してタスクレベルで: ``include_role`` を使用してプレイの ``tasks`` セクションのどこからでもロールを動的に再利用できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:94 +msgid "at the tasks level with ``import_role``: You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``." +msgstr "``import_role`` を使用してタスクレベルで: ``import_role`` を使用してプレイの ``tasks`` セクションのどこからでもロールを静的に再利用できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:99 +msgid "Using roles at the play level" +msgstr "プレイレベルでのロールの使用" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:101 +msgid "The classic (original) way to use roles is with the ``roles`` option for a given play:" +msgstr "ロールを使用する従来の (元の) 方法は、特定のプレイの ``roles`` オプションを使用して行います。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:111 +msgid "When you use the ``roles`` option at the play level, for each role 'x':" +msgstr "プレイレベルで ``roles`` オプションを使用する場合は、各ロール「x」に対して以下のように設定します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:113 +msgid "If roles/x/tasks/main.yml exists, Ansible adds the tasks in that file to the play." +msgstr "roles/x/tasks/main.yml が存在する場合、Ansible はそのファイルのタスクをプレイに追加します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:114 +msgid "If roles/x/handlers/main.yml exists, Ansible adds the handlers in that file to the play." +msgstr "roles/x/handlers/main.yml が存在する場合、Ansible はそのファイルのハンドラーをプレイに追加します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:115 +msgid "If roles/x/vars/main.yml exists, Ansible adds the variables in that file to the play." +msgstr "roles/x/vars/main.yml が存在する場合、Ansible はそのファイルの変数をプレイに追加します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:116 +msgid "If roles/x/defaults/main.yml exists, Ansible adds the variables in that file to the play." +msgstr "roles/x/defaults/main.yml が存在する場合、Ansible はそのファイルの変数をプレイに追加します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:117 +msgid "If roles/x/meta/main.yml exists, Ansible adds any role dependencies in that file to the list of roles." +msgstr "roles/x/meta/main.yml が存在する場合、Ansible はそのファイル内のすべてのロールの依存関係をロールのリストに追加します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:118 +msgid "Any copy, script, template or include tasks (in the role) can reference files in roles/x/{files,templates,tasks}/ (dir depends on task) without having to path them relatively or absolutely." +msgstr "コピー、スクリプト、テンプレート、またはインクルードタスク (ロール内) は、相対パスや絶対パスを必要とせずに roles/x/{files,templates,tasks}/ (ディレクトリーはタスクに依存します) のファイルを参照できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:120 +msgid "When you use the ``roles`` option at the play level, Ansible treats the roles as static imports and processes them during playbook parsing. Ansible executes each play in this order:" +msgstr "プレイレベルで ``roles`` オプションを使用すると、Ansible はロールを静的インポートとして処理し、Playbook の解析時に処理します。Ansible は以下の順序でそれぞれのプレイを実行します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:122 +msgid "Any ``pre_tasks`` defined in the play." +msgstr "プレイに定義されているすべての ``pre_tasks``。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:123 +msgid "Any handlers triggered by pre_tasks." +msgstr "ハンドラーは、pre_tasks により誘発されます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:124 +msgid "Each role listed in ``roles:``, in the order listed. Any role dependencies defined in the role's ``meta/main.yml`` run first, subject to tag filtering and conditionals. See :ref:`role_dependencies` for more details." +msgstr "``roles:`` に一覧表示される順序で、各ロールがリストされます。ロールの ``meta/main.yml`` で定義されたロール依存関係は、タグのフィルタリングおよび条件に基づいて最初に実行されます。詳細は、「:ref:`role_dependencies`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:125 +msgid "Any ``tasks`` defined in the play." +msgstr "プレイに定義されているすべての ``tasks``。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:126 +msgid "Any handlers triggered by the roles or tasks." +msgstr "ロールやタスクによってトリガーされるすべてのハンドラー。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:127 +msgid "Any ``post_tasks`` defined in the play." +msgstr "プレイに定義されているすべての ``post_tasks``。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:128 +msgid "Any handlers triggered by post_tasks." +msgstr "ハンドラーは、post_tasks により誘発されます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:131 +msgid "If using tags with tasks in a role, be sure to also tag your pre_tasks, post_tasks, and role dependencies and pass those along as well, especially if the pre/post tasks and role dependencies are used for monitoring outage window control or load balancing. See :ref:`tags` for details on adding and using tags." +msgstr "ロール内のタスクにタグを使用する場合は、pre_tasks、post_tasks、およびロールの依存関係にもタグを付けて、それらも渡すようにしてください。特に、事前または事後のタスクおよびロールの依存関係が、停止時のウィンドウ制御や負荷分散の監視に使用されている場合は、そのようにしてください。タグの追加と使用の詳細は、「:ref:`tags`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:133 +msgid "You can pass other keywords to the ``roles`` option:" +msgstr "他のキーワードを ``roles`` オプションに渡すことができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:152 +msgid "When you add a tag to the ``role`` option, Ansible applies the tag to ALL tasks within the role." +msgstr "タグを ``role`` オプションに追加すると、Ansible はタグをロール内のすべてのタスクに適用します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:154 +msgid "When using ``vars:`` within the ``roles:`` section of a playbook, the variables are added to the play variables, making them available to all tasks within the play before and after the role. This behavior can be changed by :ref:`DEFAULT_PRIVATE_ROLE_VARS`." +msgstr "Playbook の ``roles:`` セクションで ``vars:`` を使用すると、変数がプレイ変数に追加され、ロールの前後にプレイ内のすべてのタスクで利用できるようになります。この動作は :ref:`DEFAULT_PRIVATE_ROLE_VARS` で変更できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:157 +msgid "Including roles: dynamic reuse" +msgstr "ロールの追加: 動的な再利用" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:159 +msgid "You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``. While roles added in a ``roles`` section run before any other tasks in a play, included roles run in the order they are defined. If there are other tasks before an ``include_role`` task, the other tasks will run first." +msgstr "``include_role`` を使用すると、プレイの ``tasks`` セクション内の任意の場所でロールを動的に再利用することができます。``roles`` セクションで追加されたロールはプレイ内の他のタスクよりも先に実行されますが、含まれるロールは定義された順に実行されます。``include_role`` のタスクの前に他のタスクがある場合は、他のタスクが先に実行します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:161 +msgid "To include a role:" +msgstr "ロールを指定するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:180 +msgid "You can pass other keywords, including variables and tags, when including roles:" +msgstr "ロールを含める際には、変数やタグなど、他のキーワードを渡すことができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:196 +msgid "When you add a :ref:`tag <tags>` to an ``include_role`` task, Ansible applies the tag `only` to the include itself. This means you can pass ``--tags`` to run only selected tasks from the role, if those tasks themselves have the same tag as the include statement. See :ref:`selective_reuse` for details." +msgstr "``include_role`` タスクに :ref:`tag <tags>` を追加すると、Ansible はインクルード自体に `only` というタグを適用します。つまり、``--tags`` を渡して、ロールから選択されたタスクのみを実行することができます。ただし、それらのタスク自体が include 文と同じタグを持っている場合に限ります。詳細は、「:ref:`selective_reuse`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:198 +msgid "You can conditionally include a role:" +msgstr "ロールを条件付きで含めることができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:211 +msgid "Importing roles: static reuse" +msgstr "ロールのインポート: 静的再利用" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:213 +msgid "You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``. The behavior is the same as using the ``roles`` keyword. For example:" +msgstr "``import_role`` を使用してプレイの ``tasks`` セクションの任意の場所に、ロールを静的に再利用できます。動作は、``roles`` キーワードの使用と同じです。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:232 +msgid "You can pass other keywords, including variables and tags, when importing roles:" +msgstr "ロールをインポートする際には、変数やタグなど、他のキーワードを渡すことができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:247 +msgid "When you add a tag to an ``import_role`` statement, Ansible applies the tag to `all` tasks within the role. See :ref:`tag_inheritance` for details." +msgstr "タグを ``import_role`` 文に追加すると、Ansible はタグをロール内の `all` タスクに適用します。詳細は、「:ref:`tag_inheritance`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:250 +msgid "Role argument validation" +msgstr "ロール引数を検証する" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:252 +msgid "Beginning with version 2.11, you may choose to enable role argument validation based on an argument specification. This specification is defined in the ``meta/argument_specs.yml`` file (or with the ``.yaml`` file extension). When this argument specification is defined, a new task is inserted at the beginning of role execution that will validate the parameters supplied for the role against the specification. If the parameters fail validation, the role will fail execution." +msgstr "バージョン 2.11 以降では、引数の仕様に基づいてロールの引数検証を有効にすることができます。この仕様は、``meta/argument_specs.yml`` ファイル (または ``.yaml`` ファイル拡張子) で定義されます。この引数仕様が定義されると、ロール実行の最初に新しいタスクが挿入され、仕様に対して、ロールに指定したパラメーターを検証します。パラメーターの検証に失敗した場合は、ロールの実行が失敗します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:260 +msgid "Ansible also supports role specifications defined in the role ``meta/main.yml`` file, as well. However, any role that defines the specs within this file will not work on versions below 2.11. For this reason, we recommend using the ``meta/argument_specs.yml`` file to maintain backward compatibility." +msgstr "Ansible は、ロールの ``meta/main.yml`` ファイルで定義されるロールの仕様もサポートしますが、このファイル内の仕様を定義するロールは 2.11 未満のバージョンでは動作しません。そのため、``meta/argument_specs.yml`` ファイルを使用して後方互換性を維持することが推奨されます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:266 +msgid "When role argument validation is used on a role that has defined :ref:`dependencies <role_dependencies>`, then validation on those dependencies will run before the dependent role, even if argument validation fails for the dependent role." +msgstr ":ref:`dependencies <role_dependencies>` を定義しているロールにロールの引数検証が使用されている場合は、依存するロールの引数検証が失敗しても、それらの依存関係の検証は依存するロールの前に実行します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:271 +msgid "Specification format" +msgstr "仕様の形式" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:273 +msgid "The role argument specification must be defined in a top-level ``argument_specs`` block within the role ``meta/argument_specs.yml`` file. All fields are lower-case." +msgstr "ロール引数の指定は、ロール ``meta/argument_specs.yml`` ファイルの上位の ``argument_specs`` ブロックで定義する必要があります。すべてのフィールドは小文字になります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "entry-point-name" +msgstr "entry-point-name" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:278 +msgid "The name of the role entry point." +msgstr "ロールエントリーポイントの名前。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:279 +msgid "This should be ``main`` in the case of an unspecified entry point." +msgstr "これは、エントリーポイントが未指定の場合は ``main`` である必要があります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:280 +msgid "This will be the base name of the tasks file to execute, with no ``.yml`` or ``.yaml`` file extension." +msgstr "これは、ファイル拡張子 ``.yml`` または ``.yaml`` のない、実行するタスクファイルのベース名です。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "short_description" +msgstr "short_description" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:284 +msgid "A short, one-line description of the entry point." +msgstr "エントリーポイントの 1 行の短い説明。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:285 +msgid "The ``short_description`` is displayed by ``ansible-doc -t role -l``." +msgstr "``short_description`` は、``ansible-doc -t role -l`` に表示されます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "description" +msgstr "description" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:289 +msgid "A longer description that may contain multiple lines." +msgstr "複数の行が含まれる可能性のある長い説明。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "author" +msgstr "author" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:293 +msgid "Name of the entry point authors." +msgstr "エントリーポイント作成者の名前。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:294 +msgid "Use a multi-line list if there is more than one author." +msgstr "作成者が複数になる場合は、複数行のリストを使用します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "options" +msgstr "options" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:298 +msgid "Options are often called \"parameters\" or \"arguments\". This section defines those options." +msgstr "オプションは、しばしば「パラメーター」や「引数」と呼ばれます。このセクションでは、それらのオプションを定義します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:299 +msgid "For each role option (argument), you may include:" +msgstr "各ロールオプション (引数) に以下を含めることができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "option-name" +msgstr "option-name" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:303 +msgid "The name of the option/argument." +msgstr "オプション/引数の名前。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:307 +msgid "Detailed explanation of what this option does. It should be written in full sentences." +msgstr "このオプションの機能の詳細な説明。これは、完全な文章で記述する必要があります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "type" +msgstr "type" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:311 +msgid "The data type of the option. See :ref:`Argument spec <argument_spec>` for allowed values for ``type``. Default is ``str``." +msgstr "オプションのデータタイプ。``type`` に設定可能な値については、:ref:`引数の仕様 <argument_spec>` を参照してください。デフォルトは ``str`` です。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:312 +msgid "If an option is of type ``list``, ``elements`` should be specified." +msgstr "オプションが ``list`` タイプの場合は、``elements`` を指定する必要があります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "required" +msgstr "必須" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:316 +msgid "Only needed if ``true``." +msgstr "``true`` の場合にのみ必要です。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:317 +msgid "If missing, the option is not required." +msgstr "見つからない場合、そのオプションは必要ありません。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "default" +msgstr "default" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:321 +msgid "If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing)." +msgstr "``required`` が false もしくは指定されていない場合は、``default`` を指定できます (見つからない場合は「null」と見なされます)。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:322 +msgid "Ensure that the default value in the docs matches the default value in the code. The actual default for the role variable will always come from ``defaults/main.yml``." +msgstr "ドキュメントのデフォルト値が、コードのデフォルト値と一致していることを確認します。ロール変数の実際のデフォルトは常に ``defaults/main.yml`` から取得されます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:324 +msgid "The default field must not be listed as part of the description, unless it requires additional information or conditions." +msgstr "追加の情報や条件が必要な場合を除き、デフォルトのフィールドは、説明の一部として記載しないでください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:325 +msgid "If the option is a boolean value, you can use any of the boolean values recognized by Ansible: (such as true/false or yes/no). Choose the one that reads better in the context of the option." +msgstr "オプションがブール値の場合は、Ansible が認識する任意のブール値 (true/false、yes/no など) を使用できます。オプションのコンテキストで読み取りが適切であればこれを選択します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "choices" +msgstr "choices" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:330 +msgid "List of option values." +msgstr "オプション値のリスト。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:331 +msgid "Should be absent if empty." +msgstr "空欄の場合は指定なしになります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst +msgid "elements" +msgstr "elements" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:335 +msgid "Specifies the data type for list elements when type is ``list``." +msgstr "タイプが ``list`` の場合に、リスト要素のデータ型を指定します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:339 +msgid "If this option takes a dict or list of dicts, you can define the structure here." +msgstr "このオプションがディクショナリーまたはディクショナリーのリストを取る場合は、ここで構造を定義できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:342 +msgid "Sample specification" +msgstr "サンプル仕様" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:377 +msgid "Running a role multiple times in one play" +msgstr "1 つのプレイでロールを複数回実行する" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:379 +msgid "Ansible only executes each role once in a play, even if you define it multiple times, unless the parameters defined on the role are different for each definition. For example, Ansible only runs the role ``foo`` once in a play like this:" +msgstr "Ansible は、ロールに定義されているパラメーターが定義ごとに異なる場合を除き、各ロールを複数回定義してもプレイでは 1 回しか実行しません。たとえば、Ansible は次のようなプレイで ``foo`` というロールを 1 回だけ実行します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:390 +msgid "You have two options to force Ansible to run a role more than once." +msgstr "Ansible が複数のロールを強制的に実行するオプションは 2 つあります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:393 +msgid "Passing different parameters" +msgstr "異なるパラメーターを渡す" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:395 +msgid "If you pass different parameters in each role definition, Ansible runs the role more than once. Providing different variable values is not the same as passing different role parameters. You must use the ``roles`` keyword for this behavior, since ``import_role`` and ``include_role`` do not accept role parameters." +msgstr "各ロール定義で異なるパラメーターを渡すと、Ansible はそのロールを複数回実行します。異なる変数値を提供することは、異なるロールパラメーターを渡すこととは異なります。``import_role`` および ``include_role`` はロールパラメーターを受け入れないため、この動作には ``roles`` キーワードを使用する必要があります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:397 +msgid "This play runs the ``foo`` role twice:" +msgstr "このプレイでは、``foo`` ロールが 2 回実行されます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:407 +msgid "This syntax also runs the ``foo`` role twice;" +msgstr "この構文は、``foo`` ロールを 2 回実行します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:419 +msgid "In these examples, Ansible runs ``foo`` twice because each role definition has different parameters." +msgstr "これらの例では、各ロール定義のパラメーターが異なるため、Ansible は ``foo`` を 2 回実行します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:422 +msgid "Using ``allow_duplicates: true``" +msgstr "``allow_duplicates: true`` の使用" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:424 +msgid "Add ``allow_duplicates: true`` to the ``meta/main.yml`` file for the role:" +msgstr "ロールの ``meta/main.yml`` ファイルに ``allow_duplicates: true`` を追加します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:439 +msgid "In this example, Ansible runs ``foo`` twice because we have explicitly enabled it to do so." +msgstr "この例では、Ansible が ``foo`` を2回実行していますが、これは明示的に実行できるようにしたためです。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:444 +msgid "Using role dependencies" +msgstr "ロール依存関係の使用" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:446 +msgid "Role dependencies let you automatically pull in other roles when using a role." +msgstr "ロールの依存関係により、ロールを使用する際に他のロールを自動的にプルできます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:448 +msgid "Role dependencies are prerequisites, not true dependencies. The roles do not have a parent/child relationship. Ansible loads all listed roles, runs the roles listed under ``dependencies`` first, then runs the role that lists them. The play object is the parent of all roles, including roles called by a ``dependencies`` list." +msgstr "ロールの依存関係は前提条件であり、真の依存関係ではありません。また、ロールは親子関係を持ちません。Ansible はリストアップされたすべてのロールを読み込み、``dependencies`` にリストアップされたロールを最初に実行し、次にそれらをリストアップしたロールを実行します。play オブジェクトは、``dependencies`` のリストで呼び出されるロールを含め、すべてのロールの親です。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:450 +msgid "Role dependencies are stored in the ``meta/main.yml`` file within the role directory. This file should contain a list of roles and parameters to insert before the specified role. For example:" +msgstr "ロールの依存関係は、ロールディレクトリー内の ``meta/main.yml`` ファイルに保存されます。このファイルには、指定されたロールの前に挿入するロールとパラメーターの一覧を含める必要があります。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:468 +msgid "Ansible always executes roles listed in ``dependencies`` before the role that lists them. Ansible executes this pattern recursively when you use the ``roles`` keyword. For example, if you list role ``foo`` under ``roles:``, role ``foo`` lists role ``bar`` under ``dependencies`` in its meta/main.yml file, and role ``bar`` lists role ``baz`` under ``dependencies`` in its meta/main.yml, Ansible executes ``baz``, then ``bar``, then ``foo``." +msgstr "Ansible は、``dependencies`` に記載されているロールを、それを記載しているロールの前に常に実行します。``roles`` キーワードを使用すると、Ansible はこのパターンを再帰的に実行します。たとえば、ロール ``foo`` を ``roles:`` の下にリストし、ロール ``foo`` が meta/main.yml ファイルの ``dependencies`` の下にロール ``bar`` をリストし、ロール ``bar`` が meta/main.yml の ``dependencies`` の下にロール ``baz`` をリストしている場合、Ansibleは ``baz``、``bar``、``foo`` の順に実行します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:471 +msgid "Running role dependencies multiple times in one play" +msgstr "1 つのプレイでロールの依存関係を複数回実行する" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:473 +msgid "Ansible treats duplicate role dependencies like duplicate roles listed under ``roles:``: Ansible only executes role dependencies once, even if defined multiple times, unless the parameters, tags, or when clause defined on the role are different for each definition. If two roles in a play both list a third role as a dependency, Ansible only runs that role dependency once, unless you pass different parameters, tags, when clause, or use ``allow_duplicates: true`` in the role you want to run multiple times. See :ref:`Galaxy role dependencies <galaxy_dependencies>` for more details." +msgstr "Ansible は、``roles:`` に記載されている重複したロールのように、重複したロールの依存関係を扱います。Ansible は、ロールに定義されたパラメーター、タグ、または when 句が定義ごとに異なる場合を除き、複数回定義されていてもロールの依存関係を 1 回のみ実行します。プレイ内の 2 つのロールが両方とも依存関係として 3 番目のロールをリストしている場合、Ansible は、複数回実行するロールで異なるパラメーター、タグ、when 句を渡すか、``allow_duplicates: true`` を使用しない限り、そのロールの依存関係を 1 回のみ実行します。詳細は、「:ref:`Galaxy role dependencies <galaxy_dependencies>`」を参照してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:477 +msgid "Role deduplication does not consult the invocation signature of parent roles. Additionally, when using ``vars:`` instead of role params, there is a side effect of changing variable scoping. Using ``vars:`` results in those variables being scoped at the play level. In the below example, using ``vars:`` would cause ``n`` to be defined as ``4`` through the entire play, including roles called before it." +msgstr "ロールの重複排除は、親ロールの呼び出し署名を参照しません。さらに、ロールパラメーターの代わりに ``vars:`` を使用する場合は、変数のスコープを変更するという副作用があります。``vars:`` を使用すると、それらの変数がプレイレベルで対象となります。以下の例では、``vars:`` を使用すると、それ以前に呼び出されたロールを含め、プレー全体を通して ``n`` が ``4`` として定義されることになります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:479 +msgid "In addition to the above, users should be aware that role de-duplication occurs before variable evaluation. This means that :term:`Lazy Evaluation` may make seemingly different role invocations equivalently the same, preventing the role from running more than once." +msgstr "上記に加えて、ユーザーは変数評価の前にロールの重複排除が行われることに注意する必要があります。つまり、:term:`Lazy Evaluation` は、一見異なるロールの呼び出しを等価にして、ロールが複数回実行されるのを防ぐことができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:482 +msgid "For example, a role named ``car`` depends on a role named ``wheel`` as follows:" +msgstr "たとえば、``car`` という名前のロールは、以下のように ``wheel`` という名前のロールに依存します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:497 +msgid "And the ``wheel`` role depends on two roles: ``tire`` and ``brake``. The ``meta/main.yml`` for wheel would then contain the following:" +msgstr "そして、``wheel`` のロールは、``tire`` と ``brake`` の 2 つのロールに依存します。このため、wheel 用の ``meta/main.yml`` は以下のようになります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:506 +msgid "And the ``meta/main.yml`` for ``tire`` and ``brake`` would contain the following:" +msgstr "そして、「``tire``」および「``brake``」の「``meta/main.yml``」には、次のような内容が含まれています。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:513 +msgid "The resulting order of execution would be as follows:" +msgstr "その結果作成される実行順序は以下のようになります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:526 +msgid "To use ``allow_duplicates: true`` with role dependencies, you must specify it for the role listed under ``dependencies``, not for the role that lists it. In the example above, ``allow_duplicates: true`` appears in the ``meta/main.yml`` of the ``tire`` and ``brake`` roles. The ``wheel`` role does not require ``allow_duplicates: true``, because each instance defined by ``car`` uses different parameter values." +msgstr "``allow_duplicates: true`` をロール依存で使用するには、それをリストしているロールではなく、``dependencies`` の下にリストされているロールに対して指定する必要があります。上記の例では、``allow_duplicates: true`` は、``tire`` ロールおよび ``brake`` ロールの ``meta/main.yml`` に表示されます。``wheel`` ロールは、``car`` で定義された各インスタンスが異なるパラメーター値を使用するため、``allow_duplicates: true`` を必要としません。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:529 +msgid "See :ref:`playbooks_variables` for details on how Ansible chooses among variable values defined in different places (variable inheritance and scope). Also deduplication happens ONLY at the play level, so multiple plays in the same playbook may rerun the roles." +msgstr "Ansible が、さまざまな場所（変数継承および範囲）で定義される変数の値から選択する方法は、「:ref:`playbooks_variables`」を参照してください。また、重複排除はプレイレベルでのみ行われるため、同じ Playbook の複数のプレイがロールを再実行する可能性があります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:535 +msgid "Embedding modules and plugins in roles" +msgstr "ロールでのモジュールおよびプラグインの埋め込み" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:537 +msgid "If you write a custom module (see :ref:`developing_modules`) or a plugin (see :ref:`developing_plugins`), you might wish to distribute it as part of a role. For example, if you write a module that helps configure your company's internal software, and you want other people in your organization to use this module, but you do not want to tell everyone how to configure their Ansible library path, you can include the module in your internal_config role." +msgstr "カスタムモジュール (「:ref:`developing_modules`」を参照) やプラグイン (「:ref:`developing_plugins`」を参照) を作成した場合は、ロールの一部として配布したい場合があります。たとえば、社内のソフトウェアを設定するためのモジュールを作成し、組織内の他の人にもこのモジュールを使用してほしいにも関わらず、Ansible のライブラリーパスを設定する方法を全員に開示したくない場合は、internal_config ロールにモジュールを含めることができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:539 +msgid "To add a module or a plugin to a role: Alongside the 'tasks' and 'handlers' structure of a role, add a directory named 'library' and then include the module directly inside the 'library' directory." +msgstr "モジュールやプラグインをロールに追加するには、ロールの「tasks」および「handlers」構造の横に、「library」という名前のディレクトリーを追加し、その「library」ディレクトリー内にモジュールを直接インクルードします。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:542 +msgid "Assuming you had this:" +msgstr "以下があるとします。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:552 +msgid "The module will be usable in the role itself, as well as any roles that are called *after* this role, as follows:" +msgstr "モジュールは、次のように、ロール自体、およびこのロールの *後に* 呼び出されるすべてのロールで使用できます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:563 +msgid "If necessary, you can also embed a module in a role to modify a module in Ansible's core distribution. For example, you can use the development version of a particular module before it is released in production releases by copying the module and embedding the copy in a role. Use this approach with caution, as API signatures may change in core components, and this workaround is not guaranteed to work." +msgstr "必要に応じて、ロールにモジュールを埋め込み、Ansible のコアディストリビューションのモジュールを変更することもできます。たとえば、モジュールをコピーし、そのコピーをロールに埋め込むことで、特定のモジュールの開発バージョンを実稼働リリースの前に使用することができます。コアコンポーネントでは API シグネチャーが変更する可能性があり、この回避策は動作が保証されていないため、この方法は慎重に使用してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:565 +msgid "The same mechanism can be used to embed and distribute plugins in a role, using the same schema. For example, for a filter plugin:" +msgstr "同じスキーマを使用して、ロールにプラグインを埋め込んだり配布したりすることもできます。たとえば、フィルタープラグインの場合は、以下のようになります。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:575 +msgid "These filters can then be used in a Jinja template in any role called after 'my_custom_filter'." +msgstr "これらのフィルターは、Jinja のテンプレートで、「my_custom_filter」の後に呼ばれる任意のロールで使用することができます。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:578 +msgid "Sharing roles: Ansible Galaxy" +msgstr "ロールの共有: Ansible Galaxy" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:580 +msgid "`Ansible Galaxy <https://galaxy.ansible.com>`_ is a free site for finding, downloading, rating, and reviewing all kinds of community-developed Ansible roles and can be a great way to get a jumpstart on your automation projects." +msgstr "`Ansible Galaxy <https://galaxy.ansible.com>`_ は、コミュニティーで開発されたあらゆる種類の Ansible ロールを検索、ダウンロード、評価、およびレビューする無料サイトで、ここで自動化プロジェクトをすぐに開始するための優れた方法です。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:582 +msgid "The client ``ansible-galaxy`` is included in Ansible. The Galaxy client allows you to download roles from Ansible Galaxy, and also provides an excellent default framework for creating your own roles." +msgstr "クライアント ``ansible-galaxy`` は、Ansible に含まれています。Galaxy クライアントを使用すると、Ansible Galaxy からロールをダウンロードでき、独自のロールを作成する優れたデフォルトのフレームワークも提供します。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:584 +msgid "Read the `Ansible Galaxy documentation <https://galaxy.ansible.com/docs/>`_ page for more information" +msgstr "詳細は、`Ansible Galaxy ドキュメント <https://galaxy.ansible.com/docs/>`_ ページを参照してください。" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:589 +msgid "How to create new roles, share roles on Galaxy, role management" +msgstr "新規ロールの作成、Galaxy でのロールの共有、およびロールの管理の方法" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:597 +msgid "Variables in playbooks" +msgstr "Playbook の変数" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:602 +msgid ":ref:`tags`" +msgstr ":ref:`tags`" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:603 +msgid "Using tags to select or skip roles/tasks in long playbooks" +msgstr "タグを使用した長い Playbook でロール/タスクの選択またはスキップ" + +#: ../../rst/user_guide/playbooks_reuse_roles.rst:607 +msgid "Extending Ansible by writing your own modules" +msgstr "独自のモジュールを作成して Ansible を拡張" + +#: ../../rst/user_guide/playbooks_roles.rst:4 +msgid "Playbook Roles and Include Statements" +msgstr "Playbook ロールおよび Include 文" + +#: ../../rst/user_guide/playbooks_roles.rst:7 +#: ../../rst/user_guide/windows_dsc.rst:5 +#: ../../rst/user_guide/windows_usage.rst:9 +msgid "Topics" +msgstr "トピック" + +#: ../../rst/user_guide/playbooks_roles.rst:9 +msgid "The documentation regarding roles and includes for playbooks have moved. Their new location is here: :ref:`playbooks_reuse`. Please update any links you may have made directly to this page." +msgstr "Playbook のロールおよびインクルードに関するドキュメントが移動しました。新しい場所は「:ref:`playbooks_reuse`」です。このページに直接作成したリンクを更新してください。" + +#: ../../rst/user_guide/playbooks_roles.rst:17 +msgid ":ref:`playbooks_reuse`" +msgstr ":ref:`playbooks_reuse`" + +#: ../../rst/user_guide/playbooks_roles.rst:18 +msgid "Creating reusable Playbooks." +msgstr "再利用可能な Playbook の作成" + +#: ../../rst/user_guide/playbooks_special_topics.rst:6 +msgid "Advanced playbooks features" +msgstr "Playbook の高度な機能" + +#: ../../rst/user_guide/playbooks_special_topics.rst:8 +msgid "This page is obsolete. Refer to the :ref:`main User Guide index page <user_guide_index>` for links to all playbook-related topics. Please update any links you may have made directly to this page." +msgstr "このページは使用されなくなりました。Playbook に関連するすべてのトピックへのリンクは、:ref:`メインのユーザーガイドのインデックスページ <user_guide_index>` を参照してください。このページに直接リンクを張っている場合は更新してください。" + +#: ../../rst/user_guide/playbooks_startnstep.rst:5 +msgid "Executing playbooks for troubleshooting" +msgstr "トラブルシューティングのための Playbook の実行" + +#: ../../rst/user_guide/playbooks_startnstep.rst:7 +msgid "When you are testing new plays or debugging playbooks, you may need to run the same play multiple times. To make this more efficient, Ansible offers two alternative ways to execute a playbook: start-at-task and step mode." +msgstr "新しいプレイをテストしたり、Playbook をデバッグしたりする際に、同じプレイを複数回実行しないといけない場合があります。これを効率的に行うために、Ansible では Playbook の実行方法として、start-at-task モードと step モードの 2 種類を用意しています。" + +#: ../../rst/user_guide/playbooks_startnstep.rst:12 +msgid "start-at-task" +msgstr "start-at-task" + +#: ../../rst/user_guide/playbooks_startnstep.rst:14 +msgid "To start executing your playbook at a particular task (usually the task that failed on the previous run), use the ``--start-at-task`` option." +msgstr "特定のタスク (通常は直前の実行で失敗したタスク) で Playbook の実行を開始するには、``--start-at-task`` オプションを使用します。" + +#: ../../rst/user_guide/playbooks_startnstep.rst:20 +msgid "In this example, Ansible starts executing your playbook at a task named \"install packages\". This feature does not work with tasks inside dynamically re-used roles or tasks (``include_*``), see :ref:`dynamic_vs_static`." +msgstr "この例では、Ansible は「install packages」という名前のタスクで Playbook の実行を開始します。この機能は、動的に再利用されるロールやタスク内のタスク (``include_*``) では動作しません。「:ref:`dynamic_vs_static`」を参照してください。" + +#: ../../rst/user_guide/playbooks_startnstep.rst:25 +msgid "Step mode" +msgstr "step モード" + +#: ../../rst/user_guide/playbooks_startnstep.rst:27 +msgid "To execute a playbook interactively, use ``--step``." +msgstr "Playbook を対話的に実行するには、``--step`` を使用します。" + +#: ../../rst/user_guide/playbooks_startnstep.rst:33 +msgid "With this option, Ansible stops on each task, and asks if it should execute that task. For example, if you have a task called \"configure ssh\", the playbook run will stop and ask." +msgstr "このオプションを使用すると、Ansible は各タスクで停止し、そのタスクを実行すべきかどうかを尋ねます。たとえば、「configure ssh」という名前のタスクがあった場合、Playbook の実行は停止し、次のように尋ねてきます。" + +#: ../../rst/user_guide/playbooks_startnstep.rst:39 +msgid "Answer \"y\" to execute the task, answer \"n\" to skip the task, and answer \"c\" to exit step mode, executing all remaining tasks without asking." +msgstr "「y」と答えてタスクを実行し、「n」と答えてタスクをスキップし、「c」と応えて step モードを終了し、残りのタスクをすべて実行します。" + +#: ../../rst/user_guide/playbooks_startnstep.rst:45 +msgid ":ref:`playbook_debugger`" +msgstr ":ref:`playbook_debugger`" + +#: ../../rst/user_guide/playbooks_startnstep.rst:46 +msgid "Using the Ansible debugger" +msgstr "Ansible デバッガーの使用" + +#: ../../rst/user_guide/playbooks_strategies.rst:4 +msgid "Controlling playbook execution: strategies and more" +msgstr "Playbook の実行の制御: strategy など" + +#: ../../rst/user_guide/playbooks_strategies.rst:6 +msgid "By default, Ansible runs each task on all hosts affected by a play before starting the next task on any host, using 5 forks. If you want to change this default behavior, you can use a different strategy plugin, change the number of forks, or apply one of several keywords like ``serial``." +msgstr "デフォルトでは、Ansible はプレイの影響を受けるすべてのホストで各タスクを実行してから、任意のホストで次のタスクを開始し、5 つのフォークを使用します。このデフォルトの動作を変更する場合は、別のストラテジープラグインを使用するか、フォーク数を変更するか、``serial`` のようなキーワードのいずれかを適用することができます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:12 +msgid "Selecting a strategy" +msgstr "ストラテジーの選択" + +#: ../../rst/user_guide/playbooks_strategies.rst:13 +msgid "The default behavior described above is the :ref:`linear strategy<linear_strategy>`. Ansible offers other strategies, including the :ref:`debug strategy<debug_strategy>` (see also :ref:`playbook_debugger`) and the :ref:`free strategy<free_strategy>`, which allows each host to run until the end of the play as fast as it can:" +msgstr "上述のデフォルトの動作は :ref:`linear strategy<linear_strategy>` です。Ansible には、:ref:`debug strategy<debug_strategy>` (:ref:`playbook_debugger` も参照) や :ref:`free strategy<free_strategy>` など、他のストラテジーも用意されています。フリーストラテジーでは、各ホストがプレイが終了するまでできるだけ速く実行することができます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:22 +msgid "You can select a different strategy for each play as shown above, or set your preferred strategy globally in ``ansible.cfg``, under the ``defaults`` stanza:" +msgstr "上記のように各プレイに異なるストラテジーを選択するか、``defaults`` stanza の ``ansible.cfg`` で優先されるストラテジーをグローバルに設定できます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:29 +msgid "All strategies are implemented as :ref:`strategy plugins<strategy_plugins>`. Please review the documentation for each strategy plugin for details on how it works." +msgstr "すべてのストラテジーは :ref:`strategy プラグイン<strategy_plugins>` として実装されます。その仕組みの詳細は、各 strategy プラグインのドキュメントを参照してください。" + +#: ../../rst/user_guide/playbooks_strategies.rst:32 +msgid "Setting the number of forks" +msgstr "フォークの数の設定" + +#: ../../rst/user_guide/playbooks_strategies.rst:33 +msgid "If you have the processing power available and want to use more forks, you can set the number in ``ansible.cfg``:" +msgstr "利用可能な処理能力があり、さらに多くのフォークを使用する場合は、``ansible.cfg`` で数値を設定できます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:40 +msgid "or pass it on the command line: `ansible-playbook -f 30 my_playbook.yml`." +msgstr "または、コマンドラインで渡します (`ansible-playbook -f 30 my_playbook.yml`)。" + +#: ../../rst/user_guide/playbooks_strategies.rst:43 +msgid "Using keywords to control execution" +msgstr "キーワードを使用した実行の制御" + +#: ../../rst/user_guide/playbooks_strategies.rst:45 +msgid "In addition to strategies, several :ref:`keywords<playbook_keywords>` also affect play execution. You can set a number, a percentage, or a list of numbers of hosts you want to manage at a time with ``serial``. Ansible completes the play on the specified number or percentage of hosts before starting the next batch of hosts. You can restrict the number of workers allotted to a block or task with ``throttle``. You can control how Ansible selects the next host in a group to execute against with ``order``. You can run a task on a single host with ``run_once``. These keywords are not strategies. They are directives or options applied to a play, block, or task." +msgstr "ストラテジーだけでなく、いくつかの :ref:`キーワード<playbook_keywords>` もプレイの実行に影響を与えます。``serial`` では、一度に管理したいホストの数、割合、またはリストを設定できます。Ansible は、指定した数または割合のホストでプレイを完了してから、次のホストのバッチを開始します。``throttle`` で、ブロックやタスクに割り当てられるワーカーの数を制限することができます。``order`` で、Ansible がグループ内の次のホストを選択して実行する方法を制御できます。``run_once`` を使用して、1 つのタスクを 1 つのホストで実行することができます。これらのキーワードはストラテジーではなく、プレイ、ブロック、またはタスクに適用されるディレクティブやオプションです。" + +#: ../../rst/user_guide/playbooks_strategies.rst:47 +msgid "Other keywords that affect play execution include ``ignore_errors``, ``ignore_unreachable``, and ``any_errors_fatal``. These options are documented in :ref:`playbooks_error_handling`." +msgstr "プレイの実行に影響する他のキーワードには、``ignore_errors``、``ignore_unreachable``、および ``any_errors_fatal`` が含まれます。これらのオプションは、「:ref:`playbooks_error_handling`」に記載されています。" + +#: ../../rst/user_guide/playbooks_strategies.rst:52 +msgid "Setting the batch size with ``serial``" +msgstr "``serial`` を使用してバッチサイズの設定" + +#: ../../rst/user_guide/playbooks_strategies.rst:54 +msgid "By default, Ansible runs in parallel against all the hosts in the :ref:`pattern <intro_patterns>` you set in the ``hosts:`` field of each play. If you want to manage only a few machines at a time, for example during a rolling update, you can define how many hosts Ansible should manage at a single time using the ``serial`` keyword:" +msgstr "デフォルトでは、Ansible は、各プレイの ``hosts:`` フィールドで設定した :ref:`pattern <intro_patterns>` のすべてのホストに対して並行して実行します。ローリングアップデート中など、一度に数台のマシンのみを管理する場合は、``serial`` キーワードを使用して、Ansible が一度に管理するホストの数を定義できます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:71 +msgid "In the above example, if we had 6 hosts in the group 'webservers', Ansible would execute the play completely (both tasks) on 3 of the hosts before moving on to the next 3 hosts:" +msgstr "上の例では、「webservers」というグループに 6 台のホストがあった場合、Ansible はそのうちの 3 台のホストでプレイを完全に (両方のタスクを) 実行してから、次の 3 台のホストに移ります。" + +#: ../../rst/user_guide/playbooks_strategies.rst:109 +msgid "Setting the batch size with ``serial`` changes the scope of the Ansible failures to the batch size, not the entire host list. You can use :ref:`ignore_unreachable <ignore_unreachable>` or :ref:`max_fail_percentage <maximum_failure_percentage>` to modify this behavior." +msgstr "``serial`` を使用してバッチサイズを設定すると、ホストリスト全体ではなく、Ansible の失敗のスコープがバッチサイズに変更されます。この動作を変更するには、:ref:`ignore_unreachable <ignore_unreachable>` または :ref:`max_fail_percentage <maximum_failure_percentage>` を使用します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:111 +msgid "You can also specify a percentage with the ``serial`` keyword. Ansible applies the percentage to the total number of hosts in a play to determine the number of hosts per pass:" +msgstr "``serial`` キーワードでパーセンテージを指定することもできます。Ansible は、プレイ内のホストの合計数にパーセンテージを適用して、パスごとのホスト数を決定します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:120 +msgid "If the number of hosts does not divide equally into the number of passes, the final pass contains the remainder. In this example, if you had 20 hosts in the webservers group, the first batch would contain 6 hosts, the second batch would contain 6 hosts, the third batch would contain 6 hosts, and the last batch would contain 2 hosts." +msgstr "ホストの数がパスの数に等しく分配されない場合は、最後のパスには残りの数が含まれます。この例では、webservers グループに 20 台のホストがある場合、最初のバッチには 6 台のホストが、2 番目のバッチには 6 台のホストが、3 番目のバッチには 6 台のホストが、そして最後のバッチには 2 台のホストが含まれます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:122 +msgid "You can also specify batch sizes as a list. For example:" +msgstr "また、バッチサイズをリストとして指定することもできます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:134 +msgid "In the above example, the first batch would contain a single host, the next would contain 5 hosts, and (if there are any hosts left), every following batch would contain either 10 hosts or all the remaining hosts, if fewer than 10 hosts remained." +msgstr "上記の例では、最初のバッチには 1 台のホストが含まれ、次のバッチには 5 台のホストが含まれ、(ホストが残っていれば) その後のすべてのバッチには 10 台のホストが含まれるか、または 10 台未満のホストが残っていれば、残りのすべてのホストが含まれることになります。" + +#: ../../rst/user_guide/playbooks_strategies.rst:136 +msgid "You can list multiple batch sizes as percentages:" +msgstr "複数のバッチサイズをパーセンテージとして一覧表示できます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:148 +msgid "You can also mix and match the values:" +msgstr "値を混在させたり、一致させることもできます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:161 +msgid "No matter how small the percentage, the number of hosts per pass will always be 1 or greater." +msgstr "パーセンテージを小さくしても、各パスのホスト数は常に 1 以上になります。" + +#: ../../rst/user_guide/playbooks_strategies.rst:164 +msgid "Restricting execution with ``throttle``" +msgstr "``throttle`` で実行を制限" + +#: ../../rst/user_guide/playbooks_strategies.rst:166 +msgid "The ``throttle`` keyword limits the number of workers for a particular task. It can be set at the block and task level. Use ``throttle`` to restrict tasks that may be CPU-intensive or interact with a rate-limiting API:" +msgstr "``throttle`` キーワードは、特定のタスクに対するワーカーの数を制限します。これは、ブロックおよびタスクのレベルで設定できます。``throttle`` を使用して、CPU に負荷がかかる可能性のあるタスクや、レート制限 API と相互作用するタスクを制限します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:174 +msgid "If you have already restricted the number of forks or the number of machines to execute against in parallel, you can reduce the number of workers with ``throttle``, but you cannot increase it. In other words, to have an effect, your ``throttle`` setting must be lower than your ``forks`` or ``serial`` setting if you are using them together." +msgstr "すでにフォークの数や並列実行するマシンの数を制限している場合は、``throttle`` でワーカーの数を減らすことはできますが、増やすことはできません。つまり、それを合わせて使用する場合に効果を得るためには、``throttle`` の設定が ``forks`` や ``serial`` の設定よりも低くなければなりません。" + +#: ../../rst/user_guide/playbooks_strategies.rst:177 +msgid "Ordering execution based on inventory" +msgstr "インベントリーに基づく実行の順序付け" + +#: ../../rst/user_guide/playbooks_strategies.rst:179 +msgid "The ``order`` keyword controls the order in which hosts are run. Possible values for order are:" +msgstr "``order`` キーワードは、ホストが実行する順序を制御します。order に指定できる値は次のとおりです。" + +#: ../../rst/user_guide/playbooks_strategies.rst:181 +msgid "inventory:" +msgstr "inventory:" + +#: ../../rst/user_guide/playbooks_strategies.rst:182 +msgid "(default) The order provided by the inventory for the selection requested (see note below)" +msgstr "（デフォルト）要求された選択に対してインベントリーによって提供される順序（以下の注記を参照）" + +#: ../../rst/user_guide/playbooks_strategies.rst:183 +msgid "reverse_inventory:" +msgstr "reverse_inventory:" + +#: ../../rst/user_guide/playbooks_strategies.rst:184 +msgid "The same as above, but reversing the returned list" +msgstr "上記と同じですが、返されたリストの再検証" + +#: ../../rst/user_guide/playbooks_strategies.rst:185 +msgid "sorted:" +msgstr "sorted:" + +#: ../../rst/user_guide/playbooks_strategies.rst:186 +msgid "Sorted alphabetically sorted by name" +msgstr "名前をアルファベット順で並べ替えます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:187 +msgid "reverse_sorted:" +msgstr "reverse_sorted:" + +#: ../../rst/user_guide/playbooks_strategies.rst:188 +msgid "Sorted by name in reverse alphabetical order" +msgstr "アルファベットの逆順で名前がソートされます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:190 +msgid "shuffle:" +msgstr "shuffle:" + +#: ../../rst/user_guide/playbooks_strategies.rst:190 +msgid "Randomly ordered on each run" +msgstr "実行ごとにランダムに順序付けられます。" + +#: ../../rst/user_guide/playbooks_strategies.rst:193 +msgid "the 'inventory' order does not equate to the order in which hosts/groups are defined in the inventory source file, but the 'order in which a selection is returned from the compiled inventory'. This is a backwards compatible option and while reproducible it is not normally predictable. Due to the nature of inventory, host patterns, limits, inventory plugins and the ability to allow multiple sources it is almost impossible to return such an order. For simple cases this might happen to match the file definition order, but that is not guaranteed." +msgstr "'インベントリー' の順序は、インベントリーソースファイル内でホスト/グループが定義する順序と同じではありませんが、'コンパイルされたインベントリーから選択が返される順序' と同じです。これは下位互換性のあるオプションであり、再現可能ですが、通常は予測できません。インベントリーの性質、ホストパターン、制限、インベントリープラグイン、および複数のソースを許可する機能により、そのような順序を返すことはほとんど不可能です。単純なケースでは、これはファイル定義の順序と一致する可能性がありますが、それは保証されていません。" + +#: ../../rst/user_guide/playbooks_strategies.rst:198 +msgid "Running on a single machine with ``run_once``" +msgstr "シングルマシンで、``run_once`` で動作します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:200 +msgid "If you want a task to run only on the first host in your batch of hosts, set ``run_once`` to true on that task:" +msgstr "ホストのバッチの最初のホストでタスクを実行する場合は、そのタスクで ``run_once`` を true に設定します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:216 +msgid "Ansible executes this task on the first host in the current batch and applies all results and facts to all the hosts in the same batch. This approach is similar to applying a conditional to a task such as:" +msgstr "Ansible は、現在のバッチの最初のホストでこのタスクを実行し、すべての結果とファクトを同じバッチのすべてのホストに適用します。この方法は、次のような条件をタスクに適用することに似ています。" + +#: ../../rst/user_guide/playbooks_strategies.rst:223 +msgid "However, with ``run_once``, the results are applied to all the hosts. To run the task on a specific host, instead of the first host in the batch, delegate the task:" +msgstr "ただし、``run_once`` では、結果はすべてのホストに適用されます。バッチの最初のホストではなく、特定のホストでタスクを実行するには、タスクを次のように委譲します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:231 +msgid "As always with :ref:`delegation <playbooks_delegation>`, the action will be executed on the delegated host, but the information is still that of the original host in the task." +msgstr ":ref:`委譲 <playbooks_delegation>` の場合と同様、アクションは委譲されたホストで実行されますが、情報はタスクの元のホストの情報になります。" + +#: ../../rst/user_guide/playbooks_strategies.rst:234 +msgid "When used together with ``serial``, tasks marked as ``run_once`` will be run on one host in *each* serial batch. If the task must run only once regardless of ``serial`` mode, use :code:`when: inventory_hostname == ansible_play_hosts_all[0]` construct." +msgstr "``serial`` と併用すると、``run_once`` とマークされたタスクは、*各* シリアルバッチの中の 1 台のホストで実行します。タスクが ``serial`` モードに関係なく 1 回だけ実行する必要がある場合は、:code:`when: inventory_hostname == ansible_play_hosts_all[0]` コンストラクトを使用します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:238 +msgid "Any conditional (in other words, `when:`) will use the variables of the 'first host' to decide if the task runs or not, no other hosts will be tested." +msgstr "条件 (つまり `when:`) は、「first host」の変数を使用して、タスクが実行されるかどうかを判断し、他のホストはテストされません。" + +#: ../../rst/user_guide/playbooks_strategies.rst:241 +msgid "If you want to avoid the default behavior of setting the fact for all hosts, set ``delegate_facts: True`` for the specific task or block." +msgstr "すべてのホストにファクトを設定するデフォルトの動作を回避する場合は、特定のタスクまたはブロックに ``delegate_facts: True`` を設定します。" + +#: ../../rst/user_guide/playbooks_strategies.rst:247 +msgid ":ref:`playbooks_delegation`" +msgstr ":ref:`playbooks_delegation`" + +#: ../../rst/user_guide/playbooks_strategies.rst:248 +msgid "Running tasks on or assigning facts to specific machines" +msgstr "特定マシンでのタスクの実行、または特定マシンへのファクトの割り当て" + +#: ../../rst/user_guide/playbooks_tags.rst:5 +msgid "Tags" +msgstr "タグ" + +#: ../../rst/user_guide/playbooks_tags.rst:7 +msgid "If you have a large playbook, it may be useful to run only specific parts of it instead of running the entire playbook. You can do this with Ansible tags. Using tags to execute or skip selected tasks is a two-step process:" +msgstr "大規模な Playbook を使用する場合は、Playbook 全体を実行するのではなく、特定の部分だけを実行すると便利な場合があります。これを実現するには、Ansible のタグを使用します。タグを使用して選択したタスクを実行またはスキップするには、2 つのステップがあります。" + +#: ../../rst/user_guide/playbooks_tags.rst:9 +msgid "Add tags to your tasks, either individually or with tag inheritance from a block, play, role, or import." +msgstr "タスクにタグを追加するには、個別にタグを追加するか、ブロック、プレイ、ロール、またはインポートからタグを継承する必要があります。" + +#: ../../rst/user_guide/playbooks_tags.rst:10 +msgid "Select or skip tags when you run your playbook." +msgstr "Playbook の実行時にタグを選択またはスキップします。" + +#: ../../rst/user_guide/playbooks_tags.rst:16 +msgid "Adding tags with the tags keyword" +msgstr "tags キーワードを使用したタグの追加" + +#: ../../rst/user_guide/playbooks_tags.rst:18 +msgid "You can add tags to a single task or include. You can also add tags to multiple tasks by defining them at the level of a block, play, role, or import. The keyword ``tags`` addresses all these use cases. The ``tags`` keyword always defines tags and adds them to tasks; it does not select or skip tasks for execution. You can only select or skip tasks based on tags at the command line when you run a playbook. See :ref:`using_tags` for more details." +msgstr "タグは、単一のタスクまたはインクルードに追加できます。また、ブロック、プレイ、ロール、またはインポートのレベルでタグを定義することで、複数のタスクにタグを追加することもできます。``tags`` キーワードは、これらすべてのユースケースに対応しています。``tags`` キーワードは、常にタグを定義してタスクに追加しますが、実行するタスクの選択やスキップは行いません。タグに基づいてタスクを選択またはスキップできるのは、Playbook の実行時にコマンドラインで行う場合のみです。詳細は、「:ref:`using_tags`」を参照してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:21 +msgid "Adding tags to individual tasks" +msgstr "個別タスクへのタグの追加" + +#: ../../rst/user_guide/playbooks_tags.rst:23 +msgid "At the simplest level, you can apply one or more tags to an individual task. You can add tags to tasks in playbooks, in task files, or within a role. Here is an example that tags two tasks with different tags:" +msgstr "最も簡単なレベルでは、個々のタスクに 1 つまたは複数のタグを適用できます。タグは、Playbook 内、タスクファイル内、またはロール内のタスクに追加できます。以下は、2 つのタスクに異なるタグを付ける例です。" + +#: ../../rst/user_guide/playbooks_tags.rst:45 +msgid "You can apply the same tag to more than one individual task. This example tags several tasks with the same tag, \"ntp\":" +msgstr "同じタグを複数の個別タスクに適用できます。この例では、同じタグ「ntp」を使用して、複数のタスクにタグを付けることができます。" + +#: ../../rst/user_guide/playbooks_tags.rst:81 +msgid "If you ran these four tasks in a playbook with ``--tags ntp``, Ansible would run the three tasks tagged ``ntp`` and skip the one task that does not have that tag." +msgstr "``--tags ntp`` を使用して、この 4 つのタスクを Playbook で実行した場合、Ansible は ``ntp`` のタグが付いた 3 つのタスクを実行し、タグが付いていない 1 つのタスクをスキップします。" + +#: ../../rst/user_guide/playbooks_tags.rst:86 +msgid "Adding tags to includes" +msgstr "インクルードするタグの追加" + +#: ../../rst/user_guide/playbooks_tags.rst:88 +msgid "You can apply tags to dynamic includes in a playbook. As with tags on an individual task, tags on an ``include_*`` task apply only to the include itself, not to any tasks within the included file or role. If you add ``mytag`` to a dynamic include, then run that playbook with ``--tags mytag``, Ansible runs the include itself, runs any tasks within the included file or role tagged with ``mytag``, and skips any tasks within the included file or role without that tag. See :ref:`selective_reuse` for more details." +msgstr "タグは、Playbook 内の動的インクルードにタグを適用できます。個々のタスクのタグと同様に、``include_*`` タスクのタグは、インクルード自体にのみ適用され、インクルードされたファイルやロール内のタスクには適用されません。動的インクルードに ``mytag`` を追加し、その Playbook を ``--tags mytag`` で実行すると、Ansible はインクルード自体を実行し、``mytag`` でタグ付けされたインクルードファイルまたはロール内のタスクを実行し、そのタグのないインクルードファイルまたはロール内のタスクをスキップします。詳細は「:ref:`selective_reuse`」を参照してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:90 +msgid "You add tags to includes the same way you add tags to any other task:" +msgstr "タグを追加して、他のタスクにタグを追加する方法と同じ方法でインクルードします。" + +#: ../../rst/user_guide/playbooks_tags.rst:101 +msgid "You can add a tag only to the dynamic include of a role. In this example, the ``foo`` tag will `not` apply to tasks inside the ``bar`` role:" +msgstr "タグは、ロールの動的インクルードにのみ追加できます。この例では、``foo`` タグは ``bar`` ロール内のタスクに適用 `されません`。" + +#: ../../rst/user_guide/playbooks_tags.rst:114 +msgid "With plays, blocks, the ``role`` keyword, and static imports, Ansible applies tag inheritance, adding the tags you define to every task inside the play, block, role, or imported file. However, tag inheritance does *not* apply to dynamic re-use with ``include_role`` and ``include_tasks``. With dynamic re-use (includes), the tags you define apply only to the include itself. If you need tag inheritance, use a static import. If you cannot use an import because the rest of your playbook uses includes, see :ref:`apply_keyword` for ways to work around this behavior." +msgstr "プレイ、ブロック、``role`` キーワード、および静的なインポートでは、Ansible はタグ継承を適用し、定義したタグをプレイ、ブロック、ロール、またはインポートしたファイル内のすべてのタスクに追加します。しかし、``include_role`` や ``include_tasks`` のような動的再利用では、タグの継承は *適用されません*。動的再利用 (インクルード) では、定義したタグはインクルード自体にのみ適用されます。タグの継承が必要な場合は、静的インポートを使用してください。Playbook の他の部分がインクルードを使用しているためにインポートを使用できない場合は、この動作を回避する方法について「:ref:`apply_keyword`」を参照してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:119 +msgid "Tag inheritance: adding tags to multiple tasks" +msgstr "タグの継承: 複数のタスクへのタグの追加" + +#: ../../rst/user_guide/playbooks_tags.rst:121 +msgid "If you want to apply the same tag or tags to multiple tasks without adding a ``tags`` line to every task, you can define the tags at the level of your play or block, or when you add a role or import a file. Ansible applies the tags down the dependency chain to all child tasks. With roles and imports, Ansible appends the tags set by the ``roles`` section or import to any tags set on individual tasks or blocks within the role or imported file. This is called tag inheritance. Tag inheritance is convenient, because you do not have to tag every task. However, the tags still apply to the tasks individually." +msgstr "すべてのタスクに ``tags`` 行を追加することなく、複数のタスクに同じタグを適用したい場合は、プレイやブロックのレベル、またはロールの追加やファイルのインポートの際にタグを定義することができます。Ansible は、依存関係の連鎖の下にあるタグをすべての子タスクに適用します。ロールやインポートの場合、Ansible は ``roles`` セクションやインポートで設定されたタグを、ロールやインポートしたファイル内の個々のタスクやブロックに設定されたタグに追加します。これを「タグの継承」と呼びます。タグの継承は、すべてのタスクにタグを付ける必要がないため便利です。ただし、タグはタスクに個別に適用されます。" + +#: ../../rst/user_guide/playbooks_tags.rst:124 +msgid "Adding tags to blocks" +msgstr "ブロックへのタグの追加" + +#: ../../rst/user_guide/playbooks_tags.rst:126 +msgid "If you want to apply a tag to many, but not all, of the tasks in your play, use a :ref:`block <playbooks_blocks>` and define the tags at that level. For example, we could edit the NTP example shown above to use a block:" +msgstr "プレイ中のタスクのすべてではなく、多くのタスクにタグを適用したい場合は、:ref:`ブロック <playbooks_blocks>` を使用し、そのレベルでタグを定義します。たとえば、上で紹介した NTP の例を編集して、ブロックを使用することができます。" + +#: ../../rst/user_guide/playbooks_tags.rst:161 +msgid "Adding tags to plays" +msgstr "プレイへのタグの追加" + +#: ../../rst/user_guide/playbooks_tags.rst:163 +msgid "If all the tasks in a play should get the same tag, you can add the tag at the level of the play. For example, if you had a play with only the NTP tasks, you could tag the entire play:" +msgstr "プレイの中のすべてのタスクに同じタグを付ける必要がある場合は、プレイのレベルでタグを追加することができます。たとえば、NTP タスクだけのプレイがあった場合は、プレイ全体にタグを付けることができます。" + +#: ../../rst/user_guide/playbooks_tags.rst:194 +msgid "Adding tags to roles" +msgstr "ロールへのタグの追加" + +#: ../../rst/user_guide/playbooks_tags.rst:196 +msgid "There are three ways to add tags to roles:" +msgstr "ロールにタグを追加するには、3 つの方法があります。" + +#: ../../rst/user_guide/playbooks_tags.rst:198 +msgid "Add the same tag or tags to all tasks in the role by setting tags under ``roles``. See examples in this section." +msgstr "``roles`` セクションにタグを設定して、ロールのすべてのタスクに同じタグを追加します。本セクションの例を参照してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:199 +msgid "Add the same tag or tags to all tasks in the role by setting tags on a static ``import_role`` in your playbook. See examples in :ref:`tags_on_imports`." +msgstr "Playbook の静的 ``import_role`` にタグを設定して、ロール内のすべてのタスクに同じタグを追加します。「:ref:`tags_on_imports`」の例を参照してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:200 +msgid "Add a tag or tags to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role. To select or skip tasks within the role, you must have tags set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the same tag or tags to the include. When you use this approach, and then run your playbook with ``--tags foo``, Ansible runs the include itself plus any tasks in the role that also have the tag ``foo``. See :ref:`tags_on_includes` for details." +msgstr "ロール自体の中の個々のタスクやブロックにタグを追加します。これは、ロール内の一部のタスクを選択またはスキップすることができる唯一の方法です。ロール内のタスクを選択またはスキップするには、個々のタスクまたはブロックにタグを設定し、Playbook で動的な ``include_role`` を使用して、同じタグをインクルードに追加する必要があります。この方法で ``--tags foo`` を付けて Playbook を実行すると、Ansible はインクルード自体に加えて、タグ ``foo`` を持つロール内のタスクを実行します。詳細は、「:ref:`tags_on_includes`」を参照してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:202 +msgid "When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds any tags you define to all the tasks in the role. For example:" +msgstr "``roles`` キーワードを使用して Playbook にロールを静的に組み込むと、Ansible は定義したタグをロール内のすべてのタスクに追加します。たとえば、以下のようになります。" + +#: ../../rst/user_guide/playbooks_tags.rst:212 +msgid "or:" +msgstr "または" + +#: ../../rst/user_guide/playbooks_tags.rst:229 +msgid "Adding tags to imports" +msgstr "インポートへのタグの追加" + +#: ../../rst/user_guide/playbooks_tags.rst:231 +msgid "You can also apply a tag or tags to all the tasks imported by the static ``import_role`` and ``import_tasks`` statements:" +msgstr "また、静的な ``import_role`` 文や ``import_tasks`` 文によりインポートされたすべてのタスクに、タグを適用することもできます。" + +#: ../../rst/user_guide/playbooks_tags.rst:252 +msgid "Tag inheritance for includes: blocks and the ``apply`` keyword" +msgstr "インクルードのタグ継承: ブロックおよび ``apply`` キーワード" + +#: ../../rst/user_guide/playbooks_tags.rst:254 +msgid "By default, Ansible does not apply :ref:`tag inheritance <tag_inheritance>` to dynamic re-use with ``include_role`` and ``include_tasks``. If you add tags to an include, they apply only to the include itself, not to any tasks in the included file or role. This allows you to execute selected tasks within a role or task file - see :ref:`selective_reuse` when you run your playbook." +msgstr "デフォルトでは、Ansible は :ref:`タグ継承 <tag_inheritance>` を適用せず、``include_role`` および ``include_tasks`` を使用した動的再利用を行います。タグをインクルードに追加すると、タグはインクルード自体にのみ適用され、インクルードしたファイルやロール内のタスクには適用されません。これにより、ロールやタスクファイル内の選択したタスクを実行することができます。Playbook を実行する際には、「:ref:`selective_reuse`」を参照してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:256 +msgid "If you want tag inheritance, you probably want to use imports. However, using both includes and imports in a single playbook can lead to difficult-to-diagnose bugs. For this reason, if your playbook uses ``include_*`` to re-use roles or tasks, and you need tag inheritance on one include, Ansible offers two workarounds. You can use the ``apply`` keyword:" +msgstr "タグの継承が必要な場合は、おそらくインポートを使用したいと思うでしょう。ただし、1 つの Playbook でインクルードとインポートの両方を使用すると、診断が困難なバグが発生する可能性があります。このような理由から、Playbook で ``include_*`` を使用してロールやタスクを再利用している場合に、1 つのインクルードでタグの継承が必要な場合、Ansible には 2 つの回避策があります。``apply`` キーワードを使用することができます。" + +#: ../../rst/user_guide/playbooks_tags.rst:269 +msgid "Or you can use a block:" +msgstr "または、以下のブロックを使用できます。" + +#: ../../rst/user_guide/playbooks_tags.rst:281 +msgid "Special tags: always and never" +msgstr "特別なタグ: always および never" + +#: ../../rst/user_guide/playbooks_tags.rst:283 +msgid "Ansible reserves two tag names for special behavior: always and never. If you assign the ``always`` tag to a task or play, Ansible will always run that task or play, unless you specifically skip it (``--skip-tags always``)." +msgstr "Ansible は、特別な動作のために、always と never という 2 つのタグ名を予約しています。``always`` タグをタスクやプレイに割り当てると、Ansible は特にスキップしない限り、常にそのタスクやプレイを実行します (``--skip-tags always``)。" + +#: ../../rst/user_guide/playbooks_tags.rst:303 +msgid "Fact gathering is tagged with 'always' by default. It is only skipped if you apply a tag and then use a different tag in ``--tags`` or the same tag in ``--skip-tags``." +msgstr "ファクト収集には、デフォルトで「always」というタグが付けられています。タグを適用した後、``--tags`` で別のタグを使用したり、``--skip-tags`` で同じタグを使用した場合に限りスキップされます。" + +#: ../../rst/user_guide/playbooks_tags.rst:308 +msgid "The role argument specification validation task is tagged with 'always' by default. This validation will be skipped if you use ``--skip-tags always``." +msgstr "ロールの引数の仕様検証タスクは、デフォルトで「always」でタグ付けされます。この検証は、``--skip-tags always`` を使用する場合に省略されます。" + +#: ../../rst/user_guide/playbooks_tags.rst:313 +msgid "If you assign the ``never`` tag to a task or play, Ansible will skip that task or play unless you specifically request it (``--tags never``)." +msgstr "``never`` タグをタスクまたはプレイに割り当てると、特に要求しない限り (``--tags never``)、Ansible はそのタスクまたはプレイをスキップします。" + +#: ../../rst/user_guide/playbooks_tags.rst:325 +msgid "The rarely-used debug task in the example above only runs when you specifically request the ``debug`` or ``never`` tags." +msgstr "上記の例では、ほとんど使用されないデバッグタスクは、``debug`` タグまたは ``never`` タグを特別に要求した場合にのみ実行します。" + +#: ../../rst/user_guide/playbooks_tags.rst:330 +msgid "Selecting or skipping tags when you run a playbook" +msgstr "Playbook の実行時にタグの選択または省略" + +#: ../../rst/user_guide/playbooks_tags.rst:332 +msgid "Once you have added tags to your tasks, includes, blocks, plays, roles, and imports, you can selectively execute or skip tasks based on their tags when you run :ref:`ansible-playbook`. Ansible runs or skips all tasks with tags that match the tags you pass at the command line. If you have added a tag at the block or play level, with ``roles``, or with an import, that tag applies to every task within the block, play, role, or imported role or file. If you have a role with lots of tags and you want to call subsets of the role at different times, either :ref:`use it with dynamic includes <selective_reuse>`, or split the role into multiple roles." +msgstr "タスク、インクルード、ブロック、プレイ、ロール、およびインポートにタグを追加したら、:ref:`ansible-playbook` を実行する際に、タグに基づいてタスクを選択的に実行またはスキップすることができます。Ansible は、コマンドラインで指定したタグと一致するタグを持つすべてのタスクを実行またはスキップします。ブロックやプレイのレベルで、``roles`` またはインポートを使用してタグを追加した場合、そのタグはブロック、プレイ、ロール、もしくはインポートされたロールまたはファイル内のすべてのタスクに適用されます。多くのタグを持つロールがあり、ロールのサブセットを異なるタイミングで呼び出したい場合は、:ref:`動的インクルードで使用する <selective_reuse>` か、ロールを複数のロールに分割してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:334 +msgid ":ref:`ansible-playbook` offers five tag-related command-line options:" +msgstr ":ref:`ansible-playbook` は、タグ関連のコマンドラインオプションを 5 つ提供します。" + +#: ../../rst/user_guide/playbooks_tags.rst:336 +msgid "``--tags all`` - run all tasks, ignore tags (default behavior)" +msgstr "``--tags all`` - すべてのタスクを実行し、タグを無視します (デフォルトの動作)。" + +#: ../../rst/user_guide/playbooks_tags.rst:337 +msgid "``--tags [tag1, tag2]`` - run only tasks with either the tag ``tag1`` or the tag ``tag2``" +msgstr "``--tags [tag1, tag2]`` - ``tag1`` タグまたは ``tag2`` タグのいずれかでのみタスクを実行します。" + +#: ../../rst/user_guide/playbooks_tags.rst:338 +msgid "``--skip-tags [tag3, tag4]`` - run all tasks except those with either the tag ``tag3`` or the tag ``tag4``" +msgstr "``--skip-tags [tag3, tag4]`` - ``tag3`` タグまたは ``tag4`` タグのいずれかが指定されたタスク以外のすべてのタスクを実行します。" + +#: ../../rst/user_guide/playbooks_tags.rst:339 +msgid "``--tags tagged`` - run only tasks with at least one tag" +msgstr "``--tags tagged`` - 1 つ以上のタグでタスクのみを実行します。" + +#: ../../rst/user_guide/playbooks_tags.rst:340 +msgid "``--tags untagged`` - run only tasks with no tags" +msgstr "``--tags untagged`` - タグなしでタスクのみを実行します。" + +#: ../../rst/user_guide/playbooks_tags.rst:342 +msgid "For example, to run only tasks and blocks tagged ``configuration`` and ``packages`` in a very long playbook:" +msgstr "たとえば、非常に長い Playbook で、タスクと、``configuration`` および ``packages`` のタグが付けられたブロックのみを実行するには、以下のコマンドを実行します。" + +#: ../../rst/user_guide/playbooks_tags.rst:348 +msgid "To run all tasks except those tagged ``packages``:" +msgstr "``packages`` のタグが付いたタスク以外のすべてのタスクを実行するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_tags.rst:355 +msgid "Previewing the results of using tags" +msgstr "タグの使用結果のプレビュー" + +#: ../../rst/user_guide/playbooks_tags.rst:357 +msgid "When you run a role or playbook, you might not know or remember which tasks have which tags, or which tags exist at all. Ansible offers two command-line flags for :ref:`ansible-playbook` that help you manage tagged playbooks:" +msgstr "ロールや Playbook を実行する際、どのタスクがどのタグを持っているのか、あるいはどのタグが存在するのかを知らない、あるいは覚えていない場合があります。Ansible では、タグ付き Playbookの管理に役立つ :ref:`ansible-playbook` にコマンドラインフラグを 2 つ提供しています。" + +#: ../../rst/user_guide/playbooks_tags.rst:359 +msgid "``--list-tags`` - generate a list of available tags" +msgstr "``--list-tags`` - 利用可能なタグのリストを生成します。" + +#: ../../rst/user_guide/playbooks_tags.rst:360 +msgid "``--list-tasks`` - when used with ``--tags tagname`` or ``--skip-tags tagname``, generate a preview of tagged tasks" +msgstr "``--list-tasks`` - ``--tags tagname`` または ``--skip-tags tagname`` と併用すると、タグ付けされたタスクのプレビューを生成します。" + +#: ../../rst/user_guide/playbooks_tags.rst:362 +msgid "For example, if you do not know whether the tag for configuration tasks is ``config`` or ``conf`` in a playbook, role, or tasks file, you can display all available tags without running any tasks:" +msgstr "たとえば、Playbook、ロール、またはタスクファイルの中で、設定タスクのタグが ``config`` か ``conf`` かがわからない場合は、タスクを実行せずに利用可能なタグをすべて表示することができます。" + +#: ../../rst/user_guide/playbooks_tags.rst:368 +msgid "If you do not know which tasks have the tags ``configuration`` and ``packages``, you can pass those tags and add ``--list-tasks``. Ansible lists the tasks but does not execute any of them." +msgstr "``configuration`` と ``packages`` のタグを持つタスクがわからない場合は、これらのタグを渡して ``--list-tasks`` を追加します。Ansible はタスクをリストアップしますが、実行はしません。" + +#: ../../rst/user_guide/playbooks_tags.rst:374 +msgid "These command-line flags have one limitation: they cannot show tags or tasks within dynamically included files or roles. See :ref:`dynamic_vs_static` for more information on differences between static imports and dynamic includes." +msgstr "これらのコマンドラインフラグには、動的インクルードされたファイルやロール内のタグやタスクを表示することができないという制限があります。静的インポートと動的インクルードの違いについての詳細は、「:ref:`dynamic_vs_static`」を参照してください。" + +#: ../../rst/user_guide/playbooks_tags.rst:379 +msgid "Selectively running tagged tasks in re-usable files" +msgstr "再利用可能なファイルでタグ付けされたタスクを選択的に実行" + +#: ../../rst/user_guide/playbooks_tags.rst:381 +msgid "If you have a role or a tasks file with tags defined at the task or block level, you can selectively run or skip those tagged tasks in a playbook if you use a dynamic include instead of a static import. You must use the same tag on the included tasks and on the include statement itself. For example you might create a file with some tagged and some untagged tasks:" +msgstr "タスクやブロックのレベルでタグが定義されているロールやタスクファイルがある場合は、静的インポートの代わりに動的インクルードを使用すると、Playbook 内のタグ付きタスクを選択的に実行したりスキップしたりすることができます。インクルードされるタスクと include 文自体には、同じタグを使用する必要があります。たとえば、タグ付きのタスクとタグなしのタスクを含むファイルを作成する場合は、以下のようになります。" + +#: ../../rst/user_guide/playbooks_tags.rst:404 +msgid "And you might include the tasks file above in a playbook:" +msgstr "また、Playbook に上記のタスクファイルを含めることができます。" + +#: ../../rst/user_guide/playbooks_tags.rst:416 +msgid "When you run the playbook with ``ansible-playbook -i hosts myplaybook.yml --tags \"mytag\"``, Ansible skips the task with no tags, runs the tagged individual task, and runs the two tasks in the block." +msgstr "``ansible-playbook -i hosts myplaybook.yml --tags \"mytag\"`` を使用して Playbook を実行すると、Ansible はタグのないタスクを省略し、タグ付けされた個別のタスクを実行し、ブロック内の 2 つのタスクを実行します。" + +#: ../../rst/user_guide/playbooks_tags.rst:419 +msgid "Configuring tags globally" +msgstr "タグのグローバル設定" + +#: ../../rst/user_guide/playbooks_tags.rst:421 +msgid "If you run or skip certain tags by default, you can use the :ref:`TAGS_RUN` and :ref:`TAGS_SKIP` options in Ansible configuration to set those defaults." +msgstr "デフォルトで特定のタグを実行するか、スキップする場合は、Ansible 設定で :ref:`TAGS_RUN` オプションおよび :ref:`TAGS_SKIP` オプションを使用してこれらのデフォルトを設定できます。" + +#: ../../rst/user_guide/playbooks_templating.rst:5 +msgid "Templating (Jinja2)" +msgstr "テンプレート作成 (Jinja2)" + +#: ../../rst/user_guide/playbooks_templating.rst:7 +msgid "Ansible uses Jinja2 templating to enable dynamic expressions and access to :ref:`variables <playbooks_variables>` and :ref:`facts <vars_and_facts>`. You can use templating with the :ref:`template module <template_module>`. For example, you can create a template for a configuration file, then deploy that configuration file to multiple environments and supply the correct data (IP address, hostname, version) for each environment. You can also use templating in playbooks directly, by templating task names and more. You can use all the :ref:`standard filters and tests <jinja2:builtin-filters>` included in Jinja2. Ansible includes additional specialized filters for selecting and transforming data, tests for evaluating template expressions, and :ref:`lookup_plugins` for retrieving data from external sources such as files, APIs, and databases for use in templating." +msgstr "Ansible は Jinja2 テンプレートを使用して動的な式を有効にし、:ref:`variables <playbooks_variables>` および :ref:`facts <vars_and_facts>` へのアクセスを有効にします。:ref:`template module <template_module>` でテンプレートを使用できます。たとえば、設定ファイルのテンプレートを作成してから、その設定ファイルを複数の環境にデプロイし、各環境に対して適切なデータ（IP アドレス、ホスト名、バージョン）を指定できます。 タスク名などをテンプレート化することで、Playbook でテンプレートを直接使用することもできます。Jinja2 に含まれるすべての :ref:`standard filters and tests <jinja2:builtin-filters>` を使用できます。Ansible には、データを選択および変換するための追加の特殊なフィルター、テンプレート式の評価のテスト、テンプレートで使用するファイル、API、データベースなどの外部ソースからデータを取得するための :ref:`lookup_plugins` が含まれています。" + +#: ../../rst/user_guide/playbooks_templating.rst:9 +msgid "All templating happens on the Ansible controller **before** the task is sent and executed on the target machine. This approach minimizes the package requirements on the target (jinja2 is only required on the controller). It also limits the amount of data Ansible passes to the target machine. Ansible parses templates on the controller and passes only the information needed for each task to the target machine, instead of passing all the data on the controller and parsing it on the target." +msgstr "テンプレート化はすべて、タスクが送信されターゲットマシンで実行する **前** に、Ansible のコントローラーで行われます。このアプローチにより、ターゲットでのパッケージ要件を最小限に抑えることができます (jinja2 はコントローラーでのみ必要です)。また、Ansible がターゲットマシンに渡すデータの量も制限されます。Ansible は、コントローラーですべてのデータを渡してターゲットで解析するのではなく、コントローラーでテンプレートを解析し、各タスクに必要な情報だけをターゲットマシンに渡します。" + +#: ../../rst/user_guide/playbooks_templating.rst:13 +msgid "Files and data used by the :ref:`template module <template_module>` must be utf-8 encoded." +msgstr ":ref:`template module <template_module>` で使用されるファイルおよびデータは utf-8 エンコードされている必要があります。" + +#: ../../rst/user_guide/playbooks_templating.rst:29 +msgid "Get the current time" +msgstr "現在の時間を取得" + +#: ../../rst/user_guide/playbooks_templating.rst:33 +msgid "The ``now()`` Jinja2 function retrieves a Python datetime object or a string representation for the current time." +msgstr "Jinja2 関数 ``now()`` は、Python の datetime オブジェクトまたは現在の時間を表す文字列を取得します。" + +#: ../../rst/user_guide/playbooks_templating.rst:35 +msgid "The ``now()`` function supports 2 arguments:" +msgstr "``now()`` 関数は、2 つの引数をサポートします。" + +#: ../../rst/user_guide/playbooks_templating.rst:38 +msgid "utc" +msgstr "utc" + +#: ../../rst/user_guide/playbooks_templating.rst:38 +msgid "Specify ``True`` to get the current time in UTC. Defaults to ``False``." +msgstr "UTC で現在の時間を取得するには、``True`` を指定します。デフォルトは ``False`` です。" + +#: ../../rst/user_guide/playbooks_templating.rst:42 +msgid "fmt" +msgstr "fmt" + +#: ../../rst/user_guide/playbooks_templating.rst:41 +msgid "Accepts a `strftime <https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior>`_ string that returns a formatted date time string." +msgstr "`strftime <https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior>`_ の文字列を受け取り、形式化された日時文字列を返します。" + +#: ../../rst/user_guide/playbooks_templating.rst:56 +msgid "`Jinja2 Docs <https://jinja.palletsprojects.com/en/latest/templates/>`_" +msgstr "`Jinja2 Docs <https://jinja.palletsprojects.com/en/latest/templates/>`_" + +#: ../../rst/user_guide/playbooks_templating.rst:57 +msgid "Jinja2 documentation, includes the syntax and semantics of the templates" +msgstr "Jinja2 ドキュメント（テンプレートの構文およびセマンティクスを含む）" + +#: ../../rst/user_guide/playbooks_tests.rst:5 +msgid "Tests" +msgstr "テスト" + +#: ../../rst/user_guide/playbooks_tests.rst:7 +msgid "`Tests <https://jinja.palletsprojects.com/en/latest/templates/#tests>`_ in Jinja are a way of evaluating template expressions and returning True or False. Jinja ships with many of these. See `builtin tests`_ in the official Jinja template documentation." +msgstr "Jinja の `Tests <https://jinja.palletsprojects.com/en/latest/templates/#tests>`_ は、テンプレート式を評価して、True または False を返します。Jinja にはこれらの多くが同梱されています。Jinja の公式テンプレートドキュメントの「`builtin tests`_」をご覧ください。" + +#: ../../rst/user_guide/playbooks_tests.rst:9 +msgid "The main difference between tests and filters are that Jinja tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in jinja. Tests can also be used in list processing filters, like ``map()`` and ``select()`` to choose items in the list." +msgstr "テストとフィルターの主な違いは、Jinja のテストは比較に使用されるのに対し、フィルターはデータ操作に使用され、Jinja では用途が異なります。テストは、``map()`` や ``select()`` のように、リスト内の項目を選択するリスト処理フィルターにも使用できます。" + +#: ../../rst/user_guide/playbooks_tests.rst:11 +msgid "Like all templating, tests always execute on the Ansible controller, **not** on the target of a task, as they test local data." +msgstr "すべてのテンプレートと同様、テストは常に、ローカルデータをテストする際にタスクのターゲットでは **なく**、Ansible コントローラーで実行されます。" + +#: ../../rst/user_guide/playbooks_tests.rst:13 +msgid "In addition to those Jinja2 tests, Ansible supplies a few more and users can easily create their own." +msgstr "このような Jinja2 テストに加えて、Ansible はより多くのものを提供しており、ユーザーは独自のテストを簡単に作成できます。" + +#: ../../rst/user_guide/playbooks_tests.rst:21 +msgid "Test syntax" +msgstr "テストの構文" + +#: ../../rst/user_guide/playbooks_tests.rst:23 +msgid "`Test syntax <https://jinja.palletsprojects.com/en/latest/templates/#tests>`_ varies from `filter syntax <https://jinja.palletsprojects.com/en/latest/templates/#filters>`_ (``variable | filter``). Historically Ansible has registered tests as both jinja tests and jinja filters, allowing for them to be referenced using filter syntax." +msgstr "`テストの構文 <https://jinja.palletsprojects.com/en/latest/templates/#tests>` は、`フィルターの構文 <https://jinja.palletsprojects.com/en/latest/templates/#filters>`_ (``variable | filter``) と異なります。これまで Ansible は、テストを jinja テストと jinja フィルターの両方に登録し、filter 構文を使用して参照できるようにしてきました。" + +#: ../../rst/user_guide/playbooks_tests.rst:25 +msgid "As of Ansible 2.5, using a jinja test as a filter will generate a deprecation warning. As of Ansible 2.9+ using jinja test syntax is required." +msgstr "Ansible 2.5 の時点では、jinja テストをフィルターとして使用すると非推奨に関する警告が生成されます。Ansible 2.9 以降では、jinja テスト構文を使用する必要があります。" + +#: ../../rst/user_guide/playbooks_tests.rst:27 +msgid "The syntax for using a jinja test is as follows" +msgstr "jinja テストを使用するための構文は、以下のとおりです。" + +#: ../../rst/user_guide/playbooks_tests.rst:33 +msgid "Such as" +msgstr "例:" + +#: ../../rst/user_guide/playbooks_tests.rst:42 +msgid "Testing strings" +msgstr "文字列のテスト" + +#: ../../rst/user_guide/playbooks_tests.rst:44 +msgid "To match strings against a substring or a regular expression, use the ``match``, ``search`` or ``regex`` tests" +msgstr "サブ文字列または正規表現に対して文字列と一致させるには、「``match``」、「``search``」、または「``regex``」を使用します。" + +#: ../../rst/user_guide/playbooks_tests.rst:68 +msgid "``match`` succeeds if it finds the pattern at the beginning of the string, while ``search`` succeeds if it finds the pattern anywhere within string. By default, ``regex`` works like ``search``, but ``regex`` can be configured to perform other tests as well, by passing the ``match_type`` keyword argument. In particular, ``match_type`` determines the ``re`` method that gets used to perform the search. The full list can be found in the relevant Python documentation `here <https://docs.python.org/3/library/re.html#regular-expression-objects>`_." +msgstr "``match`` は、文字列の先頭でパターンを見つけた場合に成功し、``search`` は、文字列内の任意の場所でパターンを見つけた場合に成功します。デフォルトでは、``regex`` は ``search`` のように動作しますが、``regex`` は ``match_type`` キーワード引数を渡すことで、他のテストも実行するように構成することができます。特に、``match_type`` は、検索を実行する際に使用される ``re`` メソッドを決定します。完全なリストは、`こちら <https://docs.python.org/3/library/re.html#regular-expression-objects>`_ にある関連 Python ドキュメントを参照してください。" + +#: ../../rst/user_guide/playbooks_tests.rst:70 +msgid "All of the string tests also take optional ``ignorecase`` and ``multiline`` arguments. These correspond to ``re.I`` and ``re.M`` from Python's ``re`` library, respectively." +msgstr "すべての文字列テストは、任意の ``ignorecase`` 引数および ``multiline`` 引数を取ります。これらは、Python の ``re`` ライブラリーからそれぞれ ``re.I`` および ``re.M`` に対応します。" + +#: ../../rst/user_guide/playbooks_tests.rst:75 +msgid "Vault" +msgstr "Vault" + +#: ../../rst/user_guide/playbooks_tests.rst:79 +msgid "You can test whether a variable is an inline single vault encrypted value using the ``vault_encrypted`` test." +msgstr "変数がインラインの 1 つの vault で暗号化された値であるかどうかは、``vault_encrypted`` テストでテストできます。" + +#: ../../rst/user_guide/playbooks_tests.rst:99 +msgid "Testing truthiness" +msgstr "真偽の検証" + +#: ../../rst/user_guide/playbooks_tests.rst:103 +msgid "As of Ansible 2.10, you can now perform Python like truthy and falsy checks." +msgstr "Ansible 2.10 以降では、Python を真偽チェックのように実行できるようになりました。" + +#: ../../rst/user_guide/playbooks_tests.rst:119 +msgid "Additionally, the ``truthy`` and ``falsy`` tests accept an optional parameter called ``convert_bool`` that will attempt to convert boolean indicators to actual booleans." +msgstr "また、``truthy`` テストおよび ``falsy`` テストは、ブール値インジケーターを実際のブール値に変換しようとする ``convert_bool`` と呼ばれる任意のパラメーターを受け入れます。" + +#: ../../rst/user_guide/playbooks_tests.rst:139 +msgid "Comparing versions" +msgstr "バージョンの比較" + +#: ../../rst/user_guide/playbooks_tests.rst:143 +msgid "In 2.5 ``version_compare`` was renamed to ``version``" +msgstr "2.5 では、``version_compare`` の名前が ``version`` に変更されました。" + +#: ../../rst/user_guide/playbooks_tests.rst:145 +msgid "To compare a version number, such as checking if the ``ansible_facts['distribution_version']`` version is greater than or equal to '12.04', you can use the ``version`` test." +msgstr "``ansible_facts['distribution_version']`` のバージョンが「12.04」以上かどうかを確認するなど、バージョン番号を比較するには、``version`` テストを使用します。" + +#: ../../rst/user_guide/playbooks_tests.rst:148 +msgid "The ``version`` test can also be used to evaluate the ``ansible_facts['distribution_version']``" +msgstr "``version`` テストを使用して ``ansible_facts['distribution_version']`` を評価することもできます。" + +#: ../../rst/user_guide/playbooks_tests.rst:154 +msgid "If ``ansible_facts['distribution_version']`` is greater than or equal to 12.04, this test returns True, otherwise False." +msgstr "``ansible_facts['distribution_version']`` が 12.04 以上の場合は、このテストで True が返り、それ以外の場合は False が返ります。" + +#: ../../rst/user_guide/playbooks_tests.rst:156 +msgid "The ``version`` test accepts the following operators" +msgstr "``version`` テストでは、以下の演算子を受け入れます。" + +#: ../../rst/user_guide/playbooks_tests.rst:162 +msgid "This test also accepts a 3rd parameter, ``strict`` which defines if strict version parsing as defined by ``ansible.module_utils.compat.version.StrictVersion`` should be used. The default is ``False`` (using ``ansible.module_utils.compat.version.LooseVersion``), ``True`` enables strict version parsing" +msgstr "このテストは、3 番目のパラメーター ``strict`` も受け入れます。これは、``ansible.module_utils.compat.version.StrictVersion`` で定義された厳格なバージョン解析機能を使用できます。デフォルトは ``False`` (``ansible.module_utils.compat.version.LooseVersion`` を使用) で、``True`` は、厳格なバージョン解析を有効にします。" + +#: ../../rst/user_guide/playbooks_tests.rst:168 +msgid "As of Ansible 2.11 the ``version`` test accepts a ``version_type`` parameter which is mutually exclusive with ``strict``, and accepts the following values" +msgstr "Ansible 2.11 の時点で、``version`` テストは ``strict`` と相互に排他的な ``version_type`` パラメーターを受け入れ、以下の値を受け入れます。" + +#: ../../rst/user_guide/playbooks_tests.rst:174 +msgid "Using ``version_type`` to compare a semantic version would be achieved like the following" +msgstr "``version_type`` を使用してセマンティックバージョンを比較すると、以下のように実行されます。" + +#: ../../rst/user_guide/playbooks_tests.rst:180 +msgid "When using ``version`` in a playbook or role, don't use ``{{ }}`` as described in the `FAQ <https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#when-should-i-use-also-how-to-interpolate-variables-or-dynamic-variable-names>`_" +msgstr "Playbook またはロールで ``version`` を使用する場合は、`FAQ <https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#when-should-i-use-also-how-to-interpolate-variables-or-dynamic-variable-names>`_ で説明されているように ``{{ }}`` を使用しないでください。" + +#: ../../rst/user_guide/playbooks_tests.rst:195 +msgid "Set theory tests" +msgstr "セット理論テスト" + +#: ../../rst/user_guide/playbooks_tests.rst:199 +msgid "In 2.5 ``issubset`` and ``issuperset`` were renamed to ``subset`` and ``superset``" +msgstr "2.5 では、``issubset`` および ``issuperset`` の名前が ``subset`` および ``superset`` に変更されました。" + +#: ../../rst/user_guide/playbooks_tests.rst:201 +msgid "To see if a list includes or is included by another list, you can use 'subset' and 'superset'" +msgstr "リストに別のリストが含まれているか、またはリストが別のリストに含まれているかを確認するには、「subset」および「superset」を使用します。" + +#: ../../rst/user_guide/playbooks_tests.rst:220 +msgid "Testing if a list contains a value" +msgstr "リストに値が含まれるかどうかのテスト" + +#: ../../rst/user_guide/playbooks_tests.rst:224 +msgid "Ansible includes a ``contains`` test which operates similarly, but in reverse of the Jinja2 provided ``in`` test. The ``contains`` test is designed to work with the ``select``, ``reject``, ``selectattr``, and ``rejectattr`` filters" +msgstr "Ansible には、Jinja2 が提供する ``in`` テストとは逆に、同様の動作をする ``contains`` テストが含まれています。``contains`` テストは、フィルターの ``select``、``reject``、``selectattr``、および ``rejectattr`` で動作するように設計されています。" + +#: ../../rst/user_guide/playbooks_tests.rst:256 +msgid "Testing if a list value is True" +msgstr "リスト値が True の場合のテスト" + +#: ../../rst/user_guide/playbooks_tests.rst:260 +msgid "You can use `any` and `all` to check if any or all elements in a list are true or not" +msgstr "`any` および `all` を使用して、リスト内の一部またはすべての要素が true かどうかを確認できます。" + +#: ../../rst/user_guide/playbooks_tests.rst:285 +msgid "Testing paths" +msgstr "パスのテスト" + +#: ../../rst/user_guide/playbooks_tests.rst:287 +msgid "In 2.5 the following tests were renamed to remove the ``is_`` prefix" +msgstr "2.5 では、以下のテストの名前が変更になり、``is_`` プレフィックスが削除されました。" + +#: ../../rst/user_guide/playbooks_tests.rst:289 +msgid "The following tests can provide information about a path on the controller" +msgstr "以下のテストは、コントローラー上のパスに関する情報を提供します。" + +#: ../../rst/user_guide/playbooks_tests.rst:332 +msgid "Testing size formats" +msgstr "サイズ形式のテスト" + +#: ../../rst/user_guide/playbooks_tests.rst:334 +msgid "The ``human_readable`` and ``human_to_bytes`` functions let you test your playbooks to make sure you are using the right size format in your tasks, and that you provide Byte format to computers and human-readable format to people." +msgstr "``human_readable`` 関数および ``human_to_bytes`` 関数を使用すると、Playbook をテストして、タスクで適切なサイズの形式を使用しているかどうか、また、コンピューターにはバイト形式、およびユーザーには人間が判読可能な形式を提供しているかどうかを確認することができます。" + +#: ../../rst/user_guide/playbooks_tests.rst:339 +msgid "Human readable" +msgstr "人間が読み取り可能" + +#: ../../rst/user_guide/playbooks_tests.rst:341 +msgid "Asserts whether the given string is human readable or not." +msgstr "指定の文字列が人が判読できるかどうかをアサートします。" + +#: ../../rst/user_guide/playbooks_tests.rst:343 +#: ../../rst/user_guide/playbooks_tests.rst:368 +msgid "For example" +msgstr "たとえば、以下のようになります。" + +#: ../../rst/user_guide/playbooks_tests.rst:357 +#: ../../rst/user_guide/playbooks_tests.rst:384 +msgid "This would result in" +msgstr "これにより、以下のようになります。" + +#: ../../rst/user_guide/playbooks_tests.rst:364 +msgid "Human to bytes" +msgstr "人間からバイト" + +#: ../../rst/user_guide/playbooks_tests.rst:366 +msgid "Returns the given string in the Bytes format." +msgstr "指定した文字列をバイト形式で返します。" + +#: ../../rst/user_guide/playbooks_tests.rst:394 +msgid "Testing task results" +msgstr "タスク結果のテスト" + +#: ../../rst/user_guide/playbooks_tests.rst:396 +msgid "The following tasks are illustrative of the tests meant to check the status of tasks" +msgstr "以下のタスクは、タスクのステータスを確認するためのテストを示しています。" + +#: ../../rst/user_guide/playbooks_tests.rst:427 +msgid "From 2.1, you can also use success, failure, change, and skip so that the grammar matches, for those who need to be strict about it." +msgstr "2.1 以降、文法を厳密にする必要がある場合に、success、failure、change、および skip を使用して、文法が一致するようにすることもできます。" + +#: ../../rst/user_guide/playbooks_tests.rst:432 +msgid "Type Tests" +msgstr "タイプテスト" + +#: ../../rst/user_guide/playbooks_tests.rst:434 +msgid "When looking to determine types, it may be tempting to use the ``type_debug`` filter and compare that to the string name of that type, however, you should instead use type test comparisons, such as:" +msgstr "タイプを決定する際には、``type_debug`` フィルターを使用して、そのタイプの文字列名と比較したくなるかもしれません。しかし、代わりに以下のようなタイプテストの比較を使用する必要があります。" + +#: ../../rst/user_guide/playbooks_variables.rst:5 +msgid "Using Variables" +msgstr "変数の使用" + +#: ../../rst/user_guide/playbooks_variables.rst:7 +msgid "Ansible uses variables to manage differences between systems. With Ansible, you can execute tasks and playbooks on multiple different systems with a single command. To represent the variations among those different systems, you can create variables with standard YAML syntax, including lists and dictionaries. You can define these variables in your playbooks, in your :ref:`inventory <intro_inventory>`, in re-usable :ref:`files <playbooks_reuse>` or :ref:`roles <playbooks_reuse_roles>`, or at the command line. You can also create variables during a playbook run by registering the return value or values of a task as a new variable." +msgstr "Ansible は変数を使用してシステム間の違いを管理します。Ansible では、1 つのコマンドで複数の異なるシステム上でタスクや Playbook を実行することができます。これらの異なるシステム間の差異を表現するために、リストやディクショナリーなどの標準的な YAML 構文で変数を作成できます。これらの変数は、Playbook、:ref:`インベントリー <intro_inventory>`、再利用可能な :ref:`ファイル <playbooks_reuse>`、または :ref:`ロール <playbooks_reuse_roles>`、もしくはコマンドラインで定義できます。また、タスクの戻り値を新しい変数として登録することで、Playbook の実行中に変数を作成することもできます。" + +#: ../../rst/user_guide/playbooks_variables.rst:9 +msgid "After you create variables, either by defining them in a file, passing them at the command line, or registering the return value or values of a task as a new variable, you can use those variables in module arguments, in :ref:`conditional \"when\" statements <playbooks_conditionals>`, in :ref:`templates <playbooks_templating>`, and in :ref:`loops <playbooks_loops>`. The `ansible-examples github repository <https://github.com/ansible/ansible-examples>`_ contains many examples of using variables in Ansible." +msgstr "ファイルで定義したり、コマンドラインで渡したり、タスクの戻り値を新しい変数として登録したりして変数を作成した後は、その変数をモジュールの引数、:ref:`条件分岐の「when」文 <playbooks_conditionals>`、:ref:`テンプレート <playbooks_templating>`、および :ref:`ループ <playbooks_loops>` で使用することができます。`ansible-examples github リポジトリー <https://github.com/ansible/ansible-examples>`_ には、Ansible での変数の使用例が多数掲載されています。" + +#: ../../rst/user_guide/playbooks_variables.rst:11 +msgid "Once you understand the concepts and examples on this page, read about :ref:`Ansible facts <vars_and_facts>`, which are variables you retrieve from remote systems." +msgstr "このページの概念と例を理解したら、リモートシステムから取得する変数である :ref:`Ansible ファクト <vars_and_facts>` を確認します。" + +#: ../../rst/user_guide/playbooks_variables.rst:19 +msgid "Creating valid variable names" +msgstr "有効な変数名の作成" + +#: ../../rst/user_guide/playbooks_variables.rst:21 +msgid "Not all strings are valid Ansible variable names. A variable name can only include letters, numbers, and underscores. `Python keywords`_ or :ref:`playbook keywords<playbook_keywords>` are not valid variable names. A variable name cannot begin with a number." +msgstr "すべての文字列が有効な Ansible の変数名になるわけではありません。変数名には、文字、数字、アンダースコアのみを含めることができます。`Python キーワード`_ または :ref:`playbook キーワード<playbook_keywords>` は有効な変数名ではありません。変数名は、数字で始めることはできません。" + +#: ../../rst/user_guide/playbooks_variables.rst:23 +msgid "Variable names can begin with an underscore. In many programming languages, variables that begin with an underscore are private. This is not true in Ansible. Variables that begin with an underscore are treated exactly the same as any other variable. Do not rely on this convention for privacy or security." +msgstr "変数名はアンダースコアで始めることができます。多くのプログラミング言語では、アンダースコアで始まる変数はプライベートです。Ansible ではこれは当てはまりません。アンダースコアで始まる変数は、他の変数とまったく同じように扱われます。プライバシーやセキュリティーのために、この規約に依存しないでください。" + +#: ../../rst/user_guide/playbooks_variables.rst:25 +msgid "This table gives examples of valid and invalid variable names:" +msgstr "この表は、有効かつ無効な変数名の例を紹介します。" + +#: ../../rst/user_guide/playbooks_variables.rst:31 +msgid "Valid variable names" +msgstr "有効な変数名" + +#: ../../rst/user_guide/playbooks_variables.rst:31 +msgid "Not valid" +msgstr "有効ではない" + +#: ../../rst/user_guide/playbooks_variables.rst:33 +msgid "``foo``" +msgstr "``foo``" + +#: ../../rst/user_guide/playbooks_variables.rst:33 +msgid "``*foo``, `Python keywords`_ such as ``async`` and ``lambda``" +msgstr "``*foo``、`Python キーワード`_ (``async``、``lambda`` など)" + +#: ../../rst/user_guide/playbooks_variables.rst:35 +msgid "``foo_env``" +msgstr "``foo_env``" + +#: ../../rst/user_guide/playbooks_variables.rst:35 +msgid ":ref:`playbook keywords<playbook_keywords>` such as ``environment``" +msgstr "``environment`` などの :ref:`playbook キーワード<playbook_keywords>`" + +#: ../../rst/user_guide/playbooks_variables.rst:37 +msgid "``foo_port``" +msgstr "``foo_port``" + +#: ../../rst/user_guide/playbooks_variables.rst:37 +msgid "``foo-port``, ``foo port``, ``foo.port``" +msgstr "``foo-port``、``foo port``、``foo.port``" + +#: ../../rst/user_guide/playbooks_variables.rst:39 +msgid "``foo5``, ``_foo``" +msgstr "``foo5``、``_foo``" + +#: ../../rst/user_guide/playbooks_variables.rst:39 +msgid "``5foo``, ``12``" +msgstr "``5foo``、``12``" + +#: ../../rst/user_guide/playbooks_variables.rst:45 +msgid "Simple variables" +msgstr "単純な変数" + +#: ../../rst/user_guide/playbooks_variables.rst:47 +msgid "Simple variables combine a variable name with a single value. You can use this syntax (and the syntax for lists and dictionaries shown below) in a variety of places. For details about setting variables in inventory, in playbooks, in reusable files, in roles, or at the command line, see :ref:`setting_variables`." +msgstr "単純変数は、変数名と 1 つの値を組み合わせたものです。この構文 (および後述のリストやディレクトリーの構文) は、さまざまな場所で使用できます。インベントリー、Playbook、再利用可能なファイル、ロール、コマンドラインでの変数設定の詳細については、「:ref:`setting_variables`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:50 +msgid "Defining simple variables" +msgstr "簡単な変数の定義" + +#: ../../rst/user_guide/playbooks_variables.rst:52 +msgid "You can define a simple variable using standard YAML syntax. For example:" +msgstr "標準の YAML 構文を使用して単純な変数を定義できます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:59 +msgid "Referencing simple variables" +msgstr "単純な変数の参照" + +#: ../../rst/user_guide/playbooks_variables.rst:61 +msgid "After you define a variable, use Jinja2 syntax to reference it. Jinja2 variables use double curly braces. For example, the expression ``My amp goes to {{ max_amp_value }}`` demonstrates the most basic form of variable substitution. You can use Jinja2 syntax in playbooks. For example:" +msgstr "変数を定義した後は、Jinja2 の構文を使用して変数を参照します。Jinja2 の変数には二重の中括弧が使用されます。たとえば、``My amp goes to {{ max_amp_value }}`` という式は、最も基本的な形の変数置換を示しています。Playbook では、Jinja2 構文を使用できます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:69 +msgid "In this example, the variable defines the location of a file, which can vary from one system to another." +msgstr "この例では、変数がファイルの場所を定義していますが、これはシステムごとに異なる可能性があります。" + +#: ../../rst/user_guide/playbooks_variables.rst:73 +msgid "Ansible allows Jinja2 loops and conditionals in :ref:`templates <playbooks_templating>` but not in playbooks. You cannot create a loop of tasks. Ansible playbooks are pure machine-parseable YAML." +msgstr "Ansible では、:ref:`テンプレート <playbooks_templating>` で Jinja2 のループや条件分岐を使用できますが、Playbook では使用できません。タスクのループを作成することはできません。Ansible の Playbook は純粋に機械で解析可能な YAML です。" + +#: ../../rst/user_guide/playbooks_variables.rst:78 +msgid "When to quote variables (a YAML gotcha)" +msgstr "変数を引用するタイミング (YAML に関する注意点)" + +#: ../../rst/user_guide/playbooks_variables.rst:80 +msgid "If you start a value with ``{{ foo }}``, you must quote the whole expression to create valid YAML syntax. If you do not quote the whole expression, the YAML parser cannot interpret the syntax - it might be a variable or it might be the start of a YAML dictionary. For guidance on writing YAML, see the :ref:`yaml_syntax` documentation." +msgstr "値を ``{{ foo }}`` で始めた場合、有効な YAML 構文を作成するためには式全体を引用しなければなりません。式全体を引用符で囲まないと、YAML パーサーはその構文を解釈できません。それは変数かもしれないし、YAML ディレクトリーの始まりかもしれません。YAML の記述方法については、「:ref:`yaml_syntax`」のドキュメントを参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:82 +msgid "If you use a variable without quotes like this:" +msgstr "引用符なしの変数を使用する場合は、以下のようになります。" + +#: ../../rst/user_guide/playbooks_variables.rst:90 +msgid "You will see: ``ERROR! Syntax Error while loading YAML.`` If you add quotes, Ansible works correctly:" +msgstr "``ERROR! Syntax Error while loading YAML.`` を参照してください。引用符を追加すると、Ansible が正常に機能します。" + +#: ../../rst/user_guide/playbooks_variables.rst:101 +msgid "List variables" +msgstr "リスト変数" + +#: ../../rst/user_guide/playbooks_variables.rst:103 +msgid "A list variable combines a variable name with multiple values. The multiple values can be stored as an itemized list or in square brackets ``[]``, separated with commas." +msgstr "リスト変数は、変数名と複数の値を組み合わせたものです。複数の値は、項目別のリストとして、または角括弧 ``[]`` の中にコンマで区切って格納できます。" + +#: ../../rst/user_guide/playbooks_variables.rst:106 +msgid "Defining variables as lists" +msgstr "変数をリストとして定義" + +#: ../../rst/user_guide/playbooks_variables.rst:108 +msgid "You can define variables with multiple values using YAML lists. For example:" +msgstr "YAML リストを使用して、複数の値で変数を定義できます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:118 +msgid "Referencing list variables" +msgstr "リスト変数の参照" + +#: ../../rst/user_guide/playbooks_variables.rst:120 +msgid "When you use variables defined as a list (also called an array), you can use individual, specific fields from that list. The first item in a list is item 0, the second item is item 1. For example:" +msgstr "リスト (配列とも呼ばれる) として定義された変数を使用する場合は、そのリストから個々の特定のフィールドを使用することができます。リストの最初の項目は項目 0、2 番目の項目は項目 1 です。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:126 +msgid "The value of this expression would be \"northeast\"." +msgstr "この式の値は「northeast」になります。" + +#: ../../rst/user_guide/playbooks_variables.rst:131 +msgid "Dictionary variables" +msgstr "ディクショナリー変数" + +#: ../../rst/user_guide/playbooks_variables.rst:133 +msgid "A dictionary stores the data in key-value pairs. Usually, dictionaries are used to store related data, such as the information contained in an ID or a user profile." +msgstr "ディクショナリーは、データをキーと値のペアに保存します。通常、ディクショナリーは ID またはユーザープロファイルに含まれる情報などの関連データを保存するために使用されます。" + +#: ../../rst/user_guide/playbooks_variables.rst:136 +msgid "Defining variables as key:value dictionaries" +msgstr "変数を key:value ディクショナリーとして定義" + +#: ../../rst/user_guide/playbooks_variables.rst:138 +msgid "You can define more complex variables using YAML dictionaries. A YAML dictionary maps keys to values. For example:" +msgstr "YAML ディクショナリーを使用してより複雑な変数を定義できます。YAML ディクショナリーはキーを値にマッピングします。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:147 +msgid "Referencing key:value dictionary variables" +msgstr "key:value ディクショナリー変数の参照" + +#: ../../rst/user_guide/playbooks_variables.rst:149 +msgid "When you use variables defined as a key:value dictionary (also called a hash), you can use individual, specific fields from that dictionary using either bracket notation or dot notation:" +msgstr "key:value ディクショナリー (ハッシュとも呼ばれます) として定義された変数を使用する場合は、括弧表記またはドット表記のいずれかを使用して、そのディクショナリーの個々の特定のフィールドを使用できます。" + +#: ../../rst/user_guide/playbooks_variables.rst:156 +msgid "Both of these examples reference the same value (\"one\"). Bracket notation always works. Dot notation can cause problems because some keys collide with attributes and methods of python dictionaries. Use bracket notation if you use keys which start and end with two underscores (which are reserved for special meanings in python) or are any of the known public attributes:" +msgstr "これらの例では、どちらも同じ値 (「one」) を参照しています。括弧表記は常に有効です。ドット表記では、一部のキーが python ディクショナリーの属性やメソッドと衝突するため、問題が生じます。2 つのアンダースコアで始まって終わるキー (python では特別な意味を持つものとして予約されています) や、既知の公開属性を使用する場合は、括弧表記を使用してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:158 +msgid "``add``, ``append``, ``as_integer_ratio``, ``bit_length``, ``capitalize``, ``center``, ``clear``, ``conjugate``, ``copy``, ``count``, ``decode``, ``denominator``, ``difference``, ``difference_update``, ``discard``, ``encode``, ``endswith``, ``expandtabs``, ``extend``, ``find``, ``format``, ``fromhex``, ``fromkeys``, ``get``, ``has_key``, ``hex``, ``imag``, ``index``, ``insert``, ``intersection``, ``intersection_update``, ``isalnum``, ``isalpha``, ``isdecimal``, ``isdigit``, ``isdisjoint``, ``is_integer``, ``islower``, ``isnumeric``, ``isspace``, ``issubset``, ``issuperset``, ``istitle``, ``isupper``, ``items``, ``iteritems``, ``iterkeys``, ``itervalues``, ``join``, ``keys``, ``ljust``, ``lower``, ``lstrip``, ``numerator``, ``partition``, ``pop``, ``popitem``, ``real``, ``remove``, ``replace``, ``reverse``, ``rfind``, ``rindex``, ``rjust``, ``rpartition``, ``rsplit``, ``rstrip``, ``setdefault``, ``sort``, ``split``, ``splitlines``, ``startswith``, ``strip``, ``swapcase``, ``symmetric_difference``, ``symmetric_difference_update``, ``title``, ``translate``, ``union``, ``update``, ``upper``, ``values``, ``viewitems``, ``viewkeys``, ``viewvalues``, ``zfill``." +msgstr "``add``、``append``、``as_integer_ratio``、``bit_length``、``capitalize``、``center``、``clear``、``conjugate``、``copy``、``count``、``decode``、``denominator``、``difference``、``difference_update``、``discard``、``encode``、``endswith``、``expandtabs``、``extend``、``find``、``format``、``fromhex``、``fromkeys``、``get``、``has_key``、``hex``、``imag``、``index``、``insert``、``intersection``、``intersection_update``、``isalnum``、``isalpha``、``isdecimal``、``isdigit``、``isdisjoint``、``is_integer``、``islower``、``isnumeric``、``isspace``、``issubset``、``issuperset``、``istitle``、``isupper``、``items``、``iteritems``、``iterkeys``、``itervalues``、``join``、``keys``、``ljust``、``lower``、``lstrip``、``numerator``、``partition``、``pop``、``popitem``、``real``、``remove``、``replace``、``reverse``、``rfind``、``rindex``、``rjust``、``rpartition``、``rsplit``、``rstrip``、``setdefault``、``sort``、``split``、``splitlines``、``startswith``、``strip``、``swapcase``、``symmetric_difference``、``symmetric_difference_update``、``title``、``translate``、``union``、``update``、``upper``、``values``、``viewitems``、``viewkeys``、``viewvalues``、``zfill``" + +#: ../../rst/user_guide/playbooks_variables.rst:163 +msgid "Registering variables" +msgstr "変数の登録" + +#: ../../rst/user_guide/playbooks_variables.rst:165 +msgid "You can create variables from the output of an Ansible task with the task keyword ``register``. You can use registered variables in any later tasks in your play. For example:" +msgstr "タスクキーワード ``register`` を使用して、Ansible タスクの出力から変数を作成することができます。登録した変数は、プレイ中の後続のタスクで使用することができます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:182 +msgid "For more examples of using registered variables in conditions on later tasks, see :ref:`playbooks_conditionals`. Registered variables may be simple variables, list variables, dictionary variables, or complex nested data structures. The documentation for each module includes a ``RETURN`` section describing the return values for that module. To see the values for a particular task, run your playbook with ``-v``." +msgstr "登録された変数を後のタスクの条件で使用する例は、「:ref:`playbooks_conditionals`」を参照してください。登録した変数には、単純な変数、リスト変数、ディクショナリー変数、複雑にネストしたデータ構造などがあります。各モジュールのドキュメントには、そのモジュールの戻り値を説明した ``RETURN`` セクションがあります。特定のタスクの値を確認するには、``-v`` で Playbook を実行します。" + +#: ../../rst/user_guide/playbooks_variables.rst:184 +msgid "Registered variables are stored in memory. You cannot cache registered variables for use in future plays. Registered variables are only valid on the host for the rest of the current playbook run." +msgstr "登録された変数はメモリーに保存されます。登録された変数を将来のプレイで使用するためにキャッシュすることはできません。登録された変数は、現在の Playbook の残りの実行中、ホスト上でのみ有効です。" + +#: ../../rst/user_guide/playbooks_variables.rst:186 +msgid "Registered variables are host-level variables. When you register a variable in a task with a loop, the registered variable contains a value for each item in the loop. The data structure placed in the variable during the loop will contain a ``results`` attribute, that is a list of all responses from the module. For a more in-depth example of how this works, see the :ref:`playbooks_loops` section on using register with a loop." +msgstr "登録された変数は、ホストレベルの変数です。ループのあるタスクで変数を登録すると、登録された変数にはループ内の各項目の値が入ります。ループ中に変数に置かれたデータ構造には、``results`` 属性、つまりモジュールからの全応答のリストが含まれます。この動作の詳細な例については、ループで登録の使用に関する「:ref:`playbooks_loops`」セクションを参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:188 +msgid "If a task fails or is skipped, Ansible still registers a variable with a failure or skipped status, unless the task is skipped based on tags. See :ref:`tags` for information on adding and using tags." +msgstr "タスクが失敗またはスキップしても、タグに基づいてタスクがスキップされていない限り、Ansible は失敗またはスキップのステータスで変数を登録します。タグの追加および使用に関する情報は、「:ref:`tags`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:193 +msgid "Referencing nested variables" +msgstr "ネストされた変数の参照" + +#: ../../rst/user_guide/playbooks_variables.rst:195 +msgid "Many registered variables (and :ref:`facts <vars_and_facts>`) are nested YAML or JSON data structures. You cannot access values from these nested data structures with the simple ``{{ foo }}`` syntax. You must use either bracket notation or dot notation. For example, to reference an IP address from your facts using the bracket notation:" +msgstr "多くの登録された変数 (および :ref:`ファクト <vars_and_facts>`) は、ネストされた YAML または JSON データ構造です。これらのネストしたデータ構造の値には、単純な ``{{ foo }}`` の構文ではアクセスできません。括弧表記またはドット表記のいずれかを使用する必要があります。たとえば、括弧表記を使用してファクトから IP アドレスを参照するには、以下を行います。" + +#: ../../rst/user_guide/playbooks_variables.rst:201 +msgid "To reference an IP address from your facts using the dot notation:" +msgstr "ドット表記を使用してファクトから IP アドレスを参照するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_variables.rst:211 +msgid "Transforming variables with Jinja2 filters" +msgstr "Jinja2 フィルターを使用した変数の変換" + +#: ../../rst/user_guide/playbooks_variables.rst:213 +msgid "Jinja2 filters let you transform the value of a variable within a template expression. For example, the ``capitalize`` filter capitalizes any value passed to it; the ``to_yaml`` and ``to_json`` filters change the format of your variable values. Jinja2 includes many `built-in filters <https://jinja.palletsprojects.com/templates/#builtin-filters>`_ and Ansible supplies many more filters. To find more examples of filters, see :ref:`playbooks_filters`." +msgstr "Jinja2 のフィルターは、テンプレート式内の変数の値を変換することができます。たとえば、``capitalize`` フィルターは、渡された値をすべて大文字にします。``to_yaml`` フィルターおよび ``to_json`` フィルターは、変数の値の形式を変更します。Jinja2 には多くの `built-in フィルター <https://jinja.palletsprojects.com/templates/#builtin-filters>`_ があり、Ansible にはさらに多くのフィルターが用意されています。フィルターのその他の例については、「:ref:`playbooks_filters`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:218 +msgid "Where to set variables" +msgstr "変数を設定する場所" + +#: ../../rst/user_guide/playbooks_variables.rst:220 +msgid "You can define variables in a variety of places, such as in inventory, in playbooks, in reusable files, in roles, and at the command line. Ansible loads every possible variable it finds, then chooses the variable to apply based on :ref:`variable precedence rules <ansible_variable_precedence>`." +msgstr "変数は、インベントリー、Playbook、再利用可能ファイル、ロール、コマンドラインなど、さまざまな場所で定義することができます。Ansible は、検出可能なすべての変数を読み込み、:ref:`変数の優先順位ルール <ansible_variable_precedence>` に基づいて適用する変数を選択します。" + +#: ../../rst/user_guide/playbooks_variables.rst:225 +msgid "Defining variables in inventory" +msgstr "インベントリーでの変数の定義" + +#: ../../rst/user_guide/playbooks_variables.rst:227 +msgid "You can define different variables for each individual host, or set shared variables for a group of hosts in your inventory. For example, if all machines in the ``[Boston]`` group use 'boston.ntp.example.com' as an NTP server, you can set a group variable. The :ref:`intro_inventory` page has details on setting :ref:`host variables <host_variables>` and :ref:`group variables <group_variables>` in inventory." +msgstr "個々のホストごとに異なる変数を定義したり、インベントリー内のホストグループに共有変数を設定することができます。たとえば、``[Boston]`` グループのすべてのマシンが NTP サーバーとして「boston.ntp.example.com」を使用する場合は、グループ変数を設定することができます。「:ref:`intro_inventory`」 ページには、インベントリーで :ref:`host 変数 <host_variables>` および :ref:`group 変数 <group_variables>` を設定するための詳細が記載されています。" + +#: ../../rst/user_guide/playbooks_variables.rst:232 +msgid "Defining variables in a play" +msgstr "プレイでの変数の定義" + +#: ../../rst/user_guide/playbooks_variables.rst:234 +msgid "You can define variables directly in a playbook play:" +msgstr "変数は Playbook プレイで直接定義できます。" + +#: ../../rst/user_guide/playbooks_variables.rst:242 +msgid "When you define variables in a play, they are only visible to tasks executed in that play." +msgstr "プレイで変数を定義すると、そのプレイで実行しているタスクでのみ表示されます。" + +#: ../../rst/user_guide/playbooks_variables.rst:248 +msgid "Defining variables in included files and roles" +msgstr "インクルードファイルおよびロールでの変数の定義" + +#: ../../rst/user_guide/playbooks_variables.rst:250 +msgid "You can define variables in reusable variables files and/or in reusable roles. When you define variables in reusable variable files, the sensitive variables are separated from playbooks. This separation enables you to store your playbooks in a source control software and even share the playbooks, without the risk of exposing passwords or other sensitive and personal data. For information about creating reusable files and roles, see :ref:`playbooks_reuse`." +msgstr "変数は、再利用可能な変数ファイルや再利用可能なロールに定義することができます。再利用可能な変数ファイルに変数を定義すると、機密性の高い変数が Playbook から分離されます。この分離により、パスワードなどの機密情報や個人情報を流出させることなく、ソースコントロールソフトウェアに Playbook を保存したり、Playbook を共有したりすることができます。再利用可能なファイルやロールの作成は、「:ref:`playbooks_reuse`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:252 +msgid "This example shows how you can include variables defined in an external file:" +msgstr "この例は、外部ファイルで定義された変数を追加する方法を示しています。" + +#: ../../rst/user_guide/playbooks_variables.rst:270 +msgid "The contents of each variables file is a simple YAML dictionary. For example:" +msgstr "各変数ファイルの内容は、単純な YAML ディクショナリーです。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:280 +msgid "You can keep per-host and per-group variables in similar files. To learn about organizing your variables, see :ref:`splitting_out_vars`." +msgstr "ホスト別およびグループ別の変数を同様のファイルに維持することができます。変数を整理する方法は、「:ref:`splitting_out_vars`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:285 +msgid "Defining variables at runtime" +msgstr "ランタイム時の変数の定義" + +#: ../../rst/user_guide/playbooks_variables.rst:287 +msgid "You can define variables when you run your playbook by passing variables at the command line using the ``--extra-vars`` (or ``-e``) argument. You can also request user input with a ``vars_prompt`` (see :ref:`playbooks_prompts`). When you pass variables at the command line, use a single quoted string, that contains one or more variables, in one of the formats below." +msgstr "Playbook の実行時に変数を定義するには、コマンドラインで ``--extra-vars`` (または ``-e``) 引数を使用して変数を渡します。また、``vars_prompt`` (:ref:`playbooks_prompts` 参照) でユーザーの入力を要求することもできます。コマンドラインで変数を渡すときは、以下のいずれかの形式で、1 つまたは複数の変数を含む一重引用符で囲まれた文字列を使用します。" + +#: ../../rst/user_guide/playbooks_variables.rst:290 +msgid "key=value format" +msgstr "key=value 形式" + +#: ../../rst/user_guide/playbooks_variables.rst:292 +msgid "Values passed in using the ``key=value`` syntax are interpreted as strings. Use the JSON format if you need to pass non-string values such as Booleans, integers, floats, lists, and so on." +msgstr "``key=value`` 構文を使用して渡される値は文字列として解釈されます。ブール値、整数、浮動小数点、リストなど、文字列以外の値を渡す必要がある場合は、JSON 形式を使用します。" + +#: ../../rst/user_guide/playbooks_variables.rst:299 +msgid "JSON string format" +msgstr "JSON 文字列の形式" + +#: ../../rst/user_guide/playbooks_variables.rst:306 +msgid "When passing variables with ``--extra-vars``, you must escape quotes and other special characters appropriately for both your markup (for example, JSON), and for your shell:" +msgstr "``--extra-vars`` で変数を渡す場合には、マークアップ (JSON など) とシェルの両方で、引用符やその他の特殊文字を適切にエスケープする必要があります。" + +#: ../../rst/user_guide/playbooks_variables.rst:314 +msgid "If you have a lot of special characters, use a JSON or YAML file containing the variable definitions." +msgstr "特殊文字が多数ある場合は、変数定義を含む JSON ファイルまたは YAML ファイルを使用します。" + +#: ../../rst/user_guide/playbooks_variables.rst:317 +msgid "vars from a JSON or YAML file" +msgstr "JSON ファイルまたは YAML ファイルの変数" + +#: ../../rst/user_guide/playbooks_variables.rst:327 +msgid "Variable precedence: Where should I put a variable?" +msgstr "変数の優先順位: 変数をどこに置くべきか" + +#: ../../rst/user_guide/playbooks_variables.rst:329 +msgid "You can set multiple variables with the same name in many different places. When you do this, Ansible loads every possible variable it finds, then chooses the variable to apply based on variable precedence. In other words, the different variables will override each other in a certain order." +msgstr "同じ名前の複数の変数をさまざまな場所に設定することができます。これを行うと、Ansible は検出可能なすべての変数を読み込み、次に変数の優先順位に基づいて適用する変数を選択します。つまり、異なる変数が一定の順序で互いに上書きされます。" + +#: ../../rst/user_guide/playbooks_variables.rst:331 +msgid "Teams and projects that agree on guidelines for defining variables (where to define certain types of variables) usually avoid variable precedence concerns. We suggest that you define each variable in one place: figure out where to define a variable, and keep it simple. For examples, see :ref:`variable_examples`." +msgstr "変数の定義に関するガイドライン (特定のタイプの変数をどこで定義するか) に合意したチームやプロジェクトは、通常、変数の優先順位に関する懸念を回避することができます。各変数は、一箇所で定義することが推奨されます。どこで変数を定義するかを把握し、簡潔さを保ってください。例については、「:ref:`variable_examples`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:333 +msgid "Some behavioral parameters that you can set in variables you can also set in Ansible configuration, as command-line options, and using playbook keywords. For example, you can define the user Ansible uses to connect to remote devices as a variable with ``ansible_user``, in a configuration file with ``DEFAULT_REMOTE_USER``, as a command-line option with ``-u``, and with the playbook keyword ``remote_user``. If you define the same parameter in a variable and by another method, the variable overrides the other setting. This approach allows host-specific settings to override more general settings. For examples and more details on the precedence of these various settings, see :ref:`general_precedence_rules`." +msgstr "変数で設定できる動作パラメーターの中には、Ansible の構成、コマンドラインオプション、および Playbook キーワードで設定できるものがあります。たとえば、Ansible がリモートデバイスへの接続に使用するユーザーは、変数では ``ansible_user``、構成ファイルでは ``DEFAULT_REMOTE_USER``、コマンドラインオプションでは ``-u`` 、Playbook キーワードでは ``remote_user`` で定義できます。変数と別の方法で同じパラメーターを定義した場合は、変数が別の設定を上書きします。この方法では、ホスト固有の設定がより一般的な設定を上書きします。これらのさまざまな設定の優先順位の例や詳細は、「:ref:`general_precedence_rules`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:336 +msgid "Understanding variable precedence" +msgstr "変数の優先順位について" + +#: ../../rst/user_guide/playbooks_variables.rst:338 +msgid "Ansible does apply variable precedence, and you might have a use for it. Here is the order of precedence from least to greatest (the last listed variables override all other variables):" +msgstr "Ansible では変数の優先順位を適用しており、それを利用できる場合があります。ここでは、優先順位の低いものから高いものまでを紹介します (最後に挙げた変数が他のすべての変数を上書きします)。" + +#: ../../rst/user_guide/playbooks_variables.rst:340 +msgid "command line values (for example, ``-u my_user``, these are not variables)" +msgstr "コマンドラインの値 (例: ``-u my_user`` (これらは変数ではありません))" + +#: ../../rst/user_guide/playbooks_variables.rst:341 +msgid "role defaults (defined in role/defaults/main.yml) [1]_" +msgstr "ロールのデフォルト(role/defaults/main.yml で定義) [1]_" + +#: ../../rst/user_guide/playbooks_variables.rst:342 +msgid "inventory file or script group vars [2]_" +msgstr "インベントリーファイルまたはスクリプトのグループ変数 [2]_" + +#: ../../rst/user_guide/playbooks_variables.rst:343 +msgid "inventory group_vars/all [3]_" +msgstr "インベントリー group_vars/all [3]_" + +#: ../../rst/user_guide/playbooks_variables.rst:344 +msgid "playbook group_vars/all [3]_" +msgstr "playbook group_vars/all [3]_" + +#: ../../rst/user_guide/playbooks_variables.rst:345 +msgid "inventory group_vars/* [3]_" +msgstr "インベントリー group_vars/* [3]_" + +#: ../../rst/user_guide/playbooks_variables.rst:346 +msgid "playbook group_vars/* [3]_" +msgstr "playbook group_vars/* [3]_" + +#: ../../rst/user_guide/playbooks_variables.rst:347 +msgid "inventory file or script host vars [2]_" +msgstr "インベントリーファイルまたはスクリプトホスト変数 [2]_" + +#: ../../rst/user_guide/playbooks_variables.rst:348 +msgid "inventory host_vars/* [3]_" +msgstr "インベントリー host_vars/* [3]_" + +#: ../../rst/user_guide/playbooks_variables.rst:349 +msgid "playbook host_vars/* [3]_" +msgstr "playbook host_vars/* [3]_" + +#: ../../rst/user_guide/playbooks_variables.rst:350 +msgid "host facts / cached set_facts [4]_" +msgstr "ホストファクト / キャッシュ済み set_facts [4]_" + +#: ../../rst/user_guide/playbooks_variables.rst:351 +msgid "play vars" +msgstr "プレイ変数" + +#: ../../rst/user_guide/playbooks_variables.rst:352 +msgid "play vars_prompt" +msgstr "play vars_prompt" + +#: ../../rst/user_guide/playbooks_variables.rst:353 +msgid "play vars_files" +msgstr "play vars_files" + +#: ../../rst/user_guide/playbooks_variables.rst:354 +msgid "role vars (defined in role/vars/main.yml)" +msgstr "role 変数 (role/vars/main.yml で定義)" + +#: ../../rst/user_guide/playbooks_variables.rst:355 +msgid "block vars (only for tasks in block)" +msgstr "ブロック変数 (ブロックのタスクにのみ適用)" + +#: ../../rst/user_guide/playbooks_variables.rst:356 +msgid "task vars (only for the task)" +msgstr "タスク変数 (タスク専用)" + +#: ../../rst/user_guide/playbooks_variables.rst:357 +#: ../../rst/user_guide/windows_faq.rst:168 +msgid "include_vars" +msgstr "include_vars" + +#: ../../rst/user_guide/playbooks_variables.rst:358 +msgid "set_facts / registered vars" +msgstr "set_facts / 登録変数" + +#: ../../rst/user_guide/playbooks_variables.rst:359 +msgid "role (and include_role) params" +msgstr "role (および include_role) パラメーター" + +#: ../../rst/user_guide/playbooks_variables.rst:360 +msgid "include params" +msgstr "include パラメーター" + +#: ../../rst/user_guide/playbooks_variables.rst:361 +msgid "extra vars (for example, ``-e \"user=my_user\"``)(always win precedence)" +msgstr "追加の変数 (例: ``-e \"user=my_user\"``)(常に優先されます)" + +#: ../../rst/user_guide/playbooks_variables.rst:363 +msgid "In general, Ansible gives precedence to variables that were defined more recently, more actively, and with more explicit scope. Variables in the defaults folder inside a role are easily overridden. Anything in the vars directory of the role overrides previous versions of that variable in the namespace. Host and/or inventory variables override role defaults, but explicit includes such as the vars directory or an ``include_vars`` task override inventory variables." +msgstr "一般的に、Ansible は、より新しく、より積極的に、より明確なスコープで定義された変数を優先します。ロール内の defaults フォルダーにある変数は簡単に上書きされます。ロールの vars ディレクトリーにあるものは、名前空間内のその変数の以前のバージョンを上書きします。ホストおよび/またはインベントリー変数はロールのデフォルトを上書きしますが、vars ディレクトリーや ``include_vars`` タスクなどの明示的なインクルードはインベントリー変数を上書きします。" + +#: ../../rst/user_guide/playbooks_variables.rst:365 +msgid "Ansible merges different variables set in inventory so that more specific settings override more generic settings. For example, ``ansible_ssh_user`` specified as a group_var is overridden by ``ansible_user`` specified as a host_var. For details about the precedence of variables set in inventory, see :ref:`how_we_merge`." +msgstr "Ansible は、インベントリーに設定した異なる変数をマージして、より特定の設定がより一般的な設定を上書きするようにします。たとえば、group_var として指定した ``ansible_ssh_user`` は、host_var として指定した ``ansible_user`` により上書きされます。インベントリーで設定された変数の優先順位の詳細については、「:ref:`how_we_merge`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:368 +msgid "Footnotes" +msgstr "注記" + +#: ../../rst/user_guide/playbooks_variables.rst:369 +msgid "Tasks in each role see their own role's defaults. Tasks defined outside of a role see the last role's defaults." +msgstr "各ロールのタスクには、それぞれのロールのデフォルト値が表示されます。ロールの外で定義されたタスクには、最後のロールのデフォルトが表示されます。" + +#: ../../rst/user_guide/playbooks_variables.rst:370 +msgid "Variables defined in inventory file or provided by dynamic inventory." +msgstr "インベントリーファイルで定義される変数、または動的インベントリーで指定される変数。" + +#: ../../rst/user_guide/playbooks_variables.rst:371 +msgid "Includes vars added by 'vars plugins' as well as host_vars and group_vars which are added by the default vars plugin shipped with Ansible." +msgstr "「vars プラグイン」と、Ansible に同梱されるデフォルトの vars プラグインにより追加される host_vars および group_vars が含まれるインクルード変数。" + +#: ../../rst/user_guide/playbooks_variables.rst:372 +msgid "When created with set_facts's cacheable option, variables have the high precedence in the play, but are the same as a host facts precedence when they come from the cache." +msgstr "set_facts のキャッシュ可能なオプションを使用して作成すると、変数がプレイに優先されますが、キャッシュからのホストのファクトと同様に優先されます。" + +#: ../../rst/user_guide/playbooks_variables.rst:375 +msgid "Within any section, redefining a var overrides the previous instance. If multiple groups have the same variable, the last one loaded wins. If you define a variable twice in a play's ``vars:`` section, the second one wins." +msgstr "どのセクションでも、変数を再定義すると前のインスタンスが上書きされます。複数のグループが同じ変数を持っている場合は、最後に読み込まれたものが優先されます。プレイ中の ``vars:`` のセクションで変数を 2 回定義した場合は、2 回目の変数が優先されます。" + +#: ../../rst/user_guide/playbooks_variables.rst:378 +msgid "The previous describes the default config ``hash_behaviour=replace``, switch to ``merge`` to only partially overwrite." +msgstr "以前は、デフォルトの設定 ``hash_behaviour=replace`` を説明し、``merge`` に切り替えてを部分的に上書きします。" + +#: ../../rst/user_guide/playbooks_variables.rst:383 +msgid "Scoping variables" +msgstr "変数のスコープ設定" + +#: ../../rst/user_guide/playbooks_variables.rst:385 +msgid "You can decide where to set a variable based on the scope you want that value to have. Ansible has three main scopes:" +msgstr "変数をどこに設定するかは、その値が持つべきスコープに基づいて決めることができます。Ansible には大きく分けて 3 つのスコープがあります。" + +#: ../../rst/user_guide/playbooks_variables.rst:387 +msgid "Global: this is set by config, environment variables and the command line" +msgstr "グローバル: これは、設定、環境変数、およびコマンドラインで設定されます。" + +#: ../../rst/user_guide/playbooks_variables.rst:388 +msgid "Play: each play and contained structures, vars entries (vars; vars_files; vars_prompt), role defaults and vars." +msgstr "プレイ: 各プレイおよび含まれる構造、変数エントリー (vars、vars_files、vars_prompt)、ロールのデフォルト、および変数" + +#: ../../rst/user_guide/playbooks_variables.rst:389 +msgid "Host: variables directly associated to a host, like inventory, include_vars, facts or registered task outputs" +msgstr "ホスト: インベントリー、include_vars、ファクト、または登録されたタスクの出力などのホストに直接関連付けられる変数" + +#: ../../rst/user_guide/playbooks_variables.rst:391 +msgid "Inside a template, you automatically have access to all variables that are in scope for a host, plus any registered variables, facts, and magic variables." +msgstr "テンプレート内では、ホストのスコープ内にあるすべての変数と、登録済みの変数、ファクト、およびマジック変数に自動的にアクセスできます。" + +#: ../../rst/user_guide/playbooks_variables.rst:396 +msgid "Tips on where to set variables" +msgstr "変数を設定する場所に関するヒント" + +#: ../../rst/user_guide/playbooks_variables.rst:398 +msgid "You should choose where to define a variable based on the kind of control you might want over values." +msgstr "変数を定義する場所は、値をどのように制御するかによって選択する必要があります。" + +#: ../../rst/user_guide/playbooks_variables.rst:400 +msgid "Set variables in inventory that deal with geography or behavior. Since groups are frequently the entity that maps roles onto hosts, you can often set variables on the group instead of defining them on a role. Remember: child groups override parent groups, and host variables override group variables. See :ref:`define_variables_in_inventory` for details on setting host and group variables." +msgstr "地理や動作を扱うインベントリーに変数を設定します。グループは、ホストにロールをマッピングするエンティティーであることが多いため、ロールに変数を定義する代わりに、グループに変数を設定することができます。子グループが親グループを上書きし、ホスト変数がグループ変数を上書きすることを忘れないでください。ホスト変数とグループ変数の設定の詳細は、「:ref:`define_variables_in_inventory`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:402 +msgid "Set common defaults in a ``group_vars/all`` file. See :ref:`splitting_out_vars` for details on how to organize host and group variables in your inventory. Group variables are generally placed alongside your inventory file, but they can also be returned by dynamic inventory (see :ref:`intro_dynamic_inventory`) or defined in AWX or on :ref:`ansible_platform` from the UI or API:" +msgstr "``group_vars/all`` ファイルで共通のデフォルトを設定します。インベントリーでホスト変数とグループ変数を整理する方法の詳細については、「:ref:`splitting_out_vars`」を参照してください。グループ変数は通常、インベントリーファイルと一緒に置かれますが、動的インベントリー (:ref:`intro_dynamic_inventory` を参照) で返されたり、AWX、または UI や API から :ref:`ansible_platform` で定義することもできます。" + +#: ../../rst/user_guide/playbooks_variables.rst:411 +msgid "Set location-specific variables in ``group_vars/my_location`` files. All groups are children of the ``all`` group, so variables set here override those set in ``group_vars/all``:" +msgstr "``group_vars/my_location`` ファイルにロケーション固有の変数を設定します。すべてのグループは ``all`` グループの子であるため、ここに設定される変数は ``group_vars/all`` で設定した変数を上書きします。" + +#: ../../rst/user_guide/playbooks_variables.rst:419 +msgid "If one host used a different NTP server, you could set that in a host_vars file, which would override the group variable:" +msgstr "1 つのホストが別の NTP サーバーを使用している場合は、host_vars ファイルにそのホストを設定できます。これにより、グループ変数が上書きされます。" + +#: ../../rst/user_guide/playbooks_variables.rst:427 +msgid "Set defaults in roles to avoid undefined-variable errors. If you share your roles, other users can rely on the reasonable defaults you added in the ``roles/x/defaults/main.yml`` file, or they can easily override those values in inventory or at the command line. See :ref:`playbooks_reuse_roles` for more info. For example:" +msgstr "未定義な変数エラーを防ぐために、ロールにデフォルト値を設定します。ロールを共有している場合、他のユーザーは、``roles/x/defaults/main.yml`` ファイルで追加した妥当なデフォルト値を信頼するか、インベントリーやコマンドラインで簡単にその値を上書きすることができます。詳細は、「:ref:`playbooks_reuse_roles`」を参照してください。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:436 +msgid "Set variables in roles to ensure a value is used in that role, and is not overridden by inventory variables. If you are not sharing your role with others, you can define app-specific behaviors like ports this way, in ``roles/x/vars/main.yml``. If you are sharing roles with others, putting variables here makes them harder to override, although they still can by passing a parameter to the role or setting a variable with ``-e``:" +msgstr "ロールに変数を設定することで、値がそのロールで使用され、インベントリー変数で上書きされないようにします。ロールを他の人と共有していない場合は、ポートなどのアプリ固有の動作を、このように ``roles/x/vars/main.yml`` で定義できます。他の人とロールを共有している場合は、ここに変数を置くことで上書きされにくくなります。ただし、ロールにパラメーターを渡したり、``-e`` で変数を設定したりすれば、上書きされる可能性はあります。" + +#: ../../rst/user_guide/playbooks_variables.rst:445 +msgid "Pass variables as parameters when you call roles for maximum clarity, flexibility, and visibility. This approach overrides any defaults that exist for a role. For example:" +msgstr "明確さ、柔軟性、および可視性を最大化するためにロールを呼び出す場合は、パラメーターとして変数を渡します。この方法では、ロールに存在するデフォルトを上書きします。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:454 +msgid "When you read this playbook it is clear that you have chosen to set a variable or override a default. You can also pass multiple values, which allows you to run the same role multiple times. See :ref:`run_role_twice` for more details. For example:" +msgstr "この Playbook を読むと、変数の設定やデフォルトの上書きを選択したことがわかります。また、複数の値を渡すことができるため、同じロールを複数回実行することができます。詳細は「:ref:`run_role_twice`」を参照してください。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_variables.rst:472 +msgid "Variables set in one role are available to later roles. You can set variables in a ``roles/common_settings/vars/main.yml`` file and use them in other roles and elsewhere in your playbook:" +msgstr "1 つのロールに設定された変数は、後のロールで使用できます。変数は、``roles/common_settings/vars/main.yml`` ファイルに設定して、他のロールや Playbook の他の場所で使用します。" + +#: ../../rst/user_guide/playbooks_variables.rst:483 +msgid "There are some protections in place to avoid the need to namespace variables. In this example, variables defined in 'common_settings' are available to 'something' and 'something_else' tasks, but tasks in 'something' have foo set at 12, even if 'common_settings' sets foo to 20." +msgstr "変数の名前空間化の必要性を回避するために、いくつかの保護機能があります。この例では、「common_settings」で定義された変数は「something」と「something_else」のタスクで使用できますが、「common_settings」で foo が 20 に設定されていても、「something」のタスクでは foo が 12 に設定されています。" + +#: ../../rst/user_guide/playbooks_variables.rst:486 +msgid "Instead of worrying about variable precedence, we encourage you to think about how easily or how often you want to override a variable when deciding where to set it. If you are not sure what other variables are defined, and you need a particular value, use ``--extra-vars`` (``-e``) to override all other variables." +msgstr "変数の優先順位を気にするのではなく、変数をどこに設定するかを決める際には、どれだけ簡単に、あるいはどれだけ頻繁に変数を上書きしたいかを考えることが推奨されます。他の変数がどのように定義されているかわからず、特定の値が必要な場合は、``--extra-vars`` (``-e``) を使用して、他のすべての変数を上書きします。" + +#: ../../rst/user_guide/playbooks_variables.rst:489 +msgid "Using advanced variable syntax" +msgstr "高度な変数構文の使用" + +#: ../../rst/user_guide/playbooks_variables.rst:491 +msgid "For information about advanced YAML syntax used to declare variables and have more control over the data placed in YAML files used by Ansible, see :ref:`playbooks_advanced_syntax`." +msgstr "変数を宣言するのに使用される高度な YAML 構文、および Ansible により使用される YAML ファイルにあるデータに対する制御の詳細は、「:ref:`playbooks_advanced_syntax`」を参照してください。" + +#: ../../rst/user_guide/playbooks_variables.rst:500 +msgid "Jinja2 filters and their uses" +msgstr "Jinja2 フィルターおよびその使用" + +#: ../../rst/user_guide/playbooks_variables.rst:507 +msgid ":ref:`special_variables`" +msgstr ":ref:`special_variables`" + +#: ../../rst/user_guide/playbooks_variables.rst:508 +msgid "List of special variables" +msgstr "特殊な変数のリスト" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:5 +msgid "Discovering variables: facts and magic variables" +msgstr "変数の検出: ファクトおよびマジック変数" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:7 +msgid "With Ansible you can retrieve or discover certain variables containing information about your remote systems or about Ansible itself. Variables related to remote systems are called facts. With facts, you can use the behavior or state of one system as configuration on other systems. For example, you can use the IP address of one system as a configuration value on another system. Variables related to Ansible are called magic variables." +msgstr "Ansible では、リモートシステムや Ansible 自体に関する情報を含む特定の変数を取得または検出を行うことができます。リモートシステムに関連する変数をファクトと呼びます。ファクトを使用すると、あるシステムの動作や状態を他のシステムの設定値として使用することができます。たとえば、あるシステムの IP アドレスを、他のシステムの設定値として使用することができます。Ansible に関連する変数をマジック変数と呼びます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:13 +msgid "Ansible facts" +msgstr "Ansible ファクト" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:15 +msgid "Ansible facts are data related to your remote systems, including operating systems, IP addresses, attached filesystems, and more. You can access this data in the ``ansible_facts`` variable. By default, you can also access some Ansible facts as top-level variables with the ``ansible_`` prefix. You can disable this behavior using the :ref:`INJECT_FACTS_AS_VARS` setting. To see all available facts, add this task to a play:" +msgstr "Ansible のファクトは、オペレーティングシステム、IP アドレス、添付のファイルシステムなど、リモートシステムに関連するデータです。このデータには、``ansible_facts`` という変数でアクセスできます。デフォルトでは、一部の Ansible ファクトは、``ansible_`` というプレフィックスを持つトップレベルの変数としてアクセスすることもできます。この動作は、:ref:`INJECT_FACTS_AS_VARS` の設定で無効にすることができます。利用可能なすべてのファクトを表示するには、このタスクをプレイに追加します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:23 +msgid "To see the 'raw' information as gathered, run this command at the command line:" +msgstr "収集された「生」の情報を見るには、コマンドラインで次のコマンドを実行します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:29 +msgid "Facts include a large amount of variable data, which may look like this:" +msgstr "ファクトには大量の変数データが含まれており、それは次のようなものです。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:490 +msgid "You can reference the model of the first disk in the facts shown above in a template or playbook as:" +msgstr "上記のファクトの最初のディスクのモデルをテンプレートまたは Playbook で参照できます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:496 +msgid "To reference the system hostname:" +msgstr "システムのホスト名を参照するには、以下を実行します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:502 +msgid "You can use facts in conditionals (see :ref:`playbooks_conditionals`) and also in templates. You can also use facts to create dynamic groups of hosts that match particular criteria, see the :ref:`group_by module <group_by_module>` documentation for details." +msgstr "ファクトは、条件式 (:ref:`playbooks_conditionals` を参照) やテンプレートでも使用できます。また、ファクトを使用して、特定の条件に一致するホストの動的なグループを作成することもできます。詳細は、:ref:`group_by モジュール <group_by_module>` のドキュメントを参照してください。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:504 +#, python-format +msgid "Because ``ansible_date_time`` is created and cached when Ansible gathers facts before each playbook run, it can get stale with long-running playbooks. If your playbook takes a long time to run, use the ``pipe`` filter (for example, ``lookup('pipe', 'date +%Y-%m-%d.%H:%M:%S')``) or :ref:`now() <templating_now>` with a Jinja 2 template instead of ``ansible_date_time``." +msgstr "``ansible_date_time`` は、Ansible が各 Playbook の実行前にファクトを収集したときにキャッシュされるため、長時間実行される Playbook で古くなる可能性があります。Playbook の実行に長い時間がかかる場合は、``ansible_date_time`` ではなく Jinja 2 テンプレートで ``pipe`` フィルター（例: ``lookup('pipe', 'date +%Y-%m-%d.%H:%M:%S')``）または :ref:`now() <templating_now>` を使用します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:509 +msgid "Package requirements for fact gathering" +msgstr "ファクト収集のパッケージ要件" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:511 +msgid "On some distros, you may see missing fact values or facts set to default values because the packages that support gathering those facts are not installed by default. You can install the necessary packages on your remote hosts using the OS package manager. Known dependencies include:" +msgstr "一部のディストリビューションでは、ファクトの収集をサポートするパッケージがデフォルトでインストールされていないため、ファクトの値が見つからなかったり、ファクトがデフォルト値に設定されたりすることがあります。OS のパッケージマネージャーを使用して、リモートホストに必要なパッケージをインストールすることができます。既知の依存関係には以下のものがあります。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:513 +msgid "Linux Network fact gathering - Depends on the ``ip`` binary, commonly included in the ``iproute2`` package." +msgstr "Linux ネットワークファクト収集 - 一般的に ``iproute2`` パッケージに含まれる ``ip`` バイナリーによって異なります。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:518 +msgid "Caching facts" +msgstr "ファクトのキャッシュ" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:520 +msgid "Like registered variables, facts are stored in memory by default. However, unlike registered variables, facts can be gathered independently and cached for repeated use. With cached facts, you can refer to facts from one system when configuring a second system, even if Ansible executes the current play on the second system first. For example:" +msgstr "登録された変数と同様に、ファクトはデフォルトでメモリーに保存されます。ただし、登録された変数とは異なり、ファクトは独立して収集し、繰り返し使用するためにキャッシュすることができます。キャッシュされたファクトを使用すると、Ansible が 2 つ目のシステムで現在のプレイを最初に実行した場合でも、1 つのシステムのファクトを参照して 2 つ目のシステムを設定することができます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:526 +msgid "Caching is controlled by the cache plugins. By default, Ansible uses the memory cache plugin, which stores facts in memory for the duration of the current playbook run. To retain Ansible facts for repeated use, select a different cache plugin. See :ref:`cache_plugins` for details." +msgstr "キャッシュ処理は、キャッシュプラグインによって制御されます。デフォルトでは、Ansible はメモリーキャッシュプラグインを使用し、現在の Playbook の実行期間中、メモリーにファクトを保存します。Ansible のファクトを繰り返し使用するために保持するには、別のキャッシュプラグインを選択します。詳細は「:ref:`cache_plugins`」を参照してください。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:528 +msgid "Fact caching can improve performance. If you manage thousands of hosts, you can configure fact caching to run nightly, then manage configuration on a smaller set of servers periodically throughout the day. With cached facts, you have access to variables and information about all hosts even when you are only managing a small number of servers." +msgstr "ファクトキャッシュ処理はパフォーマンスを向上させます。何千台ものホストを管理している場合は、ファクトキャッシュ処理を毎晩実行するように設定し、小規模なサーバ群の設定を 1 日中定期的に管理することができます。キャッシュされたファクトがあれば、少数のサーバーしか管理していなくても、すべてのホストに関する変数および情報にアクセスすることができます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:533 +msgid "Disabling facts" +msgstr "ファクトの無効化" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:535 +msgid "By default, Ansible gathers facts at the beginning of each play. If you do not need to gather facts (for example, if you know everything about your systems centrally), you can turn off fact gathering at the play level to improve scalability. Disabling facts may particularly improve performance in push mode with very large numbers of systems, or if you are using Ansible on experimental platforms. To disable fact gathering:" +msgstr "デフォルトでは、Ansible は各プレイの開始時にファクトを収集します。ファクトを収集する必要がない場合 (たとえば、システムに関する情報をすべて一元的に把握している場合) は、プレイレベルでのファクト収集をオフにすることで、スケーラビリティーを向上させることができます。ファクトを無効にすると、非常に多数のシステムを使用するプッシュモードや、実験的なプラットフォームで Ansible を使用している場合に、特にパフォーマンスが向上することがあります。ファクトの収集を無効にするには、以下を行います。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:543 +msgid "Adding custom facts" +msgstr "カスタムファクトの追加" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:545 +msgid "The setup module in Ansible automatically discovers a standard set of facts about each host. If you want to add custom values to your facts, you can write a custom facts module, set temporary facts with a ``ansible.builtin.set_fact`` task, or provide permanent custom facts using the facts.d directory." +msgstr "Ansible のセットアップモジュールは、各ホストに関する標準的なファクトのセットを自動的に検出します。ファクトにカスタム値を追加したい場合は、カスタムファクトモジュールを記述したり、``ansible.builtin.set_fact`` タスクで一時的なファクトを設定したり、facts.d ディレクトリーを使用して恒久的なカスタムファクトを提供したりすることができます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:550 +msgid "facts.d or local facts" +msgstr "facts.d またはローカルファクト" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:554 +msgid "You can add static custom facts by adding static files to facts.d, or add dynamic facts by adding executable scripts to facts.d. For example, you can add a list of all users on a host to your facts by creating and running a script in facts.d." +msgstr "静的なカスタムファクトは、静的ファイルを facts.d に追加することで追加でき、動的なファクトは実行可能なスクリプトを facts.d に追加することで追加できます。たとえば、facts.d でスクリプトを作成して実行することにより、ホスト上のすべてのユーザーのリストをファクトに追加できます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:556 +msgid "To use facts.d, create an ``/etc/ansible/facts.d`` directory on the remote host or hosts. If you prefer a different directory, create it and specify it using the ``fact_path`` play keyword. Add files to the directory to supply your custom facts. All file names must end with ``.fact``. The files can be JSON, INI, or executable files returning JSON." +msgstr "facts.d を使用するには、リモートホストまたはホスト上に ``/etc/ansible/facts.d`` ディレクトリーを作成します。別のディレクトリーを使用する場合は、そのディレクトリーを作成し、プレイキーワード ``fact_path`` を使用して指定します。このディレクトリーにファイルを追加して、カスタムファクトを提供します。すべてのファイル名は、``.fact`` で終わる必要があります。ファイルには、JSON、INI、または JSON を返す実行可能ファイルを使用できます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:558 +msgid "To add static facts, simply add a file with the ``.fact`` extension. For example, create ``/etc/ansible/facts.d/preferences.fact`` with this content:" +msgstr "静的ファクトを追加するには、``.fact`` 拡張子を持つファイルを追加するだけです。たとえば、以下の内容で ``/etc/ansible/facts.d/preferences.fact`` を作成します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:566 +msgid "Make sure the file is not executable as this will break the ``ansible.builtin.setup`` module." +msgstr "``ansible.builtin.setup`` モジュールが壊れるため、このファイルが実行ファイルではないことを確認してください。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:568 +msgid "The next time fact gathering runs, your facts will include a hash variable fact named ``general`` with ``asdf`` and ``bar`` as members. To validate this, run the following:" +msgstr "次回、ファクト収集が実行されると、ファクトには、``asdf`` と ``bar`` をメンバーとする ``general`` という名前のハッシュ変数ファクトが含まれるようになります。これを検証するには、次のように実行します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:574 +msgid "And you will see your custom fact added:" +msgstr "これにより、カスタムファクトが追加されているのが確認できます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:589 +msgid "The ansible_local namespace separates custom facts created by facts.d from system facts or variables defined elsewhere in the playbook, so variables will not override each other. You can access this custom fact in a template or playbook as:" +msgstr "ansible_local 名前空間は、facts.d で作成されたカスタムファクトと、システムファクトや Playbook 内の他の場所で定義された変数を分離し、変数が互いに上書きされないようにします。このカスタムファクトには、テンプレートや Playbook で次のようにアクセスできます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:595 +msgid "The key part in the key=value pairs will be converted into lowercase inside the ansible_local variable. Using the example above, if the ini file contained ``XYZ=3`` in the ``[general]`` section, then you should expect to access it as: ``{{ ansible_local['preferences']['general']['xyz'] }}`` and not ``{{ ansible_local['preferences']['general']['XYZ'] }}``. This is because Ansible uses Python's `ConfigParser`_ which passes all option names through the `optionxform`_ method and this method's default implementation converts option names to lower case." +msgstr "鍵と値のペアの鍵の部分は、ansible_local 変数内で小文字に変換されます。上記の例では、ini ファイルの ``[general]`` セクションに ``XYZ=3`` が含まれていた場合は、``{{ ansible_local['preferences']['general']['XYZ'] }}`` ではなく、``{{ ansible_local['preferences']['general']['xyz'] }}`` としてアクセスすることになります。これは、Ansible が Python の `ConfigParser`_ を使用して、すべてのオプション名を `optionxform`_ メソッドに渡しており、このメソッドのデフォルトの実装では、オプション名が小文字に変換されるためです。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:600 +msgid "You can also use facts.d to execute a script on the remote host, generating dynamic custom facts to the ansible_local namespace. For example, you can generate a list of all users that exist on a remote host as a fact about that host. To generate dynamic custom facts using facts.d:" +msgstr "facts.d を使用して、リモートホスト上でスクリプトを実行し、ansible_local 名前空間に動的なカスタムファクトを生成することもできます。たとえば、リモートホストに存在するすべてのユーザーのリストを、そのホストに関するファクトとして生成することができます。facts.d を使用して動的なカスタムファクトを生成するには、以下の手順に従います。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:602 +msgid "Write and test a script to generate the JSON data you want." +msgstr "スクリプトを作成してテストして、必要な JSON データを生成します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:603 +msgid "Save the script in your facts.d directory." +msgstr "スクリプトを facts.d ディレクトリーに保存します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:604 +msgid "Make sure your script has the ``.fact`` file extension." +msgstr "スクリプトに ``.fact`` ファイル拡張子があることを確認します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:605 +msgid "Make sure your script is executable by the Ansible connection user." +msgstr "スクリプトが Ansible 接続ユーザーによって実行可能であることを確認します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:606 +msgid "Gather facts to execute the script and add the JSON output to ansible_local." +msgstr "スクリプトを実行するファクトを収集し、JSON 出力を ansible_local に追加します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:608 +msgid "By default, fact gathering runs once at the beginning of each play. If you create a custom fact using facts.d in a playbook, it will be available in the next play that gathers facts. If you want to use it in the same play where you created it, you must explicitly re-run the setup module. For example:" +msgstr "デフォルトでは、ファクトの収集は各プレイの開始時に一度だけ実行します。Playbook で facts.d を使用してカスタムファクトを作成すると、ファクトを収集する次のプレイで使用できるようになります。作成したのと同じプレイで使用したい場合は、セットアップモジュールを明示的に再実行する必要があります。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:630 +msgid "If you use this pattern frequently, a custom facts module would be more efficient than facts.d." +msgstr "このパターンを頻繁に使用すると、カスタムファクトモジュールは facts.d よりも効率が上がります。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:635 +msgid "Information about Ansible: magic variables" +msgstr "Ansible に関する情報: マジック変数" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:637 +msgid "You can access information about Ansible operations, including the python version being used, the hosts and groups in inventory, and the directories for playbooks and roles, using \"magic\" variables. Like connection variables, magic variables are :ref:`special_variables`. Magic variable names are reserved - do not set variables with these names. The variable ``environment`` is also reserved." +msgstr "使用している Python のバージョン、インベントリー内のホストやグループ、Playbook やロールのディレクトリーなど、Ansible の操作に関する情報は、「マジック」変数を使用してアクセスすることができます。接続変数と同様に、マジック変数は :ref:`special_variables` です。マジック変数の名前は予約済みです。これらの名前で変数を設定しないでください。変数 ``environment`` も予約済みです。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:639 +msgid "The most commonly used magic variables are ``hostvars``, ``groups``, ``group_names``, and ``inventory_hostname``. With ``hostvars``, you can access variables defined for any host in the play, at any point in a playbook. You can access Ansible facts using the ``hostvars`` variable too, but only after you have gathered (or cached) facts. Note that variables defined at play objects are not defined for specific hosts and therefore are not mapped to hostvars." +msgstr "最も一般的に使用されるマジック変数は、``hostvars``、``groups``、``group_names``、および ``inventory_hostname`` です。``hostvars`` を使用すると、Playbook 内の任意の時点で、プレイ内の任意のホストに対して定義された変数にアクセスできます。``hostvars`` 変数を使用して Ansible のファクトにアクセスすることもできますが、ファクトを収集 (またはキャッシュ) した後でなければなりません。プレイオブジェクトで定義された変数は特定のホストに対して定義されていないため、hostvars にマップされないことに注意してください。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:641 +msgid "If you want to configure your database server using the value of a 'fact' from another node, or the value of an inventory variable assigned to another node, you can use ``hostvars`` in a template or on an action line:" +msgstr "他のノードの「ファクト」の値や、他のノードに割り当てられたインベントリー変数の値を使用してデータベースサーバーを設定する場合は、テンプレートやアクション行で ``hostvars`` を使用することができます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:647 +msgid "With ``groups``, a list of all the groups (and hosts) in the inventory, you can enumerate all hosts within a group. For example:" +msgstr "``groups`` では、インベントリー内のすべてのグループ (およびホスト) のリストで、グループ内のすべてのホストを列挙できます。以下に例を示します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:655 +msgid "You can use ``groups`` and ``hostvars`` together to find all the IP addresses in a group." +msgstr "``groups`` と ``hostvars`` を一緒に使用して、グループ内のすべての IP アドレスを探すことができます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:663 +msgid "You can use this approach to point a frontend proxy server to all the hosts in your app servers group, to set up the correct firewall rules between servers, and so on. You must either cache facts or gather facts for those hosts before the task that fills out the template." +msgstr "この方法を使用して、フロントエンドプロキシーサーバーがアプリサーバーグループ内のすべてのホストを指すようにしたり、サーバー間に正しいファイアウォールルールを設定したりできます。テンプレートに入力するタスクの前に、ファクトをキャッシュするか、それらのホストのファクトを収集する必要があります。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:665 +msgid "With ``group_names``, a list (array) of all the groups the current host is in, you can create templated files that vary based on the group membership (or role) of the host:" +msgstr "``group_names`` では、現在のホストが置かれているすべてのグループのリスト (配列) は、ホストのグループメンバーシップ (またはロール) に基づいて異なるテンプレートファイルを作成できます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:673 +msgid "You can use the magic variable ``inventory_hostname``, the name of the host as configured in your inventory, as an alternative to ``ansible_hostname`` when fact-gathering is disabled. If you have a long FQDN, you can use ``inventory_hostname_short``, which contains the part up to the first period, without the rest of the domain." +msgstr "ファクト収集が無効になっているときには、``ansible_hostname`` の代わりに、インベントリーで設定されたホストの名前であるマジック変数 ``inventory_hostname`` を使用できます。長い FQDN がある場合には、最初のピリオドまでの部分を含み、ドメインの残りの部分を含まない ``inventory_hostname_short`` を使用することができます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:675 +msgid "Other useful magic variables refer to the current play or playbook. These vars may be useful for filling out templates with multiple hostnames or for injecting the list into the rules for a load balancer." +msgstr "その他の有用なマジック変数は、現在のプレイや Playbook を参照します。これらの変数は、複数のホスト名でテンプレートを埋めるときや、ロードバランサーのルールにリストを注入するときに便利です。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:677 +msgid "``ansible_play_hosts`` is the list of all hosts still active in the current play." +msgstr "``ansible_play_hosts`` は、現在のプレイでアクティブなままになっているすべてのホストの完全なリストです。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:679 +msgid "``ansible_play_batch`` is a list of hostnames that are in scope for the current 'batch' of the play." +msgstr "``ansible_play_batch`` は、現在のプレイの「バッチ」の範囲内にあるホスト名のリストです。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:681 +msgid "The batch size is defined by ``serial``, when not set it is equivalent to the whole play (making it the same as ``ansible_play_hosts``)." +msgstr "バッチサイズは ``serial`` で定義されます。設定されていない場合は、プレイ全体に相当するようになります (``ansible_play_hosts`` と同じになります)。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:683 +msgid "``ansible_playbook_python`` is the path to the python executable used to invoke the Ansible command line tool." +msgstr "``ansible_playbook_python`` は、Ansible コマンドラインツールを起動するのに使用される Python 実行ファイルへのパスです。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:685 +msgid "``inventory_dir`` is the pathname of the directory holding Ansible's inventory host file." +msgstr "``inventory_dir`` は、Ansible のインベントリーホストファイルを保持するディレクトリーのパス名です。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:687 +msgid "``inventory_file`` is the pathname and the filename pointing to the Ansible's inventory host file." +msgstr "``inventory_file`` は、Ansible のインベントリーホストファイルを参照するパス名とファイル名です。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:689 +msgid "``playbook_dir`` contains the playbook base directory." +msgstr "``playbook_dir`` には Playbook のベースディレクトリーが含まれます。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:691 +msgid "``role_path`` contains the current role's pathname and only works inside a role." +msgstr "``role_path`` には現在のロールのパス名が含まれ、ロール内でのみ動作します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:693 +msgid "``ansible_check_mode`` is a boolean, set to ``True`` if you run Ansible with ``--check``." +msgstr "``ansible_check_mode`` が ``--check`` で Ansible を実行する場合は ``True`` に設定します。" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:698 +msgid "Ansible version" +msgstr "Ansible version" + +#: ../../rst/user_guide/playbooks_vars_facts.rst:702 +msgid "To adapt playbook behavior to different versions of Ansible, you can use the variable ``ansible_version``, which has the following structure:" +msgstr "Playbook の動作をさまざまなバージョンの Ansible に適用するには、``ansible_version`` 変数を使用できます。この変数には、以下の構造があります。" + +#: ../../rst/user_guide/playbooks_vault.rst:4 +msgid "Using vault in playbooks" +msgstr "Playbook での Vault の使用" + +#: ../../rst/user_guide/playbooks_vault.rst:6 +msgid "The documentation regarding Ansible Vault has moved. The new location is here: :ref:`vault`. Please update any links you may have made directly to this page." +msgstr "Ansible Vault に関するドキュメントが移動しました。新しい場所は「:ref:`vault`」です。このページに直接作成した可能性のあるリンクを更新してください。" + +#: ../../rst/user_guide/plugin_filtering_config.rst:4 +msgid "Rejecting modules" +msgstr "モジュールの拒否" + +#: ../../rst/user_guide/plugin_filtering_config.rst:6 +msgid "If you want to avoid using certain modules, you can add them to a reject list to prevent Ansible from loading them. To reject plugins, create a yaml configuration file. The default location for this file is :file:`/etc/ansible/plugin_filters.yml`. You can select a different path for the reject list using the :ref:`PLUGIN_FILTERS_CFG` setting in the ``defaults`` section of your ansible.cfg. Here is an example reject list:" +msgstr "特定のモジュールの使用を回避したい場合は、そのモジュールを拒否リストに追加して、Ansible がそのモジュールを読み込まないようにすることができます。プラグインを拒否するには、yaml 設定ファイルを作成します。このファイルのデフォルトの場所は :file:`/etc/ansible/plugin_filters.yml` です。ansible.cfg の ``defaults`` セクションにある :ref:`PLUGIN_FILTERS_CFG` の設定を使用して、拒否リストの別のパスを選択できます。以下に拒否リストの例を示します。" + +#: ../../rst/user_guide/plugin_filtering_config.rst:18 +msgid "The file contains two fields:" +msgstr "このファイルには、2 つのフィールドが含まれています。" + +#: ../../rst/user_guide/plugin_filtering_config.rst:20 +msgid "A file version so that you can update the format while keeping backwards compatibility in the future. The present version should be the string, ``\"1.0\"``" +msgstr "将来的に後方互換性を保ちながら形式を更新できるようにするファイルのバージョン。現在のバージョンは ``\"1.0\"`` 文字列とします。" + +#: ../../rst/user_guide/plugin_filtering_config.rst:22 +msgid "A list of modules to reject. Ansible will not load any module in this list when it searches for a module to invoke for a task." +msgstr "拒否するモジュールのリスト。Ansible は、モジュールを検索してタスクを呼び出すときに、このリストのモジュールを読み込みません。" + +#: ../../rst/user_guide/plugin_filtering_config.rst:26 +msgid "The ``stat`` module is required for Ansible to run. Do not add this module to your reject list." +msgstr "Ansible を実行するには、``stat`` モジュールが必要です。このモジュールを拒否リストに追加しないでください。" + +#: ../../rst/user_guide/sample_setup.rst:5 +msgid "Sample Ansible setup" +msgstr "Ansible 設定の例" + +#: ../../rst/user_guide/sample_setup.rst:7 +msgid "You have learned about playbooks, inventory, roles, and variables. This section pulls all those elements together, outlining a sample setup for automating a web service. You can find more example playbooks illustrating these patterns in our `ansible-examples repository <https://github.com/ansible/ansible-examples>`_. (NOTE: These may not use all of the features in the latest release, but are still an excellent reference!)." +msgstr "ここまで、Playbook、インベントリー、ロール、および変数について学んできました。このセクションでは、これらの要素をまとめて、Web サービスを自動化するためのセットアップのサンプルを紹介します。これらのパターンを示す Playbook の例は、`ansible-examples リポジトリー <https://github.com/ansible/ansible-examples>`_ を参照してください (注: 最新のリリースではすべての機能を使用していない場合がありますが、それでも優れた参考資料となります)。" + +#: ../../rst/user_guide/sample_setup.rst:9 +msgid "The sample setup organizes playbooks, roles, inventory, and variables files by function, with tags at the play and task level for greater granularity and control. This is a powerful and flexible approach, but there are other ways to organize Ansible content. Your usage of Ansible should fit your needs, not ours, so feel free to modify this approach and organize your content as you see fit." +msgstr "サンプルの設定では、Playbook、ロール、インベントリー、変数ファイルを機能別に整理し、プレイやタスクのレベルでタグを付けて、より詳細にコントロールしています。これは強力で柔軟なアプローチですが、Ansible のコンテンツを整理する方法は他にもあります。Ansible の使用方法は、私たちのニーズではなく、使用する人や組織のニーズに合わせる必要があります。したがって、このアプローチを自由に変更して、コンテンツを適切に整理してください。" + +#: ../../rst/user_guide/sample_setup.rst:15 +msgid "Sample directory layout" +msgstr "ディレクトリーレイアウトの例" + +#: ../../rst/user_guide/sample_setup.rst:17 +msgid "This layout organizes most tasks in roles, with a single inventory file for each environment and a few playbooks in the top-level directory:" +msgstr "このレイアウトでは、ほとんどのタスクがロールごとに整理されており、環境ごとに 1 つのインベントリーファイルを作成し、トップレベルのディレクトリーにいくつかの Playbook を置いています。" + +#: ../../rst/user_guide/sample_setup.rst:42 +msgid "By default, Ansible assumes your playbooks are stored in one directory with roles stored in a sub-directory called ``roles/``. As you use Ansible to automate more tasks, you may want to move your playbooks into a sub-directory called ``playbooks/``. If you do this, you must configure the path to your ``roles/`` directory using the ``roles_path`` setting in ansible.cfg." +msgstr "デフォルトでは、Ansible は、Playbook が ``roles/`` という名前のサブディレクトリーに保存されているロールを持つ 1 つのディレクトリーに保存されていることを前提とします。Ansible を使用してより多くのタスクを自動化する場合は、Playbook を ``playbooks/`` と呼ばれるサブディレクトリーに移動したい場合があります。これを行う場合は、ansible.cfg の ``roles_path`` の設定を使用して、``roles/`` ディレクトリーへのパスを設定する必要があります。" + +#: ../../rst/user_guide/sample_setup.rst:45 +msgid "Alternative directory layout" +msgstr "代替ディレクトリーレイアウト" + +#: ../../rst/user_guide/sample_setup.rst:47 +msgid "Alternatively you can put each inventory file with its ``group_vars``/``host_vars`` in a separate directory. This is particularly useful if your ``group_vars``/``host_vars`` don't have that much in common in different environments. The layout could look something like this:" +msgstr "また、``group_vars``/``host_vars`` を含む各インベントリーファイルを別のディレクトリーに置くこともできます。これは、``group_vars``/``host_vars`` が異なる環境であまり共通していない場合に特に有効です。レイアウトは以下のようになります。" + +#: ../../rst/user_guide/sample_setup.rst:84 +msgid "This layout gives you more flexibility for larger environments, as well as a total separation of inventory variables between different environments. However, this approach is harder to maintain, because there are more files. For more information on organizing group and host variables, see :ref:`splitting_out_vars`." +msgstr "このレイアウトにより、大規模な環境にも柔軟に対応することができ、異なる環境間でインベントリー変数を完全に分離することができます。しかし、この方法では、ファイル数が多くなるため、メンテナンスが難しくなります。グループ変数とホスト変数の整理の詳細は、「:ref:`splitting_out_vars`」を参照してください。" + +#: ../../rst/user_guide/sample_setup.rst:89 +msgid "Sample group and host variables" +msgstr "グループ変数およびホスト変数の例" + +#: ../../rst/user_guide/sample_setup.rst:91 +msgid "These sample group and host variables files record the variable values that apply to each machine or group of machines. For instance, the data center in Atlanta has its own NTP servers, so when setting up ntp.conf, we should use them:" +msgstr "これらのグループ変数とホスト変数のサンプルファイルには、各マシンやマシングループに適用される変数の値が記録されています。たとえば、アトランタのデータセンターには独自の NTP サーバーがあるため、ntp.conf を設定する際には、それらを使用する必要があります。" + +#: ../../rst/user_guide/sample_setup.rst:100 +msgid "Similarly, the webservers have some configuration that does not apply to the database servers:" +msgstr "同様に、Web サーバーには、データベースサーバーには適用されない以下のような設定があります。" + +#: ../../rst/user_guide/sample_setup.rst:109 +msgid "Default values, or values that are universally true, belong in a file called group_vars/all:" +msgstr "デフォルト値または汎用的に true である値がある場合は、それらを group_vars/all というファイルに配置します。" + +#: ../../rst/user_guide/sample_setup.rst:118 +msgid "If necessary, you can define specific hardware variance in systems in a host_vars file:" +msgstr "必要に応じて、システムの特定のハードウェアの差異を host_vars ファイルに定義することができます。" + +#: ../../rst/user_guide/sample_setup.rst:127 +msgid "Again, if you are using :ref:`dynamic inventory <dynamic_inventory>`, Ansible creates many dynamic groups automatically. So a tag like \"class:webserver\" would load in variables from the file \"group_vars/ec2_tag_class_webserver\" automatically." +msgstr "繰り返しになりますが、:ref:`動的インベントリー <dynamic_inventory>` を使用している場合、Ansible は多くの動的グループを自動的に作成します。つまり、「class:webserver」のようなタグは、「group_vars/ec2_tag_class_webserver」ファイルから変数を自動的に読み込むことになります。" + +#: ../../rst/user_guide/sample_setup.rst:132 +msgid "Sample playbooks organized by function" +msgstr "関数別に整理された Playbook のサンプル" + +#: ../../rst/user_guide/sample_setup.rst:134 +msgid "With this setup, a single playbook can define all the infrastructure. The site.yml playbook imports two other playbooks, one for the webservers and one for the database servers:" +msgstr "この設定では、1 つの Playbook ですべてのインフラストラクチャーを定義することができます。Playbook site.yml は、Web サーバー用とデータベースサーバー用の 2 つの Playbook をインポートしています。" + +#: ../../rst/user_guide/sample_setup.rst:143 +msgid "The webservers.yml file, also at the top level, maps the configuration of the webservers group to the roles related to the webservers group:" +msgstr "同じくトップレベルにある webservers.yml ファイルは、webservers グループの設定を、webservers グループに関連するロールにマッピングします。" + +#: ../../rst/user_guide/sample_setup.rst:154 +msgid "With this setup, you can configure your whole infrastructure by \"running\" site.yml, or run a subset by running webservers.yml. This is analogous to the Ansible \"--limit\" parameter but a little more explicit:" +msgstr "この設定により、site.yml を「実行」してインフラストラクチャー全体を設定したり、webservers.yml を実行してサブセットを設定したりすることができます。これは、Ansible の「--limit」パラメーターに似ていますが、もう少し明確になっています。" + +#: ../../rst/user_guide/sample_setup.rst:164 +msgid "Sample task and handler files in a function-based role" +msgstr "関数ベースのロール内のタスクおよびハンドラーのサンプルファイル" + +#: ../../rst/user_guide/sample_setup.rst:166 +msgid "Ansible loads any file called ``main.yml`` in a role sub-directory. This sample ``tasks/main.yml`` file is simple - it sets up NTP, but it could do more if we wanted:" +msgstr "Ansible は、ロールのサブディレクトリーにある ``main.yml`` ファイルを読み込みます。このサンプルの ``tasks/main.yml`` ファイルは、NTP を設定するというシンプルなものですが、必要に応じてもっと多くのことができます。" + +#: ../../rst/user_guide/sample_setup.rst:194 +msgid "Here is an example handlers file. As a review, handlers are only fired when certain tasks report changes, and are run at the end of each play:" +msgstr "ハンドラーファイルの例を紹介します。レビューとして、ハンドラーは特定のタスクが変更を報告したときにのみ起動し、各プレイの最後に実行します。" + +#: ../../rst/user_guide/sample_setup.rst:206 +msgid "See :ref:`playbooks_reuse_roles` for more information." +msgstr "詳細は、「:ref:`playbooks_reuse_roles`」を参照してください。" + +#: ../../rst/user_guide/sample_setup.rst:212 +msgid "What the sample setup enables" +msgstr "設定例の有効化" + +#: ../../rst/user_guide/sample_setup.rst:214 +msgid "The basic organizational structure described above enables a lot of different automation options. To reconfigure your entire infrastructure:" +msgstr "上記の基本的な組織構造により、多くの異なる自動化オプションが可能になります。インフラストラクチャー全体を再構成するには、以下のようになります。" + +#: ../../rst/user_guide/sample_setup.rst:220 +msgid "To reconfigure NTP on everything:" +msgstr "全面的に NTP を再設定するには、以下を実行します。" + +#: ../../rst/user_guide/sample_setup.rst:226 +msgid "To reconfigure only the webservers:" +msgstr "webservers のみを再設定するには、以下を実行します。" + +#: ../../rst/user_guide/sample_setup.rst:232 +msgid "To reconfigure only the webservers in Boston:" +msgstr "Boston で webservers のみを再設定するには、以下を実行します。" + +#: ../../rst/user_guide/sample_setup.rst:238 +msgid "To reconfigure only the first 10 webservers in Boston, and then the next 10:" +msgstr "Boston で最初の 10 台の webservers だけを再設定し、次の 10 台は、以下のようにします。" + +#: ../../rst/user_guide/sample_setup.rst:245 +msgid "The sample setup also supports basic ad hoc commands:" +msgstr "設定例では、基本的なアドホックコマンドもサポートします。" + +#: ../../rst/user_guide/sample_setup.rst:252 +msgid "To discover what tasks would run or what hostnames would be affected by a particular Ansible command:" +msgstr "実行するタスクまたは特定の Ansible コマンドの影響を受けるホスト名を検出するには、以下を実行します。" + +#: ../../rst/user_guide/sample_setup.rst:265 +msgid "Organizing for deployment or configuration" +msgstr "デプロイメントまたは設定の整理" + +#: ../../rst/user_guide/sample_setup.rst:267 +msgid "The sample setup models a typical configuration topology. When doing multi-tier deployments, there are going to be some additional playbooks that hop between tiers to roll out an application. In this case, 'site.yml' may be augmented by playbooks like 'deploy_exampledotcom.yml' but the general concepts still apply. Ansible allows you to deploy and configure using the same tool, so you would likely reuse groups and keep the OS configuration in separate playbooks or roles from the app deployment." +msgstr "このサンプルでは、典型的な設定トポロジーをモデル化しています。複数階層のデプロイメントを行う場合は、アプリケーションを展開するために階層間を行き来する Playbook が追加されることがあります。この場合、「site.yml」には「deploy_exampledotcom.yml」などの Playbook が追加されますが、一般的な概念は変わりません。Ansible では、デプロイと設定を同じツールで行うことができるため、グループを再利用したり、OS の設定をアプリのデプロイとは別の Playbook やロールにまとめたりすることが考えられます。" + +#: ../../rst/user_guide/sample_setup.rst:271 +msgid "Consider \"playbooks\" as a sports metaphor -- you can have one set of plays to use against all your infrastructure and situational plays that you use at different times and for different purposes." +msgstr "「Playbook」をスポーツに例えて考えてみましょう。すべてのインフラストラクチャーに対して使用する 1 セットのプレイと、時と場合に応じて使用する状況に応じたプレイがあります。" + +#: ../../rst/user_guide/sample_setup.rst:276 +msgid "Using local Ansible modules" +msgstr "ローカル Ansible モジュールの使用" + +#: ../../rst/user_guide/sample_setup.rst:278 +msgid "If a playbook has a :file:`./library` directory relative to its YAML file, this directory can be used to add Ansible modules that will automatically be in the Ansible module path. This is a great way to keep modules that go with a playbook together. This is shown in the directory structure example at the start of this section." +msgstr "Playbook に、YAML ファイルに相対する :file:`./library` ディレクトリーがある場合は、このディレクトリーを使用して、自動的に Ansible モジュールパスに含まれる Ansible モジュールを追加することができます。これは、Playbook に付随するモジュールをまとめておくのに最適な方法です。これは、このセクションの最初にあるディレクトリー構造の例で示されています。" + +#: ../../rst/user_guide/vault.rst:5 ../../rst/user_guide/vault.rst:121 +msgid "Encrypting content with Ansible Vault" +msgstr "Ansible Vault を使用したコンテンツの暗号化" + +#: ../../rst/user_guide/vault.rst:7 +msgid "Ansible Vault encrypts variables and files so you can protect sensitive content such as passwords or keys rather than leaving it visible as plaintext in playbooks or roles. To use Ansible Vault you need one or more passwords to encrypt and decrypt content. If you store your vault passwords in a third-party tool such as a secret manager, you need a script to access them. Use the passwords with the :ref:`ansible-vault` command-line tool to create and view encrypted variables, create encrypted files, encrypt existing files, or edit, re-key, or decrypt files. You can then place encrypted content under source control and share it more safely." +msgstr "Ansible Vault は変数やファイルを暗号化するため、パスワードや鍵などの機密コンテンツを Playbook やロールの中で平文のまま放置することなく保護することができます。Ansible Vault を使用するには、コンテンツを暗号化および復号を行うために 1 つ以上のパスワードが必要です。シークレットマネージャーなどのサードパーティーツールに Vault のパスワードを保存している場合は、そのパスワードにアクセスするためのスクリプトが必要です。:ref:`ansible-vault` コマンドラインツールでパスワードを使用して、暗号化された変数の作成と表示、暗号化されたファイルの作成、既存ファイルの暗号化、またはファイルの編集、鍵の再設定、復号を行います。また、暗号化されたコンテンツをソースコントロール下に置き、より安全に共有することができます。" + +#: ../../rst/user_guide/vault.rst:10 +msgid "Encryption with Ansible Vault ONLY protects 'data at rest'. Once the content is decrypted ('data in use'), play and plugin authors are responsible for avoiding any secret disclosure, see :ref:`no_log <keep_secret_data>` for details on hiding output and :ref:`vault_securing_editor` for security considerations on editors you use with Ansible Vault." +msgstr "Ansible Vault による暗号化は、「静止状態のデータ」のみを保護します。コンテンツが復号化された後 (「使用中のデータ」)、プレイやプラグインの作者は、秘密の漏洩を回避する責任があります。出力の非表示に関する詳細は「:ref:`no_log <keep_secret_data>`」を、Ansible Vault で使用するエディターのセキュリティーに関する考慮点は「:ref:`vault_securing_editor`」を参照してください。" + +#: ../../rst/user_guide/vault.rst:12 +msgid "You can use encrypted variables and files in ad hoc commands and playbooks by supplying the passwords you used to encrypt them. You can modify your ``ansible.cfg`` file to specify the location of a password file or to always prompt for the password." +msgstr "暗号化された変数やファイルは、暗号化に使用したパスワードを入力することで、アドホックコマンドや Playbook で使用することができます。``ansible.cfg`` ファイルを変更して、パスワードファイルの場所を指定したり、常にパスワードの入力を促すようにすることができます。" + +#: ../../rst/user_guide/vault.rst:18 +msgid "Managing vault passwords" +msgstr "Vault パスワードの管理" + +#: ../../rst/user_guide/vault.rst:20 +msgid "Managing your encrypted content is easier if you develop a strategy for managing your vault passwords. A vault password can be any string you choose. There is no special command to create a vault password. However, you need to keep track of your vault passwords. Each time you encrypt a variable or file with Ansible Vault, you must provide a password. When you use an encrypted variable or file in a command or playbook, you must provide the same password that was used to encrypt it. To develop a strategy for managing vault passwords, start with two questions:" +msgstr "暗号化されたコンテンツを管理するには、Vault のパスワードを管理するためのストラテジーを立てるとよいでしょう。Vault パスワードは任意の文字列です。Vault パスワードを作成するための特別なコマンドはありません。しかし、Vault パスワードを管理する必要があります。Ansible Vault で変数やファイルを暗号化する際は、毎回パスワードを入力する必要があります。暗号化された変数やファイルをコマンドや Playbook で使用する際には、暗号化に使用したパスワードを入力する必要があります。Vault のパスワードを管理するためのストラテジーを立てるには、次の 2 つの質問から始めます。" + +#: ../../rst/user_guide/vault.rst:22 +msgid "Do you want to encrypt all your content with the same password, or use different passwords for different needs?" +msgstr "同じパスワードですべてのコンテンツを暗号化する必要がりますか。または、異なるニーズに合わせて異なるパスワードを使用しますか" + +#: ../../rst/user_guide/vault.rst:23 +msgid "Where do you want to store your password or passwords?" +msgstr "パスワードをどこに保存しますか。" + +#: ../../rst/user_guide/vault.rst:26 +msgid "Choosing between a single password and multiple passwords" +msgstr "1 つのパスワードと複数のパスワードの選択" + +#: ../../rst/user_guide/vault.rst:28 +msgid "If you have a small team or few sensitive values, you can use a single password for everything you encrypt with Ansible Vault. Store your vault password securely in a file or a secret manager as described below." +msgstr "少人数のチームや機密性の高い値が少ない場合は、Ansible Vault で暗号化するすべてのものに 1 つのパスワードを使用することができます。Vault のパスワードは、後述するようにファイルやシークレットマネージャーに安全に保管してください。" + +#: ../../rst/user_guide/vault.rst:30 +msgid "If you have a larger team or many sensitive values, you can use multiple passwords. For example, you can use different passwords for different users or different levels of access. Depending on your needs, you might want a different password for each encrypted file, for each directory, or for each environment. For example, you might have a playbook that includes two vars files, one for the dev environment and one for the production environment, encrypted with two different passwords. When you run the playbook, select the correct vault password for the environment you are targeting, using a vault ID." +msgstr "チームの規模が大きかったり、機密性の高い値が多い場合は、複数のパスワードを使用することができます。たとえば、ユーザーやアクセスレベルごとに異なるパスワードを使用することができます。必要に応じて、暗号化したファイルごと、ディレクトリーごと、あるいは環境ごとに異なるパスワードが必要になる場合があります。たとえば、開発環境用と実稼働環境用の 2 つの vars ファイルを含む Playbook を作成し、2 つの異なるパスワードで暗号化する場合などです。Playbook を実行する際には、Vault ID を使用して、対象となる環境に適した Vault パスワードを選択します。" + +#: ../../rst/user_guide/vault.rst:35 +msgid "Managing multiple passwords with vault IDs" +msgstr "Vault ID を使用した複数パスワードの管理" + +#: ../../rst/user_guide/vault.rst:37 +msgid "If you use multiple vault passwords, you can differentiate one password from another with vault IDs. You use the vault ID in three ways:" +msgstr "複数の Vault パスワードを使用する場合は、Vault ID から別のパスワードを区別することができます。以下の 3 つの方法で Vault ID を使用します。" + +#: ../../rst/user_guide/vault.rst:39 +msgid "Pass it with :option:`--vault-id <ansible-playbook --vault-id>` to the :ref:`ansible-vault` command when you create encrypted content" +msgstr "暗号化されたコンテンツの作成時に、:option:`--vault-id <ansible-playbook --vault-id>` を :ref:`ansible-vault` コマンドに渡します。" + +#: ../../rst/user_guide/vault.rst:40 +msgid "Include it wherever you store the password for that vault ID (see :ref:`storing_vault_passwords`)" +msgstr "その Vault ID のパスワードを保存する場所を追加します (「:ref:`storing_vault_passwords`」を参照)。" + +#: ../../rst/user_guide/vault.rst:41 +msgid "Pass it with :option:`--vault-id <ansible-playbook --vault-id>` to the :ref:`ansible-playbook` command when you run a playbook that uses content you encrypted with that vault ID" +msgstr "Vault ID で暗号化されたコンテンツを使用する Playbook を実行する際に、これを :option:`--vault-id <ansible-playbook --vault-id>` で :ref:`ansible-playbook` コマンドに渡します。" + +#: ../../rst/user_guide/vault.rst:43 +msgid "When you pass a vault ID as an option to the :ref:`ansible-vault` command, you add a label (a hint or nickname) to the encrypted content. This label documents which password you used to encrypt it. The encrypted variable or file includes the vault ID label in plain text in the header. The vault ID is the last element before the encrypted content. For example:" +msgstr ":ref:`ansible-vault` コマンドのオプションとして Vault ID を渡すと、暗号化されたコンテンツにラベル (ヒントやニックネーム) が追加されます。このラベルは、どのパスワードを使用して暗号化したかを記録します。暗号化された変数やファイルは、ヘッダーに平文で Vault ID ラベルを含みます。Vault ID は暗号化されたコンテンツの前の最後の要素です。以下に例を示します。" + +#: ../../rst/user_guide/vault.rst:55 +msgid "In addition to the label, you must provide a source for the related password. The source can be a prompt, a file, or a script, depending on how you are storing your vault passwords. The pattern looks like this:" +msgstr "ラベルに加えて、関連するパスワードのソースを提供する必要があります。ソースは、Vault パスワードをどのように保存するかによって、プロンプト、ファイル、またはスクリプトになります。パターンは次のようになります。" + +#: ../../rst/user_guide/vault.rst:61 +msgid "If your playbook uses multiple encrypted variables or files that you encrypted with different passwords, you must pass the vault IDs when you run that playbook. You can use :option:`--vault-id <ansible-playbook --vault-id>` by itself, with :option:`--vault-password-file <ansible-playbook --vault-password-file>`, or with :option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>`. The pattern is the same as when you create encrypted content: include the label and the source for the matching password." +msgstr "Playbook が複数の暗号化された変数や、異なるパスワードで暗号化したファイルを使用する場合は、その Playbook を実行する際に Vault ID を渡す必要があります。:option:`--vault-id <ansible-playbook --vault-id>` を単独で、もしくは :option:`--vault-password-file <ansible-playbook --vault-password-file>` または :option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>` と一緒に使用することができます。パターンは、暗号化されたコンテンツを作成するときと同じで、一致するパスワードのラベルとソースを含めます。" + +#: ../../rst/user_guide/vault.rst:63 +msgid "See below for examples of encrypting content with vault IDs and using content encrypted with vault IDs. The :option:`--vault-id <ansible-playbook --vault-id>` option works with any Ansible command that interacts with vaults, including :ref:`ansible-vault`, :ref:`ansible-playbook`, and so on." +msgstr "Vault ID でコンテンツを暗号化する例と、Vault ID で暗号化されたコンテンツを使用する例については、以下を参照してください。:option:`--vault-id <ansible-playbook --vault-id>` オプションは、:ref:`ansible-vault`、:ref:`ansible-playbook` など、Vault と相互作用するすべての Ansible コマンドで動作します。" + +#: ../../rst/user_guide/vault.rst:66 +msgid "Limitations of vault IDs" +msgstr "Vault ID の制限" + +#: ../../rst/user_guide/vault.rst:68 +msgid "Ansible does not enforce using the same password every time you use a particular vault ID label. You can encrypt different variables or files with the same vault ID label but different passwords. This usually happens when you type the password at a prompt and make a mistake. It is possible to use different passwords with the same vault ID label on purpose. For example, you could use each label as a reference to a class of passwords, rather than a single password. In this scenario, you must always know which specific password or file to use in context. However, you are more likely to encrypt two files with the same vault ID label and different passwords by mistake. If you encrypt two files with the same label but different passwords by accident, you can :ref:`rekey <rekeying_files>` one file to fix the issue." +msgstr "Ansible は、特定の Vault ID ラベルを使用するたびに同じパスワードを使用することを強制しません。異なる変数やファイルを、同じ Vault ID ラベルで異なるパスワードを使用して暗号化することができます。これは通常、プロンプトでパスワードを入力して間違えた場合に起こります。意図的に、同じ Vault ID ラベルで異なるパスワードを使用することは可能です。たとえば、各ラベルを、単一のパスワードではなく、パスワードのクラスへの参照として使用することができます。このシナリオでは、どの特定のパスワードまたはファイルを使用するかを常にコンテキストで知っておく必要があります。しかし、誤って同じ Vault ID ラベルと異なるパスワードを使用する 2 つのファイルを暗号化してしまう可能性が高くなります。誤って同じラベルで異なるパスワードの 2 つのファイルを暗号化してしまった場合は、1つのファイルで :ref:`rekey <rekeying_files>` を行って問題を解決できます。" + +#: ../../rst/user_guide/vault.rst:71 +msgid "Enforcing vault ID matching" +msgstr "Vault ID 一致の強制" + +#: ../../rst/user_guide/vault.rst:73 +msgid "By default the vault ID label is only a hint to remind you which password you used to encrypt a variable or file. Ansible does not check that the vault ID in the header of the encrypted content matches the vault ID you provide when you use the content. Ansible decrypts all files and variables called by your command or playbook that are encrypted with the password you provide. To check the encrypted content and decrypt it only when the vault ID it contains matches the one you provide with ``--vault-id``, set the config option :ref:`DEFAULT_VAULT_ID_MATCH`. When you set :ref:`DEFAULT_VAULT_ID_MATCH`, each password is only used to decrypt data that was encrypted with the same label. This is efficient, predictable, and can reduce errors when different values are encrypted with different passwords." +msgstr "デフォルトでは、Vault ID ラベルは、変数やファイルの暗号化にどのパスワードを使用したかを思い出させるためのヒントに過ぎません。Ansible は、暗号化されたコンテンツのヘッダーにある Vault ID が、コンテンツの使用時に指定した Vault ID と一致するかどうかはチェックしません。Ansible は、指定したパスワードで暗号化されたコマンドまたは Playbook によって呼び出されたすべてのファイルおよび変数を復号します。暗号化されたコンテンツをチェックし、コンテンツに含まれる Vault ID が ``--vault-id`` で指定したものと一致した場合にのみ暗号化を解除するには、設定オプション :ref:`DEFAULT_VAULT_ID_MATCH` を設定します。:ref:`DEFAULT_VAULT_ID_MATCH` を設定すると、各パスワードは同じラベルで暗号化したデータを復号するためにのみ使用されます。これは効率的で予測可能であり、異なる値が異なるパスワードで暗号化された場合のエラーを減らすことができます。" + +#: ../../rst/user_guide/vault.rst:76 +msgid "Even with the :ref:`DEFAULT_VAULT_ID_MATCH` setting enabled, Ansible does not enforce using the same password every time you use a particular vault ID label." +msgstr ":ref:`DEFAULT_VAULT_ID_MATCH` の設定が有効になっている場合でも、特定の Vault ID ラベルを使用するたびに、Ansible は同じパスワードの使用を強制しません。" + +#: ../../rst/user_guide/vault.rst:81 +msgid "Storing and accessing vault passwords" +msgstr "Vault パスワードの保存およびアクセス" + +#: ../../rst/user_guide/vault.rst:83 +msgid "You can memorize your vault password, or manually copy vault passwords from any source and paste them at a command-line prompt, but most users store them securely and access them as needed from within Ansible. You have two options for storing vault passwords that work from within Ansible: in files, or in a third-party tool such as the system keyring or a secret manager. If you store your passwords in a third-party tool, you need a vault password client script to retrieve them from within Ansible." +msgstr "Valut パスワードを記憶したり、Valut パスワードを任意のソースから手動でコピーしてコマンドラインプロンプトに貼り付けたりすることもできますが、ほとんどのユーザーは安全に保管し、必要に応じて Ansible 内からアクセスします。Ansible 内で機能する Valut パスワードの保管方法には、ファイルに保管する方法と、システムキーリングやシークレットマネージャーなどのサードパーティーツールに保管する方法があります。サードパーティーのツールにパスワードを保存する場合、Ansible 内からパスワードを取得するには、Vault パスワードクライアントスクリプトが必要です。" + +#: ../../rst/user_guide/vault.rst:86 +msgid "Storing passwords in files" +msgstr "パスワードのファイルへの保存" + +#: ../../rst/user_guide/vault.rst:88 +msgid "To store a vault password in a file, enter the password as a string on a single line in the file. Make sure the permissions on the file are appropriate. Do not add password files to source control." +msgstr "Vault のパスワードをファイルに保存するには、ファイルの 1 行にパスワードを文字列で入力します。ファイルのパーミッションが適切であることを確認してください。パスワードファイルをソースコントロールに追加しないでください。" + +#: ../../rst/user_guide/vault.rst:93 +msgid "Storing passwords in third-party tools with vault password client scripts" +msgstr "Vault パスワードクライアントスクリプトを使用したサードパーティーツールへのパスワードの保存" + +#: ../../rst/user_guide/vault.rst:95 +msgid "You can store your vault passwords on the system keyring, in a database, or in a secret manager and retrieve them from within Ansible using a vault password client script. Enter the password as a string on a single line. If your password has a vault ID, store it in a way that works with your password storage tool." +msgstr "Valut パスワードは、システムキーリング、データベース、またはシークレットマネージャーに保存し、Valut パスワードクライアントスクリプトを使用して Ansible 内から取り出すことができます。パスワードは 1 行の文字列として入力します。パスワードに Vault ID がある場合は、パスワード保存ツールと連携する方法で保存します。" + +#: ../../rst/user_guide/vault.rst:97 +msgid "To create a vault password client script:" +msgstr "Vault パスワードクライアントスクリプトを作成するには、以下のようにします。" + +#: ../../rst/user_guide/vault.rst:99 +msgid "Create a file with a name ending in either ``-client`` or ``-client.EXTENSION``" +msgstr "``-client`` または ``-client.EXTENSION`` で終わる名前でファイルを作成します。" + +#: ../../rst/user_guide/vault.rst:100 +msgid "Make the file executable" +msgstr "ファイルを実行可能な状態にします。" + +#: ../../rst/user_guide/vault.rst:104 +msgid "Within the script itself:" +msgstr "スクリプト自体:" + +#: ../../rst/user_guide/vault.rst:102 +msgid "Print the passwords to standard output" +msgstr "標準出力にパスワードを出力します。" + +#: ../../rst/user_guide/vault.rst:103 +msgid "Accept a ``--vault-id`` option" +msgstr "``--vault-id`` オプションを許可します。" + +#: ../../rst/user_guide/vault.rst:104 +msgid "If the script prompts for data (for example, a database password), display the prompts to the TTY." +msgstr "スクリプトがデータ (データベースパスワードなど) の入力を求める場合は、TTY にプロンプトが表示されます。" + +#: ../../rst/user_guide/vault.rst:106 +msgid "When you run a playbook that uses vault passwords stored in a third-party tool, specify the script as the source within the ``--vault-id`` flag. For example:" +msgstr "サードパーティーのツールに保存されている Vault パスワードを使用する Playbook を実行する場合は、``--vault-id`` フラグ内でスクリプトをソースとして指定します。以下を例に示します。" + +#: ../../rst/user_guide/vault.rst:112 +msgid "Ansible executes the client script with a ``--vault-id`` option so the script knows which vault ID label you specified. For example a script loading passwords from a secret manager can use the vault ID label to pick either the 'dev' or 'prod' password. The example command above results in the following execution of the client script:" +msgstr "Ansible はクライアントスクリプトを ``--vault-id`` オプション付きで実行するため、スクリプトは指定された Vault ID ラベルを知ることができます。たとえば、シークレットマネージャーからパスワードを読み込むスクリプトは、Vault ID ラベルを使用して、「dev」または「prod」のいずれかのパスワードを選択できます。上記のコマンドの例では、クライアントスクリプトの実行結果は次のようになります。" + +#: ../../rst/user_guide/vault.rst:118 +msgid "For an example of a client script that loads passwords from the system keyring, see the `vault-keyring-client script <https://github.com/ansible-community/contrib-scripts/blob/main/vault/vault-keyring-client.py>`_." +msgstr "システムキーリングからパスワードを読み込むクライアントスクリプトの例は、:file:`vault-keyring-client script <https://github.com/ansible-community/contrib-scripts/blob/main/vault/vault-keyring-client.py>` を参照してください。" + +#: ../../rst/user_guide/vault.rst:123 +msgid "Once you have a strategy for managing and storing vault passwords, you can start encrypting content. You can encrypt two types of content with Ansible Vault: variables and files. Encrypted content always includes the ``!vault`` tag, which tells Ansible and YAML that the content needs to be decrypted, and a ``|`` character, which allows multi-line strings. Encrypted content created with ``--vault-id`` also contains the vault ID label. For more details about the encryption process and the format of content encrypted with Ansible Vault, see :ref:`vault_format`. This table shows the main differences between encrypted variables and encrypted files:" +msgstr "Vault のパスワードを管理および保管するためのストラテジーができたら、コンテンツの暗号化を開始できます。Ansible Vault では、変数とファイルの 2 種類のコンテンツを暗号化することができます。暗号化されたコンテンツには、必ず ``!vault`` タグが含まれます。これは、コンテンツの復号が必要であることを Ansible と YAML に伝えるもので、複数行の文字列を可能にする ``|`` 文字も含まれています。``--vault-id`` で作成された暗号化コンテンツには、Vault ID ラベルも含まれます。Ansible Vault における暗号化プロセスと形式の詳細は、「:ref:`vault_format`」を参照してください。この表は、暗号化された変数と暗号化されたファイルの主な違いを示しています。" + +#: ../../rst/user_guide/vault.rst:129 +msgid "Encrypted variables" +msgstr "暗号化された変数" + +#: ../../rst/user_guide/vault.rst:129 +msgid "Encrypted files" +msgstr "暗号化されたファイル" + +#: ../../rst/user_guide/vault.rst:131 +msgid "How much is encrypted?" +msgstr "どのくらい暗号化されているのか" + +#: ../../rst/user_guide/vault.rst:131 +msgid "Variables within a plaintext file" +msgstr "平文ファイル内の変数" + +#: ../../rst/user_guide/vault.rst:131 +msgid "The entire file" +msgstr "ファイル全体" + +#: ../../rst/user_guide/vault.rst:133 +msgid "When is it decrypted?" +msgstr "復号するタイミング" + +#: ../../rst/user_guide/vault.rst:133 +msgid "On demand, only when needed" +msgstr "オンデマンドで (必要な場合にのみ)" + +#: ../../rst/user_guide/vault.rst:133 +msgid "Whenever loaded or referenced [#f1]_" +msgstr "読み込みまたは参照する場合 [#f1]_" + +#: ../../rst/user_guide/vault.rst:135 +msgid "What can be encrypted?" +msgstr "暗号化できるもの" + +#: ../../rst/user_guide/vault.rst:135 +msgid "Only variables" +msgstr "変数のみ" + +#: ../../rst/user_guide/vault.rst:135 +msgid "Any structured data file" +msgstr "構造化データファイル" + +#: ../../rst/user_guide/vault.rst:139 +msgid "Ansible cannot know if it needs content from an encrypted file unless it decrypts the file, so it decrypts all encrypted files referenced in your playbooks and roles." +msgstr "Ansible は、ファイルを復号しない限り、暗号化されたファイルからコンテンツを必要とするかどうかを認識できないため、Playbook およびロールで参照される暗号化されたファイルをすべて復号します。" + +#: ../../rst/user_guide/vault.rst:145 +msgid "Encrypting individual variables with Ansible Vault" +msgstr "Ansible Vault による個々の変数の暗号化" + +#: ../../rst/user_guide/vault.rst:147 +msgid "You can encrypt single values inside a YAML file using the :ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` command. For one way to keep your vaulted variables safely visible, see :ref:`tip_for_variables_and_vaults`." +msgstr ":ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` コマンドを使用して、YAML ファイル内で 1 つの値を暗号化することができます。Vault を使用した変数を安全に表示できる方法は、「:ref:`tip_for_variables_and_vaults`」を参照してください。" + +#: ../../rst/user_guide/vault.rst:150 +msgid "Advantages and disadvantages of encrypting variables" +msgstr "変数を暗号化することの利点および欠点" + +#: ../../rst/user_guide/vault.rst:152 +msgid "With variable-level encryption, your files are still easily legible. You can mix plaintext and encrypted variables, even inline in a play or role. However, password rotation is not as simple as with file-level encryption. You cannot :ref:`rekey <rekeying_files>` encrypted variables. Also, variable-level encryption only works on variables. If you want to encrypt tasks or other content, you must encrypt the entire file." +msgstr "変数レベルの暗号化では、ファイルを簡単に読み取ることができます。平文の変数と暗号化された変数を混在させることができ、プレイやロールの中でインラインでも使用できます。しかし、パスワードのローテーションはファイルレベルの暗号化のように簡単ではありません。暗号化された変数に :ref:`鍵の再設定 <rekeying_files>` は使用できません。また、変数レベルの暗号化は変数に対してのみ機能します。タスクやその他のコンテンツを暗号化する場合は、ファイル全体を暗号化する必要があります。" + +#: ../../rst/user_guide/vault.rst:157 +msgid "Creating encrypted variables" +msgstr "暗号化されたファイルの作成" + +#: ../../rst/user_guide/vault.rst:159 +msgid "The :ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` command encrypts and formats any string you type (or copy or generate) into a format that can be included in a playbook, role, or variables file. To create a basic encrypted variable, pass three options to the :ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` command:" +msgstr ":ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` コマンドは、入力 (もしくはコピーまたは生成) した文字列を暗号化して、Playbook、ロール、変数ファイルに含めることができる形式にします。基本的な暗号化変数を作成するには、:ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` コマンドに 3 つのオプションを渡します。" + +#: ../../rst/user_guide/vault.rst:161 +msgid "a source for the vault password (prompt, file, or script, with or without a vault ID)" +msgstr "Vault パスワードのソース (プロンプト、ファイル、またはスクリプト、Vault ID あり/なし)" + +#: ../../rst/user_guide/vault.rst:162 +msgid "the string to encrypt" +msgstr "暗号化する文字列" + +#: ../../rst/user_guide/vault.rst:163 +msgid "the string name (the name of the variable)" +msgstr "文字列名 (変数の名前)" + +#: ../../rst/user_guide/vault.rst:165 +msgid "The pattern looks like this:" +msgstr "パターンは以下のようになります。" + +#: ../../rst/user_guide/vault.rst:171 +msgid "For example, to encrypt the string 'foobar' using the only password stored in 'a_password_file' and name the variable 'the_secret':" +msgstr "たとえば、「a_password_file」に保存されたパスワードのみを使用して文字列を「foobar」を暗号化する際に、変数「the_secret」に名前を付けます。" + +#: ../../rst/user_guide/vault.rst:177 ../../rst/user_guide/vault.rst:195 +msgid "The command above creates this content:" +msgstr "上記のコマンドにより、以下のような内容が作成されます。" + +#: ../../rst/user_guide/vault.rst:189 +msgid "To encrypt the string 'foooodev', add the vault ID label 'dev' with the 'dev' vault password stored in 'a_password_file', and call the encrypted variable 'the_dev_secret':" +msgstr "文字列「foooodev」を暗号化するには、Vault ID ラベル「dev」に「a_password_file」に格納されている「dev」の Vault パスワードを追加し、暗号化された変数「the_dev_secret」を呼び出します。" + +#: ../../rst/user_guide/vault.rst:207 +msgid "To encrypt the string 'letmein' read from stdin, add the vault ID 'dev' using the 'dev' vault password stored in `a_password_file`, and name the variable 'db_password':" +msgstr "標準入力から読み込んだ文字列「letmein」を暗号化するために、`a_password_file` に保存されている「dev」の Vault のパスワードを使用して Vault ID「dev」を追加し、変数に「db_password」という名前を付けます。" + +#: ../../rst/user_guide/vault.rst:215 +msgid "Typing secret content directly at the command line (without a prompt) leaves the secret string in your shell history. Do not do this outside of testing." +msgstr "秘密の内容をコマンドラインで直接入力すると (プロンプトなし)、シェルの履歴に秘密の文字列が残ります。テスト時以外はこのようなことをしないでください。" + +#: ../../rst/user_guide/vault.rst:217 +msgid "The command above creates this output:" +msgstr "上記のコマンドにより、以下が出力されます。" + +#: ../../rst/user_guide/vault.rst:230 +msgid "To be prompted for a string to encrypt, encrypt it with the 'dev' vault password from 'a_password_file', name the variable 'new_user_password' and give it the vault ID label 'dev':" +msgstr "暗号化する文字列の入力を求められるため、「a_password_file」の「dev」の Vault パスワードで暗号化し、変数名を「new_user_password」とし、Vault ID ラベル「dev」を付与します。" + +#: ../../rst/user_guide/vault.rst:236 +msgid "The command above triggers this prompt:" +msgstr "上記のコマンドにより、以下のプロンプトが表示されます。" + +#: ../../rst/user_guide/vault.rst:242 +msgid "Type the string to encrypt (for example, 'hunter2'), hit ctrl-d, and wait." +msgstr "暗号化する文字列 (「hunter2」など) を入力し、ctrl-d を押してお待ちください。" + +#: ../../rst/user_guide/vault.rst:246 +msgid "Do not press ``Enter`` after supplying the string to encrypt. That will add a newline to the encrypted value." +msgstr "暗号化する文字列を指定した後に ``Enter`` を押さないでください。暗号化された値に改行を追加します。" + +#: ../../rst/user_guide/vault.rst:248 +msgid "The sequence above creates this output:" +msgstr "上記のシーケンスにより、以下のような出力が作成されます。" + +#: ../../rst/user_guide/vault.rst:260 +msgid "You can add the output from any of the examples above to any playbook, variables file, or role for future use. Encrypted variables are larger than plain-text variables, but they protect your sensitive content while leaving the rest of the playbook, variables file, or role in plain text so you can easily read it." +msgstr "上記の例の出力を将来使用するために、任意の Playbook、変数ファイル、またはロールに追加することができます。暗号化された変数は、平文の変数よりもサイズが大きくなりますが、機密性の高いコンテンツを保護する一方で、Playbook、変数ファイル、またはロールの残りの部分は平文のままなとなるため、簡単に読み取ることができます。" + +#: ../../rst/user_guide/vault.rst:263 +msgid "Viewing encrypted variables" +msgstr "暗号化された変数の表示" + +#: ../../rst/user_guide/vault.rst:265 +msgid "You can view the original value of an encrypted variable using the debug module. You must pass the password that was used to encrypt the variable. For example, if you stored the variable created by the last example above in a file called 'vars.yml', you could view the unencrypted value of that variable like this:" +msgstr "暗号化された変数の元の値は、デバッグモジュールを使用して見ることができます。その際には、変数の暗号化に使用したパスワードを渡す必要があります。たとえば、上記の最後の例で作成した変数を「vars.yml」というファイルに保存した場合に、その変数の暗号化されていない値を見るには次のようにします。" + +#: ../../rst/user_guide/vault.rst:277 +msgid "Encrypting files with Ansible Vault" +msgstr "Ansible Vault によるファイルの暗号化" + +#: ../../rst/user_guide/vault.rst:279 +msgid "Ansible Vault can encrypt any structured data file used by Ansible, including:" +msgstr "Ansible Vault は、Ansible が使用するあらゆる構造化データファイルを暗号化することができます。以下に例を示します。" + +#: ../../rst/user_guide/vault.rst:281 +msgid "group variables files from inventory" +msgstr "インベントリーからのグループ変数ファイル" + +#: ../../rst/user_guide/vault.rst:282 +msgid "host variables files from inventory" +msgstr "インベントリーからのホスト変数ファイル" + +#: ../../rst/user_guide/vault.rst:283 +msgid "variables files passed to ansible-playbook with ``-e @file.yml`` or ``-e @file.json``" +msgstr "``-e @file.yml`` または ``-e @file.json`` で ansible-playbook に渡される変数ファイル" + +#: ../../rst/user_guide/vault.rst:284 +msgid "variables files loaded by ``include_vars`` or ``vars_files``" +msgstr "``include_vars`` または ``vars_files`` により読み込まれた変数ファイル" + +#: ../../rst/user_guide/vault.rst:285 +msgid "variables files in roles" +msgstr "ロールの変数ファイル" + +#: ../../rst/user_guide/vault.rst:286 +msgid "defaults files in roles" +msgstr "ロール内のデフォルトファイル" + +#: ../../rst/user_guide/vault.rst:287 +msgid "tasks files" +msgstr "タスクファイル" + +#: ../../rst/user_guide/vault.rst:288 +msgid "handlers files" +msgstr "ハンドラーファイル" + +#: ../../rst/user_guide/vault.rst:289 +msgid "binary files or other arbitrary files" +msgstr "バイナリーファイルまたはその他の任意のファイル" + +#: ../../rst/user_guide/vault.rst:291 +msgid "The full file is encrypted in the vault." +msgstr "完全なファイルは Vault で暗号化されます。" + +#: ../../rst/user_guide/vault.rst:295 +msgid "Ansible Vault uses an editor to create or modify encrypted files. See :ref:`vault_securing_editor` for some guidance on securing the editor." +msgstr "Ansible Vault はエディターを使用して暗号化されたファイルの作成または変更します。エディターのセキュリティー保護に関するいくつかのガイダンスは、「:ref:`vault_securing_editor`」を参照してください。" + +#: ../../rst/user_guide/vault.rst:299 +msgid "Advantages and disadvantages of encrypting files" +msgstr "ファイルを暗号化することの利点および欠点" + +#: ../../rst/user_guide/vault.rst:301 +msgid "File-level encryption is easy to use. Password rotation for encrypted files is straightforward with the :ref:`rekey <rekeying_files>` command. Encrypting files can hide not only sensitive values, but the names of the variables you use. However, with file-level encryption the contents of files are no longer easy to access and read. This may be a problem with encrypted tasks files. When encrypting a variables file, see :ref:`tip_for_variables_and_vaults` for one way to keep references to these variables in a non-encrypted file. Ansible always decrypts the entire encrypted file when it is when loaded or referenced, because Ansible cannot know if it needs the content unless it decrypts it." +msgstr "ファイルレベルの暗号化は簡単に使用できます。暗号化されたファイルのパスワードローテーションは、:ref:`rekey <rekeying_files>` コマンドで簡単に行うことができます。ファイルを暗号化すると、慎重に扱うべき値だけでなく、使用する変数の名前も隠すことができます。しかし、ファイルレベルの暗号化では、ファイルの内容に簡単にアクセスして読むことができなくなります。これは暗号化されたタスクファイルでは問題になるかもしれません。変数ファイルを暗号化する場合、これらの変数への参照を暗号化されていないファイルに保持する 1 つの方法、「:ref:`tip_for_variables_and_vaults`」を参照してください。Ansible は、暗号化されたファイルを読み込んだり参照したりする際には、常に暗号化されたファイル全体を復号します。これは、Ansible は復号しない限りコンテンツが必要かどうかを知ることができないからです。" + +#: ../../rst/user_guide/vault.rst:306 +msgid "Creating encrypted files" +msgstr "暗号化されたファイルの作成" + +#: ../../rst/user_guide/vault.rst:308 +msgid "To create a new encrypted data file called 'foo.yml' with the 'test' vault password from 'multi_password_file':" +msgstr "「multi_password_file」の Vault パスワード「test」を使用して、「foo.yml」という名前の新しい暗号化データファイルを作成するには、以下を行います。" + +#: ../../rst/user_guide/vault.rst:314 +msgid "The tool launches an editor (whatever editor you have defined with $EDITOR, default editor is vi). Add the content. When you close the editor session, the file is saved as encrypted data. The file header reflects the vault ID used to create it:" +msgstr "このツールは、エディター ($EDITOR で定義したエディターがなんであれ、デフォルトは vi) を起動します。コンテンツを追加します。エディターセッションを終了すると、ファイルは暗号化されたデータとして保存されます。ファイルのヘッダーには、作成時に使用した Vault ID が反映されます。" + +#: ../../rst/user_guide/vault.rst:320 +msgid "To create a new encrypted data file with the vault ID 'my_new_password' assigned to it and be prompted for the password:" +msgstr "Vault ID「my_new_password」が割り当てられた新しい暗号化データファイルを作成し、パスワードの入力を求められるようにするには、以下を行います。" + +#: ../../rst/user_guide/vault.rst:326 +msgid "Again, add content to the file in the editor and save. Be sure to store the new password you created at the prompt, so you can find it when you want to decrypt that file." +msgstr "ここでも、エディターのファイルにコンテンツを追加して保存します。プロンプトで作成した新しいパスワードを必ず保存し、そのファイルを復号するときに見つけられるようにしてください。" + +#: ../../rst/user_guide/vault.rst:331 +msgid "Encrypting existing files" +msgstr "既存ファイルの暗号化" + +#: ../../rst/user_guide/vault.rst:333 +msgid "To encrypt an existing file, use the :ref:`ansible-vault encrypt <ansible_vault_encrypt>` command. This command can operate on multiple files at once. For example:" +msgstr "既存ファイルを暗号化するには、:ref:`ansible-vault encrypt <ansible_vault_encrypt>` コマンドを使用します。このコマンドは、一度に複数のファイルで動作します。以下に例を示します。" + +#: ../../rst/user_guide/vault.rst:339 +msgid "To encrypt existing files with the 'project' ID and be prompted for the password:" +msgstr "「プロジェクト」IDで既存のファイルを暗号化し、パスワードの入力を求めるプロンプトを表示するには、以下のようになります。" + +#: ../../rst/user_guide/vault.rst:349 +msgid "Viewing encrypted files" +msgstr "暗号化したファイルの表示" + +#: ../../rst/user_guide/vault.rst:351 +msgid "To view the contents of an encrypted file without editing it, you can use the :ref:`ansible-vault view <ansible_vault_view>` command:" +msgstr "暗号化したファイルの内容を編集せずに表示する場合は、:ref:`ansible-vault view <ansible_vault_view>` コマンドを使用できます。" + +#: ../../rst/user_guide/vault.rst:361 +msgid "Editing encrypted files" +msgstr "暗号化されたファイルの編集" + +#: ../../rst/user_guide/vault.rst:363 +msgid "To edit an encrypted file in place, use the :ref:`ansible-vault edit <ansible_vault_edit>` command. This command decrypts the file to a temporary file, allows you to edit the content, then saves and re-encrypts the content and removes the temporary file when you close the editor. For example:" +msgstr "暗号化されたファイルをその場で編集するには、:ref:`ansible-vault edit <ansible_vault_edit>` コマンドを使用します。このコマンドは、ファイルを一時的なファイルに復号し、内容を編集できるようにした後、内容を保存して再度暗号化し、エディターを閉じるときに一時的なファイルを削除します。以下に例を示します。" + +#: ../../rst/user_guide/vault.rst:369 +msgid "To edit a file encrypted with the ``vault2`` password file and assigned the vault ID ``pass2``:" +msgstr "「``vault2``」パスワードファイルで暗号化され、Vault ID「``pass2``」を割り当てたファイルを編集するには、以下を実行します。" + +#: ../../rst/user_guide/vault.rst:379 +msgid "Changing the password and/or vault ID on encrypted files" +msgstr "暗号化されたファイルのパスワードまたは Vault ID の変更" + +#: ../../rst/user_guide/vault.rst:381 +msgid "To change the password on an encrypted file or files, use the :ref:`rekey <ansible_vault_rekey>` command:" +msgstr "暗号化された 1 つまたは複数のファイルのパスワードを変更するには、:ref:`rekey <ansible_vault_rekey>` コマンドを使用します。" + +#: ../../rst/user_guide/vault.rst:387 +msgid "This command can rekey multiple data files at once and will ask for the original password and also the new password. To set a different ID for the rekeyed files, pass the new ID to ``--new-vault-id``. For example, to rekey a list of files encrypted with the 'preprod1' vault ID from the 'ppold' file to the 'preprod2' vault ID and be prompted for the new password:" +msgstr "このコマンドは、複数のデータファイルの鍵を一度に再設定することができ、元のパスワードと新しいパスワードを要求します。鍵を一度に再設定したファイルに別の ID を設定するには、新しい ID を ``--new-vault-id`` に渡します。たとえば、「ppold」ファイルから「preprod1」の Vault ID で暗号化されたファイルのリストで Vault ID「preprod2」に鍵を再設定し、新しいパスワードの入力を求める場合です。" + +#: ../../rst/user_guide/vault.rst:397 +msgid "Decrypting encrypted files" +msgstr "暗号化されたファイルの復号化" + +#: ../../rst/user_guide/vault.rst:399 +msgid "If you have an encrypted file that you no longer want to keep encrypted, you can permanently decrypt it by running the :ref:`ansible-vault decrypt <ansible_vault_decrypt>` command. This command will save the file unencrypted to the disk, so be sure you do not want to :ref:`edit <ansible_vault_edit>` it instead." +msgstr "暗号化されたファイルがあり、そのファイルを暗号化したままにしておきたくない場合は、:ref:`ansible-vault decrypt <ansible_vault_decrypt>` コマンドを実行することで永久に暗号化を解除することができます。このコマンドは暗号化されていないファイルをディスクに保存するため、代わりに :ref:`edit <ansible_vault_edit>` を使用しないようにしてください。" + +#: ../../rst/user_guide/vault.rst:409 +msgid "Steps to secure your editor" +msgstr "エディターを確保するための手順" + +#: ../../rst/user_guide/vault.rst:411 +msgid "Ansible Vault relies on your configured editor, which can be a source of disclosures. Most editors have ways to prevent loss of data, but these normally rely on extra plain text files that can have a clear text copy of your secrets. Consult your editor documentation to configure the editor to avoid disclosing secure data. The following sections provide some guidance on common editors but should not be taken as a complete guide to securing your editor." +msgstr "Ansible Vault は、設定されたエディターに依存しており、これが情報漏えいの原因となることがあります。ほとんどのエディターには、データの損失を防ぐ方法がありますが、通常は、秘密のコピーが平文で保存されている可能性のある追加の平文ファイルに依存しています。エディターのドキュメントを参照して、セキュアなデータの開示を回避するようにエディターを設定してください。以下のセクションでは、一般的なエディターに関するガイダンスを提供していますが、エディターのセキュリティーを確保するための完全なガイドと考えるべきではありません。" + +#: ../../rst/user_guide/vault.rst:415 +msgid "vim" +msgstr "vim" + +#: ../../rst/user_guide/vault.rst:417 +msgid "You can set the following ``vim`` options in command mode to avoid cases of disclosure. There may be more settings you need to modify to ensure security, especially when using plugins, so consult the ``vim`` documentation." +msgstr "以下の ``vim`` オプションをコマンドモードで設定することで、情報漏えいのケースを回避することができます。特にプラグインを使用している場合など、セキュリティーを確保するために変更しなければならない設定が他にもあるかもしれないため、``vim`` のドキュメントを参照してください。" + +#: ../../rst/user_guide/vault.rst:420 +msgid "Disable swapfiles that act like an autosave in case of crash or interruption." +msgstr "クラッシュまたは中断が発生した場合に自動保存として機能する swapfiles を無効にします。" + +#: ../../rst/user_guide/vault.rst:426 ../../rst/user_guide/vault.rst:460 +msgid "Disable creation of backup files." +msgstr "バックアップファイルの作成を無効にします。" + +#: ../../rst/user_guide/vault.rst:433 +msgid "Disable the viminfo file from copying data from your current session." +msgstr "viminfo ファイルを無効にして、現在のセッションからデータをコピーします。" + +#: ../../rst/user_guide/vault.rst:439 +msgid "Disable copying to the system clipboard." +msgstr "システムクリップボードへのコピーを無効にします。" + +#: ../../rst/user_guide/vault.rst:446 +msgid "You can optionally add these settings in ``.vimrc`` for all files, or just specific paths or extensions. See the ``vim`` manual for details." +msgstr "必要に応じて、すべてのファイルまたは特定のパスまたは拡張の ``.vimrc`` にこれらの設定を追加できます。詳細は、``vim`` マニュアルを参照してください。" + +#: ../../rst/user_guide/vault.rst:450 +msgid "Emacs" +msgstr "Emacs" + +#: ../../rst/user_guide/vault.rst:452 +msgid "You can set the following Emacs options to avoid cases of disclosure. There may be more settings you need to modify to ensure security, especially when using plugins, so consult the Emacs documentation." +msgstr "以下の Emacs オプションを設定することで、情報漏えいを回避することができます。特にプラグインを使用する場合は、セキュリティーを確保するために変更する必要がある設定が他にもあるかもしれないため、Emacs のドキュメントを参照してください。" + +#: ../../rst/user_guide/vault.rst:454 +msgid "Do not copy data to the system clipboard." +msgstr "データをシステムクリップボードにコピーしないでください。" + +#: ../../rst/user_guide/vault.rst:466 +msgid "Disable autosave files." +msgstr "自動保存ファイルを無効にします。" + +#: ../../rst/user_guide/vault.rst:477 +msgid "Using encrypted variables and files" +msgstr "暗号化された変数とファイルの使用" + +#: ../../rst/user_guide/vault.rst:479 +msgid "When you run a task or playbook that uses encrypted variables or files, you must provide the passwords to decrypt the variables or files. You can do this at the command line or in the playbook itself." +msgstr "暗号化された変数やファイルを使用するタスクや Playbook を実行する際は、変数やファイルを復号するためのパスワードを提供する必要があります。これは、コマンドラインまたは Playbook の中で行うことができます。" + +#: ../../rst/user_guide/vault.rst:482 +msgid "Passing a single password" +msgstr "単一のパスワードを渡す" + +#: ../../rst/user_guide/vault.rst:484 +msgid "If all the encrypted variables and files your task or playbook needs use a single password, you can use the :option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>` or :option:`--vault-password-file <ansible-playbook --vault-password-file>` cli options." +msgstr "タスクや Playbook が必要とするすべての暗号化された変数やファイルが単一のパスワードを使用する場合は、CLI オプション :option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>` または :option:`--vault-password-file <ansible-playbook --vault-password-file>` を使用できます。" + +#: ../../rst/user_guide/vault.rst:486 ../../rst/user_guide/vault.rst:554 +msgid "To prompt for the password:" +msgstr "パスワードを要求する場合は、以下のようになります。" + +#: ../../rst/user_guide/vault.rst:492 +msgid "To retrieve the password from the :file:`/path/to/my/vault-password-file` file:" +msgstr ":file:`/path/to/my/vault-password-file` ファイルからパスワードを取得するには、以下を行います。" + +#: ../../rst/user_guide/vault.rst:498 +msgid "To get the password from the vault password client script :file:`my-vault-password-client.py`:" +msgstr "Vault パスワードクライアントスクリプト :file:`my-vault-password-client.py` から Vault パスワードを取得する場合は、以下のようになります。" + +#: ../../rst/user_guide/vault.rst:508 +msgid "Passing vault IDs" +msgstr "Vault ID を渡す" + +#: ../../rst/user_guide/vault.rst:510 +msgid "You can also use the :option:`--vault-id <ansible-playbook --vault-id>` option to pass a single password with its vault label. This approach is clearer when multiple vaults are used within a single inventory." +msgstr ":option:`--vault-id <ansible-playbook --vault-id>` オプションを使用して、Vault ラベルで単一のパスワードを渡すこともできます。この方法は、1 つのインベントリー内で複数の vault を使用している場合はより明確になります。" + +#: ../../rst/user_guide/vault.rst:512 +msgid "To prompt for the password for the 'dev' vault ID:" +msgstr "Vault ID「dev」のパスワードを要求する場合は、次のようになります。" + +#: ../../rst/user_guide/vault.rst:518 +msgid "To retrieve the password for the 'dev' vault ID from the :file:`dev-password` file:" +msgstr "「dev」の Vault ID のパスワードを :file:`dev-password` のファイルから取得するには、以下を行います。" + +#: ../../rst/user_guide/vault.rst:524 +msgid "To get the password for the 'dev' vault ID from the vault password client script :file:`my-vault-password-client.py`:" +msgstr "Vault パスワードクライアントスクリプト :file:`my-vault-password-client.py` から Vault ID 「dev」のパスワードを取得する場合は、以下を行います。" + +#: ../../rst/user_guide/vault.rst:531 +msgid "Passing multiple vault passwords" +msgstr "複数の Vault パスワードを渡す" + +#: ../../rst/user_guide/vault.rst:533 +msgid "If your task or playbook requires multiple encrypted variables or files that you encrypted with different vault IDs, you must use the :option:`--vault-id <ansible-playbook --vault-id>` option, passing multiple ``--vault-id`` options to specify the vault IDs ('dev', 'prod', 'cloud', 'db') and sources for the passwords (prompt, file, script). . For example, to use a 'dev' password read from a file and to be prompted for the 'prod' password:" +msgstr "タスクや Playbook で、異なる Vault ID で暗号化した複数の暗号化変数やファイルが必要な場合は、:option:`--vault-id <ansible-playbook --vault-id>` オプションを使用し、複数の ``--vault-id`` オプションを渡して Vault ID (「dev」、「prod」、「cloud」、「db」) とパスワードのソース (プロンプト、ファイル、スクリプト) を指定する必要があります。たとえば、ファイルから読み込んだ「dev」のパスワードを使用し、「prod」のパスワードを求めるプロンプトを表示する場合などです。" + +#: ../../rst/user_guide/vault.rst:539 +msgid "By default the vault ID labels (dev, prod and so on) are only hints. Ansible attempts to decrypt vault content with each password. The password with the same label as the encrypted data will be tried first, after that each vault secret will be tried in the order they were provided on the command line." +msgstr "デフォルトでは、Vault ID ラベル (dev、prodなど) はヒントでしかありません。Ansible は、各パスワードで Vault のコンテンツの復号を試みます。暗号化されたデータと同じラベルのパスワードが最初に試行され、その後、コマンドラインで指定された順に各 Vault シークレットが試行されます。" + +#: ../../rst/user_guide/vault.rst:541 +msgid "Where the encrypted data has no label, or the label does not match any of the provided labels, the passwords will be tried in the order they are specified. In the example above, the 'dev' password will be tried first, then the 'prod' password for cases where Ansible doesn't know which vault ID is used to encrypt something." +msgstr "暗号化されたデータにラベルがない場合、またはラベルが、提供されたラベルのどれとも一致しない場合、パスワードは指定された順に試行されます。上の例では、「dev」パスワードが最初に試行され、次に「prod」パスワードが試行されます。これは、Ansible がどの Vault ID が何かの暗号化に使用されているかを知らない場合に行われます。" + +#: ../../rst/user_guide/vault.rst:544 +msgid "Using ``--vault-id`` without a vault ID" +msgstr "Vault ID なしで ``--vault-id`` を使用" + +#: ../../rst/user_guide/vault.rst:546 +msgid "The :option:`--vault-id <ansible-playbook --vault-id>` option can also be used without specifying a vault-id. This behavior is equivalent to :option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>` or :option:`--vault-password-file <ansible-playbook --vault-password-file>` so is rarely used." +msgstr ":option:`--vault-id <ansible-playbook --vault-id>` オプションは、vault-id を指定せずに使用することもできます。この動作は :option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>` または :option:`--vault-password-file <ansible-playbook --vault-password-file>` と同等であるため、ほとんど使用されません。" + +#: ../../rst/user_guide/vault.rst:548 +msgid "For example, to use a password file :file:`dev-password`:" +msgstr "たとえば、パスワードファイル :file:`dev-password` を使用する場合は、以下のようになります。" + +#: ../../rst/user_guide/vault.rst:560 +msgid "To get the password from an executable script :file:`my-vault-password-client.py`:" +msgstr "実行スクリプト :file:`my-vault-password-client.py` からパスワードを取得する場合は、以下のようになります。" + +#: ../../rst/user_guide/vault.rst:568 +msgid "Configuring defaults for using encrypted content" +msgstr "暗号化されたコンテンツを使用するためのデフォルトの設定" + +#: ../../rst/user_guide/vault.rst:571 +msgid "Setting a default vault ID" +msgstr "デフォルトの Vault ID の設定" + +#: ../../rst/user_guide/vault.rst:573 +msgid "If you use one vault ID more frequently than any other, you can set the config option :ref:`DEFAULT_VAULT_IDENTITY_LIST` to specify a default vault ID and password source. Ansible will use the default vault ID and source any time you do not specify :option:`--vault-id <ansible-playbook --vault-id>`. You can set multiple values for this option. Setting multiple values is equivalent to passing multiple :option:`--vault-id <ansible-playbook --vault-id>` cli options." +msgstr "ある Vault ID を他の Vault IDよ りも頻繁に使用する場合は、設定オプション :ref:`DEFAULT_VAULT_IDENTITY_LIST` を設定して、デフォルトの Vault ID とパスワードソースを指定することができます。Ansible は、:option:`--vault-id <ansible-playbook --vault-id>` を指定しない場合は、デフォルトの Vault ID とソースを使用します。このオプションには複数の値を設定できます。複数の値を設定することは、複数の CLI オプション :option:`--vault-id <ansible-playbook --vault-id>` を渡すことと同じです。" + +#: ../../rst/user_guide/vault.rst:576 +msgid "Setting a default password source" +msgstr "デフォルトのパスワードソースの設定" + +#: ../../rst/user_guide/vault.rst:578 +msgid "If you use one vault password file more frequently than any other, you can set the :ref:`DEFAULT_VAULT_PASSWORD_FILE` config option or the :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` environment variable to specify that file. For example, if you set ``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt``, Ansible will automatically search for the password in that file. This is useful if, for example, you use Ansible from a continuous integration system such as Jenkins." +msgstr "ある Vault パスワードファイルを他のファイルよりも頻繁に使用する場合は、:ref:`DEFAULT_VAULT_PASSWORD_FILE` 設定オプションまたは環境変数 :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` を設定して、そのファイルを指定することができます。たとえば、``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt`` を設定すると、Ansible は自動的にそのファイル内のパスワードを検索します。これは、たとえば、Jenkins などの継続的統合システムから Ansible を使用する場合に便利です。" + +#: ../../rst/user_guide/vault.rst:581 +msgid "When are encrypted files made visible?" +msgstr "暗号化ファイルをいつ表示するか。" + +#: ../../rst/user_guide/vault.rst:583 +msgid "In general, content you encrypt with Ansible Vault remains encrypted after execution. However, there is one exception. If you pass an encrypted file as the ``src`` argument to the :ref:`copy <copy_module>`, :ref:`template <template_module>`, :ref:`unarchive <unarchive_module>`, :ref:`script <script_module>` or :ref:`assemble <assemble_module>` module, the file will not be encrypted on the target host (assuming you supply the correct vault password when you run the play). This behavior is intended and useful. You can encrypt a configuration file or template to avoid sharing the details of your configuration, but when you copy that configuration to servers in your environment, you want it to be decrypted so local users and processes can access it." +msgstr "一般的に、Ansible Vault で暗号化したコンテンツは、実行後も暗号化されたままです。ただし、1 つだけ例外があります。:ref:`copy <copy_module>` モジュール、:ref:`template <template_module>` モジュール、:ref:`unarchive <unarchive_module>` モジュール、:ref:`script <script_module>` モジュール、または :ref:`assemble <assemble_module>` モジュールへの ``src`` 引数として暗号化されたファイルを渡した場合、そのファイルはターゲットホスト上では暗号化されません (プレイの実行時に正しい Vault パスワードを供給していることが前提です)。この動作は意図されたものであり、便利なものです。設定ファイルやテンプレートを暗号化して、設定の詳細を共有しないようにすることができますが、その設定を環境内のサーバーにコピーするときは、ローカルのユーザーやプロセスがアクセスできるように、暗号化を解除します。" + +#: ../../rst/user_guide/vault.rst:588 +msgid "Format of files encrypted with Ansible Vault" +msgstr "Ansible Vault で暗号化されたファイルの形式" + +#: ../../rst/user_guide/vault.rst:590 +msgid "Ansible Vault creates UTF-8 encoded txt files. The file format includes a newline terminated header. For example:" +msgstr "Ansible Vault は、UTF-8 でエンコードされたテキストファイルを作成します。ファイル形式には、改行で終了するヘッダーが含まれます。以下に例を示します。" + +#: ../../rst/user_guide/vault.rst:596 +msgid "or" +msgstr "または" + +#: ../../rst/user_guide/vault.rst:602 +msgid "The header contains up to four elements, separated by semi-colons (``;``)." +msgstr "ヘッダーには、セミコロン (``;``) で区切られた最大 4 つの要素が含まれます。" + +#: ../../rst/user_guide/vault.rst:604 +msgid "The format ID (``$ANSIBLE_VAULT``). Currently ``$ANSIBLE_VAULT`` is the only valid format ID. The format ID identifies content that is encrypted with Ansible Vault (via vault.is_encrypted_file())." +msgstr "形式 ID (``$ANSIBLE_VAULT``)。現在、``$ANSIBLE_VAULT`` は唯一の有効な形式 ID です。フォーマット ID は、(vault.is_encrypted_file() を介して) Ansible Vault で暗号化されているコンテンツを識別します。" + +#: ../../rst/user_guide/vault.rst:606 +msgid "The vault format version (``1.X``). All supported versions of Ansible will currently default to '1.1' or '1.2' if a labeled vault ID is supplied. The '1.0' format is supported for reading only (and will be converted automatically to the '1.1' format on write). The format version is currently used as an exact string compare only (version numbers are not currently 'compared')." +msgstr "Vault 形式バージョン (``1.X``) です。現在、サポートされているすべてのバージョンの Ansible では、ラベル付きの Vault IDが指定された場合は、デフォルトで「1.1」または「1.2」になります。「1.0」形式は読み込みのみサポートしています (書き込み時には自動的に「1.1」形式に変換されます)。形式のバージョンは、現在、正確な文字列の比較としてのみ使用されています (バージョン番号は現在「比較」されません)。" + +#: ../../rst/user_guide/vault.rst:608 +msgid "The cipher algorithm used to encrypt the data (``AES256``). Currently ``AES256`` is the only supported cipher algorithm. Vault format 1.0 used 'AES', but current code always uses 'AES256'." +msgstr "データの暗号化に使用される暗号アルゴリズム (``AES256``)。現在、``AES256`` が唯一サポートされている暗号アルゴリズムです。Vault 形式 1.0 では「AES」を使用していましたが、現在のコードでは常に「AES256」を使用します。" + +#: ../../rst/user_guide/vault.rst:610 +msgid "The vault ID label used to encrypt the data (optional, ``vault-id-label``) For example, if you encrypt a file with ``--vault-id dev@prompt``, the vault-id-label is ``dev``." +msgstr "データの暗号化に使用される vault ID ラベル (任意: ``vault-id-label``)。たとえば、``--vault-id dev@prompt`` でファイルを暗号化する場合は、vault-id-label が ``dev`` になります。" + +#: ../../rst/user_guide/vault.rst:612 +msgid "Note: In the future, the header could change. Fields after the format ID and format version depend on the format version, and future vault format versions may add more cipher algorithm options and/or additional fields." +msgstr "注: 将来的には、ヘッダーが変更する可能性があります。形式 ID と形式バージョンの後のフィールドは、形式のバージョンに依存しており、将来の Vault 形式のバージョンでは、暗号アルゴリズムのオプションやフィールドが追加される可能性があります。" + +#: ../../rst/user_guide/vault.rst:614 +msgid "The rest of the content of the file is the 'vaulttext'. The vaulttext is a text armored version of the encrypted ciphertext. Each line is 80 characters wide, except for the last line which may be shorter." +msgstr "ファイルの残りの内容は「vaulttext」です。vaulttext は、暗号化された暗号文のテキスト版です。各行の幅は 80 文字です。ただし、最終行は短くなる場合があります。" + +#: ../../rst/user_guide/vault.rst:618 +msgid "Ansible Vault payload format 1.1 - 1.2" +msgstr "Ansible Vault ペイロード形式 1.1 - 1.2" + +#: ../../rst/user_guide/vault.rst:620 +msgid "The vaulttext is a concatenation of the ciphertext and a SHA256 digest with the result 'hexlifyied'." +msgstr "vaulttext は、暗号化テキストと SHA256 ダイジェストを連結したもので、結果は「hexlifyied」です。" + +#: ../../rst/user_guide/vault.rst:622 +msgid "'hexlify' refers to the ``hexlify()`` method of the Python Standard Library's `binascii <https://docs.python.org/3/library/binascii.html>`_ module." +msgstr "「hexlify」は、Python 標準ライブラリーの `binascii <https://docs.python.org/3/library/binascii.html>`_ モジュールの ``hexlify()`` メソッドを指します。" + +#: ../../rst/user_guide/vault.rst:624 +msgid "hexlify()'ed result of:" +msgstr "hexlify() が行われた結果:" + +#: ../../rst/user_guide/vault.rst:626 +msgid "hexlify()'ed string of the salt, followed by a newline (``0x0a``)" +msgstr "hexlify() で編集されたソルトの文字列とそれに続く改行 (``0x0a``)。" + +#: ../../rst/user_guide/vault.rst:627 +msgid "hexlify()'ed string of the crypted HMAC, followed by a newline. The HMAC is:" +msgstr "hexlify() で暗号化された HMAC の文字列の後に、改行を入れます。その HMAC は以下のようになります。" + +#: ../../rst/user_guide/vault.rst:629 +msgid "a `RFC2104 <https://www.ietf.org/rfc/rfc2104.txt>`_ style HMAC" +msgstr "`RFC2104 <https://www.ietf.org/rfc/rfc2104.txt>`_ スタイルの HMAC" + +#: ../../rst/user_guide/vault.rst:631 +msgid "inputs are:" +msgstr "入力は次のとおりです。" + +#: ../../rst/user_guide/vault.rst:633 +msgid "The AES256 encrypted ciphertext" +msgstr "AES256 で暗号化した暗号文" + +#: ../../rst/user_guide/vault.rst:634 +msgid "A PBKDF2 key. This key, the cipher key, and the cipher IV are generated from:" +msgstr "PBKDF2 キー。このキー、暗号キー、および暗号 IV を生成します。" + +#: ../../rst/user_guide/vault.rst:636 +msgid "the salt, in bytes" +msgstr "バイト単位のソルト" + +#: ../../rst/user_guide/vault.rst:637 +msgid "10000 iterations" +msgstr "10000 回の繰り返し" + +#: ../../rst/user_guide/vault.rst:638 +msgid "SHA256() algorithm" +msgstr "SHA256() アルゴリズム" + +#: ../../rst/user_guide/vault.rst:639 +msgid "the first 32 bytes are the cipher key" +msgstr "最初の 32 バイトは暗号キーです。" + +#: ../../rst/user_guide/vault.rst:640 +msgid "the second 32 bytes are the HMAC key" +msgstr "2 番目の 32 バイトは HMAC キーです。" + +#: ../../rst/user_guide/vault.rst:641 +msgid "remaining 16 bytes are the cipher IV" +msgstr "残りの 16 バイトは暗号 IV です。" + +#: ../../rst/user_guide/vault.rst:643 +msgid "hexlify()'ed string of the ciphertext. The ciphertext is:" +msgstr "暗号文の hexlify() が行われた文字列です。暗号文は以下のようになります。" + +#: ../../rst/user_guide/vault.rst:645 +msgid "AES256 encrypted data. The data is encrypted using:" +msgstr "AES256 で暗号化されたデータです。データは次を使用して暗号化されます。" + +#: ../../rst/user_guide/vault.rst:647 +msgid "AES-CTR stream cipher" +msgstr "AES-CTR ストリーム暗号" + +#: ../../rst/user_guide/vault.rst:648 +msgid "cipher key" +msgstr "暗号鍵" + +#: ../../rst/user_guide/vault.rst:649 +msgid "IV" +msgstr "IV" + +#: ../../rst/user_guide/vault.rst:650 +msgid "a 128 bit counter block seeded from an integer IV" +msgstr "整数 IV からシードされた 128 ビットのカウンターブロック" + +#: ../../rst/user_guide/vault.rst:651 +msgid "the plaintext" +msgstr "平文" + +#: ../../rst/user_guide/vault.rst:653 +msgid "the original plaintext" +msgstr "元の平文" + +#: ../../rst/user_guide/vault.rst:654 +msgid "padding up to the AES256 blocksize. (The data used for padding is based on `RFC5652 <https://tools.ietf.org/html/rfc5652#section-6.3>`_)" +msgstr "AES256 ブロックサイズまでのパディング (パディングに使用するデータは `RFC5652 <https://tools.ietf.org/html/rfc5652#section-6.3>`_ に基づいています)" + +#: ../../rst/user_guide/windows.rst:4 +msgid "Windows Guides" +msgstr "Windows ガイド" + +#: ../../rst/user_guide/windows.rst:6 +msgid "The following sections provide information on managing Windows hosts with Ansible." +msgstr "以下のセクションでは、Ansible を使用した Windows ホストの管理を説明します。" + +#: ../../rst/user_guide/windows.rst:9 +msgid "Because Windows is a non-POSIX-compliant operating system, there are differences between how Ansible interacts with them and the way Windows works. These guides will highlight some of the differences between Linux/Unix hosts and hosts running Windows." +msgstr "Windows は POSIX に準拠していない OS であるため、Ansible の動作方法と Windows の動作方法には違いがあります。このガイドでは、Linux/Unix ホストと Windows を実行するホストの違いを紹介します。" + +#: ../../rst/user_guide/windows_dsc.rst:2 +msgid "Desired State Configuration" +msgstr "Desired State Configuration" + +#: ../../rst/user_guide/windows_dsc.rst:8 +msgid "What is Desired State Configuration?" +msgstr "Desired State Configuration とは" + +#: ../../rst/user_guide/windows_dsc.rst:9 +msgid "Desired State Configuration, or DSC, is a tool built into PowerShell that can be used to define a Windows host setup through code. The overall purpose of DSC is the same as Ansible, it is just executed in a different manner. Since Ansible 2.4, the ``win_dsc`` module has been added and can be used to take advantage of existing DSC resources when interacting with a Windows host." +msgstr "Desired State Configuration (DSC) は、PowerShell に組み込まれたツールで、コードによって Windows ホストのセットアップを定義するために使用することができます。DSC の全体的な目的は Ansible と同じですが、実行方法が異なるだけです。Ansible 2.4 からは、``win_dsc`` モジュールが追加され、Windows ホストとのやりとりの際に、既存の DSC リソースを活用することができます。" + +#: ../../rst/user_guide/windows_dsc.rst:15 +msgid "More details on DSC can be viewed at `DSC Overview <https://docs.microsoft.com/en-us/powershell/scripting/dsc/overview?view=powershell-7.2>`_." +msgstr "DSC の詳細は、`DSC Overview <https://docs.microsoft.com/en-us/powershell/scripting/dsc/overview?view=powershell-7.2>`_ を参照してください。" + +#: ../../rst/user_guide/windows_dsc.rst:18 +#: ../../rst/user_guide/windows_setup.rst:11 +msgid "Host Requirements" +msgstr "ホスト要件" + +#: ../../rst/user_guide/windows_dsc.rst:19 +msgid "To use the ``win_dsc`` module, a Windows host must have PowerShell v5.0 or newer installed. All supported hosts can be upgraded to PowerShell v5." +msgstr "``win_dsc`` モジュールを使用するには、Windows ホストに PowerShell v5.0 以降がインストールされている必要があります。サポート対象のホストはすべて、PowerShell v5.0 にアップグレードすることができます。" + +#: ../../rst/user_guide/windows_dsc.rst:22 +msgid "Once the PowerShell requirements have been met, using DSC is as simple as creating a task with the ``win_dsc`` module." +msgstr "PowerShell の要件を満たしていれば、DSC を使用することは、``win_dsc`` モジュールでタスクを作成するのと同じぐらい簡単です。" + +#: ../../rst/user_guide/windows_dsc.rst:26 +msgid "Why Use DSC?" +msgstr "DSC を使用する理由" + +#: ../../rst/user_guide/windows_dsc.rst:27 +msgid "DSC and Ansible modules have a common goal which is to define and ensure the state of a resource. Because of this, resources like the DSC `File resource <https://docs.microsoft.com/en-us/powershell/scripting/dsc/reference/resources/windows/fileresource>`_ and Ansible ``win_file`` can be used to achieve the same result. Deciding which to use depends on the scenario." +msgstr "DSC と Ansible モジュールには、リソースの状態を定義して保証するという共通の目的があります。このため、DSC `ファイルリソース <https://docs.microsoft.com/en-us/powershell/scripting/dsc/reference/resources/windows/fileresource>`_ や Ansible``win_file`` のようなリソースを使用して、同じ結果を得ることができます。どちらを使用するかは、シナリオによって異なります。" + +#: ../../rst/user_guide/windows_dsc.rst:33 +msgid "Reasons for using an Ansible module over a DSC resource:" +msgstr "DSC リソースで Ansible モジュールを使用する理由:" + +#: ../../rst/user_guide/windows_dsc.rst:35 +msgid "The host does not support PowerShell v5.0, or it cannot easily be upgraded" +msgstr "ホストが PowerShell v5.0 をサポートしていない、または簡単にアップグレードできない" + +#: ../../rst/user_guide/windows_dsc.rst:36 +msgid "The DSC resource does not offer a feature present in an Ansible module. For example, win_regedit can manage the ``REG_NONE`` property type, while the DSC ``Registry`` resource cannot" +msgstr "DSC リソースは、Ansible モジュールに存在する機能を提供しない。たとえば、win_regedit は ``REG_NONE`` のプロパティータイプを管理できますが、DSC の ``Registry`` リソースでは管理できません。" + +#: ../../rst/user_guide/windows_dsc.rst:39 +msgid "DSC resources have limited check mode support, while some Ansible modules have better checks" +msgstr "DSC のリソースはチェックモードのサポートが限られているが、Ansible モジュールの中にはより優れたチェック機能を持つものがある" + +#: ../../rst/user_guide/windows_dsc.rst:41 +msgid "DSC resources do not support diff mode, while some Ansible modules do" +msgstr "DSC リソースでは差分モードがサポートされないが、一部の Ansible モジュールではサポートされる" + +#: ../../rst/user_guide/windows_dsc.rst:42 +msgid "Custom resources require further installation steps to be run on the host beforehand, while Ansible modules are built-in to Ansible" +msgstr "カスタムリソースでは、事前にホスト上で追加のインストール手順を実行する必要があるが、Ansible モジュールは Ansible に組み込まれている" + +#: ../../rst/user_guide/windows_dsc.rst:44 +msgid "There are bugs in a DSC resource where an Ansible module works" +msgstr "Ansible モジュールが機能する DSC リソースにバグがある" + +#: ../../rst/user_guide/windows_dsc.rst:46 +msgid "Reasons for using a DSC resource over an Ansible module:" +msgstr "Ansible モジュールで DSC リソースを使用する理由:" + +#: ../../rst/user_guide/windows_dsc.rst:48 +msgid "The Ansible module does not support a feature present in a DSC resource" +msgstr "Ansible モジュールは、DSC リソースに存在する機能をサポートしていない" + +#: ../../rst/user_guide/windows_dsc.rst:49 +msgid "There is no Ansible module available" +msgstr "利用可能な Ansible モジュールがない" + +#: ../../rst/user_guide/windows_dsc.rst:50 +msgid "There are bugs in an existing Ansible module" +msgstr "既存の Ansible モジュールにバグがある" + +#: ../../rst/user_guide/windows_dsc.rst:52 +msgid "In the end, it doesn't matter whether the task is performed with DSC or an Ansible module; what matters is that the task is performed correctly and the playbooks are still readable. If you have more experience with DSC over Ansible and it does the job, just use DSC for that task." +msgstr "つまるところ、タスクが DSC で実行されるか Ansible モジュールで実行されるかは重要ではありません。重要なのは、タスクが正しく実行され、Playbook が読めることです。Ansible よりも DSC の方を使用した経験があり、それで必要なことができるのであれば、そのタスクには DSC を使用すると良いでしょう。" + +#: ../../rst/user_guide/windows_dsc.rst:58 +msgid "How to Use DSC?" +msgstr "DSC の使用方法" + +#: ../../rst/user_guide/windows_dsc.rst:59 +msgid "The ``win_dsc`` module takes in a free-form of options so that it changes according to the resource it is managing. A list of built-in resources can be found at `resources <https://docs.microsoft.com/en-us/powershell/scripting/dsc/resources/resources>`_." +msgstr "``win_dsc`` モジュールは、管理しているリソースに応じて変化するように、フリーフォームのオプションを取り入れています。組み込まれているリソースのリストは、`resources <https://docs.microsoft.com/en-us/powershell/scripting/dsc/resources/resources>`_ を参照してください。" + +#: ../../rst/user_guide/windows_dsc.rst:63 +msgid "Using the `Registry <https://docs.microsoft.com/en-us/powershell/scripting/dsc/reference/resources/windows/registryresource>`_ resource as an example, this is the DSC definition as documented by Microsoft:" +msgstr "`Registry <https://docs.microsoft.com/en-us/powershell/scripting/dsc/reference/resources/windows/registryresource>`_ リソースを例にとると、これは Microsoft が文書化したDSCの定義です。" + +#: ../../rst/user_guide/windows_dsc.rst:80 +msgid "When defining the task, ``resource_name`` must be set to the DSC resource being used - in this case, the ``resource_name`` should be set to ``Registry``. The ``module_version`` can refer to a specific version of the DSC resource installed; if left blank it will default to the latest version. The other options are parameters that are used to define the resource, such as ``Key`` and ``ValueName``. While the options in the task are not case sensitive, keeping the case as-is is recommended because it makes it easier to distinguish DSC resource options from Ansible's ``win_dsc`` options." +msgstr "タスクを定義する際には、使用する DSC リソースを ``resource_name`` に設定する必要があります。この場合、``resource_name`` は ``Registry`` に設定する必要があります。``module_version`` はインストールされている DSC リソースの特定のバージョンを参照することができますが、空白にするとデフォルトで最新バージョンになります。その他のオプションは ``Key`` や ``ValueName`` のようにリソースを定義するためのパラメーターになります。タスクのオプションは大文字小文字を区別しませんが、DSC リソースのオプションと Ansible の``win_dsc`` のオプションを区別しやすくするために、大文字小文字をそのままにしておくことが推奨されます。" + +#: ../../rst/user_guide/windows_dsc.rst:89 +msgid "This is what the Ansible task version of the above DSC Registry resource would look like:" +msgstr "上記の DSC レジストリーリソースの Ansible タスクバージョンは、以下のようになります。" + +#: ../../rst/user_guide/windows_dsc.rst:101 +msgid "Starting in Ansible 2.8, the ``win_dsc`` module automatically validates the input options from Ansible with the DSC definition. This means Ansible will fail if the option name is incorrect, a mandatory option is not set, or the value is not a valid choice. When running Ansible with a verbosity level of 3 or more (``-vvv``), the return value will contain the possible invocation options based on the ``resource_name`` specified. Here is an example of the invocation output for the above ``Registry`` task:" +msgstr "Ansible 2.8 より、``win_dsc`` モジュールは、Ansible からの入力オプションを DSC 定義で自動的に検証します。つまり、オプション名が間違っていたり、必須オプションが設定されていなかったり、値が有効な選択肢でなかったりすると、Ansible は失敗します。Ansible を冗長レベル 3 以上 (``-vvv``) で実行した場合、戻り値には、指定された ``resource_name`` に基づいて可能な呼び出しオプションが含まれます。以下は、上記の ``Registry`` タスクの呼び出し出力の例です。" + +#: ../../rst/user_guide/windows_dsc.rst:156 +msgid "The ``invocation.module_args`` key shows the actual values that were set as well as other possible values that were not set. Unfortunately, this will not show the default value for a DSC property, only what was set from the Ansible task. Any ``*_password`` option will be masked in the output for security reasons; if there are any other sensitive module options, set ``no_log: True`` on the task to stop all task output from being logged." +msgstr "``invocation.module_args`` キーは、設定された実際の値と、設定されなかった他の可能な値を表示します。DSC プロパティーのデフォルト値は表示されず、Ansible タスクで設定された値のみが表示されます。``*_password`` オプションは、セキュリティー上の理由から出力ではマスクされます。他に機密性の高いモジュールオプションがある場合は、タスクに ``no_log: True`` を設定して、すべてのタスク出力がログに記録されないようにしてください。" + +#: ../../rst/user_guide/windows_dsc.rst:165 +msgid "Property Types" +msgstr "プロパティータイプ" + +#: ../../rst/user_guide/windows_dsc.rst:166 +msgid "Each DSC resource property has a type that is associated with it. Ansible will try to convert the defined options to the correct type during execution. For simple types like ``[string]`` and ``[bool]``, this is a simple operation, but complex types like ``[PSCredential]`` or arrays (like ``[string[]]``) require certain rules." +msgstr "各 DSC リソースプロパティーには、それに関連付けられたタイプがあります。Ansible は、実行時に定義されたオプションを正しいタイプに変換しようとします。``[string]`` や ``[bool]`` のような単純なタイプでは、これは単純な操作ですが、``[PSCredential]`` や配列 (``[string[]]`` など) のような複雑なタイプでは、特定のルールが必要です。" + +#: ../../rst/user_guide/windows_dsc.rst:173 +msgid "PSCredential" +msgstr "PSCredential" + +#: ../../rst/user_guide/windows_dsc.rst:174 +msgid "A ``[PSCredential]`` object is used to store credentials in a secure way, but Ansible has no way to serialize this over JSON. To set a DSC PSCredential property, the definition of that parameter should have two entries that are suffixed with ``_username`` and ``_password`` for the username and password, respectively. For example:" +msgstr "``[PSCredential]`` オブジェクトは認証情報を安全な方法で保存するために使用されますが、Ansible にはこれを JSON でシリアル化する方法がありません。DSC PSCredential プロパティーを設定するには、そのパラメーターの定義に、ユーザ名とパスワードをそれぞれ ``_username`` と ``_password`` をサフィックスにした 2 つのエントリーを追加する必要があります。たとえば、以下のようになります。" + +#: ../../rst/user_guide/windows_dsc.rst:188 +msgid "On versions of Ansible older than 2.8, you should set ``no_log: yes`` on the task definition in Ansible to ensure any credentials used are not stored in any log file or console output." +msgstr "2.8 より古いバージョンの Ansible では、Ansible のタスク定義に ``no_log: yes`` を設定して、使用する認証情報がログファイルまたはコンソールの出力に保存されないようにする必要があります。" + +#: ../../rst/user_guide/windows_dsc.rst:192 +msgid "A ``[PSCredential]`` is defined with ``EmbeddedInstance(\"MSFT_Credential\")`` in a DSC resource MOF definition." +msgstr "``[PSCredential]`` は、DSC リソースの MOF 定義において``EmbeddedInstance(\"MSFT_Credential\")`` と共に定義されます。" + +#: ../../rst/user_guide/windows_dsc.rst:196 +msgid "CimInstance Type" +msgstr "CimInstance タイプ" + +#: ../../rst/user_guide/windows_dsc.rst:197 +msgid "A ``[CimInstance]`` object is used by DSC to store a dictionary object based on a custom class defined by that resource. Defining a value that takes in a ``[CimInstance]`` in YAML is the same as defining a dictionary in YAML. For example, to define a ``[CimInstance]`` value in Ansible:" +msgstr "``[CimInstance]`` オブジェクトは、DSC がそのリソースで定義されたカスタムクラスに基づいてディクショナリーオブジェクトを格納するために使用されます。``[CimInstance]`` を取り込む値を YAML で定義することは、YAML でディクショナリーを定義することと同じです。たとえば、Ansible で``[CimInstance]`` の値を定義する場合は、以下のようになります。" + +#: ../../rst/user_guide/windows_dsc.rst:211 +msgid "In the above example, the CIM instance is a representation of the class `MSFT_xWebAuthenticationInformation <https://github.com/dsccommunity/xWebAdministration/blob/master/source/DSCResources/MSFT_xWebSite/MSFT_xWebSite.schema.mof>`_. This class accepts four boolean variables, ``Anonymous``, ``Basic``, ``Digest``, and ``Windows``. The keys to use in a ``[CimInstance]`` depend on the class it represents. Please read through the documentation of the resource to determine the keys that can be used and the types of each key value. The class definition is typically located in the ``<resource name>.schema.mof``." +msgstr "上記の例では、CIM インスタンスは、クラス `MSFT_xWebAuthenticationInformation <https://github.com/dsccommunity/xWebAdministration/blob/master/source/DSCResources/MSFT_xWebSite/MSFT_xWebSite.schema.mof>`_ の表現です。このクラスは、``Anonymous``、``Basic``、``Digest``、``Windows`` という 4 つのブール変数を受け入れます。``[CimInstance]`` で使用するキーは、それが表現するクラスによって異なります。使用できるキーと各キーの値のタイプについては、リソースのドキュメントを参照してください。クラスの定義は、通常、``<resource name>.schema.mof`` にあります。" + +#: ../../rst/user_guide/windows_dsc.rst:220 +msgid "HashTable Type" +msgstr "HashTable タイプ" + +#: ../../rst/user_guide/windows_dsc.rst:221 +msgid "A ``[HashTable]`` object is also a dictionary but does not have a strict set of keys that can/need to be defined. Like a ``[CimInstance]``, define it as a normal dictionary value in YAML. A ``[HashTable]]`` is defined with ``EmbeddedInstance(\"MSFT_KeyValuePair\")`` in a DSC resource MOF definition." +msgstr "``[HashTable]`` オブジェクトもディクショナリーですが、定義できる/しなければならない厳密な鍵のセットがありません。``[CimInstance]`` のように、YAML で通常のディクショナリー値のように定義します。``[HashTable]]`` は、DSC リソースの MOF 定義において ``EmbeddedInstance(\"MSFT_KeyValuePair\")`` と共に定義されます。" + +#: ../../rst/user_guide/windows_dsc.rst:227 +msgid "Arrays" +msgstr "配列" + +#: ../../rst/user_guide/windows_dsc.rst:228 +msgid "Simple type arrays like ``[string[]]`` or ``[UInt32[]]`` are defined as a list or as a comma-separated string which is then cast to their type. Using a list is recommended because the values are not manually parsed by the ``win_dsc`` module before being passed to the DSC engine. For example, to define a simple type array in Ansible:" +msgstr "``[string[]]`` や ``[UInt32[]]`` のような単純なタイプの配列は、リストまたはコンマ区切りの文字列として定義され、それらがタイプにキャストされます。リストを使用すると、DSC エンジンに渡す前に ``win_dsc`` モジュールで値が手動で解析されないため、推奨されます。たとえば、Ansible で単純なタイプの配列を定義するには、次のようにします。" + +#: ../../rst/user_guide/windows_dsc.rst:249 +msgid "Complex type arrays like ``[CimInstance[]]`` (array of dicts), can be defined like this example:" +msgstr "``[CimInstance[]]`` (ディクショナリーの配列) のような複雑なタイプの配列は、次の例のように定義できます。" + +#: ../../rst/user_guide/windows_dsc.rst:267 +msgid "The above example is an array with two values of the class `MSFT_xWebBindingInformation <https://github.com/dsccommunity/xWebAdministration/blob/master/source/DSCResources/MSFT_xWebSite/MSFT_xWebSite.schema.mof>`_. When defining a ``[CimInstance[]]``, be sure to read the resource documentation to find out what keys to use in the definition." +msgstr "上記の例は、`MSFT_xWebBindingInformation <https://github.com/dsccommunity/xWebAdministration/blob/master/source/DSCResources/MSFT_xWebSite/MSFT_xWebSite.schema.mof>`_ クラスの 2 つの値のある配列です。``[CimInstance[]]`` を定義すると、リソースドキュメントを参照して、定義で使用するキーを確認してください。" + +#: ../../rst/user_guide/windows_dsc.rst:272 +msgid "DateTime" +msgstr "日時" + +#: ../../rst/user_guide/windows_dsc.rst:273 +msgid "A ``[DateTime]`` object is a DateTime string representing the date and time in the `ISO 8601 <https://www.w3.org/TR/NOTE-datetime>`_ date time format. The value for a ``[DateTime]`` field should be quoted in YAML to ensure the string is properly serialized to the Windows host. Here is an example of how to define a ``[DateTime]`` value in Ansible:" +msgstr "``[DateTime]`` オブジェクトは、`ISO 8601 <https://www.w3.org/TR/NOTE-datetime>`_ の日時フォーマットで日付と時間を表す DateTime 文字列です。``[DateTime]`` フィールドの値は、文字列が Windows ホストに適切にシリアライズされるように、YAML で引用する必要があります。以下は、Ansible で``[DateTime]`` の値を定義する方法の例です。" + +#: ../../rst/user_guide/windows_dsc.rst:290 +msgid "All the values above are equal to a UTC date time of February 22nd 2019 at 1:57pm with 31 seconds and 2311892 milliseconds." +msgstr "上記のすべての値は、UTCの 日付時刻が 2019 年 2 月 22 日午後 1 時 57 分 31 秒 2311892 ミリ秒であることと同じです。" + +#: ../../rst/user_guide/windows_dsc.rst:294 +msgid "Run As Another User" +msgstr "別のユーザーとして実行" + +#: ../../rst/user_guide/windows_dsc.rst:295 +msgid "By default, DSC runs each resource as the SYSTEM account and not the account that Ansible uses to run the module. This means that resources that are dynamically loaded based on a user profile, like the ``HKEY_CURRENT_USER`` registry hive, will be loaded under the ``SYSTEM`` profile. The parameter ``PsDscRunAsCredential`` is a parameter that can be set for every DSC resource, and force the DSC engine to run under a different account. As ``PsDscRunAsCredential`` has a type of ``PSCredential``, it is defined with the ``_username`` and ``_password`` suffix." +msgstr "デフォルトでは、DSC は各リソースを、Ansible がモジュールの実行に使用するアカウントではなく、SYSTEM アカウントとして実行します。つまり、``HKEY_CURRENT_USER`` のレジストリーハイブのように、ユーザープロファイルに基づいて動的に読み込まれるリソースは、``SYSTEM`` のプロファイルで読み込まれます。``PsDscRunAsCredential`` は、DSC エンジンが別のアカウントで実行されるように、すべての DSC リソースに設定することができるパラメーターです。``PsDscRunAsCredential`` はタイプが ``PSCredential`` なので、サフィックス ``_username`` と``_password`` で定義されています。" + +#: ../../rst/user_guide/windows_dsc.rst:304 +msgid "Using the Registry resource type as an example, this is how to define a task to access the ``HKEY_CURRENT_USER`` hive of the Ansible user:" +msgstr "レジストリーリソースタイプを例として使用し、Ansible ユーザーの ``HKEY_CURRENT_USER`` ハイブにアクセスするタスクを定義する方法を説明します。" + +#: ../../rst/user_guide/windows_dsc.rst:321 +msgid "Custom DSC Resources" +msgstr "カスタムの DSC リソース" + +#: ../../rst/user_guide/windows_dsc.rst:322 +msgid "DSC resources are not limited to the built-in options from Microsoft. Custom modules can be installed to manage other resources that are not usually available." +msgstr "DSC のリソースは、Microsoft の組み込みオプションに限定されません。カスタムモジュールをインストールすることで、通常では利用できない他のリソースを管理することができます。" + +#: ../../rst/user_guide/windows_dsc.rst:326 +msgid "Finding Custom DSC Resources" +msgstr "カスタムの DSC リソースの見つけ方" + +#: ../../rst/user_guide/windows_dsc.rst:327 +msgid "You can use the `PSGallery <https://www.powershellgallery.com/>`_ to find custom resources, along with documentation on how to install them on a Windows host." +msgstr "`PSGallery <https://www.powershellgallery.com/>`_ を使用すると、カスタムリソースと、それを Windows ホストにインストールする方法に関するドキュメントを見つけることができます。" + +#: ../../rst/user_guide/windows_dsc.rst:330 +msgid "The ``Find-DscResource`` cmdlet can also be used to find custom resources. For example:" +msgstr "``Find-DscResource`` コマンドレットを使用して、カスタムリソースを検索することもできます。以下に例を示します。" + +#: ../../rst/user_guide/windows_dsc.rst:340 +msgid "DSC resources developed by Microsoft that start with ``x`` means the resource is experimental and comes with no support." +msgstr "Microsoft が開発した DSC リソースで、``x`` で始まるものは、実験的なリソースであり、サポートがないことを意味しています。" + +#: ../../rst/user_guide/windows_dsc.rst:344 +msgid "Installing a Custom Resource" +msgstr "カスタムリソースのインストール" + +#: ../../rst/user_guide/windows_dsc.rst:345 +msgid "There are three ways that a DSC resource can be installed on a host:" +msgstr "DSC リソースをホストにインストールする方法は 3 つあります。" + +#: ../../rst/user_guide/windows_dsc.rst:347 +msgid "Manually with the ``Install-Module`` cmdlet" +msgstr "``Install-Module`` コマンドレットを手動で使用" + +#: ../../rst/user_guide/windows_dsc.rst:348 +msgid "Using the ``win_psmodule`` Ansible module" +msgstr "Ansibleモジュール ``win_psmodule`` を使用" + +#: ../../rst/user_guide/windows_dsc.rst:349 +msgid "Saving the module manually and copying it to another host" +msgstr "モジュールを手動で保存して別のホストにコピー" + +#: ../../rst/user_guide/windows_dsc.rst:351 +msgid "The following is an example of installing the ``xWebAdministration`` resources using ``win_psmodule``:" +msgstr "以下は、``win_psmodule`` を使用して ``xWebAdministration`` リソースをインストールする例です。" + +#: ../../rst/user_guide/windows_dsc.rst:361 +msgid "Once installed, the win_dsc module will be able to use the resource by referencing it with the ``resource_name`` option." +msgstr "インストールすると、win_dsc モジュールは、``resource_name`` オプションでリソースを参照することで、リソースを使用できるようになります。" + +#: ../../rst/user_guide/windows_dsc.rst:364 +msgid "The first two methods above only work when the host has access to the internet. When a host does not have internet access, the module must first be installed using the methods above on another host with internet access and then copied across. To save a module to a local filepath, the following PowerShell cmdlet can be run:" +msgstr "上記の最初の 2 つの方法は、ホストがインターネットにアクセスできる場合にのみ機能します。ホストがインターネットにアクセスできない場合は、まずインターネットにアクセスできる別のホスト上で上記の方法を使用してモジュールをインストールし、それをコピーする必要があります。モジュールをローカルのファイルパスに保存するには、次の PowerShell コマンドレットを実行します。" + +#: ../../rst/user_guide/windows_dsc.rst:374 +msgid "This will create a folder called ``xWebAdministration`` in ``C:\\temp``, which can be copied to any host. For PowerShell to see this offline resource, it must be copied to a directory set in the ``PSModulePath`` environment variable. In most cases, the path ``C:\\Program Files\\WindowsPowerShell\\Module`` is set through this variable, but the ``win_path`` module can be used to add different paths." +msgstr "これにより、``C:\\temp`` の中に``xWebAdministration`` フォルダーが作成され、このフィルダーはどのホストにもコピーできるようになります。PowerShell がこのオフラインリソースを見るためには、環境変数 ``PSModulePath`` で設定されたディレクトリーにコピーされている必要があります。ほとんどの場合は、この変数を通じてパス ``C:\\Program Files\\WindowsPowerShell\\Module`` が設定されますが、``win_path`` モジュールを使用して異なるパスを追加することができます。" + +#: ../../rst/user_guide/windows_dsc.rst:382 +msgid "Examples" +msgstr "例" + +#: ../../rst/user_guide/windows_dsc.rst:384 +msgid "Extract a zip file" +msgstr "zip ファイルの展開" + +#: ../../rst/user_guide/windows_dsc.rst:396 +msgid "Create a directory" +msgstr "ディレクトリーの作成" + +#: ../../rst/user_guide/windows_dsc.rst:419 +msgid "Interact with Azure" +msgstr "Azure の操作" + +#: ../../rst/user_guide/windows_dsc.rst:442 +msgid "Setup IIS Website" +msgstr "IIS Web サイトのセットアップ" + +#: ../../rst/user_guide/windows_dsc.rst:501 +#: ../../rst/user_guide/windows_setup.rst:573 +#: ../../rst/user_guide/windows_usage.rst:512 +#: ../../rst/user_guide/windows_winrm.rst:1004 +msgid ":ref:`List of Windows Modules <windows_modules>`" +msgstr ":ref:`List of Windows Modules <windows_modules>`" + +#: ../../rst/user_guide/windows_dsc.rst:502 +#: ../../rst/user_guide/windows_setup.rst:574 +#: ../../rst/user_guide/windows_usage.rst:513 +#: ../../rst/user_guide/windows_winrm.rst:1005 +msgid "Windows specific module list, all implemented in PowerShell" +msgstr "Windows 固有のモジュールリスト (すべて PowerShell に実装)" + +#: ../../rst/user_guide/windows_faq.rst:4 +msgid "Windows Frequently Asked Questions" +msgstr "Windows に関するよくある質問 (FAQ)" + +#: ../../rst/user_guide/windows_faq.rst:6 +msgid "Here are some commonly asked questions in regards to Ansible and Windows and their answers." +msgstr "ここでは、Ansible および Windows に関するよくある質問とその回答を紹介します。" + +#: ../../rst/user_guide/windows_faq.rst:9 +msgid "This document covers questions about managing Microsoft Windows servers with Ansible. For questions about Ansible Core, please see the :ref:`general FAQ page <ansible_faq>`." +msgstr "本ガイドでは、Ansible を使用した Microsoft Windows サーバーの管理に関する質問について説明します。Ansible Core に関する質問は、「:ref:`一般的な FAQ ページ <ansible_faq>`」を参照してください。" + +#: ../../rst/user_guide/windows_faq.rst:14 +msgid "Does Ansible work with Windows XP or Server 2003?" +msgstr "Ansible は、Windows XP または Server 2003 で動作しますか" + +#: ../../rst/user_guide/windows_faq.rst:15 +msgid "Ansible does not work with Windows XP or Server 2003 hosts. Ansible does work with these Windows operating system versions:" +msgstr "Ansible は、Windows XP または Server 2003 ホストでは動作しません。Ansible は、以下の Windows オペレーティングシステムバージョンで動作します。" + +#: ../../rst/user_guide/windows_faq.rst:17 +msgid "Windows Server 2008 :sup:`1`" +msgstr "Windows Server 2008 :sup:`1`" + +#: ../../rst/user_guide/windows_faq.rst:18 +msgid "Windows Server 2008 R2 :sup:`1`" +msgstr "Windows Server 2008 R2 :sup:`1`" + +#: ../../rst/user_guide/windows_faq.rst:19 +msgid "Windows Server 2012" +msgstr "Windows Server 2012" + +#: ../../rst/user_guide/windows_faq.rst:20 +msgid "Windows Server 2012 R2" +msgstr "Windows Server 2012 R2" + +#: ../../rst/user_guide/windows_faq.rst:21 +msgid "Windows Server 2016" +msgstr "Windows Server 2016" + +#: ../../rst/user_guide/windows_faq.rst:22 +msgid "Windows Server 2019" +msgstr "Windows Server 2019" + +#: ../../rst/user_guide/windows_faq.rst:23 +msgid "Windows 7 :sup:`1`" +msgstr "Windows 7 :sup:`1`" + +#: ../../rst/user_guide/windows_faq.rst:24 +msgid "Windows 8.1" +msgstr "Windows 8.1" + +#: ../../rst/user_guide/windows_faq.rst:25 +msgid "Windows 10" +msgstr "Windows 10" + +#: ../../rst/user_guide/windows_faq.rst:27 +msgid "1 - See the :ref:`Server 2008 FAQ <windows_faq_server2008>` entry for more details." +msgstr "1 - 詳細は、:ref:`Server 2008 FAQ <windows_faq_server2008>` を参照してください。" + +#: ../../rst/user_guide/windows_faq.rst:29 +msgid "Ansible also has minimum PowerShell version requirements - please see :ref:`windows_setup` for the latest information." +msgstr "また、Ansible には PowerShell の最小バージョン要件があります。最新情報は「:ref:`windows_setup`」を参照してください。" + +#: ../../rst/user_guide/windows_faq.rst:35 +msgid "Are Server 2008, 2008 R2 and Windows 7 supported?" +msgstr "Server 2008、2008 R2、Windows 7 に対応していますか" + +#: ../../rst/user_guide/windows_faq.rst:36 +msgid "Microsoft ended Extended Support for these versions of Windows on January 14th, 2020, and Ansible deprecated official support in the 2.10 release. No new feature development will occur targeting these operating systems, and automated testing has ceased. However, existing modules and features will likely continue to work, and simple pull requests to resolve issues with these Windows versions may be accepted." +msgstr "Microsoft は 2020 年 1 月 14 日にこれらのバージョンの Windows の Extended Support を終了し、Ansible は 2.10 のリリースで公式サポートを終了しました。これらのオペレーティングシステムを対象とした新機能の開発は今後行われず、自動テストも終了しています。しかし、既存のモジュールや機能は引き続き動作する可能性があり、これらの Windows バージョンに関する問題を解決するための簡単なプル要求は承認される可能性があります。" + +#: ../../rst/user_guide/windows_faq.rst:39 +msgid "Can I manage Windows Nano Server with Ansible?" +msgstr "Ansible で Windows Nano Server を管理できますか" + +#: ../../rst/user_guide/windows_faq.rst:40 +msgid "Ansible does not currently work with Windows Nano Server, since it does not have access to the full .NET Framework that is used by the majority of the modules and internal components." +msgstr "Ansible は現在、Windows Nano Server では動作しません。これは、大部分のモジュールや内部コンポーネントで使用されている完全な .NET フレームワークにアクセスできないためです。" + +#: ../../rst/user_guide/windows_faq.rst:47 +msgid "Can Ansible run on Windows?" +msgstr "Ansible は Windows で実行できますか" + +#: ../../rst/user_guide/windows_faq.rst:48 +msgid "No, Ansible can only manage Windows hosts. Ansible cannot run on a Windows host natively, though it can run under the Windows Subsystem for Linux (WSL)." +msgstr "いいえ、Ansible は Windows ホストのみを管理できます。Ansible は Windows ホスト上ではネイティブに実行できませんが、Windows Subsystem for Linux (WSL) の下で実行できます。" + +#: ../../rst/user_guide/windows_faq.rst:51 +msgid "The Windows Subsystem for Linux is not supported by Ansible and should not be used for production systems." +msgstr "Windows Subsystem for Linux は Ansible ではサポートされていないため、実稼働システムには使用しないでください。" + +#: ../../rst/user_guide/windows_faq.rst:54 +msgid "To install Ansible on WSL, the following commands can be run in the bash terminal:" +msgstr "WSL に Ansible をインストールするには、bash ターミナルで以下のコマンドを実行します。" + +#: ../../rst/user_guide/windows_faq.rst:63 +msgid "To run Ansible from source instead of a release on the WSL, simply uninstall the pip installed version and then clone the git repo." +msgstr "WSL のリリースではなくソースから Ansible を実行するには、インストールした pip をアンインストールし、git リポジトリーのクローンを作成します。" + +#: ../../rst/user_guide/windows_faq.rst:75 +msgid "If you encounter timeout errors when running Ansible on the WSL, this may be due to an issue with ``sleep`` not returning correctly. The following workaround may resolve the issue:" +msgstr "WSL 上で Ansible を実行したときにタイムアウトエラーが発生する場合は、``sleep`` が正しく返されない問題が原因となっている可能性があります。以下の回避策により、この問題が解決される場合があります。" + +#: ../../rst/user_guide/windows_faq.rst:83 +msgid "Another option is to use WSL 2 if running Windows 10 later than build 2004." +msgstr "別のオプションとして、ビルド 2004 よりも Windows 10 以上を実行している場合は WSL 2 を使用します。" + +#: ../../rst/user_guide/windows_faq.rst:91 +msgid "Can I use SSH keys to authenticate to Windows hosts?" +msgstr "SSH キーを使用して Windows ホストへの認証を行うことはできますか" + +#: ../../rst/user_guide/windows_faq.rst:92 +msgid "You cannot use SSH keys with the WinRM or PSRP connection plugins. These connection plugins use X509 certificates for authentication instead of the SSH key pairs that SSH uses." +msgstr "WinRM または PSRP connection プラグインで SSH 鍵を使用することはできません。これらの connection プラグインは、認証に SSH が使用する SSH キーペアを使用する代わりに、X509 証明書を使用します。" + +#: ../../rst/user_guide/windows_faq.rst:96 +msgid "The way X509 certificates are generated and mapped to a user is different from the SSH implementation; consult the :ref:`windows_winrm` documentation for more information." +msgstr "X509 証明書が生成され、ユーザーにマッピングされる方法は、SSH の実装とは異なります。詳細は、:ref:`windows_winrm` のドキュメントを参照してください。" + +#: ../../rst/user_guide/windows_faq.rst:100 +msgid "Ansible 2.8 has added an experimental option to use the SSH connection plugin, which uses SSH keys for authentication, for Windows servers. See :ref:`this question <windows_faq_ssh>` for more information." +msgstr "Ansible 2.8 には、認証に SSH 鍵を使用する SSH connection プラグインを Windows サーバーで使用する実験的なオプションが追加されました。詳細は「:ref:`this question <windows_faq_ssh>`」を参照してください。" + +#: ../../rst/user_guide/windows_faq.rst:107 +msgid "Why can I run a command locally that does not work under Ansible?" +msgstr "Ansible で機能しないコマンドをローカルで実行できるのはなぜですか" + +#: ../../rst/user_guide/windows_faq.rst:108 +msgid "Ansible executes commands through WinRM. These processes are different from running a command locally in these ways:" +msgstr "Ansible は、WinRM を介してコマンドを実行します。これらのプロセスは、以下の方法でローカルでコマンドを実行するのとは異なります。" + +#: ../../rst/user_guide/windows_faq.rst:111 +msgid "Unless using an authentication option like CredSSP or Kerberos with credential delegation, the WinRM process does not have the ability to delegate the user's credentials to a network resource, causing ``Access is Denied`` errors." +msgstr "CredSSP や Kerberos のような認証オプションを使用して、認証情報の委譲を行っていない限り、WinRM プロセスにはユーザーの認証情報をネットワークリソースに委譲する機能がなく、``Access is Denied`` エラーが発生します。" + +#: ../../rst/user_guide/windows_faq.rst:116 +msgid "All processes run under WinRM are in a non-interactive session. Applications that require an interactive session will not work." +msgstr "WinRM で実行されるすべてのプロセスは、非対話型セッションです。対話型セッションを必要とするアプリケーションは機能しません。" + +#: ../../rst/user_guide/windows_faq.rst:119 +msgid "When running through WinRM, Windows restricts access to internal Windows APIs like the Windows Update API and DPAPI, which some installers and programs rely on." +msgstr "WinRM を介して実行する場合、Windows は、一部のインストーラーやプログラムが依存している Windows Update API や DPAPI などの Windows 内部 API へのアクセスを制限します。" + +#: ../../rst/user_guide/windows_faq.rst:123 +msgid "Some ways to bypass these restrictions are to:" +msgstr "これらの制限を回避する方法は次のとおりです。" + +#: ../../rst/user_guide/windows_faq.rst:125 +msgid "Use ``become``, which runs a command as it would when run locally. This will bypass most WinRM restrictions, as Windows is unaware the process is running under WinRM when ``become`` is used. See the :ref:`become` documentation for more information." +msgstr "``become`` を使用すると、ローカルで実行するときと同じようにコマンドを実行できます。``become`` を使用すると、Windows はプロセスが WinRM の下で実行していることに気づかないため、ほとんどの WinRM の制限を回避することができます。詳細は、:ref:`become` のドキュメントを参照してください。" + +#: ../../rst/user_guide/windows_faq.rst:130 +msgid "Use a scheduled task, which can be created with ``win_scheduled_task``. Like ``become``, it will bypass all WinRM restrictions, but it can only be used to run commands, not modules." +msgstr "``win_scheduled_task`` で作成できる、スケジュールされたタスクを使用します。``become`` と同様に、WinRM の制限をすべて回避できますが、モジュールではなくコマンドの実行にのみ使用できます。" + +#: ../../rst/user_guide/windows_faq.rst:134 +msgid "Use ``win_psexec`` to run a command on the host. PSExec does not use WinRM and so will bypass any of the restrictions." +msgstr "``win_psexec`` を使用してホストでコマンドを実行します。PSExec は WinRM を使用しないため、あらゆる制限を回避することができます。" + +#: ../../rst/user_guide/windows_faq.rst:137 +msgid "To access network resources without any of these workarounds, you can use CredSSP or Kerberos with credential delegation enabled." +msgstr "これらの回避策を取らずにネットワークリソースにアクセスするには、認証情報の委譲を有効にした CredSSP または Kerberos を使用することができます。" + +#: ../../rst/user_guide/windows_faq.rst:140 +msgid "See :ref:`become` more info on how to use become. The limitations section at :ref:`windows_winrm` has more details around WinRM limitations." +msgstr "become の使用方法に関する詳細は、「:ref:`become`」を参照してください。:ref:`windows_winrm` の制限のセクションには、WinRM 制限の詳細が記載されています。" + +#: ../../rst/user_guide/windows_faq.rst:144 +msgid "This program won't install on Windows with Ansible" +msgstr "このプログラムが、Ansible がインストールされている Windows にはインストールされません" + +#: ../../rst/user_guide/windows_faq.rst:145 +msgid "See :ref:`this question <windows_faq_winrm>` for more information about WinRM limitations." +msgstr "WinRMの制限の詳細は、「:ref:`こちらの質問 <windows_faq_winrm>`」を参照してください。" + +#: ../../rst/user_guide/windows_faq.rst:148 +msgid "What Windows modules are available?" +msgstr "どのような Windows モジュールが利用できますか" + +#: ../../rst/user_guide/windows_faq.rst:149 +msgid "Most of the Ansible modules in Ansible Core are written for a combination of Linux/Unix machines and arbitrary web services. These modules are written in Python and most of them do not work on Windows." +msgstr "Ansible Core の Ansible モジュールの多くは、Linux/Unix マシンと任意の Web サービスの組み合わせを想定して記述されます。これらのモジュールは Python で記述されており、そのほとんどが Windows では動作しません。" + +#: ../../rst/user_guide/windows_faq.rst:153 +msgid "Because of this, there are dedicated Windows modules that are written in PowerShell and are meant to be run on Windows hosts. A list of these modules can be found :ref:`here <windows_modules>`." +msgstr "このため、PowerShell で記述されており、Windows ホストで実行することを目的としている専用の Windows モジュールがあります。これらのモジュールの一覧は、「:ref:`here <windows_modules>`」にあります。" + +#: ../../rst/user_guide/windows_faq.rst:157 +msgid "In addition, the following Ansible Core modules/action-plugins work with Windows:" +msgstr "次の Ansible Core モジュールおよびアクションプラグインは、Windows で動作します。" + +#: ../../rst/user_guide/windows_faq.rst:159 +msgid "add_host" +msgstr "add_host" + +#: ../../rst/user_guide/windows_faq.rst:160 +msgid "assert" +msgstr "assert" + +#: ../../rst/user_guide/windows_faq.rst:161 +msgid "async_status" +msgstr "async_status" + +#: ../../rst/user_guide/windows_faq.rst:162 +msgid "debug" +msgstr "debug" + +#: ../../rst/user_guide/windows_faq.rst:163 +msgid "fail" +msgstr "fail" + +#: ../../rst/user_guide/windows_faq.rst:164 +msgid "fetch" +msgstr "fetch" + +#: ../../rst/user_guide/windows_faq.rst:165 +msgid "group_by" +msgstr "group_by" + +#: ../../rst/user_guide/windows_faq.rst:166 +msgid "include" +msgstr "include" + +#: ../../rst/user_guide/windows_faq.rst:167 +msgid "include_role" +msgstr "include_role" + +#: ../../rst/user_guide/windows_faq.rst:169 +msgid "meta" +msgstr "meta" + +#: ../../rst/user_guide/windows_faq.rst:170 +msgid "pause" +msgstr "pause" + +#: ../../rst/user_guide/windows_faq.rst:171 +msgid "raw" +msgstr "raw" + +#: ../../rst/user_guide/windows_faq.rst:172 +msgid "script" +msgstr "script" + +#: ../../rst/user_guide/windows_faq.rst:173 +msgid "set_fact" +msgstr "set_fact" + +#: ../../rst/user_guide/windows_faq.rst:174 +msgid "set_stats" +msgstr "set_stats" + +#: ../../rst/user_guide/windows_faq.rst:175 +msgid "setup" +msgstr "setup" + +#: ../../rst/user_guide/windows_faq.rst:176 +msgid "slurp" +msgstr "slurp" + +#: ../../rst/user_guide/windows_faq.rst:177 +msgid "template (also: win_template)" +msgstr "template (win_template も同様)" + +#: ../../rst/user_guide/windows_faq.rst:178 +msgid "wait_for_connection" +msgstr "wait_for_connection" + +#: ../../rst/user_guide/windows_faq.rst:180 +msgid "Ansible Windows modules exist in the :ref:`plugins_in_ansible.windows`, :ref:`plugins_in_community.windows`, and :ref:`plugins_in_chocolatey.chocolatey` collections." +msgstr "Ansible Windows モジュールは、:ref:`plugins_in_ansible.windows`、:ref:`plugins_in_community.windows`、および :ref:`plugins_in_chocolatey.chocolatey` コレクションに存在します。" + +#: ../../rst/user_guide/windows_faq.rst:183 +msgid "Can I run Python modules on Windows hosts?" +msgstr "Windows ホストで Python モジュールを実行できますか" + +#: ../../rst/user_guide/windows_faq.rst:184 +msgid "No, the WinRM connection protocol is set to use PowerShell modules, so Python modules will not work. A way to bypass this issue to use ``delegate_to: localhost`` to run a Python module on the Ansible controller. This is useful if during a playbook, an external service needs to be contacted and there is no equivalent Windows module available." +msgstr "できません。WinRM 接続プロトコルは PowerShell モジュールを使用するように設定されているため、Python モジュールは動作しません。この問題を回避するには、``delegate_to: localhost`` を使用して Ansible コントローラー上で Python モジュールを実行する方法があります。これは、Playbook 中に外部サービスに接続する必要があり、同等の Windows モジュールがない場合に便利です。" + +#: ../../rst/user_guide/windows_faq.rst:193 +msgid "Can I connect to Windows hosts over SSH?" +msgstr "SSH 経由で Windows ホストに接続できますか" + +#: ../../rst/user_guide/windows_faq.rst:194 +msgid "Ansible 2.8 has added an experimental option to use the SSH connection plugin to manage Windows hosts. To connect to Windows hosts over SSH, you must install and configure the `Win32-OpenSSH <https://github.com/PowerShell/Win32-OpenSSH>`_ fork that is in development with Microsoft on the Windows host(s). While most of the basics should work with SSH, ``Win32-OpenSSH`` is rapidly changing, with new features added and bugs fixed in every release. It is highly recommend you `install <https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH>`_ the latest release of ``Win32-OpenSSH`` from the GitHub Releases page when using it with Ansible on Windows hosts." +msgstr "Ansible 2.8 には、SSH connection プラグインを使用して Windows ホストを管理する実験的なオプションが追加されました。Windows ホストに SSH 接続するには、Microsoft と共同で開発中の `Win32-OpenSSH <https://github.com/PowerShell/Win32-OpenSSH>`_ フォークを Windows ホストにインストールして設定する必要があります。基本的な機能のほとんどは SSH で動作するはずですが、``Win32-OpenSSH`` はリリースごとに新機能が追加されたり、バグが修正されたりと、急速に変化しています。Windows ホストで Ansible を使用する際には、GitHub Releases ページから ``Win32-OpenSSH`` の最新リリースを `インストール <https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH>`_ することが強く推奨されます。" + +#: ../../rst/user_guide/windows_faq.rst:203 +msgid "To use SSH as the connection to a Windows host, set the following variables in the inventory:" +msgstr "Windows ホストへの接続に SSH を使用するには、インベントリーに以下の変数を設定します。" + +#: ../../rst/user_guide/windows_faq.rst:214 +msgid "The value for ``ansible_shell_type`` should either be ``cmd`` or ``powershell``. Use ``cmd`` if the ``DefaultShell`` has not been configured on the SSH service and ``powershell`` if that has been set as the ``DefaultShell``." +msgstr "``ansible_shell_type`` の値は、``cmd`` または ``powershell`` のいずれかでなければなりません。SSH サービスで ``DefaultShell`` が設定されていない場合は ``cmd`` を使用して、``DefaultShell`` として設定されている場合は ``powershell`` を使用してください。" + +#: ../../rst/user_guide/windows_faq.rst:219 +msgid "Why is connecting to a Windows host via SSH failing?" +msgstr "SSH 経由で Windows ホストに接続できないのはなぜですか" + +#: ../../rst/user_guide/windows_faq.rst:220 +msgid "Unless you are using ``Win32-OpenSSH`` as described above, you must connect to Windows hosts using :ref:`windows_winrm`. If your Ansible output indicates that SSH was used, either you did not set the connection vars properly or the host is not inheriting them correctly." +msgstr "上記のように ``Win32-OpenSSH`` を使用している場合を除き、Windows ホストへの接続には :ref:`windows_winrm` を使用する必要があります。Ansible の出力で SSH が使用されたと表示された場合は、接続バーが正しく設定されていないか、ホストに正しく継承されていません。" + +#: ../../rst/user_guide/windows_faq.rst:224 +msgid "Make sure ``ansible_connection: winrm`` is set in the inventory for the Windows host(s)." +msgstr "Windows ホストのインベントリーに ``ansible_connection: winrm`` が設定されていることを確認してください。" + +#: ../../rst/user_guide/windows_faq.rst:228 +msgid "Why are my credentials being rejected?" +msgstr "認証情報が拒否されるのはなぜですか" + +#: ../../rst/user_guide/windows_faq.rst:229 +msgid "This can be due to a myriad of reasons unrelated to incorrect credentials." +msgstr "これは、誤った認証情報とは無関係の、多種多様なものが原因である可能性があります。" + +#: ../../rst/user_guide/windows_faq.rst:231 +msgid "See HTTP 401/Credentials Rejected at :ref:`windows_setup` for a more detailed guide of this could mean." +msgstr "この現象の詳細については、:ref:`windows_setup` の「HTTP 401/認証情報の拒否」を参照してください。" + +#: ../../rst/user_guide/windows_faq.rst:235 +msgid "Why am I getting an error SSL CERTIFICATE_VERIFY_FAILED?" +msgstr "SSL CERTIFICATE_VERIFY_FAILED エラーが発生するのはなぜですか" + +#: ../../rst/user_guide/windows_faq.rst:236 +msgid "When the Ansible controller is running on Python 2.7.9+ or an older version of Python that has backported SSLContext (like Python 2.7.5 on RHEL 7), the controller will attempt to validate the certificate WinRM is using for an HTTPS connection. If the certificate cannot be validated (such as in the case of a self signed cert), it will fail the verification process." +msgstr "Ansible コントローラーが Python 2.7.9 以降または SSLContext をバックポートした古いバージョンの Python (RHEL 7 の Python 2.7.5 など) で動作している場合、コントローラーは WinRM が HTTPS 接続に使用している証明書を検証しようとします。証明書を検証できない場合 (自己署名証明書の場合など) は、検証プロセスに失敗します。" + +#: ../../rst/user_guide/windows_faq.rst:242 +msgid "To ignore certificate validation, add ``ansible_winrm_server_cert_validation: ignore`` to inventory for the Windows host." +msgstr "証明書の検証を無視するには、Windows ホストのインベントリーに ``ansible_winrm_server_cert_validation: ignore`` を追加してください。" + +#: ../../rst/user_guide/windows_faq.rst:248 +msgid ":ref:`windows`" +msgstr ":ref:`windows`" + +#: ../../rst/user_guide/windows_faq.rst:249 +msgid "The Windows documentation index" +msgstr "Windows ドキュメントの目次" + +#: ../../rst/user_guide/windows_performance.rst:4 +msgid "Windows performance" +msgstr "Windows パフォーマンス" + +#: ../../rst/user_guide/windows_performance.rst:5 +msgid "This document offers some performance optimizations you might like to apply to your Windows hosts to speed them up specifically in the context of using Ansible with them, and generally." +msgstr "本書では、特に Ansible をそのホストで使用するような状況、および一般的に使用する状況で高速化するために、Windows ホストに適用するパフォーマンスの最適化をいくつか説明します。" + +#: ../../rst/user_guide/windows_performance.rst:10 +msgid "Optimize PowerShell performance to reduce Ansible task overhead" +msgstr "Ansible タスクのオーバーヘッドを軽減するための PowerShell のパフォーマンスの最適化" + +#: ../../rst/user_guide/windows_performance.rst:11 +msgid "To speed up the startup of PowerShell by around 10x, run the following PowerShell snippet in an Administrator session. Expect it to take tens of seconds." +msgstr "PowerShell の起動を約 10 倍高速化するには、Administrator セッションで以下の PowerShell スニペットを実行します。数十秒かかることが予想されます。" + +#: ../../rst/user_guide/windows_performance.rst:17 +msgid "If native images have already been created by the ngen task or service, you will observe no difference in performance (but this snippet will at that point execute faster than otherwise)." +msgstr "ネイティブイメージが ngen タスクやサービスによってすでに作成されている場合は、パフォーマンスに違いはありません (ただし、このスニペットはその時点で他の場合よりも高速に実行されます)。" + +#: ../../rst/user_guide/windows_performance.rst:42 +msgid "PowerShell is used by every Windows Ansible module. This optimization reduces the time PowerShell takes to start up, removing that overhead from every invocation." +msgstr "PowerShell はすべての Windows Ansible モジュールによって使用されます。この最適化により、PowerShell の起動時間を短縮し、呼び出しごとにそのオーバーヘッドを取り除きます。" + +#: ../../rst/user_guide/windows_performance.rst:45 +msgid "This snippet uses `the native image generator, ngen <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#WhenToUse>`_ to pre-emptively create native images for the assemblies that PowerShell relies on." +msgstr "このスニペットは `ネイティブイメージジェネレーター ngen <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#WhenToUse>`_ を使用して、PowerShell が依存しているアセンブリーのネイティブイメージを事前に作成します。" + +#: ../../rst/user_guide/windows_performance.rst:49 +msgid "Fix high-CPU-on-boot for VMs/cloud instances" +msgstr "仮想マシン/クラウドインスタンスの、システム起動時の高 CPU を修正" + +#: ../../rst/user_guide/windows_performance.rst:50 +msgid "If you are creating golden images to spawn instances from, you can avoid a disruptive high CPU task near startup via `processing the ngen queue <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#native-image-service>`_ within your golden image creation, if you know the CPU types won't change between golden image build process and runtime." +msgstr "インスタンスを生成するためにゴールデンイメージを作成している場合は、ゴールデンイメージのビルドプロセスとランタイムの間で CPU タイプが変わらないことがわかっていれば、ゴールデンイメージの作成時に `ngen キューの処理 <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#native-image-service>`_ を使用することで、起動時に高い CPU タスクが発生するのを防ぐことができます。" + +#: ../../rst/user_guide/windows_performance.rst:55 +msgid "Place the following near the end of your playbook, bearing in mind the factors that can cause native images to be invalidated (`see MSDN <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#native-images-and-jit-compilation>`_)." +msgstr "Playbook の最後付近に以下を置き、ネイティブイメージが無効になる可能性のある要素に注意してください (`MSDN <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#native-images-and-jit-compilation>`_ を参照)。" + +#: ../../rst/user_guide/windows_setup.rst:4 +msgid "Setting up a Windows Host" +msgstr "Windows ホストのセットアップ" + +#: ../../rst/user_guide/windows_setup.rst:5 +msgid "This document discusses the setup that is required before Ansible can communicate with a Microsoft Windows host." +msgstr "本書では、Ansible が Microsoft Windows ホストと通信する前に必要なセットアップを説明します。" + +#: ../../rst/user_guide/windows_setup.rst:12 +msgid "For Ansible to communicate to a Windows host and use Windows modules, the Windows host must meet these requirements:" +msgstr "Ansible が Windows ホストと通信し、Windows モジュールを使用するためには、Windows ホストが以下の要件を満たす必要があります。" + +#: ../../rst/user_guide/windows_setup.rst:15 +msgid "Ansible can generally manage Windows versions under current and extended support from Microsoft. Ansible can manage desktop OSs including Windows 8.1, and 10, and server OSs including Windows Server 2012, 2012 R2, 2016, 2019, and 2022." +msgstr "Ansible は、Microsoft の現行および拡張サポート下にある Windows バージョンを一般的に管理できます。Ansible は、Windows 8.1および 10 を含むデスクトップ OS、ならびに Windows Server 2012、2012 R2、2016、2019、および 2022 を含むサーバー OS を管理できます。" + +#: ../../rst/user_guide/windows_setup.rst:20 +msgid "Ansible requires PowerShell 3.0 or newer and at least .NET 4.0 to be installed on the Windows host." +msgstr "Ansible を利用するには、Windows ホストに PowerShell 3.0 以降と少なくとも .NET 4.0 がインストールされている必要があります。" + +#: ../../rst/user_guide/windows_setup.rst:23 +msgid "A WinRM listener should be created and activated. More details for this can be found below." +msgstr "WinRM リスナーを作成し、有効にする必要があります。詳細は以下を参照してください。" + +#: ../../rst/user_guide/windows_setup.rst:26 +msgid "While these are the base requirements for Ansible connectivity, some Ansible modules have additional requirements, such as a newer OS or PowerShell version. Please consult the module's documentation page to determine whether a host meets those requirements." +msgstr "これらは、Ansible 接続の基本的な要件ですが、Ansible モジュールの中には、新しい OS や PowerShell のバージョンなど、追加の要件があるものもあります。ホストがこれらの要件を満たしているかどうかは、モジュールのドキュメントページを参照してください。" + +#: ../../rst/user_guide/windows_setup.rst:32 +msgid "Upgrading PowerShell and .NET Framework" +msgstr "PowerShell および .NET Framework のアップグレード" + +#: ../../rst/user_guide/windows_setup.rst:33 +msgid "Ansible requires PowerShell version 3.0 and .NET Framework 4.0 or newer to function on older operating systems like Server 2008 and Windows 7. The base image does not meet this requirement. You can use the `Upgrade-PowerShell.ps1 <https://github.com/jborean93/ansible-windows/blob/master/scripts/Upgrade-PowerShell.ps1>`_ script to update these." +msgstr "Ansible が Server 2008 や Windows 7 などの古いオペレーティングシステムで機能するためには、PowerShell の バージョン3.0 と .NET Framework 4.0 以降が必要です。ベースイメージは、この要件を満たしていません。`Upgrade-PowerShell.ps1 <https://github.com/jborean93/ansible-windows/blob/master/scripts/Upgrade-PowerShell.ps1>`_ スクリプトを使用してこれらを更新することができます。" + +#: ../../rst/user_guide/windows_setup.rst:36 +msgid "This is an example of how to run this script from PowerShell:" +msgstr "このスクリプトを PowerShell から実行する例を以下に示します。" + +#: ../../rst/user_guide/windows_setup.rst:52 +msgid "Once completed, you will need to remove auto logon and set the execution policy back to the default (``Restricted `` for Windows clients, or ``RemoteSigned`` for Windows servers). You can do this with the following PowerShell commands:" +msgstr "完了したら、自動ログオンを解除して、実行ポリシーをデフォルト (Windows クライアントの場合は ``Restricted ``、Windows サーバーの場合は ``RemoteSigned``) に戻す必要があります。これには以下の PowerShell コマンドが必要です。" + +#: ../../rst/user_guide/windows_setup.rst:66 +msgid "The script works by checking to see what programs need to be installed (such as .NET Framework 4.5.2) and what PowerShell version is required. If a reboot is required and the ``username`` and ``password`` parameters are set, the script will automatically reboot and logon when it comes back up from the reboot. The script will continue until no more actions are required and the PowerShell version matches the target version. If the ``username`` and ``password`` parameters are not set, the script will prompt the user to manually reboot and logon when required. When the user is next logged in, the script will continue where it left off and the process continues until no more actions are required." +msgstr "このスクリプトは、インストールが必要なプログラム (.NET Framework 4.5.2 など) や、必要な PowerShell バージョンを確認して動作します。再起動が必要で、``username`` パラメーターと ``password`` パラメーターが設定されている場合は、スクリプトが自動的に再起動し、再起動から復帰したときにログオンします。スクリプトは、アクションが不要になり、PowerShell バージョンがターゲットのバージョンと一致するまで続行されます。``username`` パラメーターおよび ``password`` パラメーターが設定されていない場合、スクリプトは必要に応じてユーザーに手動で再起動とログオンを促します。ユーザーが次にログインすると、スクリプトは前回の続きを実行し、アクションが必要なくなるまで処理を続けます。" + +#: ../../rst/user_guide/windows_setup.rst:77 +msgid "If running on Server 2008, then SP2 must be installed. If running on Server 2008 R2 or Windows 7, then SP1 must be installed." +msgstr "Server 2008 で実行する場合は、SP2 がインストールされている必要があります。Server 2008 R2 または Windows 7 で実行している場合は SP1 をインストールする必要があります。" + +#: ../../rst/user_guide/windows_setup.rst:80 +msgid "Windows Server 2008 can only install PowerShell 3.0; specifying a newer version will result in the script failing." +msgstr "Windows Server 2008 では PowerShell 3.0 しかインストールできないため、それより新しいバージョンを指定するとスクリプトが失敗します。" + +#: ../../rst/user_guide/windows_setup.rst:83 +msgid "The ``username`` and ``password`` parameters are stored in plain text in the registry. Make sure the cleanup commands are run after the script finishes to ensure no credentials are still stored on the host." +msgstr "``username`` と ``password`` のパラメーターは、レジストリーに平文で保存されます。スクリプトの終了後にクリーンアップコマンドを実行して、ホスト上に認証情報が保存されていないことを確認してください。" + +#: ../../rst/user_guide/windows_setup.rst:88 +msgid "WinRM Memory Hotfix" +msgstr "WinRM Memory Hotfix" + +#: ../../rst/user_guide/windows_setup.rst:89 +msgid "When running on PowerShell v3.0, there is a bug with the WinRM service that limits the amount of memory available to WinRM. Without this hotfix installed, Ansible will fail to execute certain commands on the Windows host. These hotfixes should be installed as part of the system bootstrapping or imaging process. The script `Install-WMF3Hotfix.ps1 <https://github.com/jborean93/ansible-windows/blob/master/scripts/Install-WMF3Hotfix.ps1>`_ can be used to install the hotfix on affected hosts." +msgstr "PowerShell v3.0 で実行する場合は、WinRM サービスのバグにより、WinRM で使用できるメモリー量が制限されるという問題がありました。この Hotfix をインストールしないと、Windows ホスト上で Ansible による特定のコマンドの実行に失敗します。これらの Hotfix は、システムのブートストラップまたはイメージングプロセスの一部としてインストールする必要があります。`Install-WMF3Hotfix.ps1 <https://github.com/jborean93/ansible-windows/blob/master/scripts/Install-WMF3Hotfix.ps1>`_ というスクリプトを使用すると、影響を受けるホストに hotfix をインストールできます。" + +#: ../../rst/user_guide/windows_setup.rst:95 +msgid "The following PowerShell command will install the hotfix:" +msgstr "以下の PowerShell コマンドは hotfix をインストールします。" + +#: ../../rst/user_guide/windows_setup.rst:106 +msgid "For more details, please refer to the `Hotfix document <https://support.microsoft.com/en-us/help/2842230/out-of-memory-error-on-a-computer-that-has-a-customized-maxmemorypersh>`_ from Microsoft." +msgstr "詳細は、Microsoft 社の `Hotfix ドキュメント <https://support.microsoft.com/en-us/help/2842230/out-of-memory-error-on-a-computer-that-has-a-customized-maxmemorypersh>`_ を参照してください。" + +#: ../../rst/user_guide/windows_setup.rst:109 +msgid "WinRM Setup" +msgstr "WinRM の設定" + +#: ../../rst/user_guide/windows_setup.rst:110 +msgid "Once Powershell has been upgraded to at least version 3.0, the final step is to configure the WinRM service so that Ansible can connect to it. There are two main components of the WinRM service that governs how Ansible can interface with the Windows host: the ``listener`` and the ``service`` configuration settings." +msgstr "Powershell をバージョン 3.0 以降にアップグレードしたら、最後のステップとして、WinRM サービスを設定して Ansible が接続できるようにします。WinRM サービスには、Ansible が Windows ホストとどのように連携するかを決定する構成設定 ``listener`` および ``service`` の 2 つの主要コンポーネントがあります。" + +#: ../../rst/user_guide/windows_setup.rst:116 +msgid "WinRM Listener" +msgstr "WinRM リスナー" + +#: ../../rst/user_guide/windows_setup.rst:117 +msgid "The WinRM services listens for requests on one or more ports. Each of these ports must have a listener created and configured." +msgstr "WinRM サービスは、1 つ以上のポートで要求をリッスンします。これらのポートごとにリスナーを作成し、設定する必要があります。" + +#: ../../rst/user_guide/windows_setup.rst:120 +msgid "To view the current listeners that are running on the WinRM service, run the following command:" +msgstr "WinRM サービスで実行している現在のリスナーを表示するには、次のコマンドを実行します。" + +#: ../../rst/user_guide/windows_setup.rst:127 +#: ../../rst/user_guide/windows_setup.rst:245 +msgid "This will output something like:" +msgstr "これにより、以下のようなものが出力されます。" + +#: ../../rst/user_guide/windows_setup.rst:153 +msgid "In the example above there are two listeners activated; one is listening on port 5985 over HTTP and the other is listening on port 5986 over HTTPS. Some of the key options that are useful to understand are:" +msgstr "上の例では、2 つのリスナーが有効になっています。1 つは HTTP でポート 5985 をリッスンしており、もう 1 つは HTTPS でポート 5986 をリッスンしています。理解しておくと便利なオプションをいくつか紹介します。" + +#: ../../rst/user_guide/windows_setup.rst:157 +msgid "``Transport``: Whether the listener is run over HTTP or HTTPS, it is recommended to use a listener over HTTPS as the data is encrypted without any further changes required." +msgstr "``Transport``: リスナーが HTTP または HTTPS のどちらで実行している場合でも、データはさらなる変更なしに暗号化されるため、HTTPS 経由でリスナーを使用することが推奨されます。" + +#: ../../rst/user_guide/windows_setup.rst:161 +msgid "``Port``: The port the listener runs on, by default it is ``5985`` for HTTP and ``5986`` for HTTPS. This port can be changed to whatever is required and corresponds to the host var ``ansible_port``." +msgstr "``Port``: リスナーが実行するポート。デフォルトは、HTTP の場合は ``5985``、HTTPS の場合は ``5986`` です。このポートは、必要なものにそれぞれ変更でき、ホスト変数 ``ansible_port`` に対応することができます。" + +#: ../../rst/user_guide/windows_setup.rst:165 +msgid "``URLPrefix``: The URL prefix to listen on, by default it is ``wsman``. If this is changed, the host var ``ansible_winrm_path`` must be set to the same value." +msgstr "``URLPrefix``: リッスンする URL プレフィックス。デフォルトは ``wsman`` です。これが変更された場合、ホスト変数 ``ansible_winrm_path`` は同じ値に設定する必要があります。" + +#: ../../rst/user_guide/windows_setup.rst:169 +msgid "``CertificateThumbprint``: If running over an HTTPS listener, this is the thumbprint of the certificate in the Windows Certificate Store that is used in the connection. To get the details of the certificate itself, run this command with the relevant certificate thumbprint in PowerShell:" +msgstr "``CertificateThumbprint``: HTTPS リスナーを介して実行する場合、これは接続に使用される Windows 証明書ストアの証明書のサムプリントです。証明書自体の詳細を取得するには、PowerShell で該当する証明書のサムプリントを指定して次のコマンドを実行します。" + +#: ../../rst/user_guide/windows_setup.rst:180 +msgid "Setup WinRM Listener" +msgstr "WinRM リスナーの設定" + +#: ../../rst/user_guide/windows_setup.rst:181 +msgid "There are three ways to set up a WinRM listener:" +msgstr "WinRM リスナーを設定するには、3 つの方法があります。" + +#: ../../rst/user_guide/windows_setup.rst:183 +msgid "Using ``winrm quickconfig`` for HTTP or ``winrm quickconfig -transport:https`` for HTTPS. This is the easiest option to use when running outside of a domain environment and a simple listener is required. Unlike the other options, this process also has the added benefit of opening up the Firewall for the ports required and starts the WinRM service." +msgstr "HTTP には ``winrm quickconfig`` を、HTTPS には ``winrm quickconfig -transport:https`` を使用します。これは、ドメイン環境外で動作し、シンプルなリスナーが必要な場合に、最も簡単に使用できるオプションです。他のオプションとは異なり、このプロセスには、必要なポートのためにファイアウォールを開き、WinRM サービスを開始するという利点があります。" + +#: ../../rst/user_guide/windows_setup.rst:189 +msgid "Using Group Policy Objects. This is the best way to create a listener when the host is a member of a domain because the configuration is done automatically without any user input. For more information on group policy objects, see the `Group Policy Objects documentation <https://msdn.microsoft.com/en-us/library/aa374162(v=vs.85).aspx>`_." +msgstr "グループポリシーオブジェクトの使用。設定は、ユーザーが入力せずに自動的に行われるため、この方法は、ホストがドメインのメンバーである場合にリスナーを作成するのに最適な方法です。グループポリシーオブジェクトの詳細は、`Group Policy Objects ドキュメント <https://msdn.microsoft.com/en-us/library/aa374162(v=vs.85).aspx>`_ を参照してください。" + +#: ../../rst/user_guide/windows_setup.rst:194 +msgid "Using PowerShell to create the listener with a specific configuration. This can be done by running the following PowerShell commands:" +msgstr "PowerShell を使用して、特定の設定でリスナーを作成します。これは、以下の PowerShell コマンドを実行することで可能になります。" + +#: ../../rst/user_guide/windows_setup.rst:209 +msgid "To see the other options with this PowerShell cmdlet, see `New-WSManInstance <https://docs.microsoft.com/en-us/powershell/module/microsoft.wsman.management/new-wsmaninstance?view=powershell-5.1>`_." +msgstr "この PowerShell コマンドレッドを伴う他のオプションを表示するには、「`New-WSManInstance <https://docs.microsoft.com/en-us/powershell/module/microsoft.wsman.management/new-wsmaninstance?view=powershell-5.1>`_」を参照してください。" + +#: ../../rst/user_guide/windows_setup.rst:212 +msgid "When creating an HTTPS listener, an existing certificate needs to be created and stored in the ``LocalMachine\\My`` certificate store. Without a certificate being present in this store, most commands will fail." +msgstr "HTTPS リスナーを作成する際には、既存の証明書を作成し、``LocalMachine\\My`` の証明書ストアに保存する必要があります。このストアに証明書が存在しないと、ほとんどのコマンドが失敗します。" + +#: ../../rst/user_guide/windows_setup.rst:217 +msgid "Delete WinRM Listener" +msgstr "WinRM リスナーの削除" + +#: ../../rst/user_guide/windows_setup.rst:218 +msgid "To remove a WinRM listener:" +msgstr "WinRM リスナーを削除するには、以下を実行します。" + +#: ../../rst/user_guide/windows_setup.rst:228 +msgid "The ``Keys`` object is an array of strings, so it can contain different values. By default it contains a key for ``Transport=`` and ``Address=`` which correspond to the values from winrm enumerate winrm/config/Listeners." +msgstr "``Keys`` オブジェクトは文字列の配列であるため、異なる値を含むことができます。デフォルトでは、winrm enumerate winrm/config/Listeners の値に対応する ``Transport=`` および ``Address=`` のキーを含んでいます。" + +#: ../../rst/user_guide/windows_setup.rst:233 +msgid "WinRM Service Options" +msgstr "WinRM サービスオプション" + +#: ../../rst/user_guide/windows_setup.rst:234 +msgid "There are a number of options that can be set to control the behavior of the WinRM service component, including authentication options and memory settings." +msgstr "WinRM サービスコンポーネントの動作を制御するように設定でき、認証オプションやメモリー設定など、複数のオプションを設定できます。" + +#: ../../rst/user_guide/windows_setup.rst:237 +msgid "To get an output of the current service configuration options, run the following command:" +msgstr "現在のサービス設定オプションの出力を得るには、次のコマンドを実行します。" + +#: ../../rst/user_guide/windows_setup.rst:283 +msgid "While many of these options should rarely be changed, a few can easily impact the operations over WinRM and are useful to understand. Some of the important options are:" +msgstr "これらのオプションの多くはほとんど変更する必要はありませんが、いくつかのオプションは WinRM の操作に簡単に影響を与えるため、理解しておくと便利です。重要なオプションの一部を紹介します。" + +#: ../../rst/user_guide/windows_setup.rst:287 +msgid "``Service\\AllowUnencrypted``: This option defines whether WinRM will allow traffic that is run over HTTP without message encryption. Message level encryption is only possible when ``ansible_winrm_transport`` is ``ntlm``, ``kerberos`` or ``credssp``. By default this is ``false`` and should only be set to ``true`` when debugging WinRM messages." +msgstr "``Service\\AllowUnencrypted``: このオプションは、メッセージを暗号化せずに HTTP で実行するトラフィックを WinRM で許可するかどうかを定義します。メッセージレベルの暗号化は、``ansible_winrm_transport`` が ``ntlm``、``kerberos``、または ``credssp`` の場合にのみ可能です。デフォルトでは、これは ``false`` であり、WinRM メッセージをデバッグする場合に限り ``true`` に設定する必要があります。" + +#: ../../rst/user_guide/windows_setup.rst:293 +msgid "``Service\\Auth\\*``: These flags define what authentication options are allowed with the WinRM service. By default, ``Negotiate (NTLM)`` and ``Kerberos`` are enabled." +msgstr "``Service\\Auth\\*``: これらのフラグは、WinRM サービスで許可される認証オプションを定義します。デフォルトでは、``Negotiate (NTLM)`` および ``Kerberos`` が有効になります。" + +#: ../../rst/user_guide/windows_setup.rst:297 +msgid "``Service\\Auth\\CbtHardeningLevel``: Specifies whether channel binding tokens are not verified (None), verified but not required (Relaxed), or verified and required (Strict). CBT is only used when connecting with NTLM or Kerberos over HTTPS." +msgstr "``Service\\Auth\\CbtHardeningLevel``: チャンネルバインディングトークンを検証しない (None)、検証済みだが必要ない (Relaxed)、検証済みで必要 (Strict) のいずれかを指定します。CBT は、HTTPS の NTLM または Kerberos での接続時にのみ使用されます。" + +#: ../../rst/user_guide/windows_setup.rst:302 +msgid "``Service\\CertificateThumbprint``: This is the thumbprint of the certificate used to encrypt the TLS channel used with CredSSP authentication. By default this is empty; a self-signed certificate is generated when the WinRM service starts and is used in the TLS process." +msgstr "``Service\\CertificateThumbprint``: これは、CredSSP 認証で使用される TLS チャンネルの暗号化に使用される証明書のサムプリントです。デフォルトでは、これは空です。自己署名証明書は、WinRM サービスの起動時に生成され、TLS プロセスで使用されます。" + +#: ../../rst/user_guide/windows_setup.rst:307 +msgid "``Winrs\\MaxShellRunTime``: This is the maximum time, in milliseconds, that a remote command is allowed to execute." +msgstr "``Winrs\\MaxShellRunTime``: リモートコマンドの実行を許可する最大時間をミリ秒単位で指定します。" + +#: ../../rst/user_guide/windows_setup.rst:310 +msgid "``Winrs\\MaxMemoryPerShellMB``: This is the maximum amount of memory allocated per shell, including the shell's child processes." +msgstr "``Winrs\\MaxMemoryPerShellMB``: シェルの子プロセスを含め、シェルごとに割り当てられるメモリーの最大量です。" + +#: ../../rst/user_guide/windows_setup.rst:313 +msgid "To modify a setting under the ``Service`` key in PowerShell:" +msgstr "PowerShell の ``Service`` キーで設定を変更するには、以下を実行します。" + +#: ../../rst/user_guide/windows_setup.rst:323 +msgid "To modify a setting under the ``Winrs`` key in PowerShell:" +msgstr "PowerShell の ``Winrs`` キーで設定を変更するには、以下を実行します。" + +#: ../../rst/user_guide/windows_setup.rst:333 +msgid "If running in a domain environment, some of these options are set by GPO and cannot be changed on the host itself. When a key has been configured with GPO, it contains the text ``[Source=\"GPO\"]`` next to the value." +msgstr "ドメイン環境で動作している場合、これらのオプションの一部は GPO によって設定され、ホスト自体では変更できません。GPO で設定されたキーには、値の横に ``[Source=\"GPO\"]`` というテキストが表示されます。" + +#: ../../rst/user_guide/windows_setup.rst:338 +msgid "Common WinRM Issues" +msgstr "一般的な WinRM の問題" + +#: ../../rst/user_guide/windows_setup.rst:339 +msgid "Because WinRM has a wide range of configuration options, it can be difficult to setup and configure. Because of this complexity, issues that are shown by Ansible could in fact be issues with the host setup instead." +msgstr "WinRM にはさまざまな設定オプションがあるため、セットアップや設定が難しい場合があります。そのため、Ansible で表示される問題が、実際にはホストの設定の問題である可能性もあります。" + +#: ../../rst/user_guide/windows_setup.rst:343 +msgid "One easy way to determine whether a problem is a host issue is to run the following command from another Windows host to connect to the target Windows host:" +msgstr "問題がホストの問題であるかどうかを判断する簡単な方法として、別の Windows ホストから次のコマンドを実行して、対象の Windows ホストに接続する方法があります。" + +#: ../../rst/user_guide/windows_setup.rst:363 +msgid "If this fails, the issue is probably related to the WinRM setup. If it works, the issue may not be related to the WinRM setup; please continue reading for more troubleshooting suggestions." +msgstr "失敗した場合は、WinRM の設定に問題があると思われます。成功した場合は、問題が WinRM の設定に関連していない可能性があるため、さらに詳しいトラブルシューティングの方法をご確認ください。" + +#: ../../rst/user_guide/windows_setup.rst:366 +msgid "HTTP 401/Credentials Rejected" +msgstr "HTTP 401/認証情報の拒否" + +#: ../../rst/user_guide/windows_setup.rst:367 +msgid "A HTTP 401 error indicates the authentication process failed during the initial connection. Some things to check for this are:" +msgstr "HTTP 401 エラーは、最初の接続時に認証プロセスが失敗したことを示します。これを確認するためのいくつかの項目があります。" + +#: ../../rst/user_guide/windows_setup.rst:370 +msgid "Verify that the credentials are correct and set properly in your inventory with ``ansible_user`` and ``ansible_password``" +msgstr "``ansible_user`` および ``ansible_password`` を使用して、認証情報が正しく、インベントリーに適切に設定されていることを確認します。" + +#: ../../rst/user_guide/windows_setup.rst:373 +msgid "Ensure that the user is a member of the local Administrators group or has been explicitly granted access (a connection test with the ``winrs`` command can be used to rule this out)." +msgstr "ユーザーがローカルの Administrators グループのメンバーであるか、明示的にアクセスを許可されていることを確認してください (``winrs`` コマンドによる接続テストで除外できます)。" + +#: ../../rst/user_guide/windows_setup.rst:377 +msgid "Make sure that the authentication option set by ``ansible_winrm_transport`` is enabled under ``Service\\Auth\\*``" +msgstr "``ansible_winrm_transport`` で設定した認証オプションが、``Service\\Auth\\*`` で有効になっていることを確認してください。" + +#: ../../rst/user_guide/windows_setup.rst:380 +msgid "If running over HTTP and not HTTPS, use ``ntlm``, ``kerberos`` or ``credssp`` with ``ansible_winrm_message_encryption: auto`` to enable message encryption. If using another authentication option or if the installed pywinrm version cannot be upgraded, the ``Service\\AllowUnencrypted`` can be set to ``true`` but this is only recommended for troubleshooting" +msgstr "HTTPS ではなく HTTP で実行する場合は、``ntlm``、``kerberos``、または ``credssp`` と ``ansible_winrm_message_encryption: auto`` を使用してメッセージの暗号化を有効にしてください。他の認証オプションを使用している場合や、インストールされている pywinrm のバージョンをアップグレードできない場合は、``Service\\AllowUnencrypted`` を``true`` に設定できますが、これはトラブルシューティングのためにのみ推奨されます。" + +#: ../../rst/user_guide/windows_setup.rst:386 +msgid "Ensure the downstream packages ``pywinrm``, ``requests-ntlm``, ``requests-kerberos``, and/or ``requests-credssp`` are up to date using ``pip``." +msgstr "ダウンストリームパッケージである ``pywinrm``、``requests-ntlm``、``requests-kerberos``、または ``requests-credssp``、もしくはその組み合わせが ``pip`` を使用して最新の状態になっていることを確認します。" + +#: ../../rst/user_guide/windows_setup.rst:389 +msgid "If using Kerberos authentication, ensure that ``Service\\Auth\\CbtHardeningLevel`` is not set to ``Strict``." +msgstr "Kerberos 認証を使用する場合は、``Service\\Auth\\CbtHardeningLevel`` が ``Strict`` に設定されていないことを確認してください。" + +#: ../../rst/user_guide/windows_setup.rst:392 +msgid "When using Basic or Certificate authentication, make sure that the user is a local account and not a domain account. Domain accounts do not work with Basic and Certificate authentication." +msgstr "Basic 認証や Certificate 認証を使用する際は、ユーザーがドメインアカウントではなく、ローカルアカウントであることを確認してください。ドメインアカウントは、Basic 認証や Certificate 認証では機能しません。" + +#: ../../rst/user_guide/windows_setup.rst:397 +msgid "HTTP 500 Error" +msgstr "HTTP 500 Error" + +#: ../../rst/user_guide/windows_setup.rst:398 +msgid "These indicate an error has occurred with the WinRM service. Some things to check for include:" +msgstr "これらは、WinRM サービスでエラーが発生したことを示しています。確認すべき点は以下の通りです。" + +#: ../../rst/user_guide/windows_setup.rst:401 +msgid "Verify that the number of current open shells has not exceeded either ``WinRsMaxShellsPerUser`` or any of the other Winrs quotas haven't been exceeded." +msgstr "現在のオープンシェルの数が ``WinRsMaxShellsPerUser`` のどちらかを超えていないか、または他の Winrs のクォータを超えていないかを確認してください。" + +#: ../../rst/user_guide/windows_setup.rst:406 +msgid "Timeout Errors" +msgstr "タイムアウトエラー" + +#: ../../rst/user_guide/windows_setup.rst:407 +msgid "These usually indicate an error with the network connection where Ansible is unable to reach the host. Some things to check for include:" +msgstr "これらは通常、Ansible がホストに到達できないネットワーク接続のエラーを示しています。チェック項目には以下が含まれます。" + +#: ../../rst/user_guide/windows_setup.rst:410 +msgid "Make sure the firewall is not set to block the configured WinRM listener ports" +msgstr "ファイアウォールが、設定された WinRM リスナーポートをブロックするように設定されていないことを確認します。" + +#: ../../rst/user_guide/windows_setup.rst:411 +msgid "Ensure that a WinRM listener is enabled on the port and path set by the host vars" +msgstr "WinRM リスナーが、ホスト変数によって設定されたポートおよびパスで有効になっていることを確認します。" + +#: ../../rst/user_guide/windows_setup.rst:412 +msgid "Ensure that the ``winrm`` service is running on the Windows host and configured for automatic start" +msgstr "Windows ホスト上で ``winrm`` サービスが稼動しており、自動起動するように設定されていることを確認します。" + +#: ../../rst/user_guide/windows_setup.rst:416 +msgid "Connection Refused Errors" +msgstr "接続拒否エラー" + +#: ../../rst/user_guide/windows_setup.rst:417 +msgid "These usually indicate an error when trying to communicate with the WinRM service on the host. Some things to check for:" +msgstr "これらは通常、ホスト上の WinRM サービスと通信しようとする際にエラーを示します。いくつかのチェック項目があります。" + +#: ../../rst/user_guide/windows_setup.rst:420 +msgid "Ensure that the WinRM service is up and running on the host. Use ``(Get-Service -Name winrm).Status`` to get the status of the service." +msgstr "ホスト上で WinRM サービスが稼働していることを確認します。``(Get-Service -Name winrm).Status`` を使用して、サービスのステータスを取得します。" + +#: ../../rst/user_guide/windows_setup.rst:422 +msgid "Check that the host firewall is allowing traffic over the WinRM port. By default this is ``5985`` for HTTP and ``5986`` for HTTPS." +msgstr "ホスト側のファイアウォールが、WinRM ポートへのトラフィックを許可していることを確認します。デフォルトでは、HTTP では ``5985``、HTTPS では ``5986`` となっています。" + +#: ../../rst/user_guide/windows_setup.rst:425 +msgid "Sometimes an installer may restart the WinRM or HTTP service and cause this error. The best way to deal with this is to use ``win_psexec`` from another Windows host." +msgstr "インストーラーが WinRM や HTTP サービスを再起動してしまい、このエラーが発生することがあります。これに対処する最良の方法は、別の Windows ホストから ``win_psexec`` を使用します。" + +#: ../../rst/user_guide/windows_setup.rst:430 +msgid "Failure to Load Builtin Modules" +msgstr "組み込みモジュールの読み込みに失敗" + +#: ../../rst/user_guide/windows_setup.rst:431 +msgid "If powershell fails with an error message similar to ``The 'Out-String' command was found in the module 'Microsoft.PowerShell.Utility', but the module could not be loaded.`` then there could be a problem trying to access all the paths specified by the ``PSModulePath`` environment variable. A common cause of this issue is that the ``PSModulePath`` environment variable contains a UNC path to a file share and because of the double hop/credential delegation issue the Ansible process cannot access these folders. The way around this problems is to either:" +msgstr "``The 'Out-String' command was found in the module 'Microsoft.PowerShell.Utility', but the module could not be loaded.`` のようなエラーメッセージで powershell が失敗する場合は、``PSModulePath`` 環境変数で指定されたすべてのパスにアクセスしようとすると問題が発生する可能性があります。この問題の一般的な原因は、``PSModulePath`` 環境変数にファイル共有への UNC パスが含まれており、ダブルホップ/認証情報の委譲問題のために Ansible プロセスがこれらのディレクトリーにアクセスできないことです。この問題を回避するには、以下の方法があります。" + +#: ../../rst/user_guide/windows_setup.rst:437 +msgid "Remove the UNC path from the ``PSModulePath`` environment variable, or" +msgstr "``PSModulePath`` 環境変数から UNC パスを削除します。" + +#: ../../rst/user_guide/windows_setup.rst:438 +msgid "Use an authentication option that supports credential delegation like ``credssp`` or ``kerberos`` with credential delegation enabled" +msgstr "認証情報の委譲を有効にした ``credssp`` や ``kerberos`` のような、認証情報の委譲をサポートする認証オプションを使用します。" + +#: ../../rst/user_guide/windows_setup.rst:440 +msgid "See `KB4076842 <https://support.microsoft.com/en-us/help/4076842>`_ for more information on this problem." +msgstr "この問題の詳細は、「`KB4076842 <https://support.microsoft.com/en-us/help/4076842>`_」を参照してください。" + +#: ../../rst/user_guide/windows_setup.rst:443 +msgid "Windows SSH Setup" +msgstr "Windows SSH の設定" + +#: ../../rst/user_guide/windows_setup.rst:444 +msgid "Ansible 2.8 has added an experimental SSH connection for Windows managed nodes." +msgstr "Ansible 2.8 では、Windows 管理ノードの実験的な SSH 接続が追加されました。" + +#: ../../rst/user_guide/windows_setup.rst:447 +msgid "Use this feature at your own risk! Using SSH with Windows is experimental, the implementation may make backwards incompatible changes in feature releases. The server side components can be unreliable depending on the version that is installed." +msgstr "この機能はご自身の責任でお使いください。Windows での SSH の使用は実験的なものであり、実装は機能リリースにおいて後方互換性のない変更を行う可能性があります。また、サーバー側のコンポーネントは、インストールされているバージョンによっては信頼性に欠けることがあります。" + +#: ../../rst/user_guide/windows_setup.rst:453 +msgid "Installing OpenSSH using Windows Settings" +msgstr "Windows 設定を使用した OpenSSH のインストール" + +#: ../../rst/user_guide/windows_setup.rst:454 +msgid "OpenSSH can be used to connect Window 10 clients to Windows Server 2019. OpenSSH Client is available to install on Windows 10 build 1809 and later, while OpenSSH Server is available to install on Windows Server 2019 and later." +msgstr "OpenSSH は、WinkW 10 クライアントを Windows Server 2019 に接続するために使用できます。OpenSSH クライアントは Windows 10 ビルド 1809 以降にインストールできますが、OpenSSH Server は Windows Server 2019 以降に利用できます。" + +#: ../../rst/user_guide/windows_setup.rst:457 +msgid "Please refer `this guide <https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse>`_." +msgstr "`this guide <https://docs.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse>`_ を参照してください。" + +#: ../../rst/user_guide/windows_setup.rst:460 +msgid "Installing Win32-OpenSSH" +msgstr "Win32-OpenSSH のインストール" + +#: ../../rst/user_guide/windows_setup.rst:461 +msgid "The first step to using SSH with Windows is to install the `Win32-OpenSSH <https://github.com/PowerShell/Win32-OpenSSH>`_ service on the Windows host. Microsoft offers a way to install ``Win32-OpenSSH`` through a Windows capability but currently the version that is installed through this process is too old to work with Ansible. To install ``Win32-OpenSSH`` for use with Ansible, select one of these installation options:" +msgstr "Windows で SSH を利用するための最初のステップは、Windows ホストに `Win32-OpenSSH <https://github.com/PowerShell/Win32-OpenSSH>`_ サービスをインストールすることです。Microsoft 社では、Windows の機能を利用して ``Win32-OpenSSH`` をインストールする方法を提供していますが、現在、この方法でインストールされるバージョンは、Ansible で動作させるには古すぎます。Ansible で使用するために ``Win32-OpenSSH`` をインストールするには、以下のインストールオプションのいずれかを選択します。" + +#: ../../rst/user_guide/windows_setup.rst:467 +msgid "Manually install the service, following the `install instructions <https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH>`_ from Microsoft." +msgstr "Microsoft 社が提供する `インストール手順 <https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH>`_ に従って、サービスを手動でインストールしてください。" + +#: ../../rst/user_guide/windows_setup.rst:470 +msgid "Install the `openssh <https://chocolatey.org/packages/openssh>`_ package using Chocolatey:" +msgstr "Chocolatey を使用して `openssh <https://chocolatey.org/packages/openssh>`_ パッケージをインストールします。" + +#: ../../rst/user_guide/windows_setup.rst:476 +msgid "Use ``win_chocolatey`` to install the service" +msgstr "``win_chocolatey`` を使用してサービスをインストールします。" + +#: ../../rst/user_guide/windows_setup.rst:486 +msgid "Use an existing Ansible Galaxy role like `jborean93.win_openssh <https://galaxy.ansible.com/jborean93/win_openssh>`_:" +msgstr "`jborean93.win_openssh <https://galaxy.ansible.com/jborean93/win_openssh>`_ などの既存の Ansible Galaxy ロールを使用します。" + +#: ../../rst/user_guide/windows_setup.rst:503 +msgid "``Win32-OpenSSH`` is still a beta product and is constantly being updated to include new features and bugfixes. If you are using SSH as a connection option for Windows, it is highly recommend you install the latest release from one of the 3 methods above." +msgstr "``Win32-OpenSSH`` は未だベータ版の製品であり、新機能やバグ修正を含めて常に更新されています。Windows で SSH 接続をご利用の方は、上記 3 つの方法から最新版をインストールすることが強く推奨されます。" + +#: ../../rst/user_guide/windows_setup.rst:509 +msgid "Configuring the Win32-OpenSSH shell" +msgstr "Win32-OpenSSH シェルの設定" + +#: ../../rst/user_guide/windows_setup.rst:511 +msgid "By default ``Win32-OpenSSH`` will use ``cmd.exe`` as a shell. To configure a different shell, use an Ansible task to define the registry setting:" +msgstr "デフォルトでは、``Win32-OpenSSH`` は ``cmd.exe`` をシェルとして使用します。別のシェルを設定するには、Ansible タスクを使用して、レジストリー設定を定義します。" + +#: ../../rst/user_guide/windows_setup.rst:532 +msgid "Win32-OpenSSH Authentication" +msgstr "Win32-OpenSSH 認証" + +#: ../../rst/user_guide/windows_setup.rst:533 +msgid "Win32-OpenSSH authentication with Windows is similar to SSH authentication on Unix/Linux hosts. You can use a plaintext password or SSH public key authentication, add public keys to an ``authorized_key`` file in the ``.ssh`` folder of the user's profile directory, and configure the service using the ``sshd_config`` file used by the SSH service as you would on a Unix/Linux host." +msgstr "Windows での Win32-OpenSSH 認証は、Unix/Linux ホストでの SSH 認証に似ています。平文のパスワードまたは SSH 公開鍵認証を使用し、公開鍵をユーザーのプロファイルディレクトリーの ``.ssh`` ディレクトリーにある ``authorized_key`` ファイルに追加し、Unix/Linux ホストと同様に SSH サービスで使用される ``sshd_config`` ファイルを使用してサービスを設定することができます。" + +#: ../../rst/user_guide/windows_setup.rst:540 +msgid "When using SSH key authentication with Ansible, the remote session won't have access to the user's credentials and will fail when attempting to access a network resource. This is also known as the double-hop or credential delegation issue. There are two ways to work around this issue:" +msgstr "Ansible で SSH キー認証を使用する場合は、リモートセッションがユーザーの認証情報にアクセスできず、ネットワークリソースにアクセスしようとすると失敗することがあります。これは、ダブルホップや認証情報の委譲の問題としても知られています。この問題を回避するには 2 つの方法があります。" + +#: ../../rst/user_guide/windows_setup.rst:545 +msgid "Use plaintext password auth by setting ``ansible_password``" +msgstr "``ansible_password`` を設定して平文テキストのパスワード認証を使用する" + +#: ../../rst/user_guide/windows_setup.rst:546 +msgid "Use ``become`` on the task with the credentials of the user that needs access to the remote resource" +msgstr "リモートリソースへのアクセスを必要とするユーザーの認証情報を使用して、タスクで ``become`` を使用する" + +#: ../../rst/user_guide/windows_setup.rst:549 +msgid "Configuring Ansible for SSH on Windows" +msgstr "Windows で SSH 用に Ansible の設定" + +#: ../../rst/user_guide/windows_setup.rst:550 +msgid "To configure Ansible to use SSH for Windows hosts, you must set two connection variables:" +msgstr "Ansible が Windows ホストに SSH を使用するように設定するには、接続変数を 2 つ設定する必要があります。" + +#: ../../rst/user_guide/windows_setup.rst:552 +msgid "set ``ansible_connection`` to ``ssh``" +msgstr "``ansible_connection`` を ``ssh`` に設定します。" + +#: ../../rst/user_guide/windows_setup.rst:553 +msgid "set ``ansible_shell_type`` to ``cmd`` or ``powershell``" +msgstr "``ansible_shell_type`` を ``cmd`` または ``powershell`` に設定する" + +#: ../../rst/user_guide/windows_setup.rst:555 +msgid "The ``ansible_shell_type`` variable should reflect the ``DefaultShell`` configured on the Windows host. Set to ``cmd`` for the default shell or set to ``powershell`` if the ``DefaultShell`` has been changed to PowerShell." +msgstr "``ansible_shell_type`` 変数には、Windows ホストで設定されている``DefaultShell`` を反映させる必要があります。デフォルトシェルの場合は ``cmd`` に、``DefaultShell`` が PowerShell に変更している場合は ``powershell`` に設定します。" + +#: ../../rst/user_guide/windows_setup.rst:560 +msgid "Known issues with SSH on Windows" +msgstr "Windows での SSH に関する既知の問題" + +#: ../../rst/user_guide/windows_setup.rst:561 +msgid "Using SSH with Windows is experimental, and we expect to uncover more issues. Here are the known ones:" +msgstr "Windows での SSH の使用は実験的なものであり、より多くの問題が明らかになることを期待しています。ここでは、既知のものを紹介します。" + +#: ../../rst/user_guide/windows_setup.rst:564 +msgid "Win32-OpenSSH versions older than ``v7.9.0.0p1-Beta`` do not work when ``powershell`` is the shell type" +msgstr "``powershell`` がシェルタイプの場合は、``v7.9.0.0p1-Beta`` よりも古い Win32-OpenSSH バージョンは機能しません。" + +#: ../../rst/user_guide/windows_setup.rst:565 +msgid "While SCP should work, SFTP is the recommended SSH file transfer mechanism to use when copying or fetching a file" +msgstr "SCP も有効ですが、SFTP は、ファイルのコピーまたは取得時に使用する、推奨される SSH ファイル転送メカニズムです。" + +#: ../../rst/user_guide/windows_usage.rst:2 +msgid "Using Ansible and Windows" +msgstr "Ansible および Windows の使用" + +#: ../../rst/user_guide/windows_usage.rst:3 +msgid "When using Ansible to manage Windows, many of the syntax and rules that apply for Unix/Linux hosts also apply to Windows, but there are still some differences when it comes to components like path separators and OS-specific tasks. This document covers details specific to using Ansible for Windows." +msgstr "Ansible を使用して Windows を管理する場合は、Unix/Linux ホストに適用される構文やルールの多くが Windows にも適用されますが、パスセパレーターや OS 固有のタスクなどのコンポーネントに関しては、若干の違いがあります。このドキュメントでは、Ansible を Windows で使用する際の詳細情報を説明します。" + +#: ../../rst/user_guide/windows_usage.rst:12 +msgid "Use Cases" +msgstr "ユースケース" + +#: ../../rst/user_guide/windows_usage.rst:13 +msgid "Ansible can be used to orchestrate a multitude of tasks on Windows servers. Below are some examples and info about common tasks." +msgstr "Ansible は、Windows サーバーにある多数のタスクを調整するために使用できます。以下は、一般的なタスクに関する例と情報です。" + +#: ../../rst/user_guide/windows_usage.rst:17 +msgid "Installing Software" +msgstr "ソフトウェアのインストール" + +#: ../../rst/user_guide/windows_usage.rst:18 +msgid "There are three main ways that Ansible can be used to install software:" +msgstr "Ansible を使用してソフトウェアをインストールできる主な方法は 3 つあります。" + +#: ../../rst/user_guide/windows_usage.rst:20 +msgid "Using the ``win_chocolatey`` module. This sources the program data from the default public `Chocolatey <https://chocolatey.org/>`_ repository. Internal repositories can be used instead by setting the ``source`` option." +msgstr "``win_chocolatey`` モジュールを使用。このモジュールは、デフォルトのパブリックな `Chocolatey <https://chocolatey.org/>`_ リポジトリーからプログラムデータを調達します。``source`` オプションを設定することで、代わりに内部リポジトリーを使用することができます。" + +#: ../../rst/user_guide/windows_usage.rst:24 +msgid "Using the ``win_package`` module. This installs software using an MSI or .exe installer from a local/network path or URL." +msgstr "``win_package`` モジュールを使用します。これは、ローカル/ネットワークパスまたは URL から MSI または .exe インストーラーを使用してソフトウェアをインストールします。" + +#: ../../rst/user_guide/windows_usage.rst:27 +msgid "Using the ``win_command`` or ``win_shell`` module to run an installer manually." +msgstr "``win_command`` モジュールまたは ``win_shell`` モジュールを使用して手動でインストーラーを実行します。" + +#: ../../rst/user_guide/windows_usage.rst:29 +msgid "The ``win_chocolatey`` module is recommended since it has the most complete logic for checking to see if a package has already been installed and is up-to-date." +msgstr "``win_chocolatey`` モジュールは、パッケージがすでにインストールされていて最新かどうかを確認するための最も完全なロジックを備えているため、このモジュールを使用することが推奨されます。" + +#: ../../rst/user_guide/windows_usage.rst:31 +msgid "Below are some examples of using all three options to install 7-Zip:" +msgstr "以下は、3 つのすべてのオプションを使用して 7-Zip をインストールするいくつかの例です。" + +#: ../../rst/user_guide/windows_usage.rst:81 +msgid "Some installers like Microsoft Office or SQL Server require credential delegation or access to components restricted by WinRM. The best method to bypass these issues is to use ``become`` with the task. With ``become``, Ansible will run the installer as if it were run interactively on the host." +msgstr "Microsoft Office や SQL Server などの一部のインストーラーは、認証情報の委譲や WinRM で制限されたコンポーネントへのアクセスを必要とします。これらの問題を回避するための最良の方法は、タスクに ``become`` を使用することです。``become`` を使用すると、Ansible はあたかもホスト上で対話的に実行されているかのようにインストーラを実行します。" + +#: ../../rst/user_guide/windows_usage.rst:86 +msgid "Many installers do not properly pass back error information over WinRM. In these cases, if the install has been verified to work locally the recommended method is to use become." +msgstr "多くのインストーラーは、WinRM を介してエラー情報を適切に返しません。このような場合には、ローカルでの動作が確認されている場合には become を使用することが推奨されます。" + +#: ../../rst/user_guide/windows_usage.rst:88 +msgid "Some installers restart the WinRM or HTTP services, or cause them to become temporarily unavailable, making Ansible assume the system is unreachable." +msgstr "一部のインストーラーは、WinRM サービスまたは HTTP サービスを再起動したり、一時的に利用できなくなったりするため、システムが到達不能であると Ansible により想定されます。" + +#: ../../rst/user_guide/windows_usage.rst:91 +msgid "Installing Updates" +msgstr "更新のインストール" + +#: ../../rst/user_guide/windows_usage.rst:92 +msgid "The ``win_updates`` and ``win_hotfix`` modules can be used to install updates or hotfixes on a host. The module ``win_updates`` is used to install multiple updates by category, while ``win_hotfix`` can be used to install a single update or hotfix file that has been downloaded locally." +msgstr "``win_updates`` モジュールおよび ``win_hotfix`` モジュールを使用すると、ホストにアップデートや Hotfix をインストールできます。モジュール ``win_updates`` はカテゴリー別に複数のアップデートをインストールするために使用され、``win_hotfix`` はローカルにダウンロードした単一の更新または Hotfix ファイルをインストールするために使用されます。" + +#: ../../rst/user_guide/windows_usage.rst:97 +msgid "The ``win_hotfix`` module has a requirement that the DISM PowerShell cmdlets are present. These cmdlets were only added by default on Windows Server 2012 and newer and must be installed on older Windows hosts." +msgstr "``win_hotfix`` モジュールには、DISM PowerShell コマンドレットが存在するという要件があります。これらのコマンドレットは、Windows Server 2012 以降でのみデフォルトで追加されており、それ以前の Windows ホストではインストールする必要があります。" + +#: ../../rst/user_guide/windows_usage.rst:101 +msgid "The following example shows how ``win_updates`` can be used:" +msgstr "次の例は、``win_updates`` の使用方法を示しています。" + +#: ../../rst/user_guide/windows_usage.rst:117 +msgid "The following example show how ``win_hotfix`` can be used to install a single update or hotfix:" +msgstr "以下の例では、``win_hotfix`` を使用して単一のアップデートまたは Hotfix をインストールする方法を示しています。" + +#: ../../rst/user_guide/windows_usage.rst:139 +msgid "Set Up Users and Groups" +msgstr "ユーザーおよびグループの設定" + +#: ../../rst/user_guide/windows_usage.rst:140 +msgid "Ansible can be used to create Windows users and groups both locally and on a domain." +msgstr "Ansible を使用して、ローカルとドメインの両方で Windows ユーザーとグループを作成できます。" + +#: ../../rst/user_guide/windows_usage.rst:143 +msgid "Local" +msgstr "ローカル" + +#: ../../rst/user_guide/windows_usage.rst:144 +msgid "The modules ``win_user``, ``win_group`` and ``win_group_membership`` manage Windows users, groups and group memberships locally." +msgstr "``win_user`` モジュール、``win_group`` モジュール、および ``win_group_membership`` モジュールは、Windows のユーザー、グループ、およびグループのメンバーシップをローカルに管理します。" + +#: ../../rst/user_guide/windows_usage.rst:147 +msgid "The following is an example of creating local accounts and groups that can access a folder on the same host:" +msgstr "以下は、同じホストにあるディレクトリーにアクセスできるローカルアカウントおよびグループを作成する例を示します。" + +#: ../../rst/user_guide/windows_usage.rst:190 +msgid "Domain" +msgstr "ドメイン" + +#: ../../rst/user_guide/windows_usage.rst:191 +msgid "The modules ``win_domain_user`` and ``win_domain_group`` manages users and groups in a domain. The below is an example of ensuring a batch of domain users are created:" +msgstr "``win_domain_user`` モジュールおよび ``win_domain_group`` モジュールは、ドメインのユーザーおよびグループを管理します。以下は、ドメインユーザーのバッチを確実に作成する例です。" + +#: ../../rst/user_guide/windows_usage.rst:217 +msgid "Running Commands" +msgstr "コマンドの実行" + +#: ../../rst/user_guide/windows_usage.rst:218 +msgid "In cases where there is no appropriate module available for a task, a command or script can be run using the ``win_shell``, ``win_command``, ``raw``, and ``script`` modules." +msgstr "タスクに適したモジュールがない場合は、``win_shell`` モジュール、``win_command`` モジュール、``raw`` モジュール、および ``script`` モジュールを使用してコマンドやスクリプトを実行できます。" + +#: ../../rst/user_guide/windows_usage.rst:221 +msgid "The ``raw`` module simply executes a Powershell command remotely. Since ``raw`` has none of the wrappers that Ansible typically uses, ``become``, ``async`` and environment variables do not work." +msgstr "``raw`` モジュールは、Powershell コマンドをリモートで実行するだけです。``raw`` は、Ansible が通常使用するラッパーを一切使用していないため、``become``、``async``、および環境変数は動作しません。" + +#: ../../rst/user_guide/windows_usage.rst:225 +msgid "The ``script`` module executes a script from the Ansible controller on one or more Windows hosts. Like ``raw``, ``script`` currently does not support ``become``, ``async``, or environment variables." +msgstr "``script`` モジュールは、Ansible コントローラーからのスクリプトを 1 つまたは複数の Windows ホスト上で実行します。``raw`` と同様に、``script`` は現在、``become``、``async``、または環境変数をサポートしていません。" + +#: ../../rst/user_guide/windows_usage.rst:229 +msgid "The ``win_command`` module is used to execute a command which is either an executable or batch file, while the ``win_shell`` module is used to execute commands within a shell." +msgstr "``win_command`` モジュールは、実行ファイルまたはバッチファイルであるコマンドを実行するために使用され、``win_shell`` モジュールは、シェル内のコマンドを実行するために使用されます。" + +#: ../../rst/user_guide/windows_usage.rst:233 +msgid "Choosing Command or Shell" +msgstr "コマンドまたはシェルの選択" + +#: ../../rst/user_guide/windows_usage.rst:234 +msgid "The ``win_shell`` and ``win_command`` modules can both be used to execute a command or commands. The ``win_shell`` module is run within a shell-like process like ``PowerShell`` or ``cmd``, so it has access to shell operators like ``<``, ``>``, ``|``, ``;``, ``&&``, and ``||``. Multi-lined commands can also be run in ``win_shell``." +msgstr "``win_shell`` モジュールおよび ``win_command`` モジュールは、どちらもコマンドの実行に使用できます。``win_shell`` モジュールは ``PowerShell`` や ``cmd`` などのシェルのようななプロセス内で実行するため、``<``、``>``、``|``、``;``、``&&``、``||`` などのシェル演算子を使用できます。``win_shell`` では、複数行のコマンドも実行できます。" + +#: ../../rst/user_guide/windows_usage.rst:238 +msgid "The ``win_command`` module simply runs a process outside of a shell. It can still run a shell command like ``mkdir`` or ``New-Item`` by passing the shell commands to a shell executable like ``cmd.exe`` or ``PowerShell.exe``." +msgstr "``win_command`` モジュールは、シェルの外部でプロセスを実行するだけです。``cmd.exe`` や ``PowerShell.exe`` などのシェル実行ファイルに、``mkdir`` や ``New-Item`` などのシェルコマンドを渡してシェルコマンドを実行できます。" + +#: ../../rst/user_guide/windows_usage.rst:242 +msgid "Here are some examples of using ``win_command`` and ``win_shell``:" +msgstr "以下は、``win_command`` と ``win_shell`` を使用した例です。" + +#: ../../rst/user_guide/windows_usage.rst:270 +msgid "Some commands like ``mkdir``, ``del``, and ``copy`` only exist in the CMD shell. To run them with ``win_command`` they must be prefixed with ``cmd.exe /c``." +msgstr "``mkdir``、``del``、``copy`` などの一部のコマンドは、CMD シェルにのみ存在します。``win_command`` でそれらを実行するには、``cmd.exe /c`` プレフィックスを付ける必要があります。" + +#: ../../rst/user_guide/windows_usage.rst:275 +msgid "Argument Rules" +msgstr "引数のルール" + +#: ../../rst/user_guide/windows_usage.rst:276 +msgid "When running a command through ``win_command``, the standard Windows argument rules apply:" +msgstr "``win_command`` を通じてコマンドを実行する際には、Windows の標準的な引数ルールが適用されます。" + +#: ../../rst/user_guide/windows_usage.rst:279 +msgid "Each argument is delimited by a white space, which can either be a space or a tab." +msgstr "各引数は、空白またはタブのいずれかである空白で区切られます。" + +#: ../../rst/user_guide/windows_usage.rst:282 +msgid "An argument can be surrounded by double quotes ``\"``. Anything inside these quotes is interpreted as a single argument even if it contains whitespace." +msgstr "引数は二重引用符 ``\"`` で囲むことができます。これらの引用符の内側には、空白が含まれていても、1 つの引数として解釈されます。" + +#: ../../rst/user_guide/windows_usage.rst:285 +msgid "A double quote preceded by a backslash ``\\`` is interpreted as just a double quote ``\"`` and not as an argument delimiter." +msgstr "バックスラッシュ ``\\`` が前に付いた二重引用符は、引数区切り文字ではなく二重引用符 ``\"`` として解釈されます。" + +#: ../../rst/user_guide/windows_usage.rst:288 +msgid "Backslashes are interpreted literally unless it immediately precedes double quotes; for example ``\\`` == ``\\`` and ``\\\"`` == ``\"``" +msgstr "バックスラッシュは、二重引用符の直前にない限り、文字通りに解釈されます (例: ``\\`` ==``\\`` および ``\\\"`` == ``\"``)。" + +#: ../../rst/user_guide/windows_usage.rst:291 +msgid "If an even number of backslashes is followed by a double quote, one backslash is used in the argument for every pair, and the double quote is used as a string delimiter for the argument." +msgstr "偶数個のバックスラッシュの後に二重引用符が続く場合は、すべてのペアの引数で 1 つのバックスラッシュが使用され、二重引用符が引数の文字列区切り文字として使用されます。" + +#: ../../rst/user_guide/windows_usage.rst:295 +msgid "If an odd number of backslashes is followed by a double quote, one backslash is used in the argument for every pair, and the double quote is escaped and made a literal double quote in the argument." +msgstr "奇数個のバックスラッシュの後に二重引用符が続く場合、引数ではペアごとに 1 つのバックスラッシュが使用され、二重引用符はエスケープされて引数のリテラル二重引用符となります。" + +#: ../../rst/user_guide/windows_usage.rst:299 +msgid "With those rules in mind, here are some examples of quoting:" +msgstr "これらのルールを念頭に置いて、引用の例をいくつか示します。" + +#: ../../rst/user_guide/windows_usage.rst:324 +msgid "For more information, see `escaping arguments <https://msdn.microsoft.com/en-us/library/17w5ykft(v=vs.85).aspx>`_." +msgstr "詳細情報は、「`escaping arguments <https://msdn.microsoft.com/en-us/library/17w5ykft(v=vs.85).aspx>`_」を参照してください。" + +#: ../../rst/user_guide/windows_usage.rst:327 +msgid "Creating and Running a Scheduled Task" +msgstr "スケジュールされたタスクの作成および実行" + +#: ../../rst/user_guide/windows_usage.rst:328 +msgid "WinRM has some restrictions in place that cause errors when running certain commands. One way to bypass these restrictions is to run a command through a scheduled task. A scheduled task is a Windows component that provides the ability to run an executable on a schedule and under a different account." +msgstr "WinRM には、特定のコマンドを実行したときにエラーが発生するような制限が設けられています。これらの制限を回避する方法の 1 つとして、スケジュールされたタスクを使用してコマンドを実行する方法があります。スケジュールされたタスクとは、実行ファイルをスケジュールに沿って、別のアカウントで実行する機能を提供する Windows コンポーネントです。" + +#: ../../rst/user_guide/windows_usage.rst:333 +msgid "Ansible version 2.5 added modules that make it easier to work with scheduled tasks in Windows. The following is an example of running a script as a scheduled task that deletes itself after running:" +msgstr "Ansible バージョン 2.5 では、Windows でのスケジュールタスクの操作を容易にするモジュールが追加されました。以下は、実行後に自分自身を削除するスクリプトをスケジュールタスクとして実行する例です。" + +#: ../../rst/user_guide/windows_usage.rst:362 +msgid "The modules used in the above example were updated/added in Ansible version 2.5." +msgstr "上記の例で使用されているモジュールは、Ansible バージョン 2.5 で更新または追加されたものです。" + +#: ../../rst/user_guide/windows_usage.rst:366 +msgid "Path Formatting for Windows" +msgstr "Windows のパスのフォーマット" + +#: ../../rst/user_guide/windows_usage.rst:367 +msgid "Windows differs from a traditional POSIX operating system in many ways. One of the major changes is the shift from ``/`` as the path separator to ``\\``. This can cause major issues with how playbooks are written, since ``\\`` is often used as an escape character on POSIX systems." +msgstr "Windows は、従来の POSIX オペレーティングシステムとは多くの点で異なります。主な変更点のひとつは、パスの区切り文字が ``/`` から ``\\`` になったことです。POSIX システムでは、``\\`` がしばしばエスケープ文字として使用されるため、これは Playbook の記述方法に重大な問題を引き起こす可能性があります。" + +#: ../../rst/user_guide/windows_usage.rst:372 +msgid "Ansible allows two different styles of syntax; each deals with path separators for Windows differently:" +msgstr "Ansible では、2 つの異なるスタイルの構文を使用できます。それぞれ Windows のパスセパレーターの扱いが異なります。" + +#: ../../rst/user_guide/windows_usage.rst:375 +msgid "YAML Style" +msgstr "YAML スタイル" + +#: ../../rst/user_guide/windows_usage.rst:376 +msgid "When using the YAML syntax for tasks, the rules are well-defined by the YAML standard:" +msgstr "タスクに YAML 構文を使用する場合、そのルールは YAML 規格によって明確に定義されています。" + +#: ../../rst/user_guide/windows_usage.rst:379 +msgid "When using a normal string (without quotes), YAML will not consider the backslash an escape character." +msgstr "通常の文字列 (引用符なし) を使用する場合、YAML はバックスラッシュをエスケープ文字とはみなしません。" + +#: ../../rst/user_guide/windows_usage.rst:382 +msgid "When using single quotes ``'``, YAML will not consider the backslash an escape character." +msgstr "一重引用符 ``'`` を使用する場合、YAML はバックスラッシュをエスケープ文字とはみなしません。" + +#: ../../rst/user_guide/windows_usage.rst:385 +msgid "When using double quotes ``\"``, the backslash is considered an escape character and needs to escaped with another backslash." +msgstr "二重引用符 ``\"`` を使用する場合、バックスラッシュはエスケープ文字と見なされ、別のバックスラッシュでエスケープする必要があります。" + +#: ../../rst/user_guide/windows_usage.rst:388 +msgid "You should only quote strings when it is absolutely necessary or required by YAML, and then use single quotes." +msgstr "文字列を引用するのは、絶対に必要な場合や YAML で要求される場合のみとし、その場合は一重引用符を使用します。" + +#: ../../rst/user_guide/windows_usage.rst:391 +msgid "The YAML specification considers the following `escape sequences <https://yaml.org/spec/current.html#id2517668>`_:" +msgstr "YAML 仕様は、以下の `エスケープシーケンス <https://yaml.org/spec/current.html#id2517668>`_ を考慮します。" + +#: ../../rst/user_guide/windows_usage.rst:393 +msgid "``\\0``, ``\\\\``, ``\\\"``, ``\\_``, ``\\a``, ``\\b``, ``\\e``, ``\\f``, ``\\n``, ``\\r``, ``\\t``, ``\\v``, ``\\L``, ``\\N`` and ``\\P`` -- Single character escape" +msgstr "``\\0``、``\\\\``、``\\\"``、``\\_``、``\\a``、``\\b``、``\\e``、``\\f``、``\\n" +"``、``\\r``、``\\t``、``\\v``、``\\L``、``\\N``、および ``\\P`` -- 一文字のエスケープ" + +#: ../../rst/user_guide/windows_usage.rst:396 +msgid "``<TAB>``, ``<SPACE>``, ``<NBSP>``, ``<LNSP>``, ``<PSP>`` -- Special characters" +msgstr "``<TAB>``、``<SPACE>``、``<NBSP>``、``<LNSP>``、``<PSP>`` -- 特殊文字" + +#: ../../rst/user_guide/windows_usage.rst:399 +#: ../../rst/user_guide/windows_usage.rst:453 +msgid "``\\x..`` -- 2-digit hex escape" +msgstr "``\\x..`` -- 2 桁の 16 進エスケープ" + +#: ../../rst/user_guide/windows_usage.rst:401 +#: ../../rst/user_guide/windows_usage.rst:455 +msgid "``\\u....`` -- 4-digit hex escape" +msgstr "``\\u....`` -- 4 桁の 16 進エスケープ" + +#: ../../rst/user_guide/windows_usage.rst:403 +#: ../../rst/user_guide/windows_usage.rst:457 +msgid "``\\U........`` -- 8-digit hex escape" +msgstr "``\\U........`` -- 8 桁の 16 進エスケープ" + +#: ../../rst/user_guide/windows_usage.rst:405 +msgid "Here are some examples on how to write Windows paths:" +msgstr "Windows パスの記述方法の例を次に示します。" + +#: ../../rst/user_guide/windows_usage.rst:421 +msgid "This is an example which will fail:" +msgstr "これは失敗する例です。" + +#: ../../rst/user_guide/windows_usage.rst:428 +msgid "This example shows the use of single quotes when they are required:" +msgstr "この例は、必要な場合の一重引用符の使用を示しています。" + +#: ../../rst/user_guide/windows_usage.rst:439 +msgid "Legacy key=value Style" +msgstr "従来の key=value スタイル" + +#: ../../rst/user_guide/windows_usage.rst:440 +msgid "The legacy ``key=value`` syntax is used on the command line for ad hoc commands, or inside playbooks. The use of this style is discouraged within playbooks because backslash characters need to be escaped, making playbooks harder to read. The legacy syntax depends on the specific implementation in Ansible, and quoting (both single and double) does not have any effect on how it is parsed by Ansible." +msgstr "従来の ``key=value`` の構文は、コマンドラインでのアドホックなコマンドや Playbook 内で使用されます。バックスラッシュ文字をエスケープする必要があり、Playbook が読みづらくなるため、Playbook 内ではこのスタイルの使用は推奨されません。従来の構文は、Ansible の特定の実装に依存しており、引用符 (単一および二重) は、Ansible での解析方法には影響しません。" + +#: ../../rst/user_guide/windows_usage.rst:447 +msgid "The Ansible key=value parser parse_kv() considers the following escape sequences:" +msgstr "Ansible の key=value パーサー parse_kv() は、以下のエスケープシーケンスを考慮します。" + +#: ../../rst/user_guide/windows_usage.rst:450 +msgid "``\\``, ``'``, ``\"``, ``\\a``, ``\\b``, ``\\f``, ``\\n``, ``\\r``, ``\\t`` and ``\\v`` -- Single character escape" +msgstr "``\\``、``'``、``\"``、``\\a``、``\\b``、``\\f``、``\\n" +"``、``\\r``、``\\t``、および ``\\v`` -- 一文字のエスケープ" + +#: ../../rst/user_guide/windows_usage.rst:459 +msgid "``\\N{...}`` -- Unicode character by name" +msgstr "``\\N{...}`` -- 名前による Unicode 文字" + +#: ../../rst/user_guide/windows_usage.rst:461 +msgid "This means that the backslash is an escape character for some sequences, and it is usually safer to escape a backslash when in this form." +msgstr "これは、バックスラッシュがいくつかのシーケンスのエスケープ文字になっていることを意味しており、通常、この形式の場合はバックスラッシュをエスケープする方が安全です。" + +#: ../../rst/user_guide/windows_usage.rst:464 +msgid "Here are some examples of using Windows paths with the key=value style:" +msgstr "key=value スタイルで Windows パスを使用する例を次に示します。" + +#: ../../rst/user_guide/windows_usage.rst:486 +msgid "The failing examples don't fail outright but will substitute ``\\t`` with the ``<TAB>`` character resulting in ``tempdir`` being ``C:\\Windows<TAB>emp``." +msgstr "失敗した例では、完全に失敗するわけではありませんが、``\\t`` を ``<TAB>`` の文字で置き換えて、``tempdir`` を ``C:\\Windows<TAB>emp`` にします。" + +#: ../../rst/user_guide/windows_usage.rst:491 +msgid "Some things you cannot do with Ansible and Windows are:" +msgstr "ここでは、Ansible および Windows でできないことを説明します。" + +#: ../../rst/user_guide/windows_usage.rst:493 +msgid "Upgrade PowerShell" +msgstr "PowerShell のアップグレード" + +#: ../../rst/user_guide/windows_usage.rst:495 +msgid "Interact with the WinRM listeners" +msgstr "WinRM リスナーとの対話" + +#: ../../rst/user_guide/windows_usage.rst:497 +msgid "Because WinRM is reliant on the services being online and running during normal operations, you cannot upgrade PowerShell or interact with WinRM listeners with Ansible. Both of these actions will cause the connection to fail. This can technically be avoided by using ``async`` or a scheduled task, but those methods are fragile if the process it runs breaks the underlying connection Ansible uses, and are best left to the bootstrapping process or before an image is created." +msgstr "WinRM は、通常の運用時にサービスがオンラインで稼働していることに依存しているため、PowerShell をアップグレードしたり、Ansible で WinRM リスナーと対話したりすることはできません。これらのアクションはいずれも、接続の失敗を引き起こします。これは、技術的には ``async`` やスケジュールされたタスクを使用することで回避できますが、これらの方法は、実行するプロセスによって Ansible が使用する基礎的な接続が壊れると脆弱になるため、ブートストラッププロセスやイメージが作成される前に任せるのが最適です。" + +#: ../../rst/user_guide/windows_usage.rst:501 +msgid "Developing Windows Modules" +msgstr "Windows モジュールの開発" + +#: ../../rst/user_guide/windows_usage.rst:502 +msgid "Because Ansible modules for Windows are written in PowerShell, the development guides for Windows modules differ substantially from those for standard standard modules. Please see :ref:`developing_modules_general_windows` for more information." +msgstr "Windows 用の Ansible モジュールは PowerShell で書かれているため、Windows モジュールの開発ガイドは標準規格のモジュールの開発ガイドとは大きく異なります。詳細は、「:ref:`developing_modules_general_windows`」を参照してください。" + +#: ../../rst/user_guide/windows_winrm.rst:4 +msgid "Windows Remote Management" +msgstr "Windows リモート管理" + +#: ../../rst/user_guide/windows_winrm.rst:5 +msgid "Unlike Linux/Unix hosts, which use SSH by default, Windows hosts are configured with WinRM. This topic covers how to configure and use WinRM with Ansible." +msgstr "デフォルトで SSH を使用する Linux/Unix ホストとは異なり、Windows ホストは WinRM で設定されています。このトピックでは、Ansible で WinRM を設定し、使用する方法を説明します。" + +#: ../../rst/user_guide/windows_winrm.rst:14 +msgid "What is WinRM?" +msgstr "WinRM とは" + +#: ../../rst/user_guide/windows_winrm.rst:16 +msgid "WinRM is a management protocol used by Windows to remotely communicate with another server. It is a SOAP-based protocol that communicates over HTTP/HTTPS, and is included in all recent Windows operating systems. Since Windows Server 2012, WinRM has been enabled by default, but in most cases extra configuration is required to use WinRM with Ansible." +msgstr "WinRM は、Windows が別のサーバーとリモートで通信する際に使用する管理プロトコルです。WinRM は、HTTP/HTTPS で通信する SOAP ベースのプロトコルで、最近のすべての Windows OS に搭載されています。Windows Server 2012 以降、WinRM はデフォルトで有効になっていますが、ほとんどの場合は、Ansible で WinRM を使用するには追加の設定が必要です。" + +#: ../../rst/user_guide/windows_winrm.rst:22 +msgid "Ansible uses the `pywinrm <https://github.com/diyan/pywinrm>`_ package to communicate with Windows servers over WinRM. It is not installed by default with the Ansible package, but can be installed by running the following:" +msgstr "Ansible は `pywinrm <https://github.com/diyan/pywinrm>`_ パッケージを使用して、WinRM を介して Windows サーバーと通信します。デフォルトでは Ansible パッケージとともにインストールされませんが、以下を実行することでインストールできます。" + +#: ../../rst/user_guide/windows_winrm.rst:30 +msgid "on distributions with multiple python versions, use pip2 or pip2.x, where x matches the python minor version Ansible is running under." +msgstr "複数の python バージョンがあるディストリビューションでは、pip2 または pip2.x を使用します。x は、Ansible を実行している python マイナーバージョンと一致します。" + +#: ../../rst/user_guide/windows_winrm.rst:34 +msgid "Using the ``winrm`` or ``psrp`` connection plugins in Ansible on MacOS in the latest releases typically fail. This is a known problem that occurs deep within the Python stack and cannot be changed by Ansible. The only workaround today is to set the environment variable ``no_proxy=*`` and avoid using Kerberos auth." +msgstr "最新リリースの MacOS 上の Ansible で、connection プラグイン ``winrm`` または ``psrp`` を使用すると、通常は失敗します。これは、Python スタックの奥深くで発生する既知の問題であり、Ansible では変更できません。現在の唯一の回避策は、環境変数 ``no_proxy=*`` を設定し、Kerberos 認証を使用しないようにしてください。" + +#: ../../rst/user_guide/windows_winrm.rst:44 +msgid "WinRM authentication options" +msgstr "WinRM 認証オプション" + +#: ../../rst/user_guide/windows_winrm.rst:46 +msgid "When connecting to a Windows host, there are several different options that can be used when authenticating with an account. The authentication type may be set on inventory hosts or groups with the ``ansible_winrm_transport`` variable." +msgstr "Windows ホストに接続する際、アカウントで認証する際に使用できるいくつかの異なるオプションがあります。認証タイプは、インベントリーのホストまたはグループに ``ansible_winrm_transport`` 変数で設定できます。" + +#: ../../rst/user_guide/windows_winrm.rst:50 +msgid "The following matrix is a high level overview of the options:" +msgstr "以下のマトリックスは、オプションの概要を示しています。" + +#: ../../rst/user_guide/windows_winrm.rst:53 +msgid "Option" +msgstr "オプション" + +#: ../../rst/user_guide/windows_winrm.rst:53 +msgid "Local Accounts" +msgstr "ローカルアカウント" + +#: ../../rst/user_guide/windows_winrm.rst:53 +msgid "Active Directory Accounts" +msgstr "Active Directory アカウント" + +#: ../../rst/user_guide/windows_winrm.rst:53 +msgid "Credential Delegation" +msgstr "認証情報の委譲" + +#: ../../rst/user_guide/windows_winrm.rst:53 +msgid "HTTP Encryption" +msgstr "HTTP 暗号化" + +#: ../../rst/user_guide/windows_winrm.rst:55 +#: ../../rst/user_guide/windows_winrm.rst:69 +msgid "Basic" +msgstr "基本" + +#: ../../rst/user_guide/windows_winrm.rst:55 +#: ../../rst/user_guide/windows_winrm.rst:57 +#: ../../rst/user_guide/windows_winrm.rst:59 +#: ../../rst/user_guide/windows_winrm.rst:61 +#: ../../rst/user_guide/windows_winrm.rst:63 +msgid "Yes" +msgstr "可" + +#: ../../rst/user_guide/windows_winrm.rst:55 +#: ../../rst/user_guide/windows_winrm.rst:57 +#: ../../rst/user_guide/windows_winrm.rst:59 +#: ../../rst/user_guide/windows_winrm.rst:61 +msgid "No" +msgstr "不可" + +#: ../../rst/user_guide/windows_winrm.rst:57 +#: ../../rst/user_guide/windows_winrm.rst:96 +msgid "Certificate" +msgstr "証明書" + +#: ../../rst/user_guide/windows_winrm.rst:59 +#: ../../rst/user_guide/windows_winrm.rst:300 +msgid "Kerberos" +msgstr "Kerberos" + +#: ../../rst/user_guide/windows_winrm.rst:61 +#: ../../rst/user_guide/windows_winrm.rst:270 +msgid "NTLM" +msgstr "NTLM" + +#: ../../rst/user_guide/windows_winrm.rst:63 +#: ../../rst/user_guide/windows_winrm.rst:513 +msgid "CredSSP" +msgstr "CredSSP" + +#: ../../rst/user_guide/windows_winrm.rst:71 +msgid "Basic authentication is one of the simplest authentication options to use, but is also the most insecure. This is because the username and password are simply base64 encoded, and if a secure channel is not in use (eg, HTTPS) then it can be decoded by anyone. Basic authentication can only be used for local accounts (not domain accounts)." +msgstr "Basic 認証は、最もシンプルな認証方法の 1 つですが、安全性が最も低くなります。これは、ユーザー名およびパスワードが単純に Base64 エンコードされているためで、安全なチャンネル (例: HTTPS) が使用されていない場合は、誰でも解読することができます。Basic 認証は、ローカルアカウントにのみ使用することができます (ドメインアカウントには使用できません)。" + +#: ../../rst/user_guide/windows_winrm.rst:76 +msgid "The following example shows host vars configured for basic authentication:" +msgstr "以下の例は、基本認証に設定されているホスト変数を示しています。" + +#: ../../rst/user_guide/windows_winrm.rst:85 +msgid "Basic authentication is not enabled by default on a Windows host but can be enabled by running the following in PowerShell:" +msgstr "Basic 認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" + +#: ../../rst/user_guide/windows_winrm.rst:98 +msgid "Certificate authentication uses certificates as keys similar to SSH key pairs, but the file format and key generation process is different." +msgstr "証明書認証は、SSH キーペアに似た鍵として証明書を使用しますが、ファイル形式と鍵の生成プロセスは異なります。" + +#: ../../rst/user_guide/windows_winrm.rst:101 +msgid "The following example shows host vars configured for certificate authentication:" +msgstr "以下の例では、証明書認証に設定されているホスト変数を示しています。" + +#: ../../rst/user_guide/windows_winrm.rst:110 +msgid "Certificate authentication is not enabled by default on a Windows host but can be enabled by running the following in PowerShell:" +msgstr "証明書認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" + +#: ../../rst/user_guide/windows_winrm.rst:117 +msgid "Encrypted private keys cannot be used as the urllib3 library that is used by Ansible for WinRM does not support this functionality." +msgstr "WinRM 向けに Ansible が使用する urllib3 ライブラリーがこの機能をサポートしていないため、暗号化された秘密鍵は使用できません。" + +#: ../../rst/user_guide/windows_winrm.rst:120 +msgid ".._winrm_certificate_generate:" +msgstr ".._winrm_certificate_generate:" + +#: ../../rst/user_guide/windows_winrm.rst:123 +msgid "Generate a Certificate" +msgstr "証明書の生成" + +#: ../../rst/user_guide/windows_winrm.rst:125 +msgid "A certificate must be generated before it can be mapped to a local user. This can be done using one of the following methods:" +msgstr "証明書をローカルユーザーにマッピングする前に、証明書を生成する必要があります。これは、以下のいずれかの方法で行うことができます。" + +#: ../../rst/user_guide/windows_winrm.rst:128 +msgid "OpenSSL" +msgstr "OpenSSL" + +#: ../../rst/user_guide/windows_winrm.rst:129 +msgid "PowerShell, using the ``New-SelfSignedCertificate`` cmdlet" +msgstr "``New-SelfSignedCertificate`` コマンドレットを使用した PowerShell" + +#: ../../rst/user_guide/windows_winrm.rst:130 +msgid "Active Directory Certificate Services" +msgstr "Active Directory 証明書サービス" + +#: ../../rst/user_guide/windows_winrm.rst:132 +msgid "Active Directory Certificate Services is beyond of scope in this documentation but may be the best option to use when running in a domain environment. For more information, see the `Active Directory Certificate Services documentation <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732625(v=ws.11)>`_." +msgstr "Active Directory Certificate Services は、このドキュメントでは対象外になりますが、ドメイン環境で実行する場合には、最適なオプションになるかもしれません。詳細は、`Active Directory Certificate Services のドキュメント <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc732625(v=ws.11)>`_ を参照してください。" + +#: ../../rst/user_guide/windows_winrm.rst:136 +msgid "Using the PowerShell cmdlet ``New-SelfSignedCertificate`` to generate a certificate for authentication only works when being generated from a Windows 10 or Windows Server 2012 R2 host or later. OpenSSL is still required to extract the private key from the PFX certificate to a PEM file for Ansible to use." +msgstr "PowerShell コマンドレット (``New-SelfSignedCertificate``) を使用して認証用の証明書を生成する場合は、Windows 10 または Windows Server 2012 R2 ホスト以降から生成された場合にのみ機能します。PFX 証明書から Ansible が使用する PEM ファイルに秘密鍵を抽出するには、OpenSSL が引き続き必要となります。" + +#: ../../rst/user_guide/windows_winrm.rst:142 +msgid "To generate a certificate with ``OpenSSL``:" +msgstr "``OpenSSL`` で証明書を生成するには、以下を実行します。" + +#: ../../rst/user_guide/windows_winrm.rst:162 +msgid "To generate a certificate with ``New-SelfSignedCertificate``:" +msgstr "``New-SelfSignedCertificate`` で証明書を生成するには、以下を実行します。" + +#: ../../rst/user_guide/windows_winrm.rst:190 +msgid "To convert the PFX file to a private key that pywinrm can use, run the following command with OpenSSL ``openssl pkcs12 -in cert.pfx -nocerts -nodes -out cert_key.pem -passin pass: -passout pass:``" +msgstr "PFX ファイルを pywinrm が使用できる秘密鍵に変換するには、OpenSSL で ``openssl pkcs12 -in cert.pfx -nocerts -nodes -out cert_key.pem -passin pass: -passout pass:`` コマンドを実行します。" + +#: ../../rst/user_guide/windows_winrm.rst:197 +msgid "Import a Certificate to the Certificate Store" +msgstr "証明書ストアへの証明書のインポート" + +#: ../../rst/user_guide/windows_winrm.rst:199 +msgid "Once a certificate has been generated, the issuing certificate needs to be imported into the ``Trusted Root Certificate Authorities`` of the ``LocalMachine`` store, and the client certificate public key must be present in the ``Trusted People`` folder of the ``LocalMachine`` store. For this example, both the issuing certificate and public key are the same." +msgstr "証明書が生成されたら、発行した証明書を ``LocalMachine`` ストアの ``Trusted Root Certificate Authorities`` にインポートし、クライアント証明書の公開鍵を ``LocalMachine`` ストアの ``Trusted People`` ディレクトリーに存在させる必要があります。この例では、発行した証明書と公開鍵の両方が同じものです。" + +#: ../../rst/user_guide/windows_winrm.rst:205 +msgid "Following example shows how to import the issuing certificate:" +msgstr "以下の例では、発行した証明書をインポートする方法を示します。" + +#: ../../rst/user_guide/windows_winrm.rst:219 +msgid "If using ADCS to generate the certificate, then the issuing certificate will already be imported and this step can be skipped." +msgstr "ADCS を使用して証明書を生成する場合は、発行する証明書がすでにインポートされているため、この手順は省略できます。" + +#: ../../rst/user_guide/windows_winrm.rst:222 +msgid "The code to import the client certificate public key is:" +msgstr "クライアント証明書の公開鍵をインポートするコードは以下のとおりです。" + +#: ../../rst/user_guide/windows_winrm.rst:239 +msgid "Mapping a Certificate to an Account" +msgstr "証明書のアカウントへのマッピング" + +#: ../../rst/user_guide/windows_winrm.rst:241 +msgid "Once the certificate has been imported, map it to the local user account:" +msgstr "証明書をインポートしたら、これをローカルユーザーアカウントにマッピングします。" + +#: ../../rst/user_guide/windows_winrm.rst:262 +msgid "Once this is complete, the hostvar ``ansible_winrm_cert_pem`` should be set to the path of the public key and the ``ansible_winrm_cert_key_pem`` variable should be set to the path of the private key." +msgstr "これが完了したら、ホスト変数 ``ansible_winrm_cert_pem`` に公開鍵のパスを設定し、変数``ansible_winrm_cert_key_pem`` に秘密鍵のパスを設定してください。" + +#: ../../rst/user_guide/windows_winrm.rst:272 +msgid "NTLM is an older authentication mechanism used by Microsoft that can support both local and domain accounts. NTLM is enabled by default on the WinRM service, so no setup is required before using it." +msgstr "NTLM は、Microsoft が使用している古い認証メカニズムで、ローカルアカウントとドメインアカウントの両方をサポートしています。NTLM は、WinRM サービスでデフォルトで有効になっているため、使用する前に設定する必要はありません。" + +#: ../../rst/user_guide/windows_winrm.rst:276 +msgid "NTLM is the easiest authentication protocol to use and is more secure than ``Basic`` authentication. If running in a domain environment, ``Kerberos`` should be used instead of NTLM." +msgstr "NTLM は最も簡単に使用できる認証プロトコルであり、``Basic`` 認証よりも安全です。ドメイン環境で稼働している場合は、NTLM の代わりに ``Kerberos`` を使用する必要があります。" + +#: ../../rst/user_guide/windows_winrm.rst:280 +msgid "Kerberos has several advantages over using NTLM:" +msgstr "Kerberos は NTLM の使用と比較して、以下のような利点があります。" + +#: ../../rst/user_guide/windows_winrm.rst:282 +msgid "NTLM is an older protocol and does not support newer encryption protocols." +msgstr "NTLM は古いプロトコルであり、新しい暗号化プロトコルをサポートしません。" + +#: ../../rst/user_guide/windows_winrm.rst:284 +msgid "NTLM is slower to authenticate because it requires more round trips to the host in the authentication stage." +msgstr "NTLM は、認証の段階でホストへのラウンドトリップが多くなるため、認証に時間がかかります。" + +#: ../../rst/user_guide/windows_winrm.rst:286 +msgid "Unlike Kerberos, NTLM does not allow credential delegation." +msgstr "Kerberos とは異なり、NTLM は認証情報の委譲を許可していません。" + +#: ../../rst/user_guide/windows_winrm.rst:288 +msgid "This example shows host variables configured to use NTLM authentication:" +msgstr "以下の例では、NTLM 認証を使用するように設定されているホスト変数を示しています。" + +#: ../../rst/user_guide/windows_winrm.rst:302 +msgid "Kerberos is the recommended authentication option to use when running in a domain environment. Kerberos supports features like credential delegation and message encryption over HTTP and is one of the more secure options that is available through WinRM." +msgstr "Kerberos は、ドメイン環境で実行する場合に使用する推奨の認証オプションです。Kerberos は、認証情報の委譲や HTTP でのメッセージ暗号化などの機能をサポートしており、WinRM で利用できるより安全なオプションの 1 つです。" + +#: ../../rst/user_guide/windows_winrm.rst:307 +msgid "Kerberos requires some additional setup work on the Ansible host before it can be used properly." +msgstr "Kerberos を正しく使用するには、Ansible ホスト上でいくつかの追加設定作業が必要です。" + +#: ../../rst/user_guide/windows_winrm.rst:310 +msgid "The following example shows host vars configured for Kerberos authentication:" +msgstr "以下の例は、Kerberos 認証に設定されたホスト変数を示しています。" + +#: ../../rst/user_guide/windows_winrm.rst:320 +msgid "As of Ansible version 2.3, the Kerberos ticket will be created based on ``ansible_user`` and ``ansible_password``. If running on an older version of Ansible or when ``ansible_winrm_kinit_mode`` is ``manual``, a Kerberos ticket must already be obtained. See below for more details." +msgstr "Ansible バージョン 2.3 以降では、``ansible_user`` と ``ansible_password`` に基づいて Kerberos チケットが作成されます。古いバージョンの Ansible で実行している場合や、``ansible_winrm_kinit_mode`` が ``manual`` の場合は、すでに Kerberos チケットを取得している必要があります。詳細は以下を参照してください。" + +#: ../../rst/user_guide/windows_winrm.rst:325 +msgid "There are some extra host variables that can be set:" +msgstr "設定可能な追加のホスト変数があります。" + +#: ../../rst/user_guide/windows_winrm.rst:338 +msgid "Installing the Kerberos Library" +msgstr "Kerberos ライブラリーのインストール" + +#: ../../rst/user_guide/windows_winrm.rst:340 +msgid "Some system dependencies that must be installed prior to using Kerberos. The script below lists the dependencies based on the distro:" +msgstr "Kerberos を使用する前にインストールする必要があるシステム依存関係があります。以下のスクリプトは、ディストリビューションに基づく依存関係を一覧表示します。" + +#: ../../rst/user_guide/windows_winrm.rst:369 +msgid "Once the dependencies have been installed, the ``python-kerberos`` wrapper can be install using ``pip``:" +msgstr "依存関係がインストールされたら、``pip`` を使用して ``python-kerberos`` ラッパーをインストールできます。" + +#: ../../rst/user_guide/windows_winrm.rst:378 +msgid "While Ansible has supported Kerberos auth through ``pywinrm`` for some time, optional features or more secure options may only be available in newer versions of the ``pywinrm`` and/or ``pykerberos`` libraries. It is recommended you upgrade each version to the latest available to resolve any warnings or errors. This can be done through tools like ``pip`` or a system package manager like ``dnf``, ``yum``, ``apt`` but the package names and versions available may differ between tools." +msgstr "Ansible はこれまで、``pywinrm`` を通じて Kerberos 認証をサポートしてきましたが、オプション機能やより安全なオプションは、``pywinrm`` ライブラリーまたは ``pykerberos`` ライブラリーの新しいバージョンでのみ利用できる場合があります。警告やエラーが発生した場合は、各バージョンを最新のものにアップグレードすることが推奨されます。この作業は、``pip`` のようなツールや、``dnf``、``yum``、``apt`` のようなシステムパッケージマネージャーで行うことができますが、パッケージ名や利用可能なバージョンはツールによって異なる場合があります。" + +#: ../../rst/user_guide/windows_winrm.rst:390 +msgid "Configuring Host Kerberos" +msgstr "ホスト Kerberos の設定" + +#: ../../rst/user_guide/windows_winrm.rst:392 +msgid "Once the dependencies have been installed, Kerberos needs to be configured so that it can communicate with a domain. This configuration is done through the ``/etc/krb5.conf`` file, which is installed with the packages in the script above." +msgstr "依存関係がインストールされたら、Kerberos がドメインと通信できるように設定する必要があります。この設定は、上のスクリプトでパッケージと一緒にインストールされた ``/etc/krb5.conf`` ファイルを通じて行われます。" + +#: ../../rst/user_guide/windows_winrm.rst:396 +msgid "To configure Kerberos, in the section that starts with:" +msgstr "Kerberos を設定するには、以下で始まるセクションで行います。" + +#: ../../rst/user_guide/windows_winrm.rst:402 +msgid "Add the full domain name and the fully qualified domain names of the primary and secondary Active Directory domain controllers. It should look something like this:" +msgstr "プライマリーおよびセカンダリーの Active Directory ドメインコントローラーの完全ドメイン名および完全修飾ドメイン名を追加します。以下のようになるはずです。" + +#: ../../rst/user_guide/windows_winrm.rst:414 +msgid "In the section that starts with:" +msgstr "以下で始まるセクションで、" + +#: ../../rst/user_guide/windows_winrm.rst:420 +msgid "Add a line like the following for each domain that Ansible needs access for:" +msgstr "Ansible がアクセスする必要のある各ドメインに以下のような行を追加します。" + +#: ../../rst/user_guide/windows_winrm.rst:427 +msgid "You can configure other settings in this file such as the default domain. See `krb5.conf <https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html>`_ for more details." +msgstr "このファイルでは、デフォルトのドメインなど、その他の設定を行うことができます。詳細は `krb5.conf <https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html>`_ を参照してください。" + +#: ../../rst/user_guide/windows_winrm.rst:434 +msgid "Automatic Kerberos Ticket Management" +msgstr "Kerberos チケットの自動管理" + +#: ../../rst/user_guide/windows_winrm.rst:436 +msgid "Ansible version 2.3 and later defaults to automatically managing Kerberos tickets when both ``ansible_user`` and ``ansible_password`` are specified for a host. In this process, a new ticket is created in a temporary credential cache for each host. This is done before each task executes to minimize the chance of ticket expiration. The temporary credential caches are deleted after each task completes and will not interfere with the default credential cache." +msgstr "Ansible バージョン 2.3 以降では、ホストに ``ansible_user`` および ``ansible_password`` の両方が指定された場合は、デフォルトで Kerberos チケットを自動的に管理します。このプロセスでは、各ホストの一時的な認証情報キャッシュに新しいチケットが作成されます。これは、チケットが失効する可能性を最小限にするために、各タスクが実行される前に行われます。一時的な認証情報キャッシュは、各タスクが完了すると削除され、デフォルトの認証情報キャッシュに干渉することはありません。" + +#: ../../rst/user_guide/windows_winrm.rst:443 +msgid "To disable automatic ticket management, set ``ansible_winrm_kinit_mode=manual`` via the inventory." +msgstr "チケットの自動管理を無効にするには、インベントリーから ``ansible_winrm_kinit_mode=manual`` を設定してください。" + +#: ../../rst/user_guide/windows_winrm.rst:446 +msgid "Automatic ticket management requires a standard ``kinit`` binary on the control host system path. To specify a different location or binary name, set the ``ansible_winrm_kinit_cmd`` hostvar to the fully qualified path to a MIT krbv5 ``kinit``-compatible binary." +msgstr "自動チケット管理には、制御ホストシステムのパスに標準の ``kinit`` バイナリーが必要です。別の場所やバイナリー名を指定するには、ホスト変数 ``ansible_winrm_kinit_cmd`` に MIT krbv5 ``kinit`` 互換バイナリーへの完全修飾パスを設定します。" + +#: ../../rst/user_guide/windows_winrm.rst:454 +msgid "Manual Kerberos Ticket Management" +msgstr "Kerberos チケットの手動管理" + +#: ../../rst/user_guide/windows_winrm.rst:456 +msgid "To manually manage Kerberos tickets, the ``kinit`` binary is used. To obtain a new ticket the following command is used:" +msgstr "Kerberos チケットを手動で管理するには、``kinit`` バイナリーを使用します。新しいチケットを取得するには、以下のコマンドを使用します。" + +#: ../../rst/user_guide/windows_winrm.rst:463 +msgid "The domain must match the configured Kerberos realm exactly, and must be in upper case." +msgstr "ドメインは設定された Kerberos レルムに完全に一致し、大文字である必要があります。" + +#: ../../rst/user_guide/windows_winrm.rst:465 +msgid "To see what tickets (if any) have been acquired, use the following command:" +msgstr "取得したチケット (存在する場合) を確認するには、以下のコマンドを使用します。" + +#: ../../rst/user_guide/windows_winrm.rst:471 +msgid "To destroy all the tickets that have been acquired, use the following command:" +msgstr "取得したすべてのチケットを破棄するには、以下のコマンドを使用します。" + +#: ../../rst/user_guide/windows_winrm.rst:480 +msgid "Troubleshooting Kerberos" +msgstr "Kerberos のトラブルシューティング" + +#: ../../rst/user_guide/windows_winrm.rst:482 +msgid "Kerberos is reliant on a properly-configured environment to work. To troubleshoot Kerberos issues, ensure that:" +msgstr "Kerberos は、適切に構成された環境でなければ動作しません。Kerberos の問題をトラブルシューティングするには、以下を確認してください。" + +#: ../../rst/user_guide/windows_winrm.rst:485 +msgid "The hostname set for the Windows host is the FQDN and not an IP address." +msgstr "Windows ホストのホスト名には、IP アドレスではなく FQDN であることを確認します。" + +#: ../../rst/user_guide/windows_winrm.rst:487 +msgid "The forward and reverse DNS lookups are working properly in the domain. To test this, ping the windows host by name and then use the ip address returned with ``nslookup``. The same name should be returned when using ``nslookup`` on the IP address." +msgstr "このドメインでは、DNS の正引きと逆引きが正常に動作しています。これをテストするには、Windows ホストに名前で ping を打ち、``nslookup`` で返された IP アドレスを使用します。IP アドレスに ``nslookup`` を使用すると、同じ名前が返されるはずです。" + +#: ../../rst/user_guide/windows_winrm.rst:492 +msgid "The Ansible host's clock is synchronized with the domain controller. Kerberos is time sensitive, and a little clock drift can cause the ticket generation process to fail." +msgstr "Ansible ホストの時計はドメインコントローラーと同期します。Kerberos は時間に敏感で、わずかな時計のずれにより、チケット生成プロセスが失敗する可能性があります。" + +#: ../../rst/user_guide/windows_winrm.rst:496 +msgid "Ensure that the fully qualified domain name for the domain is configured in the ``krb5.conf`` file. To check this, run:" +msgstr "ドメインの完全修飾ドメイン名が、``krb5.conf`` ファイルに設定されていることを確認してください。これを確認するには、次を実行します。" + +#: ../../rst/user_guide/windows_winrm.rst:504 +msgid "If the domain name returned by ``klist`` is different from the one requested, an alias is being used. The ``krb5.conf`` file needs to be updated so that the fully qualified domain name is used and not an alias." +msgstr "``klist`` で返されたドメイン名が要求されたものと異なる場合は、エイリアスが使用されています。``krb5.conf`` ファイルを更新して、エイリアスではなく完全修飾ドメイン名を使用する必要があります。" + +#: ../../rst/user_guide/windows_winrm.rst:508 +msgid "If the default kerberos tooling has been replaced or modified (some IdM solutions may do this), this may cause issues when installing or upgrading the Python Kerberos library. As of the time of this writing, this library is called ``pykerberos`` and is known to work with both MIT and Heimdal Kerberos libraries. To resolve ``pykerberos`` installation issues, ensure the system dependencies for Kerberos have been met (see: `Installing the Kerberos Library`_), remove any custom Kerberos tooling paths from the PATH environment variable, and retry the installation of Python Kerberos library package." +msgstr "デフォルトの kerberos ツールが置き換えられたり変更したりした場合 (いくつかの IdM ソリューションではそうなっているかもしれません)、Python Kerberos ライブラリーをインストールしたりアップグレードしたりする際に問題が発生する可能性があります。本ガイドの作成時点で、このライブラリーは ``pykerberos`` と呼ばれ、MIT と Heimdal Kerberos ライブラリーの両方で動作することが知られています。``pykerberos`` のインストール問題を解決するには、Kerberos のシステム依存性が満たされていることを確認し (参照: `Installing the Kerberos Library`_)、PATH 環境変数からカスタムの Kerberos ツールパスを削除し、Python Kerberos ライブラリーパッケージのインストールを再試行してください。" + +#: ../../rst/user_guide/windows_winrm.rst:515 +msgid "CredSSP authentication is a newer authentication protocol that allows credential delegation. This is achieved by encrypting the username and password after authentication has succeeded and sending that to the server using the CredSSP protocol." +msgstr "CredSSP 認証は、認証情報の委譲を可能にする新しい認証プロトコルになります。これは、認証が成功した後のユーザー名とパスワードを暗号化し、それを CredSSP プロトコルを使用してサーバーに送信することで実現しています。" + +#: ../../rst/user_guide/windows_winrm.rst:520 +msgid "Because the username and password are sent to the server to be used for double hop authentication, ensure that the hosts that the Windows host communicates with are not compromised and are trusted." +msgstr "ユーザー名とパスワードをサーバーに送信してダブルホップ認証に使用するため、Windows ホストが通信するホストが漏洩しておらず、信頼できることを確認してください。" + +#: ../../rst/user_guide/windows_winrm.rst:524 +msgid "CredSSP can be used for both local and domain accounts and also supports message encryption over HTTP." +msgstr "CredSSP は、ローカルアカウントとドメインアカウントの両方に使用でき、HTTPでのメッセージ暗号化にも対応しています。" + +#: ../../rst/user_guide/windows_winrm.rst:527 +msgid "To use CredSSP authentication, the host vars are configured like so:" +msgstr "CredSSP 認証を使用するには、以下のようにホスト変数を設定します。" + +#: ../../rst/user_guide/windows_winrm.rst:536 +msgid "There are some extra host variables that can be set as shown below:" +msgstr "以下のように設定できる追加のホスト変数があります。" + +#: ../../rst/user_guide/windows_winrm.rst:542 +msgid "CredSSP authentication is not enabled by default on a Windows host, but can be enabled by running the following in PowerShell:" +msgstr "CredSSP 認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" + +#: ../../rst/user_guide/windows_winrm.rst:552 +msgid "Installing CredSSP Library" +msgstr "CredSSP ライブラリーのインストール" + +#: ../../rst/user_guide/windows_winrm.rst:554 +msgid "The ``requests-credssp`` wrapper can be installed using ``pip``:" +msgstr "``requests-credssp`` ラッパーは、``pip`` を使用してインストールできます。" + +#: ../../rst/user_guide/windows_winrm.rst:563 +msgid "CredSSP and TLS 1.2" +msgstr "CredSSP および TLS 1.2" + +#: ../../rst/user_guide/windows_winrm.rst:565 +msgid "By default the ``requests-credssp`` library is configured to authenticate over the TLS 1.2 protocol. TLS 1.2 is installed and enabled by default for Windows Server 2012 and Windows 8 and more recent releases." +msgstr "デフォルトでは、``requests-credssp`` ライブラリーは、TLS 1.2 プロトコルで認証するように設定されています。TLS 1.2 は、Windows Server 2012 および Windows 8 と、それ以降のリリースでは、デフォルトでインストールされ、有効になっています。" + +#: ../../rst/user_guide/windows_winrm.rst:569 +msgid "There are two ways that older hosts can be used with CredSSP:" +msgstr "古いホストを CredSSP で使用できる方法は 2 つあります。" + +#: ../../rst/user_guide/windows_winrm.rst:571 +msgid "Install and enable a hotfix to enable TLS 1.2 support (recommended for Server 2008 R2 and Windows 7)." +msgstr "TLS 1.2 のサポートを有効にする Hotfix をインストールして有効にしてください (Server 2008 R2 および Windows 7 で推奨)。" + +#: ../../rst/user_guide/windows_winrm.rst:574 +msgid "Set ``ansible_winrm_credssp_disable_tlsv1_2=True`` in the inventory to run over TLS 1.0. This is the only option when connecting to Windows Server 2008, which has no way of supporting TLS 1.2" +msgstr "インベントリーに ``ansible_winrm_credssp_disable_tlsv1_2=True`` を設定して、TLS 1.0 で実行するように設定します。これは、TLS 1.2 に対応していない Windows Server 2008 に接続する際の唯一の選択肢です。" + +#: ../../rst/user_guide/windows_winrm.rst:578 +msgid "See :ref:`winrm_tls12` for more information on how to enable TLS 1.2 on the Windows host." +msgstr "Windows ホストで TLS 1.2 を有効にする方法は、「:ref:`winrm_tls12`」を参照してください。" + +#: ../../rst/user_guide/windows_winrm.rst:584 +msgid "Set CredSSP Certificate" +msgstr "CredSSP 証明書の設定" + +#: ../../rst/user_guide/windows_winrm.rst:586 +msgid "CredSSP works by encrypting the credentials through the TLS protocol and uses a self-signed certificate by default. The ``CertificateThumbprint`` option under the WinRM service configuration can be used to specify the thumbprint of another certificate." +msgstr "CredSSP は、TLS プロトコルで認証情報を暗号化して動作し、デフォルトでは自己署名証明書を使用します。WinRM サービス構成の ``CertificateThumbprint`` オプションを使用して、別の証明書のサムプリントを指定することができます。" + +#: ../../rst/user_guide/windows_winrm.rst:589 +msgid "This certificate configuration is independent of the WinRM listener certificate. With CredSSP, message transport still occurs over the WinRM listener, but the TLS-encrypted messages inside the channel use the service-level certificate." +msgstr "この証明書構成は、WinRM リスナーの証明書とは独立しています。CredSSP では、メッセージトランスポートは引き続き WinRM リスナーを介して行われますが、チャンネル内の TLS 暗号化メッセージにはサービスレベル証明書が使用されます。" + +#: ../../rst/user_guide/windows_winrm.rst:593 +msgid "To explicitly set the certificate to use for CredSSP:" +msgstr "CredSSP に使用する証明書を明示的に設定するには、以下を実行します。" + +#: ../../rst/user_guide/windows_winrm.rst:607 +msgid "Non-Administrator Accounts" +msgstr "管理者以外のアカウント" + +#: ../../rst/user_guide/windows_winrm.rst:609 +msgid "WinRM is configured by default to only allow connections from accounts in the local ``Administrators`` group. This can be changed by running:" +msgstr "WinRM は、デフォルトで、ローカルの ``Administrators`` グループのアカウントからの接続のみを許可するように設定されています。これは、以下を実行して変更できます。" + +#: ../../rst/user_guide/windows_winrm.rst:616 +msgid "This will display an ACL editor, where new users or groups may be added. To run commands over WinRM, users and groups must have at least the ``Read`` and ``Execute`` permissions enabled." +msgstr "これにより、ACL エディターが表示され、新しいユーザーまたはグループを追加できます。WinRM でコマンドを実行するには、ユーザーおよびグループに少なくとも ``Read`` および ``Execute`` パーミッションが有効になっている必要があります。" + +#: ../../rst/user_guide/windows_winrm.rst:620 +msgid "While non-administrative accounts can be used with WinRM, most typical server administration tasks require some level of administrative access, so the utility is usually limited." +msgstr "WinRM では、管理者以外のアカウントを使用することもできますが、一般的なサーバー管理作業では、ある程度の管理者権限が必要となるため、実用性は限られてしまいます。" + +#: ../../rst/user_guide/windows_winrm.rst:626 +msgid "WinRM Encryption" +msgstr "WinRM 暗号化" + +#: ../../rst/user_guide/windows_winrm.rst:628 +msgid "By default WinRM will fail to work when running over an unencrypted channel. The WinRM protocol considers the channel to be encrypted if using TLS over HTTP (HTTPS) or using message level encryption. Using WinRM with TLS is the recommended option as it works with all authentication options, but requires a certificate to be created and used on the WinRM listener." +msgstr "デフォルトでは、WinRM は、暗号化されていないチャンネル上で実行すると、動作に失敗します。WinRM プロトコルは、TLS over HTTP (HTTPS) を使用している場合や、メッセージレベルの暗号化を使用している場合は、チャンネルが暗号化されているとみなします。WinRM を TLS で使用することは、すべての認証オプションで動作するため、推奨されるオプションですが、WinRM リスナーで証明書を作成して使用する必要があります。" + +#: ../../rst/user_guide/windows_winrm.rst:634 +msgid "If in a domain environment, ADCS can create a certificate for the host that is issued by the domain itself." +msgstr "ドメイン環境の場合、ADCS はドメイン自体が発行するホストの証明書を作成できます。" + +#: ../../rst/user_guide/windows_winrm.rst:637 +msgid "If using HTTPS is not an option, then HTTP can be used when the authentication option is ``NTLM``, ``Kerberos`` or ``CredSSP``. These protocols will encrypt the WinRM payload with their own encryption method before sending it to the server. The message-level encryption is not used when running over HTTPS because the encryption uses the more secure TLS protocol instead. If both transport and message encryption is required, set ``ansible_winrm_message_encryption=always`` in the host vars." +msgstr "HTTPS を使用することができない場合は、認証オプションが ``NTLM``、``Kerberos``、または ``CredSSP`` であれば、HTTP を使用することができます。これらのプロトコルは、WinRM ペイロードを独自の暗号化方式で暗号化してからサーバーに送信します。暗号化は、より安全な TLS プロトコルを代わりに使用するため、HTTPS で実行する場合に、メッセージレベルの暗号化は使用されません。トランスポートとメッセージの両方の暗号化が必要な場合は、ホスト変数に ``ansible_winrm_message_encryption=always`` を設定してください。" + +#: ../../rst/user_guide/windows_winrm.rst:645 +msgid "Message encryption over HTTP requires pywinrm>=0.3.0." +msgstr "HTTPでのメッセージ暗号化には 0.3.0 以上の pywinrm が必要です。" + +#: ../../rst/user_guide/windows_winrm.rst:647 +msgid "A last resort is to disable the encryption requirement on the Windows host. This should only be used for development and debugging purposes, as anything sent from Ansible can be viewed, manipulated and also the remote session can completely be taken over by anyone on the same network. To disable the encryption requirement:" +msgstr "最後の手段として、Windows ホストの暗号化要件を無効にすることができます。これは、Ansible から送信されたものはすべて閲覧、操作でき、また同じネットワーク上の誰もがリモートセッションを完全に乗っ取ることができるため、開発やデバッグの目的でのみ使用してください。暗号化を無効にするには、以下の手順に従います。" + +#: ../../rst/user_guide/windows_winrm.rst:657 +msgid "Do not disable the encryption check unless it is absolutely required. Doing so could allow sensitive information like credentials and files to be intercepted by others on the network." +msgstr "どうしても必要な場合を除き、暗号化チェックを無効にしないでください。暗号化チェックを無効にすると、認証情報やファイルなどの機密情報がネットワーク上の他の人に傍受される可能性があります。" + +#: ../../rst/user_guide/windows_winrm.rst:664 +msgid "Inventory Options" +msgstr "インベントリーオプション" + +#: ../../rst/user_guide/windows_winrm.rst:666 +msgid "Ansible's Windows support relies on a few standard variables to indicate the username, password, and connection type of the remote hosts. These variables are most easily set up in the inventory, but can be set on the ``host_vars``/ ``group_vars`` level." +msgstr "Ansible の Windows サポートは、リモートホストのユーザー名、パスワード、接続タイプを示すいくつかの標準変数に依存しています。これらの変数はインベントリーで最も簡単に設定できますが、``host_vars``/``group_vars`` レベルで設定することもできます。" + +#: ../../rst/user_guide/windows_winrm.rst:671 +msgid "When setting up the inventory, the following variables are required:" +msgstr "インベントリーを設定する際に、以下の変数が必要になります。" + +#: ../../rst/user_guide/windows_winrm.rst:686 +msgid "Using the variables above, Ansible will connect to the Windows host with Basic authentication through HTTPS. If ``ansible_user`` has a UPN value like ``username@MY.DOMAIN.COM`` then the authentication option will automatically attempt to use Kerberos unless ``ansible_winrm_transport`` has been set to something other than ``kerberos``." +msgstr "上記の変数を使用すると、Ansible は HTTPS を通じて Basic 認証で Windows ホストに接続します。``ansible_user`` に ``username@MY.DOMAIN.COM`` のような UPN 値がある場合は、``ansible_winrm_transport`` が ``kerberos`` 以外に設定されていない限り、認証オプションは自動的に Kerberos の使用を試みます。" + +#: ../../rst/user_guide/windows_winrm.rst:692 +msgid "The following custom inventory variables are also supported for additional configuration of WinRM connections:" +msgstr "以下のカスタムインベントリー変数も、WinRM 接続の追加設定のためにサポートされています。" + +#: ../../rst/user_guide/windows_winrm.rst:695 +msgid "``ansible_port``: The port WinRM will run over, HTTPS is ``5986`` which is the default while HTTP is ``5985``" +msgstr "``ansible_port``: WinRM が実行するポートです。HTTPS のデフォルトは ``5986`` で、HTTP のデフォルトは ``5985`` です。" + +#: ../../rst/user_guide/windows_winrm.rst:698 +msgid "``ansible_winrm_scheme``: Specify the connection scheme (``http`` or ``https``) to use for the WinRM connection. Ansible uses ``https`` by default unless ``ansible_port`` is ``5985``" +msgstr "``ansible_winrm_scheme``: WinRM 接続に使用する接続スキーム (``http`` または ``https``) を指定します。Ansible は、``ansible_port`` が ``5985`` に指定されていない限り、デフォルトで ``https`` を使用します。" + +#: ../../rst/user_guide/windows_winrm.rst:702 +msgid "``ansible_winrm_path``: Specify an alternate path to the WinRM endpoint, Ansible uses ``/wsman`` by default" +msgstr "``ansible_winrm_path``: WinRMエンドポイントへの別のパスを指定します。Ansible はデフォルトで ``/wsman`` を使用します。" + +#: ../../rst/user_guide/windows_winrm.rst:705 +msgid "``ansible_winrm_realm``: Specify the realm to use for Kerberos authentication. If ``ansible_user`` contains ``@``, Ansible will use the part of the username after ``@`` by default" +msgstr "``ansible_winrm_realm``: Kerberos 認証に使用するレルムを指定します。``ansible_user`` に ``@`` が含まれる場合、Ansible はデフォルトで ``@`` の後にユーザー名の一部を使用します。" + +#: ../../rst/user_guide/windows_winrm.rst:709 +msgid "``ansible_winrm_transport``: Specify one or more authentication transport options as a comma-separated list. By default, Ansible will use ``kerberos, basic`` if the ``kerberos`` module is installed and a realm is defined, otherwise it will be ``plaintext``" +msgstr "``ansible_winrm_transport``: 1 つ以上の認証トランスポートオプションをコンマ区切りのリストで指定します。デフォルトでは、``kerberos`` モジュールがインストールされていてレルムが定義されている場合、Ansible は ``kerberos, basic`` を使用し、それ以外の場合は ``plaintext`` になります。" + +#: ../../rst/user_guide/windows_winrm.rst:714 +msgid "``ansible_winrm_server_cert_validation``: Specify the server certificate validation mode (``ignore`` or ``validate``). Ansible defaults to ``validate`` on Python 2.7.9 and higher, which will result in certificate validation errors against the Windows self-signed certificates. Unless verifiable certificates have been configured on the WinRM listeners, this should be set to ``ignore``" +msgstr "``ansible_winrm_server_cert_validation``: サーバー証明書の検証モード (``ignore`` または``validate``) を指定します。Ansible のデフォルトは、Python 2.7.9 以降では ``validate`` で、これは Windows の自己署名証明書に対して証明書の検証エラーが発生します。WinRM リスナーで検証可能な証明書が設定されていない場合は、この設定を ``ignore`` に設定する必要があります。" + +#: ../../rst/user_guide/windows_winrm.rst:721 +msgid "``ansible_winrm_operation_timeout_sec``: Increase the default timeout for WinRM operations, Ansible uses ``20`` by default" +msgstr "``ansible_winrm_operation_timeout_sec``: WinRM 操作のデフォルトタイムアウトを増やすと、Ansible はデフォルトで ``20`` を使用します。" + +#: ../../rst/user_guide/windows_winrm.rst:724 +msgid "``ansible_winrm_read_timeout_sec``: Increase the WinRM read timeout, Ansible uses ``30`` by default. Useful if there are intermittent network issues and read timeout errors keep occurring" +msgstr "``ansible_winrm_read_timeout_sec``: WinRM の読み取りタイムアウトを増やします。Ansible はデフォルトで ``30`` を使用します。ネットワークの問題が断続的に発生し、読み取りタイムアウトのエラーが発生し続ける場合に有効です。" + +#: ../../rst/user_guide/windows_winrm.rst:728 +msgid "``ansible_winrm_message_encryption``: Specify the message encryption operation (``auto``, ``always``, ``never``) to use, Ansible uses ``auto`` by default. ``auto`` means message encryption is only used when ``ansible_winrm_scheme`` is ``http`` and ``ansible_winrm_transport`` supports message encryption. ``always`` means message encryption will always be used and ``never`` means message encryption will never be used" +msgstr "``ansible_winrm_message_encryption``: 使用するメッセージ暗号化操作 (``auto``、``always``、``never``) を指定します。Ansible はデフォルトで ``auto`` を使用します。``auto`` は、``ansible_winrm_scheme`` が ``http`` で、``ansible_winrm_transport`` がメッセージ暗号化をサポートしている場合に限り、メッセージ暗号化が使用されることを意味します。``always`` は、メッセージ暗号化が常に使用されることを意味し、``never`` は、メッセージ暗号化が決して使用されないことを意味します。" + +#: ../../rst/user_guide/windows_winrm.rst:735 +msgid "``ansible_winrm_ca_trust_path``: Used to specify a different cacert container than the one used in the ``certifi`` module. See the HTTPS Certificate Validation section for more details." +msgstr "``ansible_winrm_ca_trust_path``: ``certifi`` モジュールで使用されているものとは異なる cacert コンテナーを指定するために使用します。詳細は、「HTTPS 証明書の検証」セクションを参照してください。" + +#: ../../rst/user_guide/windows_winrm.rst:739 +msgid "``ansible_winrm_send_cbt``: When using ``ntlm`` or ``kerberos`` over HTTPS, the authentication library will try to send channel binding tokens to mitigate against man in the middle attacks. This flag controls whether these bindings will be sent or not (default: ``yes``)." +msgstr "``ansible_winrm_send_cbt``: ``ntlm`` または ``kerberos`` を HTTPS で使用する場合、認証ライブラリーは、中間者攻撃を緩和するためにチャンネルバインディングトークンの送信を試みます。このフラグは、これらのバインディングを送信するかどうかを制御します (デフォルト: ``yes``)。" + +#: ../../rst/user_guide/windows_winrm.rst:744 +msgid "``ansible_winrm_*``: Any additional keyword arguments supported by ``winrm.Protocol`` may be provided in place of ``*``" +msgstr "``ansible_winrm_*``: ``winrm.Protocol`` でサポートされている任意の追加キーワード引数は、代わりに ``*`` で指定できます。" + +#: ../../rst/user_guide/windows_winrm.rst:747 +msgid "In addition, there are also specific variables that need to be set for each authentication option. See the section on authentication above for more information." +msgstr "さらに、各認証オプションで設定する必要がある特定の変数もあります。詳細は、上記の認証に関するセクションを参照してください。" + +#: ../../rst/user_guide/windows_winrm.rst:750 +msgid "Ansible 2.0 has deprecated the \"ssh\" from ``ansible_ssh_user``, ``ansible_ssh_pass``, ``ansible_ssh_host``, and ``ansible_ssh_port`` to become ``ansible_user``, ``ansible_password``, ``ansible_host``, and ``ansible_port``. If using a version of Ansible prior to 2.0, the older style (``ansible_ssh_*``) should be used instead. The shorter variables are ignored, without warning, in older versions of Ansible." +msgstr "Ansible 2.0 では、``ansible_ssh_user``、``ansible_ssh_pass``、``ansible_ssh_host``、および ``ansible_ssh_port`` の「ssh」が非推奨となり、``ansible_user``、``ansible_password``、``ansible_host``、および ``ansible_port`` となりました。Ansible 2.0 より前のバージョンを使用している場合は、代わりに古いスタイル (``ansible_ssh_*``) を使用する必要があります。短い方の変数は、古いバージョンの Ansible では警告なしに無視されます。" + +#: ../../rst/user_guide/windows_winrm.rst:757 +msgid "``ansible_winrm_message_encryption`` is different from transport encryption done over TLS. The WinRM payload is still encrypted with TLS when run over HTTPS, even if ``ansible_winrm_message_encryption=never``." +msgstr "``ansible_winrm_message_encryption`` は、TLS 上で行われるトランスポート暗号化とは異なります。WinRM ペイロードは、``ansible_winrm_message_encryption=never`` であっても、HTTPS で実行された場合でも TLS で暗号化されます。" + +#: ../../rst/user_guide/windows_winrm.rst:764 +msgid "IPv6 Addresses" +msgstr "IPv6 アドレス" + +#: ../../rst/user_guide/windows_winrm.rst:766 +msgid "IPv6 addresses can be used instead of IPv4 addresses or hostnames. This option is normally set in an inventory. Ansible will attempt to parse the address using the `ipaddress <https://docs.python.org/3/library/ipaddress.html>`_ package and pass to pywinrm correctly." +msgstr "IPv4 アドレスやホスト名の代わりに、IPv6 アドレスを使用することができます。このオプションは通常、インベントリーで設定します。Ansible は、`ipaddress <https://docs.python.org/3/library/ipaddress.html>`_ パッケージを使用してアドレスの解析を試み、pywinrm に正しく渡します。" + +#: ../../rst/user_guide/windows_winrm.rst:771 +msgid "When defining a host using an IPv6 address, just add the IPv6 address as you would an IPv4 address or hostname:" +msgstr "IPv6 アドレスを使用してホストを定義する場合は、IPv4 アドレスやホスト名と同じように IPv6 アドレスを追加するだけです。" + +#: ../../rst/user_guide/windows_winrm.rst:785 +msgid "The ipaddress library is only included by default in Python 3.x. To use IPv6 addresses in Python 2.7, make sure to run ``pip install ipaddress`` which installs a backported package." +msgstr "ipaddress ライブラリーは Python 3.x にのみデフォルトで含まれています。Python 2.7 で IPv6 アドレスを使用するには、バックポートされたパッケージをインストールする ``pip install ipaddress`` を必ず実行してください。" + +#: ../../rst/user_guide/windows_winrm.rst:792 +msgid "HTTPS Certificate Validation" +msgstr "HTTPS 証明書の検証" + +#: ../../rst/user_guide/windows_winrm.rst:794 +msgid "As part of the TLS protocol, the certificate is validated to ensure the host matches the subject and the client trusts the issuer of the server certificate. When using a self-signed certificate or setting ``ansible_winrm_server_cert_validation: ignore`` these security mechanisms are bypassed. While self signed certificates will always need the ``ignore`` flag, certificates that have been issued from a certificate authority can still be validated." +msgstr "TLS プロトコルの一環として、証明書が検証され、ホストがサブジェクトと一致し、クライアントがサーバー証明書の発行者を信頼していることが確認されます。自己署名証明書を使用したり、``ansible_winrm_server_cert_validation: ignore`` を設定したりすると、これらのセキュリティーメカニズムが回避されます。自己署名証明書には常に ``ignore`` フラグが必要ですが、認証局から発行された証明書は検証されます。" + +#: ../../rst/user_guide/windows_winrm.rst:802 +msgid "One of the more common ways of setting up a HTTPS listener in a domain environment is to use Active Directory Certificate Service (AD CS). AD CS is used to generate signed certificates from a Certificate Signing Request (CSR). If the WinRM HTTPS listener is using a certificate that has been signed by another authority, like AD CS, then Ansible can be set up to trust that issuer as part of the TLS handshake." +msgstr "ドメイン環境で HTTPS リスナーをセットアップする一般的な方法の 1 つに、Active Directory Certificate Service (AD CS) を使用する方法があります。AD CS は、CSR (Certificate Signing Request) から署名付き証明書を生成するために使用されます。WinRM HTTPS リスナーが AD CS のような別の機関によって署名された証明書を使用している場合、Ansible は TLS ハンドシェイクの一部としてその発行者を信頼するように設定することができます。" + +#: ../../rst/user_guide/windows_winrm.rst:809 +msgid "To get Ansible to trust a Certificate Authority (CA) like AD CS, the issuer certificate of the CA can be exported as a PEM encoded certificate. This certificate can then be copied locally to the Ansible controller and used as a source of certificate validation, otherwise known as a CA chain." +msgstr "AD CS のような認証局 (CA) を Ansible に信頼させるには、CA の発行者証明書を PEM エンコード証明書としてエクスポートします。この証明書は、Ansible コントローラーのローカルにコピーして、証明書検証のソースとして使用することができます (CA チェーンとも呼ばれます)。" + +#: ../../rst/user_guide/windows_winrm.rst:814 +msgid "The CA chain can contain a single or multiple issuer certificates and each entry is contained on a new line. To then use the custom CA chain as part of the validation process, set ``ansible_winrm_ca_trust_path`` to the path of the file. If this variable is not set, the default CA chain is used instead which is located in the install path of the Python package `certifi <https://github.com/certifi/python-certifi>`_." +msgstr "CA チェーンには、単一または複数の発行者証明書を含めることができ、各エントリーは新しい行に含まれます。認証プロセスの一部としてカスタム CA チェーンを使用するには、``ansible_winrm_ca_trust_path`` にファイルのパスを設定します。この変数が設定されていない場合は、Python パッケージ `certifi <https://github.com/certifi/python-certifi>`_ のインストールパスにあるデフォルトの CAチ ェーンが使用されます。" + +#: ../../rst/user_guide/windows_winrm.rst:821 +msgid "Each HTTP call is done by the Python requests library which does not use the systems built-in certificate store as a trust authority. Certificate validation will fail if the server's certificate issuer is only added to the system's truststore." +msgstr "HTTP 呼び出しはそれぞれ、システムに組み込まれた証明書ストアを信頼機関として使用しない Python リクエストライブラリーによって行われます。サーバーの証明書発行者がシステムのトラストストアに追加されていない場合、証明書の検証は失敗します。" + +#: ../../rst/user_guide/windows_winrm.rst:829 +msgid "TLS 1.2 Support" +msgstr "TLS 1.2 のサポート" + +#: ../../rst/user_guide/windows_winrm.rst:831 +msgid "As WinRM runs over the HTTP protocol, using HTTPS means that the TLS protocol is used to encrypt the WinRM messages. TLS will automatically attempt to negotiate the best protocol and cipher suite that is available to both the client and the server. If a match cannot be found then Ansible will error out with a message similar to:" +msgstr "WinRM は HTTP プロトコル上で動作するため、HTTPS を使用するということは、WinRM メッセージの暗号化に TLS プロトコルが使用されることを意味します。TLS は、クライアントとサーバーの両方で利用可能な、最適なプロトコルと暗号スイートを自動的に取り決めようとします。一致するものが見つからない場合、Ansible は次のようなメッセージでエラーになります。" + +#: ../../rst/user_guide/windows_winrm.rst:841 +msgid "Commonly this is when the Windows host has not been configured to support TLS v1.2 but it could also mean the Ansible controller has an older OpenSSL version installed." +msgstr "これは、Windows ホストが TLS v1.2 をサポートするように設定されていない場合ですが、Ansible コントローラーに古い OpenSSL バージョンがインストールされていることも意味します。" + +#: ../../rst/user_guide/windows_winrm.rst:845 +msgid "Windows 8 and Windows Server 2012 come with TLS v1.2 installed and enabled by default but older hosts, like Server 2008 R2 and Windows 7, have to be enabled manually." +msgstr "Windows 8 および Windows Server 2012 には、デフォルトで TLS v1.2 がインストールされ、有効になっていますが、Server 2008 R2 や Windows 7 などの古いホストは手動で有効にする必要があります。" + +#: ../../rst/user_guide/windows_winrm.rst:849 +msgid "There is a bug with the TLS 1.2 patch for Server 2008 which will stop Ansible from connecting to the Windows host. This means that Server 2008 cannot be configured to use TLS 1.2. Server 2008 R2 and Windows 7 are not affected by this issue and can use TLS 1.2." +msgstr "Server 2008 の TLS 1.2 パッチにはバグがあり、Ansible の Windows ホストへの接続が停止してしまいます。これは、Server 2008 が TLS 1.2 を使用するように設定できないことを意味します。Server 2008 R2 とWindows 7 はこの問題の影響を受けず、TLS 1.2 を使用できます。" + +#: ../../rst/user_guide/windows_winrm.rst:854 +msgid "To verify what protocol the Windows host supports, you can run the following command on the Ansible controller:" +msgstr "Windows ホストが対応しているプロトコルを確認するには、Ansible コントローラーで以下のコマンドを実行します。" + +#: ../../rst/user_guide/windows_winrm.rst:861 +msgid "The output will contain information about the TLS session and the ``Protocol`` line will display the version that was negotiated:" +msgstr "出力には TLS セッションに関する情報が含まれ、``Protocol`` 行にはネゴシエートされたバージョンが表示されます。" + +#: ../../rst/user_guide/windows_winrm.rst:899 +msgid "If the host is returning ``TLSv1`` then it should be configured so that TLS v1.2 is enable. You can do this by running the following PowerShell script:" +msgstr "ホストが ``TLSv1`` を返す場合は、TLS v1.2 が有効になるように設定する必要があります。これは、次の PowerShell スクリプトを実行することで行うことができます。" + +#: ../../rst/user_guide/windows_winrm.rst:924 +msgid "The below Ansible tasks can also be used to enable TLS v1.2:" +msgstr "以下の Ansible タスクを使用して TLS v1.2 を有効にすることもできます。" + +#: ../../rst/user_guide/windows_winrm.rst:954 +msgid "There are other ways to configure the TLS protocols as well as the cipher suites that are offered by the Windows host. One tool that can give you a GUI to manage these settings is `IIS Crypto <https://www.nartac.com/Products/IISCrypto/>`_ from Nartac Software." +msgstr "TLS プロトコルや、Windows ホストが提供する暗号スイートを設定する方法は他にもあります。これらの設定を管理するための GUI を提供するツールとして、Nartac Software 社の `IIS Crypto <https://www.nartac.com/Products/IISCrypto/>`_ があります。" + +#: ../../rst/user_guide/windows_winrm.rst:962 +msgid "WinRM limitations" +msgstr "WinRM の制限" + +#: ../../rst/user_guide/windows_winrm.rst:963 +msgid "Due to the design of the WinRM protocol , there are a few limitations when using WinRM that can cause issues when creating playbooks for Ansible. These include:" +msgstr "WinRM プロトコルの設計上、WinRM を使用する際にはいくつかの制限があり、Ansible の Playbook を作成する際に問題となることがあります。これには次のようなものがあります。" + +#: ../../rst/user_guide/windows_winrm.rst:967 +msgid "Credentials are not delegated for most authentication types, which causes authentication errors when accessing network resources or installing certain programs." +msgstr "ほとんどの認証タイプで認証情報が委譲されていないため、ネットワークリソースへのアクセスや特定のプログラムのインストール時に認証エラーが発生することがありました。" + +#: ../../rst/user_guide/windows_winrm.rst:971 +msgid "Many calls to the Windows Update API are blocked when running over WinRM." +msgstr "WinRM 経由で実行すると、Windows Update API への多くの呼び出しがブロックされます。" + +#: ../../rst/user_guide/windows_winrm.rst:973 +msgid "Some programs fail to install with WinRM due to no credential delegation or because they access forbidden Windows API like WUA over WinRM." +msgstr "認証情報の委譲や、WUA over WinRM などの禁止されている Windows API へのアクセスにより、一部のプログラムは WinRM でインストールできない場合があります。" + +#: ../../rst/user_guide/windows_winrm.rst:976 +msgid "Commands under WinRM are done under a non-interactive session, which can prevent certain commands or executables from running." +msgstr "WinRM のコマンドは非対話型セッションで実行されるため、特定のコマンドや実行ファイルが実行できない場合があります。" + +#: ../../rst/user_guide/windows_winrm.rst:979 +msgid "You cannot run a process that interacts with ``DPAPI``, which is used by some installers (like Microsoft SQL Server)." +msgstr "一部のインストーラー (Microsoft SQL Server など) が使用する ``DPAPI`` と対話するプロセスを実行することはできません。" + +#: ../../rst/user_guide/windows_winrm.rst:982 +msgid "Some of these limitations can be mitigated by doing one of the following:" +msgstr "この制限の一部は、以下のいずれかを実行して軽減できます。" + +#: ../../rst/user_guide/windows_winrm.rst:984 +msgid "Set ``ansible_winrm_transport`` to ``credssp`` or ``kerberos`` (with ``ansible_winrm_kerberos_delegation=true``) to bypass the double hop issue and access network resources" +msgstr "ダブルホップ問題を回避してネットワークリソースにアクセスするために、``ansible_winrm_transport`` を ``credssp`` または ``kerberos`` (``ansible_winrm_kerberos_delegation=true`` を使用) に設定します。" + +#: ../../rst/user_guide/windows_winrm.rst:988 +msgid "Use ``become`` to bypass all WinRM restrictions and run a command as it would locally. Unlike using an authentication transport like ``credssp``, this will also remove the non-interactive restriction and API restrictions like WUA and DPAPI" +msgstr "``become`` を使用すると、すべての WinRM 制限を回避して、ローカルと同様にコマンドを実行できます。``credssp`` のような認証トランスポートを使用する場合とは異なり、非対話型の制限や、WUA や DPAPI などの API の制限も解除されます。" + +#: ../../rst/user_guide/windows_winrm.rst:993 +msgid "Use a scheduled task to run a command which can be created with the ``win_scheduled_task`` module. Like ``become``, this bypasses all WinRM restrictions but can only run a command and not modules." +msgstr "``win_scheduled_task`` モジュールで作成されるコマンドを実行するために、スケジュールされたタスクを使用します。``become`` と同様に、WinRM の制限をすべて回避しますが、実行できるのはコマンドのみで、モジュールは実行できません。" + +#~ msgid "Any machine with Ansible installed. You can run Ansible commands and playbooks by invoking the ``ansible`` or ``ansible-playbook`` command from any control node. You can use any computer that has a Python installation as a control node - laptops, shared desktops, and servers can all run Ansible. However, you cannot use a Windows machine as a control node. You can have multiple control nodes." +#~ msgstr "Ansible がインストールされているマシン。任意のコントロールノードから ``ansible`` コマンドまたは ``ansible-playbook`` コマンドを呼び出すことで、Ansible コマンドおよび Playbook を実行できます。Python がインストールされているコンピューターであれば、ラップトップ、共有ディスクトップ、サーバーなど、どのコンピューターでも Ansible を実行することができます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを持つことができます。" + +#~ msgid "The network devices (and/or servers) you manage with Ansible. Managed nodes are also sometimes called \"hosts\". Ansible is not installed on managed nodes." +#~ msgstr "Ansible で管理するネットワークデバイス (またはサーバー)。管理ノードは「ホスト」と呼ばれることもあります。Ansible は管理ノードにインストールされません。" + +#~ msgid "A list of managed nodes. An inventory file is also sometimes called a \"hostfile\". Your inventory can specify information like IP address for each managed node. An inventory can also organize managed nodes, creating and nesting groups for easier scaling. To learn more about inventory, see :ref:`the Working with Inventory<intro_inventory>` section." +#~ msgstr "管理ノードの一覧。インベントリーファイルは「ホストファイル」と呼ばれることもあります。インベントリーは、各管理ノードに対して IP アドレスなどの情報を指定できます。インベントリーは管理ノードを整理でき、スケーリングが容易になるグループの作成やネスト化が可能です。インベントリーの詳細は「:ref:`インベントリーでの作業 <intro_inventory>`」セクションを参照してください。" + +#~ msgid "The units of action in Ansible. You can execute a single task once with an ad hoc command." +#~ msgstr "Ansible でのアクションの単位。アドホックコマンドを使用すると、単一のタスクを実行できます。" + +#~ msgid "Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`." +#~ msgstr "順番に並べられたタスクの一覧は保存されているため、その順番でタスクを繰り返し実行することができます。Playbook には、タスクだけでなく、変数も含めることができます。Playbook は YAML で記述されているため、読みやすく、書きやすく、共有しやすく、理解しやすい特徴があります。Playbook の詳細は、「:ref:`about_playbooks`」を参照してください。" + +#~ msgid "Welcome to the Ansible User Guide! This guide covers how to work with Ansible, including using the command line, working with inventory, interacting with data, writing tasks, plays, and playbooks; executing playbooks, and reference materials. This page outlines the most common situations and questions that bring readers to this section. If you prefer a traditional table of contents, you can find one at the bottom of the page." +#~ msgstr "Ansible ユーザーガイドへようこそ! 本ガイドでは、コマンドラインの使用、インベントリーの操作、データの操作、タスク、プレイ、Playbook の作成、Playbook 実行、参考資料など、Ansible の使用方法について説明しています。このページでは、読者がこのセクションを訪れる時に抱く最も一般的な状況および質問の概要を説明します。従来の目次をご希望の方は、ページ下部を参照してください。" + +#~ msgid "Getting started" +#~ msgstr "はじめに" + +#~ msgid "I'd like an overview of how Ansible works. Where can I find:" +#~ msgstr "Ansible がどのように機能するかの概要を知りたいです。どこで見つけることができますか。" + +#~ msgid "a :ref:`quick video overview <quickstart_guide>`" +#~ msgstr ":ref:`クイックビデオの概要 <quickstart_guide>`" + +#~ msgid "a :ref:`text introduction <intro_getting_started>`" +#~ msgstr ":ref:`テキストの紹介 <intro_getting_started>`" + +#~ msgid "I'm ready to learn about Ansible. What :ref:`basic_concepts` do I need to learn?" +#~ msgstr "Ansible に関する準備が整っています。どの :ref:`basic_concepts` を学ぶ必要がありますか。" + +#~ msgid "I want to use Ansible without writing a playbook. How do I use :ref:`ad hoc commands <intro_adhoc>`?" +#~ msgstr "Playbook を作成せずに Ansible を使用する場合は、:ref:`アドホックコマンド <intro_adhoc>` をどのように使用すればいいですか。" + +#~ msgid "I'm running an Ansible command and forgot which flags to use. Do you have a :ref:`cheatsheet`?" +#~ msgstr "Ansible コマンドを実行する際に、使用するフラグを忘れてしまいました。:ref:`チートシート` はありますか?" + +#~ msgid "If you prefer to read the entire User Guide, here's a list of the pages in order:" +#~ msgstr "本ユーザーガイドをすべて読む場合は、以下に示す順番でページを表示してください。" + +#~ msgid "Getting Started" +#~ msgstr "はじめに" + +#~ msgid "Now that you have read the :ref:`installation guide<installation_guide>` and installed Ansible on a control node, you are ready to learn how Ansible works. A basic Ansible command or playbook:" +#~ msgstr "「:ref:`インストールガイド<installation_guide>`」を読み、コントロールノードに Ansible をインストールしたら、Ansible の仕組みを学ぶ準備ができました。基本的な Ansible のコマンドや Playbook です。" + +#~ msgid "selects machines to execute against from inventory" +#~ msgstr "インベントリーから実行するマシンを選択する" + +#~ msgid "connects to those machines (or network devices, or other managed nodes), usually over SSH" +#~ msgstr "通常は SSH 経由で、このマシン (もしくはネットワークデバイスまたはその他の管理対象ノード) に接続する" + +#~ msgid "copies one or more modules to the remote machines and starts execution there" +#~ msgstr "1 つ以上のモジュールをリモートマシンにコピーし、そこで実行を開始する" + +#~ msgid "Ansible can do much more, but you should understand the most common use case before exploring all the powerful configuration, deployment, and orchestration features of Ansible. This page illustrates the basic process with a simple inventory and an ad hoc command. Once you understand how Ansible works, you can read more details about :ref:`ad hoc commands<intro_adhoc>`, organize your infrastructure with :ref:`inventory<intro_inventory>`, and harness the full power of Ansible with :ref:`playbooks<playbooks_intro>`." +#~ msgstr "Ansible はさらに多くのことができますが、Ansible の強力な設定、デプロイメント、オーケストレーション機能をすべて試す前に、最も一般的な使用例を理解しておく必要があります。このページでは、簡単なインベントリーとアドホックコマンドを使用して、基本的なプロセスを説明しています。Ansible の仕組みを理解したら、:ref:`アドホックコマンド<intro_adhoc>` の詳細を読み、:ref:`インベントリー<intro_inventory>` でインフラストラクチャーを整理し、:ref:`Playbook<playbooks_intro>` で Ansible の機能を最大限に活用することができます。" + +#~ msgid "Selecting machines from inventory" +#~ msgstr "インベントリーからのマシンの選択" + +#~ msgid "Ansible reads information about which machines you want to manage from your inventory. Although you can pass an IP address to an ad hoc command, you need inventory to take advantage of the full flexibility and repeatability of Ansible." +#~ msgstr "Ansible は、インベントリーから管理したいマシンの情報を読み込みます。アドホックコマンドに IP アドレスを渡すこともできますが、Ansible の柔軟性と再現性を最大限に活用するにはインベントリーが必要です。" + +#~ msgid "Action: create a basic inventory" +#~ msgstr "アクション: 基本的なインベントリーの作成" + +#~ msgid "For this basic inventory, edit (or create) ``/etc/ansible/hosts`` and add a few remote systems to it. For this example, use either IP addresses or FQDNs:" +#~ msgstr "この基本的なインベントリーでは、``/etc/ansible/hosts`` を編集 (または作成) し、リモートシステムをいくつか追加します。たとえば、IP アドレスまたは FQDN を使用します。" + +#~ msgid "Beyond the basics" +#~ msgstr "中級編" + +#~ msgid "Your inventory can store much more than IPs and FQDNs. You can create :ref:`aliases<inventory_aliases>`, set variable values for a single host with :ref:`host vars<host_variables>`, or set variable values for multiple hosts with :ref:`group vars<group_variables>`." +#~ msgstr "インベントリーには、IP や FQDN 以外にも多くの情報を保存することができます。:ref:`エイリアス<inventory_aliases>` を作成したり、:ref:`host 変数<host_variables>` で単一のホストに変数値を設定したり、:ref:`group 変数<group_variables>` で複数のホストに変数値を設定したりすることができます。" + +#~ msgid "Connecting to remote nodes" +#~ msgstr "リモートノードへの接続" + +#~ msgid "Ansible communicates with remote machines over the `SSH protocol <https://www.ssh.com/ssh/protocol/>`_. By default, Ansible uses native OpenSSH and connects to remote machines using your current user name, just as SSH does." +#~ msgstr "Ansible は `SSH プロトコル <https://www.ssh.com/ssh/protocol/>`_ でリモートマシンと通信します。デフォルトでは、Ansible はネイティブの OpenSSH を使用し、SSH と同様に現在のユーザー名を使用してリモートマシンに接続します。" + +#~ msgid "Action: check your SSH connections" +#~ msgstr "アクション: SSH 接続の確認" + +#~ msgid "Confirm that you can connect using SSH to all the nodes in your inventory using the same username. If necessary, add your public SSH key to the ``authorized_keys`` file on those systems." +#~ msgstr "インベントリー内のすべてのノードに、同じユーザー名で SSH 接続できることを確認します。必要に応じて、これらのシステムの ``authorized_keys`` ファイルに自分の公開 SSH 鍵を追加します。" + +#~ msgid "You can override the default remote user name in several ways, including:" +#~ msgstr "次のようないくつかの方法で、デフォルトのリモートユーザー名を上書きできます。" + +#~ msgid "passing the ``-u`` parameter at the command line" +#~ msgstr "コマンドラインで ``-u`` パラメーターを渡す" + +#~ msgid "setting user information in your inventory file" +#~ msgstr "インベントリーファイルにユーザー情報を設定する" + +#~ msgid "setting user information in your configuration file" +#~ msgstr "設定ファイルにユーザー情報を設定する" + +#~ msgid "setting environment variables" +#~ msgstr "追加の環境変数を設定する" + +#~ msgid "See :ref:`general_precedence_rules` for details on the (sometimes unintuitive) precedence of each method of passing user information. You can read more about connections in :ref:`connections`." +#~ msgstr "ユーザー情報を渡す各メソッドの優先順位 (意図しない場合もあります) の詳細は、「:ref:`general_precedence_rules`」を参照してください。接続については、「:ref:`connections`」を参照してください。" + +#~ msgid "Copying and executing modules" +#~ msgstr "モジュールのコピーおよび実行" + +#~ msgid "Once it has connected, Ansible transfers the modules required by your command or playbook to the remote machine(s) for execution." +#~ msgstr "接続後、Ansible はコマンドまたは Playbook が必要とするモジュールを、リモートマシンに転送して実行します。" + +#~ msgid "Action: run your first Ansible commands" +#~ msgstr "アクション: 最初の Ansible コマンドの実行" + +#~ msgid "Use the ping module to ping all the nodes in your inventory:" +#~ msgstr "ping モジュールを使用して、インベントリー内のすべてのノードに対して ping を実行します。" + +#~ msgid "You should see output for each host in your inventory, similar to this:" +#~ msgstr "次のようなインベントリー内の各ホストの出力が表示されます。" + +#~ msgid "You can use ``-u`` as one way to specify the user to connect as, by default Ansible uses SSH, which defaults to the 'current user'." +#~ msgstr "``-u`` は、接続するユーザーを指定する 1 つの方法として使用できます。デフォルトでは、Ansible は SSH を使用しますが、SSH ではデフォルトで「現在のユーザー」が指定されます。" + +#~ msgid "Now run a live command on all of your nodes:" +#~ msgstr "全ノードでライブコマンドを実行します。" + +#~ msgid "Action: Run your first playbook" +#~ msgstr "アクション: 最初の Playbook の実行" + +#~ msgid "Playbooks are used to pull together tasks into reusable units." +#~ msgstr "Playbook は、複数のタスクを再利用可能な単位にプルするために使用されます。" + +#~ msgid "Ansible does not store playbooks for you; they are simply YAML documents that you store and manage, passing them to Ansible to run as needed." +#~ msgstr "Ansible は、Playbook を保存しません。Playbook は、保存および管理する単純な YAML ドキュメントであり、必要に応じて実行するために Ansible に渡します。" + +#~ msgid "In a directory of your choice you can create your first playbook in a file called mytask.yaml:" +#~ msgstr "任意のディレクトリーでは、mytask.yaml という名前のファイルに最初の Playbook を作成できます。" + +#~ msgid "You can run this command as follows:" +#~ msgstr "このコマンドは、以下のように実行できます。" + +#~ msgid "and may see output like this:" +#~ msgstr "また、以下のような出力が表示される可能性があります。" + +#~ msgid "Read on to learn more about controlling which nodes your playbooks execute on, more sophisticated tasks, and the meaning of the output." +#~ msgstr "Playbook が実行するノード、より高度なタスク、および出力の意味を把握するには、こちらを参照してください。" + +#~ msgid "By default Ansible uses SFTP to transfer files. If the machine or device you want to manage does not support SFTP, you can switch to SCP mode in :ref:`intro_configuration`. The files are placed in a temporary directory and executed from there." +#~ msgstr "Ansible のデフォルトでは、ファイルの転送に SFTP を使用します。管理するマシンやデバイスが SFTP をサポートしていない場合は、:ref:`intro_configuration` で SCP モードに切り替えることができます。ファイルは一時ディレクトリーに置かれ、そこから実行されます。" + +#~ msgid "If you need privilege escalation (sudo and similar) to run a command, pass the ``become`` flags:" +#~ msgstr "コマンドを実行する権限昇格 (sudo など) が必要な場合は、``become`` フラグを渡します。" + +#~ msgid "You can read more about privilege escalation in :ref:`become`." +#~ msgstr "権限の昇格の詳細は、「:ref:`become`」を参照してください。" + +#~ msgid "Congratulations! You have contacted your nodes using Ansible. You used a basic inventory file and an ad hoc command to direct Ansible to connect to specific remote nodes, copy a module file there and execute it, and return output. You have a fully working infrastructure." +#~ msgstr "これで、Ansible を使用してノードに接続できました。基本的なインベントリーファイルとアドホックコマンドを使用して、Ansible が特定のリモートノードに接続し、そこにモジュールファイルをコピーして実行し、出力を返すように指示しました。これで完全に機能するインフラストラクチャーが完成しました。" + +#~ msgid "Resources" +#~ msgstr "リソース" + +#~ msgid "`Product Demos <https://github.com/ansible/product-demos>`_" +#~ msgstr "`Product Demos <https://github.com/ansible/product-demos>`_" + +#~ msgid "`Katakoda <https://katacoda.com/rhel-labs>`_" +#~ msgstr "`Katakoda <https://katacoda.com/rhel-labs>`_" + +#~ msgid "`Workshops <https://github.com/ansible/workshops>`_" +#~ msgstr "`Workshops <https://github.com/ansible/workshops>`_" + +#~ msgid "`Ansible Examples <https://github.com/ansible/ansible-examples>`_" +#~ msgstr "`Ansible Examples <https://github.com/ansible/ansible-examples>`_" + +#~ msgid "`Ansible Baseline <https://github.com/ansible/ansible-baseline>`_" +#~ msgstr "`Ansible Baseline <https://github.com/ansible/ansible-baseline>`_" + +#~ msgid "Next steps" +#~ msgstr "次のステップ" + +#~ msgid "Next you can read about more real-world cases in :ref:`intro_adhoc`, explore what you can do with different modules, or read about the Ansible :ref:`working_with_playbooks` language. Ansible is not just about running commands, it also has powerful configuration management and deployment features." +#~ msgstr "次に、:ref:`intro_adhoc` のより多くの実例を読んだり、さまざまなモジュールでできることを調べたり、Ansible :ref:`working_with_playbooks` の言語について読んだりすることができます。Ansible は、単にコマンドを実行するだけでなく、強力な構成管理機能およびデプロイ機能を備えています。" + +#~ msgid "More information about inventory" +#~ msgstr "インベントリーの詳細情報" + +#~ msgid "Learning Ansible's configuration management language" +#~ msgstr "Ansible の設定管理言語の概要" + +#~ msgid "`Ansible Demos <https://github.com/ansible/product-demos>`_" +#~ msgstr "`Ansible Demos <https://github.com/ansible/product-demos>`_" + +#~ msgid "Demonstrations of different Ansible usecases" +#~ msgstr "各種 Ansible のユースケースのデモ" + +#~ msgid "`RHEL Labs <https://katacoda.com/rhel-labs>`_" +#~ msgstr "`RHEL Labs <https://katacoda.com/rhel-labs>`_" + +#~ msgid "Labs to provide further knowledge on different topics" +#~ msgstr "さまざまなトピックでの詳細な知識を提供するラボ" + +#~ msgid "Note that due to historic behavior and custom re-implementation of some of the Jinja internals in Ansible there is an exception to the behavior. When used in a Jinja expression (for example in conjunction with operators, other filters, and so on) the return value differs, in those situations the return value is ``none``. See the two examples below:" +#~ msgstr "Ansibleの一部のJinja内部過去の動作とカスタムの再実装により、動作に例外があることに注意してください。Jinja式で（たとえば、演算子や他のフィルターなどと組み合わせて）使用すると、戻り値は異なります。そのような状況では、戻り値は ``none`` のようになります。以下の2つの例を参照してください。" + +#~ msgid "When ``jinja2_native`` setting is enabled, the ``regex_search`` filter always returns ``none`` if it cannot find a match." +#~ msgstr "``jinja2_native`` 設定を有効にすると、``regex_search`` フィルターは一致するものが見つからない場合に常に ``none`` を返します。" + +#~ msgid "Role dependencies let you automatically pull in other roles when using a role. Ansible does not execute role dependencies when you include or import a role. You must use the ``roles`` keyword if you want Ansible to execute role dependencies." +#~ msgstr "ロールの依存関係により、あるロールを使用する際に他のロールを自動的に取り込むことができます。Ansible は、ロールをインクルードまたはインポートする際にロールの依存関係を実行しません。Ansible でロールの依存関係を実行したい場合は、``roles`` キーワードを使用する必要があります。" + +#~ msgid "Ansible Quickstart Guide" +#~ msgstr "Ansible クイックスタートガイド" + +#~ msgid "We've recorded a short video that introduces Ansible." +#~ msgstr "Ansible を紹介する短い動画を作成しました。" + +#~ msgid "The `quickstart video <https://www.ansible.com/resources/videos/quick-start-video>`_ is about 13 minutes long and gives you a high level introduction to Ansible -- what it does and how to use it. We'll also tell you about other products in the Ansible ecosystem." +#~ msgstr "`クイックスタートの動画 <https://www.ansible.com/resources/videos/quick-start-video>`_ は約 13 分で、Ansible が何をするのか、どのように使用するのかなど、Ansible を高レベルで紹介しています。また、Ansible のエコシステムにおける他の製品についてもご紹介します。" + +#~ msgid "Enjoy, and be sure to visit the rest of the documentation to learn more." +#~ msgstr "動画をお楽しみください。より詳細な説明は、本ガイドをご覧ください。" + +#~ msgid "`A system administrators guide to getting started with Ansible <https://www.redhat.com/en/blog/system-administrators-guide-getting-started-ansible-fast>`_" +#~ msgstr "`A system administrators guide to getting started with Ansible <https://www.redhat.com/en/blog/system-administrators-guide-getting-started-ansible-fast>`_" + +#~ msgid "A step by step introduction to Ansible" +#~ msgstr "Ansible の概要 (ステップバイステップ)" + +#~ msgid "`Ansible Automation for SysAdmins <https://opensource.com/downloads/ansible-quickstart>`_" +#~ msgstr "`Ansible Automation for SysAdmins <https://opensource.com/downloads/ansible-quickstart>`_" + +#~ msgid "A downloadable guide for getting started with Ansible" +#~ msgstr "Ansible を使い始めるためのダウンロード可能なガイド" + +#~ msgid ":ref:`network_getting_started`" +#~ msgstr ":ref:`network_getting_started`" + +#~ msgid "A guide for network engineers using Ansible for the first time" +#~ msgstr "はじめて Ansible を使用するネットワークエンジニアのためのガイド" + +#~ msgid "Details about each component can be read below, but the script `ConfigureRemotingForAnsible.ps1 <https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1>`_ can be used to set up the basics. This script sets up both HTTP and HTTPS listeners with a self-signed certificate and enables the ``Basic`` authentication option on the service." +#~ msgstr "各コンポーネントの詳細については後述しますが、基本的な設定には `ConfigureRemotingForAnsible.ps1 <https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1>`_ スクリプトが使用できます。このスクリプトは、自己署名証明書を使用して HTTP と HTTPS の両方のリスナーを設定し、サービスで ``Basic`` 認証オプションを有効にします。" + +#~ msgid "To use this script, run the following in PowerShell:" +#~ msgstr "このスクリプトを使用するには、以下を PowerShell で実行します。" + +#~ msgid "There are different switches and parameters (like ``-EnableCredSSP`` and ``-ForceNewSSLCert``) that can be set alongside this script. The documentation for these options are located at the top of the script itself." +#~ msgstr "このスクリプトには、さまざまなスイッチやパラメーター (``-EnableCredSSP`` や ``-ForceNewSSLCert`` など) を設定することができます。これらのオプションのドキュメントは、スクリプト本体の上部にあります。" + +#~ msgid "The ConfigureRemotingForAnsible.ps1 script is intended for training and development purposes only and should not be used in a production environment, since it enables settings (like ``Basic`` authentication) that can be inherently insecure." +#~ msgstr "ConfigureRemotingForAnsible.ps1 スクリプトは、トレーニングと開発のみを目的としており、実稼働環境では使用しないでください。これは、本質的に安全でない可能性のある設定 (``Basic`` 認証など) を可能にするためです。" + |