1# SOME DESCRIPTIVE TITLE. 2# Copyright (C) Ansible project contributors. 3# This file is distributed under the same license as the Ansible package. 4# FIRST AUTHOR <EMAIL@ADDRESS>, 2021. 5# 6msgid "" 7msgstr "" 8"Project-Id-Version: Ansible devel\n" 9"Report-Msgid-Bugs-To: \n" 10"POT-Creation-Date: 2021-07-12 10:48+0200\n" 11"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" 12"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n" 13"Language-Team: LANGUAGE <LL@li.org>\n" 14"MIME-Version: 1.0\n" 15"Content-Type: text/plain; charset=utf-8\n" 16"Content-Transfer-Encoding: 8bit\n" 17"Generated-By: Babel 2.9.0\n" 18 19#: ../../rst/user_guide/basic_concepts.rst:5 20msgid "Ansible concepts" 21msgstr "Ansible の概念" 22 23#: ../../rst/user_guide/basic_concepts.rst:7 24msgid "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." 25msgstr "この概念は、Ansible のすべての用途に共通しています。あらゆる種類の自動化のために Ansible を使用するには、これらを理解する必要があります。この基本的な紹介は、本ガイドの内容を理解するのに必要な背景を説明します。" 26 27#: ../../rst/shared_snippets/basic_concepts.txt:2 28msgid "Control node" 29msgstr "コントロールノード" 30 31#: ../../rst/shared_snippets/basic_concepts.txt:4 32msgid "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." 33msgstr "Ansible がインストールされているマシン。任意のコントロールノードから ``ansible`` コマンドまたは ``ansible-playbook`` コマンドを呼び出すことで、Ansible コマンドおよび Playbook を実行できます。Python がインストールされているコンピューターであれば、ラップトップ、共有ディスクトップ、サーバーなど、どのコンピューターでも Ansible を実行することができます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを持つことができます。" 34 35#: ../../rst/shared_snippets/basic_concepts.txt:7 36msgid "Managed nodes" 37msgstr "管理ノード" 38 39#: ../../rst/shared_snippets/basic_concepts.txt:9 40msgid "The network devices (and/or servers) you manage with Ansible. Managed nodes are also sometimes called \"hosts\". Ansible is not installed on managed nodes." 41msgstr "Ansible で管理するネットワークデバイス (またはサーバー)。管理ノードは「ホスト」と呼ばれることもあります。Ansible は管理ノードにインストールされません。" 42 43#: ../../rst/shared_snippets/basic_concepts.txt:12 44msgid "Inventory" 45msgstr "インベントリー" 46 47#: ../../rst/shared_snippets/basic_concepts.txt:14 48msgid "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." 49msgstr "管理ノードの一覧。インベントリーファイルは「ホストファイル」と呼ばれることもあります。インベントリーは、各管理ノードに対して IP アドレスなどの情報を指定できます。インベントリーは管理ノードを整理でき、スケーリングが容易になるグループの作成やネスト化が可能です。インベントリーの詳細は「:ref:`インベントリーでの作業 <intro_inventory>`」セクションを参照してください。" 50 51#: ../../rst/shared_snippets/basic_concepts.txt:17 52msgid "Collections" 53msgstr "コレクション" 54 55#: ../../rst/shared_snippets/basic_concepts.txt:19 56msgid "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`." 57msgstr "コレクションは、Playbook、ロール、モジュール、プラグインを含む Ansible コンテンツのディストリビューション形式です。`Ansible Galaxy <https://galaxy.ansible.com>`_ でコレクションをインストールして使用することができます。コレクションの詳細は、「:ref:`collections`」を参照してください。" 58 59#: ../../rst/shared_snippets/basic_concepts.txt:22 60msgid "Modules" 61msgstr "モジュール" 62 63#: ../../rst/shared_snippets/basic_concepts.txt:24 64msgid "The units of code Ansible executes. 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. Starting in Ansible 2.10, modules are grouped in collections. For an idea of how many collections Ansible includes, take a look at the :ref:`list_of_collections`." 65msgstr "Ansible が実行するコードの単位。各モジュールは、特定タイプのデータベースのユーザーを管理したり、特定タイプのネットワークデバイスの VLAN インターフェースを管理するなど、特定の用途に使用されます。タスクで 1 つのモジュールを起動したり、Playbook で複数のモジュールを起動したりすることができます。Ansible 2.10 以降、モジュールはコレクションとしてまとめられています。Ansible に含まれるコレクションの数は、「:ref:`list_of_collections`」を参照してください。" 66 67#: ../../rst/shared_snippets/basic_concepts.txt:27 68msgid "Tasks" 69msgstr "タスク" 70 71#: ../../rst/shared_snippets/basic_concepts.txt:29 72msgid "The units of action in Ansible. You can execute a single task once with an ad hoc command." 73msgstr "Ansible でのアクションの単位。アドホックコマンドを使用すると、単一のタスクを実行できます。" 74 75#: ../../rst/shared_snippets/basic_concepts.txt:32 76msgid "Playbooks" 77msgstr "Playbook" 78 79#: ../../rst/shared_snippets/basic_concepts.txt:34 80msgid "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`." 81msgstr "順番に並べられたタスクの一覧は保存されているため、その順番でタスクを繰り返し実行することができます。Playbook には、タスクだけでなく、変数も含めることができます。Playbook は YAML で記述されているため、読みやすく、書きやすく、共有しやすく、理解しやすい特徴があります。Playbook の詳細は、「:ref:`about_playbooks`」を参照してください。" 82 83#: ../../rst/user_guide/become.rst:5 84msgid "Understanding privilege escalation: become" 85msgstr "権限昇格の理解: become" 86 87#: ../../rst/user_guide/become.rst:7 88msgid "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 leverages existing privilege escalation tools like `sudo`, `su`, `pfexec`, `doas`, `pbrun`, `dzdo`, `ksu`, `runas`, `machinectl` and others." 89msgstr "Ansible は既存の権限昇格システムを使用して、root 権限または別のユーザーのパーミッションでタスクを実行します。この機能を使用すると、このマシンにログインしたユーザー (リモートユーザー) とは別のユーザー「になる (become)」ことができるため、この機能は ``become`` と呼ばれています。``become`` キーワードは、`sudo`、`su`、`pfexec`、`doas`、`pbrun`、`dzdo`、`ksu`、`runas`、`machinectl` などの既存の特権昇格ツールを活用します。" 90 91#: ../../rst/user_guide/become.rst:13 92msgid "Using become" 93msgstr "become の使用" 94 95#: ../../rst/user_guide/become.rst:15 96msgid "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." 97msgstr "play ディレクティブまたは task ディレクティブ、接続変数、またはコマンドラインでの ``become`` の使用を制御できます。複数の方法で権限昇格プロパティーを設定する場合は、:ref:`一般的な優先順位ルール<general_precedence_rules>` を確認し、使用する設定を確認します。" 98 99#: ../../rst/user_guide/become.rst:17 100msgid "A full list of all become plugins that are included in Ansible can be found in the :ref:`become_plugin_list`." 101msgstr "Ansible に含まれる全 become プラグインの完全リストは、:ref:`become_plugin_list` にあります。" 102 103#: ../../rst/user_guide/become.rst:20 104msgid "Become directives" 105msgstr "Become ディレクティブ" 106 107#: ../../rst/user_guide/become.rst:22 108msgid "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``." 109msgstr "プレイまたはタスクレベルで、``become`` を制御するディレクティブを設定できます。多くの場合は、ホストごとに異なる接続変数を設定することで、これらをオーバーライドできます。これらの変数とディレクティブは独立しています。たとえば、``become_user`` に設定しても ``become`` に設定されません。" 110 111#: ../../rst/user_guide/become.rst:25 112msgid "become" 113msgstr "become" 114 115#: ../../rst/user_guide/become.rst:25 116msgid "set to ``yes`` to activate privilege escalation." 117msgstr "権限昇格をアクティブにするには、``yes`` に設定します。" 118 119#: ../../rst/user_guide/become.rst:28 120msgid "become_user" 121msgstr "become_user" 122 123#: ../../rst/user_guide/become.rst:28 124msgid "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``." 125msgstr "希望する権限を持つユーザーに設定します。ログインしたユーザーではなく、`become` を行ったユーザーになります。ホストレベルで設定できるようにする ``become: yes`` を意味するものではありません。デフォルト値は ``root`` です。" 126 127#: ../../rst/user_guide/become.rst:31 128msgid "become_method" 129msgstr "become_method" 130 131#: ../../rst/user_guide/become.rst:31 132msgid "(at play or task level) overrides the default method set in ansible.cfg, set to use any of the :ref:`become_plugins`." 133msgstr "(play レベルまたは task レベルで)、ansible.cfg に設定されたデフォルトのメソッドをオーバーライドし、:ref:`become_plugins` を使用するよう設定します。" 134 135#: ../../rst/user_guide/become.rst:34 136msgid "become_flags" 137msgstr "become_flags" 138 139#: ../../rst/user_guide/become.rst:34 140msgid "(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." 141msgstr "(play レベルまたは task レベルで) タスクまたはロールに特定のフラグの使用を許可します。一般的な使い方としては、シェルが nologin に設定されているときに、ユーザーを nobody に変更するのが一般的な方法です。Ansible 2.2 で追加されました。" 142 143#: ../../rst/user_guide/become.rst:36 144msgid "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``):" 145msgstr "たとえば、``root`` 以外のユーザーとして接続する際にシステムサービスを管理する (``root`` 権限が必要) には、``become_user`` (``root``) のデフォルト値を使用できます。" 146 147#: ../../rst/user_guide/become.rst:46 148msgid "To run a command as the ``apache`` user:" 149msgstr "``apache`` ユーザーとしてコマンドを実行するには、次を実行します。" 150 151#: ../../rst/user_guide/become.rst:55 152msgid "To do something as the ``nobody`` user when the shell is nologin:" 153msgstr "シェルが nologin の場合に ``nobody`` ユーザーとして操作を行う場合は、次を実行します。" 154 155#: ../../rst/user_guide/become.rst:66 156msgid "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." 157msgstr "sudo のパスワードを指定するには、``ansible-playbook`` を ``--ask-become-pass`` (略して ``-K``) と一緒に実行します。``become`` を使用して Playbook を実行し、Playbook がハングしているように見える場合は、ほとんどの場合、特権昇格のプロンプトで止まっています。`CTRL-c` で停止させてから、``-K`` と適切なパスワードで Playbook を実行してください。" 158 159#: ../../rst/user_guide/become.rst:70 160msgid "Become connection variables" 161msgstr "Become 接続変数" 162 163#: ../../rst/user_guide/become.rst:72 164msgid "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." 165msgstr "管理対象ノードまたはグループごとに異なる ``become`` オプションを定義できます。これらの変数はインベントリーで定義するか、通常の変数として使用できます。" 166 167#: ../../rst/user_guide/become.rst:75 168#: ../../rst/user_guide/intro_inventory.rst:573 169#: ../../rst/user_guide/intro_inventory.rst:648 170msgid "ansible_become" 171msgstr "ansible_become" 172 173#: ../../rst/user_guide/become.rst:75 174msgid "overrides the ``become`` directive, decides if privilege escalation is used or not." 175msgstr "``become`` ディレクティブを上書きします。権限のエスカレーションが使用されるかどうかを指定します。" 176 177#: ../../rst/user_guide/become.rst:78 178#: ../../rst/user_guide/intro_inventory.rst:575 179msgid "ansible_become_method" 180msgstr "ansible_become_method" 181 182#: ../../rst/user_guide/become.rst:78 183msgid "which privilege escalation method should be used" 184msgstr "使用する権限昇格方法です。" 185 186#: ../../rst/user_guide/become.rst:81 187#: ../../rst/user_guide/intro_inventory.rst:577 188msgid "ansible_become_user" 189msgstr "ansible_become_user" 190 191#: ../../rst/user_guide/become.rst:81 192msgid "set the user you become through privilege escalation; does not imply ``ansible_become: yes``" 193msgstr "権限昇格で become を行うユーザーを設定します。``ansible_become: yes`` を意味するものではありません。" 194 195#: ../../rst/user_guide/become.rst:84 196#: ../../rst/user_guide/intro_inventory.rst:579 197msgid "ansible_become_password" 198msgstr "ansible_become_password" 199 200#: ../../rst/user_guide/become.rst:84 201msgid "set the privilege escalation password. See :ref:`playbooks_vault` for details on how to avoid having secrets in plain text" 202msgstr "権限昇格パスワードを設定します。平文での秘密の使用を回避する方法は、「:ref:`playbooks_vault`」を参照してください。" 203 204#: ../../rst/user_guide/become.rst:87 205msgid "ansible_common_remote_group" 206msgstr "ansible_common_remote_group" 207 208#: ../../rst/user_guide/become.rst:87 209msgid "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." 210msgstr "``setfacl`` と ``chown`` の両方が失敗した場合に、Ansible が一時ファイルをグループに ``chgrp`` しようとするかどうかを決定します。詳細は「`非特権ユーザーになるリスク`_」を参照してください。バージョン 2.10 で追加されました。" 211 212#: ../../rst/user_guide/become.rst:89 213msgid "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:" 214msgstr "たとえば、すべてのタスクを ``webserver`` という名前のサーバーで ``root`` として実行することを望み、``manager`` ユーザーとしてのみ接続できる場合は、以下のようなインベントリーエントリーを使用できます。" 215 216#: ../../rst/user_guide/become.rst:96 217msgid "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`." 218msgstr "上記の変数はすべての become プラグインに汎用的なものですが、代わりにプラグイン固有の変数を設定することもできます。そのプラグインが持つすべてのオプションとその定義方法の一覧は、各プラグインのドキュメントを参照してください。Ansible における become プラグインの完全なリストは :ref:`become_plugins` を参照してください。" 219 220#: ../../rst/user_guide/become.rst:101 221msgid "Become command-line options" 222msgstr "Become コマンドラインオプション" 223 224#: ../../rst/user_guide/become.rst:104 225msgid "ask for privilege escalation password; does not imply become will be used. Note that this password will be used for all hosts." 226msgstr "権限昇格パスワードを要求します。これは。必ずしも become が使用されるとは限りません。このパスワードはすべてのホストで使用されることに注意してください。" 227 228#: ../../rst/user_guide/become.rst:107 229msgid "run operations with become (no password implied)" 230msgstr "become で操作を実行します (パスワードがないことを示しています)。" 231 232#: ../../rst/user_guide/become.rst:110 233msgid "privilege escalation method to use (default=sudo), valid choices: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ]" 234msgstr "使用する特権昇格方法 (デフォルトは sudo)。有効な選択肢は、[ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ] となります。" 235 236#: ../../rst/user_guide/become.rst:114 237msgid "run operations as this user (default=root), does not imply --become/-b" 238msgstr "このユーザー (デフォルトは root) として操作を実行します。--become/-b を意味するものではありません。" 239 240#: ../../rst/user_guide/become.rst:117 241msgid "Risks and limitations of become" 242msgstr "become のリスクおよび制限" 243 244#: ../../rst/user_guide/become.rst:119 245msgid "Although privilege escalation is mostly intuitive, there are a few limitations on how it works. Users should be aware of these to avoid surprises." 246msgstr "特権の昇格はほとんど直感的ですが、それがどのように機能するかについては、いくつかの制限があります。問題が発生しないように、これらの点に注意する必要があります。" 247 248#: ../../rst/user_guide/become.rst:123 249msgid "Risks of becoming an unprivileged user" 250msgstr "非特権ユーザーになる (become) リスク" 251 252#: ../../rst/user_guide/become.rst:125 253msgid "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." 254msgstr "Ansible モジュールは、まずモジュールファイルにパラメーターを代入し、次にそのファイルをリモートマシンにコピーし、最後にそこで実行することで、リモートマシン上で実行されます。" 255 256#: ../../rst/user_guide/become.rst:129 257msgid "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." 258msgstr "モジュールファイルが ``become`` を使用せずに、``become_user`` が root の場合や、リモートマシンへの接続が root として行われる場合、すべてのことは問題ありません。このような場合、Ansible は、ユーザーおよび root による読み取りのみを許可するパーミッション、または切り替え先の非特権ユーザーの読み取りのみを許可するパーミッションを持つモジュールファイルを作成します。" 259 260#: ../../rst/user_guide/become.rst:135 261msgid "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:" 262msgstr "ただし、接続ユーザーと ``become_user`` の両方が特権を持たない場合、モジュールファイルは Ansible が接続するユーザー (``remote_user``) として記述されますが、Ansible が ``become`` に設定されているユーザーがファイルを読み取れる必要があります。Ansible がこれをプラットフォーム別に解決する方法の詳細は次のとおりですが、POSIX システムでは、Ansible がこの問題を解決します。" 263 264#: ../../rst/user_guide/become.rst:141 265msgid "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." 266msgstr "まず、リモート ``PATH`` に :command:`setfacl` がインストールされ、利用可能な場合は、リモートホストの一時ディレクトリーが POSIX.1e ファイルシステム ACL サポートでマウントされている場合、Ansible は POSIX ACL を使用して 2 つの非特権ユーザーとモジュールファイルを共有します。" 267 268#: ../../rst/user_guide/become.rst:146 269msgid "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." 270msgstr "次に、POSIX ACL が利用 **できない** か、:command:`setfacl` を実行できない場合、Ansible は、特権のないユーザーとして対応するシステムの :command:`chown` を使用してモジュールファイルの所有権を変更しようとします。" 271 272#: ../../rst/user_guide/become.rst:150 273msgid "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." 274msgstr "Ansible 2.11 の新機能として、Ansible は、ファイルに ACL を設定する際に macOS 固有の方法で :command:`chmod +a` を試行します。" 275 276#: ../../rst/user_guide/become.rst:153 277msgid "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``." 278msgstr "Ansible 2.10 の新機能で、上記のすべてが失敗すると、Ansible は構成設定 ``ansible_common_remote_group`` の値を確認します。多くのシステムでは、特定のユーザーが、ファイルのグループ所有権を、所属するグループに変更できます。その結果、2 番目の非特権ユーザー (``become_user``) に、Ansible が (``remote_user``として) 接続するユーザーに共通する UNIX グループがあり、``ansible_common_remote_group`` がそのグループとして定義されている場合は、 :command:`chgrp` を使用してモジュールファイルのグループ所有権をそのグループに変更しようとすることができます。したがって、``become_user`` が読みるようになる可能性があります。" 279 280#: ../../rst/user_guide/become.rst:163 281msgid "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." 282msgstr "この時点で、``ansible_common_remote_group`` が定義され、 :command:`chgrp` が試行されて正常に返された場合、Ansible は新しいグループの所有権で十分であると仮定し (ただし、重要なことですが、確認はしません)、それ以上はフォールバックしません。つまり、``become_user`` が実際に ``remote_user`` とグループを共有しているかどうかは **確認しません**。コマンドが正常に終了する限り、Ansible はその結果を成功とみなし、以下の ``allow_world_readable_tmpfiles`` のチェックには進みません。" 283 284#: ../../rst/user_guide/become.rst:171 285msgid "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.**" 286msgstr "``ansible_common_remote_group`` が **設定されておらず**、そこでの chown が失敗した場合、または ``ansible_common_remote_group`` *が* 設定されているが :command:`chgrp` (またはそれに続くグループパーミッションの :command:`chmod`) が成功しない終了コードを返した場合、Ansible は最後に ``allow_world_readable_tmpfiles`` の値を確認します。この値が設定されていると、Ansible はモジュールファイルを誰もが読める一時ディレクトリーに置き、``become_user`` (およびシステム上の他のユーザー) がファイルの内容を読めるように、誰もが読み取り可能なパーミッションを設定します。**モジュールに渡されるパラメーターに機密性があり、リモートマシンを信用していない場合、これは潜在的なセキュリティーリスクとなります。**" 287 288#: ../../rst/user_guide/become.rst:182 289msgid "Once the module is done executing, Ansible deletes the temporary file." 290msgstr "モジュールの実行が完了すると、Ansible は一時ファイルを削除します。" 291 292#: ../../rst/user_guide/become.rst:184 293msgid "Several ways exist to avoid the above logic flow entirely:" 294msgstr "上記のロジックフローを完全に回避する方法はいくつかあります。" 295 296#: ../../rst/user_guide/become.rst:186 297msgid "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." 298msgstr "`pipelining` を使用します。パイプラインを有効にすると、Ansible はモジュールをクライアント上の一時ファイルに保存しません。代わりに、モジュールをリモートの python インタープリターの標準入力にパイプします。パイプラインは、ファイル転送を伴う python モジュール (例: :ref:`copy <copy_module>`、:ref:`fetch <fetch_module>`、:ref:`template <template_module>`) や、python 以外のモジュールでは機能しません。" 299 300#: ../../rst/user_guide/become.rst:192 301msgid "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." 302msgstr "非特権ユーザーは使用しないでください。root に ``become`` した場合、または ``become`` を使用しない場合は、UNIX ファイルの権限で保護されます。Ansible 2.1 以降では、UNIX ファイルのパーミッションは、root として管理マシンに接続し、権限のないアカウントにアクセスするには、``become`` を使用しても保護されます。" 303 304#: ../../rst/user_guide/become.rst:198 305msgid "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." 306msgstr "Solaris ZFS ファイルシステムにはファイルシステム ACL がありますが、ACL は POSIX.1e ファイルシステムの acl ではありません (正しくは NFSv4 ACL)。Ansible はこれらの ACL を使用してその一時ファイルのパーミッションを管理できないため、リモートマシンが ZFS を使用している場合は ``allow_world_readable_tmpfiles`` を再処理しないといけない場合があります。" 307 308#: ../../rst/user_guide/become.rst:205 309msgid "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." 310msgstr "Ansible では、知らずに ``become`` を安全でない状態で使用することは困難です。Ansible 2.1 以降、Ansible は ``become`` で安全に実行できない場合は、デフォルトでエラーを発行するようになっています。パイプラインや POSIX ACL を使用できず、非特権ユーザーとして接続しなければならず、``become`` を使用して別の非特権ユーザーとして実行しなければならず、管理対象のノードが、そこで実行したいモジュールが誰でも読むことができる程度に安全であると判断した場合は、:file:`ansible.cfg` ファイルで ``allow_world_readable_tmpfiles`` を有効にすることができます。``allow_world_readable_tmpfiles`` を設定すると、これがエラーから警告に変わり、2.1 以前のようにタスクを実行できるようになります。" 311 312#: ../../rst/user_guide/become.rst:217 313msgid "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." 314msgstr "Ansible 2.10 では、上記の ``ansible_common_remote_group`` フォールバックが導入されました。上記のように、有効になっていると、``remote_user`` と ``become_user`` の両方が非特権ユーザーである場合に使用されます。このフォールバックが発生するときの詳細は、上記のテキストを参照してください。" 315 316#: ../../rst/user_guide/become.rst:222 317msgid "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." 318msgstr "上記のように、``ansible_common_remote_group`` と ``allow_world_readable_tmpfiles`` の両方が有効になると、誰でも読み取り可能なフォールバックがトリガーされず、Ansible がまだモジュールファイルにアクセスできない可能性があります。これは、グループの所有権変更が成功した後に、Ansible はこれ以上フォールバックせず、``become_user`` が実際には「共通グループ」のメンバーであることを確認するためのチェックが行われないためですこれは、このようなチェックを行うと、リモートマシンへの別のラウンドトリップ接続が必要になり、時間のかかる操作になってしまうことを考慮した設計上の決定です。しかし、Ansible はこの場合、警告を発します。" 319 320#: ../../rst/user_guide/become.rst:234 321msgid "Not supported by all connection plugins" 322msgstr "すべての接続プラグインでサポートされない" 323 324#: ../../rst/user_guide/become.rst:236 325msgid "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)." 326msgstr "特権昇格の方法は、使用する接続プラグインがサポートしている必要があります。ほとんどの接続プラグインは、become をサポートしていないと警告を表示します。一部の接続プラグインでは、常に root として実行されるため (jail、chroot など)、無視されます。" 327 328#: ../../rst/user_guide/become.rst:241 329msgid "Only one method may be enabled per host" 330msgstr "ホストごとに有効にできる方法は 1 つだけ" 331 332#: ../../rst/user_guide/become.rst:243 333msgid "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)." 334msgstr "メソッドを連鎖させることはできません。``sudo /bin/su -`` を使用してユーザーになる (become) ことはできません。そのユーザーとして sudo でコマンドを実行するか、直接 su できるような権限が必要です (pbrun、pfexec、その他のサポートされている方法も同様です)。" 335 336#: ../../rst/user_guide/become.rst:248 337msgid "Privilege escalation must be general" 338msgstr "特権昇格は一般的なものにすること" 339 340#: ../../rst/user_guide/become.rst:250 341msgid "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 :ref:`ansible_tower` to manage indirect access to SSH credentials." 342msgstr "特権昇格の許可を特定のコマンドに限定することはできません。Ansible は常に特定のコマンドを使用して何かを行うわけではなく、毎回変更される一時ファイル名からモジュール (コード) を実行します。許可されるコマンドとして「/sbin/service」や「/bin/chmod」を指定した場合、これらのパスは Ansible がモジュールを実行するために作成する一時ファイルと一致しないため、Ansible では失敗します。sudo/pbrun/doas 環境で特定のコマンドパスしか実行できないようなセキュリティールールがある場合は、この制約を受けない特別なアカウントで Ansible を使用するか、:ref:`ansible_tower` を使用して SSH 認証情報への間接的なアクセスを管理してください。" 343 344#: ../../rst/user_guide/become.rst:261 345msgid "May not access environment variables populated by pamd_systemd" 346msgstr "pamd_systemd が設定する環境変数にアクセスできない場合" 347 348#: ../../rst/user_guide/become.rst:263 349msgid "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." 350msgstr "``systemd`` を init として使用しているほとんどの Linux ディストリビューションでは、``become`` が使用するデフォルトの方法では、systemd の意味での新しい「セッション」を開くことができません。``pam_systemd`` モジュールは新しいセッションを完全には初期化しないため、ssh で開いた通常のセッションと比べて驚くことがあるかもしれません。``pam_systemd`` によって設定されたいくつかの環境変数、特に ``XDG_RUNTIME_DIR`` は新しいユーザーには設定されず、代わりに継承されたり、単に空になったりします。" 351 352#: ../../rst/user_guide/become.rst:271 353msgid "This might cause trouble when trying to invoke systemd commands that depend on ``XDG_RUNTIME_DIR`` to access the bus:" 354msgstr "このため、バスへのアクセスを ``XDG_RUNTIME_DIR`` に依存する systemd コマンドを呼び出す際に問題が発生する可能性があります。" 355 356#: ../../rst/user_guide/become.rst:281 357msgid "To force ``become`` to open a new systemd session that goes through ``pam_systemd``, you can use ``become_method: machinectl``." 358msgstr "``become`` に、``pam_systemd`` を通して新しい systemd セッションを開くために、``become_method: machinectl`` を使用することができます。" 359 360#: ../../rst/user_guide/become.rst:284 361msgid "For more information, see `this systemd issue <https://github.com/systemd/systemd/issues/825#issuecomment-127917622>`_." 362msgstr "詳細情報は、「`this systemd issue <https://github.com/systemd/systemd/issues/825#issuecomment-127917622>`_」を参照してください。" 363 364#: ../../rst/user_guide/become.rst:290 365msgid "Become and network automation" 366msgstr "become およびネットワーク自動化" 367 368#: ../../rst/user_guide/become.rst:292 369msgid "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." 370msgstr "バージョン 2.6 以降、Ansible は、``enable`` モードをサポートするすべての Ansible が保守するネットワークプラットフォームにおいて、特権昇格 (``enable`` モードまたは特権 EXEC モードへの移行) のために ``become`` をサポートしています。``become`` を使用すると、``provider`` ディクショナリーの ``authorize`` オプションおよび ``auth_pass``のオプションが置き換えられます。" 371 372#: ../../rst/user_guide/become.rst:294 373msgid "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." 374msgstr "ネットワークデバイスの特権昇格に ``become`` を使用するには、接続タイプを ``connection: ansible.netcommon.network_cli`` または ``connection: ansible.netcommon.httpapi`` のいずれかに設定する必要があります。詳細については、「:ref:`platform_options`」を確認してください。" 375 376#: ../../rst/user_guide/become.rst:296 377msgid "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." 378msgstr "昇格した権限は、それを必要とする特定のタスクのみ、プレイ全体でのみ、またはすべてのプレイで使用することができます。``become: yes`` と ``become_method: enable`` を追加すると、これらのパラメーターが設定されているタスク、プレイ、または Playbook を実行する前に、``enable`` モードに入るよう Ansible に指示します。" 379 380#: ../../rst/user_guide/become.rst:298 381msgid "If you see this error message, the task that generated it requires ``enable`` mode to succeed:" 382msgstr "このエラーメッセージが表示された場合に、エラーメッセージを生成したタスクを成功させるには、``enable`` モードが必要になります。" 383 384#: ../../rst/user_guide/become.rst:304 385msgid "To set ``enable`` mode for a specific task, add ``become`` at the task level:" 386msgstr "特定のタスクに ``enable`` モードを設定するには、タスクレベルで ``become`` を追加します。" 387 388#: ../../rst/user_guide/become.rst:315 389msgid "To set enable mode for all tasks in a single play, add ``become`` at the play level:" 390msgstr "1 つのプレイのすべてのタスクに enable モードを設定するには、プレイレベルに ``become`` を追加します。" 391 392#: ../../rst/user_guide/become.rst:329 393msgid "Setting enable mode for all tasks" 394msgstr "すべてのタスクに enable モードの設定" 395 396#: ../../rst/user_guide/become.rst:331 397msgid "Often you wish for all tasks in all plays to run using privilege mode, that is best achieved by using ``group_vars``:" 398msgstr "すべてのプレイのすべてのタスクを特権モードで実行させたいと思うことがよくありますが、そのような場合には、``group_vars`` を使用することが最適です。" 399 400#: ../../rst/user_guide/become.rst:333 401msgid "**group_vars/eos.yml**" 402msgstr "**group_vars/eos.yml**" 403 404#: ../../rst/user_guide/become.rst:344 405msgid "Passwords for enable mode" 406msgstr "enable モードのパスワード" 407 408#: ../../rst/user_guide/become.rst:346 409msgid "If you need a password to enter ``enable`` mode, you can specify it in one of two ways:" 410msgstr "``enable`` モードに入るパスワードが必要な場合は、以下のいずれかの方法で指定できます。" 411 412#: ../../rst/user_guide/become.rst:348 413msgid "providing the :option:`--ask-become-pass <ansible-playbook --ask-become-pass>` command line option" 414msgstr ":option:`--ask-become-pass <ansible-playbook --ask-become-pass>` コマンドラインオプションの指定" 415 416#: ../../rst/user_guide/become.rst:349 417msgid "setting the ``ansible_become_password`` connection variable" 418msgstr "``ansible_become_password`` 接続変数の設定" 419 420#: ../../rst/user_guide/become.rst:353 421msgid "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`." 422msgstr "通知パスワードは平文で保存しないでください。Ansible Vault でパスワードやその他の秘密を暗号化する方法は、「:ref:`vault`」を参照してください。" 423 424#: ../../rst/user_guide/become.rst:356 425msgid "authorize and auth_pass" 426msgstr "authorize および auth_pass" 427 428#: ../../rst/user_guide/become.rst:358 429msgid "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``:" 430msgstr "Ansible では、従来のネットワークの Playbook について、``connection: local`` を使用した ``enable`` モードを引き続きサポートしています。``connection: local`` で ``enable`` モードに入るには、モジュールオプション ``authorize`` および ``auth_pass`` を使用します。" 431 432#: ../../rst/user_guide/become.rst:373 433msgid "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." 434msgstr "ネットワークデバイスの ``enable`` モードに ``become`` を一貫して使用するように Playbook を更新することが推奨されます。``authorize`` および ``provider`` ディクショナリーの使用は、今後は推奨されません。詳細は、「:ref:`platform_options`」および「:ref:`network_modules`」のドキュメントを参照してください。" 435 436#: ../../rst/user_guide/become.rst:378 437msgid "Become and Windows" 438msgstr "Become および Windows" 439 440#: ../../rst/user_guide/become.rst:380 441msgid "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." 442msgstr "Ansible 2.3 以降、``become`` は ``runas`` メソッドを通じて Windows ホストでも使用できるようになりました。Windows 上の Become は、非 Windows ホスト上の ``become`` と同じインベントリー設定と起動引数を使用するため、設定と変数名はこのドキュメントで定義されているものと同じになります。" 443 444#: ../../rst/user_guide/become.rst:385 445msgid "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." 446msgstr "``become`` は、別のユーザーの ID を装うために使用することができますが、Windows ホストではそれ以外にも使用方法があります。重要な用途の 1 つは、ネットワーク委譲の制約や、WUA API のような禁止されたシステムコールへのアクセスなど、WinRM 上で実行する際に課される制限の一部を回避することです。``become`` を ``ansible_user`` と同じユーザーで使用すると、これらの制限を回避して、WinRM セッションでは通常アクセスできないコマンドを実行することができます。" 447 448#: ../../rst/user_guide/become.rst:393 449msgid "Administrative rights" 450msgstr "管理者権限" 451 452#: ../../rst/user_guide/become.rst:395 453msgid "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 remote user. If it fails to elevate the user token, it will continue to use the limited token during execution." 454msgstr "Windows の多くのタスクを完了するには、管理者権限が必要です。``runas`` の become メソッドを使用すると、Ansible はリモートユーザーが使用できる全権限でモジュールの実行を試みます。ユーザートークンの昇格に失敗すると、実行中に制限されたトークンを引き続き使用します。" 455 456#: ../../rst/user_guide/become.rst:400 457msgid "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." 458msgstr "ユーザーは、昇格された権限で become プロセスを実行するには、``SeDebugPrivilege`` が必要です。この権限はデフォルトで管理者に割り当てられます。デバッグ権限が利用できない場合、become プロセスは、限られた一連の特権およびグループで実行されます。" 459 460#: ../../rst/user_guide/become.rst:405 461msgid "To determine the type of token that Ansible was able to get, run the following task:" 462msgstr "Ansible が取得できたトークンの種類を確認するには、以下のタスクを実行します。" 463 464#: ../../rst/user_guide/become.rst:414 465msgid "The output will look something similar to the below:" 466msgstr "出力は以下のようになります。" 467 468#: ../../rst/user_guide/become.rst:502 469msgid "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:" 470msgstr "``label`` キーにおいて、``account_name`` エントリーは、ユーザーに管理権限があるかどうかを判断します。ここでは、返すことができるラベルと、そのラベルが表す内容を紹介します。" 471 472#: ../../rst/user_guide/become.rst:506 473msgid "``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." 474msgstr "``Medium``: Ansible が昇格したトークンの取得に失敗し、制限付きのトークンで実行されました。モジュールの実行中に、ユーザーに割り当てられた特権のサブセットのみが利用可能で、ユーザーは管理者権限を持っていません。" 475 476#: ../../rst/user_guide/become.rst:510 477msgid "``High``: An elevated token was used and all the privileges assigned to the user are available during the module execution." 478msgstr "``High``: 昇格されたトークンが使用され、ユーザーに割り当てられたすべての特権は、モジュールの実行時に利用できます。" 479 480#: ../../rst/user_guide/become.rst:513 481msgid "``System``: The ``NT AUTHORITY\\System`` account is used and has the highest level of privileges available." 482msgstr "``System``: ``NT AUTHORITY\\System`` アカウントが使用され、利用可能な最高レベルの特権が付与されます。" 483 484#: ../../rst/user_guide/become.rst:516 485msgid "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." 486msgstr "出力には、ユーザーに付与される権限の一覧が表示されます。権限の値が ``disabled`` の場合、特権はログオントークンに割り当てられますが、有効になっていません。ほとんどのシナリオでは、これらの特権は必要に応じて自動的に有効になります。" 487 488#: ../../rst/user_guide/become.rst:521 489msgid "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:" 490msgstr "Ansible のバージョンが 2.5 よりも古い場合や、通常の ``runas`` のエスカレーションプロセスが失敗した場合は、昇格したトークンを以下の方法で取得できます。" 491 492#: ../../rst/user_guide/become.rst:524 493msgid "Set the ``become_user`` to ``System`` which has full control over the operating system." 494msgstr "``become_user`` を、オペレーティングシステムを完全にコントロールする ``System`` に設定します。" 495 496#: ../../rst/user_guide/become.rst:527 497msgid "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:" 498msgstr "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 ホストでこの特権を設定できます。" 499 500#: ../../rst/user_guide/become.rst:543 501msgid "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:" 502msgstr "そのユーザーになる (become) 前に、ホストで UAC をオフにし、再起動します。UAC は、``least privilege`` プリンシパルでアカウントを実行するように設計されたセキュリティープロトコルです。以下のタスクを実行して UAC をオフにすることができます。" 503 504#: ../../rst/user_guide/become.rst:563 505msgid "Granting the ``SeTcbPrivilege`` or turning UAC off can cause Windows security vulnerabilities and care should be given if these steps are taken." 506msgstr "``SeTcbPrivilege`` を付与するか UAC をオフにすると、Windows のセキュリティー上の脆弱性を引き起こす可能性があるため、このような手順を実行する場合は注意が必要です。" 507 508#: ../../rst/user_guide/become.rst:567 509msgid "Local service accounts" 510msgstr "ローカルサービスアカウント" 511 512#: ../../rst/user_guide/become.rst:569 513msgid "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:" 514msgstr "Ansible バージョン 2.5 より前のバージョンでは、``become`` は、Windows でローカルまたはドメインのユーザーアカウントでのみ動作していました。``System`` や ``NetworkService`` などのローカルサービスアカウントは、これらの旧バージョンでは ``become_user`` として使用できません。この制限は、Ansible 2.5 のリリース以降は解除されました。``become_user`` に設定できる 3 つのサービスアカウントは以下のとおりです。" 515 516#: ../../rst/user_guide/become.rst:575 517msgid "System" 518msgstr "システム" 519 520#: ../../rst/user_guide/become.rst:576 521msgid "NetworkService" 522msgstr "NetworkService" 523 524#: ../../rst/user_guide/become.rst:577 525msgid "LocalService" 526msgstr "LocalService" 527 528#: ../../rst/user_guide/become.rst:579 529msgid "Because local service accounts do not have passwords, the ``ansible_become_password`` parameter is not required and is ignored if specified." 530msgstr "ローカルサービスアカウントはパスワードを持たないため、``ansible_become_password`` パラメーターは必須ではなく、指定しても無視されます。" 531 532#: ../../rst/user_guide/become.rst:584 533msgid "Become without setting a password" 534msgstr "パスワードを設定しない Become" 535 536#: ../../rst/user_guide/become.rst:586 537msgid "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:" 538msgstr "Ansible 2.8 では、Windows のローカルまたはドメインアカウントになるために、そのアカウントのパスワードがなくても ``become`` を使用することができます。この方法を行うには、以下の要件を満たす必要があります。" 539 540#: ../../rst/user_guide/become.rst:590 541msgid "The connection user has the ``SeDebugPrivilege`` privilege assigned" 542msgstr "接続ユーザーに ``SeDebugPrivilege`` 権限が割り当てられている" 543 544#: ../../rst/user_guide/become.rst:591 545msgid "The connection user is part of the ``BUILTIN\\Administrators`` group" 546msgstr "接続ユーザーが ``BUILTIN\\Administrators`` グループに属している" 547 548#: ../../rst/user_guide/become.rst:592 549msgid "The ``become_user`` has either the ``SeBatchLogonRight`` or ``SeNetworkLogonRight`` user right" 550msgstr "``become_user`` に、``SeBatchLogonRight`` または``SeNetworkLogonRight`` のユーザー権限がある" 551 552#: ../../rst/user_guide/become.rst:594 553msgid "Using become without a password is achieved in one of two different methods:" 554msgstr "パスワードなしの become は、次のいずれかの方法で使用できます。" 555 556#: ../../rst/user_guide/become.rst:596 557msgid "Duplicating an existing logon session's token if the account is already logged on" 558msgstr "そのアカウントがすでにログオンしている場合は、既存のログオンセッションのトークンを複製する" 559 560#: ../../rst/user_guide/become.rst:597 561msgid "Using S4U to generate a logon token that is valid on the remote host only" 562msgstr "S4U を使用してリモートホストでのみ有効なログイントークンを生成する" 563 564#: ../../rst/user_guide/become.rst:599 565msgid "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." 566msgstr "最初のシナリオでは、そのユーザーアカウントの別のログオンから become プロセスを起動します。これは既存の RDP ログイン、コンソールログオンですが、これは常に発生するとは限りません。これは、スケジュール済みタスクの ``Run only when user is logged on`` オプションと類似しています。" 567 568#: ../../rst/user_guide/become.rst:604 569msgid "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." 570msgstr "become アカウントの別のログオンが存在しない場合は、S4U を使用して新しいログオンを作成し、それを介してモジュールを実行します。これは、スケジュール済みタスクの ``Do not store password`` オプションを持つ ``Run whether user is logged on or not`` と似ています。このシナリオでは、become プロセスは通常の WinRM プロセスなどのネットワークリソースにアクセスできません。" 571 572#: ../../rst/user_guide/become.rst:610 573msgid "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:``." 574msgstr "パスワードなしで become を使用することと、パスワードがないアカウントになる (become) ことを区別するには、``ansible_become_password`` を undefined にしておくか、``ansible_become_password:`` を設定してください。" 575 576#: ../../rst/user_guide/become.rst:614 577msgid "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" 578msgstr "Ansible の実行時に既存のトークンがユーザーに存在するという保証がないため、become プロセスがローカルリソースにのみアクセスできます。タスクがネットワークリソースにアクセスする必要がある場合は、パスワードで become を使用します。" 579 580#: ../../rst/user_guide/become.rst:620 581msgid "Accounts without a password" 582msgstr "パスワードのないアカウント" 583 584#: ../../rst/user_guide/become.rst:622 585msgid "As a general security best practice, you should avoid allowing accounts without passwords." 586msgstr "セキュリティーに関する一般的なベストプラクティスとして、パスワードのないアカウントを許可しないでください。" 587 588#: ../../rst/user_guide/become.rst:624 589msgid "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: ''``." 590msgstr "Ansible を使用して、パスワードがない Windows アカウントになります (``Guest`` アカウントなど)。パスワードのないアカウントになるには、通常どおり変数を設定しますが、``ansible_become_password: ''`` を設定します。" 591 592#: ../../rst/user_guide/become.rst:628 593msgid "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:" 594msgstr "このようなアカウントで 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 タスクで実行できます。" 595 596#: ../../rst/user_guide/become.rst:643 597msgid "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." 598msgstr "これは、パスワードがないアカウント専用です。become_user にパスワードがある場合は、``ansible_become_password`` でアカウントのパスワードを設定する必要があります。" 599 600#: ../../rst/user_guide/become.rst:648 601msgid "Become flags for Windows" 602msgstr "Windows での Become フラグ" 603 604#: ../../rst/user_guide/become.rst:650 605msgid "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``." 606msgstr "Ansible 2.5 では、``become_flags`` パラメーターを become メソッド ``runas`` に追加しました。このパラメーターは、``become_flags`` タスクディレクティブを使用するか、``ansible_become_flags`` を使用して Ansible の設定で設定できます。このパラメーターで最初にサポートされる 2 つの有効な値は ``logon_type`` と ``logon_flags`` です。" 607 608#: ../../rst/user_guide/become.rst:656 609msgid "These flags should only be set when becoming a normal user account, not a local service account like LocalSystem." 610msgstr "これらのフラグは、LocalSystem などのローカルサービスアカウントではなく、通常のユーザーアカウントになる (become) 場合にのみ設定する必要があります。" 611 612#: ../../rst/user_guide/become.rst:658 613msgid "The key ``logon_type`` sets the type of logon operation to perform. The value can be set to one of the following:" 614msgstr "鍵 ``logon_type`` は、実行するログオン操作のタイプを設定します。値は以下のいずれかに設定できます。" 615 616#: ../../rst/user_guide/become.rst:661 617msgid "``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." 618msgstr "``interactive``: デフォルトのログオンタイプ。プロセスは、ローカルでプロセスを実行するときと同じコンテキストで実行されます。これにより、すべての WinRM 制限が回避され、推奨される方法です。" 619 620#: ../../rst/user_guide/become.rst:665 621msgid "``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." 622msgstr "``batch``: パスワードセットを使用してスケジュールされたタスクに似たバッチコンテキストでプロセスを実行します。これにより、ほとんどの WinRM 制限を回避する必要があり、``become_user`` が対話的にログインできない場合に役立ちます。" 623 624#: ../../rst/user_guide/become.rst:670 625msgid "``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." 626msgstr "``new_credentials``: 呼び出し元ユーザーと同じ認証情報の下で実行されますが、発信側の接続は ``runas.exe /netonly`` と同様に``become_user`` と ``become_password`` のコンテキストの下で実行されます。``logon_flags`` フラグは、``netcredentials_only`` にも設定する必要があります。このフラグは、プロセスが異なる認証情報セットを使用してネットワークリソース (SMB 共有など) にアクセスする必要がある場合に使用します。" 627 628#: ../../rst/user_guide/become.rst:677 629msgid "``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." 630msgstr "``network``: キャッシュされた認証情報なしで、ネットワークコンテキストでプロセスを実行します。これにより、認証情報の委譲を使用せずに通常の WinRM プロセスを実行するのと同じ種類のログオンセッションが実行され、同じ制限で動作します。" 631 632#: ../../rst/user_guide/become.rst:682 633msgid "``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." 634msgstr "``network_cleartext``: ``network`` ログオンタイプなのですが、代わりに認証情報をキャッシュするため、ネットワークリソースにアクセスできます。これは、認証情報の委譲を使用して通常の WinRM プロセスを実行するのと同じタイプのログオンセッションです。" 635 636#: ../../rst/user_guide/become.rst:686 637msgid "For more information, see `dwLogonType <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-logonusera>`_." 638msgstr "詳細情報は、「`dwLogonType <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-logonusera>`_」を参照してください。" 639 640#: ../../rst/user_guide/become.rst:689 641msgid "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:" 642msgstr "``logon_flags`` キーは、新規プロセスの作成時に Windows がユーザーをログに記録する方法を指定します。この値は、以下の複数の値に設定でき、値を設定しないこともできます。" 643 644#: ../../rst/user_guide/become.rst:692 645msgid "``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``." 646msgstr "``with_profile``: デフォルトのログオンフラグセット。このプロセスは、``HKEY_USERS`` レジストリーキーのユーザーのプロファイルを ``HKEY_CURRENT_USER`` に読み込みます。" 647 648#: ../../rst/user_guide/become.rst:695 649msgid "``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``." 650msgstr "``netcredentials_only``: プロセスは呼び出し元と同じトークンを使用しますが、リモートリソースにアクセスする際には ``become_user`` と ``become_password`` を使用します。これは、信頼関係がないドメイン間シナリオで便利です。また、``new_credentials`` ``logon_type`` と共に使用する必要があります。" 651 652#: ../../rst/user_guide/become.rst:700 653msgid "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``." 654msgstr "デフォルトでは ``logon_flags=with_profile`` が設定されていますが、プロファイルを読み込む必要がない場合は ``logon_flags=`` を設定するか、``netcredentials_only`` でプロファイルを読み込む必要がある場合は``logon_flags=with_profile,netcredentials_only`` を設定してください。" 655 656#: ../../rst/user_guide/become.rst:704 657msgid "For more information, see `dwLogonFlags <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-createprocesswithtokenw>`_." 658msgstr "詳細情報は、「`dwLogonFlags <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-createprocesswithtokenw>`_」を参照してください。" 659 660#: ../../rst/user_guide/become.rst:706 661msgid "Here are some examples of how to use ``become_flags`` with Windows tasks:" 662msgstr "Windows タスクで ``become_flags`` を使用する例を以下に示します。" 663 664#: ../../rst/user_guide/become.rst:734 665msgid "Limitations of become on Windows" 666msgstr "Windows における become 制限" 667 668#: ../../rst/user_guide/become.rst:736 669msgid "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." 670msgstr "Windows Server 2008、2008 R2、Windows 7 で``async`` および ``become`` を使用してタスクを実行できるのは、Ansible 2.7 以降を使用している場合のみです。" 671 672#: ../../rst/user_guide/become.rst:739 673msgid "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." 674msgstr "デフォルトでは、become ユーザーは対話型セッションでログオンするため、Windows ホストでこの権限を設定する必要があります。``SeAllowLogOnLocally`` 特権を継承しない場合、または ``SeDenyLogOnLocally`` 特権を継承する場合は become プロセスに失敗します。特権を追加するか、``logon_type`` フラグを設定して使用するログオンタイプを変更してください。" 675 676#: ../../rst/user_guide/become.rst:745 677msgid "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)." 678msgstr "Ansible バージョン 2.3 よりも前のバージョンでは、``ansible_winrm_transport`` が ``basic`` または ``credssp`` のいずれかでのみ機能していました。この制限は、Windows Server 2008 (R2 バージョン以外) を除くすべてのホストで 2.4 リリース以降に取り込まれました。" 679 680#: ../../rst/user_guide/become.rst:750 681msgid "The Secondary Logon service ``seclogon`` must be running to use ``ansible_become_method: runas``" 682msgstr "``ansible_become_method: runas`` を使用するには、セカンダリーログオンサービス ``seclogon`` が実行している必要があります。" 683 684#: ../../rst/user_guide/become.rst:754 685msgid "`Mailing List <https://groups.google.com/forum/#!forum/ansible-project>`_" 686msgstr "`Mailing List <https://groups.google.com/forum/#!forum/ansible-project>`_" 687 688#: ../../rst/user_guide/become.rst:755 ../../rst/user_guide/intro_adhoc.rst:204 689#: ../../rst/user_guide/intro_bsd.rst:104 690#: ../../rst/user_guide/intro_dynamic_inventory.rst:247 691#: ../../rst/user_guide/intro_getting_started.rst:196 692#: ../../rst/user_guide/intro_inventory.rst:789 693#: ../../rst/user_guide/intro_patterns.rst:169 694#: ../../rst/user_guide/modules.rst:34 695#: ../../rst/user_guide/modules_intro.rst:50 696#: ../../rst/user_guide/modules_support.rst:68 697#: ../../rst/user_guide/playbooks_best_practices.rst:167 698#: ../../rst/user_guide/playbooks_intro.rst:155 699#: ../../rst/user_guide/playbooks_reuse.rst:206 700#: ../../rst/user_guide/playbooks_reuse_includes.rst:32 701#: ../../rst/user_guide/playbooks_reuse_roles.rst:620 702#: ../../rst/user_guide/sample_setup.rst:285 703msgid "Questions? Help? Ideas? Stop by the list on Google Groups" 704msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。" 705 706#: ../../rst/user_guide/become.rst:756 707#: ../../rst/user_guide/collections_using.rst:382 708#: ../../rst/user_guide/intro_adhoc.rst:205 709#: ../../rst/user_guide/intro_bsd.rst:105 710#: ../../rst/user_guide/intro_dynamic_inventory.rst:248 711#: ../../rst/user_guide/intro_getting_started.rst:197 712#: ../../rst/user_guide/intro_inventory.rst:790 713#: ../../rst/user_guide/intro_patterns.rst:170 714#: ../../rst/user_guide/modules.rst:35 715#: ../../rst/user_guide/modules_intro.rst:51 716#: ../../rst/user_guide/modules_support.rst:69 717#: ../../rst/user_guide/playbooks_advanced_syntax.rst:111 718#: ../../rst/user_guide/playbooks_async.rst:169 719#: ../../rst/user_guide/playbooks_blocks.rst:188 720#: ../../rst/user_guide/playbooks_conditionals.rst:507 721#: ../../rst/user_guide/playbooks_debugger.rst:328 722#: ../../rst/user_guide/playbooks_delegation.rst:135 723#: ../../rst/user_guide/playbooks_environment.rst:140 724#: ../../rst/user_guide/playbooks_error_handling.rst:244 725#: ../../rst/user_guide/playbooks_filters.rst:1807 726#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:742 727#: ../../rst/user_guide/playbooks_lookups.rst:36 728#: ../../rst/user_guide/playbooks_loops.rst:444 729#: ../../rst/user_guide/playbooks_prompts.rst:115 730#: ../../rst/user_guide/playbooks_strategies.rst:221 731#: ../../rst/user_guide/playbooks_tags.rst:432 732#: ../../rst/user_guide/playbooks_templating.rst:54 733#: ../../rst/user_guide/playbooks_tests.rst:402 734#: ../../rst/user_guide/playbooks_variables.rst:465 735#: ../../rst/user_guide/windows_dsc.rst:504 736#: ../../rst/user_guide/windows_faq.rst:250 737#: ../../rst/user_guide/windows_setup.rst:575 738#: ../../rst/user_guide/windows_usage.rst:512 739#: ../../rst/user_guide/windows_winrm.rst:913 740msgid "`irc.libera.chat <https://libera.chat/>`_" 741msgstr "`irc.libera.chat <https://libera.chat/>`_" 742 743#: ../../rst/user_guide/become.rst:757 744#: ../../rst/user_guide/collections_using.rst:383 745#: ../../rst/user_guide/intro_adhoc.rst:206 746#: ../../rst/user_guide/intro_bsd.rst:106 747#: ../../rst/user_guide/intro_dynamic_inventory.rst:249 748#: ../../rst/user_guide/intro_getting_started.rst:198 749#: ../../rst/user_guide/intro_inventory.rst:791 750#: ../../rst/user_guide/intro_patterns.rst:171 751#: ../../rst/user_guide/modules.rst:36 752#: ../../rst/user_guide/modules_intro.rst:52 753#: ../../rst/user_guide/modules_support.rst:70 754#: ../../rst/user_guide/playbooks_advanced_syntax.rst:112 755#: ../../rst/user_guide/playbooks_async.rst:170 756#: ../../rst/user_guide/playbooks_blocks.rst:189 757#: ../../rst/user_guide/playbooks_conditionals.rst:508 758#: ../../rst/user_guide/playbooks_debugger.rst:329 759#: ../../rst/user_guide/playbooks_delegation.rst:136 760#: ../../rst/user_guide/playbooks_environment.rst:141 761#: ../../rst/user_guide/playbooks_error_handling.rst:245 762#: ../../rst/user_guide/playbooks_filters.rst:1808 763#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:743 764#: ../../rst/user_guide/playbooks_lookups.rst:37 765#: ../../rst/user_guide/playbooks_loops.rst:445 766#: ../../rst/user_guide/playbooks_prompts.rst:116 767#: ../../rst/user_guide/playbooks_strategies.rst:222 768#: ../../rst/user_guide/playbooks_tags.rst:433 769#: ../../rst/user_guide/playbooks_templating.rst:55 770#: ../../rst/user_guide/playbooks_tests.rst:403 771#: ../../rst/user_guide/playbooks_variables.rst:466 772#: ../../rst/user_guide/windows_dsc.rst:505 773#: ../../rst/user_guide/windows_faq.rst:251 774#: ../../rst/user_guide/windows_setup.rst:576 775#: ../../rst/user_guide/windows_usage.rst:513 776#: ../../rst/user_guide/windows_winrm.rst:914 777msgid "#ansible IRC chat channel" 778msgstr "IRC チャットチャンネル (#ansible)" 779 780#: ../../rst/user_guide/collections_using.rst:6 781msgid "Using collections" 782msgstr "コレクションの使用" 783 784#: ../../rst/user_guide/collections_using.rst:8 785msgid "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>`." 786msgstr "コレクションは、Playbook、ロール、モジュール、プラグインなどの Ansible コンテンツの配布形式です。モジュールがコアの Ansible リポジトリーからコレクションに移動したため、モジュールのドキュメントも :ref:`コレクションページ <list_of_collections>` に移動します。" 787 788#: ../../rst/user_guide/collections_using.rst:10 789msgid "You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_." 790msgstr "`Ansible Galaxy <https://galaxy.ansible.com>`_ を使用してコレクションをインストールして使用できます。" 791 792#: ../../rst/user_guide/collections_using.rst:12 793msgid "For details on how to *develop* collections see :ref:`developing_collections`." 794msgstr "*develop* コレクションの使用方法は、「:ref:`developing_collections`」を参照してください。" 795 796#: ../../rst/user_guide/collections_using.rst:13 797msgid "For the current development status of Collections and FAQ see `Ansible Collections Community Guide <https://github.com/ansible-collections/overview/blob/main/README.rst>`_." 798msgstr "コレクションおよび FAQ の現在の開発ステータスは、「`Ansible コレクションのコミュニティーガイド <https://github.com/ansible-collections/overview/blob/main/README.rst>`_」を参照してください。" 799 800#: ../../rst/user_guide/collections_using.rst:22 801msgid "Installing collections" 802msgstr "コレクションのインストール" 803 804#: ../../rst/user_guide/collections_using.rst:26 805msgid "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``." 806msgstr "この段落で説明されているようにコレクションを手動でインストールした場合には、``ansible`` パッケージまたは ``ansible-core`` をアップグレードすると、コレクションは自動的にアップグレードされません。" 807 808#: ../../rst/user_guide/collections_using.rst:29 809msgid "Installing collections with ``ansible-galaxy``" 810msgstr "``ansible-galaxy`` でコレクションのインストール" 811 812#: ../../rst/shared_snippets/installing_collections.txt:3 813msgid "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." 814msgstr "デフォルトでは、``ansible-galaxy collection install`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載)。追加設定は必要ありません。" 815 816#: ../../rst/shared_snippets/installing_collections.txt:7 817msgid "See :ref:`Configuring the ansible-galaxy client <galaxy_server_config>` if you are using any other Galaxy server, such as Red Hat Automation Hub." 818msgstr "Red Hat Automation Hub などの他の Galaxy サーバーを使用している場合は、「:ref:`Configuring the ansible-galaxy client <galaxy_server_config>`」を参照してください。" 819 820#: ../../rst/shared_snippets/installing_collections.txt:9 821msgid "To install a collection hosted in Galaxy:" 822msgstr "Galaxy でホストされるコレクションをインストールするには、以下を実行します。" 823 824#: ../../rst/shared_snippets/installing_collections.txt:15 825msgid "To upgrade a collection to the latest available version from the Galaxy server you can use the ``--upgrade`` option:" 826msgstr "コレクションを Galaxy サーバーから利用可能な最新バージョンにアップグレードするには、``--upgrade`` オプションを使用します。" 827 828#: ../../rst/shared_snippets/installing_collections.txt:21 829msgid "You can also directly use the tarball from your build:" 830msgstr "ビルドから tarball を直接使用することもできます。" 831 832#: ../../rst/shared_snippets/installing_collections.txt:27 833msgid "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." 834msgstr "ローカルソースディレクトリーからコレクションを構築してインストールできます。``ansible-galaxy`` ユーティリティーは、ディレクトリー内の ``MANIFEST.json`` または ``galaxy.yml`` メタデータを使用してコレクションを構築します。" 835 836#: ../../rst/shared_snippets/installing_collections.txt:34 837msgid "You can also install multiple collections in a namespace directory." 838msgstr "名前空間ディレクトリーに複数のコレクションをインストールすることもできます。" 839 840#: ../../rst/shared_snippets/installing_collections.txt:51 841msgid "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``." 842msgstr "install コマンドは、親ディレクトリーが ``ansible_collections`` ディレクトリーに含まれている場合を除き、``-p`` オプションで指定したパスに、パス ``ansible_collections`` を自動的に追加します。" 843 844#: ../../rst/shared_snippets/installing_collections.txt:55 845msgid "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``" 846msgstr "``-p`` オプションを使用してインストールパスを指定する場合は、Ansible 自体がコレクションを見つけることが予想される場所であるため、:ref:`COLLECTIONS_PATHS` に設定された値のいずれかを使用します。パスを指定しないと、``ansible-galaxy collection install`` は :ref:`COLLECTIONS_PATHS` で定義されている最初のパスにコレクションをインストールします。これは、デフォルトでは ``~/.ansible/collections`` です。" 847 848#: ../../rst/shared_snippets/installing_collections.txt:59 849msgid "You can also keep a collection adjacent to the current playbook, under a ``collections/ansible_collections/`` directory structure." 850msgstr "また、``collections/ansible_collections/`` ディレクトリー構造の下で、コレクションを現在の Playbook の横に維持することもできます。" 851 852#: ../../rst/shared_snippets/installing_collections.txt:71 853msgid "See :ref:`collection_structure` for details on the collection directory structure." 854msgstr "コレクションディレクトリー構造の詳細は、「:ref:`collection_structure`」を参照してください。" 855 856#: ../../rst/user_guide/collections_using.rst:36 857msgid "Installing an older version of a collection" 858msgstr "古いバージョンのコレクションのインストール" 859 860#: ../../rst/shared_snippets/installing_older_collection.txt:2 861msgid "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:" 862msgstr "一度にインストールするコレクションのバージョンは 1 つだけです。デフォルトでは、``ansible-galaxy`` により利用可能な最新バージョンがインストールされます。特定のバージョンをインストールする場合は、バージョン範囲識別子を追加できます。たとえば、コレクションの 1.0.0-beta.1 バージョンをインストールするには、以下を実行します。" 863 864#: ../../rst/shared_snippets/installing_older_collection.txt:8 865msgid "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:" 866msgstr "``,`` で区切って複数の範囲識別子を指定できます。シェルが、``>``、``!``、およびその他の演算子を含むコマンド全体を渡すように、一重引用符を使用します。たとえば、1.0.0 以上 2.0.0 未満の最新バージョンをインストールするには、次を実行します。" 867 868#: ../../rst/shared_snippets/installing_older_collection.txt:14 869msgid "Ansible will always install the most recent version that meets the range identifiers you specify. You can use the following range identifiers:" 870msgstr "Ansible は、指定する範囲識別子を満たす最新バージョンを常にインストールします。以下の範囲識別子を使用できます。" 871 872#: ../../rst/shared_snippets/installing_older_collection.txt:16 873msgid "``*``: The most recent version. This is the default." 874msgstr "``*``: 最新バージョンです。これがデフォルトです。" 875 876#: ../../rst/shared_snippets/installing_older_collection.txt:17 877msgid "``!=``: Not equal to the version specified." 878msgstr "``!=``: 指定されたバージョンと同等ではありません。" 879 880#: ../../rst/shared_snippets/installing_older_collection.txt:18 881msgid "``==``: Exactly the version specified." 882msgstr "``==``: 指定されたバージョンそのものになります。" 883 884#: ../../rst/shared_snippets/installing_older_collection.txt:19 885msgid "``>=``: Greater than or equal to the version specified." 886msgstr "``>=``: 指定されたバージョン以上になります。" 887 888#: ../../rst/shared_snippets/installing_older_collection.txt:20 889msgid "``>``: Greater than the version specified." 890msgstr "``>``: 指定されたバージョンよりも大きくなります。" 891 892#: ../../rst/shared_snippets/installing_older_collection.txt:21 893msgid "``<=``: Less than or equal to the version specified." 894msgstr "``<=``: 指定されたバージョン以下になります。" 895 896#: ../../rst/shared_snippets/installing_older_collection.txt:22 897msgid "``<``: Less than the version specified." 898msgstr "``<``: 指定されたバージョンよりも小さくなります。" 899 900#: ../../rst/shared_snippets/installing_older_collection.txt:25 901msgid "By default ``ansible-galaxy`` ignores pre-release versions. To install a pre-release version, you must use the ``==`` range identifier to require it explicitly." 902msgstr "デフォルトでは、``ansible-galaxy`` はリリース前のバージョンを無視します。リリース前のバージョンをインストールするには、``==`` 範囲識別子を使用して明示的に要求する必要があります。" 903 904#: ../../rst/user_guide/collections_using.rst:41 905msgid "Installing a collection from a git repository" 906msgstr "git リポジトリーからのコレクションのインストール" 907 908#: ../../rst/shared_snippets/installing_collections_git_repo.txt:1 909msgid "You can install a collection in a git repository by providing the URI to the repository instead of a collection name or path to a ``tar.gz`` file. The collection must contain a ``galaxy.yml`` or ``MANIFEST.json`` file, which will be used to generate the would-be collection artifact data from the directory. The URI should be prefixed with ``git+`` (or with ``git@`` to use a private repository with ssh authentication) and optionally supports a comma-separated `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ version (for example, a commit or tag)." 910msgstr "コレクション名または ``tar.gz`` ファイルへのパスではなく、リポジトリーに URI を提供することにより、git リポジトリーにコレクションをインストールできます。コレクションには、``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルが必要です。このコレクションは、ディレクトリーからの will-be コレクションアーティファクトデータを生成するのに使用されます。URI の接頭辞には ``git+`` (または ssh 認証でプライベートリポジトリーを使用する ``git@``）を付け、必要に応じてコンマ区切りの `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ バージョン (コミットまたはタグなど) をサポートする必要があります。" 911 912#: ../../rst/shared_snippets/installing_collections_git_repo.txt:5 913msgid "Embedding credentials into a git URI is not secure. Make sure to use safe auth options for security reasons. For example, use `SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_, `netrc <https://linux.die.net/man/5/netrc>`_ or `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_/`url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ in Git config to prevent your creds from being exposed in logs." 914msgstr "認証情報を git URI に埋め込むことは安全ではありません。セキュリティー上の理由から、安全な認証オプションを使用してください。たとえば、Git 設定の `SSH <https://help.github.com/en/github/authenticating-to-github/connecting-to-github-with-ssh>`_、`netrc <https://linux.die.net/man/5/netrc>`_、または `http.extraHeader <https://git-scm.com/docs/git-config#Documentation/git-config.txt-httpextraHeader>`_/`url.<base>.pushInsteadOf <https://git-scm.com/docs/git-config#Documentation/git-config.txt-urlltbasegtpushInsteadOf>`_ で、クレジットがログに公開されないようにします。" 915 916#: ../../rst/shared_snippets/installing_collections_git_repo.txt:18 917msgid "In a ``requirements.yml`` file, you can also use the ``type`` and ``version`` keys in addition to using the ``git+repo,version`` syntax for the collection name." 918msgstr "``requirements.yml`` ファイルでは、コレクション名の ``git+repo,version`` 構文を使用する他に、``type`` キーおよび ``version`` キーを使用することもできます。" 919 920#: ../../rst/shared_snippets/installing_collections_git_repo.txt:27 921msgid "Git repositories can be used for collection dependencies as well. This can be helpful for local development and testing but built/published artifacts should only have dependencies on other artifacts." 922msgstr "git リポジトリーはコレクションの依存関係にも使用できます。これは、ローカル開発およびテストに役立ちますが、ビルド/公開されたアーティファクトには他のアーティファクトへの依存関係のみが必要です。" 923 924#: ../../rst/shared_snippets/installing_collections_git_repo.txt:34 925msgid "Default repository search locations" 926msgstr "デフォルトのリポジトリー検索の場所" 927 928#: ../../rst/shared_snippets/installing_collections_git_repo.txt:36 929msgid "There are two paths searched in a repository for collections by default." 930msgstr "デフォルトでは、コレクション用のリポジトリーで 2 つのパスが検索されます。" 931 932#: ../../rst/shared_snippets/installing_collections_git_repo.txt:38 933msgid "The first is the ``galaxy.yml`` or ``MANIFEST.json`` file in the top level of the repository path. If the file exists it's used as the collection metadata and the individual collection will be installed." 934msgstr "1 つ目は、リポジトリーパスの最上位にある ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ファイルが存在する場合は、コレクションのメタデータとして使用され、個々のコレクションがインストールされます。" 935 936#: ../../rst/shared_snippets/installing_collections_git_repo.txt:49 937msgid "The second is a ``galaxy.yml`` or ``MANIFEST.json`` file in each directory in the repository path (one level deep). In this scenario, each directory with a metadata file is installed as a collection." 938msgstr "2 つ目は、リポジトリーパス (1 レベルの深さ) の各ディレクトリーの ``galaxy.yml`` ファイルまたは ``MANIFEST.json`` ファイルです。ここでは、メタデータファイルが含まれる各ディレクトリーがコレクションとしてインストールされます)。" 939 940#: ../../rst/shared_snippets/installing_collections_git_repo.txt:62 941msgid "Specifying the location to search for collections" 942msgstr "コレクションを検索する場所の指定" 943 944#: ../../rst/shared_snippets/installing_collections_git_repo.txt:64 945msgid "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 which path ansible-galaxy should inspect for metadata file(s). The path should be a directory to a collection or multiple collections (rather than the path to a ``galaxy.yml`` file or ``MANIFEST.json`` file)." 946msgstr "異なるリポジトリー構造がある場合や、コレクションのサブセットのみをインストールする場合は、URI の最後にフラグメントを追加して (任意のコンマ区切りバージョンの前)、ansible-galaxy がメタデータファイルを調べるパスを示すことができます。パスは、(``MANIFEST.json`` ファイルまたは ``galaxy.yml`` ファイルへのパスではなく) コレクションまたは複数のコレクションへのディレクトリーである必要があります。" 947 948#: ../../rst/user_guide/collections_using.rst:48 949msgid "Install multiple collections with a requirements file" 950msgstr "要件ファイルを使用した複数のコレクションのインストール" 951 952#: ../../rst/shared_snippets/installing_multiple_collections.txt:2 953msgid "You can also setup a ``requirements.yml`` file to install multiple collections in one command. This file is a YAML file in the format:" 954msgstr "``requirements.yml`` ファイルを設定して、1 つのコマンドで複数のコレクションをインストールすることもできます。このファイルは、以下の形式の YAML ファイルです。" 955 956#: ../../rst/shared_snippets/installing_multiple_collections.txt:16 957msgid "The supported keys for collection requirement entries are ``name``, ``version``, ``source``, and ``type``." 958msgstr "コレクション要件エントリーでサポートされるキーは ``name``、``version``、``source``、および ``type`` です。" 959 960#: ../../rst/shared_snippets/installing_multiple_collections.txt:18 961msgid "The ``version`` key can take in the same range identifier format documented above. If you're installing a collection from a git repository instead of a built collection artifact, the ``version`` key refers to a `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_." 962msgstr "``version`` キーは、上記の範囲識別子の形式を取ることができます。ビルドコレクションアーティファクトではなく git リポジトリーからコレクションをインストールする場合は、``version`` キーは `git commit-ish <https://git-scm.com/docs/gitglossary#def_commit-ish>`_ を参照します。" 963 964#: ../../rst/shared_snippets/installing_multiple_collections.txt:20 965msgid "The ``type`` key can be set to ``galaxy``, ``url``, ``file``, and ``git``. If ``type`` is omitted, the ``name`` key is used to implicitly determine the source of the collection." 966msgstr "``type`` キーは ``galaxy``、``url``、``file``、および ``git`` に設定できます。``type`` を省略すると、``name`` キーを使用してコレクションのソースを暗黙的に決定します。" 967 968#: ../../rst/shared_snippets/installing_multiple_collections.txt:22 969msgid "Roles can also be specified and placed under the ``roles`` key. The values follow the same format as a requirements file used in older Ansible releases." 970msgstr "ロールは、``roles`` キーの下に指定して配置することもできます。この値は、古い Ansible リリースで使用される要件ファイルと同じ形式に従います。" 971 972#: ../../rst/shared_snippets/installing_multiple_collections.txt:39 973msgid "To install both roles and collections at the same time with one command, run the following:" 974msgstr "1 つのコマンドで、ロールとコレクションを同時にインストールするには、以下のコマンドを実行します。" 975 976#: ../../rst/shared_snippets/installing_multiple_collections.txt:45 977msgid "Running ``ansible-galaxy collection install -r`` or ``ansible-galaxy role install -r`` will only install collections, or roles respectively." 978msgstr "``ansible-galaxy collection install -r`` または ``ansible-galaxy role install -r`` を実行すると、それぞれコレクションまたはロールがインストールされます。" 979 980#: ../../rst/shared_snippets/installing_multiple_collections.txt:49 981msgid "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." 982msgstr "カスタムコレクションまたはロールインストールパスを指定する場合は、同じ要件ファイルからロールとコレクションの両方をインストールすることはできません。今回の例では、コレクションは省略され、コマンドは ``ansible-galaxy role install`` のように処理されます。" 983 984#: ../../rst/user_guide/collections_using.rst:55 985msgid "Downloading a collection for offline use" 986msgstr "オフラインで使用するコレクションのダウンロード" 987 988#: ../../rst/shared_snippets/download_tarball_collections.txt:3 989msgid "To download the collection tarball from Galaxy for offline use:" 990msgstr "オフラインで使用するために、コレクション tarball を Galaxy からダウンロードするには、以下を行います。" 991 992#: ../../rst/shared_snippets/download_tarball_collections.txt:5 993msgid "Navigate to the collection page." 994msgstr "コレクションページに移動します。" 995 996#: ../../rst/shared_snippets/download_tarball_collections.txt:6 997msgid "Click on :guilabel:`Download tarball`." 998msgstr ":guilabel:`Download tarball` をクリックします。" 999 1000#: ../../rst/shared_snippets/download_tarball_collections.txt:8 1001msgid "You may also need to manually download any dependent collections." 1002msgstr "また、依存するコレクションを手動でダウンロードする必要がある場合があります。" 1003 1004#: ../../rst/user_guide/collections_using.rst:63 1005msgid "Configuring the ``ansible-galaxy`` client" 1006msgstr "``ansible-galaxy`` クライアントの設定" 1007 1008#: ../../rst/shared_snippets/galaxy_server_list.txt:3 1009msgid "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`)." 1010msgstr "デフォルトでは、``ansible-galaxy`` は https://galaxy.ansible.com を Galaxy サーバーとして使用します (:ref:`galaxy_server` の :file:`ansible.cfg` ファイルに記載）。" 1011 1012#: ../../rst/shared_snippets/galaxy_server_list.txt:5 1013msgid "You can use either option below to configure ``ansible-galaxy collection`` to use other servers (such as Red Hat Automation Hub or a custom Galaxy server):" 1014msgstr "以下のオプションを使用して、他のサーバー (Red Hat Automation Hub、カスタムの Galaxy サーバーなど) を使用するように ``ansible-galaxy collection`` を設定できます。" 1015 1016#: ../../rst/shared_snippets/galaxy_server_list.txt:7 1017msgid "Set the server list in the :ref:`galaxy_server_list` configuration option in :ref:`ansible_configuration_settings_locations`." 1018msgstr "「:ref:`ansible_configuration_settings_locations`」の「:ref:`galaxy_server_list`」設定オプションにサーバーリストを設定します。" 1019 1020#: ../../rst/shared_snippets/galaxy_server_list.txt:8 1021msgid "Use the ``--server`` command line argument to limit to an individual server." 1022msgstr "``--server`` コマンドライン引数を使用して、個々のサーバーに制限します。" 1023 1024#: ../../rst/shared_snippets/galaxy_server_list.txt:10 1025msgid "To configure a Galaxy server list in ``ansible.cfg``:" 1026msgstr "``ansible.cfg`` で Galaxy サーバー一覧を設定するには、以下を行います。" 1027 1028#: ../../rst/shared_snippets/galaxy_server_list.txt:13 1029msgid "Add the ``server_list`` option under the ``[galaxy]`` section to one or more server names." 1030msgstr "``server_list`` セクションの ``[galaxy]`` オプションを 1 つ以上のサーバー名に追加します。" 1031 1032#: ../../rst/shared_snippets/galaxy_server_list.txt:14 1033msgid "Create a new section for each server name." 1034msgstr "各サーバー名に新しいセクションを作成します。" 1035 1036#: ../../rst/shared_snippets/galaxy_server_list.txt:15 1037msgid "Set the ``url`` option for each server name." 1038msgstr "各サーバー名に ``url`` オプションを設定します。" 1039 1040#: ../../rst/shared_snippets/galaxy_server_list.txt:16 1041msgid "Optionally, set the API token for each server name. Go to https://galaxy.ansible.com/me/preferences and click :guilabel:`Show API key`." 1042msgstr "必要に応じて、各サーバー名の API トークンを設定します。https://galaxy.ansible.com/me/preferences に移動し、guilabel:`Show API key` をクリックします。" 1043 1044#: ../../rst/shared_snippets/galaxy_server_list.txt:19 1045msgid "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." 1046msgstr "各サーバー名の ``url`` オプションは、スラッシュ ``/`` で終了する必要があります。Galaxy サーバー一覧の API トークンを設定しない場合は、``--api-key`` 引数を使用してトークンを ``ansible-galaxy collection publish`` コマンドに渡します。" 1047 1048#: ../../rst/shared_snippets/galaxy_server_list.txt:21 1049msgid "For Automation Hub, you additionally need to:" 1050msgstr "Automation Hub の場合には、さらに以下の操作が必要です。" 1051 1052#: ../../rst/shared_snippets/galaxy_server_list.txt:23 1053msgid "Set the ``auth_url`` option for each server name." 1054msgstr "各サーバー名に ``auth_url`` オプションを設定します。" 1055 1056#: ../../rst/shared_snippets/galaxy_server_list.txt:24 1057msgid "Set the API token for each server name. Go to https://cloud.redhat.com/ansible/automation-hub/token/ and click ::guilabel:`Get API token` from the version dropdown to copy your API token." 1058msgstr "各サーバー名の API トークンを設定します。https://cloud.redhat.com/ansible/automation-hub/token/ に、バージョンドロップダウンリストから ::guilabel:`Get API token` をクリックして API トークンをコピーします。" 1059 1060#: ../../rst/shared_snippets/galaxy_server_list.txt:26 1061msgid "The following example shows how to configure multiple servers:" 1062msgstr "以下の例は、複数のサーバーを設定する方法を示しています。" 1063 1064#: ../../rst/shared_snippets/galaxy_server_list.txt:52 1065msgid "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." 1066msgstr "``--server`` コマンドライン引数を使用して ``server_list`` で明示的な Galaxy サーバーを選択し、この引数の値はサーバー名と一致する必要があります。サーバー一覧にないサーバーを使用する場合は、そのサーバーにアクセスする URL に値を設定します (サーバーリスト内のすべてのサーバーは無視されます)。また、事前定義されたサーバーのいずれかに ``--api-key`` 引数を使用することはできません。サーバーの一覧を定義していない場合、または ``--server`` に URL を指定した場合限り、``api_key`` 引数を使用できます。" 1067 1068#: ../../rst/shared_snippets/galaxy_server_list.txt:56 1069msgid "**Galaxy server list configuration options**" 1070msgstr "**Galaxy サーバー一覧設定オプション**" 1071 1072#: ../../rst/shared_snippets/galaxy_server_list.txt:58 1073msgid "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:" 1074msgstr ":ref:`galaxy_server_list` オプションは、優先順位が付けられたサーバー識別子の一覧です。コレクションを検索する場合、インストールプロセスは次の順序で検索します。たとえば、``automation_hub`` を検索してから、``my_org_hub``、``release_galaxy``、最後に ``test_galaxy`` で、コレクションが見つかるまで行います。次に、実際の Galaxy インスタンスが ``[galaxy_server.{{ id }}]`` セクションで定義され。ここでは、``{{ id }}`` は、一覧で定義されているサーバー識別子です。このセクションでは、次のキーを定義できます。" 1075 1076#: ../../rst/shared_snippets/galaxy_server_list.txt:64 1077msgid "``url``: The URL of the Galaxy instance to connect to. Required." 1078msgstr "``url``: 接続する Galaxy インスタンスの URL。必須。" 1079 1080#: ../../rst/shared_snippets/galaxy_server_list.txt:65 1081msgid "``token``: An API token key to use for authentication against the Galaxy instance. Mutually exclusive with ``username``." 1082msgstr "``token``: Galaxy インスタンスに対する認証に使用する API トークンキー。``username`` と相互に排他的です。" 1083 1084#: ../../rst/shared_snippets/galaxy_server_list.txt:66 1085msgid "``username``: The username to use for basic authentication against the Galaxy instance. Mutually exclusive with ``token``." 1086msgstr "``username``: Galaxy インスタンスに対する Basic 認証に使用するユーザー名。``token`` と相互に排他的です。" 1087 1088#: ../../rst/shared_snippets/galaxy_server_list.txt:67 1089msgid "``password``: The password to use, in conjunction with ``username``, for basic authentication." 1090msgstr "``password``: Basic 認証に使用するパスワード。``username`` と併用します。" 1091 1092#: ../../rst/shared_snippets/galaxy_server_list.txt:68 1093msgid "``auth_url``: The URL of a Keycloak server 'token_endpoint' if using SSO authentication (for example, Automation Hub). Mutually exclusive with ``username``. Requires ``token``." 1094msgstr "``auth_url``: SSO 認証 (例: Automation Hub) を使用する場合は Keycloak サーバー「token_endpoint」の URL です。``username`` と相互に排他的です。``token`` が必要です。" 1095 1096#: ../../rst/shared_snippets/galaxy_server_list.txt:70 1097msgid "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``." 1098msgstr "これらのサーバーオプションを ``ansible.cfg`` ファイルで定義するだけでなく、それらを環境変数として定義することもできます。環境変数は ``ANSIBLE_GALAXY_SERVER_{{ id }}_{{ key }}`` の形式です。``{{ id }}`` はサーバー識別子の大文字形式であり、``{{ key }}`` は定義するキーです。たとえば、``ANSIBLE_GALAXY_SERVER_RELEASE_GALAXY_TOKEN=secret_token`` を設定することで、``release_galaxy`` に ``token`` を定義することができます。" 1099 1100#: ../../rst/shared_snippets/galaxy_server_list.txt:75 1101msgid "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." 1102msgstr "Galaxy サーバー 1 つだけを使用する操作 (例: ``publish`` コマンド、``info`` コマンド、または ``install`` コマンド) の場合、``ansible-galaxy collection`` コマンドは、``--server`` 引数を使用して明示的なサーバーに渡しない限り、``server_list`` の最初のエントリーを使用します。" 1103 1104#: ../../rst/shared_snippets/galaxy_server_list.txt:79 1105msgid "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." 1106msgstr "コレクションが見つかると、その要件は親コレクションと同じ Galaxy インスタンス内でのみ検索されます。インストールプロセスでは、別の Galaxy インスタンスでコレクション要件を検索しません。" 1107 1108#: ../../rst/user_guide/collections_using.rst:70 1109msgid "Downloading collections" 1110msgstr "コレクションのダウンロード" 1111 1112#: ../../rst/user_guide/collections_using.rst:72 1113msgid "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." 1114msgstr "オフラインインストール用のコレクションとその依存関係をダウンロードするには、``ansible-galaxy collection download`` を実行します。これにより、指定されたコレクションとその依存関係を指定のディレクトリーにダウンロードして、Galaxy サーバーにアクセスせずに、ホストにこれらのコレクションをインストールするのに使用できる ``requirements.yml`` ファイルを作成します。すべてのコレクションは、デフォルトで ``./collections`` ディレクトリーにダウンロードされます。" 1115 1116#: ../../rst/user_guide/collections_using.rst:77 1117msgid "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." 1118msgstr "``install`` コマンドと同様、コレクションは :ref:`configured galaxy server config <galaxy_server_config>` に基づいて取得されます。ダウンロードするコレクションが URL や tarball へのパスで指定されていた場合でも、設定された Galaxy サーバーからコレクションが再ダウンロードされます。" 1119 1120#: ../../rst/user_guide/collections_using.rst:81 1121msgid "Collections can be specified as one or multiple collections or with a ``requirements.yml`` file just like ``ansible-galaxy collection install``." 1122msgstr "コレクションは、1 つまたは複数のコレクションとして、または ``ansible-galaxy collection install`` のように ``requirements.yml`` ファイルで指定できます。" 1123 1124#: ../../rst/user_guide/collections_using.rst:84 1125msgid "To download a single collection and its dependencies:" 1126msgstr "1 つのコレクションとその依存関係をダウンロードするには、以下を行います。" 1127 1128#: ../../rst/user_guide/collections_using.rst:90 1129msgid "To download a single collection at a specific version:" 1130msgstr "特定のバージョンで単一のコレクションをダウンロードするには、以下を実行します。" 1131 1132#: ../../rst/user_guide/collections_using.rst:96 1133msgid "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`." 1134msgstr "複数のコレクションをダウンロードするには、上記のように複数のコレクションをコマンドライン引数として指定するか、:ref:`collection_requirements_file` に記載されている形式で要件ファイルを使用します。" 1135 1136#: ../../rst/user_guide/collections_using.rst:103 1137msgid "You can also download a source collection directory. The collection is built with the mandatory ``galaxy.yml`` file." 1138msgstr "ソースコレクションディレクトリーをダウンロードすることもできます。コレクションは必須の ``galaxy.yml`` ファイルでビルドされます。" 1139 1140#: ../../rst/user_guide/collections_using.rst:111 1141msgid "You can download multiple source collections from a single namespace by providing the path to the namespace." 1142msgstr "名前空間へのパスを指定すると、単一の名前空間から複数のソースコレクションをダウンロードできます。" 1143 1144#: ../../rst/user_guide/collections_using.rst:127 1145msgid "All the collections are downloaded by default to the ``./collections`` folder but you can use ``-p`` or ``--download-path`` to specify another path:" 1146msgstr "コレクションはすべて、デフォルトで ``./collections`` ディレクトリーにダウンロードされますが、``-p`` または ``--download-path`` を使用して別のパスを指定することもできます。" 1147 1148#: ../../rst/user_guide/collections_using.rst:134 1149msgid "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 or Automation Hub server." 1150msgstr "コレクションをダウンロードした後、ディレクトリーには指定されたコレクション、その依存関係、および ``requirements.yml`` ファイルが含まれます。このディレクトリーは、``ansible-galaxy collection install`` と同じように、Galaxy サーバーまたは Automation Hub サーバーにアクセスせずにホストにコレクションをインストールできます。" 1151 1152#: ../../rst/user_guide/collections_using.rst:148 1153msgid "Listing collections" 1154msgstr "コレクション一覧の表示" 1155 1156#: ../../rst/user_guide/collections_using.rst:150 1157msgid "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." 1158msgstr "インストールされたコレクションを一覧表示するには、``ansible-galaxy collection list`` を実行します。これは、設定されたコレクションの検索パスにあるインストールされたコレクションをすべて表示します。これは、MANIFEST.json ではなく galaxy.yml ファイルが含まれる開発中のコレクションも表示します。コレクションが配置されているパスとバージョン情報が表示されます。バージョン情報がない場合は、``*`` がバージョン番号に表示されます。" 1159 1160#: ../../rst/user_guide/collections_using.rst:169 1161msgid "Run with ``-vvv`` to display more detailed information." 1162msgstr "詳細情報を表示するには、``-vvv`` を付けて実行します。" 1163 1164#: ../../rst/user_guide/collections_using.rst:171 1165msgid "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." 1166msgstr "特定のコレクションを一覧表示するには、有効な完全修飾コレクション名 (FQCN) を ``ansible-galaxy collection list`` コマンドに渡します。コレクションのインスタンス一覧が表示されます。" 1167 1168#: ../../rst/user_guide/collections_using.rst:187 1169msgid "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." 1170msgstr "他のパスのコレクションを検索するには、``-p`` オプションを使用します。複数の検索パスを指定する場合は、``:`` で区切って指定します。コマンドラインで指定されたパスのリストは、設定されたコレクションの検索パスの先頭に追加されます。" 1171 1172#: ../../rst/user_guide/collections_using.rst:223 1173msgid "Verifying collections" 1174msgstr "コレクションの検証" 1175 1176#: ../../rst/user_guide/collections_using.rst:226 1177msgid "Verifying collections with ``ansible-galaxy``" 1178msgstr "``ansible-galaxy`` でコレクションを検証" 1179 1180#: ../../rst/user_guide/collections_using.rst:228 1181msgid "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." 1182msgstr "インストールすると、インストールしたコレクションの内容が、サーバー上のコレクションの内容と一致することを確認できます。この機能は、設定されたコレクションパスのいずれかにコレクションがインストールされ、設定された galaxy サーバーのいずれかにコレクションが存在することを想定します。" 1183 1184#: ../../rst/user_guide/collections_using.rst:234 1185msgid "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." 1186msgstr "``ansible-galaxy collection verify`` コマンドの出力は、成功すると何も表示されません。コレクションを変更すると、変更したファイルがコレクション名の下に表示されます。" 1187 1188#: ../../rst/user_guide/collections_using.rst:244 1189msgid "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." 1190msgstr "``-vvv`` フラグを使用すると、インストールされたコレクションのバージョンとパス、検証に使用されるリモートコレクションの URL、正常な確認出力などの追加情報を表示できます。" 1191 1192#: ../../rst/user_guide/collections_using.rst:255 1193msgid "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." 1194msgstr "プレリリースまたは最新でないバージョンのコレクションをインストールしている場合は、検証する特定のバージョンを含める必要があります。バージョンが省略された場合、インストールされたコレクションは、サーバーで利用可能な最新バージョンと比較して検証されます。" 1195 1196#: ../../rst/user_guide/collections_using.rst:261 1197msgid "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." 1198msgstr "``namespace.collection_name:version`` 形式に加えて、``requirements.yml`` ファイルで検証するコレクションを提供することができます。``requirements.yml`` に記載されている依存関係は、検証プロセスに含まれないため、別途検証する必要があります。" 1199 1200#: ../../rst/user_guide/collections_using.rst:267 1201msgid "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." 1202msgstr "``tar.gz`` ファイルに対する検証はサポートされていません。``requirements.yml`` にインストール用の tar ファイルや URL へのパスが含まれている場合は、``--ignore-errors`` フラグを使用して、ファイル内で ``namespace.name`` 形式を使用しているすべてのコレクションが処理されるようにすることができます。" 1203 1204#: ../../rst/user_guide/collections_using.rst:272 1205msgid "Using collections in a Playbook" 1206msgstr "Playbook でのコレクションの使用" 1207 1208#: ../../rst/user_guide/collections_using.rst:274 1209msgid "Once installed, you can reference a collection content by its fully qualified collection name (FQCN):" 1210msgstr "インストールが完了すると、完全修飾コレクション名 (FQCN) でコレクションコンテンツを参照できます。" 1211 1212#: ../../rst/user_guide/collections_using.rst:283 1213msgid "This works for roles or any type of plugin distributed within the collection:" 1214msgstr "これは、コレクションで配布されるロールまたはすべてのタイプのプラグインで機能します。" 1215 1216#: ../../rst/user_guide/collections_using.rst:299 1217msgid "Simplifying module names with the ``collections`` keyword" 1218msgstr "``collections`` キーワードを使用したモジュール名の簡素化" 1219 1220#: ../../rst/user_guide/collections_using.rst:301 1221msgid "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." 1222msgstr "``collections`` キーワードを使用すると、ロールまたは Playbook が非修飾モジュールおよびアクション名を検索する必要のあるコレクションの一覧を定義できます。つまり、``collections`` キーワードを使用すると、そのロールまたは Playbook 全体で、モジュールおよびアクションプラグインを短縮名で参照できます。" 1223 1224#: ../../rst/user_guide/collections_using.rst:304 1225msgid "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." 1226msgstr "Playbook で ``collections`` キーワードと 1 つ以上のロールの両方を使用している場合、ロールは Playbook で設定されたコレクションを継承しません。これが、常に FQCN を使用することが推奨される理由の 1 つです。ロールの詳細については、以下を参照してください。" 1227 1228#: ../../rst/user_guide/collections_using.rst:307 1229msgid "Using ``collections`` in roles" 1230msgstr "ロールでの ``collections`` の使用" 1231 1232#: ../../rst/user_guide/collections_using.rst:309 1233msgid "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." 1234msgstr "ロール内で、Ansible がロールの ``meta/main.yml`` の ``collections`` キーワードを使用して、ロール内のタスクを検索するコレクションを制御できます。Ansible は、ロールを呼び出す Playbook が別の ``collections`` キーワードエントリーで異なるコレクションを定義する場合でも、ロール内に定義されたコレクションリストを使用します。コレクション内で定義されたロールは、常に暗黙的に自身のコレクションを最初に検索するため、同じコレクションに含まれるモジュール、アクション、または他のロールにアクセスするために ``collections`` キーワードを使用する必要はありません。" 1235 1236#: ../../rst/user_guide/collections_using.rst:320 1237msgid "Using ``collections`` in playbooks" 1238msgstr "Playbook での ``collections`` の使用" 1239 1240#: ../../rst/user_guide/collections_using.rst:322 1241msgid "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." 1242msgstr "Playbook では、Ansible が実行するモジュールやアクションプラグインを検索するコレクションを制御することができます。ただし、Playbook で呼び出したロールは、独自のコレクション検索順序を定義し、呼び出した Playbook の設定を継承しません。これは、ロールが独自の ``collections`` キーワードを定義していない場合でも同様です。" 1243 1244#: ../../rst/user_guide/collections_using.rst:340 1245msgid "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)." 1246msgstr "``collections`` キーワードは、名前空間以外のプラグインおよびロール参照に対して、順序付けされた「検索パス」を作成します。コンテンツのインストールや、プラグインやロールの読み込みに関する Ansible の動作は変更されません。非アクションやモジュールプラグイン (検索、フィルター、テストなど) が必要なことに注意してください。" 1247 1248#: ../../rst/user_guide/collections_using.rst:344 1249msgid "Using a playbook from a collection" 1250msgstr "コレクションからの Playbook の使用" 1251 1252#: ../../rst/user_guide/collections_using.rst:348 1253msgid "You can also distribute playbooks in your collection and invoke them using the same semantics you use for plugins:" 1254msgstr "コレクションに Playbook を分散し、プラグインに使用するのと同じセマンティクスを使用して Playbook を呼び出すこともできます。" 1255 1256#: ../../rst/user_guide/collections_using.rst:354 1257msgid "From inside a playbook:" 1258msgstr "Playbook 内から、以下を実行します。" 1259 1260#: ../../rst/user_guide/collections_using.rst:361 1261msgid "A few recommendations when creating such playbooks, ``hosts:`` should be generic or at least have a variable input." 1262msgstr "このような Playbook を作成する際のいくつかの推奨事項として、``hosts:`` は一般的なものにするか、少なくとも変数入力にする必要があります。" 1263 1264#: ../../rst/user_guide/collections_using.rst:372 1265msgid "This will have an implied entry in the ``collections:`` keyword of ``my_namespace.my_collection`` just as with roles." 1266msgstr "これは、ロールと同様に、``my_namespace.my_collection`` の ``collections:`` キーワードに暗黙的なエントリーを持ちます。" 1267 1268#: ../../rst/user_guide/collections_using.rst:376 1269msgid ":ref:`developing_collections`" 1270msgstr ":ref:`developing_collections`" 1271 1272#: ../../rst/user_guide/collections_using.rst:377 1273msgid "Develop or modify a collection." 1274msgstr "コレクションを開発するか、または変更します。" 1275 1276#: ../../rst/user_guide/collections_using.rst:378 1277msgid ":ref:`collections_galaxy_meta`" 1278msgstr ":ref:`collections_galaxy_meta`" 1279 1280#: ../../rst/user_guide/collections_using.rst:379 1281msgid "Understand the collections metadata structure." 1282msgstr "コレクションのメタデータ構造を理解します。" 1283 1284#: ../../rst/user_guide/collections_using.rst:380 1285msgid "`Mailing List <https://groups.google.com/group/ansible-devel>`_" 1286msgstr "`Mailing List <https://groups.google.com/group/ansible-devel>`_" 1287 1288#: ../../rst/user_guide/collections_using.rst:381 1289msgid "The development mailing list" 1290msgstr "開発メーリングリスト" 1291 1292#: ../../rst/user_guide/command_line_tools.rst:4 1293msgid "Working with command line tools" 1294msgstr "コマンドラインツールの使用" 1295 1296#: ../../rst/user_guide/command_line_tools.rst:6 1297msgid "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." 1298msgstr "ほとんどのユーザーは、`ansible` および `ansible-playbook` に精通しているものの、Ansible が提供する唯一のユーティリティーではありません。以下は、Ansible ユーティリティーの完全なリストです。各ページには、ユーティリティーの説明と、サポートされるパラメーター一覧が含まれています。" 1299 1300#: ../../rst/user_guide/complex_data_manipulation.rst:4 1301msgid "Data manipulation" 1302msgstr "データ操作" 1303 1304#: ../../rst/user_guide/complex_data_manipulation.rst:6 1305msgid "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." 1306msgstr "多くの場合は、変数を使用して複雑な操作を行う必要がありますが、Ansible はデータ処理/操作ツールとしてはお勧めできませんが、既存の Jinja2 テンプレートと、追加された多くの Ansible フィルター、ルックアップ、テストを併用することで、非常に複雑な変換を行うことができます。" 1307 1308#: ../../rst/user_guide/complex_data_manipulation.rst:11 1309msgid "Let's start with a quick definition of each type of plugin:" 1310msgstr "まずは、それぞれのプラグインの定義を簡単に説明します。" 1311 1312#: ../../rst/user_guide/complex_data_manipulation.rst:9 1313msgid "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." 1314msgstr "lookups: 主に「外部データ」を照会するために使用されます。Ansible では、``with_<lookup>`` 構成を使用したループの主要部分でしたが、処理するデータを返すために独立して使用することもできます。前述のようにループでの主な機能であるため、通常はリストを返します。Jinja2 の演算子 ``lookup`` または ``query`` と一緒に使用します。" 1315 1316#: ../../rst/user_guide/complex_data_manipulation.rst:10 1317msgid "filters: used to change/transform data, used with the ``|`` Jinja2 operator." 1318msgstr "filters: Jinja2 演算子 ``|`` で使用される、データの変更/変換に使用します。" 1319 1320#: ../../rst/user_guide/complex_data_manipulation.rst:11 1321msgid "tests: used to validate data, used with the ``is`` Jinja2 operator." 1322msgstr "tests: Jinja2 演算子 ``is`` で使用されるデータの検証に使用されます。" 1323 1324#: ../../rst/user_guide/complex_data_manipulation.rst:19 1325msgid "Loops and list comprehensions" 1326msgstr "ループおよびリストの競合" 1327 1328#: ../../rst/user_guide/complex_data_manipulation.rst:21 1329msgid "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``." 1330msgstr "ほとんどのプログラミング言語にはループ (``for``、``while`` など) やリスト内包があり、オブジェクトのリストを含むリストの変換を行うことができます。Jinja2 には、このような機能を提供するフィルターがいくつかあります (``map``、``select``、``reject``、``selectattr``、``rejectattr``)。" 1331 1332#: ../../rst/user_guide/complex_data_manipulation.rst:23 1333msgid "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." 1334msgstr "map: これは基本的な for ループで、リストのすべての項目を変更することができます。「attribute」キーワードを使用すると、リスト要素の属性に基づいて変換を行うことができます。" 1335 1336#: ../../rst/user_guide/complex_data_manipulation.rst:24 1337msgid "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." 1338msgstr "select/reject: これは、条件のあるループ用であり、条件の結果に基づいて一致する (または一致しない) リストのサブセットを作成できます。" 1339 1340#: ../../rst/user_guide/complex_data_manipulation.rst:25 1341msgid "selectattr/rejectattr: very similar to the above but it uses a specific attribute of the list elements for the conditional statement." 1342msgstr "selectattr/rejectattr: 上記と非常に似ていますが、条件文に対して list 要素の特定の属性を使用します。" 1343 1344#: ../../rst/user_guide/complex_data_manipulation.rst:30 1345msgid "Use a loop to create exponential backoff for retries/until." 1346msgstr "ループを使用して再試行/一時停止の指数関数的なバックオフを作成します。" 1347 1348#: ../../rst/user_guide/complex_data_manipulation.rst:44 1349msgid "Extract keys from a dictionary matching elements from a list" 1350msgstr "リストから一致するディクショナリー要素からキーを抽出します。" 1351 1352#: ../../rst/user_guide/complex_data_manipulation.rst:46 1353msgid "The Python equivalent code would be:" 1354msgstr "Python と同等のコードは以下のとおりです。" 1355 1356#: ../../rst/user_guide/complex_data_manipulation.rst:55 1357msgid "There are several ways to do it in Ansible, this is just one example:" 1358msgstr "Ansible で実行する方法はいくつかあります。以下は一例です。" 1359 1360#: ../../rst/user_guide/complex_data_manipulation.rst:57 1361msgid "Way to extract matching keys from a list of dictionaries" 1362msgstr "ディクショナリーのリストから一致するキーを抽出する方法" 1363 1364#: ../../rst/user_guide/complex_data_manipulation.rst:84 1365msgid "Results of debug task, a list with the extracted keys" 1366msgstr "デバッグタスクの結果 (展開した鍵を含むリスト)" 1367 1368#: ../../rst/user_guide/complex_data_manipulation.rst:97 1369msgid "Get the unique list of values of a variable that vary per host" 1370msgstr "ホストごとに異なる変数の値の一意のリストを取得します。" 1371 1372#: ../../rst/user_guide/complex_data_manipulation.rst:107 1373msgid "Find mount point" 1374msgstr "マウントポイントの検索" 1375 1376#: ../../rst/user_guide/complex_data_manipulation.rst:109 1377msgid "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:" 1378msgstr "今回のケースでは、マシン間で指定されたパスのマウントポイントを検索したいのですが、すでにマウントファクトを収集しているため、次のように使用できます。" 1379 1380#: ../../rst/user_guide/complex_data_manipulation.rst:111 1381msgid "Use selectattr to filter mounts into list I can then sort and select the last from" 1382msgstr "selectattr を使用してマウントにフィルターを設定してリストにし、ソートして最後のものを選択します。" 1383 1384#: ../../rst/user_guide/complex_data_manipulation.rst:128 1385msgid "Omit elements from a list" 1386msgstr "リストからの要素を省略" 1387 1388#: ../../rst/user_guide/complex_data_manipulation.rst:130 1389msgid "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:" 1390msgstr "特別な ``omit`` 変数は、モジュールオプションでのみ機能しますが、要素のリストを調整するための識別子として、他の方法でも使用することができます。" 1391 1392#: ../../rst/user_guide/complex_data_manipulation.rst:132 1393msgid "Inline list filtering when feeding a module option" 1394msgstr "モジュールオプションのフィード時のインラインリストのフィルタリング" 1395 1396#: ../../rst/user_guide/complex_data_manipulation.rst:146 1397msgid "Another way is to avoid adding elements to the list in the first place, so you can just use it directly:" 1398msgstr "もう 1 つの方法は、そもそもリストに要素を追加しないようにして、直接利用することです。" 1399 1400#: ../../rst/user_guide/complex_data_manipulation.rst:148 1401msgid "Using set_fact in a loop to increment a list conditionally" 1402msgstr "ループで set_fact を使用してリストを条件付きで増分する" 1403 1404#: ../../rst/user_guide/complex_data_manipulation.rst:166 1405msgid "Combine values from same list of dicts" 1406msgstr "同じリストのディクショナリーの値を結合する" 1407 1408#: ../../rst/user_guide/complex_data_manipulation.rst:167 1409msgid "Combining positive and negative filters from examples above, you can get a 'value when it exists' and a 'fallback' when it doesn't." 1410msgstr "上記の例から正のフィルターと負のフィルターを組み合わせると、「存在する場合の値」と存在しない場合の「フォールバック」を得ることができます。" 1411 1412#: ../../rst/user_guide/complex_data_manipulation.rst:169 1413msgid "Use selectattr and rejectattr to get the ansible_host or inventory_hostname as needed" 1414msgstr "必要に応じて、selectattr および rejectattr を使用して ansible_host または inventory_hostname を取得します。" 1415 1416#: ../../rst/user_guide/complex_data_manipulation.rst:187 1417msgid "Custom Fileglob Based on a Variable" 1418msgstr "変数に基づくカスタムファイルグロブ" 1419 1420#: ../../rst/user_guide/complex_data_manipulation.rst:189 1421msgid "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." 1422msgstr "この例では、`Python argument list unpacking <https://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists>`_ を使用して、変数に基づいてファイルグロブのカスタムリストを作成します。" 1423 1424#: ../../rst/user_guide/complex_data_manipulation.rst:191 1425msgid "Using fileglob with a list based on a variable." 1426msgstr "変数に基づくリストでファイルグロブの使用。" 1427 1428#: ../../rst/user_guide/complex_data_manipulation.rst:212 1429msgid "Complex Type transformations" 1430msgstr "複雑なタイプ変換" 1431 1432#: ../../rst/user_guide/complex_data_manipulation.rst:214 1433msgid "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 leveraged to achieve more complex transformations." 1434msgstr "Jinja には単純なデータ型変換のためのフィルターが用意されていますが (``int``、``bool`` など)、データ構造を変換したい場合はそう簡単ではありません。上記のようにループやリスト内包を利用することもできますし、他のフィルターやルックアップを連鎖させて利用することで、より複雑な変換を行うことができます。" 1435 1436#: ../../rst/user_guide/complex_data_manipulation.rst:221 1437msgid "Create dictionary from list" 1438msgstr "リストからディクショナリーを作成" 1439 1440#: ../../rst/user_guide/complex_data_manipulation.rst:223 1441msgid "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." 1442msgstr "ほとんどの言語では、ペアのリストからディクショナリー (マップ、連想配列、ハッシュなど) を簡単に作成できますが、Ansible ではいくつかの方法があり、データのソースによって最適な方法が異なります。" 1443 1444#: ../../rst/user_guide/complex_data_manipulation.rst:226 1445msgid "These example produces ``{\"a\": \"b\", \"c\": \"d\"}``" 1446msgstr "これらの例では、``{\"a\": \"b\", \"c\": \"d\"}`` を生成します。" 1447 1448#: ../../rst/user_guide/complex_data_manipulation.rst:228 1449msgid "Simple list to dict by assuming the list is [key, value , key, value, ...]" 1450msgstr "リストが [key, value , key, value, ...] であることを前提とする、ディクショナリーへの単純なリスト" 1451 1452#: ../../rst/user_guide/complex_data_manipulation.rst:236 1453msgid "It is simpler when we have a list of pairs:" 1454msgstr "ペアのリストがある場合はより簡単にできます。" 1455 1456#: ../../rst/user_guide/complex_data_manipulation.rst:243 1457msgid "Both end up being the same thing, with ``slice(2)`` transforming ``single_list`` to a ``list_of_pairs`` generator." 1458msgstr "``slice(2)`` が ``single_list`` を ``list_of_pairs`` ジェネレーターに変換することで、両方とも同じ内容になります。" 1459 1460#: ../../rst/user_guide/complex_data_manipulation.rst:247 1461msgid "A bit more complex, using ``set_fact`` and a ``loop`` to create/update a dictionary with key value pairs from 2 lists:" 1462msgstr "``set_fact`` と ``loop`` を使用して、2 つのリストからキーと値のペアを持つ、もう少し複雑なディクショナリーを作成/更新します。" 1463 1464#: ../../rst/user_guide/complex_data_manipulation.rst:249 1465msgid "Using set_fact to create a dictionary from a set of lists" 1466msgstr "set_fact を使用してリストのセットからのディクショナリーの作成" 1467 1468#: ../../rst/user_guide/complex_data_manipulation.rst:267 1469msgid "This results in ``{\"foo\": \"a\", \"var\": \"b\", \"bar\": \"c\"}``." 1470msgstr "その結果、``{\"foo\": \"a\", \"var\": \"b\", \"bar\": \"c\"}`` になります。" 1471 1472#: ../../rst/user_guide/complex_data_manipulation.rst:270 1473msgid "You can even combine these simple examples with other filters and lookups to create a dictionary dynamically by matching patterns to variable names:" 1474msgstr "これらの簡単な例を他のフィルターや検索と組み合わせて、変数名にパターンを一致させて動的にディクショナリーを作成することもできます。" 1475 1476#: ../../rst/user_guide/complex_data_manipulation.rst:272 1477msgid "Using 'vars' to define dictionary from a set of lists without needing a task" 1478msgstr "「vars」を使用して、タスクを必要とせずにリストのセットからディクショナリーを定義" 1479 1480#: ../../rst/user_guide/complex_data_manipulation.rst:279 1481msgid "A quick explanation, since there is a lot to unpack from these two lines:" 1482msgstr "以下の 2 つの行から展開するため、簡単な説明があります。" 1483 1484#: ../../rst/user_guide/complex_data_manipulation.rst:281 1485msgid "The ``varnames`` lookup returns a list of variables that match \"begin with ``my``\"." 1486msgstr "``varnames`` 検索は、「begin with ``my``」に一致する変数の一覧を返します。" 1487 1488#: ../../rst/user_guide/complex_data_manipulation.rst:282 1489msgid "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." 1490msgstr "そして、前のステップのリストを ``vars`` 検索に送り、値のリストを取得します。``*`` は「リストを参照解除する」ために使用されます (Jinja でも通用する python の手法です)。そうでなければ、リストを 1 つの引数として受け取ることになります。" 1491 1492#: ../../rst/user_guide/complex_data_manipulation.rst:284 1493msgid "Both lists get passed to the ``zip`` filter to pair them off into a unified list (key, value, key2, value2, ...)." 1494msgstr "両方のリストは、``zip`` フィルターに渡され、それらをペアにして統一されたリスト (key, value, key2, value2, ...) にします。" 1495 1496#: ../../rst/user_guide/complex_data_manipulation.rst:285 1497msgid "The dict function then takes this 'list of pairs' to create the dictionary." 1498msgstr "その後、dict 関数はこの「ペアのリスト」を取得し、ディクショナリーを作成します。" 1499 1500#: ../../rst/user_guide/complex_data_manipulation.rst:288 1501msgid "An example on how to use facts to find a host's data that meets condition X:" 1502msgstr "ファクトを使用して、条件 X を満たすホストのデータを検索する例:" 1503 1504#: ../../rst/user_guide/complex_data_manipulation.rst:297 1505msgid "Using an example from @zoradache on reddit, to show the 'uptime in days/hours/minutes' (assumes facts where gathered). https://www.reddit.com/r/ansible/comments/gj5a93/trying_to_get_uptime_from_seconds/fqj2qr3/" 1506msgstr "reddit の @zoradache 氏の例を参考に、「日/時間/分単位での稼働時間」を表示しています (ファクトが収集されていることを前提としています) (https://www.reddit.com/r/ansible/comments/gj5a93/trying_to_get_uptime_from_seconds/fqj2qr3/)。" 1507 1508#: ../../rst/user_guide/complex_data_manipulation.rst:309 1509msgid ":doc:`playbooks_filters`" 1510msgstr ":doc:`playbooks_filters`" 1511 1512#: ../../rst/user_guide/complex_data_manipulation.rst:310 1513msgid "Jinja2 filters included with Ansible" 1514msgstr "Ansible に含まれる Jinja2 フィルター" 1515 1516#: ../../rst/user_guide/complex_data_manipulation.rst:311 1517msgid ":doc:`playbooks_tests`" 1518msgstr ":doc:`playbooks_tests`" 1519 1520#: ../../rst/user_guide/complex_data_manipulation.rst:312 1521msgid "Jinja2 tests included with Ansible" 1522msgstr "Ansible に含まれる Jinja2 テスト" 1523 1524#: ../../rst/user_guide/complex_data_manipulation.rst:313 1525msgid "`Jinja2 Docs <https://jinja.palletsprojects.com/>`_" 1526msgstr "`Jinja2 Docs <https://jinja.palletsprojects.com/>`_" 1527 1528#: ../../rst/user_guide/complex_data_manipulation.rst:314 1529msgid "Jinja2 documentation, includes lists for core filters and tests" 1530msgstr "Jinja2 ドキュメント。コアフィルターおよびテストの一覧が含まれます。" 1531 1532#: ../../rst/user_guide/connection_details.rst:5 1533msgid "Connection methods and details" 1534msgstr "接続方法および詳細" 1535 1536#: ../../rst/user_guide/connection_details.rst:7 1537msgid "This section shows you how to expand and refine the connection methods Ansible uses for your inventory." 1538msgstr "本セクションでは、Ansible がインベントリーに使用する接続方法を拡張および改良する方法を示します。" 1539 1540#: ../../rst/user_guide/connection_details.rst:10 1541msgid "ControlPersist and paramiko" 1542msgstr "ControlPersist および paramiko" 1543 1544#: ../../rst/user_guide/connection_details.rst:12 1545msgid "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'." 1546msgstr "デフォルトでは、Ansible はネイティブの OpenSSH を使用します。これは、ControlPersist (パフォーマンス機能)、Kerberos、および Jump Host 設定などの ``~/.ssh/config`` のオプションをサポートしているためです。コントロールマシンが ControlPersist をサポートしていない古いバージョンの OpenSSH を使用している場合、Ansible は「paramiko」と呼ばれる Python による OpenSSH の実装にフォールバックします。" 1547 1548#: ../../rst/user_guide/connection_details.rst:17 1549msgid "Setting a remote user" 1550msgstr "リモートユーザーの設定" 1551 1552#: ../../rst/user_guide/connection_details.rst:19 1553msgid "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:" 1554msgstr "デフォルトでは、Ansible はすべてのリモートデバイスに、コントロールノードで使用しているユーザー名で接続します。リモートデバイスにそのユーザー名が存在しない場合は、接続に別のユーザー名を設定することができます。別のユーザーとしていくつかのタスクを実行するだけの場合は、「:ref:`become`」を参照してください。Playbookで接続ユーザーを設定することができます。" 1555 1556#: ../../rst/user_guide/connection_details.rst:32 1557msgid "as a host variable in inventory:" 1558msgstr "インベントリーのホスト変数では、以下のようになります。" 1559 1560#: ../../rst/user_guide/connection_details.rst:39 1561msgid "or as a group variable in inventory:" 1562msgstr "また、インベントリーのグローバル変数では、以下のようになります。" 1563 1564#: ../../rst/user_guide/connection_details.rst:51 1565msgid "Setting up SSH keys" 1566msgstr "SSH キーの設定" 1567 1568#: ../../rst/user_guide/connection_details.rst:53 1569msgid "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``." 1570msgstr "デフォルトでは、Ansible は SSH 鍵を使用してリモートマシンに接続することを想定しています。SSH キーが推奨されますが、必要に応じて ``--ask-pass`` オプションを使用してパスワード認証を使用できます。:ref:`privilege escalation <become>` (sudo、pbrun など) のパスワードを提供する必要がある場合は、``--ask-become-pass`` を使用します。" 1571 1572#: ../../rst/user_guide/shared_snippets/SSH_password_prompt.txt:2 1573msgid "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." 1574msgstr "Ansible は、ssh 接続プラグインを使用している場合 (これがデフォルトです)は、ユーザーと ssh プロセスの間の通信を可能にするチャンネルを公開しておらず、ssh 鍵を復号するためのパスワードを手動で受け入れることができません。``ssh-agent`` を使用することが強く推奨されます。" 1575 1576#: ../../rst/user_guide/connection_details.rst:57 1577msgid "To set up SSH agent to avoid retyping passwords, you can do:" 1578msgstr "パスワードを再入力しないように SSH エージェントをセットアップするには、次のようにします。" 1579 1580#: ../../rst/user_guide/connection_details.rst:64 1581msgid "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:" 1582msgstr "セットアップによっては、代わりに Ansible の ``--private-key`` コマンドラインオプションを使用して pem ファイルを指定することもできます。秘密鍵ファイルを追加することもできます。" 1583 1584#: ../../rst/user_guide/connection_details.rst:71 1585msgid "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`." 1586msgstr "ssh-agent を使用せずに秘密鍵ファイルを追加する別の方法は、:ref:`intro_inventory` で説明するように、インベントリーファイルで ``ansible_ssh_private_key_file`` を使用することです。" 1587 1588#: ../../rst/user_guide/connection_details.rst:74 1589msgid "Running against localhost" 1590msgstr "ローカルホストに対して実行" 1591 1592#: ../../rst/user_guide/connection_details.rst:76 1593msgid "You can run commands against the control node by using \"localhost\" or \"127.0.0.1\" for the server name:" 1594msgstr "サーバー名に「localhost」または「127.0.0.1」を使用して、コントロールノードにコマンドを実行できます。" 1595 1596#: ../../rst/user_guide/connection_details.rst:82 1597msgid "You can specify localhost explicitly by adding this to your inventory file:" 1598msgstr "これをインベントリーファイルに追加して、localhost を明示的に指定できます。" 1599 1600#: ../../rst/user_guide/connection_details.rst:91 1601msgid "Managing host key checking" 1602msgstr "ホスト鍵の確認の管理" 1603 1604#: ../../rst/user_guide/connection_details.rst:93 1605msgid "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." 1606msgstr "Ansible は、デフォルトでホスト鍵の確認を有効にします。ホスト鍵を確認すると、サーバーのなりすましや中間者攻撃から保護されますが、メンテナンスが必要です。" 1607 1608#: ../../rst/user_guide/connection_details.rst:95 1609msgid "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." 1610msgstr "ホストが再インストールされ、「known_hosts」に異なるキーがある場合は、修正されるまでエラーメッセージが表示されます。新しいホストが「known_hosts」にない場合、コントロールノードはキーの確認を求めるかもしれませんが、これは Ansible を cron などから使用している場合は、インタラクティブな操作になります。このように動作しないようにしたい場合があります。" 1611 1612#: ../../rst/user_guide/connection_details.rst:97 1613msgid "If you understand the implications and wish to disable this behavior, you can do so by editing ``/usr/local/etc/ansible/ansible.cfg`` or ``~/.ansible.cfg``:" 1614msgstr "この動作を無効にした場合の影響を理解し、無効にする場合は、``/usr/local/etc/ansible/ansible.cfg`` または ``~/.ansible.cfg`` 編集します。" 1615 1616#: ../../rst/user_guide/connection_details.rst:104 1617msgid "Alternatively this can be set by the :envvar:`ANSIBLE_HOST_KEY_CHECKING` environment variable:" 1618msgstr "また、これは、:envvar:`ANSIBLE_HOST_KEY_CHECKING` 環境変数により設定できます。" 1619 1620#: ../../rst/user_guide/connection_details.rst:110 1621msgid "Also note that host key checking in paramiko mode is reasonably slow, therefore switching to 'ssh' is also recommended when using this feature." 1622msgstr "また、paramiko モードでのホストキーチェックはかなり遅いため、この機能を使用する場合は「ssh」に切り替えることも推奨されます。" 1623 1624#: ../../rst/user_guide/connection_details.rst:113 1625msgid "Other connection methods" 1626msgstr "その他の接続方法" 1627 1628#: ../../rst/user_guide/connection_details.rst:115 1629msgid "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." 1630msgstr "Ansible では、SSH 以外にもさまざまな接続方法を利用することができます。ローカルでの管理、chroot コンテナー、lxc コンテナー、および jail コンテナーの管理など、任意の接続プラグインを選択できます。「ansible-pull」と呼ばれるモードでは、システムを反転させて、スケジュールされた git チェックアウトを介してシステムを「phone home」させ、中央のリポジトリーから設定ディレクティブを引き出すこともできます。" 1631 1632#: ../../rst/user_guide/guide_rolling_upgrade.rst:3 1633msgid "Playbook Example: Continuous Delivery and Rolling Upgrades" 1634msgstr "Playbook の例: 継続的デリバリーおよびローリングアップグレード" 1635 1636#: ../../rst/user_guide/guide_rolling_upgrade.rst:11 1637msgid "What is continuous delivery?" 1638msgstr "継続的デリバリーとは" 1639 1640#: ../../rst/user_guide/guide_rolling_upgrade.rst:13 1641msgid "Continuous delivery (CD) means frequently delivering updates to your software application." 1642msgstr "継続的デリバリー (CD) は、ソフトウェアアプリケーションに更新を頻繁に配信することを意味します。" 1643 1644#: ../../rst/user_guide/guide_rolling_upgrade.rst:15 1645msgid "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." 1646msgstr "更新の頻度を上げることで、特定の期間を待つ必要がなくなり、組織は変化に対応するプロセスを改善できるという考え方です。" 1647 1648#: ../../rst/user_guide/guide_rolling_upgrade.rst:18 1649msgid "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." 1650msgstr "Ansible のユーザーの中には、エンドユーザーにアップデートを毎時またはそれ以上の頻度で配布している人がいます。承認されたコード変更があるたびに配布している場合もあります。そのためには、ダウンタイムなしで更新を迅速に適用できるツールが必要です。" 1651 1652#: ../../rst/user_guide/guide_rolling_upgrade.rst:21 1653msgid "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." 1654msgstr "本ガイドでは、Ansible の最も完成度の高いサンプル Playbook の 1 つである lamp_haproxy をテンプレートとして、この目標を達成する方法を詳細に説明します。この例では、ロール、テンプレート、グループ変数などの Ansible の機能が数多く使用されており、Web アプリケーションスタックのローリングアップグレードをダウンタイムなしで行うことができるオーケストレーション Playbook も付属しています。" 1655 1656#: ../../rst/user_guide/guide_rolling_upgrade.rst:28 1657msgid "`Click here for the latest playbooks for this example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_." 1658msgstr "`Click here for the latest playbooks for this example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_." 1659 1660#: ../../rst/user_guide/guide_rolling_upgrade.rst:31 1661msgid "The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers." 1662msgstr "Playbook は Apache、PHP、MySQL、Nagios、および HAProxy を CentOS ベースのサーバーセットにデプロイします。" 1663 1664#: ../../rst/user_guide/guide_rolling_upgrade.rst:33 1665msgid "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." 1666msgstr "ここでは、これらの Playbook を実行する方法については説明しません。その情報については、github プロジェクトに含まれる README をサンプルと一緒に読んでください。その代わり、Playbook の各部分をよく見て、それが何をするのかを説明します。" 1667 1668#: ../../rst/user_guide/guide_rolling_upgrade.rst:39 1669msgid "Site deployment" 1670msgstr "サイトのデプロイメント" 1671 1672#: ../../rst/user_guide/guide_rolling_upgrade.rst:41 1673msgid "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:" 1674msgstr "まず、``site.yml`` から始めましょう。これは、サイト全体のデプロイメント Playbook です。この Playbook を使用して、サイトの初期デプロイメントと、すべてのサーバーへの更新のプッシュを行うことができます。" 1675 1676#: ../../rst/user_guide/guide_rolling_upgrade.rst:86 1677msgid "If you're not familiar with terms like playbooks and plays, you should review :ref:`working_with_playbooks`." 1678msgstr "Playbook やプレイなどの用語に慣れていない場合は、:ref:`working_with_playbooks` を確認してください。" 1679 1680#: ../../rst/user_guide/guide_rolling_upgrade.rst:88 1681msgid "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." 1682msgstr "この Playbook では 5 つのプレイを紹介します。最初の Playbook は ``all`` のホストを対象とし、``common`` のロールをすべてのホストに適用します。これは、yum リポジトリーの設定やファイアウォールの設定など、サイト全体ですべてのサーバーに適用する必要があるものを対象としています。" 1683 1684#: ../../rst/user_guide/guide_rolling_upgrade.rst:91 1685msgid "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." 1686msgstr "次の 4 つのプレイは、特定のホストグループに対して実行し、それらのサーバーに特定のロールを適用します。Nagios 監視、データベース、Web アプリケーションのロールと一緒に、基本的な Apache セットアップをインストールして設定する ``base-apache`` ロールを実装しました。これは、サンプルの Web アプリケーションと Nagios ホストの両方で使用されます。" 1687 1688#: ../../rst/user_guide/guide_rolling_upgrade.rst:99 1689msgid "Reusable content: roles" 1690msgstr "再利用可能なコンテンツ: ロール" 1691 1692#: ../../rst/user_guide/guide_rolling_upgrade.rst:101 1693msgid "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." 1694msgstr "その結果、ロールおよび Ansible での動作についてある程度理解できるはずです。ロールは、タスク、ハンドラー、テンプレート、ファイルなどのコンテンツを再利用可能なコンポーネントに整理する方法です。" 1695 1696#: ../../rst/user_guide/guide_rolling_upgrade.rst:104 1697msgid "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." 1698msgstr "この例では、``common``、``base-apache``、``db``、``haproxy``、``nagios``、および ``web`` の 6 つのロールがあります。ロールをどのように編成するかは、ニーズおよび使用するアプリケーション次第ですが、ほとんどのサイトでは、すべてのシステムに適用される 1 つまたは複数の共通ロールと、サイトの特定の部分をインストールおよび設定する一連のアプリケーション固有のロールがあります。" 1699 1700#: ../../rst/user_guide/guide_rolling_upgrade.rst:108 1701msgid "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." 1702msgstr "ロールは変数と依存関係を持つことができ、パラメーターをロールに渡すことでその動作を変更できます。ロールについては、「:ref:`playbooks_reuse_roles`」セクションで詳しく説明しています。" 1703 1704#: ../../rst/user_guide/guide_rolling_upgrade.rst:114 1705msgid "Configuration: group variables" 1706msgstr "設定: グループ変数" 1707 1708#: ../../rst/user_guide/guide_rolling_upgrade.rst:116 1709msgid "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:" 1710msgstr "グループ変数は、サーバーのグループに適用される変数です。テンプレートや Playbook で使用することで、動作をカスタマイズしたり、簡単に変更できる設定やパラメーターを提供することができます。グループ変数は、インベントリーと同じ場所にある ``group_vars`` ディレクトリーに保存されます。以下は lamp_haproxy の``group_vars/all`` ファイルです。ご想像のとおり、これらの変数はインベントリー内のすべてのマシンに適用されます。" 1711 1712#: ../../rst/user_guide/guide_rolling_upgrade.rst:127 1713msgid "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." 1714msgstr "これは YAML ファイルですが、リストやディクショナリーを作成することで、より複雑な変数構造にすることができます。ここでは 2 つの変数を設定しています。1 つは Web サーバーのポート用、もう 1 つはマシンが時刻同期に使用する NTP サーバーのポート用です。" 1715 1716#: ../../rst/user_guide/guide_rolling_upgrade.rst:131 1717msgid "Here's another group variables file. This is ``group_vars/dbservers`` which applies to the hosts in the ``dbservers`` group:" 1718msgstr "次は、別のグループ変数ファイルです。これは、``dbservers`` グループのホストに適用される ``group_vars/dbservers`` です。" 1719 1720#: ../../rst/user_guide/guide_rolling_upgrade.rst:142 1721msgid "If you look in the example, there are group variables for the ``webservers`` group and the ``lbservers`` group, similarly." 1722msgstr "上記の例を参照すると、同様に ``webservers`` グループと ``lbservers`` グループのグループ変数も存在します。" 1723 1724#: ../../rst/user_guide/guide_rolling_upgrade.rst:144 1725msgid "These variables are used in a variety of places. You can use them in playbooks, like this, in ``roles/db/tasks/main.yml``:" 1726msgstr "これらの変数はさまざまな場所で使用され、``roles/db/tasks/main.yml`` のように Playbook でも使用できます。" 1727 1728#: ../../rst/user_guide/guide_rolling_upgrade.rst:161 1729msgid "You can also use these variables in templates, like this, in ``roles/common/templates/ntp.conf.j2``:" 1730msgstr "これらの変数は、``roles/common/templates/ntp.conf.j2`` で、テンプレートで使用することもできます。" 1731 1732#: ../../rst/user_guide/guide_rolling_upgrade.rst:176 1733msgid "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``:" 1734msgstr "{{ および }} の変数置換構文は、テンプレートでも変数でも同じであることがわかります。中括弧の中の構文は Jinja2 のもので、中のデータに対してあらゆる種類の操作やさまざまなフィルターを適用することができます。テンプレートでは、for ループや if 文を使用して、以下のように、``roles/common/templates/iptables.j2`` でより複雑な状況を処理することもできます。" 1735 1736#: ../../rst/user_guide/guide_rolling_upgrade.rst:187 1737msgid "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." 1738msgstr "これは、現在操作しているマシンのインベントリー名 (``inventory_hostname``) が、インベントリーグループ ``dbservers`` に存在するかどうかをテストしています。存在する場合、そのマシンはポート 3306 に対して iptables の ACCEPT 行を取得します。" 1739 1740#: ../../rst/user_guide/guide_rolling_upgrade.rst:190 1741msgid "Here's another example, from the same template:" 1742msgstr "以下は、同じテンプレートの別の例です。" 1743 1744#: ../../rst/user_guide/guide_rolling_upgrade.rst:198 1745msgid "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." 1746msgstr "これは、``monitoring`` というグループのすべてのホストをループし、現在のマシンの iptables 設定に、各監視ホストのデフォルトの IPv4 アドレスに ACCEPT 行を追加し、Nagios がそれらのホストを監視できるようにします。" 1747 1748#: ../../rst/user_guide/guide_rolling_upgrade.rst:201 1749msgid "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." 1750msgstr "Jinja2 とその機能については `こちら <https://jinja.palletsprojects.com/>`_ で、また Ansible の変数全般については :ref:`playbooks_variables` で詳しく説明しています。" 1751 1752#: ../../rst/user_guide/guide_rolling_upgrade.rst:207 1753msgid "The rolling upgrade" 1754msgstr "ローリングアップグレード" 1755 1756#: ../../rst/user_guide/guide_rolling_upgrade.rst:209 1757msgid "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." 1758msgstr "これで、Web サーバー、ロードバランサー、および監視機能を備えた完全なサイトが展開されました。これをどうやって更新しますか。ここで、Ansible のオーケストレーション機能が活躍します。アプリケーションの中には、「オーケストレーション」という言葉を、基本的な命令やコマンドブラストの意味で使用しているものもありますが、Ansible ではオーケストレーションを「オーケストラのようにマシンを指揮すること」と呼んでおり、そのためにかなり高度なエンジンを備えています。" 1759 1760#: ../../rst/user_guide/guide_rolling_upgrade.rst:213 1761msgid "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``." 1762msgstr "Ansible には、多層アプリケーションの操作を連携して行う機能があり、Web アプリケーションのダウンタイムなしのローリングアップグレードを簡単に編成 (オーケストレーション) することができます。これは、``rolling_update.yml`` という名前の別の Playbook に実装されています。" 1763 1764#: ../../rst/user_guide/guide_rolling_upgrade.rst:215 1765msgid "Looking at the playbook, you can see it is made up of two plays. The first play is very simple and looks like this:" 1766msgstr "Playbook を確認すると、2 つのプレイで構成されていることがわかります。1 つ目のプレイはとてもシンプルで、次のようになります。" 1767 1768#: ../../rst/user_guide/guide_rolling_upgrade.rst:222 1769msgid "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." 1770msgstr "どうなっているのでしょうか。なぜタスクが存在しないのでしょうか。Ansible は、サーバーを操作する前に、サーバーから「ファクト」を収集することをご存知かもしれません。これらのファクトは、ネットワーク情報、OS/ディストリビューションのバージョンなど、あらゆる種類のものに役立ちます。今回のケースでは、更新を実行する前に、環境内のすべての監視サーバーについて何かを知る必要があるため、この単純なプレイによって、監視サーバーのファクト収集ステップが強制的に実行されます。このパターンは時々見かけますが、知っておくと便利なワザです。" 1771 1772#: ../../rst/user_guide/guide_rolling_upgrade.rst:224 1773msgid "The next part is the update play. The first part looks like this:" 1774msgstr "次の部分は、更新プレイです。最初の部分は以下のようになっています。" 1775 1776#: ../../rst/user_guide/guide_rolling_upgrade.rst:232 1777msgid "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." 1778msgstr "これは通常のプレイ定義で、``webservers`` グループで動作します。``serial`` キーワードは、一度に操作するサーバーの数を Ansible に伝えます。このキーワードが指定されていない場合、Ansible は設定ファイルで指定されているデフォルトの「フォーク」制限まで、これらの操作を並列化します。しかし、ダウンタイムなしのローリングアップグレードでは、それほど多くのホストを一度に操作する必要はないでしょう。Web サーバーがほんの一握りしかない場合には、``serial`` を 1 に設定して、一度に 1 つのホストに対して行うのがよいでしょう。100 台ある場合は、``serial`` を 10 に設定して、一度に 10 台のホストを操作することもできます。" 1779 1780#: ../../rst/user_guide/guide_rolling_upgrade.rst:234 1781msgid "Here is the next part of the update play:" 1782msgstr "以下は更新プレイの次の部分です。" 1783 1784#: ../../rst/user_guide/guide_rolling_upgrade.rst:253 1785msgid "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``." 1786msgstr "``serial`` キーワードを使用すると、プレイが「バッチ」で実行されます。各バッチは、ホストのサブセレクションを使用した完全なプレイとしてカウントされます。これは、プレイの動作にいくつかの影響を与えます。たとえば、バッチ内のすべてのホストが失敗した場合、そのプレイは失敗し、その結果、全体の実行も失敗します。``max_fail_percentage`` と組み合わせる場合は、この点を考慮する必要があります。" 1787 1788#: ../../rst/user_guide/guide_rolling_upgrade.rst:256 1789msgid "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." 1790msgstr "``pre_tasks`` キーワードでは、ロールが呼び出される前に実行するタスクをリストアップすることができます。これはすぐに意味をなします。これらのタスクの名前を見ると、Nagios のアラートを無効にして、現在更新中の Web サーバーを HAProxy 負荷分散プールから削除していることがわかります。" 1791 1792#: ../../rst/user_guide/guide_rolling_upgrade.rst:258 1793msgid "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." 1794msgstr "``delegate_to`` 引数および ``loop`` 引数を一緒に使用すると、Ansible が各監視サーバーとロードバランサーをループし、Web サーバーに「代わって」監視サーバーまたは負荷分散サーバーでその操作を実行 (操作を委譲) することになります。プログラミング用語では、外部ループは Web サーバーのリスト、内部ループは監視サーバーのリストになります。" 1795 1796#: ../../rst/user_guide/guide_rolling_upgrade.rst:260 1797msgid "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." 1798msgstr "HAProxy のステップは少し複雑に見えることに注意してください。この例では HAProxy を使用していますが、これは自由に利用できるからです。しかし、(たとえば) F5 や Netscaler がインフラストラクチャーにある場合 (あるいは AWS の Elastic IP を設定している場合) は、代わりに Ansible モジュールを使用してそれらと通信することができます。nagios の代わりに他の監視モジュールを使用することもできますが、これは「事前タスク」セクションの主な目的、つまり、サーバーを監視から外し、ローテーションから外すことを示しています。" 1799 1800#: ../../rst/user_guide/guide_rolling_upgrade.rst:262 1801msgid "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:" 1802msgstr "次の手順では、適切なロールを Web サーバーに再適用するだけです。これにより、``web`` と ``base-apache`` のロールにおける構成管理宣言が Web サーバーに適用され、Web アプリケーションコード自体の更新も行われます。このようにしなくても、純粋に Web アプリケーションを更新するだけでもよいのですが、これはロールを使用してタスクを再利用する方法のよい例です。" 1803 1804#: ../../rst/user_guide/guide_rolling_upgrade.rst:271 1805msgid "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:" 1806msgstr "最後に、``post_tasks`` セクションで、Nuppet 設定への変更を元に戻し、Web サーバーを負荷分散プールに戻します。" 1807 1808#: ../../rst/user_guide/guide_rolling_upgrade.rst:289 1809msgid "Again, if you were using a Netscaler or F5 or Elastic Load Balancer, you would just substitute in the appropriate modules instead." 1810msgstr "NetScaler、F5、または Elastic Load Balancer を使用する場合は、代わりに適切なモジュールに置き換えてください。" 1811 1812#: ../../rst/user_guide/guide_rolling_upgrade.rst:294 1813msgid "Managing other load balancers" 1814msgstr "その他のロードバランサーの管理" 1815 1816#: ../../rst/user_guide/guide_rolling_upgrade.rst:296 1817msgid "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." 1818msgstr "この例では、シンプルな HAProxy ロードバランサーを Web サーバーのフロントエンドに使用しています。設定が簡単で、管理も容易です。これまで述べてきたように、Ansible は Citrix NetScaler、F5 BigIP、Amazon Elastic Load Balancer など、他のさまざまなロードバランサーをサポートしています。詳細は、「:ref:`working_with_modules`」のドキュメントをご覧ください。" 1819 1820#: ../../rst/user_guide/guide_rolling_upgrade.rst:298 1821msgid "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!" 1822msgstr "その他のロードバランサーの場合は、シェルコマンドを送信するか (上記の HAProxy の場合と同様)、ロードバランサーが API を公開している場合は API を呼び出す必要があるかもしれません。Ansible にモジュールが用意されているロードバランサーについては、API を呼び出す場合には、``local_action`` として実行することもできます。ローカルアクションについては、:ref:`playbooks_delegation` セクションで詳しく説明しています。モジュールがないハードウェアで何か面白いものを開発したら、良い貢献になるかもしれません。" 1823 1824#: ../../rst/user_guide/guide_rolling_upgrade.rst:303 1825msgid "Continuous delivery end-to-end" 1826msgstr "継続的デリバリーのエンドツーエンド" 1827 1828#: ../../rst/user_guide/guide_rolling_upgrade.rst:305 1829msgid "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." 1830msgstr "アプリケーションの更新を自動的にデプロイする方法が確立されましたが、これらをどのようにまとめたらよいでしょうか。多くの組織では、`Jenkins <https://jenkins.io/>`_ や `Atlassian Bamboo <https://www.atlassian.com/software/bamboo>`_ のような継続的統合ツールを使用して、開発、テスト、リリース、デプロイの各ステップを関連付けています。また、`Gerrit <https://www.gerritcodereview.com/>`_ のようなツールを使用して、アプリケーションコード自体か、Ansible Playbook のいずれか、または両方のコミットにコードレビューのステップを追加することもできます。" 1831 1832#: ../../rst/user_guide/guide_rolling_upgrade.rst:307 1833msgid "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." 1834msgstr "環境によっては、テスト環境に継続的にデプロイし、その環境に対して統合テストバッテリーを実行してから、実稼働環境に自動的にデプロイする場合があります。または、シンプルに保ち、ローリングアップデートを使用して、特にテスト環境または実稼働環境にオンデマンドでデプロイすることもできます。これはすべてあなた次第です。" 1835 1836#: ../../rst/user_guide/guide_rolling_upgrade.rst:309 1837msgid "For integration with Continuous Integration systems, you can easily trigger playbook runs using the ``ansible-playbook`` command line tool, or, if you're using :ref:`ansible_tower`, the ``tower-cli`` or the built-in REST API. (The tower-cli command 'joblaunch' will spawn a remote job over the REST API and is pretty slick)." 1838msgstr "継続的統合システムとの連携では、``ansible-playbook`` コマンドラインツール (:ref:`ansible_tower` を使用している場合は、``tower-cli`` や組み込み REST API) を使用して簡単に Playbook の実行をトリガーすることができます (tower-cli コマンドの「joblaunch」は、REST API を介してリモートジョブを生成し、非常に洗練されています)。" 1839 1840#: ../../rst/user_guide/guide_rolling_upgrade.rst:311 1841msgid "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." 1842msgstr "ここでは、Ansible を使用して多層アプリケーションを構築し、そのアプリケーションの操作を調整して、最終的に顧客に継続的に提供する方法を紹介しています。ローリングアップグレードの概念は、アプリケーションのさまざまな部分に広げることができます。たとえば、アプリケーションサーバーと一緒にフロントエンドの Web サーバーを追加したり、SQL データベースを MongoDB や Riak のようなものに置き換えたりすることができます。Ansible は、複雑な環境を簡単に管理し、一般的な操作を自動化する機能を提供します。" 1843 1844#: ../../rst/user_guide/guide_rolling_upgrade.rst:315 1845msgid "`lamp_haproxy example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_" 1846msgstr "`lamp_haproxy example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_" 1847 1848#: ../../rst/user_guide/guide_rolling_upgrade.rst:316 1849msgid "The lamp_haproxy example discussed here." 1850msgstr "ここで説明した lamp_haproxy の例です。" 1851 1852#: ../../rst/user_guide/guide_rolling_upgrade.rst:317 1853#: ../../rst/user_guide/intro_adhoc.rst:201 1854#: ../../rst/user_guide/intro_bsd.rst:99 1855#: ../../rst/user_guide/intro_getting_started.rst:189 1856#: ../../rst/user_guide/intro_inventory.rst:786 1857#: ../../rst/user_guide/intro_patterns.rst:166 1858#: ../../rst/user_guide/modules_intro.rst:43 1859#: ../../rst/user_guide/modules_support.rst:65 1860#: ../../rst/user_guide/playbooks_best_practices.rst:156 1861#: ../../rst/user_guide/playbooks_conditionals.rst:497 1862#: ../../rst/user_guide/playbooks_lookups.rst:26 1863#: ../../rst/user_guide/playbooks_reuse.rst:191 1864#: ../../rst/user_guide/playbooks_reuse_includes.rst:15 1865#: ../../rst/user_guide/playbooks_reuse_roles.rst:601 1866#: ../../rst/user_guide/playbooks_roles.rst:15 1867#: ../../rst/user_guide/sample_setup.rst:274 1868msgid ":ref:`working_with_playbooks`" 1869msgstr ":ref:`working_with_playbooks`" 1870 1871#: ../../rst/user_guide/guide_rolling_upgrade.rst:318 1872#: ../../rst/user_guide/playbooks_async.rst:166 1873#: ../../rst/user_guide/playbooks_blocks.rst:183 1874#: ../../rst/user_guide/playbooks_conditionals.rst:498 1875#: ../../rst/user_guide/playbooks_debugger.rst:325 1876#: ../../rst/user_guide/playbooks_delegation.rst:128 1877#: ../../rst/user_guide/playbooks_environment.rst:137 1878#: ../../rst/user_guide/playbooks_error_handling.rst:235 1879#: ../../rst/user_guide/playbooks_filters.rst:1794 1880#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:727 1881#: ../../rst/user_guide/playbooks_lookups.rst:27 1882#: ../../rst/user_guide/playbooks_loops.rst:433 1883#: ../../rst/user_guide/playbooks_prompts.rst:108 1884#: ../../rst/user_guide/playbooks_startnstep.rst:38 1885#: ../../rst/user_guide/playbooks_strategies.rst:214 1886#: ../../rst/user_guide/playbooks_tags.rst:427 1887#: ../../rst/user_guide/playbooks_templating.rst:43 1888#: ../../rst/user_guide/playbooks_tests.rst:389 1889#: ../../rst/user_guide/playbooks_variables.rst:450 1890#: ../../rst/user_guide/windows_dsc.rst:497 1891#: ../../rst/user_guide/windows_faq.rst:245 1892#: ../../rst/user_guide/windows_setup.rst:568 1893#: ../../rst/user_guide/windows_usage.rst:505 1894#: ../../rst/user_guide/windows_winrm.rst:906 1895msgid "An introduction to playbooks" 1896msgstr "Playbook の概要" 1897 1898#: ../../rst/user_guide/guide_rolling_upgrade.rst:319 1899#: ../../rst/user_guide/playbooks_blocks.rst:184 1900#: ../../rst/user_guide/playbooks_conditionals.rst:499 1901#: ../../rst/user_guide/playbooks_filters.rst:1801 1902#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:736 1903#: ../../rst/user_guide/playbooks_loops.rst:434 1904#: ../../rst/user_guide/playbooks_strategies.rst:217 1905#: ../../rst/user_guide/playbooks_tags.rst:428 1906#: ../../rst/user_guide/playbooks_templating.rst:48 1907#: ../../rst/user_guide/playbooks_tests.rst:396 1908#: ../../rst/user_guide/playbooks_variables.rst:457 1909msgid ":ref:`playbooks_reuse_roles`" 1910msgstr ":ref:`playbooks_reuse_roles`" 1911 1912#: ../../rst/user_guide/guide_rolling_upgrade.rst:320 1913msgid "An introduction to playbook roles" 1914msgstr "Playbook のロールの概要" 1915 1916#: ../../rst/user_guide/guide_rolling_upgrade.rst:321 1917#: ../../rst/user_guide/playbooks_advanced_syntax.rst:105 1918#: ../../rst/user_guide/playbooks_conditionals.rst:503 1919#: ../../rst/user_guide/playbooks_error_handling.rst:240 1920#: ../../rst/user_guide/playbooks_filters.rst:1797 1921#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:732 1922#: ../../rst/user_guide/playbooks_lookups.rst:30 1923#: ../../rst/user_guide/playbooks_loops.rst:440 1924#: ../../rst/user_guide/playbooks_prompts.rst:111 1925#: ../../rst/user_guide/playbooks_reuse.rst:193 1926#: ../../rst/user_guide/playbooks_reuse_includes.rst:19 1927#: ../../rst/user_guide/playbooks_reuse_roles.rst:605 1928#: ../../rst/user_guide/playbooks_tests.rst:392 1929msgid ":ref:`playbooks_variables`" 1930msgstr ":ref:`playbooks_variables`" 1931 1932#: ../../rst/user_guide/guide_rolling_upgrade.rst:322 1933msgid "An introduction to Ansible variables" 1934msgstr "Ansible 変数の概要" 1935 1936#: ../../rst/user_guide/guide_rolling_upgrade.rst:323 1937msgid "`Ansible.com: Continuous Delivery <https://www.ansible.com/use-cases/continuous-delivery>`_" 1938msgstr "`Ansible.com: Continuous Delivery <https://www.ansible.com/use-cases/continuous-delivery>`_" 1939 1940#: ../../rst/user_guide/guide_rolling_upgrade.rst:324 1941msgid "An introduction to Continuous Delivery with Ansible" 1942msgstr "Ansible を使用した継続的デリバリーの概要" 1943 1944#: ../../rst/user_guide/index.rst:5 1945msgid "User Guide" 1946msgstr "ユーザーガイド" 1947 1948#: ../../rst/user_guide/index.rst:9 1949msgid "**Making Open Source More Inclusive**" 1950msgstr "**多様性を受け入れるオープンソースの強化**" 1951 1952#: ../../rst/user_guide/index.rst:11 1953msgid "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>`_." 1954msgstr "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>`_ を参照してください。" 1955 1956#: ../../rst/user_guide/index.rst:13 1957msgid "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." 1958msgstr "Ansible ユーザーガイドへようこそ! 本ガイドでは、コマンドラインの使用、インベントリーの操作、データの操作、タスク、プレイ、Playbook の作成、Playbook 実行、参考資料など、Ansible の使用方法について説明しています。このページでは、読者がこのセクションを訪れる時に抱く最も一般的な状況および質問の概要を説明します。従来の目次をご希望の方は、ページ下部を参照してください。" 1959 1960#: ../../rst/user_guide/index.rst:16 1961msgid "Getting started" 1962msgstr "はじめに" 1963 1964#: ../../rst/user_guide/index.rst:18 1965msgid "I'd like an overview of how Ansible works. Where can I find:" 1966msgstr "Ansible がどのように機能するかの概要を知りたいです。どこで見つけることができますか。" 1967 1968#: ../../rst/user_guide/index.rst:20 1969msgid "a :ref:`quick video overview <quickstart_guide>`" 1970msgstr "a :ref:`クイックビデオの概要 <quickstart_guide>`" 1971 1972#: ../../rst/user_guide/index.rst:21 1973msgid "a :ref:`text introduction <intro_getting_started>`" 1974msgstr "a :ref:`テキストの紹介 <intro_getting_started>`" 1975 1976#: ../../rst/user_guide/index.rst:23 1977msgid "I'm ready to learn about Ansible. What :ref:`basic_concepts` do I need to learn?" 1978msgstr "Ansible に関する準備が整っています。どの :ref:`basic_concepts` を学ぶ必要がありますか。" 1979 1980#: ../../rst/user_guide/index.rst:24 1981msgid "I want to use Ansible without writing a playbook. How do I use :ref:`ad hoc commands <intro_adhoc>`?" 1982msgstr "Playbook を作成せずに Ansible を使用する場合は、:ref:`ad hoc commands <intro_adhoc>` をどのように使用すればいいですか。" 1983 1984#: ../../rst/user_guide/index.rst:27 1985msgid "Writing tasks, plays, and playbooks" 1986msgstr "タスク、プレイ、および Playbook の作成" 1987 1988#: ../../rst/user_guide/index.rst:29 1989msgid "I'm writing my first playbook. What should I :ref:`know before I begin <playbooks_tips_and_tricks>`?" 1990msgstr "最初の Playbook を作成します。:ref:`開始する前に学ぶ <playbooks_tips_and_tricks>` にはどうすれば良いですか。" 1991 1992#: ../../rst/user_guide/index.rst:30 1993msgid "I have a specific use case for a task or play:" 1994msgstr "タスクまたはプレイに特定のユースケースがあります。" 1995 1996#: ../../rst/user_guide/index.rst:32 1997msgid "Executing tasks with elevated privileges or as a different user with :ref:`become <become>`" 1998msgstr ":ref:`become <become>` を使用して、権限が昇格されたタスク、または別のユーザーとしてのタスクの実行" 1999 2000#: ../../rst/user_guide/index.rst:33 2001msgid "Repeating a task once for each item in a list with :ref:`loops <playbooks_loops>`" 2002msgstr ":ref:`ループ <playbooks_loops>` を使用してリスト内の項目ごとにタスクを 1 度繰り返す" 2003 2004#: ../../rst/user_guide/index.rst:34 2005msgid "Executing tasks on a different machine with :ref:`delegation <playbooks_delegation>`" 2006msgstr ":ref:`delegation <playbooks_delegation>` を使用して別のマシンでタスクを実行" 2007 2008#: ../../rst/user_guide/index.rst:35 2009msgid "Running tasks only when certain conditions apply with :ref:`conditionals <playbooks_conditionals>` and evaluating conditions with :ref:`tests <playbooks_tests>`" 2010msgstr ":ref:`conditionals <playbooks_conditionals>` で特定の条件が適用された場合にのみタスクを実行し、:ref:`tests <playbooks_tests>` で条件を評価します。" 2011 2012#: ../../rst/user_guide/index.rst:36 2013msgid "Grouping a set of tasks together with :ref:`blocks <playbooks_blocks>`" 2014msgstr ":ref:`blocks <playbooks_blocks>` を使用してタスクのセットをまとめる" 2015 2016#: ../../rst/user_guide/index.rst:37 2017msgid "Running tasks only when something has changed with :ref:`handlers <handlers>`" 2018msgstr ":ref:`handlers <handlers>` を使用して変更があった場合に限りタスクを実行" 2019 2020#: ../../rst/user_guide/index.rst:38 2021msgid "Changing the way Ansible :ref:`handles failures <playbooks_error_handling>`" 2022msgstr "Ansible が :ref:`失敗を処理する <playbooks_error_handling>` 方法の変更" 2023 2024#: ../../rst/user_guide/index.rst:39 2025msgid "Setting remote :ref:`environment values <playbooks_environment>`" 2026msgstr "リモートの :ref:`環境値 <playbooks_environment>` の設定" 2027 2028#: ../../rst/user_guide/index.rst:41 2029msgid "I want to leverage the power of re-usable Ansible artifacts. How do I create re-usable :ref:`files <playbooks_reuse>` and :ref:`roles <playbooks_reuse_roles>`?" 2030msgstr "再利用可能な Ansible アーティファクトの電源を活用するには、再利用可能な :ref:`ファイル <playbooks_reuse>` および :ref:`ロール <playbooks_reuse_roles>` をどのように作成すればいいですか。" 2031 2032#: ../../rst/user_guide/index.rst:42 2033msgid "I need to incorporate one file or playbook inside another. What is the difference between :ref:`including and importing <dynamic_vs_static>`?" 2034msgstr "あるファイルまたは Playbook を別のファイルに組み込む必要があります。:ref:`インクルードとインポート <dynamic_vs_static>` の違いは何ですか。" 2035 2036#: ../../rst/user_guide/index.rst:43 2037msgid "I want to run selected parts of my playbook. How do I add and use :ref:`tags <tags>`?" 2038msgstr "Playbook の選択した部分を実行する場合は、:ref:`タグ <tags>` をどのように追加して使用すればいいですか。" 2039 2040#: ../../rst/user_guide/index.rst:46 2041msgid "Working with inventory" 2042msgstr "インベントリーの使用" 2043 2044#: ../../rst/user_guide/index.rst:48 2045msgid "I have a list of servers and devices I want to automate. How do I create :ref:`inventory <intro_inventory>` to track them?" 2046msgstr "自動化するサーバーおよびデバイスの一覧があります。:ref:`インベントリー <intro_inventory>` を作成して追跡するにはどうすればいいですか。" 2047 2048#: ../../rst/user_guide/index.rst:49 2049msgid "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>`?" 2050msgstr "クラウドサービスを使用し、サーバーおよびデバイスの開始および停止が常にあります。:ref:`動的インベントリー <intro_dynamic_inventory>` を使用してこれらを追跡するにはどうすればいいですか。" 2051 2052#: ../../rst/user_guide/index.rst:50 2053msgid "I want to automate specific sub-sets of my inventory. How do I use :ref:`patterns <intro_patterns>`?" 2054msgstr "インベントリーの特定のサブセットを自動化したいです。:ref:`パターン <intro_patterns>` をどのように使用すればいいですか。" 2055 2056#: ../../rst/user_guide/index.rst:53 2057msgid "Interacting with data" 2058msgstr "データとの対話" 2059 2060#: ../../rst/user_guide/index.rst:55 2061msgid "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?" 2062msgstr "異なる属性を持つ複数のシステムに対して Playbook を 1 つ使用します。:ref:`変数 <playbooks_variables>` を使用して違いを処理するにはどうしたらいいですか。" 2063 2064#: ../../rst/user_guide/index.rst:56 2065msgid "I want to retrieve data about my systems. How do I access :ref:`Ansible facts <vars_and_facts>`?" 2066msgstr "システムに関するデータを取得したいです。:ref:`Ansible ファクト <vars_and_facts>` にアクセスするにはどうすればいいですか。" 2067 2068#: ../../rst/user_guide/index.rst:57 2069msgid "I need to access sensitive data like passwords with Ansible. How can I protect that data with :ref:`Ansible vault <vault>`?" 2070msgstr "Ansible でパスワードなどの機密データにアクセスする必要があります。:ref:`Ansible vault <vault>` でそのデータを保護するにはどうすればいいですか。" 2071 2072#: ../../rst/user_guide/index.rst:58 2073msgid "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?" 2074msgstr "データに変更を加えて、タスクで使用できるようにします。:ref:`フィルター <playbooks_filters>` を使用してデータを変換するにはどうすればよいですか。" 2075 2076#: ../../rst/user_guide/index.rst:59 2077msgid "I need to retrieve data from an external datastore. How do I use :ref:`lookups <playbooks_lookups>` to access databases and APIs?" 2078msgstr "外部データストアからデータを取得する必要があります。:ref:`検索 <playbooks_lookups>` を使用してデータベースおよび API にアクセスするにはどうすればいいですか。" 2079 2080#: ../../rst/user_guide/index.rst:60 2081msgid "I want to ask playbook users to supply data. How do I get user input with :ref:`prompts <playbooks_prompts>`?" 2082msgstr "Playbook ユーザーにデータを提供するよう依頼したいです。:ref:`プロンプト <playbooks_prompts>` でユーザー入力を取得するにはどうすれば良いですか。" 2083 2084#: ../../rst/user_guide/index.rst:61 2085msgid "I use certain modules frequently. How do I streamline my inventory and playbooks by :ref:`setting default values for module parameters <module_defaults>`?" 2086msgstr "特定のモジュールを頻繁に使用します。:ref:`モジュールパラメーターにデフォルト値を設定 <module_defaults>` によるインベントリーと Playbook をストリーミングするにはどうすれば良いですか。" 2087 2088#: ../../rst/user_guide/index.rst:64 2089msgid "Executing playbooks" 2090msgstr "Playbook の実行" 2091 2092#: ../../rst/user_guide/index.rst:66 2093msgid "Once your playbook is ready to run, you may need to use these topics:" 2094msgstr "Playbook の実行準備ができたら、以下のトピックを使用する必要があります。" 2095 2096#: ../../rst/user_guide/index.rst:68 2097msgid "Executing \"dry run\" playbooks with :ref:`check mode and diff <check_mode_dry>`" 2098msgstr ":ref:`確認モードおよび差異モード <check_mode_dry>` で「ドライラン」Playbook の実行" 2099 2100#: ../../rst/user_guide/index.rst:69 2101msgid "Running playbooks while troubleshooting with :ref:`start and step <playbooks_start_and_step>`" 2102msgstr ":ref:`start および step <playbooks_start_and_step>` を使用したトラブルシューティング時の Playbook の実行" 2103 2104#: ../../rst/user_guide/index.rst:70 2105msgid "Correcting tasks during execution with the :ref:`Ansible debugger <playbook_debugger>`" 2106msgstr ":ref:`Ansible デバッガ― <playbook_debugger>` で実行時のタスクの修正" 2107 2108#: ../../rst/user_guide/index.rst:71 2109msgid "Controlling how my playbook executes with :ref:`strategies and more <playbooks_strategies>`" 2110msgstr ":ref:`ストラテジーなど <playbooks_strategies>` を使用した Playbook の実行方法の制御" 2111 2112#: ../../rst/user_guide/index.rst:72 2113msgid "Running tasks, plays, and playbooks :ref:`asynchronously <playbooks_async>`" 2114msgstr "タスク、プレイ、および Playbook を :ref:`非同期に <playbooks_async>` の実行" 2115 2116#: ../../rst/user_guide/index.rst:75 2117msgid "Advanced features and reference" 2118msgstr "高度な機能および参照" 2119 2120#: ../../rst/user_guide/index.rst:77 2121msgid "Using :ref:`advanced syntax <playbooks_advanced_syntax>`" 2122msgstr ":ref:`高度な構文 <playbooks_advanced_syntax>` の使用" 2123 2124#: ../../rst/user_guide/index.rst:78 2125msgid "Manipulating :ref:`complex data <complex_data_manipulation>`" 2126msgstr ":ref:`複雑なデータ <complex_data_manipulation>` の処理" 2127 2128#: ../../rst/user_guide/index.rst:79 2129msgid "Using :ref:`plugins <plugins_lookup>`" 2130msgstr ":ref:`プラグイン <plugins_lookup>` の使用" 2131 2132#: ../../rst/user_guide/index.rst:80 2133msgid "Using :ref:`playbook keywords <playbook_keywords>`" 2134msgstr ":ref:`Playbook キーワード <playbook_keywords>` の使用" 2135 2136#: ../../rst/user_guide/index.rst:81 2137msgid "Using :ref:`command-line tools <command_line_tools>`" 2138msgstr ":ref:`コマンドラインツール <command_line_tools>` の使用" 2139 2140#: ../../rst/user_guide/index.rst:82 2141msgid "Rejecting :ref:`specific modules <plugin_filtering_config>`" 2142msgstr ":ref:`特定モジュール <plugin_filtering_config>` の拒否" 2143 2144#: ../../rst/user_guide/index.rst:83 2145msgid "Module :ref:`maintenance <modules_support>`" 2146msgstr "モジュールの :ref:`保守 <modules_support>`" 2147 2148#: ../../rst/user_guide/index.rst:86 2149msgid "Traditional Table of Contents" 2150msgstr "従来の目次" 2151 2152#: ../../rst/user_guide/index.rst:88 2153msgid "If you prefer to read the entire User Guide, here's a list of the pages in order:" 2154msgstr "本ユーザーガイドをすべて読む場合は、以下に示す順番でページを表示してください。" 2155 2156#: ../../rst/user_guide/intro.rst:4 2157msgid "Introduction" 2158msgstr "はじめに" 2159 2160#: ../../rst/user_guide/intro.rst:6 2161msgid "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)." 2162msgstr "ここでは、Ansible の主なコンポーネントである Playbook、構成管理、デプロイメント、オーケストレーションについて説明しますが、その前に、Ansible のインストール方法と基本的な概念について説明します。また、/usr/bin/ansible を使用してノード間でアドホックコマンドを並列実行する方法や、Ansible のコアにはどのようなモジュールが用意されているかを見ていきます (自分で作成することもできますが、これは後で説明します)。" 2163 2164#: ../../rst/user_guide/intro_adhoc.rst:5 2165msgid "Introduction to ad hoc commands" 2166msgstr "アドホックコマンドの概要" 2167 2168#: ../../rst/user_guide/intro_adhoc.rst:7 2169msgid "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`." 2170msgstr "Ansible アドホックコマンドは、`/usr/bin/ansible` コマンドラインツールを使用して、1 つまたは複数の管理ノード上の単一タスクを自動化します。アドホックコマンドは素早く簡単に実行できますが、再利用はできません。では、なぜ最初にアドホックコマンドを学ぶのかというと、アドホックコマンドは Ansible の簡易さと性能を実証するものだからです。ここで学んだ概念は、そのまま Playbook 言語に移植されます。これらの例を読んで実行する前に、「:ref:`intro_inventory`」を参照してください。" 2171 2172#: ../../rst/user_guide/intro_adhoc.rst:13 2173msgid "Why use ad hoc commands?" 2174msgstr "アドホックコマンドを使用する理由" 2175 2176#: ../../rst/user_guide/intro_adhoc.rst:15 2177msgid "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:" 2178msgstr "アドホックコマンドは、めったに繰り返さないタスクに最適です。たとえば、クリスマス休暇中に研究室のすべてのマシンの電源を切りたい場合は、Playbook を作成せず、Ansible で 1 行の簡単なコマンドを実行できます。アドホックコマンドは次のようなものです。" 2179 2180#: ../../rst/user_guide/intro_adhoc.rst:21 2181msgid "You can learn more about :ref:`patterns<intro_patterns>` and :ref:`modules<working_with_modules>` on other pages." 2182msgstr "他のページで、:ref:`パターン<intro_patterns>` や :ref:`モジュール<working_with_modules>` の詳細を確認できます。" 2183 2184#: ../../rst/user_guide/intro_adhoc.rst:24 2185msgid "Use cases for ad hoc tasks" 2186msgstr "アドホックタスクのユースケース" 2187 2188#: ../../rst/user_guide/intro_adhoc.rst:26 2189msgid "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." 2190msgstr "アドホックタスクは、サーバーの再起動、ファイルのコピー、パッケージやユーザーの管理など、さまざまな用途に使用できます。Ansible モジュールはアドホックタスクで使用できます。アドホックタスクは、Playbook と同様に、宣言型モデルを使用し、指定された最終状態に到達するために必要なアクションを計算して実行します。アドホックタスクは、開始前に現在の状態をチェックし、現在の状態が指定された最終状態と異なる場合を除いて何もしないことで、一種の冪等性を実現しています。" 2191 2192#: ../../rst/user_guide/intro_adhoc.rst:31 2193msgid "Rebooting servers" 2194msgstr "サーバーの再起動" 2195 2196#: ../../rst/user_guide/intro_adhoc.rst:33 2197msgid "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:" 2198msgstr "``ansible`` コマンドラインユーティリティーのデフォルトモジュールは、:ref:`ansible.builtin.command module<command_module>` です。アドホックタスクを使用してコマンドモジュールを呼び出し、Atlanta のすべての Web サーバを一度に 10 台ずつ再起動することができます。Ansible がこれを行う前に、インベントリー内の [atlanta] というグループに Atlanta にあるすべてのサーバーが記載されている必要があり、そのグループ内の各マシンの SSH 認証情報が有効でなければなりません。[atlanta] グループのすべてのサーバーを再起動するには、次のようにします。" 2199 2200#: ../../rst/user_guide/intro_adhoc.rst:39 2201msgid "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:" 2202msgstr "デフォルトでは、Ansible は 5 つの同時プロセスのみを使用します。フォーク数に設定された値よりも多くのホストがある場合、Ansible はそれらのホストと対話しますが、少し時間がかかります。10 個の並列フォークで [atlanta] サーバーを再起動する場合は、以下のようにします。" 2203 2204#: ../../rst/user_guide/intro_adhoc.rst:45 2205msgid "/usr/bin/ansible will default to running from your user account. To connect as a different user:" 2206msgstr "usr/bin/ansible はデフォルトで自身のユーザーアカウントから実行されます。別のユーザーとして接続するには、以下を行います。" 2207 2208#: ../../rst/user_guide/intro_adhoc.rst:51 2209msgid "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:" 2210msgstr "再起動には、おそらく権限昇格が必要です。``username`` としてサーバーに接続し、:ref:`become <become>` キーワードを使用して ``root`` ユーザーとしてコマンドを実行できます。" 2211 2212#: ../../rst/user_guide/intro_adhoc.rst:57 2213msgid "If you add ``--ask-become-pass`` or ``-K``, Ansible prompts you for the password to use for privilege escalation (sudo/su/pfexec/doas/etc)." 2214msgstr "``--ask-become-pass`` または ``-K`` を追加します。Ansible により、権限昇格に使用するパスワード (sudo/su/pfexec/doas など) の入力が求められます。" 2215 2216#: ../../rst/user_guide/intro_adhoc.rst:60 2217msgid "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." 2218msgstr ":ref:`command module <command_module>` は、piping や redirects のような拡張シェル構文をサポートしていません (ただし、シェル変数は常に動作します)。シェル特有の構文を必要とするコマンドの場合は、代わりに `shell` モジュールを使用してください。その違いについては「:ref:`working_with_modules`」のページをご覧ください。" 2219 2220#: ../../rst/user_guide/intro_adhoc.rst:65 2221msgid "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>`:" 2222msgstr "この例では、デフォルトの「command」モジュールを使用しています。別のモジュールを使用するには、モジュール名に ``-m`` を渡します。たとえば、:ref:`ansible.builtin.shell module <shell_module>` を使用します。" 2223 2224#: ../../rst/user_guide/intro_adhoc.rst:71 2225msgid "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." 2226msgstr "(:ref:`Playbooks <working_with_playbooks>` とは異なり) Ansible の *アドホック* CLI を使用してコマンドを実行する場合は、ローカルシェルが変数を保持して Ansible に渡すように、シェルの引用規則に特に注意してください。たとえば、上記の例で一重引用符ではなく二重引用符を使用すると、指定しているそのボックスの変数が評価されます。" 2227 2228#: ../../rst/user_guide/intro_adhoc.rst:80 2229msgid "Managing files" 2230msgstr "ファイルの管理" 2231 2232#: ../../rst/user_guide/intro_adhoc.rst:82 2233msgid "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:" 2234msgstr "アドホックタスクでは、Ansible と SCP の力を利用して、多数のファイルを複数のマシンに並行して転送することができます。[atlanta] グループのすべてのサーバーに直接ファイルを転送するには、次のようにします。" 2235 2236#: ../../rst/user_guide/intro_adhoc.rst:88 2237msgid "If you plan to repeat a task like this, use the :ref:`ansible.builtin.template<template_module>` module in a playbook." 2238msgstr "このようなタスクを繰り返す場合は、Playbook で :ref:`ansible.builtin.template<template_module>` モジュールを使用します。" 2239 2240#: ../../rst/user_guide/intro_adhoc.rst:90 2241msgid "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:" 2242msgstr ":ref:`ansible.builtin.file<file_module>` モジュールにより、ファイルの所有権およびパーミッションを変更できます。同じオプションを ``copy`` モジュールに直接渡すことができます。" 2243 2244#: ../../rst/user_guide/intro_adhoc.rst:98 2245msgid "The ``file`` module can also create directories, similar to ``mkdir -p``:" 2246msgstr "``file`` モジュールは、``mkdir -p`` と同様、ディレクトリーも作成できます。" 2247 2248#: ../../rst/user_guide/intro_adhoc.rst:104 2249msgid "As well as delete directories (recursively) and delete files:" 2250msgstr "ディレクトリーを (再帰的に) 削除し、ファイルを削除します。" 2251 2252#: ../../rst/user_guide/intro_adhoc.rst:113 2253msgid "Managing packages" 2254msgstr "パッケージの管理" 2255 2256#: ../../rst/user_guide/intro_adhoc.rst:115 2257msgid "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:" 2258msgstr "また、yum などのパッケージ管理モジュールを使用して、管理対象のノードにパッケージをインストール、アップデート、または削除するアドホックタスクを使用することもあります。パッケージを更新せずに確実にインストールするには、以下を行います。" 2259 2260#: ../../rst/user_guide/intro_adhoc.rst:121 2261msgid "To ensure a specific version of a package is installed:" 2262msgstr "パッケージの特定バージョンがインストールされていることを確認するには、次のコマンドを実行します。" 2263 2264#: ../../rst/user_guide/intro_adhoc.rst:127 2265msgid "To ensure a package is at the latest version:" 2266msgstr "パッケージが最新バージョンであることを確認するには、次のコマンドを実行します。" 2267 2268#: ../../rst/user_guide/intro_adhoc.rst:133 2269msgid "To ensure a package is not installed:" 2270msgstr "パッケージがインストールされていないことを確認するには、次のコマンドを実行します。" 2271 2272#: ../../rst/user_guide/intro_adhoc.rst:139 2273msgid "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." 2274msgstr "Ansible には、多くのプラットフォームでパッケージを管理するためのモジュールが用意されています。お使いのパッケージマネージャー用のモジュールがない場合は、コマンドモジュールを使用してパッケージをインストールするか、パッケージマネージャー用のモジュールを作成してください。" 2275 2276#: ../../rst/user_guide/intro_adhoc.rst:144 2277msgid "Managing users and groups" 2278msgstr "ユーザーおよびグループの管理" 2279 2280#: ../../rst/user_guide/intro_adhoc.rst:146 2281msgid "You can create, manage, and remove user accounts on your managed nodes with ad hoc tasks:" 2282msgstr "アドホックタスクを使用すると、管理ノードでユーザーアカウントを作成、管理、および削除できます。" 2283 2284#: ../../rst/user_guide/intro_adhoc.rst:154 2285msgid "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." 2286msgstr "グループやグループメンバーシップの操作方法など、利用可能なすべてのオプションの詳細は、:ref:`ansible.builtin.user <user_module>` モジュールのドキュメントを参照してください。" 2287 2288#: ../../rst/user_guide/intro_adhoc.rst:160 2289msgid "Managing services" 2290msgstr "サービスの管理" 2291 2292#: ../../rst/user_guide/intro_adhoc.rst:162 2293msgid "Ensure a service is started on all webservers:" 2294msgstr "サービスがすべての Web サーバーで起動していることを確認します。" 2295 2296#: ../../rst/user_guide/intro_adhoc.rst:168 2297msgid "Alternatively, restart a service on all webservers:" 2298msgstr "または、すべての Web サーバーでサービスを再起動します。" 2299 2300#: ../../rst/user_guide/intro_adhoc.rst:174 2301msgid "Ensure a service is stopped:" 2302msgstr "サービスが停止していることを確認します。" 2303 2304#: ../../rst/user_guide/intro_adhoc.rst:183 2305msgid "Gathering facts" 2306msgstr "ファクトの収集" 2307 2308#: ../../rst/user_guide/intro_adhoc.rst:185 2309msgid "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:" 2310msgstr "ファクトは、検出されたシステムに関する変数を表します。ファクトを使用して、タスクの条件付き実行を実装することもできますが、システムに関するアドホック情報を取得することもできます。すべてのファクトを表示するには、以下を実行します。" 2311 2312#: ../../rst/user_guide/intro_adhoc.rst:191 2313msgid "You can also filter this output to display only certain facts, see the :ref:`ansible.builtin.setup <setup_module>` module documentation for details." 2314msgstr "この出力をフィルターで絞り込んで、特定のファクトのみを表示することもできます。詳細は :ref:`ansible.builtin.setup <setup_module>` モジュールのドキュメントを参照してください。" 2315 2316#: ../../rst/user_guide/intro_adhoc.rst:193 2317msgid "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>`." 2318msgstr "これで、Ansible を実行する基本要素を理解し、:ref:`Ansible Playbooks <playbooks_intro>` を使用して反復タスクを自動化する方法を学ぶ準備が整いました。" 2319 2320#: ../../rst/user_guide/intro_adhoc.rst:197 2321msgid ":ref:`intro_configuration`" 2322msgstr ":ref:`intro_configuration`" 2323 2324#: ../../rst/user_guide/intro_adhoc.rst:198 2325msgid "All about the Ansible config file" 2326msgstr "Ansible 設定ファイルの詳細" 2327 2328#: ../../rst/user_guide/intro_adhoc.rst:199 2329#: ../../rst/user_guide/playbooks_best_practices.rst:158 2330#: ../../rst/user_guide/playbooks_intro.rst:146 2331#: ../../rst/user_guide/playbooks_reuse_includes.rst:25 2332#: ../../rst/user_guide/playbooks_reuse_roles.rst:613 2333#: ../../rst/user_guide/sample_setup.rst:276 2334msgid ":ref:`list_of_collections`" 2335msgstr ":ref:`list_of_collections`" 2336 2337#: ../../rst/user_guide/intro_adhoc.rst:200 2338#: ../../rst/user_guide/playbooks_best_practices.rst:159 2339#: ../../rst/user_guide/playbooks_intro.rst:147 2340#: ../../rst/user_guide/playbooks_reuse_includes.rst:26 2341#: ../../rst/user_guide/playbooks_reuse_roles.rst:614 2342#: ../../rst/user_guide/sample_setup.rst:277 2343msgid "Browse existing collections, modules, and plugins" 2344msgstr "既存のコレクション、モジュール、およびプラグインの閲覧" 2345 2346#: ../../rst/user_guide/intro_adhoc.rst:202 2347msgid "Using Ansible for configuration management & deployment" 2348msgstr "設定管理およびデプロイメントに Ansible の使用" 2349 2350#: ../../rst/user_guide/intro_adhoc.rst:203 2351#: ../../rst/user_guide/intro_bsd.rst:103 2352#: ../../rst/user_guide/intro_dynamic_inventory.rst:246 2353#: ../../rst/user_guide/intro_getting_started.rst:195 2354#: ../../rst/user_guide/intro_inventory.rst:788 2355#: ../../rst/user_guide/intro_patterns.rst:168 2356#: ../../rst/user_guide/modules.rst:33 2357#: ../../rst/user_guide/modules_intro.rst:49 2358#: ../../rst/user_guide/modules_support.rst:67 2359#: ../../rst/user_guide/playbooks_best_practices.rst:166 2360#: ../../rst/user_guide/playbooks_intro.rst:154 2361#: ../../rst/user_guide/playbooks_reuse.rst:205 2362#: ../../rst/user_guide/playbooks_reuse_includes.rst:31 2363#: ../../rst/user_guide/playbooks_reuse_roles.rst:619 2364#: ../../rst/user_guide/sample_setup.rst:284 2365msgid "`Mailing List <https://groups.google.com/group/ansible-project>`_" 2366msgstr "`Mailing List <https://groups.google.com/group/ansible-project>`_" 2367 2368#: ../../rst/user_guide/intro_bsd.rst:4 2369msgid "Ansible and BSD" 2370msgstr "Ansible および BSD" 2371 2372#: ../../rst/user_guide/intro_bsd.rst:6 2373msgid "Managing BSD machines is different from managing other Unix-like machines. If you have managed nodes running BSD, review these topics." 2374msgstr "BSD マシンの管理は、他の Unix 系マシンの管理とは異なります。BSD を実行している管理ノードを使用している場合は、以下のトピックを確認してください。" 2375 2376#: ../../rst/user_guide/intro_bsd.rst:12 2377msgid "Connecting to BSD nodes" 2378msgstr "BSD ノードへの接続" 2379 2380#: ../../rst/user_guide/intro_bsd.rst:14 2381msgid "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:" 2382msgstr "Ansible はデフォルトで OpenSSH を使用して管理ノードに接続します。これは、認証に SSH 鍵を使用している場合は BSD で動作します。ただし、認証に SSH パスワードを使用する場合、Ansible は sshpass に依存します。sshpass のほとんどのバージョンは BSD のログインプロンプトにうまく対応できません。したがって、BSD マシンに対して SSH パスワードを使用する場合は、OpenSSH の代わりに ``paramiko`` を使用して接続してください。これは ansible.cfg でグローバルに行うこともできますし、inventory/group/host 変数として設定することもできます。以下に例を示します。" 2383 2384#: ../../rst/user_guide/intro_bsd.rst:25 2385msgid "Bootstrapping BSD" 2386msgstr "BSD のブートストラップ" 2387 2388#: ../../rst/user_guide/intro_bsd.rst:27 2389msgid "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." 2390msgstr "Ansible はデフォルトでエージェントレスですが、管理ノードで Python が必要になります。:ref:`raw <raw_module>` モジュールのみが Python なしで動作します。このモジュールを使用して Ansible をブートストラップして BSD バリアントに Python をインストールできます (下記参照) が、Python は非常に制限されており、Ansible の機能を完全に活用するには Python を使用する必要があります。" 2391 2392#: ../../rst/user_guide/intro_bsd.rst:29 2393msgid "The following example installs Python 2.7 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:" 2394msgstr "次の例では、Ansible の完全な機能に必要な json ライブラリーを含む Python 2.7 をインストールしています。コントロールマシンでは、ほとんどのバージョンの FreeBSD で次のように実行できます。" 2395 2396#: ../../rst/user_guide/intro_bsd.rst:36 2397msgid "Or for OpenBSD:" 2398msgstr "OpenBSD の場合は、次のコマンドを使用します。" 2399 2400#: ../../rst/user_guide/intro_bsd.rst:42 2401msgid "Once this is done you can now use other Ansible modules apart from the ``raw`` module." 2402msgstr "これが完了すると、``raw`` モジュール以外の他の Ansible モジュールを使用できるようになります。" 2403 2404#: ../../rst/user_guide/intro_bsd.rst:45 2405msgid "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." 2406msgstr "この例では、FreeBSD では pkg を、OpenBSD では pkg_add を使用していますが、お使いの BSD に合わせて適切なパッケージツールを選択してください。また、パッケージ名も異なる場合があります。インストールする Python パッケージ名については、使用している BSD のパッケージリストやドキュメントを参照してください。" 2407 2408#: ../../rst/user_guide/intro_bsd.rst:50 2409msgid "Setting the Python interpreter" 2410msgstr "Python インタープリターの設定" 2411 2412#: ../../rst/user_guide/intro_bsd.rst:52 2413msgid "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, through the ``ansible_python_interpreter`` inventory variable. For example:" 2414msgstr "さまざまな Unix 系オペレーティングシステムやディストリビューションをサポートするために、Ansible は常に既存の環境変数や ``env`` 変数を頼りに正しい Python バイナリーを探すことはできません。デフォルトでは、モジュールは最も一般的な場所である ``/usr/bin/python`` を指します。BSD 系では、このパスが異なる場合があるので、``ansible_python_interpreter`` インベントリー変数を使用して、バイナリーの場所を Ansible に知らせることが推奨されます。以下に例を示します。" 2415 2416#: ../../rst/user_guide/intro_bsd.rst:61 2417msgid "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:" 2418msgstr "Ansible でバンドルされているプラグイン以外のプラグインを使用する場合は、プラグインの記述方法に応じて ``bash``、``perl``、または ``ruby`` に同様の変数を設定できます。" 2419 2420#: ../../rst/user_guide/intro_bsd.rst:71 2421msgid "Which modules are available?" 2422msgstr "利用可能なモジュール" 2423 2424#: ../../rst/user_guide/intro_bsd.rst:73 2425msgid "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)." 2426msgstr "Ansible のコアモジュールの大半は、Unix 系マシンと他の汎用サービスを組み合わせて記述されているため、Linux に限定したテクノロジー (LVG など) を対象とするものを除き、その大半が BSD 上で正常に機能します。" 2427 2428#: ../../rst/user_guide/intro_bsd.rst:76 2429msgid "Using BSD as the control node" 2430msgstr "コントロールノードとしての BSD の使用" 2431 2432#: ../../rst/user_guide/intro_bsd.rst:78 2433msgid "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." 2434msgstr "BSD をコントロールマシンとして使用することは、BSD バリアントの Ansible パッケージをインストールするか、``pip`` または「from source」の指示に従うのと同じくらい簡単です。" 2435 2436#: ../../rst/user_guide/intro_bsd.rst:83 2437msgid "BSD facts" 2438msgstr "BSD ファクト" 2439 2440#: ../../rst/user_guide/intro_bsd.rst:85 2441msgid "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." 2442msgstr "Ansible は、Linux マシンと同様の方法で BSD からファクトを収集しますが、データ、名前、構造は、ネットワーク、ディスク、およびその他のデバイスにより異なる可能性があるため、BSD 管理者にとっては出力が多少異なるもののまだ馴染みがあることが期待できます。" 2443 2444#: ../../rst/user_guide/intro_bsd.rst:90 2445msgid "BSD efforts and contributions" 2446msgstr "BSD の取り組みおよび貢献" 2447 2448#: ../../rst/user_guide/intro_bsd.rst:92 2449msgid "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!" 2450msgstr "BSD サポートは Ansible にとって重要です。貢献者の大半は Linux を使用していますが、Ansible には活発な BSD コミュニティーがあり、可能な限り BSD フレンドリーであるように努めています。BSD に関する問題や非互換性を発見した場合は、遠慮なくご報告ください。" 2451 2452#: ../../rst/user_guide/intro_bsd.rst:97 2453#: ../../rst/user_guide/intro_getting_started.rst:187 2454#: ../../rst/user_guide/intro_inventory.rst:784 2455#: ../../rst/user_guide/intro_patterns.rst:164 2456#: ../../rst/user_guide/modules.rst:23 2457#: ../../rst/user_guide/modules_intro.rst:41 2458#: ../../rst/user_guide/modules_support.rst:63 2459msgid ":ref:`intro_adhoc`" 2460msgstr ":ref:`intro_adhoc`" 2461 2462#: ../../rst/user_guide/intro_bsd.rst:98 2463#: ../../rst/user_guide/intro_getting_started.rst:188 2464#: ../../rst/user_guide/intro_inventory.rst:785 2465#: ../../rst/user_guide/intro_patterns.rst:165 2466msgid "Examples of basic commands" 2467msgstr "基本コマンドの例" 2468 2469#: ../../rst/user_guide/intro_bsd.rst:100 2470msgid "Learning ansible's configuration management language" 2471msgstr "Ansible の設定管理言語の概要" 2472 2473#: ../../rst/user_guide/intro_bsd.rst:101 2474#: ../../rst/user_guide/modules_intro.rst:45 2475#: ../../rst/user_guide/playbooks_best_practices.rst:160 2476#: ../../rst/user_guide/playbooks_intro.rst:148 2477#: ../../rst/user_guide/playbooks_reuse_includes.rst:27 2478#: ../../rst/user_guide/playbooks_reuse_roles.rst:615 2479#: ../../rst/user_guide/sample_setup.rst:278 2480msgid ":ref:`developing_modules`" 2481msgstr ":ref:`developing_modules`" 2482 2483#: ../../rst/user_guide/intro_bsd.rst:102 2484msgid "How to write modules" 2485msgstr "モジュールの書き方" 2486 2487#: ../../rst/user_guide/intro_dynamic_inventory.rst:6 2488msgid "Working with dynamic inventory" 2489msgstr "動的インベントリーの使用" 2490 2491#: ../../rst/user_guide/intro_dynamic_inventory.rst:11 2492msgid "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." 2493msgstr "Ansible のインベントリーが、ビジネス上の要求に応じてホストの回転や停止など、時間とともに変動する場合は、:ref:`inventory` で説明している静的なインベントリーソリューションではニーズに応えられません。クラウドプロバイダー、LDAP、`Cobbler <https://cobbler.github.io>`_、エンタープライズ CMDB システムなど、複数のソースからのホストの追跡が必要になる場合があります。" 2494 2495#: ../../rst/user_guide/intro_dynamic_inventory.rst:13 2496msgid "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`." 2497msgstr "Ansible は、動的な外部インベントリーシステムを通じて、これらのオプションをすべて統合します。Ansible は、外部インベントリーに接続する 2 つの方法 (:ref:`inventory_plugins` および `inventory scripts`) をサポートしています。" 2498 2499#: ../../rst/user_guide/intro_dynamic_inventory.rst:15 2500msgid "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." 2501msgstr "インベントリープラグインは、Ansible コアコードの最新の更新を利用しています。動的インベントリーには、スクリプトよりもプラグインが推奨されます。:ref:`独自のプラグインを記述 <developing_inventory>` して、追加の動的インベントリーソースに接続することができます。" 2502 2503#: ../../rst/user_guide/intro_dynamic_inventory.rst:17 2504msgid "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." 2505msgstr "また、インベントリースクリプトを使用することもできます。インベントリープラグインを実装する際に、スクリプトインベントリープラグインによる後方互換性を確保しました。以下の例では、インベントリースクリプトの使用方法を説明しています。" 2506 2507#: ../../rst/user_guide/intro_dynamic_inventory.rst:19 2508msgid "If you prefer a GUI for handling dynamic inventory, the :ref:`ansible_tower` inventory database 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." 2509msgstr "動的インベントリーを GUI で操作したい場合は、:ref:`ansible_tower` インベントリーデータベースがすべての動的インベントリーソースと同期し、その結果に Web および REST アクセスを提供し、グラフィカルインベントリーエディターを提供します。すべてのホストのデータベースレコードを使用して、過去のイベント履歴を関連付け、最後の Playbook の実行でどのホストに障害が発生したかを確認できます。" 2510 2511#: ../../rst/user_guide/intro_dynamic_inventory.rst:24 2512msgid "Inventory script example: Cobbler" 2513msgstr "インベントリースクリプトの例: Cobbler" 2514 2515#: ../../rst/user_guide/intro_dynamic_inventory.rst:26 2516msgid "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." 2517msgstr "Ansible は、Linux インストールサーバー `Cobbler <https://cobbler.github.io>`_ (最初に Michael DeHaan 氏が作成し、現在は Ansible に所属する James Cammarata が率いています) とシームレスに統合されます。" 2518 2519#: ../../rst/user_guide/intro_dynamic_inventory.rst:28 2520msgid "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'." 2521msgstr "Cobbler は主に OS のインストールを開始し、DHCP と DNS を管理するために使用されますが、複数の構成管理システムのデータを (同時にでも) 表現し、「軽量CMDB」として機能する汎用レイヤーがあります。" 2522 2523#: ../../rst/user_guide/intro_dynamic_inventory.rst:31 2524msgid "To tie your Ansible inventory to Cobbler, copy `this script <https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/cobbler.py>`_ to ``/usr/local/etc/ansible`` and ``chmod +x`` the file. Run ``cobblerd`` any time you use Ansible and use the ``-i`` command line option (for example, ``-i /usr/local/etc/ansible/cobbler.py``) to communicate with Cobbler using Cobbler's XMLRPC API." 2525msgstr "Ansible インベントリーを Cobbler に関連付けるには、`このスクリプト <https://raw.githubusercontent.com/ansible-community/contrib-scripts/main/inventory/cobbler.py>`_ を ``/usr/local/etc/ansible`` にコピーして、コピーしたファイルに ``chmod +x`` を付与します。Ansible を使用して ``cobblerd`` を実行し、``-i`` コマンドラインオプション (例: ``-i /usr/local/etc/ansible/cobbler.py``) を付けて、Cobbler の XMLRPC API 使用して Cobbler と通信します。" 2526 2527#: ../../rst/user_guide/intro_dynamic_inventory.rst:33 2528msgid "Add a ``cobbler.ini`` file in ``/usr/local/etc/ansible`` so Ansible knows where the Cobbler server is and some cache improvements can be used. For example:" 2529msgstr "Ansible が Cobbler サーバーの場所とキャッシュの改良に使用できるものを認識できるように、``/usr/local/etc/ansible`` に ``cobbler.ini`` ファイルを追加します。以下に例を示します。" 2530 2531#: ../../rst/user_guide/intro_dynamic_inventory.rst:56 2532msgid "First test the script by running ``/usr/local/etc/ansible/cobbler.py`` directly. You should see some JSON data output, but it may not have anything in it just yet." 2533msgstr "まず ``/usr/local/etc/ansible/cobbler.py`` を直接実行してスクリプトをテストします。JSON データ出力が表示されますが、まだ何も含まれていない場合もあります。" 2534 2535#: ../../rst/user_guide/intro_dynamic_inventory.rst:58 2536msgid "Let's explore what this does. In Cobbler, assume a scenario somewhat like the following:" 2537msgstr "これで何ができるのか見てみましょう。Cobbler で、次のようなシナリオを想定します。" 2538 2539#: ../../rst/user_guide/intro_dynamic_inventory.rst:67 2540msgid "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'." 2541msgstr "上の例では、システム「foo.example.com」は、ansible が直接アドレスを指定できるだけでなく、グループ名「webserver」や「atlanta」を使用してもアドレスを指定できます。Ansible は SSH を使用しているため、「foo.example.com」を経由してシステム foo に接続しますが、決して「foo」だけではありません。同様に、「ansible foo」と入力しても、システムを見つけることはできませんが、「ansible 'foo'*」と入力すると、システムの DNS 名が 'foo' で始まるため、システムを見つけることができます。" 2542 2543#: ../../rst/user_guide/intro_dynamic_inventory.rst:69 2544msgid "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:" 2545msgstr "このスクリプトは、ホストとグループの情報以外にもさまざまな情報を提供します。さらに、(Playbook を使用する際に自動的に実行される)「setup」モジュールを実行すると、変数「a」、「b」、および「c」はすべてテンプレートに自動入力されるようになります。" 2546 2547#: ../../rst/user_guide/intro_dynamic_inventory.rst:76 2548msgid "Which could be executed just like this:" 2549msgstr "これは以下のように実行できます。" 2550 2551#: ../../rst/user_guide/intro_dynamic_inventory.rst:84 2552msgid "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." 2553msgstr "「webserver」という名前は、設定ファイルの変数と同様に、Cobbler から来ています。Ansible では通常のように独自の変数を渡すことができますが、外部のインベントリースクリプトからの変数は、同じ名前のものを上書きします。" 2554 2555#: ../../rst/user_guide/intro_dynamic_inventory.rst:89 2556msgid "So, with the template above (``motd.j2``), this results in the following data being written to ``/etc/motd`` for system 'foo':" 2557msgstr "そのため、上記のテンプレート (``motd.j2``) を使用すると、以下のデータがシステム「foo」用に ``/etc/motd`` に書き込まれます。" 2558 2559#: ../../rst/user_guide/intro_dynamic_inventory.rst:95 2560msgid "And on system 'bar' (bar.example.com):" 2561msgstr "システム「bar」(bar.example.com) は、以下のようになります。" 2562 2563#: ../../rst/user_guide/intro_dynamic_inventory.rst:101 2564msgid "And technically, though there is no major good reason to do it, this also works:" 2565msgstr "技術的には、これを行う大きな正当な理由はありませんが、これも機能します。" 2566 2567#: ../../rst/user_guide/intro_dynamic_inventory.rst:107 2568msgid "So, in other words, you can use those variables in arguments/actions as well." 2569msgstr "つまり、引数やアクションでこの変数を使用することもできます。" 2570 2571#: ../../rst/user_guide/intro_dynamic_inventory.rst:112 2572msgid "Inventory script example: OpenStack" 2573msgstr "インベントリースクリプトの例: OpenStack" 2574 2575#: ../../rst/user_guide/intro_dynamic_inventory.rst:114 2576msgid "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." 2577msgstr "独自のインベントリーファイルを手動で管理する代わりに、OpenStack ベースのクラウドを使用する場合は、動的インベントリー ``openstack_inventory.py`` を使用して、OpenStack から直接 Compute インスタンスに関する情報を取得できます。" 2578 2579#: ../../rst/user_guide/intro_dynamic_inventory.rst:116 2580msgid "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>`_." 2581msgstr "最新バージョンの OpenStack インベントリースクリプトは、`こちら <https://raw.githubusercontent.com/openstack/ansible-collections-openstack/master/scripts/inventory/openstack_inventory.py>`_ からダウンロードできます。" 2582 2583#: ../../rst/user_guide/intro_dynamic_inventory.rst:118 2584msgid "You can use the inventory script explicitly (by passing the `-i openstack_inventory.py` argument to Ansible) or implicitly (by placing the script at `/usr/local/etc/ansible/hosts`)." 2585msgstr "(`-i openstack_inventory.py` 引数を Ansible に渡すことで) インベントリースクリプトを明示的に使用するか、(スクリプトを `/usr/local/etc/ansible/hosts` において) 暗黙的に使用できます。" 2586 2587#: ../../rst/user_guide/intro_dynamic_inventory.rst:121 2588msgid "Explicit use of OpenStack inventory script" 2589msgstr "OpenStack インベントリースクリプトの明示的な使用" 2590 2591#: ../../rst/user_guide/intro_dynamic_inventory.rst:123 2592msgid "Download the latest version of the OpenStack dynamic inventory script and make it executable::" 2593msgstr "最新バージョンの OpenStack の動的インベントリースクリプトをダウンロードし、実行可能にします。" 2594 2595#: ../../rst/user_guide/intro_dynamic_inventory.rst:129 2596msgid "Do not name it `openstack.py`. This name will conflict with imports from openstacksdk." 2597msgstr "`openstack.py` という名前はつけないでください。この名前は、openstacksdk からのインポートと競合します。" 2598 2599#: ../../rst/user_guide/intro_dynamic_inventory.rst:131 2600msgid "Source an OpenStack RC file:" 2601msgstr "OpenStack RC ファイルを読み込みます。" 2602 2603#: ../../rst/user_guide/intro_dynamic_inventory.rst:139 2604msgid "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>`_." 2605msgstr "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>`_」を参照してください。" 2606 2607#: ../../rst/user_guide/intro_dynamic_inventory.rst:141 2608msgid "You can confirm the file has been successfully sourced by running a simple command, such as `nova list` and ensuring it returns no errors." 2609msgstr "`nova list` などの単純なコマンドを実行してエラーを返さないようにすることで、ファイルが正常に読み込まれたことを確認できます。" 2610 2611#: ../../rst/user_guide/intro_dynamic_inventory.rst:145 2612msgid "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>`_." 2613msgstr "`nova list` コマンドを実行するには、OpenStack コマンドラインクライアントが必要です。インストール方法の詳細は、「`Install the OpenStack command-line clients <https://docs.openstack.org/user-guide/common/cli_install_openstack_command_line_clients.html>`_」を参照してください。" 2614 2615#: ../../rst/user_guide/intro_dynamic_inventory.rst:147 2616msgid "You can test the OpenStack dynamic inventory script manually to confirm it is working as expected::" 2617msgstr "OpenStack の動的インベントリースクリプトを手動でテストして、想定どおりに機能していることを確認します。" 2618 2619#: ../../rst/user_guide/intro_dynamic_inventory.rst:151 2620#: ../../rst/user_guide/intro_dynamic_inventory.rst:184 2621msgid "After a few moments you should see some JSON output with information about your compute instances." 2622msgstr "しばらくすると、Compute インスタンスに関する情報が含まれる JSON 出力が表示されます。" 2623 2624#: ../../rst/user_guide/intro_dynamic_inventory.rst:153 2625msgid "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:" 2626msgstr "動的インベントリースクリプトが想定どおりに機能していることを確認したら、以下のように Ansible が `openstack_inventory.py` スクリプトをインベントリーファイルとして使用するように指定します。" 2627 2628#: ../../rst/user_guide/intro_dynamic_inventory.rst:160 2629msgid "Implicit use of OpenStack inventory script" 2630msgstr "OpenStack インベントリースクリプトの暗黙的な使用" 2631 2632#: ../../rst/user_guide/intro_dynamic_inventory.rst:162 2633msgid "Download the latest version of the OpenStack dynamic inventory script, make it executable and copy it to `/usr/local/etc/ansible/hosts`:" 2634msgstr "最新バージョンの OpenStack 動的インベントリースクリプトをダウンロードし、実行可能にし、これを `/usr/local/etc/ansible/hosts` にコピーします。" 2635 2636#: ../../rst/user_guide/intro_dynamic_inventory.rst:170 2637msgid "Download the sample configuration file, modify it to suit your needs and copy it to `/usr/local/etc/ansible/openstack.yml`:" 2638msgstr "サンプル設定ファイルをダウンロードし、必要に応じて変更し、これを `/usr/local/etc/ansible/openstack.yml` にコピーします。" 2639 2640#: ../../rst/user_guide/intro_dynamic_inventory.rst:178 2641msgid "You can test the OpenStack dynamic inventory script manually to confirm it is working as expected:" 2642msgstr "OpenStack 動的インベントリースクリプトを手動でテストして、想定どおりに機能していることを確認します。" 2643 2644#: ../../rst/user_guide/intro_dynamic_inventory.rst:187 2645msgid "Refreshing the cache" 2646msgstr "キャッシュの更新" 2647 2648#: ../../rst/user_guide/intro_dynamic_inventory.rst:189 2649msgid "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:" 2650msgstr "OpenStack 動的インベントリースクリプトは、API 呼び出しが繰り返し行われるのを防ぐために、結果をキャッシュすることに注意してください。キャッシュを明示的に消去するには、``--refresh`` パラメーターを使用して openstack_inventory.py (または hosts) スクリプトを実行します。" 2651 2652#: ../../rst/user_guide/intro_dynamic_inventory.rst:198 2653msgid "Other inventory scripts" 2654msgstr "その他のインベントリースクリプト" 2655 2656#: ../../rst/user_guide/intro_dynamic_inventory.rst:200 2657msgid "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." 2658msgstr "Ansible 2.10 以降では、インベントリースクリプトは関連するコレクションに移動しました。現在、多くのスクリプトは `community.general scripts/inventory directory <https://github.com/ansible-collections/community.general/tree/main/scripts/inventory>`_ にあります。代わりに :ref:`inventory_plugins` を使用することが推奨されます。" 2659 2660#: ../../rst/user_guide/intro_dynamic_inventory.rst:205 2661msgid "Using inventory directories and multiple inventory sources" 2662msgstr "インベントリーディレクトリーおよび複数のインベントリーソースの使用" 2663 2664#: ../../rst/user_guide/intro_dynamic_inventory.rst:207 2665msgid "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!" 2666msgstr "Ansible で ``-i`` に指定される場所がディレクトリーの場合 (または ``ansible.cfg`` でそのように設定されている場合)、Ansible は複数のインベントリーソースを同時に使用できます。これを実行する場合は、同じ Ansible 実行で動的および静的に管理されているインベントリーソースを混在させることができます。" 2667 2668#: ../../rst/user_guide/intro_dynamic_inventory.rst:211 2669msgid "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:" 2670msgstr "インベントリーディレクトリでは、実行ファイルは動的インベントリーソースとして、その他のほとんどのファイルは静的ソースとして扱われます。以下のいずれかで終わるファイルは無視されます。" 2671 2672#: ../../rst/user_guide/intro_dynamic_inventory.rst:217 2673msgid "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." 2674msgstr "この一覧は、``ansible.cfg`` で ``inventory_ignore_extensions`` 一覧を設定するか、:envvar:`ANSIBLE_INVENTORY_IGNORE` 環境変数を設定して独自の選択に置き換えることができます。いずれの値も、上記のようにパターンのコンマ区切りの一覧である必要があります。" 2675 2676#: ../../rst/user_guide/intro_dynamic_inventory.rst:219 2677msgid "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." 2678msgstr "インベントリーディレクトリーの ``group_vars`` サブディレクトリーおよび ``host_vars`` サブディレクトリーは想定どおりに解釈されるため、インベントリーディレクトリーはさまざまな構成セットを整理するための強力な方法になります。詳細は、「:ref:`using_multiple_inventory_sources`」を参照してください。" 2679 2680#: ../../rst/user_guide/intro_dynamic_inventory.rst:224 2681msgid "Static groups of dynamic groups" 2682msgstr "動的グループの静的グループ" 2683 2684#: ../../rst/user_guide/intro_dynamic_inventory.rst:226 2685msgid "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:" 2686msgstr "静的インベントリーファイルでグループのグループを定義する場合は、子グループも静的インベントリーファイルで定義されていなければ、Ansible はエラーを返します。動的な子グループの静的グループを定義する場合は、静的インベントリーファイルで動的グループを空に定義してください。以下に例を示します。" 2687 2688#: ../../rst/user_guide/intro_dynamic_inventory.rst:244 2689#: ../../rst/user_guide/intro_getting_started.rst:185 2690msgid ":ref:`intro_inventory`" 2691msgstr ":ref:`intro_inventory`" 2692 2693#: ../../rst/user_guide/intro_dynamic_inventory.rst:245 2694msgid "All about static inventory files" 2695msgstr "静的インベントリーファイルの詳細" 2696 2697#: ../../rst/user_guide/intro_getting_started.rst:5 2698msgid "Getting Started" 2699msgstr "はじめに" 2700 2701#: ../../rst/user_guide/intro_getting_started.rst:7 2702msgid "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:" 2703msgstr "「:ref:`インストールガイド<installation_guide>`」を読み、コントロールノードに Ansible をインストールしたら、Ansible の仕組みを学ぶ準備ができました。基本的な Ansible のコマンドや Playbook です。" 2704 2705#: ../../rst/user_guide/intro_getting_started.rst:9 2706msgid "selects machines to execute against from inventory" 2707msgstr "インベントリーから実行するマシンを選択する" 2708 2709#: ../../rst/user_guide/intro_getting_started.rst:10 2710msgid "connects to those machines (or network devices, or other managed nodes), usually over SSH" 2711msgstr "通常は SSH 経由で、このマシン (もしくはネットワークデバイスまたはその他の管理対象ノード) に接続する" 2712 2713#: ../../rst/user_guide/intro_getting_started.rst:11 2714msgid "copies one or more modules to the remote machines and starts execution there" 2715msgstr "1 つ以上のモジュールをリモートマシンにコピーし、そこで実行を開始する" 2716 2717#: ../../rst/user_guide/intro_getting_started.rst:13 2718msgid "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>`." 2719msgstr "Ansible はさらに多くのことができますが、Ansible の強力な設定、デプロイメント、オーケストレーション機能をすべて試す前に、最も一般的な使用例を理解しておく必要があります。このページでは、簡単なインベントリーとアドホックコマンドを使用して、基本的なプロセスを説明しています。Ansible の仕組みを理解したら、:ref:`ad hoc commands<intro_adhoc>` の詳細を読み、:ref:`inventory<intro_inventory>` でインフラストラクチャーを整理し、:ref:`playbooks<playbooks_intro>` で Ansible の機能を最大限に活用することができます。" 2720 2721#: ../../rst/user_guide/intro_getting_started.rst:19 2722msgid "Selecting machines from inventory" 2723msgstr "インベントリーからのマシンの選択" 2724 2725#: ../../rst/user_guide/intro_getting_started.rst:21 2726msgid "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." 2727msgstr "Ansible は、インベントリーから管理したいマシンの情報を読み込みます。アドホックコマンドに IP アドレスを渡すこともできますが、Ansible の柔軟性と再現性を最大限に活用するにはインベントリーが必要です。" 2728 2729#: ../../rst/user_guide/intro_getting_started.rst:24 2730msgid "Action: create a basic inventory" 2731msgstr "アクション: 基本的なインベントリーの作成" 2732 2733#: ../../rst/user_guide/intro_getting_started.rst:25 2734msgid "For this basic inventory, edit (or create) ``/usr/local/etc/ansible/hosts`` and add a few remote systems to it. For this example, use either IP addresses or FQDNs:" 2735msgstr "この基本的なインベントリーでは、``/usr/local/etc/ansible/hosts`` を編集 (または作成) し、リモートシステムをいくつか追加します。たとえば、IP アドレスまたは FQDN を使用します。" 2736 2737#: ../../rst/user_guide/intro_getting_started.rst:34 2738#: ../../rst/user_guide/intro_getting_started.rst:49 2739#: ../../rst/user_guide/intro_getting_started.rst:150 2740msgid "Beyond the basics" 2741msgstr "中級編" 2742 2743#: ../../rst/user_guide/intro_getting_started.rst:35 2744msgid "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>`." 2745msgstr "インベントリーには、IP や FQDN 以外にも多くの情報を保存することができます。:ref:`エイリアス<inventory_aliases>` を作成したり、:ref:`host 変数<host_variables>` で単一のホストに変数値を設定したり、:ref:`group 変数<group_variables>` で複数のホストに変数値を設定したりすることができます。" 2746 2747#: ../../rst/user_guide/intro_getting_started.rst:40 2748msgid "Connecting to remote nodes" 2749msgstr "リモートノードへの接続" 2750 2751#: ../../rst/user_guide/intro_getting_started.rst:42 2752msgid "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." 2753msgstr "Ansible は `SSH プロトコル <https://www.ssh.com/ssh/protocol/>`_ でリモートマシンと通信します。デフォルトでは、Ansible はネイティブの OpenSSH を使用し、SSH と同様に現在のユーザー名を使用してリモートマシンに接続します。" 2754 2755#: ../../rst/user_guide/intro_getting_started.rst:45 2756msgid "Action: check your SSH connections" 2757msgstr "アクション: SSH 接続の確認" 2758 2759#: ../../rst/user_guide/intro_getting_started.rst:46 2760msgid "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." 2761msgstr "インベントリー内のすべてのノードに、同じユーザー名で SSH 接続できることを確認します。必要に応じて、これらのシステムの ``authorized_keys`` ファイルに自分の公開 SSH 鍵を追加します。" 2762 2763#: ../../rst/user_guide/intro_getting_started.rst:50 2764msgid "You can override the default remote user name in several ways, including:" 2765msgstr "次のようないくつかの方法で、デフォルトのリモートユーザー名を上書きできます。" 2766 2767#: ../../rst/user_guide/intro_getting_started.rst:52 2768msgid "passing the ``-u`` parameter at the command line" 2769msgstr "コマンドラインで ``-u`` パラメーターを渡す" 2770 2771#: ../../rst/user_guide/intro_getting_started.rst:53 2772msgid "setting user information in your inventory file" 2773msgstr "インベントリーファイルにユーザー情報を設定する" 2774 2775#: ../../rst/user_guide/intro_getting_started.rst:54 2776msgid "setting user information in your configuration file" 2777msgstr "設定ファイルにユーザー情報を設定する" 2778 2779#: ../../rst/user_guide/intro_getting_started.rst:55 2780msgid "setting environment variables" 2781msgstr "追加の環境変数を設定する" 2782 2783#: ../../rst/user_guide/intro_getting_started.rst:57 2784msgid "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`." 2785msgstr "ユーザー情報を渡す各メソッドの優先順位 (意図しない場合もあります) の詳細は、「:ref:`general_precedence_rules`」を参照してください。接続については、「:ref:`connections`」を参照してください。" 2786 2787#: ../../rst/user_guide/intro_getting_started.rst:60 2788msgid "Copying and executing modules" 2789msgstr "モジュールのコピーおよび実行" 2790 2791#: ../../rst/user_guide/intro_getting_started.rst:62 2792msgid "Once it has connected, Ansible transfers the modules required by your command or playbook to the remote machine(s) for execution." 2793msgstr "接続後、Ansible はコマンドまたは Playbook が必要とするモジュールをリモートマシンに転送して実行します。" 2794 2795#: ../../rst/user_guide/intro_getting_started.rst:65 2796msgid "Action: run your first Ansible commands" 2797msgstr "アクション: 最初の Ansible コマンドの実行" 2798 2799#: ../../rst/user_guide/intro_getting_started.rst:66 2800msgid "Use the ping module to ping all the nodes in your inventory:" 2801msgstr "ping モジュールを使用して、インベントリー内のすべてのノードに対して ping を実行します。" 2802 2803#: ../../rst/user_guide/intro_getting_started.rst:72 2804#: ../../rst/user_guide/intro_getting_started.rst:92 2805msgid "You should see output for each host in your inventory, similar to this:" 2806msgstr "次のようなインベントリー内の各ホストの出力が表示されます。" 2807 2808#: ../../rst/user_guide/intro_getting_started.rst:84 2809msgid "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'." 2810msgstr "``-u`` は、接続するユーザーを指定する 1 つの方法として使用できます。デフォルトでは、Ansible は SSH を使用しますが、SSH ではデフォルトで「現在のユーザー」が指定されます。" 2811 2812#: ../../rst/user_guide/intro_getting_started.rst:86 2813msgid "Now run a live command on all of your nodes:" 2814msgstr "全ノードでライブコマンドを実行します。" 2815 2816#: ../../rst/user_guide/intro_getting_started.rst:100 2817msgid "Action: Run your first playbook" 2818msgstr "アクション: 最初の Playbook の実行" 2819 2820#: ../../rst/user_guide/intro_getting_started.rst:102 2821msgid "Playbooks are used to pull together tasks into reusable units." 2822msgstr "Playbook は、複数のタスクを再利用可能な単位にプルするために使用されます。" 2823 2824#: ../../rst/user_guide/intro_getting_started.rst:104 2825msgid "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." 2826msgstr "Ansible は、Playbook を保存しません。Playbook は、保存および管理する単純な YAML ドキュメントであり、必要に応じて実行するために Ansible に渡します。" 2827 2828#: ../../rst/user_guide/intro_getting_started.rst:106 2829msgid "In a directory of your choice you can create your first playbook in a file called mytask.yml:" 2830msgstr "任意のディレクトリーでは、mytask.yml という名前のファイルに最初の Playbook を作成できます。" 2831 2832#: ../../rst/user_guide/intro_getting_started.rst:117 2833msgid "You can run this command as follows:" 2834msgstr "このコマンドは、以下のように実行できます。" 2835 2836#: ../../rst/user_guide/intro_getting_started.rst:123 2837msgid "and may see output like this:" 2838msgstr "また、以下のような出力が表示される可能性があります。" 2839 2840#: ../../rst/user_guide/intro_getting_started.rst:147 2841msgid "Read on to learn more about controlling which nodes your playbooks execute on, more sophisticated tasks, and the meaning of the output." 2842msgstr "Playbook が実行するノード、より高度なタスク、および出力の意味を把握するには、こちらを参照してください。" 2843 2844#: ../../rst/user_guide/intro_getting_started.rst:151 2845msgid "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." 2846msgstr "Ansible のデフォルトでは、ファイルの転送に SFTP を使用します。管理するマシンやデバイスが SFTP をサポートしていない場合は、:ref:`intro_configuration` で SCP モードに切り替えることができます。ファイルは一時ディレクトリーに置かれ、そこから実行されます。" 2847 2848#: ../../rst/user_guide/intro_getting_started.rst:153 2849msgid "If you need privilege escalation (sudo and similar) to run a command, pass the ``become`` flags:" 2850msgstr "コマンドを実行する権限昇格 (sudo など) が必要な場合は、``become`` フラグを渡します。" 2851 2852#: ../../rst/user_guide/intro_getting_started.rst:164 2853msgid "You can read more about privilege escalation in :ref:`become`." 2854msgstr "権限の昇格の詳細は、「:ref:`become`」を参照してください。" 2855 2856#: ../../rst/user_guide/intro_getting_started.rst:166 2857msgid "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." 2858msgstr "これで、Ansible を使用してノードに接続できました。基本的なインベントリーファイルとアドホックコマンドを使用して、Ansible が特定のリモートノードに接続し、そこにモジュールファイルをコピーして実行し、出力を返すように指示しました。これで完全に機能するインフラストラクチャーが完成しました。" 2859 2860#: ../../rst/user_guide/intro_getting_started.rst:169 2861msgid "Resources" 2862msgstr "リソース" 2863 2864#: ../../rst/user_guide/intro_getting_started.rst:170 2865msgid "`Product Demos <https://github.com/ansible/product-demos>`_" 2866msgstr "`Product Demos <https://github.com/ansible/product-demos>`_" 2867 2868#: ../../rst/user_guide/intro_getting_started.rst:171 2869msgid "`Katakoda <https://katacoda.com/rhel-labs>`_" 2870msgstr "`Katakoda <https://katacoda.com/rhel-labs>`_" 2871 2872#: ../../rst/user_guide/intro_getting_started.rst:172 2873msgid "`Workshops <https://github.com/ansible/workshops>`_" 2874msgstr "`Workshops <https://github.com/ansible/workshops>`_" 2875 2876#: ../../rst/user_guide/intro_getting_started.rst:173 2877msgid "`Ansible Examples <https://github.com/ansible/ansible-examples>`_" 2878msgstr "`Ansible Examples <https://github.com/ansible/ansible-examples>`_" 2879 2880#: ../../rst/user_guide/intro_getting_started.rst:174 2881msgid "`Ansible Baseline <https://github.com/ansible/ansible-baseline>`_" 2882msgstr "`Ansible Baseline <https://github.com/ansible/ansible-baseline>`_" 2883 2884#: ../../rst/user_guide/intro_getting_started.rst:177 2885msgid "Next steps" 2886msgstr "次のステップ" 2887 2888#: ../../rst/user_guide/intro_getting_started.rst:178 2889msgid "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." 2890msgstr "次に、:ref:`intro_adhoc` のより多くの実例を読んだり、さまざまなモジュールでできることを調べたり、Ansible :ref:`working_with_playbooks` の言語について読んだりすることができます。Ansible は、単にコマンドを実行するだけでなく、強力な構成管理機能およびデプロイ機能を備えています。" 2891 2892#: ../../rst/user_guide/intro_getting_started.rst:186 2893msgid "More information about inventory" 2894msgstr "インベントリーの詳細情報" 2895 2896#: ../../rst/user_guide/intro_getting_started.rst:190 2897msgid "Learning Ansible's configuration management language" 2898msgstr "Ansible の設定管理言語の概要" 2899 2900#: ../../rst/user_guide/intro_getting_started.rst:191 2901msgid "`Ansible Demos <https://github.com/ansible/product-demos>`_" 2902msgstr "`Ansible Demos <https://github.com/ansible/product-demos>`_" 2903 2904#: ../../rst/user_guide/intro_getting_started.rst:192 2905msgid "Demonstrations of different Ansible usecases" 2906msgstr "各種 Ansible のユースケースのデモ" 2907 2908#: ../../rst/user_guide/intro_getting_started.rst:193 2909msgid "`RHEL Labs <https://katacoda.com/rhel-labs>`_" 2910msgstr "`RHEL Labs <https://katacoda.com/rhel-labs>`_" 2911 2912#: ../../rst/user_guide/intro_getting_started.rst:194 2913msgid "Labs to provide further knowledge on different topics" 2914msgstr "さまざまなトピックでの詳細な知識を提供するラボ" 2915 2916#: ../../rst/user_guide/intro_inventory.rst:6 2917msgid "How to build your inventory" 2918msgstr "インベントリーの構築方法" 2919 2920#: ../../rst/user_guide/intro_inventory.rst:8 2921msgid "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." 2922msgstr "Ansible は、インベントリーと呼ばれるリスト、またはリストのグループを使用して、インフラストラクチャーにある複数の管理ノードまたは「ホスト」に対して同時に機能します。インベントリーが定義されたら、:ref:`パターン <intro_patterns>` を使用して Ansible で実行するホストまたはグループを選択します。" 2923 2924#: ../../rst/user_guide/intro_inventory.rst:10 2925msgid "The default location for inventory is a file called ``/usr/local/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." 2926msgstr "インベントリーのデフォルトの場所は、``/usr/local/etc/ansible/hosts`` と呼ばれるファイルです。``-i <path>`` オプションを使用して、コマンドラインで別のインベントリーファイルを指定できます。「:ref:`intro_dynamic_inventory`」で説明されているように、:ref:`using_multiple_inventory_sources` で説明されている複数のインベントリーファイルを同時に使用したり、動的またはクラウドソースまたは異なる形式 (YAML、ini など) からインベントリーをプルしたりすることもできます。バージョン 2.4 で導入された Ansible には、この柔軟でカスタマイズ可能な :ref:`inventory_plugins` があります。" 2927 2928#: ../../rst/user_guide/intro_inventory.rst:19 2929msgid "Inventory basics: formats, hosts, and groups" 2930msgstr "インベントリーの基本: 形式、ホスト、およびグループ" 2931 2932#: ../../rst/user_guide/intro_inventory.rst:21 2933msgid "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 ``/usr/local/etc/ansible/hosts`` might look like this:" 2934msgstr "インベントリーファイルは、所有するインベントリープラグインに応じて、多くの形式のいずれかになります。最も一般的な形式は INI および YAML です。基本的な INI ``/usr/local/etc/ansible/hosts`` は以下のようになります。" 2935 2936#: ../../rst/user_guide/intro_inventory.rst:37 2937msgid "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`." 2938msgstr "括弧内の見出しはグループ名で、ホストを分類し、どの時点で、どのような目的で、どのホストを制御するかを決定するのに使用されます。グループ名は、:ref:`valid_variable_names` と同じガイドラインに従ってください。" 2939 2940#: ../../rst/user_guide/intro_inventory.rst:41 2941msgid "Here's that same basic inventory file in YAML format:" 2942msgstr "以下は、同じ基本的なインベントリーファイルの YAML 形式です。" 2943 2944#: ../../rst/user_guide/intro_inventory.rst:62 2945msgid "Default groups" 2946msgstr "デフォルトのグループ" 2947 2948#: ../../rst/user_guide/intro_inventory.rst:64 2949msgid "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``." 2950msgstr "デフォルトグループが 2 つ (``all`` および ``ungrouped``) あります。``all`` グループには、すべてのホストが含まれています。``ungrouped`` グループは、``all`` 以外のグループを持たないすべてのホストを含みます。すべてのホストは、常に少なくとも 2 つのグループ (``all`` と ``ungrouped``、または``all`` と他のグループ) に属しています。``all`` と ``ungrouped`` は常に存在していますが、``group_names`` のようにグループ一覧に表示されない暗黙的なものもあります。" 2951 2952#: ../../rst/user_guide/intro_inventory.rst:71 2953msgid "Hosts in multiple groups" 2954msgstr "複数グループ内のホスト" 2955 2956#: ../../rst/user_guide/intro_inventory.rst:73 2957msgid "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:" 2958msgstr "各ホストを複数のグループに配置できます。たとえば、Atlanta のデータセンターの実稼働 Web サーバーは、[prod]、[atlanta]、および [webservers] と呼ばれるグループに追加できます。以下を追跡するグループを作成できます。" 2959 2960#: ../../rst/user_guide/intro_inventory.rst:75 2961msgid "What - An application, stack or microservice (for example, database servers, web servers, and so on)." 2962msgstr "なにを - アプリケーション、スタック、またはマイクロサービス (たとえば、データベースサーバー、Web サーバーなど)。" 2963 2964#: ../../rst/user_guide/intro_inventory.rst:76 2965msgid "Where - A datacenter or region, to talk to local DNS, storage, and so on (for example, east, west)." 2966msgstr "どこで - データセンターまたはリージョンで、ローカルの DNS やストレージなどと通信します (例: east、west)。" 2967 2968#: ../../rst/user_guide/intro_inventory.rst:77 2969msgid "When - The development stage, to avoid testing on production resources (for example, prod, test)." 2970msgstr "いつ - 開発段階で、実稼働リソースでのテストを回避するため (例: prod、test)。" 2971 2972#: ../../rst/user_guide/intro_inventory.rst:79 2973msgid "Extending the previous YAML inventory to include what, when, and where would look like:" 2974msgstr "以前の YAML インベントリーを拡張して、上述の「いつ、どこで、なにを」が含まれるようにします。" 2975 2976#: ../../rst/user_guide/intro_inventory.rst:115 2977msgid "You can see that ``one.example.com`` exists in the ``dbservers``, ``east``, and ``prod`` groups." 2978msgstr "``one.example.com`` が ``dbservers``、``east``、および ``prod`` グループに存在することを確認できます。" 2979 2980#: ../../rst/user_guide/intro_inventory.rst:117 2981msgid "You can also use nested groups to simplify ``prod`` and ``test`` in this inventory, for the same result:" 2982msgstr "また、入れ子になったグループを使用して、このインベントリーで ``prod`` と``test`` を簡素化しても、同じ結果になります。" 2983 2984#: ../../rst/user_guide/intro_inventory.rst:150 2985msgid "You can find more examples on how to organize your inventories and group your hosts in :ref:`inventory_setup_examples`." 2986msgstr "インベントリーを整理し、ホストをグループ化する方法は、「:ref:`inventory_setup_examples`」を参照してください。" 2987 2988#: ../../rst/user_guide/intro_inventory.rst:153 2989msgid "Adding ranges of hosts" 2990msgstr "ホスト範囲の追加" 2991 2992#: ../../rst/user_guide/intro_inventory.rst:155 2993msgid "If you have a lot of hosts with a similar pattern, you can add them as a range rather than listing each hostname separately:" 2994msgstr "同様のパターンを持つホストが多数ある場合は、各ホスト名を個別に一覧表示するのではなく、ホストを範囲として追加できます。" 2995 2996#: ../../rst/user_guide/intro_inventory.rst:157 2997#: ../../rst/user_guide/intro_inventory.rst:175 2998#: ../../rst/user_guide/intro_inventory.rst:256 2999#: ../../rst/user_guide/intro_inventory.rst:326 3000msgid "In INI:" 3001msgstr "INI の場合は、以下のようになります。" 3002 3003#: ../../rst/user_guide/intro_inventory.rst:164 3004#: ../../rst/user_guide/intro_inventory.rst:182 3005#: ../../rst/user_guide/intro_inventory.rst:218 3006#: ../../rst/user_guide/intro_inventory.rst:262 3007#: ../../rst/user_guide/intro_inventory.rst:304 3008#: ../../rst/user_guide/intro_inventory.rst:354 3009msgid "In YAML:" 3010msgstr "YAML の場合は、以下のようになります。" 3011 3012#: ../../rst/user_guide/intro_inventory.rst:173 3013msgid "You can specify a stride (increments between sequence numbers) when defining a numeric range of hosts:" 3014msgstr "ホストの数値範囲を定義する際に、stride (シーケンス番号間の増分) を指定することができます。" 3015 3016#: ../../rst/user_guide/intro_inventory.rst:191 3017msgid "For numeric patterns, leading zeros can be included or removed, as desired. Ranges are inclusive. You can also define alphabetic ranges:" 3018msgstr "数値のパターンでは、必要に応じて先頭にゼロを含めるか、または削除できます。範囲は包含的範囲も定義できます。また、アルファベットの範囲も定義できます。" 3019 3020#: ../../rst/user_guide/intro_inventory.rst:201 3021msgid "Adding variables to inventory" 3022msgstr "インベントリーへの変数の追加" 3023 3024#: ../../rst/user_guide/intro_inventory.rst:203 3025msgid "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." 3026msgstr "インベントリー内の特定のホストやグループに関連する変数値を保存することができます。最初のうちは、メインのインベントリーファイルのホストやグループに直接変数を追加することができます。しかし、Ansible インベントリーに管理ノードをどんどん追加していくと、変数をホストやグループの変数ファイルに分けて保存したくなることがあります。詳細は「:ref:`define_variables_in_inventory`」を参照してください。" 3027 3028#: ../../rst/user_guide/intro_inventory.rst:208 3029msgid "Assigning a variable to one machine: host variables" 3030msgstr "あるマシンへの変数の割り当て: ホスト変数" 3031 3032#: ../../rst/user_guide/intro_inventory.rst:210 3033msgid "You can easily assign a variable to a single host, then use it later in playbooks. In INI:" 3034msgstr "1 台のホストに変数を簡単に割り当てると、後で Playbook で使用できます。INI では、以下のようになります。" 3035 3036#: ../../rst/user_guide/intro_inventory.rst:231 3037msgid "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:" 3038msgstr "非標準の SSH ポートのような一意な値は、ホスト変数としてうまく機能します。ホスト名の後にコロンを付けてポート番号を追加することで、Ansible インベントリーに追加することができます。" 3039 3040#: ../../rst/user_guide/intro_inventory.rst:237 3041msgid "Connection variables also work well as host variables:" 3042msgstr "接続変数もホスト変数として機能します。" 3043 3044#: ../../rst/user_guide/intro_inventory.rst:247 3045msgid "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." 3046msgstr "SSH 設定ファイル内に非標準の SSH ポートの一覧を表示した場合、``openssh`` 接続はそのポートを見つけて使用しますが、``paramiko`` 接続は行われません。" 3047 3048#: ../../rst/user_guide/intro_inventory.rst:252 3049msgid "Inventory aliases" 3050msgstr "インベントリーエイリアス" 3051 3052#: ../../rst/user_guide/intro_inventory.rst:254 3053msgid "You can also define aliases in your inventory:" 3054msgstr "エイリアスをインベントリーに定義することもできます。" 3055 3056#: ../../rst/user_guide/intro_inventory.rst:272 3057msgid "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." 3058msgstr "上記の例では、ホストの別名「jumper」に対して Ansible を実行すると、ポート 5555 の 192.0.2.50 に接続されます。ホストへの接続をさらにカスタマイズするには、「:ref:`動作用のインベントリーパラメーター <behavioral_parameters>`」を参照してください。" 3059 3060#: ../../rst/user_guide/intro_inventory.rst:275 3061msgid "Values passed in the INI format using the ``key=value`` syntax are interpreted differently depending on where they are declared:" 3062msgstr "``key=value`` 構文を使用して INI 形式で渡される値が解釈される方法は、宣言される場所に応じて異なります。" 3063 3064#: ../../rst/user_guide/intro_inventory.rst:277 3065msgid "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." 3066msgstr "ホストのインラインで宣言すると、INI 値は Pythonの リテラル構造 (文字列、数値、タプル、リスト、ディクショナリー、ブール値、なし) として解釈されます。ホストの行は、1 行につき複数の ``key=value`` パラメーターを受け付けます。そのため、スペースが区切り文字ではなく値の一部であることを示す方法が必要です。" 3067 3068#: ../../rst/user_guide/intro_inventory.rst:279 3069msgid "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." 3070msgstr "``:vars`` セクションで宣言すると、INI の値は文字列として解釈されます。たとえば、``var=FALSE`` は FALSE と等しい文字列を作成します。ホスト行とは異なり、``:vars`` セクションは行ごとに 1 つのエントリーのみを許可するため、``=`` の後に続くすべてのものがエントリーの値である必要があります。" 3071 3072#: ../../rst/user_guide/intro_inventory.rst:281 3073msgid "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." 3074msgstr "INI インベントリーに設定されている変数の値が特定の型 (文字列やブール値など) でなければならない場合は、必ずタスクのフィルターで型を指定してください。変数を使用する際に、INI インベントリーに設定されている型に頼らないでください。" 3075 3076#: ../../rst/user_guide/intro_inventory.rst:283 3077msgid "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." 3078msgstr "変数の実際のタイプに関する混乱を回避するために、インベントリーソースに YAML 形式を使用することを検討してください。YAML インベントリープラグインは変数の値を一貫して、正しく処理します。" 3079 3080#: ../../rst/user_guide/intro_inventory.rst:285 3081msgid "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." 3082msgstr "一般的には、システムポリシーを記述する変数を定義するのに、この方法は最適ではありません。メインのインベントリーファイルに変数を設定することは、単なる省略にすぎません。変数の値を「host_vars」ディレクトリー内の個々のファイルに保存する際のガイドラインについては、「:ref:`splitting_out_vars`」を参照してください。" 3083 3084#: ../../rst/user_guide/intro_inventory.rst:290 3085msgid "Assigning a variable to many machines: group variables" 3086msgstr "多くのマシンへの変数の割り当て: グループ変数" 3087 3088#: ../../rst/user_guide/intro_inventory.rst:292 3089msgid "If all hosts in a group share a variable value, you can apply that variable to an entire group at once. In INI:" 3090msgstr "グループ内のすべてのホストが変数の値を共有している場合は、その変数をグループ全体に一度に適用することができます。INI の場合は以下のようになります。" 3091 3092#: ../../rst/user_guide/intro_inventory.rst:316 3093msgid "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>`." 3094msgstr "グループ変数は、複数のホストに一度に変数を適用する便利な方法です。しかし、Ansible は実行前に、インベントリー変数を含む変数を常にホストレベルにフラット化します。ホストが複数のグループに属している場合、Ansible はそれらのグループのすべてから変数の値を読み取ります。異なるグループで同じ変数に異なる値を割り当てた場合、Ansible は内部 :ref:`マージのルール <how_we_merge>` に基づいてどの値を使用するかを選択します。" 3095 3096#: ../../rst/user_guide/intro_inventory.rst:321 3097msgid "Inheriting variable values: group variables for groups of groups" 3098msgstr "変数値の継承: グループのグループ用グループ変数" 3099 3100#: ../../rst/user_guide/intro_inventory.rst:323 3101msgid "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:``:" 3102msgstr "INI の ``:children`` サフィックスまたは YAML の ``children:`` エントリーを使用して、グループのグループを作成できます。``:vars`` または ``vars:`` を使用して、変数をそれらのグループのグループに適用できます。" 3103 3104#: ../../rst/user_guide/intro_inventory.rst:381 3105msgid "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`." 3106msgstr "リストまたはハッシュデータを保存する必要がある場合や、インベントリーファイルとは別にホストおよびグループ固有の変数を保持する必要がある場合は、「:ref:`splitting_out_vars`」を参照してください。" 3107 3108#: ../../rst/user_guide/intro_inventory.rst:383 3109msgid "Child groups have a couple of properties to note:" 3110msgstr "子グループには、注意すべき以下のプロパティーがあります。" 3111 3112#: ../../rst/user_guide/intro_inventory.rst:385 3113msgid "Any host that is member of a child group is automatically a member of the parent group." 3114msgstr "子グループのメンバーであるホストは、自動的に親グループのメンバーになります。" 3115 3116#: ../../rst/user_guide/intro_inventory.rst:386 3117msgid "A child group's variables will have higher precedence (override) a parent group's variables." 3118msgstr "子グループの変数は、親グループの変数よりも優先度が高くなります (上書きされます)。" 3119 3120#: ../../rst/user_guide/intro_inventory.rst:387 3121msgid "Groups can have multiple parents and children, but not circular relationships." 3122msgstr "グループに複数の親と子を追加することはできますが、循環関係は設定できません。" 3123 3124#: ../../rst/user_guide/intro_inventory.rst:388 3125msgid "Hosts can also be in multiple groups, but there will only be **one** instance of a host, merging the data from the multiple groups." 3126msgstr "ホストは複数のグループに属することもできますが、ホストのインスタンスは **1 つ** だけであり、複数のグループからのデータをマージします。" 3127 3128#: ../../rst/user_guide/intro_inventory.rst:393 3129msgid "Organizing host and group variables" 3130msgstr "ホスト変数とグループ変数の整理" 3131 3132#: ../../rst/user_guide/intro_inventory.rst:395 3133msgid "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." 3134msgstr "メインのインベントリーファイルに変数を格納できますが、ホスト変数ファイルとグループ変数ファイルを別々に格納することで、変数の値をより簡単に整理できる場合があります。ホストとグループの変数ファイルは、YAML 構文を使用する必要があります。有効なファイル拡張子は、「.yml」、「.yaml」、または「.json」です。ファイル拡張子を付けなくても有効です。YAML を初めて使用する場合は、「:ref:`yaml_syntax`」を参照してください。" 3135 3136#: ../../rst/user_guide/intro_inventory.rst:398 3137msgid "Ansible loads host and group variable files by searching paths relative to the inventory file or the playbook file. If your inventory file at ``/usr/local/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:" 3138msgstr "Ansible は、インベントリーファイルまたは Playbook ファイルからの相対パスを検索して、ホストおよびグループ変数ファイルを読み込みます。``/usr/local/etc/ansible/hosts`` のインベントリーファイルに「foosball」という名前のホストがあり、それが「raleigh」と「webservers」という 2 つのグループに所属している場合、そのホストは以下の場所にある YAML ファイルの変数を使用します。" 3139 3140#: ../../rst/user_guide/intro_inventory.rst:406 3141msgid "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 ``/usr/local/etc/ansible/group_vars/raleigh`` to store the variables for the ``raleigh`` group:" 3142msgstr "たとえば、インベントリー内のホストをデータセンターごとにまとめ、各データセンターが独自の NTP サーバーおよびデータベースサーバーを使用する場合は、``/usr/local/etc/ansible/group_vars/raleigh`` という名前のファイルを作成して、``raleigh`` グループの変数を保存できます。" 3143 3144#: ../../rst/user_guide/intro_inventory.rst:414 3145msgid "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:" 3146msgstr "また、グループまたはホストの名前が付けられた *ディレクトリー* も作成できます。Ansible は、これらのディレクトリーに含まれるすべてのファイルを辞書の順に読み込みます。例では、「raleigh」グループを使用しています。" 3147 3148#: ../../rst/user_guide/intro_inventory.rst:421 3149msgid "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." 3150msgstr "「raleigh」グループのすべてのホストは、これらのファイルで定義された変数を利用できるようになります。これは、1 つのファイルが大きくなりすぎたときに、変数を整理しておくのに非常に便利です。また、いくつかのグループ変数に :ref:`Ansible Vault<playbooks_vault>` を使用したい場合にも便利です。" 3151 3152#: ../../rst/user_guide/intro_inventory.rst:425 3153msgid "You can also add ``group_vars/`` and ``host_vars/`` directories to your playbook directory. The ``ansible-playbook`` command looks for these directories in the current working directory by default. 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." 3154msgstr "また、ディレクトリー ``group_vars/`` および ``host_vars/`` を Playbook ディレクトリーに追加することもできます。``ansible-playbook`` コマンドは、デフォルトでは、これらのディレクトリーを現在の作業ディレクトリーで探します。他の Ansible コマンド (たとえば、``ansible``、``ansible-console`` など) は、インベントリーディレクトリー内の ``group_vars/`` と``host_vars/`` のみを探します。他のコマンドで Playbook ディレクトリーからグループ変数やホスト変数を読み込む場合は、コマンドラインで ``--playbook-dir`` オプションを指定する必要があります。Playbook ディレクトリーと inventory ディレクトリーの両方からインベントリーファイルを読み込んだ場合、Playbook ディレクトリーの変数はインベントリーディレクトリーで設定された変数よりも優先されます。" 3155 3156#: ../../rst/user_guide/intro_inventory.rst:428 3157msgid "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." 3158msgstr "git リポジトリー (または他のバージョン管理) でインベントリーファイルおよび変数を維持することは、インベントリーおよびホスト変数への変更を追跡する優れた方法です。" 3159 3160#: ../../rst/user_guide/intro_inventory.rst:434 3161msgid "How variables are merged" 3162msgstr "変数をマージする方法" 3163 3164#: ../../rst/user_guide/intro_inventory.rst:436 3165msgid "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):" 3166msgstr "デフォルトでは、プレイが実行される前に、変数が特定のホストにマージ/フラット化されます。これにより、Ansible はホストとタスクに焦点を当てているため、グループはインベントリーとホストの一致以外では実際には存続しません。デフォルトでは、Ansible はグループやホストに定義されたものを含む変数を上書きします (:ref:`DEFAULT_HASH_BEHAVIOUR<DEFAULT_HASH_BEHAVIOUR>` 参照)。その順序/優先順位は (低いものから高いものへ) となっています。" 3167 3168#: ../../rst/user_guide/intro_inventory.rst:438 3169msgid "all group (because it is the 'parent' of all other groups)" 3170msgstr "すべてのグループ (他のすべてのグループの「親」であるため)" 3171 3172#: ../../rst/user_guide/intro_inventory.rst:439 3173msgid "parent group" 3174msgstr "親グループ" 3175 3176#: ../../rst/user_guide/intro_inventory.rst:440 3177msgid "child group" 3178msgstr "子グループ" 3179 3180#: ../../rst/user_guide/intro_inventory.rst:441 3181msgid "host" 3182msgstr "ホスト" 3183 3184#: ../../rst/user_guide/intro_inventory.rst:443 3185msgid "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." 3186msgstr "デフォルトでは、Ansible は同じ親子レベルのグループを ASCII 順にマージし、最後に読み込まれたグループがそれ以前のグループを上書きします。たとえば、a_group は b_group にマージされ、一致する b_group の変数が a_group の変数を上書きします。" 3187 3188#: ../../rst/user_guide/intro_inventory.rst:445 3189msgid "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:" 3190msgstr "この動作を変更するには、グループ変数 ``ansible_group_priority`` を設定して、同じレベルのグループのマージ順序を変更することができます (親子の順序が解決された後)。数字が大きいほど後にマージされ、優先順位が高くなります。この変数が設定されていない場合のデフォルトは ``1`` です。たとえば、以下のようになります。" 3191 3192#: ../../rst/user_guide/intro_inventory.rst:457 3193msgid "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``." 3194msgstr "この例では、両方のグループの優先順位が同じ場合、結果は通常 ``testvar == b`` になりますが、``a_group`` の優先度が高いため、結果は ``testvar == a`` になります。" 3195 3196#: ../../rst/user_guide/intro_inventory.rst:459 3197msgid "``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." 3198msgstr "``ansible_group_priority`` は、group_vars の読み込みでこの変数が使用されるため、インベントリーソースでのみ設定でき、group_vars/ では設定できません。" 3199 3200#: ../../rst/user_guide/intro_inventory.rst:464 3201msgid "Using multiple inventory sources" 3202msgstr "複数のインベントリーソースの使用" 3203 3204#: ../../rst/user_guide/intro_inventory.rst:466 3205msgid "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." 3206msgstr "コマンドラインから複数のインベントリーパラメーターを指定するか、:envvar:`ANSIBLE_INVENTORY` を設定することで、複数のインベントリーリソース (ディレクトリー、動的インベントリースクリプト、またはインベントリープラグインによりサポートされるファイル) を同時に対象に指定できます。これは、ステージ環境や実稼働環境など、通常は異なる環境を同時に対象に指定にして特定のアクションを実行したい場合に便利です。" 3207 3208#: ../../rst/user_guide/intro_inventory.rst:471 3209msgid "Target two sources from the command line like this:" 3210msgstr "以下のようなコマンドラインから 2 つのソースを対象とします。" 3211 3212#: ../../rst/user_guide/intro_inventory.rst:477 3213msgid "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``." 3214msgstr "インベントリーに変数の競合がある場合は、:ref:`how_we_merge` および :ref:`ansible_variable_precedence` で説明されているルールに従って解決されることを覚えておいてください。マージの順序は、インベントリーのソースパラメーターの順序によって制御されます。ステージングインベントリーの ``[all:vars]`` が ``myvar = 1`` を定義していて、実稼働インベントリーが ``myvar = 2`` を定義している場合、Playbook は ``myvar = 2`` で実行されます。Playbook が ``-i production -i staging`` で実行された場合は、結果が逆になります。" 3215 3216#: ../../rst/user_guide/intro_inventory.rst:484 3217msgid "**Aggregating inventory sources with a directory**" 3218msgstr "**インベントリーソースをディレクトリーに集約**" 3219 3220#: ../../rst/user_guide/intro_inventory.rst:486 3221msgid "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:" 3222msgstr "また、複数のインベントリーソースやソースタイプを 1 つのディレクトリー下にまとめてインベントリーを作成することもできます。これは、静的ホストと動的ホストを組み合わせて、1 つのインベントリーとして管理するのに便利です。次のインベントリーは、インベントリープラグインソース、動的インベントリースクリプト、および静的ホストのファイルを組み合わせたものです。" 3223 3224#: ../../rst/user_guide/intro_inventory.rst:500 3225msgid "You can target this inventory directory simply like this:" 3226msgstr "このインベントリーディレクトリーは、次のように簡単に対象に設定できます。" 3227 3228#: ../../rst/user_guide/intro_inventory.rst:506 3229msgid "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:" 3230msgstr "他のインベントリーソースに対する変数の競合やグループのグループの依存関係がある場合は、インベントリーソースのマージ順序を制御すると便利です。インベントリーはファイル名に応じて ASCII 順にマージされるため、ファイルにプレフィックスを追加することで結果をコントロールすることができます。" 3231 3232#: ../../rst/user_guide/intro_inventory.rst:520 3233msgid "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``." 3234msgstr "``01-openstack.yml`` がグループ ``all`` に対して``myvar = 1`` を定義し、``02-dynamic-inventory.py`` が ``myvar = 2`` を定義し、``03-static-inventory`` が``myvar = 3`` を定義した場合は、Playbook が ``myvar = 3`` で実行します。" 3235 3236#: ../../rst/user_guide/intro_inventory.rst:523 3237msgid "For more details on inventory plugins and dynamic inventory scripts see :ref:`inventory_plugins` and :ref:`intro_dynamic_inventory`." 3238msgstr "インベントリープラグインおよび動的インベントリースクリプトの詳細は、「:ref:`inventory_plugins`」および「:ref:`intro_dynamic_inventory`」を参照してください。" 3239 3240#: ../../rst/user_guide/intro_inventory.rst:528 3241msgid "Connecting to hosts: behavioral inventory parameters" 3242msgstr "ホストへの接続: 動作用インベントリーパラメーター" 3243 3244#: ../../rst/user_guide/intro_inventory.rst:530 3245msgid "As described above, setting the following variables control how Ansible interacts with remote hosts." 3246msgstr "上記のように、以下の変数を設定して、Ansible がリモートホストと対話する方法を制御します。" 3247 3248#: ../../rst/user_guide/intro_inventory.rst:532 3249msgid "Host connection:" 3250msgstr "ホスト接続:" 3251 3252#: ../../rst/user_guide/intro_inventory.rst:537 3253msgid "ansible_connection" 3254msgstr "ansible_connection" 3255 3256#: ../../rst/user_guide/intro_inventory.rst:537 3257msgid "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." 3258msgstr "ホストへの接続タイプ。これは、Ansible の接続プラグインの名前です。SSH プロトコルタイプは ``smart``、``ssh``、または ``paramiko`` です。デフォルトは smart です。SSH ベース以外のタイプは次のセクションで説明します。" 3259 3260#: ../../rst/user_guide/intro_inventory.rst:539 3261msgid "General for all connections:" 3262msgstr "すべての接続に対する一般的な設定:" 3263 3264#: ../../rst/user_guide/intro_inventory.rst:541 3265#: ../../rst/user_guide/intro_inventory.rst:644 3266msgid "ansible_host" 3267msgstr "ansible_host" 3268 3269#: ../../rst/user_guide/intro_inventory.rst:542 3270msgid "The name of the host to connect to, if different from the alias you wish to give to it." 3271msgstr "接続するホストの名前 (付与するエイリアスと異なる場合)。" 3272 3273#: ../../rst/user_guide/intro_inventory.rst:543 3274msgid "ansible_port" 3275msgstr "ansible_port" 3276 3277#: ../../rst/user_guide/intro_inventory.rst:544 3278msgid "The connection port number, if not the default (22 for ssh)" 3279msgstr "デフォルトではない場合は、接続ポート番号 (ssh の場合は 22)" 3280 3281#: ../../rst/user_guide/intro_inventory.rst:545 3282#: ../../rst/user_guide/intro_inventory.rst:646 3283msgid "ansible_user" 3284msgstr "ansible_user" 3285 3286#: ../../rst/user_guide/intro_inventory.rst:546 3287msgid "The user name to use when connecting to the host" 3288msgstr "ホストに接続する際に使用するユーザー名" 3289 3290#: ../../rst/user_guide/intro_inventory.rst:549 3291msgid "ansible_password" 3292msgstr "ansible_password" 3293 3294#: ../../rst/user_guide/intro_inventory.rst:548 3295msgid "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`)" 3296msgstr "ホストへの認証に使用するパスワード (この変数を平文で保存しないでください。常に Valut を使用してください。:ref:`tip_for_variables_and_vaults` を参照)。" 3297 3298#: ../../rst/user_guide/intro_inventory.rst:551 3299msgid "Specific to the SSH connection:" 3300msgstr "SSH 接続に固有:" 3301 3302#: ../../rst/user_guide/intro_inventory.rst:553 3303msgid "ansible_ssh_private_key_file" 3304msgstr "ansible_ssh_private_key_file" 3305 3306#: ../../rst/user_guide/intro_inventory.rst:554 3307msgid "Private key file used by ssh. Useful if using multiple keys and you don't want to use SSH agent." 3308msgstr "ssh が使用する秘密鍵ファイル。複数の鍵を使用し、SSH エージェントを使用したくない場合に便利です。" 3309 3310#: ../../rst/user_guide/intro_inventory.rst:557 3311msgid "ansible_ssh_common_args" 3312msgstr "ansible_ssh_common_args" 3313 3314#: ../../rst/user_guide/intro_inventory.rst:556 3315msgid "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)." 3316msgstr "この設定は、常に :command:`sftp`、:command:`scp`、および :command:`ssh` のデフォルトのコマンドラインに追加されます。特定のホスト (またはグループ) に ``ProxyCommand`` を設定してください。" 3317 3318#: ../../rst/user_guide/intro_inventory.rst:559 3319msgid "ansible_sftp_extra_args" 3320msgstr "ansible_sftp_extra_args" 3321 3322#: ../../rst/user_guide/intro_inventory.rst:560 3323msgid "This setting is always appended to the default :command:`sftp` command line." 3324msgstr "この設定は、デフォルトの :command:`sftp` コマンドラインに常に付加されます。" 3325 3326#: ../../rst/user_guide/intro_inventory.rst:561 3327msgid "ansible_scp_extra_args" 3328msgstr "ansible_scp_extra_args" 3329 3330#: ../../rst/user_guide/intro_inventory.rst:562 3331msgid "This setting is always appended to the default :command:`scp` command line." 3332msgstr "この設定は、デフォルトの :command:`scp` コマンドラインに常に付加されます。" 3333 3334#: ../../rst/user_guide/intro_inventory.rst:563 3335msgid "ansible_ssh_extra_args" 3336msgstr "ansible_ssh_extra_args" 3337 3338#: ../../rst/user_guide/intro_inventory.rst:564 3339msgid "This setting is always appended to the default :command:`ssh` command line." 3340msgstr "この設定は、デフォルトの :command:`ssh` コマンドラインに常に付加されます。" 3341 3342#: ../../rst/user_guide/intro_inventory.rst:565 3343msgid "ansible_ssh_pipelining" 3344msgstr "ansible_ssh_pipelining" 3345 3346#: ../../rst/user_guide/intro_inventory.rst:566 3347msgid "Determines whether or not to use SSH pipelining. This can override the ``pipelining`` setting in :file:`ansible.cfg`." 3348msgstr "SSH パイプラインを使用するかどうかを決定します。これは :file:`ansible.cfg` の ``pipelining`` の設定を上書きすることができます。" 3349 3350#: ../../rst/user_guide/intro_inventory.rst:569 3351msgid "ansible_ssh_executable (added in version 2.2)" 3352msgstr "ansible_ssh_executable (バージョン 2.2 で追加)" 3353 3354#: ../../rst/user_guide/intro_inventory.rst:568 3355msgid "This setting overrides the default behavior to use the system :command:`ssh`. This can override the ``ssh_executable`` setting in :file:`ansible.cfg`." 3356msgstr "この設定により、システムの :command:`ssh` を使用するようにデフォルトの動作が上書きされます。これにより、:file:`ansible.cfg` の ``ssh_executable`` 設定を上書きできます。" 3357 3358#: ../../rst/user_guide/intro_inventory.rst:571 3359msgid "Privilege escalation (see :ref:`Ansible Privilege Escalation<become>` for further details):" 3360msgstr "権限の昇格 (詳細は「:ref:`Ansible 権限昇格<become>`」を参照):" 3361 3362#: ../../rst/user_guide/intro_inventory.rst:574 3363msgid "Equivalent to ``ansible_sudo`` or ``ansible_su``, allows to force privilege escalation" 3364msgstr "``ansible_sudo`` または ``ansible_su`` と同等です。これにより、権限昇格を強制できます。" 3365 3366#: ../../rst/user_guide/intro_inventory.rst:576 3367msgid "Allows to set privilege escalation method" 3368msgstr "権限昇格メソッドの設定を許可します。" 3369 3370#: ../../rst/user_guide/intro_inventory.rst:578 3371msgid "Equivalent to ``ansible_sudo_user`` or ``ansible_su_user``, allows to set the user you become through privilege escalation" 3372msgstr "``ansible_sudo_user`` または ``ansible_su_user`` と同等で、権限昇格により become を行うユーザーを設定できます。" 3373 3374#: ../../rst/user_guide/intro_inventory.rst:580 3375msgid "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`)" 3376msgstr "``ansible_sudo_password`` または ``ansible_su_password`` と同等で、特権昇格パスワードを設定できます (この変数を平文で保存せず、常に vault を使用してください。「:ref:`tip_for_variables_and_vaults`」を参照してください)。" 3377 3378#: ../../rst/user_guide/intro_inventory.rst:581 3379msgid "ansible_become_exe" 3380msgstr "ansible_become_exe" 3381 3382#: ../../rst/user_guide/intro_inventory.rst:582 3383msgid "Equivalent to ``ansible_sudo_exe`` or ``ansible_su_exe``, allows you to set the executable for the escalation method selected" 3384msgstr "``ansible_sudo_exe`` または ``ansible_su_exe`` と同等で、選択した昇格メソッドの実行ファイルを設定できます。" 3385 3386#: ../../rst/user_guide/intro_inventory.rst:584 3387msgid "ansible_become_flags" 3388msgstr "ansible_become_flags" 3389 3390#: ../../rst/user_guide/intro_inventory.rst:584 3391msgid "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" 3392msgstr "``ansible_sudo_flags`` または ``ansible_su_flags`` と同等で、選択された昇格方法に渡されるフラグを設定することができます。これは ``sudo_flags`` オプションの :file:`ansible.cfg` でもグローバルに設定できます。" 3393 3394#: ../../rst/user_guide/intro_inventory.rst:586 3395msgid "Remote host environment parameters:" 3396msgstr "リモートホスト環境パラメーター:" 3397 3398#: ../../rst/user_guide/intro_inventory.rst:594 3399msgid "ansible_shell_type" 3400msgstr "ansible_shell_type" 3401 3402#: ../../rst/user_guide/intro_inventory.rst:591 3403msgid "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." 3404msgstr "ターゲットシステムのシェルタイプ。:ref:`ansible_shell_executable<ansible_shell_executable>` を Bourne (sh) 以外の互換シェルに設定しない限り、この設定は使用しないでください。デフォルトでは、コマンドは ``sh`` スタイルの構文を使用してフォーマットされます。これを ``csh`` または ``fish`` に設定すると、ターゲットシステムで実行するコマンドがシェルの構文に従います。" 3405 3406#: ../../rst/user_guide/intro_inventory.rst:603 3407msgid "ansible_python_interpreter" 3408msgstr "ansible_python_interpreter" 3409 3410#: ../../rst/user_guide/intro_inventory.rst:599 3411msgid "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`." 3412msgstr "ターゲットホストの Python パス。これは、複数の Python があるシステム、\\*BSD などの :command:`/usr/bin/python` にないシステム、:command:`/usr/bin/python` が 2.X シリーズの Python 以外のシステムに役立ちます。リモートユーザーのパスを正しく設定する必要があり、:program:`python` 実行ファイルの名前が python であると想定するため、:command:`/usr/bin/env` メカニズムは使用しません。実行ファイルの名前は :program:`python2.6` のようになります。" 3413 3414#: ../../rst/user_guide/intro_inventory.rst:607 3415msgid "ansible_*_interpreter" 3416msgstr "ansible_*_interpreter" 3417 3418#: ../../rst/user_guide/intro_inventory.rst:606 3419msgid "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." 3420msgstr "ruby や perl などのあらゆるもので動作し、:ref:`ansible_python_interpreter<ansible_python_interpreter>` のように機能します。これは、そのホストで実行されるモジュールのシバンに代わるものです。" 3421 3422#: ../../rst/user_guide/intro_inventory.rst:618 3423msgid "ansible_shell_executable" 3424msgstr "ansible_shell_executable" 3425 3426#: ../../rst/user_guide/intro_inventory.rst:614 3427msgid "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.)." 3428msgstr "これにより、Ansible コントローラーがターゲットマシンで使用するシェルを設定し、:file:`ansible.cfg` の ``executable`` を上書きします。デフォルトは :command:`/bin/sh` です。:command:`/bin/sh` を使用できない場合にのみ変更する必要があります (つまり、:command:`/bin/sh` がターゲットマシンにインストールされていない場合、または sudo から実行できない場合)。" 3429 3430#: ../../rst/user_guide/intro_inventory.rst:620 3431msgid "Examples from an Ansible-INI host file:" 3432msgstr "Ansible-INI ホストファイルの例:" 3433 3434#: ../../rst/user_guide/intro_inventory.rst:630 3435msgid "Non-SSH connection types" 3436msgstr "SSH 以外の接続タイプ" 3437 3438#: ../../rst/user_guide/intro_inventory.rst:632 3439msgid "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:" 3440msgstr "前のセクションで説明したように、Ansible は SSH で Playbook を実行しますが、この接続タイプは制限されていません。ホスト固有のパラメーター ``ansible_connection=<connector>`` では、接続タイプを変更できます。次の SSH 以外のコネクターを利用できます。" 3441 3442#: ../../rst/user_guide/intro_inventory.rst:636 3443msgid "**local**" 3444msgstr "**local**" 3445 3446#: ../../rst/user_guide/intro_inventory.rst:638 3447msgid "This connector can be used to deploy the playbook to the control machine itself." 3448msgstr "このコネクターは、Playbook をコントロールマシン自体にデプロイするために使用できます。" 3449 3450#: ../../rst/user_guide/intro_inventory.rst:640 3451msgid "**docker**" 3452msgstr "**docker**" 3453 3454#: ../../rst/user_guide/intro_inventory.rst:642 3455msgid "This connector deploys the playbook directly into Docker containers using the local Docker client. The following parameters are processed by this connector:" 3456msgstr "このコネクターは、ローカルの Docker クライアントを使用して Playbook を直接 Docker コンテナーにデプロイします。以下のパラメーターはこのコネクターによって処理されます。" 3457 3458#: ../../rst/user_guide/intro_inventory.rst:645 3459msgid "The name of the Docker container to connect to." 3460msgstr "接続先の Docker コンテナーの名前。" 3461 3462#: ../../rst/user_guide/intro_inventory.rst:647 3463msgid "The user name to operate within the container. The user must exist inside the container." 3464msgstr "コンテナー内で操作するためのユーザ名。ユーザーはコンテナー内に存在している必要があります。" 3465 3466#: ../../rst/user_guide/intro_inventory.rst:649 3467msgid "If set to ``true`` the ``become_user`` will be used to operate within the container." 3468msgstr "``true`` に設定すると、``become_user`` はコンテナー内で動作するために使用されます。" 3469 3470#: ../../rst/user_guide/intro_inventory.rst:651 3471msgid "ansible_docker_extra_args" 3472msgstr "ansible_docker_extra_args" 3473 3474#: ../../rst/user_guide/intro_inventory.rst:651 3475msgid "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." 3476msgstr "Docker が認識する追加の引数を持つ文字列を指定できますが、これはコマンド固有ではありません。このパラメーターは主に、使用するリモート Docker デーモンを設定するために使用されます。" 3477 3478#: ../../rst/user_guide/intro_inventory.rst:653 3479msgid "Here is an example of how to instantly deploy to created containers:" 3480msgstr "以下は、作成されたコンテナーに即時にデプロイする例を示しています。" 3481 3482#: ../../rst/user_guide/intro_inventory.rst:677 3483msgid "For a full list with available plugins and examples, see :ref:`connection_plugin_list`." 3484msgstr "利用可能なプラグインとサンプルの一覧は、「:ref:`connection_plugin_list`」を参照してください。" 3485 3486#: ../../rst/user_guide/intro_inventory.rst:679 3487msgid "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." 3488msgstr "ドキュメントを最初から読んでいる場合、これは Ansible Playbook を初めて確認した例です。これはインベントリーファイルではありません。Playbook は、ドキュメントで後ほど詳細に説明しています。" 3489 3490#: ../../rst/user_guide/intro_inventory.rst:685 3491msgid "Inventory setup examples" 3492msgstr "インベントリーの設定例" 3493 3494#: ../../rst/user_guide/intro_inventory.rst:687 3495msgid "See also :ref:`sample_setup`, which shows inventory along with playbooks and other Ansible artifacts." 3496msgstr "Playbook およびその他の Ansible アーティファクトとともにインベントリーを表示する :ref:`sample_setup` も参照してください。" 3497 3498#: ../../rst/user_guide/intro_inventory.rst:692 3499msgid "Example: One inventory per environment" 3500msgstr "例: 各環境に 1 つのインベントリー" 3501 3502#: ../../rst/user_guide/intro_inventory.rst:694 3503msgid "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." 3504msgstr "複数の環境を管理する必要がある場合、インベントリーごとに 1 つの環境のホストのみを定義することが賢明な場合があります。こうすることで、たとえば、実際には「ステージング」サーバーを更新したいのに、誤って「テスト」環境内のノードの状態を変更してしまうことが起こりにくくなります。" 3505 3506#: ../../rst/user_guide/intro_inventory.rst:700 3507msgid "For the example mentioned above you could have an :file:`inventory_test` file:" 3508msgstr "前述の例では、:file:`inventory_test` というファイルがあります。" 3509 3510#: ../../rst/user_guide/intro_inventory.rst:714 3511msgid "That file only includes hosts that are part of the \"test\" environment. Define the \"staging\" machines in another file called :file:`inventory_staging`:" 3512msgstr "このファイルには、「テスト」環境に含まれるホストのみが含まれます。:file:`inventory_staging` と呼ばれる別のファイルの「ステージング」マシンを定義します。" 3513 3514#: ../../rst/user_guide/intro_inventory.rst:729 3515msgid "To apply a playbook called :file:`site.yml` to all the app servers in the test environment, use the following command::" 3516msgstr "`site.yml` という名前の Playbook をテスト環境のすべてのアプリケーションサーバーに適用するには、次のコマンドを使用します。" 3517 3518#: ../../rst/user_guide/intro_inventory.rst:738 3519msgid "Example: Group by function" 3520msgstr "例: 機能別にグループ化" 3521 3522#: ../../rst/user_guide/intro_inventory.rst:740 3523msgid "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:" 3524msgstr "前セクションでは、同じ機能を持つホストをクラスター化するために、グループを使用する例をすでに提示しています。これにより、データベースサーバーだけに影響する Playbook またはロール内でファイアウォールルールを定義できます。" 3525 3526#: ../../rst/user_guide/intro_inventory.rst:758 3527msgid "Example: Group by location" 3528msgstr "例: 場所別にグループ化" 3529 3530#: ../../rst/user_guide/intro_inventory.rst:760 3531msgid "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:" 3532msgstr "また、特定のホストがどこにあるかに焦点を当てたタスクもあります。たとえば、``db01.test.example.com`` と ``app01.test.example.com`` が DC1 にあり、``db02.test.example.com`` が DC2 にあるとします。" 3533 3534#: ../../rst/user_guide/intro_inventory.rst:773 3535msgid "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." 3536msgstr "実際には、たとえば特定のデータセンター内のすべてのノードを更新する日と、置かれている場所に関係なくすべてのアプリケーションサーバーを更新する日が必要になるため、これらすべての設定を組み合わせて使用することがあります。" 3537 3538#: ../../rst/user_guide/intro_inventory.rst:780 3539msgid ":ref:`inventory_plugins`" 3540msgstr ":ref:`inventory_plugins`" 3541 3542#: ../../rst/user_guide/intro_inventory.rst:781 3543msgid "Pulling inventory from dynamic or static sources" 3544msgstr "動的ソースまたは静的ソースからのインベントリーのプル" 3545 3546#: ../../rst/user_guide/intro_inventory.rst:782 3547msgid ":ref:`intro_dynamic_inventory`" 3548msgstr ":ref:`intro_dynamic_inventory`" 3549 3550#: ../../rst/user_guide/intro_inventory.rst:783 3551msgid "Pulling inventory from dynamic sources, such as cloud providers" 3552msgstr "クラウドプロバイダーなどの動的ソースからのインベントリーのプル" 3553 3554#: ../../rst/user_guide/intro_inventory.rst:787 3555msgid "Learning Ansible's configuration, deployment, and orchestration language." 3556msgstr "Ansible の設定、デプロイメント、およびオーケストレーション言語について" 3557 3558#: ../../rst/user_guide/intro_patterns.rst:4 3559msgid "Patterns: targeting hosts and groups" 3560msgstr "パターン: ホストおよびグループを対象とする" 3561 3562#: ../../rst/user_guide/intro_patterns.rst:6 3563msgid "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." 3564msgstr "アドホックコマンドまたは Playbook から Ansible を実行する場合は、実行する管理ノードまたはグループを選択する必要があります。パターンにより、インベントリー内の特定のホストやグループに対してコマンドと Playbook を実行できます。Ansible パターンは、1 台のホスト、IP アドレス、インベントリーグループ、グループセット、またはインベントリー内のすべてのホストを参照できます。パターンは柔軟性が高く、ホストのサブセットを除外または要求したり、ワイルドカードや正規表現を使用したりできます。Ansible は、パターンに含まれるすべてのインベントリーホストで実行します。" 3565 3566#: ../../rst/user_guide/intro_patterns.rst:12 3567msgid "Using patterns" 3568msgstr "パターンの使用" 3569 3570#: ../../rst/user_guide/intro_patterns.rst:14 3571msgid "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::" 3572msgstr "アドホックコマンドまたは Playbook を実行する際は、ほぼ常にパターンを使用します。パターンは、フラグのない :ref:`ad hoc command<intro_adhoc>` の唯一の要素です。通常は 2 番目の要素になります。" 3573 3574#: ../../rst/user_guide/intro_patterns.rst:18 3575#: ../../rst/user_guide/intro_patterns.rst:29 3576#: ../../rst/user_guide/playbooks_checkmode.rst:31 3577#: ../../rst/user_guide/playbooks_filters.rst:669 3578#: ../../rst/user_guide/playbooks_tests.rst:307 3579#: ../../rst/user_guide/playbooks_tests.rst:328 3580msgid "For example::" 3581msgstr "例::" 3582 3583#: ../../rst/user_guide/intro_patterns.rst:22 3584msgid "In a playbook the pattern is the content of the ``hosts:`` line for each play:" 3585msgstr "Playbook では、パターンは各プレイの ``hosts:`` 行の内容になります。" 3586 3587#: ../../rst/user_guide/intro_patterns.rst:34 3588msgid "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." 3589msgstr "多くの場合は、コマンドまたは Playbook を複数のホストに対して一度に実行するため、パターンは多くの場合インベントリーグループを参照します。アドホックコマンドと上記の Playbook は、``webservers`` グループのすべてのマシンに対して実行されます。" 3590 3591#: ../../rst/user_guide/intro_patterns.rst:39 3592msgid "Common patterns" 3593msgstr "一般的なパターン" 3594 3595#: ../../rst/user_guide/intro_patterns.rst:41 3596msgid "This table lists common patterns for targeting inventory hosts and groups." 3597msgstr "以下の表は、インベントリーホストおよびグループを対象に設定する一般的なパターンを示しています。" 3598 3599#: ../../rst/user_guide/intro_patterns.rst:47 3600#: ../../rst/user_guide/playbooks_loops.rst:394 3601msgid "Description" 3602msgstr "説明" 3603 3604#: ../../rst/user_guide/intro_patterns.rst:47 3605msgid "Pattern(s)" 3606msgstr "パターン" 3607 3608#: ../../rst/user_guide/intro_patterns.rst:47 3609msgid "Targets" 3610msgstr "ターゲット" 3611 3612#: ../../rst/user_guide/intro_patterns.rst:49 3613msgid "All hosts" 3614msgstr "すべてのホスト" 3615 3616#: ../../rst/user_guide/intro_patterns.rst:49 3617msgid "all (or \\*)" 3618msgstr "all (または \\*)" 3619 3620#: ../../rst/user_guide/intro_patterns.rst:51 3621msgid "One host" 3622msgstr "1 台のホスト" 3623 3624#: ../../rst/user_guide/intro_patterns.rst:51 3625msgid "host1" 3626msgstr "host1" 3627 3628#: ../../rst/user_guide/intro_patterns.rst:53 3629msgid "Multiple hosts" 3630msgstr "複数のホスト" 3631 3632#: ../../rst/user_guide/intro_patterns.rst:53 3633msgid "host1:host2 (or host1,host2)" 3634msgstr "host1:host2 (または host1,host2)" 3635 3636#: ../../rst/user_guide/intro_patterns.rst:55 3637msgid "One group" 3638msgstr "1 つのグループ" 3639 3640#: ../../rst/user_guide/intro_patterns.rst:55 3641msgid "webservers" 3642msgstr "webservers" 3643 3644#: ../../rst/user_guide/intro_patterns.rst:57 3645msgid "Multiple groups" 3646msgstr "複数グループ" 3647 3648#: ../../rst/user_guide/intro_patterns.rst:57 3649msgid "webservers:dbservers" 3650msgstr "webservers:dbservers" 3651 3652#: ../../rst/user_guide/intro_patterns.rst:57 3653msgid "all hosts in webservers plus all hosts in dbservers" 3654msgstr "webservers 上のすべてのホストと、dbservers 上のすべてのホスト" 3655 3656#: ../../rst/user_guide/intro_patterns.rst:59 3657msgid "Excluding groups" 3658msgstr "グループの除外" 3659 3660#: ../../rst/user_guide/intro_patterns.rst:59 3661msgid "webservers:!atlanta" 3662msgstr "webservers:!atlanta" 3663 3664#: ../../rst/user_guide/intro_patterns.rst:59 3665msgid "all hosts in webservers except those in atlanta" 3666msgstr "atlanta 上のホストを除く webservers のすべてのホスト" 3667 3668#: ../../rst/user_guide/intro_patterns.rst:61 3669msgid "Intersection of groups" 3670msgstr "グループの交差部分" 3671 3672#: ../../rst/user_guide/intro_patterns.rst:61 3673msgid "webservers:&staging" 3674msgstr "webservers:&staging" 3675 3676#: ../../rst/user_guide/intro_patterns.rst:61 3677msgid "any hosts in webservers that are also in staging" 3678msgstr "ステージ状態にある webservers のすべてのホスト" 3679 3680#: ../../rst/user_guide/intro_patterns.rst:64 3681msgid "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." 3682msgstr "ホストのリストを分離するには、コンマ (``,``) またはコロン (``:``) のいずれかを使用できます。コンマは、範囲および IPv6 アドレスを処理する場合に推奨されます。" 3683 3684#: ../../rst/user_guide/intro_patterns.rst:66 3685msgid "Once you know the basic patterns, you can combine them. This example::" 3686msgstr "基本的なパターンを把握したら、それを組み合わせることができます。以下に例を示します。" 3687 3688#: ../../rst/user_guide/intro_patterns.rst:70 3689msgid "targets all machines in the groups 'webservers' and 'dbservers' that are also in the group 'staging', except any machines in the group 'phoenix'." 3690msgstr "「phoenix」グループのマシンを除き、「staging」グループにある「webservers」グループおよび「dbservers」グループにあるすべてのマシンを対象とします。" 3691 3692#: ../../rst/user_guide/intro_patterns.rst:73 3693msgid "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::" 3694msgstr "ホストがインベントリーで FQDN または IP アドレスにより名前が付けられている限り、FQDN または IP アドレスでワイルドカードパターンを使用できます。" 3695 3696#: ../../rst/user_guide/intro_patterns.rst:79 3697msgid "You can mix wildcard patterns and groups at the same time::" 3698msgstr "ワイルドカードパターンおよびグループを同時に組み合わせることができます。" 3699 3700#: ../../rst/user_guide/intro_patterns.rst:84 3701msgid "Limitations of patterns" 3702msgstr "パターンの制限" 3703 3704#: ../../rst/user_guide/intro_patterns.rst:86 3705msgid "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:" 3706msgstr "パターンはインベントリーによって異なります。ホストまたはグループがインベントリーに記載されていない場合は、ターゲットにパターンを使用することはできません。インベントリーに表示されない IP アドレスまたはホスト名がパターンに含まれている場合は、以下のようなエラーが表示されます。" 3707 3708#: ../../rst/user_guide/intro_patterns.rst:93 3709msgid "Your pattern must match your inventory syntax. If you define a host as an :ref:`alias<inventory_aliases>`:" 3710msgstr "お使いのパターンはインベントリー構文に一致する必要があります。ホストを :ref:`エイリアス<inventory_aliases>` として定義する場合は、以下を指定します。" 3711 3712#: ../../rst/user_guide/intro_patterns.rst:103 3713msgid "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::" 3714msgstr "パターンでエイリアスを使用する必要があります。上記の例では、パターンで ``host1`` を使用する必要があります。IP アドレスを使用する場合は、エラーが再度表示されます。" 3715 3716#: ../../rst/user_guide/intro_patterns.rst:108 3717msgid "Advanced pattern options" 3718msgstr "詳細なパターンオプション" 3719 3720#: ../../rst/user_guide/intro_patterns.rst:110 3721msgid "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." 3722msgstr "上記の一般的なパターンはほとんどのニーズに対応しますが、Ansible では、対象とするホストおよびグループを定義する他の方法もいくつか提供します。" 3723 3724#: ../../rst/user_guide/intro_patterns.rst:113 3725msgid "Using variables in patterns" 3726msgstr "パターンにおける変数の使用" 3727 3728#: ../../rst/user_guide/intro_patterns.rst:115 3729msgid "You can use variables to enable passing group specifiers via the ``-e`` argument to ansible-playbook::" 3730msgstr "変数を使うと、ansible-playbook の``-e`` 引数でグループ指定子を渡せるようになります。" 3731 3732#: ../../rst/user_guide/intro_patterns.rst:120 3733msgid "Using group position in patterns" 3734msgstr "パターンにおけるグループの位置の使用" 3735 3736#: ../../rst/user_guide/intro_patterns.rst:122 3737msgid "You can define a host or subset of hosts by its position in a group. For example, given the following group::" 3738msgstr "グループ内の位置によって、ホストやホストのサブセットを定義することができます。たとえば、次のようなグループが指定された場合です。" 3739 3740#: ../../rst/user_guide/intro_patterns.rst:129 3741msgid "you can use subscripts to select individual hosts or ranges within the webservers group::" 3742msgstr "subscripts を使用して、webservers グループ内のホストまたは範囲を個別に選択できます。" 3743 3744#: ../../rst/user_guide/intro_patterns.rst:139 3745msgid "Using regexes in patterns" 3746msgstr "パターンで正規表現の使用" 3747 3748#: ../../rst/user_guide/intro_patterns.rst:141 3749msgid "You can specify a pattern as a regular expression by starting the pattern with ``~``::" 3750msgstr "パターンを正規表現として指定するには、``~`` でパターンを開始します。" 3751 3752#: ../../rst/user_guide/intro_patterns.rst:146 3753msgid "Patterns and ansible-playbook flags" 3754msgstr "パターンおよび ansible-playbook フラグ" 3755 3756#: ../../rst/user_guide/intro_patterns.rst:148 3757msgid "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. You can also limit the hosts you target on a particular run with the ``--limit`` flag::" 3758msgstr "コマンドラインオプションを使用して Playbook で定義したパターンの動作を変更できます。たとえば、``-i 127.0.0.2,`` (末尾のコンマ) を指定して、単一のホストで ``hosts: all`` を定義する Playbook を実行することができます。これは、対象とするホストがインベントリーに定義されていない場合でも有効です。また、``--limit`` フラグを使用して、特定の実行で対象とするホストを制限することもできます。" 3759 3760#: ../../rst/user_guide/intro_patterns.rst:152 3761msgid "Finally, you can use ``--limit`` to read the list of hosts from a file by prefixing the file name with ``@``::" 3762msgstr "最後に ``--limit`` を使用して、ファイル名の前に ``@`` を付けることで、ファイルからホストのリストを読み込むことができます。" 3763 3764#: ../../rst/user_guide/intro_patterns.rst:156 3765msgid "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." 3766msgstr ":ref:`RETRY_FILES_ENABLED` が ``True`` に設定されている場合は、``ansible-playbook`` の実行後に、すべてのプレイで失敗したホストのリストを含む ``.retry`` ファイルが作成されます。このファイルは、``ansible-playbook`` の実行が終了するたびに上書きされます。" 3767 3768#: ../../rst/user_guide/intro_patterns.rst:158 3769msgid "ansible-playbook site.yml --limit @site.retry" 3770msgstr "ansible-playbook site.yml --limit @site.retry" 3771 3772#: ../../rst/user_guide/intro_patterns.rst:160 3773msgid "To apply your knowledge of patterns with Ansible commands and playbooks, read :ref:`intro_adhoc` and :ref:`playbooks_intro`." 3774msgstr "Ansible コマンドおよび Playbook でパターンに関する知識を活用するには、「:ref:`intro_adhoc`」および「:ref:`playbooks_intro`」を参照してください。" 3775 3776#: ../../rst/user_guide/intro_patterns.rst:167 3777msgid "Learning the Ansible configuration management language" 3778msgstr "Ansible の設定管理言語について" 3779 3780#: ../../rst/user_guide/intro_windows.rst:2 3781msgid "Windows Support" 3782msgstr "Windows サポート" 3783 3784#: ../../rst/user_guide/intro_windows.rst:4 3785msgid "This page has been split up and moved to the new section :ref:`windows`." 3786msgstr "本ページは分割し、新しいセクション :ref:`windows` に移動しました。" 3787 3788#: ../../rst/user_guide/modules.rst:4 3789msgid "Working With Modules" 3790msgstr "モジュールの使用" 3791 3792#: ../../rst/user_guide/modules.rst:14 3793msgid "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>`." 3794msgstr "Ansible には、リモートホスト上または :ref:`Playbooks <working_with_playbooks>` を介して直接実行できる多数のモジュール (「モジュールライブラリー」と呼ばれている) が同梱されています。" 3795 3796#: ../../rst/user_guide/modules.rst:17 3797msgid "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." 3798msgstr "ユーザーは自分でモジュールを書くこともできます。これらのモジュールは、サービス、パッケージ、ファイルなど (実際にはなんでも) のシステムリソースを制御したり、システムコマンドを実行することができます。" 3799 3800#: ../../rst/user_guide/modules.rst:24 3801#: ../../rst/user_guide/modules_intro.rst:42 3802#: ../../rst/user_guide/modules_support.rst:64 3803msgid "Examples of using modules in /usr/bin/ansible" 3804msgstr "/usr/bin/ansible におけるモジュールの使用例" 3805 3806#: ../../rst/user_guide/modules.rst:25 3807#: ../../rst/user_guide/playbooks_async.rst:165 3808#: ../../rst/user_guide/playbooks_blocks.rst:182 3809#: ../../rst/user_guide/playbooks_debugger.rst:324 3810#: ../../rst/user_guide/playbooks_delegation.rst:127 3811#: ../../rst/user_guide/playbooks_environment.rst:136 3812#: ../../rst/user_guide/playbooks_error_handling.rst:234 3813#: ../../rst/user_guide/playbooks_prompts.rst:107 3814#: ../../rst/user_guide/playbooks_startnstep.rst:37 3815#: ../../rst/user_guide/playbooks_tags.rst:426 3816#: ../../rst/user_guide/playbooks_templating.rst:42 3817#: ../../rst/user_guide/playbooks_tests.rst:388 3818#: ../../rst/user_guide/windows_dsc.rst:496 3819#: ../../rst/user_guide/windows_usage.rst:504 3820#: ../../rst/user_guide/windows_winrm.rst:905 3821msgid ":ref:`playbooks_intro`" 3822msgstr ":ref:`playbooks_intro`" 3823 3824#: ../../rst/user_guide/modules.rst:26 3825msgid "Introduction to using modules with /usr/bin/ansible-playbook" 3826msgstr "/usr/bin/ansible-playbook におけるモジュール使用の概要" 3827 3828#: ../../rst/user_guide/modules.rst:27 3829msgid ":ref:`developing_modules_general`" 3830msgstr ":ref:`developing_modules_general`" 3831 3832#: ../../rst/user_guide/modules.rst:28 3833#: ../../rst/user_guide/modules_intro.rst:46 3834msgid "How to write your own modules" 3835msgstr "独自のモジュールの作成方法" 3836 3837#: ../../rst/user_guide/modules.rst:29 3838#: ../../rst/user_guide/modules_intro.rst:47 3839msgid ":ref:`developing_api`" 3840msgstr ":ref:`developing_api`" 3841 3842#: ../../rst/user_guide/modules.rst:30 3843#: ../../rst/user_guide/modules_intro.rst:48 3844msgid "Examples of using modules with the Python API" 3845msgstr "Python API でモジュールを使用する例" 3846 3847#: ../../rst/user_guide/modules.rst:31 3848msgid ":ref:`interpreter_discovery`" 3849msgstr ":ref:`interpreter_discovery`" 3850 3851#: ../../rst/user_guide/modules.rst:32 3852msgid "Configuring the right Python interpreter on target hosts" 3853msgstr "ターゲットホストでの適切な Python インタープリターの設定" 3854 3855#: ../../rst/user_guide/modules_intro.rst:4 3856msgid "Introduction to modules" 3857msgstr "モジュールの概要" 3858 3859#: ../../rst/user_guide/modules_intro.rst:6 3860msgid "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." 3861msgstr "モジュール (「タスクプラグイン」または「ライブラリープラグイン」とも呼ばれる) は、コマンドラインまたは Playbook タスクで使用可能なコードの個別単位です。Ansible は、各モジュールを実行し、通常のリモート管理ノードで実行し、戻り値を収集します。Ansible 2.10 以降では、ほとんどのモジュールはコレクションでホストされます。" 3862 3863#: ../../rst/user_guide/modules_intro.rst:8 3864msgid "You can execute modules from the command line::" 3865msgstr "コマンドラインからモジュールを実行できます。" 3866 3867#: ../../rst/user_guide/modules_intro.rst:14 3868msgid "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." 3869msgstr "各モジュールは、引数を取ることをサポートしています。ほぼすべてのモジュールは、スペースで区切られた ``key=value`` の引数を取ります。一部のモジュールは引数を取らず、コマンド/シェルモジュールは単に実行したいコマンドの文字列を取ります。" 3870 3871#: ../../rst/user_guide/modules_intro.rst:16 3872msgid "From playbooks, Ansible modules are executed in a very similar way::" 3873msgstr "Playbook から、Ansible モジュールは同じような方法で実行されます。" 3874 3875#: ../../rst/user_guide/modules_intro.rst:21 3876msgid "Another way to pass arguments to a module is using YAML syntax, also called 'complex args' ::" 3877msgstr "もしくは、「complex args」とも呼ばれる YAML 構文を使用して、モジュールに引数を渡します。" 3878 3879#: ../../rst/user_guide/modules_intro.rst:28 3880msgid "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." 3881msgstr "すべてのモジュールは JSON 形式のデータを返します。これは、どのプログラミング言語でもモジュールを作成できます。モジュールは冪等であり、現在の状態が必要な最終状態と一致することを検知すると、変更は回避する必要があります。Ansible Playbook で使用すると、モジュールは :ref:`handlers <handlers>` に通知する形式で「変更イベント」をトリガーして追加のタスクを実行できます。" 3882 3883#: ../../rst/user_guide/modules_intro.rst:30 3884msgid "You can access the documentation for each module from the command line with the ansible-doc tool::" 3885msgstr "各モジュールのドキュメントは、ansible-doc ツールを使用してコマンドラインからアクセスできます。" 3886 3887#: ../../rst/user_guide/modules_intro.rst:34 3888msgid "For a list of all available modules, see the :ref:`Collection docs <list_of_collections>`, or run the following at a command prompt::" 3889msgstr "利用可能なモジュールの一覧は、「:ref:`Collection docs <list_of_collections>`」を参照してください。または、コマンドプロンプトで次のコマンドを実行します。" 3890 3891#: ../../rst/user_guide/modules_intro.rst:44 3892#: ../../rst/user_guide/modules_support.rst:66 3893msgid "Examples of using modules with /usr/bin/ansible-playbook" 3894msgstr "/usr/bin/ansible-playbook でモジュールを使用する例" 3895 3896#: ../../rst/user_guide/modules_support.rst:5 3897msgid "Module Maintenance & Support" 3898msgstr "モジュールのメンテナンスおよびサポート" 3899 3900#: ../../rst/user_guide/modules_support.rst:7 3901msgid "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." 3902msgstr "モジュールを使用し、バグを発見した場合は、そのバグの報告場所、修正を行う担当者、およびモジュールへの変更を追跡する方法を把握することが推奨されます。Red Hat のサブスクリプションをお持ちの場合は、アクセスする問題のサポートを取得できるかどうかを認識できます。" 3903 3904#: ../../rst/user_guide/modules_support.rst:9 3905msgid "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." 3906msgstr "Ansible 2.10 以降、ほとんどのモジュールはコレクションに存在します。各コレクションのディストリビューション方法は、そのコレクションのモジュールに対するメンテナンスとサポートを反映しています。" 3907 3908#: ../../rst/user_guide/modules_support.rst:15 3909msgid "Maintenance" 3910msgstr "メンテナンス" 3911 3912#: ../../rst/user_guide/modules_support.rst:21 3913msgid "Collection" 3914msgstr "コレクション" 3915 3916#: ../../rst/user_guide/modules_support.rst:21 3917msgid "Code location" 3918msgstr "コードの場所" 3919 3920#: ../../rst/user_guide/modules_support.rst:21 3921msgid "Maintained by" 3922msgstr "メンテナンス担当" 3923 3924#: ../../rst/user_guide/modules_support.rst:23 3925msgid "ansible.builtin" 3926msgstr "ansible.builtin" 3927 3928#: ../../rst/user_guide/modules_support.rst:23 3929msgid "`ansible/ansible repo`_ on GitHub" 3930msgstr "GitHub の `ansible/ansible repo`_" 3931 3932#: ../../rst/user_guide/modules_support.rst:23 3933msgid "core team" 3934msgstr "core チーム" 3935 3936#: ../../rst/user_guide/modules_support.rst:25 3937msgid "distributed on Galaxy" 3938msgstr "Galaxy への配布" 3939 3940#: ../../rst/user_guide/modules_support.rst:25 3941#: ../../rst/user_guide/modules_support.rst:27 3942msgid "various; follow ``repo`` link" 3943msgstr "さまざま。``repo`` リンクに従ってください。" 3944 3945#: ../../rst/user_guide/modules_support.rst:25 3946msgid "community or partners" 3947msgstr "コミュニティーまたはパートナー" 3948 3949#: ../../rst/user_guide/modules_support.rst:27 3950msgid "distributed on Automation Hub" 3951msgstr "Automation Hub への配布" 3952 3953#: ../../rst/user_guide/modules_support.rst:27 3954msgid "content team or partners" 3955msgstr "コンテンツチームまたはパートナー" 3956 3957#: ../../rst/user_guide/modules_support.rst:33 3958msgid "Issue Reporting" 3959msgstr "問題の報告" 3960 3961#: ../../rst/user_guide/modules_support.rst:35 3962msgid "If you find a bug that affects a plugin in the main Ansible repo, also known as ``ansible-core``:" 3963msgstr "Ansible メインリポジトリー (``ansible-core`` とも知られている) のプラグインに影響するバグを見つけた場合は、以下を行います。" 3964 3965#: ../../rst/user_guide/modules_support.rst:37 3966msgid "Confirm that you are running the latest stable version of Ansible or the devel branch." 3967msgstr "Ansible の最新の安定版または devel ブランチを実行していることを確認します。" 3968 3969#: ../../rst/user_guide/modules_support.rst:38 3970msgid "Look at the `issue tracker in the Ansible repo <https://github.com/ansible/ansible/issues>`_ to see if an issue has already been filed." 3971msgstr "`Ansible リポジトリーの問題トラッカー <https://github.com/ansible/ansible/issues>`_ を確認して、問題がすでに報告されているかどうかを確認します。" 3972 3973#: ../../rst/user_guide/modules_support.rst:39 3974#: ../../rst/user_guide/modules_support.rst:46 3975msgid "Create an issue if one does not already exist. Include as much detail as you can about the behavior you discovered." 3976msgstr "問題が存在しない場合は、問題を作成してください。発見した動作について、できる限り詳細に記述してください。" 3977 3978#: ../../rst/user_guide/modules_support.rst:41 3979msgid "If you find a bug that affects a plugin in a Galaxy collection:" 3980msgstr "Galaxy コレクションでプラグインに影響を与えるバグを見つけた場合は、以下を行います。" 3981 3982#: ../../rst/user_guide/modules_support.rst:43 3983msgid "Find the collection on Galaxy." 3984msgstr "Galaxy のコレクションを見つけます。" 3985 3986#: ../../rst/user_guide/modules_support.rst:44 3987msgid "Find the issue tracker for the collection." 3988msgstr "コレクションの問題トラッカーの検索" 3989 3990#: ../../rst/user_guide/modules_support.rst:45 3991msgid "Look there to see if an issue has already been filed." 3992msgstr "問題がすでに報告されているかどうかを確認します。" 3993 3994#: ../../rst/user_guide/modules_support.rst:48 3995msgid "Some partner collections may be hosted in private repositories." 3996msgstr "一部のパートナーコレクションは、プライベートリポジトリーでホストされる場合があります。" 3997 3998#: ../../rst/user_guide/modules_support.rst:50 3999msgid "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 groups or IRC channels to :ref:`communicate with Ansiblers <communication>`." 4000msgstr "ご覧になった動作がバグなのかどうかわからない場合、質問がある場合、開発関連のトピックについて議論したい場合、または単に連絡を取りたい場合は、Google グループまたは IRC チャンネルのいずれかを使用して、:ref:`Ansible ユーザーと交流 <communication>` してください。" 4001 4002#: ../../rst/user_guide/modules_support.rst:52 4003msgid "If you find a bug that affects a module in an Automation Hub collection:" 4004msgstr "Automation Hub コレクションでモジュールに影響するバグを見つけた場合は、以下を行います。" 4005 4006#: ../../rst/user_guide/modules_support.rst:54 4007msgid "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." 4008msgstr "コレクションで Automation Hub 上の Issue Tracker リンクが提供されている場合、そこをクリックして、コレクションのリポジトリーに問題を作成します。指定していない場合は、`Red Hat カスタマーポータル <https://access.redhat.com/>`_ で問題を報告するための標準的なプロセスに従ってください。ポータルで問題を作成するには、Red Hat Ansible Automation Platform のサブスクリプションが必要です。" 4009 4010#: ../../rst/user_guide/modules_support.rst:57 4011msgid "Support" 4012msgstr "サポート" 4013 4014#: ../../rst/user_guide/modules_support.rst:59 4015msgid "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/>`_" 4016msgstr "``ansible-core`` にあるすべてのプラグインと、Automation Hub でホストされるすべてのプラグインは Red Hat によってサポートされます。その他のプラグインまたはコレクションは Red Hat ではサポートされません。Red Hat Ansible Automation Platform にサブスクリプションがある場合は、`Red Hat カスタマーポータル <https://access.redhat.com/>`_ に関する詳細情報とリソースを確認できます。" 4017 4018#: ../../rst/user_guide/playbook_pathing.rst:5 4019msgid "Search paths in Ansible" 4020msgstr "Ansible でパスの検索" 4021 4022#: ../../rst/user_guide/playbook_pathing.rst:7 4023msgid "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." 4024msgstr "Ansible がコントロールノード上のリソース (構成、モジュール、ロール、ssh キーなど) や、管理しているリモートノード上のリソースを検索する際のパスを制御できます。リソースを検索する場所を Ansible に伝えるには、可能な限り絶対パスを使用します。しかし、絶対パスは必ずしも実用的ではありません。このページでは、Ansible が相対検索パスをどのように解釈するか、また Ansible が必要なリソースを見つけられない場合のトラブルシューティングの方法について説明します。" 4025 4026#: ../../rst/user_guide/playbook_pathing.rst:13 4027msgid "Config paths" 4028msgstr "設定パス" 4029 4030#: ../../rst/user_guide/playbook_pathing.rst:15 4031msgid "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." 4032msgstr "デフォルトでは、これらは設定ファイルからの相対的なものですが、中には特に現在の作業ディレクトリーや Playbook からの相対的なものもあるため、説明にその旨を記載してください。ssh キーのようなものは、基本的なツールが使用する方法を反映するため、現在の作業ディレクトリーを使用するようになっています。" 4033 4034#: ../../rst/user_guide/playbook_pathing.rst:19 4035msgid "Task paths" 4036msgstr "タスクパス" 4037 4038#: ../../rst/user_guide/playbook_pathing.rst:21 4039msgid "Task paths include two different scopes: task evaluation and task execution. For task evaluation, all paths are local, like in lookups. For task execution, which usually happens on the remote nodes, local paths do not usually apply. However, if a task uses an action plugin, it uses a local path. The template and copy modules are examples of modules that use action plugins, and therefore use local paths." 4040msgstr "タスクパスには、タスクの評価とタスクの実行という 2 つの異なるスコープがあります。タスクの評価では、ルックアップのようにすべてのパスがローカルになります。タスクの実行は通常リモートノードで行われるため、ローカルパスは通常適用されません。ただし、タスクがアクションプラグインを使用する場合は、ローカルパスを使用します。アクションプラグインを使用するモジュールの例としては、template モジュールと copy モジュールがあり、ローカルパスを使用します。" 4041 4042#: ../../rst/user_guide/playbook_pathing.rst:24 4043msgid "The magic of 'local' paths" 4044msgstr "「ローカル」パスのマジック" 4045 4046#: ../../rst/user_guide/playbook_pathing.rst:26 4047msgid "Lookups and action plugins both use a special 'search magic' to find things, taking the current play into account, it uses from most specific to most general playbook dir in which a task is contained (this includes roles and includes)." 4048msgstr "lookup および action プラグインはどちらも特殊な「検索マジック」を使用します。これには現在のプレイが考慮され、タスクが含まれる Playbook ディレクトリー (これにはロールとインクルードを含む) で、より具体的な指定からより一般的な指定が使用されます。" 4049 4050#: ../../rst/user_guide/playbook_pathing.rst:28 4051msgid "Using this magic, relative paths get attempted first with a 'files|templates|vars' appended (if not already present), depending on action being taken, 'files' is the default. (in other words, include_vars will use vars/). The paths will be searched from most specific to most general (in other words, role before play). dependent roles WILL be traversed (in other words, task is in role2, role2 is a dependency of role1, role2 will be looked at first, then role1, then play). i.e ::" 4052msgstr "このマジックを使用すると、相対パスが存在していない場合は、最初に「files|templates|vars」を付加して試行されます。実行されるアクションによっては「files」がデフォルトになります (つまり、include_vars は vars/ を使用します)。パスは、最も具体的なものから最も一般的なものへ検索されます (つまり、play の前に role があります)。依存するロールは、横断されます (つまり、タスクが role2 にあり、role2 が role1 の依存関係にある場合は、role2 が最初に検索され、次に role1、そして play が検索されます)。つまり、以下のようになります。" 4053 4054#: ../../rst/user_guide/playbook_pathing.rst:36 4055msgid "By default, Ansible does not search the current working directory unless it happens to coincide with one of the paths above. If you `include` a task file from a role, it will NOT trigger role behavior, this only happens when running as a role, `include_role` will work. A new variable `ansible_search_path` var will have the search path used, in order (but without the appended subdirs). Using 5 \"v\"s (`-vvvvv`) should show the detail of the search as it happens." 4056msgstr "デフォルトでは、Ansible は上記のパスのいずれかに一致しない限り、現在の作業ディレクトリーを検索しません。ロールからタスクファイルを `include` した場合は、ロールの動作を誘発することはありません。これはロールとして実行した場合にのみ発生し、`include_role` は動作します。新しい変数 `ansible_search_path` には、使用される検索パスが順番に入ります (ただし、付加されたサブディレクトリーは含まれません)。5つの「v」(`-vvvvv`) を使用して、検索の詳細を表示します。" 4057 4058#: ../../rst/user_guide/playbook_pathing.rst:38 4059msgid "As for includes, they try the path of the included file first and fall back to the play/role that includes them." 4060msgstr "インクルードに関しては、最初にインクルードされたファイルのパスを試し、そのファイルを含むプレイまたはロールにフォールバックします。" 4061 4062#: ../../rst/user_guide/playbooks.rst:4 4063msgid "Working with playbooks" 4064msgstr "Playbook の操作" 4065 4066#: ../../rst/user_guide/playbooks.rst:6 4067msgid "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." 4068msgstr "Playbook は、Ansible の設定、デプロイメント、オーケストレーション機能を記録して実行します。リモートシステムを強制するポリシーや、一般的な IT プロセスで一連の手順を説明することができます。" 4069 4070#: ../../rst/user_guide/playbooks.rst:8 4071msgid "If Ansible modules are the tools in your workshop, playbooks are your instruction manuals, and your inventory of hosts are your raw material." 4072msgstr "Ansible モジュールがワークショップのツールである場合、Playbook は手順のマニュアルにあり、ホストのインベントリーは実際のマテリアルになります。" 4073 4074#: ../../rst/user_guide/playbooks.rst:10 4075msgid "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." 4076msgstr "基本的なレベルでは、Playbook を使用して、リモートマシンの設定およびリモートマシンへのデプロイメントを管理できます。より高度なレベルでは、ローリングアップデートに関連する複数層のロールアウトを分類し、他のホストにアクションを委譲して、監視サーバーやロードバランサーと対話できます。" 4077 4078#: ../../rst/user_guide/playbooks.rst:12 4079msgid "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." 4080msgstr "Playbook は人間が判読可能で、基本的なテキスト言語で開発されるように設計されています。Playbook と、Playbook に含まれるファイルを整理する方法は複数あり、その方法と、Ansible を最大限に活用するための提案を行います。" 4081 4082#: ../../rst/user_guide/playbooks.rst:14 4083msgid "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." 4084msgstr "Playbook ドキュメントと一緒に、「`Example Playbooks <https://github.com/ansible/ansible-examples>`_」を参照してください。ここでは、ベストプラクティスや、さまざまな概念をまとめて配置する方法を説明します。" 4085 4086#: ../../rst/user_guide/playbooks_advanced_syntax.rst:5 4087msgid "Advanced Syntax" 4088msgstr "高度な構文" 4089 4090#: ../../rst/user_guide/playbooks_advanced_syntax.rst:7 4091msgid "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>`_." 4092msgstr "このページの高度な YAML 構文の例では、Ansible が使用する YAML ファイルに配置されるデータをより細かく制御できます。Python 固有の YAML に関する追加情報は、公式 `PyYAML ドキュメント <https://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes>`_ でご覧いただけます。" 4093 4094#: ../../rst/user_guide/playbooks_advanced_syntax.rst:15 4095msgid "Unsafe or raw strings" 4096msgstr "安全でない文字列または生の文字列" 4097 4098#: ../../rst/user_guide/playbooks_advanced_syntax.rst:17 4099#, python-format 4100msgid "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." 4101msgstr "lookup プラグインから返される値を処理する際、Ansible は ``unsafe`` というデータタイプを使用してテンプレートをブロックします。データを安全ではないとマークすることで、悪意のあるユーザーが Jinja2 のテンプレートを悪用してターゲットマシンで任意のコードを実行することを防ぎます。Ansible の実装では、安全でない値が決してテンプレート化されないようにしています。``{% raw %} ... {% endraw %}`` タグで Jinja2 をエスケープするよりも包括的です。" 4102 4103#: ../../rst/user_guide/playbooks_advanced_syntax.rst:19 4104msgid "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:" 4105msgstr "定義した変数に同じ ``unsafe`` データ型を使用すると、テンプレートエラーや情報の漏えいを防ぐことができます。:ref:`vars_prompts<unsafe_prompts>` により提供された値を安全でないものとしてマーク付けできます。Playbook で ``unsafe`` を使用することもできます。最も一般的なユースケースには、テンプレートのような ``{`` や ``%`` などの特殊文字を許可するパスワードが含まれていますが、テンプレート化すべきではありません。以下に例を示します。" 4106 4107#: ../../rst/user_guide/playbooks_advanced_syntax.rst:26 4108msgid "In a playbook::" 4109msgstr "Playbook の場合は、以下のようになります。" 4110 4111#: ../../rst/user_guide/playbooks_advanced_syntax.rst:35 4112msgid "For complex variables such as hashes or arrays, use ``!unsafe`` on the individual elements::" 4113msgstr "ハッシュや配列などの複雑な変数の場合は、個々の要素で ``!unsafe`` を使用します。" 4114 4115#: ../../rst/user_guide/playbooks_advanced_syntax.rst:48 4116msgid "YAML anchors and aliases: sharing variable values" 4117msgstr "YAML アンカーおよびエイリアス: 変数値の共有" 4118 4119#: ../../rst/user_guide/playbooks_advanced_syntax.rst:50 4120msgid "`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::" 4121msgstr "`YAML アンカーおよびエイリアス <https://yaml.org/spec/1.2/spec.html#id2765878>`_ は、柔軟な方法で共有変数の値を定義、維持、および使用するのに役立ちます。``&`` でアンカーを定義し、``*`` で示すエイリアスを使用して参照します。ここでは、アンカーで 3 つの値を設定し、エイリアスでこれらの値を 2 つ使用し、3 番目の値を上書きする例を以下に示します。" 4122 4123#: ../../rst/user_guide/playbooks_advanced_syntax.rst:67 4124msgid "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>`_." 4125msgstr "ここで、``app1`` および ``app2`` は、アンカー ``&jvm_opts`` およびエイリアス ``*jvm_opts`` を使用して、``opts`` と ``port`` の値を共有します。``path`` の値は、``<<`` または `merge operator <https://yaml.org/type/merge.html>`_ によってマージされます。" 4126 4127#: ../../rst/user_guide/playbooks_advanced_syntax.rst:70 4128msgid "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::" 4129msgstr "アンカーおよびエイリアスを使用すると、入れ子になった変数など、複雑な変数値のセットを共有することもできます。ある変数値に別の変数値が含まれている場合は、その変数値を別々に定義することができます。" 4130 4131#: ../../rst/user_guide/playbooks_advanced_syntax.rst:76 4132msgid "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``::" 4133msgstr "これは非効率的であり、大規模な場合には、より多くのメンテナンスが行われます。名前に version の値を組み込むには、``app_version`` にアンカーと、``custom_name`` のエイリアスを使用できます。" 4134 4135#: ../../rst/user_guide/playbooks_advanced_syntax.rst:85 4136msgid "Now, you can re-use the value of ``app_version`` within the value of ``custom_name`` and use the output in a template::" 4137msgstr "これで、``custom_name`` の値の ``app_version`` の値を再利用し、テンプレートで出力を使用できます。" 4138 4139#: ../../rst/user_guide/playbooks_advanced_syntax.rst:101 4140msgid "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." 4141msgstr "``version`` の値を ``&my_version`` というアンカーで固定し、``*my_version`` というエイリアスで再利用しています。アンカーとエイリアスを使用することで、ディクショナリー内のネストした値にアクセスすることができます。" 4142 4143#: ../../rst/user_guide/playbooks_advanced_syntax.rst:106 4144#: ../../rst/user_guide/playbooks_conditionals.rst:504 4145#: ../../rst/user_guide/playbooks_error_handling.rst:241 4146#: ../../rst/user_guide/playbooks_filters.rst:1798 4147#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:733 4148#: ../../rst/user_guide/playbooks_lookups.rst:31 4149#: ../../rst/user_guide/playbooks_loops.rst:441 4150#: ../../rst/user_guide/playbooks_prompts.rst:112 4151#: ../../rst/user_guide/playbooks_tests.rst:393 4152msgid "All about variables" 4153msgstr "変数の詳細" 4154 4155#: ../../rst/user_guide/playbooks_advanced_syntax.rst:107 4156msgid ":doc:`complex_data_manipulation`" 4157msgstr ":doc:`complex_data_manipulation`" 4158 4159#: ../../rst/user_guide/playbooks_advanced_syntax.rst:108 4160msgid "Doing complex data manipulation in Ansible" 4161msgstr "Ansible での複雑なデータ操作の実行" 4162 4163#: ../../rst/user_guide/playbooks_advanced_syntax.rst:109 4164#: ../../rst/user_guide/windows_dsc.rst:502 4165#: ../../rst/user_guide/windows_faq.rst:248 4166#: ../../rst/user_guide/windows_setup.rst:573 4167#: ../../rst/user_guide/windows_usage.rst:510 4168#: ../../rst/user_guide/windows_winrm.rst:911 4169msgid "`User Mailing List <https://groups.google.com/group/ansible-project>`_" 4170msgstr "`User Mailing List <https://groups.google.com/group/ansible-project>`_" 4171 4172#: ../../rst/user_guide/playbooks_advanced_syntax.rst:110 4173#: ../../rst/user_guide/playbooks_async.rst:168 4174#: ../../rst/user_guide/playbooks_blocks.rst:187 4175#: ../../rst/user_guide/playbooks_conditionals.rst:506 4176#: ../../rst/user_guide/playbooks_debugger.rst:327 4177#: ../../rst/user_guide/playbooks_delegation.rst:134 4178#: ../../rst/user_guide/playbooks_environment.rst:139 4179#: ../../rst/user_guide/playbooks_error_handling.rst:243 4180#: ../../rst/user_guide/playbooks_filters.rst:1806 4181#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:741 4182#: ../../rst/user_guide/playbooks_lookups.rst:35 4183#: ../../rst/user_guide/playbooks_loops.rst:443 4184#: ../../rst/user_guide/playbooks_prompts.rst:114 4185#: ../../rst/user_guide/playbooks_strategies.rst:220 4186#: ../../rst/user_guide/playbooks_tags.rst:431 4187#: ../../rst/user_guide/playbooks_templating.rst:53 4188#: ../../rst/user_guide/playbooks_tests.rst:401 4189#: ../../rst/user_guide/playbooks_variables.rst:464 4190#: ../../rst/user_guide/windows_dsc.rst:503 4191#: ../../rst/user_guide/windows_faq.rst:249 4192#: ../../rst/user_guide/windows_setup.rst:574 4193#: ../../rst/user_guide/windows_usage.rst:511 4194#: ../../rst/user_guide/windows_winrm.rst:912 4195msgid "Have a question? Stop by the google group!" 4196msgstr "ご質問はございますか。Google Group をご覧ください。" 4197 4198#: ../../rst/user_guide/playbooks_async.rst:4 4199msgid "Asynchronous actions and polling" 4200msgstr "非同期アクションおよびポーリング" 4201 4202#: ../../rst/user_guide/playbooks_async.rst:6 4203msgid "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." 4204msgstr "デフォルトでは、Ansible はタスクを同期的に実行し、アクションが完了するまでリモートノードへの接続を維持します。つまり、Playbook 内では、デフォルトでは各タスクが次のタスクをブロックし、現在のタスクが完了するまで後続のタスクが実行されないことになります。この動作には課題があります。たとえば、あるタスクが SSH セッションの許容範囲を超えて完了するのに時間がかかり、タイムアウトが発生する場合があります。また、他のタスクを同時に実行している間、長時間実行するプロセスをバックグラウンドで実行したい場合もあります。非同期モードでは、長時間実行するタスクの実行方法を制御することができます。" 4205 4206#: ../../rst/user_guide/playbooks_async.rst:12 4207msgid "Asynchronous ad hoc tasks" 4208msgstr "非同期アドホックタスク" 4209 4210#: ../../rst/user_guide/playbooks_async.rst:14 4211msgid "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``)::" 4212msgstr ":ref:`ad hoc tasks <intro_adhoc>` を使用すると、バックグラウンドで長時間実行される操作を実行することができます。たとえば、``long_running_operation`` をバックグラウンドで非同期的に実行し、タイムアウト (``-B``) を 3600 秒に設定し、ポーリング (``-P``) を行わない場合は次のようになります。" 4213 4214#: ../../rst/user_guide/playbooks_async.rst:18 4215msgid "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::" 4216msgstr "後でジョブステータスを確認するには、``async_status`` モジュールを使用し、バックグラウンドで元のジョブの実行時に返されたジョブ ID を渡します。" 4217 4218#: ../../rst/user_guide/playbooks_async.rst:22 4219msgid "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::" 4220msgstr "Ansible は、ポーリングによって長時間実行するジョブの状態を自動的に確認することもできます。ほとんどの場合、Ansible はポーリングの間もリモートノードへの接続を維持します。30 分間実行し、60 秒ごとにステータスをポーリングするには次のようにします。" 4221 4222#: ../../rst/user_guide/playbooks_async.rst:26 4223msgid "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." 4224msgstr "ポーリングモードは高性能であるため、どのマシンでもポーリングが開始する前にすべてのジョブが開始します。すべてのジョブを非常に迅速に開始したい場合は ``--forks`` を十分な高さにしてください。制限時間 (秒単位) がなくなると (``-B``)、リモートノードのプロセスは終了します。" 4225 4226#: ../../rst/user_guide/playbooks_async.rst:28 4227msgid "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." 4228msgstr "非同期モードは、長時間実行するシェルコマンドやソフトウェアのアップグレードに最適です。たとえば、copy モジュールを非同期で実行しても、バックグラウンドでのファイル転送は行われません。" 4229 4230#: ../../rst/user_guide/playbooks_async.rst:31 4231msgid "Asynchronous playbook tasks" 4232msgstr "非同期 Playbook タスク" 4233 4234#: ../../rst/user_guide/playbooks_async.rst:33 4235msgid ":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`." 4236msgstr ":ref:`Playbooks <working_with_playbooks>` は、非同期モードとポーリングもサポートしており、構文も簡素化されています。非同期モードを Playbook で使用すると、接続のタイムアウトや、後続タスクのブロックを回避できます。Playbook での非同期モードの動作は、`poll` の値に依存します。" 4237 4238#: ../../rst/user_guide/playbooks_async.rst:36 4239msgid "Avoid connection timeouts: poll > 0" 4240msgstr "接続のタイムアウトの回避: poll > 0" 4241 4242#: ../../rst/user_guide/playbooks_async.rst:38 4243msgid "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." 4244msgstr "Playbook 内の特定のタスクにより長いタイムアウト制限を設定する場合は、``async`` を使用し、``poll`` を正の値に設定します。Ansible は、Playbook 内に記載される次のタスクをブロックし、非同期タスクが完了するか、失敗するか、タイムアウトになるまで待機します。ただし、タスクがタイムアウトになるのは、``async`` パラメーターで設定したタイムアウト制限を超えた場合のみです。" 4245 4246#: ../../rst/user_guide/playbooks_async.rst:40 4247msgid "To avoid timeouts on a task, specify its maximum runtime and how frequently you would like to poll for status::" 4248msgstr "タスクでタイムアウトを回避するには、最大ランタイムとステータスをポーリングする頻度を指定します。" 4249 4250#: ../../rst/user_guide/playbooks_async.rst:55 4251msgid "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." 4252msgstr "デフォルトのポール値は、:ref:`DEFAULT_POLL_INTERVAL` の設定で設定されます。非同期時間制限のデフォルトはありません。「async」キーワードを省略すると、タスクは同期的に実行されます。これが Ansible のデフォルトです。" 4253 4254#: ../../rst/user_guide/playbooks_async.rst:61 4255msgid "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." 4256msgstr "Ansible 2.3 の時点では、非同期は確認モードをサポートしておらず、確認モードで実行するとタスクが失敗します。確認モードでタスクをスキップする方法は、「:ref:`check_mode_dry`」を参照してください。" 4257 4258#: ../../rst/user_guide/playbooks_async.rst:66 4259msgid "When an async task completes with polling enabled, the temporary async job cache file (by default in ~/.ansible_async/) is automatically removed." 4260msgstr "ポーリングを有効にして非同期タスクが完了すると、一時的な非同期ジョブキャッシュファイル (デフォルトでは ~/.ansible_async/ にある) が自動的に削除されます。" 4261 4262#: ../../rst/user_guide/playbooks_async.rst:70 4263msgid "Run tasks concurrently: poll = 0" 4264msgstr "タスクの同時実行: poll = 0" 4265 4266#: ../../rst/user_guide/playbooks_async.rst:72 4267msgid "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." 4268msgstr "Playbook 内の複数のタスクを同時に実行する場合は、``async`` を使用し、``poll`` を 0 に設定します。``poll: 0`` を設定すると、Ansible はタスクを開始し、結果を待たずに直ちに次のタスクに移ります。各非同期タスクは、完了するか、失敗するか、タイムアウトにする (``async`` の値よりも長く実行される) まで実行されます。Playbook の実行は、非同期タスクを再度チェックせずに終了します。" 4269 4270#: ../../rst/user_guide/playbooks_async.rst:74 4271msgid "To run a playbook task asynchronously::" 4272msgstr "Playbook タスクを非同期的に実行するには、以下を実行します。" 4273 4274#: ../../rst/user_guide/playbooks_async.rst:89 4275msgid "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." 4276msgstr "排他的ロックを必要とする操作 (yum トランザクションなど) では、同じリソースに対して Playbook の後半で他のコマンドを実行することを想定して、poll 値に 0 を指定しないでください。" 4277 4278#: ../../rst/user_guide/playbooks_async.rst:92 4279msgid "Using a higher value for ``--forks`` will result in kicking off asynchronous tasks even faster. This also increases the efficiency of polling." 4280msgstr "``--forks`` の値を増やすと、非同期タスクの開始が速くなります。これにより、ポーリングの効率が高まります。" 4281 4282#: ../../rst/user_guide/playbooks_async.rst:95 4283msgid "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``." 4284msgstr "``poll: 0`` で実行すると、Ansible は非同期ジョブキャッシュファイルを自動的にクリーンアップしません。``mode: cleanup`` で:ref:`async_status <async_status_module>` モジュールを使用して手動でクリーンアップする必要があります。" 4285 4286#: ../../rst/user_guide/playbooks_async.rst:99 4287msgid "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::" 4288msgstr "非同期タスクとの同期ポイントが必要な場合は、これを登録してジョブ ID を取得し、:ref:`async_status <async_status_module>` モジュールを使用して後続のタスクで確認することができます。以下に例を示します。" 4289 4290#: ../../rst/user_guide/playbooks_async.rst:118 4291msgid "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" 4292msgstr "``async:`` の値が十分に高くない場合は、``async_status:`` が探している一時的なステータスファイルが書き込まれていないか、存在しなくなったため、「後で確認する」タスクが失敗することになります。" 4293 4294#: ../../rst/user_guide/playbooks_async.rst:122 4295msgid "To run multiple asynchronous tasks while limiting the number of tasks running concurrently::" 4296msgstr "複数の非同期タスクを実行しながら、同時に実行するタスクの数を制限するには、以下を行います。" 4297 4298#: ../../rst/user_guide/playbooks_async.rst:163 4299#: ../../rst/user_guide/playbooks_delegation.rst:129 4300msgid ":ref:`playbooks_strategies`" 4301msgstr ":ref:`playbooks_strategies`" 4302 4303#: ../../rst/user_guide/playbooks_async.rst:164 4304msgid "Options for controlling playbook execution" 4305msgstr "Playbook の実行を制御するオプション" 4306 4307#: ../../rst/user_guide/playbooks_async.rst:167 4308#: ../../rst/user_guide/playbooks_blocks.rst:186 4309#: ../../rst/user_guide/playbooks_conditionals.rst:505 4310#: ../../rst/user_guide/playbooks_debugger.rst:326 4311#: ../../rst/user_guide/playbooks_delegation.rst:133 4312#: ../../rst/user_guide/playbooks_environment.rst:138 4313#: ../../rst/user_guide/playbooks_error_handling.rst:242 4314#: ../../rst/user_guide/playbooks_filters.rst:1805 4315#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:740 4316#: ../../rst/user_guide/playbooks_lookups.rst:34 4317#: ../../rst/user_guide/playbooks_loops.rst:442 4318#: ../../rst/user_guide/playbooks_prompts.rst:113 4319#: ../../rst/user_guide/playbooks_strategies.rst:219 4320#: ../../rst/user_guide/playbooks_tags.rst:430 4321#: ../../rst/user_guide/playbooks_templating.rst:52 4322#: ../../rst/user_guide/playbooks_tests.rst:400 4323#: ../../rst/user_guide/playbooks_variables.rst:463 4324msgid "`User Mailing List <https://groups.google.com/group/ansible-devel>`_" 4325msgstr "`ユーザーメーリングリスト <https://groups.google.com/group/ansible-devel>`_" 4326 4327#: ../../rst/user_guide/playbooks_best_practices.rst:6 4328msgid "Tips and tricks" 4329msgstr "ヒントと裏技" 4330 4331#: ../../rst/user_guide/playbooks_best_practices.rst:8 4332msgid "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." 4333msgstr "これらのヒントとコツは、Ansible の使用法を最適化するのに役に立ったため、提案としてここに示します。コンテンツの整理、Playbook の作成、インベントリーの維持、Ansible の実行に役立つことを願っています。ただし、最終的には、自身の組織と目標に最も適した方法で Ansible を使用する必要があります。" 4334 4335#: ../../rst/user_guide/playbooks_best_practices.rst:14 4336msgid "General tips" 4337msgstr "一般的なヒント" 4338 4339#: ../../rst/user_guide/playbooks_best_practices.rst:16 4340msgid "These concepts apply to all Ansible activities and artifacts." 4341msgstr "この概念は、すべての Ansible アクティビティーおよびアーティファクトに適用されます。" 4342 4343#: ../../rst/user_guide/playbooks_best_practices.rst:19 4344msgid "Keep it simple" 4345msgstr "シンプルのままにする" 4346 4347#: ../../rst/user_guide/playbooks_best_practices.rst:21 4348msgid "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." 4349msgstr "できる限りシンプルに。高度な機能は必要な場合にのみ使用し、自身のユースケースに最も一致した機能を選択してください。たとえば、外部のインベントリーファイルを使用しながら、``vars``、``vars_files``、``vars_prompt``、および ``--extra-vars`` を一度に使用することはないでしょう。何かが複雑に感じられる場合は、おそらく複雑なのです。時間をかけて、よりシンプルなソリューションを探してみてください。" 4350 4351#: ../../rst/user_guide/playbooks_best_practices.rst:24 4352msgid "Use version control" 4353msgstr "バージョン制御を使用する" 4354 4355#: ../../rst/user_guide/playbooks_best_practices.rst:26 4356msgid "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." 4357msgstr "Playbook、ロール、インベントリー、変数などのファイルを git などのバージョン管理システムで管理し、変更があった場合はリポジトリーにコミットします。バージョン管理は、インフラストラクチャーを自動化するルールをいつ、なぜ変更したかを示す監査証跡となります。" 4358 4359#: ../../rst/user_guide/playbooks_best_practices.rst:29 4360msgid "Playbook tips" 4361msgstr "Playbook のヒント" 4362 4363#: ../../rst/user_guide/playbooks_best_practices.rst:31 4364msgid "These tips help make playbooks and roles easier to read, maintain, and debug." 4365msgstr "このヒントは、Playbook とロールの読み取り、維持、およびデバッグを容易にするのに役立ちます。" 4366 4367#: ../../rst/user_guide/playbooks_best_practices.rst:34 4368msgid "Use whitespace" 4369msgstr "空白を使用する" 4370 4371#: ../../rst/user_guide/playbooks_best_practices.rst:36 4372msgid "Generous use of whitespace, for example, a blank line before each block or task, makes a playbook easy to scan." 4373msgstr "各ブロックやタスクの前に空の行など、空白を使用すると Playbook を簡単にスキャンできます。" 4374 4375#: ../../rst/user_guide/playbooks_best_practices.rst:39 4376msgid "Always name tasks" 4377msgstr "常にタスクに名前を付ける" 4378 4379#: ../../rst/user_guide/playbooks_best_practices.rst:41 4380msgid "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." 4381msgstr "タスク名は任意ですが、非常に便利なものになります。その出力で、Ansible では、実行する各タスクの名前が記載されます。各タスクの機能や理由を説明する名前を選択します。" 4382 4383#: ../../rst/user_guide/playbooks_best_practices.rst:44 4384msgid "Always mention the state" 4385msgstr "状態について常に言及する" 4386 4387#: ../../rst/user_guide/playbooks_best_practices.rst:46 4388msgid "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." 4389msgstr "多くのモジュールでは、「state」パラメーターは任意です。モジュールによって「state」のデフォルト設定は異なり、複数の「state」設定をサポートしているモジュールもあります。「state=present」や「state=absent」を明示的に設定することで、Playbook やロールがより明確になります。" 4390 4391#: ../../rst/user_guide/playbooks_best_practices.rst:49 4392msgid "Use comments" 4393msgstr "コマンドを使用する" 4394 4395#: ../../rst/user_guide/playbooks_best_practices.rst:51 4396msgid "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." 4397msgstr "タスク名や状態が明示されていても、Playbook やロール (またはインベントリー/変数ファイル) の一部にさらに説明が必要な場合があります。コメント (「#」で始まる行) を追加することで、プレイやタスク (または変数設定) が何をどのように行うのか、またその理由を他のユーザー (そして将来的には自分自身) が理解するのに役立ちます。" 4398 4399#: ../../rst/user_guide/playbooks_best_practices.rst:54 4400msgid "Inventory tips" 4401msgstr "インベントリーのヒント" 4402 4403#: ../../rst/user_guide/playbooks_best_practices.rst:56 4404msgid "These tips help keep your inventory well organized." 4405msgstr "これらのヒントは、インベントリーを十分に整理するのに役に立ちます。" 4406 4407#: ../../rst/user_guide/playbooks_best_practices.rst:59 4408msgid "Use dynamic inventory with clouds" 4409msgstr "クラウドでの動的インベントリーの使用" 4410 4411#: ../../rst/user_guide/playbooks_best_practices.rst:61 4412msgid "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." 4413msgstr "クラウドプロバイダーやその他のシステムがインフラストラクチャーの正規のリストを管理している場合は、静的なインベントリーファイルを手動で更新する代わりに、:ref:`dynamic inventory <intro_dynamic_inventory>` を使用してこれらのリストを取得します。クラウドリソースでは、タグを使用して本番環境とステージング環境を区別することができます。" 4414 4415#: ../../rst/user_guide/playbooks_best_practices.rst:64 4416msgid "Group inventory by function" 4417msgstr "機能別にインベントリーのグループ化" 4418 4419#: ../../rst/user_guide/playbooks_best_practices.rst:66 4420msgid "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`." 4421msgstr "1 つのシステムは複数のグループに属することができます。「:ref:`intro_inventory`」および「:ref:`intro_patterns`」を参照してください。*webservers*、*dbservers* など、グループ内のノードの機能に応じた名前のグループを作成すると、Playbook で機能に応じてマシンをターゲットにすることができます。グループ変数システムを使用して機能固有の変数を割り当て、機能固有のユースケースを処理するために Ansible ロールを設計することができます。「:ref:`playbooks_reuse_roles`」を参照してください。" 4422 4423#: ../../rst/user_guide/playbooks_best_practices.rst:69 4424msgid "Separate production and staging inventory" 4425msgstr "別個の実稼働およびステージングのインベントリー" 4426 4427#: ../../rst/user_guide/playbooks_best_practices.rst:71 4428msgid "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!" 4429msgstr "実稼働を開発環境、テスト環境、ステージング環境から分離するには、それぞれの環境に個別のインベントリーファイルまたはディレクトリーを使用します。この方法では、-i で対象となるものを選ぶことができます。すべての環境を 1 つのファイルにまとめておくと、驚くようなことが起こります。" 4430 4431#: ../../rst/user_guide/playbooks_best_practices.rst:76 4432msgid "Keep vaulted variables safely visible" 4433msgstr "Vault 処理された変数を安全に表示" 4434 4435#: ../../rst/user_guide/playbooks_best_practices.rst:78 4436msgid "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. You can keep the names of your variables accessible (by ``grep``, for example) without exposing any secrets by adding a layer of indirection:" 4437msgstr "機密性の高い変数や秘密の変数は、Ansible Vault で暗号化する必要があります。しかし、変数名だけでなく変数の値も暗号化すると、値の出所を見つけるのが難しくなります。間接層を追加することで、秘密を公開することなく、変数の名前に (たとえば ``grep`` で) アクセスできる状態を維持することができます。" 4438 4439#: ../../rst/user_guide/playbooks_best_practices.rst:80 4440msgid "Create a ``group_vars/`` subdirectory named after the group." 4441msgstr "グループの名前が付けられた ``group_vars/`` サブディレクトリーを作成します。" 4442 4443#: ../../rst/user_guide/playbooks_best_practices.rst:81 4444msgid "Inside this subdirectory, create two files named ``vars`` and ``vault``." 4445msgstr "このサブディレクトリー内に、``vars`` と ``vault`` という名前のファイルを作成します。" 4446 4447#: ../../rst/user_guide/playbooks_best_practices.rst:82 4448msgid "In the ``vars`` file, define all of the variables needed, including any sensitive ones." 4449msgstr "``vars`` ファイルで、機密性の高い変数など、必要な変数をすべて定義します。" 4450 4451#: ../../rst/user_guide/playbooks_best_practices.rst:83 4452msgid "Copy all of the sensitive variables over to the ``vault`` file and prefix these variables with ``vault_``." 4453msgstr "すべての機密変数を ``vault`` ファイルにコピーし、この変数の前に ``vault_`` を付けます。" 4454 4455#: ../../rst/user_guide/playbooks_best_practices.rst:84 4456msgid "Adjust the variables in the ``vars`` file to point to the matching ``vault_`` variables using jinja2 syntax: ``db_password: {{ vault_db_password }}``." 4457msgstr "jinja2 構文を使用して一致する ``vault_`` 変数を参照するように、``vars`` ファイルの変数を調整します (``db_password: {{ vault_db_password }}``)。" 4458 4459#: ../../rst/user_guide/playbooks_best_practices.rst:85 4460msgid "Encrypt the ``vault`` file to protect its contents." 4461msgstr "``vault`` ファイルを暗号化することで、そのコンテンツを保護します。" 4462 4463#: ../../rst/user_guide/playbooks_best_practices.rst:86 4464msgid "Use the variable name from the ``vars`` file in your playbooks." 4465msgstr "Playbook の ``vars`` ファイルの変数名を使用します。" 4466 4467#: ../../rst/user_guide/playbooks_best_practices.rst:88 4468msgid "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." 4469msgstr "Playbook を実行する際、Ansible は暗号化されていないファイルの変数を見つけ、暗号化されたファイルから機密性の高い変数の値を引き出します。変数ファイルと Vault ファイルの数や名前に制限はありません。" 4470 4471#: ../../rst/user_guide/playbooks_best_practices.rst:91 4472msgid "Execution tricks" 4473msgstr "実行トリック" 4474 4475#: ../../rst/user_guide/playbooks_best_practices.rst:93 4476msgid "These tips apply to using Ansible, rather than to Ansible artifacts." 4477msgstr "このヒントは、Ansible アーティファクトではなく Ansible の使用に適用されます。" 4478 4479#: ../../rst/user_guide/playbooks_best_practices.rst:96 4480msgid "Try it in staging first" 4481msgstr "最初にステージングで試す" 4482 4483#: ../../rst/user_guide/playbooks_best_practices.rst:98 4484msgid "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." 4485msgstr "変更を実稼働環境に展開する前にステージング環境でテストすることは、常に素晴らしい考えです。環境は同じ大きさである必要はなく、グループ変数を使用して環境間の違いを制御することができます。" 4486 4487#: ../../rst/user_guide/playbooks_best_practices.rst:101 4488msgid "Update in batches" 4489msgstr "バッチの更新" 4490 4491#: ../../rst/user_guide/playbooks_best_practices.rst:103 4492msgid "Use the 'serial' keyword to control how many machines you update at once in the batch. See :ref:`playbooks_delegation`." 4493msgstr "「serial」キーワードを使用して、バッチで一度にアップデートするマシンの数を制御します。「:ref:`playbooks_delegation`」を参照してください。" 4494 4495#: ../../rst/user_guide/playbooks_best_practices.rst:108 4496msgid "Handling OS and distro differences" 4497msgstr "OS とディストリビューションの相違点の処理" 4498 4499#: ../../rst/user_guide/playbooks_best_practices.rst:110 4500msgid "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::" 4501msgstr "グループ変数ファイルと ``group_by`` モジュールが連携することで、Ansible は、異なる設定、パッケージ、ツールを必要とするさまざまなオペレーティングシステムやディストリビューションに対応して実行することができます。``group_by`` モジュールは、特定の条件に一致するホストの動的グループを作成します。このグループは、インベントリーファイルで定義する必要はありません。この方法では、異なるオペレーティングシステムやディストリビューション上で異なるタスクを実行することができます。以下に例を示します。" 4502 4503#: ../../rst/user_guide/playbooks_best_practices.rst:128 4504msgid "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::" 4505msgstr "最初のプレイでは、すべてのシステムをオペレーティングシステムの名前に基づいて動的なグループに分類します。後のプレイでは、これらのグループを ``hosts`` 行のパターンとして使用できます。また、グループの変数ファイルでグループ固有の設定を追加することもできます。``group_by`` タスクで作成された名前、後続のプレイでのパターンの名前、グループの変数ファイルの名前の 3 つの名前がすべて一致する必要があります。以下に例を示します。" 4506 4507#: ../../rst/user_guide/playbooks_best_practices.rst:138 4508msgid "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." 4509msgstr "この例では、CentOS マシンでは asdf に「42」という値が設定されますが、その他のマシンでは「10」が設定されます。これは、変数の設定だけでなく、特定のシステムだけに特定のロールを適用するためにも使用できます。" 4510 4511#: ../../rst/user_guide/playbooks_best_practices.rst:141 4512msgid "You can use the same setup with ``include_vars`` when you only need OS-specific variables, not tasks::" 4513msgstr "タスクではなく、OS 固有の変数のみを必要とする場合は、``include_vars`` で同じ設定を使用できます。" 4514 4515#: ../../rst/user_guide/playbooks_best_practices.rst:150 4516msgid "This pulls in variables from the group_vars/os_CentOS.yml file." 4517msgstr "これにより、group_vars/os_CentOS.yml ファイルから変数がプルされます。" 4518 4519#: ../../rst/user_guide/playbooks_best_practices.rst:154 4520#: ../../rst/user_guide/playbooks_intro.rst:142 4521#: ../../rst/user_guide/playbooks_reuse_includes.rst:13 4522#: ../../rst/user_guide/playbooks_reuse_roles.rst:599 4523#: ../../rst/user_guide/sample_setup.rst:272 4524msgid ":ref:`yaml_syntax`" 4525msgstr ":ref:`yaml_syntax`" 4526 4527#: ../../rst/user_guide/playbooks_best_practices.rst:155 4528#: ../../rst/user_guide/playbooks_intro.rst:143 4529#: ../../rst/user_guide/playbooks_reuse_includes.rst:14 4530#: ../../rst/user_guide/playbooks_reuse_roles.rst:600 4531#: ../../rst/user_guide/sample_setup.rst:273 4532msgid "Learn about YAML syntax" 4533msgstr "YAML 構文について" 4534 4535#: ../../rst/user_guide/playbooks_best_practices.rst:157 4536#: ../../rst/user_guide/sample_setup.rst:275 4537msgid "Review the basic playbook features" 4538msgstr "基本的な Playbook 機能の確認" 4539 4540#: ../../rst/user_guide/playbooks_best_practices.rst:161 4541#: ../../rst/user_guide/playbooks_reuse_includes.rst:28 4542#: ../../rst/user_guide/sample_setup.rst:279 4543msgid "Learn how to extend Ansible by writing your own modules" 4544msgstr "独自のモジュールを作成して Ansible を拡張する方法について" 4545 4546#: ../../rst/user_guide/playbooks_best_practices.rst:162 4547#: ../../rst/user_guide/playbooks_intro.rst:150 4548#: ../../rst/user_guide/sample_setup.rst:280 4549msgid ":ref:`intro_patterns`" 4550msgstr ":ref:`intro_patterns`" 4551 4552#: ../../rst/user_guide/playbooks_best_practices.rst:163 4553#: ../../rst/user_guide/playbooks_intro.rst:151 4554#: ../../rst/user_guide/sample_setup.rst:281 4555msgid "Learn about how to select hosts" 4556msgstr "ホストの選択方法について" 4557 4558#: ../../rst/user_guide/playbooks_best_practices.rst:164 4559#: ../../rst/user_guide/playbooks_intro.rst:152 4560#: ../../rst/user_guide/sample_setup.rst:282 4561msgid "`GitHub examples directory <https://github.com/ansible/ansible-examples>`_" 4562msgstr "`GitHub サンプルディレクトリー <https://github.com/ansible/ansible-examples>`_" 4563 4564#: ../../rst/user_guide/playbooks_best_practices.rst:165 4565#: ../../rst/user_guide/sample_setup.rst:283 4566msgid "Complete playbook files from the github project source" 4567msgstr "Github プロジェクトソースの完全な Playbook ファイル" 4568 4569#: ../../rst/user_guide/playbooks_blocks.rst:5 4570msgid "Blocks" 4571msgstr "ブロック" 4572 4573#: ../../rst/user_guide/playbooks_blocks.rst:7 4574msgid "Blocks create logical groups of tasks. Blocks also offer ways to handle task errors, similar to exception handling in many programming languages." 4575msgstr "ブロックは、タスクの論理的なグループを作ります。また、ブロックにはタスクのエラーを処理する方法があり、多くのプログラミング言語の例外処理に似ています。" 4576 4577#: ../../rst/user_guide/playbooks_blocks.rst:13 4578msgid "Grouping tasks with blocks" 4579msgstr "ブロックを使用したタスクのグループ化" 4580 4581#: ../../rst/user_guide/playbooks_blocks.rst:15 4582msgid "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." 4583msgstr "ブロック内のすべてのタスクは、ブロックレベルで適用されるディレクティブを継承します。単一のタスクに適用できるもの (ループを除く) のほとんどは、ブロックレベルで適用できるため、ブロックを使用すると、タスクに共通するデータやディレクティブを設定することが非常に簡単になります。ディレクティブはブロック自体には影響せず、ブロックで囲まれたタスクにのみ継承されます。たとえば、`when` 文は、ブロック自体にではなく、ブロック内のタスクに適用されます。" 4584 4585#: ../../rst/user_guide/playbooks_blocks.rst:17 4586msgid "Block example with named tasks inside the block" 4587msgstr "内部に名前付きタスクを含むブロックの例" 4588 4589#: ../../rst/user_guide/playbooks_blocks.rst:46 4590msgid "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." 4591msgstr "上の例では、Ansible がブロック内の 3 つのタスクをそれぞれ実行する前に、「when」条件が評価されます。また、3 つのタスクはすべて、特権昇格ディレクティブを継承し、root ユーザーとして実行します。最後に、``ignore_errors: yes`` は、一部のタスクが失敗しても、Ansible が Playbook の実行を継続することを保証します。" 4592 4593#: ../../rst/user_guide/playbooks_blocks.rst:48 4594msgid "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." 4595msgstr "ブロックの名前は、Ansible 2.3 から利用できるようになりました。Playbook の実行時に実行されているタスクの可視性を高めるために、ブロック内やその他の場所で、すべてのタスクに名前を使用することが推奨されます。" 4596 4597#: ../../rst/user_guide/playbooks_blocks.rst:53 4598msgid "Handling errors with blocks" 4599msgstr "ブロックを使用したエラーの処理" 4600 4601#: ../../rst/user_guide/playbooks_blocks.rst:55 4602msgid "You can control how Ansible responds to task errors using blocks with ``rescue`` and ``always`` sections." 4603msgstr "``rescue`` セクションおよび ``always`` セクションのブロックを使用して、Ansible がタスクエラーに対応する方法を制御できます。" 4604 4605#: ../../rst/user_guide/playbooks_blocks.rst:57 4606msgid "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." 4607msgstr "レスキューブロックは、ブロック内の先行タスクが失敗したときに実行するタスクを指定します。このアプローチは、多くのプログラミング言語における例外処理に似ています。Ansible は、タスクが「失敗」状態を返した後にのみレスキューブロックを実行します。誤ったタスク定義や到達不可能なホストでは、レスキューブロックは実行しません。" 4608 4609#: ../../rst/user_guide/playbooks_blocks.rst:60 4610msgid "Block error handling example" 4611msgstr "ブロックエラー処理例" 4612 4613#: ../../rst/user_guide/playbooks_blocks.rst:82 4614msgid "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." 4615msgstr "``always`` セクションをブロックに追加することもできます。前のブロックのタスクステータスに関係なく、``always`` セクションのタスクは実行します。" 4616 4617#: ../../rst/user_guide/playbooks_blocks.rst:85 4618msgid "Block with always section" 4619msgstr "always セクションのあるブロック" 4620 4621#: ../../rst/user_guide/playbooks_blocks.rst:106 4622msgid "Together, these elements offer complex error handling." 4623msgstr "この要素をまとめると、複雑なエラー処理を行います。" 4624 4625#: ../../rst/user_guide/playbooks_blocks.rst:108 4626msgid "Block with all sections" 4627msgstr "すべてのセクションのブロック" 4628 4629#: ../../rst/user_guide/playbooks_blocks.rst:140 4630msgid "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." 4631msgstr "``block`` のタスクは正常に実行されます。ブロック内のいずれかのタスクが ``failed`` を返すと、``rescue`` セクションはエラーから回復するためのタスクを実行します。``always`` セクションは、``block`` セクションと ``rescue`` セクションの結果に関わらず実行されます。" 4632 4633#: ../../rst/user_guide/playbooks_blocks.rst:142 4634msgid "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." 4635msgstr "ブロック内でエラーが発生し、レスキュータスクが成功した場合、Ansible は実行中の元のタスクの失敗ステータスを元に戻し、元のタスクが成功したかのようにプレイの実行を継続します。レスキューとなったタスクは成功したとみなされ、``max_fail_percentage`` や ``any_errors_fatal`` の設定は発生しません。ただし、Ansible は Playbook の統計で失敗を報告します。" 4636 4637#: ../../rst/user_guide/playbooks_blocks.rst:144 4638msgid "You can use blocks with ``flush_handlers`` in a rescue task to ensure that all handlers run even if an error occurs:" 4639msgstr "レスキュータスクにおいて ``flush_handlers`` でブロックを使用し、エラーが発生した場合でもすべてのハンドラーが実行されるようにします。" 4640 4641#: ../../rst/user_guide/playbooks_blocks.rst:146 4642msgid "Block run handlers in error handling" 4643msgstr "エラー処理におけるブロック実行ハンドラー" 4644 4645#: ../../rst/user_guide/playbooks_blocks.rst:172 4646msgid "Ansible provides a couple of variables for tasks in the ``rescue`` portion of a block:" 4647msgstr "Ansible は、ブロックの ``rescue`` の部分にタスクの変数をいくつか提供します。" 4648 4649#: ../../rst/user_guide/playbooks_blocks.rst:175 4650msgid "ansible_failed_task" 4651msgstr "ansible_failed_task" 4652 4653#: ../../rst/user_guide/playbooks_blocks.rst:175 4654msgid "The task that returned 'failed' and triggered the rescue. For example, to get the name use ``ansible_failed_task.name``." 4655msgstr "「失敗した」と返され、レスキューのきっかけとなったタスクです。たとえば、名前を取得するには ``ansible_failed_task.name`` を使用します。" 4656 4657#: ../../rst/user_guide/playbooks_blocks.rst:178 4658msgid "ansible_failed_result" 4659msgstr "ansible_failed_result" 4660 4661#: ../../rst/user_guide/playbooks_blocks.rst:178 4662msgid "The captured return result of the failed task that triggered the rescue. This would equate to having used this var in the ``register`` keyword." 4663msgstr "レスキューをトリガーした失敗したタスクの戻り値。これは、``register`` キーワードでこの変数を使用するのと同じです。" 4664 4665#: ../../rst/user_guide/playbooks_blocks.rst:185 4666#: ../../rst/user_guide/playbooks_conditionals.rst:500 4667#: ../../rst/user_guide/playbooks_filters.rst:1802 4668#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:737 4669#: ../../rst/user_guide/playbooks_loops.rst:435 4670#: ../../rst/user_guide/playbooks_strategies.rst:218 4671#: ../../rst/user_guide/playbooks_tags.rst:429 4672#: ../../rst/user_guide/playbooks_templating.rst:49 4673#: ../../rst/user_guide/playbooks_tests.rst:397 4674#: ../../rst/user_guide/playbooks_variables.rst:458 4675msgid "Playbook organization by roles" 4676msgstr "ロール別の Playbook の組織" 4677 4678#: ../../rst/user_guide/playbooks_checkmode.rst:5 4679msgid "Validating tasks: check mode and diff mode" 4680msgstr "タスクの検証: 確認モードと差分モード" 4681 4682#: ../../rst/user_guide/playbooks_checkmode.rst:7 4683msgid "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." 4684msgstr "Ansible には、タスクを検証するために、確認モードと差分モードという 2 つの実行モードが用意されています。これらのモードは、別々に使用することも、一緒に使用することもできます。これらのモードは、Playbook やロールを作成または編集する際に、その実行内容を知りたい場合に便利です。確認モードでは、Ansible はリモートシステムに変更を加えずに実行します。確認モードをサポートするモジュールは、自身が行った変更を報告します。確認モードをサポートしていないモジュールは、何も報告せず、何も行いません。差分モードでは、Ansible は事前と事後の比較を行います。差分モードをサポートするモジュールは、詳細情報を表示します。確認モードと差分モードを組み合わせて、Playbook やロールの詳細な検証を行うことができます。" 4685 4686#: ../../rst/user_guide/playbooks_checkmode.rst:13 4687msgid "Using check mode" 4688msgstr "確認モードの使用" 4689 4690#: ../../rst/user_guide/playbooks_checkmode.rst:15 4691msgid "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::" 4692msgstr "確認モードはあくまでもシミュレーションです。:ref:`登録変数に基づいた条件 <conditionals_registered_vars>` (先行タスクの結果) を使用するタスクの出力は生成されません。しかし、一度に 1 つのノードで実行する構成管理の Playbook を検証するには最適です。Playbook を確認モードで実行するには以下を行います。" 4693 4694#: ../../rst/user_guide/playbooks_checkmode.rst:22 4695msgid "Enforcing or preventing check mode on tasks" 4696msgstr "タスクでの確認モードの強制または禁止" 4697 4698#: ../../rst/user_guide/playbooks_checkmode.rst:26 4699msgid "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:" 4700msgstr "Playbook を実行する際に ``--check`` を付けるかどうかに関わらず、特定のタスクを常に確認モードで実行する場合は、それらのタスクに ``check_mode`` オプションを追加します。" 4701 4702#: ../../rst/user_guide/playbooks_checkmode.rst:28 4703msgid "To force a task to run in check mode, even when the playbook is called without ``--check``, set ``check_mode: yes``." 4704msgstr "``--check`` を使用せずに Playbook が呼び出された場合でも、タスクを強制的に確認モードで実行するには、``check_mode: yes`` を設定します。" 4705 4706#: ../../rst/user_guide/playbooks_checkmode.rst:29 4707msgid "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``." 4708msgstr "Playbook が ``--check`` で呼び出された場合でも、タスクを強制的に通常モードで実行し、システムに変更を加えるには、``check_mode: no`` を設定します。" 4709 4710#: ../../rst/user_guide/playbooks_checkmode.rst:46 4711msgid "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." 4712msgstr "``check_mode: yes`` を使用してシングルタスクを実行すると、Ansible モジュールをテストする際に便利です。モジュール自体をテストしたり、モジュールが変更を行う条件をテストしたりすることができます。これらのタスクに変数 (:ref:`playbooks_conditionals` を参照) を登録すると、潜在的な変更についてさらに詳しく知ることができます。" 4713 4714#: ../../rst/user_guide/playbooks_checkmode.rst:48 4715msgid "Prior to version 2.2 only the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``." 4716msgstr "バージョン 2.2 以前では、``check_mode: no`` に相当するものだけが存在していました。その表記法は ``always_run: yes`` でした。" 4717 4718#: ../../rst/user_guide/playbooks_checkmode.rst:51 4719msgid "Skipping tasks or ignoring errors in check mode" 4720msgstr "タスクをスキップまたは確認モードでエラーを無視する" 4721 4722#: ../../rst/user_guide/playbooks_checkmode.rst:55 4723msgid "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::" 4724msgstr "Ansible を確認モードで実行する際に、タスクをスキップしたり、タスクのエラーを無視したりする場合は、ブール型のマジック変数 ``ansible_check_mode`` を使用することができます。この変数は、Ansible を確認モードで実行すると、``True`` に設定されます。以下に例を示します。" 4725 4726#: ../../rst/user_guide/playbooks_checkmode.rst:74 4727msgid "Using diff mode" 4728msgstr "差分モードの使用" 4729 4730#: ../../rst/user_guide/playbooks_checkmode.rst:76 4731msgid "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)." 4732msgstr "ansible-playbook の ``--diff`` オプションは、単独でも ``--check`` と併用しても構いません。差分モードで実行すると、差分モードをサポートしているすべてのモジュールが、行われた変更を報告します (``--check`` と併用する場合は、行われたであろう変更を報告します)。差分モードは、ファイルを操作するモジュール (template モジュールなど) で最も一般的ですが、その他のモジュールでも「変更前と変更後」の情報を表示することがあります (user モジュールなど)。" 4733 4734#: ../../rst/user_guide/playbooks_checkmode.rst:78 4735msgid "Diff mode produces a large amount of output, so it is best used when checking a single host at a time. For example::" 4736msgstr "差分モードは大量の出力を生成するため、一度に 1 つのホストを確認するときに使うのが最適です。以下に例を示します。" 4737 4738#: ../../rst/user_guide/playbooks_checkmode.rst:85 4739msgid "Enforcing or preventing diff mode on tasks" 4740msgstr "タスクでの差分モードの強制または禁止" 4741 4742#: ../../rst/user_guide/playbooks_checkmode.rst:87 4743msgid "Because the ``--diff`` option can reveal sensitive information, you can disable it for a task by specifying ``diff: no``. For example::" 4744msgstr "``--diff`` オプションは機密情報を表示する可能性があるため、``diff: no`` を指定してタスクに対してこれを無効にすることができます。以下に例を示します。" 4745 4746#: ../../rst/user_guide/playbooks_conditionals.rst:5 4747msgid "Conditionals" 4748msgstr "条件 (Conditional)" 4749 4750#: ../../rst/user_guide/playbooks_conditionals.rst:7 4751msgid "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." 4752msgstr "Playbook では、ファクト (リモートシステムに関するデータ)、変数、または以前のタスクの結果の値に応じて、異なるタスクを実行したり、異なるゴールを設定したりすることができます。また、ある変数の値に応じて別の変数の値を変更したい場合もあります。また、ホストが他の基準に一致するかどうかに基づいて、ホストの追加グループを作成することもできます。これらのことはすべて、条件分岐で実現できます。" 4753 4754#: ../../rst/user_guide/playbooks_conditionals.rst:9 4755msgid "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." 4756msgstr "Ansible は Jinja2 の :ref:`テスト <playbooks_tests>` および :ref:`フィルター <playbooks_filters>` を条件分岐で使用しています。Ansible は標準的なテストやフィルターをすべてサポートしており、独自のものもいくつか追加されています。" 4757 4758#: ../../rst/user_guide/playbooks_conditionals.rst:13 4759msgid "There are many options to control execution flow in Ansible. You can find more examples of supported conditionals at `<https://jinja.palletsprojects.com/en/master/templates/#comparisons>`_." 4760msgstr "Ansible で実行フローを制御するオプションは多数あります。サポートされている条件分岐の例は、`<https://jinja.palletsprojects.com/en/master/templates/#comparisons>`_ で確認できます。" 4761 4762#: ../../rst/user_guide/playbooks_conditionals.rst:21 4763msgid "Basic conditionals with ``when``" 4764msgstr "``when`` を使用する基本的な条件分岐" 4765 4766#: ../../rst/user_guide/playbooks_conditionals.rst:23 4767msgid "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:" 4768msgstr "最も簡単な条件文は、1 つのタスクに適用されるものです。タスクを作成し、テストを適用する ``when`` の文を追加します。``when`` 句は、二重中括弧のない生の Jinja2 式です (:ref:`group_by_module` 参照)。タスクや Playbook を実行すると、Ansible はすべてのホストに対してテストを評価します。テストにパスする (True の値を返す) ホストでは、Ansible はそのタスクを実行します。たとえば、複数のマシンに mysql をインストールし、そのうちのいくつかのマシンでは SELinux が有効になっている場合は、mysql の実行を許可するように SELinux を設定するタスクがあります。このタスクは、SELinux が有効になっているマシンでのみ実行されるようにします。" 4769 4770#: ../../rst/user_guide/playbooks_conditionals.rst:37 4771msgid "Conditionals based on ansible_facts" 4772msgstr "ansible_facts に基づく条件分岐" 4773 4774#: ../../rst/user_guide/playbooks_conditionals.rst:39 4775msgid "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:" 4776msgstr "ファクトに基づいてタスクを実行したりスキップしたりしたい場合がよくあります。ファクトとは、IP アドレス、オペレーティングシステム、ファイルシステムの状態など、個々のホストの属性のことです。ファクトに基づく条件分岐で、以下を行います。" 4777 4778#: ../../rst/user_guide/playbooks_conditionals.rst:41 4779msgid "You can install a certain package only when the operating system is a particular version." 4780msgstr "特定のパッケージは、オペレーティングシステムが特定のバージョンの場合にのみインストールできます。" 4781 4782#: ../../rst/user_guide/playbooks_conditionals.rst:42 4783msgid "You can skip configuring a firewall on hosts with internal IP addresses." 4784msgstr "内部 IP アドレスを持つホストでファイアウォールの設定を省略できます。" 4785 4786#: ../../rst/user_guide/playbooks_conditionals.rst:43 4787msgid "You can perform cleanup tasks only when a filesystem is getting full." 4788msgstr "ファイルシステムが満杯になった場合にのみ、クリーンアップタスクを実行することができます。" 4789 4790#: ../../rst/user_guide/playbooks_conditionals.rst:45 4791msgid "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::" 4792msgstr "条件文に頻繁に現れるファクトの一覧は、:ref:`commonly_used_facts` を参照してください。すべてのファクトがすべてのホストに存在するわけではありません。たとえば、以下の例で使用されている「lsb_major_release」ファクトは、ターゲットホストに lsb_release パッケージがインストールされている場合にのみ存在します。システム上で利用可能なファクトを確認するには、Playbook にデバッグタスクを追加します。" 4793 4794#: ../../rst/user_guide/playbooks_conditionals.rst:51 4795msgid "Here is a sample conditional based on a fact:" 4796msgstr "以下は、ファクトに基づく条件分岐の例です。" 4797 4798#: ../../rst/user_guide/playbooks_conditionals.rst:60 4799msgid "If you have multiple conditions, you can group them with parentheses:" 4800msgstr "複数の条件がある場合は、括弧でグループ化できます。" 4801 4802#: ../../rst/user_guide/playbooks_conditionals.rst:70 4803msgid "You can use `logical operators <https://jinja.palletsprojects.com/en/master/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::" 4804msgstr "`論理演算子 <https://jinja.palletsprojects.com/en/master/templates/#logic>`_ を使用して条件を組み合わせることができます。すべてが True である必要がある複数の条件がある場合 (つまり、論理的な ``and``)、それらをリストとして指定することができます。" 4805 4806#: ../../rst/user_guide/playbooks_conditionals.rst:79 4807msgid "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::" 4808msgstr "ファクトまたは変数が文字列で、それに対して数学比較を実行する必要がある場合は、フィルターを使用して Ansible が値を整数として読み取るようにします。" 4809 4810#: ../../rst/user_guide/playbooks_conditionals.rst:88 4811msgid "Conditions based on registered variables" 4812msgstr "登録済みの変数に基づく条件" 4813 4814#: ../../rst/user_guide/playbooks_conditionals.rst:90 4815msgid "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:" 4816msgstr "Playbook では、以前のタスクの結果に基づいてタスクを実行またはスキップしたい場合がよくあります。たとえば、以前のタスクによってサービスがアップグレードされた後に、そのサービスを設定したい場合などです。登録された変数に基づいて条件分岐を作成するには、次のようにします。" 4817 4818#: ../../rst/user_guide/playbooks_conditionals.rst:92 4819msgid "Register the outcome of the earlier task as a variable." 4820msgstr "以前のタスクの結果を変数として登録します。" 4821 4822#: ../../rst/user_guide/playbooks_conditionals.rst:93 4823msgid "Create a conditional test based on the registered variable." 4824msgstr "登録した変数に基づいて条件分岐テストを作成します。" 4825 4826#: ../../rst/user_guide/playbooks_conditionals.rst:95 4827msgid "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::" 4828msgstr "登録された変数の名前は、``register`` キーワードを使用して作成します。登録された変数には、そのキーワードを作成したタスクのステータスと、そのタスクが生成した出力が常に含まれています。登録された変数は、テンプレートやアクション行、および条件付きの ``when`` 文で使用できます。登録された変数の文字列内容にアクセスするには、``variable.stdout`` を使用します。以下に例を示します。" 4829 4830#: ../../rst/user_guide/playbooks_conditionals.rst:110 4831msgid "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::" 4832msgstr "登録された結果は、変数がリストの場合、タスクのループ内で使用できます。変数がリストでない場合は、``stdout_lines`` または``variable.stdout.split()`` でリストに変換できます。また、他のフィールドで行を分割することもできます。" 4833 4834#: ../../rst/user_guide/playbooks_conditionals.rst:128 4835msgid "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:" 4836msgstr "登録された変数の文字列内容は空になることがあります。登録された変数の標準出力が空のホストでのみ別のタスクを実行したい場合は、登録された変数の文字列内容が空であるかどうかをチェックします。" 4837 4838#: ../../rst/user_guide/playbooks_conditionals.rst:146 4839msgid "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:" 4840msgstr "タスクが失敗したホストや、条件が満たされずに Ansible がタスクをスキップしたホストであっても、Ansible は常にすべてのホストの登録変数に何かを登録します。これらのホストでフォローアップタスクを実行するには、登録済みの変数に ``is skipped`` を照会します (「undefined」や「default」ではありません)。詳細は、「:ref:`registered_variables`」を参照してください。以下は、タスクの成功または失敗に基づく条件分岐のサンプルです。失敗したときにホスト上で Ansible の実行を継続させたい場合は、エラーを無視することを忘れないでください。" 4841 4842#: ../../rst/user_guide/playbooks_conditionals.rst:168 4843msgid "Older versions of Ansible used ``success`` and ``fail``, but ``succeeded`` and ``failed`` use the correct tense. All of these options are now valid." 4844msgstr "古いバージョンの Ansible では、``success`` および ``fail`` が使用されていましたが、``succeeded`` および ``failed`` は正しい時制を使用します。このオプションはすべて有効になりました。" 4845 4846#: ../../rst/user_guide/playbooks_conditionals.rst:172 4847msgid "Conditionals based on variables" 4848msgstr "変数に基づく条件分岐" 4849 4850#: ../../rst/user_guide/playbooks_conditionals.rst:174 4851msgid "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:" 4852msgstr "また、Playbook やインベントリーで定義された変数に基づいて、条件分岐を作成することもできます。条件分岐にはブール値の入力が必要なため (条件を成立させるためには、テストが True と評価されなければなりません)、「yes」、「on」、「1」、「true」などの内容を持つ文字列変数など、ブール値以外の変数には、``| bool`` フィルターを適用する必要があります。変数は次のように定義できます。" 4853 4854#: ../../rst/user_guide/playbooks_conditionals.rst:182 4855msgid "With the variables above, Ansible would run one of these tasks and skip the other:" 4856msgstr "上記の変数を使用すると、Ansible はこれらのタスクのいずれかを実行し、他のタスクを省略します。" 4857 4858#: ../../rst/user_guide/playbooks_conditionals.rst:195 4859msgid "If a required variable has not been set, you can skip or fail using Jinja2's `defined` test. For example:" 4860msgstr "必要な変数が設定されていない場合は、省略するか、Jinja2 の `定義済み` テストを使用して失敗します。以下に例を示します。" 4861 4862#: ../../rst/user_guide/playbooks_conditionals.rst:208 4863msgid "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." 4864msgstr "これは、変数ファイルの条件分岐インポートとの組み合わせで特に有効です (以下参照)。これらの例が示すように、条件分岐の中で変数を使用するために `{{ }}` を使用する必要はありません。それらはすでに暗示されているためです。" 4865 4866#: ../../rst/user_guide/playbooks_conditionals.rst:214 4867msgid "Using conditionals in loops" 4868msgstr "ループでの条件分岐の使用" 4869 4870#: ../../rst/user_guide/playbooks_conditionals.rst:216 4871msgid "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:" 4872msgstr "``when`` 文と :ref:`loop <playbooks_loops>` を組み合わせた場合、Ansible は各アイテムに対して個別に条件を処理します。これは意図的なもので、ループ内の一部のアイテムでタスクを実行し、他のアイテムではスキップすることができます。以下に例を示します。" 4873 4874#: ../../rst/user_guide/playbooks_conditionals.rst:226 4875msgid "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:" 4876msgstr "ループ変数が未定義のときにタスク全体を省略する必要がある場合は、`|default` フィルターを使用して空のイテレーターを指定します。たとえば、リストをループする場合は、以下を行います。" 4877 4878#: ../../rst/user_guide/playbooks_conditionals.rst:235 4879msgid "You can do the same thing when looping over a dict:" 4880msgstr "同じことが、ディクショナリーをループするときにもできます。" 4881 4882#: ../../rst/user_guide/playbooks_conditionals.rst:247 4883msgid "Loading custom facts" 4884msgstr "カスタムファクトの読み込み中" 4885 4886#: ../../rst/user_guide/playbooks_conditionals.rst:249 4887msgid "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:" 4888msgstr ":ref:`developing_modules` で説明しているように、独自のファクトを提供することができます。それらを実行するには、タスクリストの先頭にある独自のカスタムファクト収集モジュールを呼び出すだけで、そこから返された変数は将来のタスクにアクセスできるようになります。" 4889 4890#: ../../rst/user_guide/playbooks_conditionals.rst:264 4891msgid "Conditionals with re-use" 4892msgstr "再利用による条件分岐" 4893 4894#: ../../rst/user_guide/playbooks_conditionals.rst:266 4895msgid "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." 4896msgstr "条件分岐は、再利用可能なタスクファイル、Playbook、またはロールで使用できます。Ansible はこれらの条件文を、動的再利用 (インクルード) および静的再利用 (インポート) で異なる方法で実行します。Ansible での再利用の詳細は、「:ref:`playbooks_reuse`」を参照してください。" 4897 4898#: ../../rst/user_guide/playbooks_conditionals.rst:271 4899msgid "Conditionals with imports" 4900msgstr "インポートのある条件分岐" 4901 4902#: ../../rst/user_guide/playbooks_conditionals.rst:273 4903msgid "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``::" 4904msgstr "インポートステートメントに条件分岐を追加すると、Ansible はインポートされたファイル内のすべてのタスクにその条件を適用します。この動作は、:ref:`tag_inheritance` と同等です。Ansible は、すべてのタスクに条件を適用し、各タスクを個別に評価します。たとえば、``main.yml`` という Playbookと、``other_tasks.yml`` というタスクファイルがあるとします。" 4905 4906#: ../../rst/user_guide/playbooks_conditionals.rst:289 4907#: ../../rst/user_guide/playbooks_conditionals.rst:329 4908msgid "Ansible expands this at execution time to the equivalent of::" 4909msgstr "Ansible は、実行時にこれを以下に相当するものに拡張します。" 4910 4911#: ../../rst/user_guide/playbooks_conditionals.rst:303 4912msgid "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." 4913msgstr "したがって、``x`` が最初に未定義であれば、``debug`` のタスクはスキップされます。このような動作を望まない場合は、``include_*`` 文を使用して、その文自体にのみ条件を適用します。" 4914 4915#: ../../rst/user_guide/playbooks_conditionals.rst:305 4916msgid "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`." 4917msgstr "``import_playbook`` には、他の ``import_*`` 文と同様に条件を適用できます。この方法を使用すると、Ansible は基準に一致しないすべてのホスト上のすべてのタスクに対して「skipped」メッセージを返し、反復的な出力を作成します。多くの場合、:ref:`group_by モジュール <group_by_module>` は、同じ目的を達成するためのより合理的な方法となります。「:ref:`os_variance`」を参照してください。" 4918 4919#: ../../rst/user_guide/playbooks_conditionals.rst:310 4920msgid "Conditionals with includes" 4921msgstr "includes を持つ条件分岐" 4922 4923#: ../../rst/user_guide/playbooks_conditionals.rst:312 4924msgid "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::" 4925msgstr "``include_*`` 文に条件分岐を使用すると、その条件はインクルードタスク自体にのみ適用され、インクルードファイル内の他のタスクには適用されません。上記のインポートに対する条件分岐の例と対比するために、同じ Playbook とタスクファイルを見てください。ただし、インポートの代わりにインクルードを使用しています。" 4926 4927#: ../../rst/user_guide/playbooks_conditionals.rst:347 4928msgid "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`." 4929msgstr "``import_tasks`` の代わりに ``include_tasks`` を使用すると、``other_tasks.yml`` からの両方のタスクが想定どおりに実行されます。``include`` と ``import`` の相違点は、「:ref:`playbooks_reuse`」を参照してください。" 4930 4931#: ../../rst/user_guide/playbooks_conditionals.rst:350 4932msgid "Conditionals with roles" 4933msgstr "ロールを含む条件分岐" 4934 4935#: ../../rst/user_guide/playbooks_conditionals.rst:352 4936msgid "There are three ways to apply conditions to roles:" 4937msgstr "状態をロールに適用する方法は 3 つあります。" 4938 4939#: ../../rst/user_guide/playbooks_conditionals.rst:354 4940msgid "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." 4941msgstr "``when`` 文を ``roles`` キーワードの下に置くことで、ロール内のすべてのタスクに同じ条件を追加します。このセクションの例を参照してください。" 4942 4943#: ../../rst/user_guide/playbooks_conditionals.rst:355 4944msgid "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." 4945msgstr "Playbook の静的 ``import_role`` に ``when`` 文を配置して、ロール内のすべてのタスクに同じ条件を追加します。" 4946 4947#: ../../rst/user_guide/playbooks_conditionals.rst:356 4948msgid "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." 4949msgstr "ロール自体の中の個々のタスクまたはブロックに条件を追加します。これは、``when`` 文に基づいてロール内の一部のタスクを選択またはスキップすることができる唯一の方法です。ロール内のタスクを選択またはスキップするには、個々のタスクまたはブロックに条件を設定し、Playbook で動的 ``include_role`` を使用し、条件をインクルードに追加する必要があります。この方法を使用すると、Ansible は条件をインクルード自体に加えて、``when`` の文を持つロール内のすべてのタスクに適用します。" 4950 4951#: ../../rst/user_guide/playbooks_conditionals.rst:358 4952msgid "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:" 4953msgstr "``roles`` キーワードを使用して Playbook にロールを静的に組み込むと、Ansible は定義した条件をロール内のすべてのタスクに追加します。たとえば、以下のようになります。" 4954 4955#: ../../rst/user_guide/playbooks_conditionals.rst:370 4956msgid "Selecting variables, files, or templates based on facts" 4957msgstr "ファクトに基づいた変数、ファイル、またはテンプレートの選択" 4958 4959#: ../../rst/user_guide/playbooks_conditionals.rst:372 4960msgid "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:" 4961msgstr "ホストに関するファクトによって、特定の変数に使用する値や、そのホスト用に選択するファイルやテンプレートが決定することがあります。たとえば、パッケージの名前は CentOS と Debian では異なります。また、一般的なサービスの設定ファイルも、OS のフレーバーやバージョンごとに異なります。ホストに関するファクトに基づいて、異なる変数ファイルやテンプレートなどを読み込むには、以下を行います。" 4962 4963#: ../../rst/user_guide/playbooks_conditionals.rst:374 4964msgid "name your vars files, templates, or files to match the Ansible fact that differentiates them" 4965msgstr "変数ファイル、テンプレート、またはファイルを区別する Ansible ファクトに合わせて名前を付ける" 4966 4967#: ../../rst/user_guide/playbooks_conditionals.rst:376 4968msgid "select the correct vars file, template, or file for each host with a variable based on that Ansible fact" 4969msgstr "Ansible ファクトに基づいて変数を使用して、各ホストの正しい変数ファイル、テンプレート、またはファイルを選択します。" 4970 4971#: ../../rst/user_guide/playbooks_conditionals.rst:378 4972msgid "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." 4973msgstr "Ansible は、変数とタスクを分離することで、Playbook がネストされた条件分岐による任意のコードにならないようにしています。このアプローチでは、追跡すべき決定ポイントが少なくなるため、より合理的で監査可能な設定ルールになります。" 4974 4975#: ../../rst/user_guide/playbooks_conditionals.rst:381 4976msgid "Selecting variables files based on facts" 4977msgstr "ファクトに基づく変数ファイルの選択" 4978 4979#: ../../rst/user_guide/playbooks_conditionals.rst:383 4980msgid "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::" 4981msgstr "変数の値を vars ファイルに置き、条件付きでインポートすることで、最小限の構文で複数のプラットフォームや OS バージョンで動作する Playbook を作成することができます。一部の CentOS と一部の Debian サーバーに Apache をインストールする場合は、YAML のキーと値で変数ファイルを作成します。以下に例を示します。" 4982 4983#: ../../rst/user_guide/playbooks_conditionals.rst:390 4984msgid "Then import those variables files based on the facts you gather on the hosts in your playbook::" 4985msgstr "次に、Playbook のホストに収集するファクトに基づいて、これらの変数ファイルをインポートします。" 4986 4987#: ../../rst/user_guide/playbooks_conditionals.rst:404 4988msgid "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." 4989msgstr "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 がエラーを出力します。" 4990 4991#: ../../rst/user_guide/playbooks_conditionals.rst:407 4992msgid "Selecting files and templates based on facts" 4993msgstr "ファクトに基づくファイルとテンプレートの選択" 4994 4995#: ../../rst/user_guide/playbooks_conditionals.rst:409 4996msgid "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." 4997msgstr "OS のフレーバーやバージョンによって、設定ファイルやテンプレートが異なる場合も同様の方法で対応できます。各ホストに割り当てられた変数に基づいて、適切なファイルやテンプレートを選択します。この方法は、複数の OS やパッケージのバージョンに対応するために 1 つのテンプレートに多くの条件分岐を入れるよりも、はるかにすっきりすることが多いです。" 4998 4999#: ../../rst/user_guide/playbooks_conditionals.rst:411 5000msgid "For example, you can template out a configuration file that is very different between, say, CentOS and Debian::" 5001msgstr "例えば、CentOS と Debian の間で大きく異なる設定ファイルをテンプレート化することができます。" 5002 5003#: ../../rst/user_guide/playbooks_conditionals.rst:427 5004msgid "Commonly-used facts" 5005msgstr "一般的に使用されるファクト" 5006 5007#: ../../rst/user_guide/playbooks_conditionals.rst:429 5008msgid "The following Ansible facts are frequently used in conditionals." 5009msgstr "以下の Ansible ファクトは、条件分岐で頻繁に使用されます。" 5010 5011#: ../../rst/user_guide/playbooks_conditionals.rst:434 5012msgid "ansible_facts['distribution']" 5013msgstr "ansible_facts['distribution']" 5014 5015#: ../../rst/user_guide/playbooks_conditionals.rst:436 5016#: ../../rst/user_guide/playbooks_conditionals.rst:474 5017msgid "Possible values (sample, not complete list)::" 5018msgstr "使用できる値 (完全リストではなく一部です):" 5019 5020#: ../../rst/user_guide/playbooks_conditionals.rst:465 5021msgid "ansible_facts['distribution_major_version']" 5022msgstr "ansible_facts['distribution_major_version']" 5023 5024#: ../../rst/user_guide/playbooks_conditionals.rst:467 5025msgid "The major version of the operating system. For example, the value is `16` for Ubuntu 16.04." 5026msgstr "オペレーティングシステムのメジャーバージョンです。たとえば、Ubuntu 16.04 の場合は `16` となります。" 5027 5028#: ../../rst/user_guide/playbooks_conditionals.rst:472 5029msgid "ansible_facts['os_family']" 5030msgstr "ansible_facts['os_family']" 5031 5032#: ../../rst/user_guide/playbooks_conditionals.rst:501 5033#: ../../rst/user_guide/playbooks_error_handling.rst:236 5034#: ../../rst/user_guide/playbooks_filters.rst:1803 5035#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:738 5036#: ../../rst/user_guide/playbooks_intro.rst:144 5037#: ../../rst/user_guide/playbooks_loops.rst:436 5038#: ../../rst/user_guide/playbooks_reuse.rst:199 5039#: ../../rst/user_guide/playbooks_reuse_includes.rst:17 5040#: ../../rst/user_guide/playbooks_reuse_roles.rst:603 5041#: ../../rst/user_guide/playbooks_templating.rst:50 5042#: ../../rst/user_guide/playbooks_tests.rst:398 5043#: ../../rst/user_guide/playbooks_variables.rst:459 5044#: ../../rst/user_guide/windows_dsc.rst:498 5045#: ../../rst/user_guide/windows_faq.rst:246 5046#: ../../rst/user_guide/windows_setup.rst:569 5047#: ../../rst/user_guide/windows_usage.rst:506 5048#: ../../rst/user_guide/windows_winrm.rst:907 5049msgid ":ref:`playbooks_best_practices`" 5050msgstr ":ref:`playbooks_best_practices`" 5051 5052#: ../../rst/user_guide/playbooks_conditionals.rst:502 5053#: ../../rst/user_guide/playbooks_error_handling.rst:237 5054#: ../../rst/user_guide/playbooks_filters.rst:1804 5055#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:739 5056#: ../../rst/user_guide/playbooks_loops.rst:437 5057#: ../../rst/user_guide/playbooks_reuse.rst:200 5058#: ../../rst/user_guide/playbooks_reuse_includes.rst:18 5059#: ../../rst/user_guide/playbooks_reuse_roles.rst:604 5060#: ../../rst/user_guide/playbooks_templating.rst:51 5061#: ../../rst/user_guide/playbooks_tests.rst:399 5062#: ../../rst/user_guide/playbooks_variables.rst:460 5063#: ../../rst/user_guide/windows_dsc.rst:499 5064#: ../../rst/user_guide/windows_faq.rst:247 5065#: ../../rst/user_guide/windows_setup.rst:570 5066#: ../../rst/user_guide/windows_usage.rst:507 5067#: ../../rst/user_guide/windows_winrm.rst:908 5068msgid "Tips and tricks for playbooks" 5069msgstr "Playbook のヒントと裏技" 5070 5071#: ../../rst/user_guide/playbooks_debugger.rst:5 5072msgid "Debugging tasks" 5073msgstr "タスクのデバッグ" 5074 5075#: ../../rst/user_guide/playbooks_debugger.rst:7 5076msgid "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." 5077msgstr "Ansible にはタスクデバッガーがあり、変更が成功したかどうかを確認するために Playbook を編集して再度実行するのではなく、実行中にエラーを修正することができます。タスクのコンテキスト内で、デバッガーのすべての機能にアクセスできます。変数の値をチェックしたり設定したり、モジュールの引数を更新したり、新しい変数や引数を使用してタスクを再実行したりできます。デバッガーは、失敗の原因を解決し、Playbook の実行を続行することができます。" 5078 5079#: ../../rst/user_guide/playbooks_debugger.rst:13 5080msgid "Enabling the debugger" 5081msgstr "デバッガーの有効化" 5082 5083#: ../../rst/user_guide/playbooks_debugger.rst:15 5084msgid "The debugger is not enabled by default. If you want to invoke the debugger during playbook execution, you must enable it first." 5085msgstr "デバッガーはデフォルトでは有効になっていません。Playbook の実行中にデバッガーを呼び出す場合は、最初に有効にする必要があります。" 5086 5087#: ../../rst/user_guide/playbooks_debugger.rst:17 5088msgid "Use one of these three methods to enable the debugger:" 5089msgstr "以下の 3 つの方法のいずれかを使用してデバッガーを有効にします。" 5090 5091#: ../../rst/user_guide/playbooks_debugger.rst:19 5092msgid "with the debugger keyword" 5093msgstr "デバッガーキーワードの使用" 5094 5095#: ../../rst/user_guide/playbooks_debugger.rst:20 5096msgid "in configuration or an environment variable, or" 5097msgstr "設定または環境変数で" 5098 5099#: ../../rst/user_guide/playbooks_debugger.rst:21 5100msgid "as a strategy" 5101msgstr "ストラテジーとして" 5102 5103#: ../../rst/user_guide/playbooks_debugger.rst:24 5104msgid "Enabling the debugger with the ``debugger`` keyword" 5105msgstr "``debugger`` キーワードでデバッガーを有効にする" 5106 5107#: ../../rst/user_guide/playbooks_debugger.rst:28 5108msgid "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:" 5109msgstr "``debugger`` キーワードを使用すると、特定のプレイ、ロール、ブロック、またはタスクに対してデバッガーを有効 (または無効) にすることができます。このオプションは、Playbook、プレイ、およびロールを開発または拡張する際に特に役立ちます。新規または更新されたタスクでデバッガーを有効にすることができます。失敗しても、効率的にエラーを修正することができます。``debugger`` キーワードは 5 つの値を受け入れます。" 5110 5111#: ../../rst/user_guide/playbooks_debugger.rst:34 5112msgid "Value" 5113msgstr "値" 5114 5115#: ../../rst/user_guide/playbooks_debugger.rst:34 5116msgid "Result" 5117msgstr "結果" 5118 5119#: ../../rst/user_guide/playbooks_debugger.rst:36 5120msgid "always" 5121msgstr "always" 5122 5123#: ../../rst/user_guide/playbooks_debugger.rst:36 5124msgid "Always invoke the debugger, regardless of the outcome" 5125msgstr "結果に関係なく、常にデバッガーを呼び出します。" 5126 5127#: ../../rst/user_guide/playbooks_debugger.rst:38 5128msgid "never" 5129msgstr "never" 5130 5131#: ../../rst/user_guide/playbooks_debugger.rst:38 5132msgid "Never invoke the debugger, regardless of the outcome" 5133msgstr "結果に関係なく、デバッガーを呼び出しません。" 5134 5135#: ../../rst/user_guide/playbooks_debugger.rst:40 5136msgid "on_failed" 5137msgstr "on_failed" 5138 5139#: ../../rst/user_guide/playbooks_debugger.rst:40 5140msgid "Only invoke the debugger if a task fails" 5141msgstr "タスクが失敗した場合に限りデバッガーを呼び出します。" 5142 5143#: ../../rst/user_guide/playbooks_debugger.rst:42 5144msgid "on_unreachable" 5145msgstr "on_unreachable" 5146 5147#: ../../rst/user_guide/playbooks_debugger.rst:42 5148msgid "Only invoke the debugger if a host is unreachable" 5149msgstr "ホストが到達できない場合に限りデバッガーを呼び出します。" 5150 5151#: ../../rst/user_guide/playbooks_debugger.rst:44 5152msgid "on_skipped" 5153msgstr "on_skipped" 5154 5155#: ../../rst/user_guide/playbooks_debugger.rst:44 5156msgid "Only invoke the debugger if the task is skipped" 5157msgstr "タスクがスキップされた場合に限りデバッガーを呼び出します。" 5158 5159#: ../../rst/user_guide/playbooks_debugger.rst:48 5160msgid "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." 5161msgstr "``debugger`` キーワードを使用すると、指定した値が、デバッガ―を有効または無効にするグローバル構成よりも優先されます。``debugger`` をロールやタスクなどの複数のレベルで定義した場合、Ansible は最も詳細な定義を尊重します。プレイまたはロールのレベルでの定義は、異なる値を指定しない限り、そのプレイまたはロール内のすべてのブロックおよびタスクに適用されます。ブロックレベルの定義は、プレイまたはロールレベルの定義よりも優先され、異なる値が指定されていない限り、そのブロック内のすべてのタスクに適用されます。タスクレベルでの定義は、常にタスクに適用され、ブロック、プレイ、またはロールレベルでの定義よりも優先されます。" 5162 5163#: ../../rst/user_guide/playbooks_debugger.rst:51 5164msgid "Examples of using the ``debugger`` keyword" 5165msgstr "``debugger`` キーワードの使用例" 5166 5167#: ../../rst/user_guide/playbooks_debugger.rst:53 5168msgid "Example of setting the ``debugger`` keyword on a task:" 5169msgstr "タスクに ``debugger`` キーワードを設定する例:" 5170 5171#: ../../rst/user_guide/playbooks_debugger.rst:61 5172msgid "Example of setting the ``debugger`` keyword on a play:" 5173msgstr "プレイに ``debugger`` キーワードを設定する例:" 5174 5175#: ../../rst/user_guide/playbooks_debugger.rst:73 5176msgid "Example of setting the ``debugger`` keyword at multiple levels:" 5177msgstr "複数のレベルで ``debugger`` キーワードを設定する例:" 5178 5179#: ../../rst/user_guide/playbooks_debugger.rst:86 5180msgid "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." 5181msgstr "この例では、デバッガーは、プレイレベルでは ``never`` に、タスクレベルでは ``on_failed`` に設定されています。タスクが失敗した場合、タスクの定義が親プレイの定義を上書きするため、Ansible はデバッガーを起動します。" 5182 5183#: ../../rst/user_guide/playbooks_debugger.rst:89 5184msgid "Enabling the debugger in configuration or an environment variable" 5185msgstr "設定または環境変数でのデバッガーの有効化" 5186 5187#: ../../rst/user_guide/playbooks_debugger.rst:93 5188msgid "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." 5189msgstr "タスクデバッガーをグローバルに有効にするには、ansible.cfg 内の設定または環境変数を使用します。オプションは ``True`` または ``False`` のみです。設定オプションまたは環境変数を ``True`` に設定した場合、Ansible はデフォルトで失敗したタスクに対してデバッガーを実行します。" 5190 5191#: ../../rst/user_guide/playbooks_debugger.rst:95 5192msgid "To enable the task debugger from ansible.cfg, add this setting to the defaults section::" 5193msgstr "ansible.cfg からタスクデバッガーを有効にするには、以下の設定を defaults セクションに追加します。" 5194 5195#: ../../rst/user_guide/playbooks_debugger.rst:100 5196msgid "To enable the task debugger with an environment variable, pass the variable when you run your playbook::" 5197msgstr "環境変数でタスクデバッガーを有効にするには、Playbook の実行時に変数を渡します。" 5198 5199#: ../../rst/user_guide/playbooks_debugger.rst:104 5200msgid "When you enable the debugger globally, every failed task invokes the debugger, unless the role, play, block, or task explicity disables the debugger. If you need more granular control over what conditions trigger the debugger, use the ``debugger`` keyword." 5201msgstr "グローバルにデバッガを有効にすると、ロール、プレイ、ブロック、またはタスクが明示的にデバッガ―を無効にしていない限り、失敗したタスクはすべてデバッガ―を起動します。どのような条件でデバッガーが起動するかをより詳細に制御する必要がある場合は、``debugger`` キーワードを使用します。" 5202 5203#: ../../rst/user_guide/playbooks_debugger.rst:107 5204msgid "Enabling the debugger as a strategy" 5205msgstr "ストラテジーとしてのデバッガーの有効化" 5206 5207#: ../../rst/user_guide/playbooks_debugger.rst:109 5208msgid "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:" 5209msgstr "レガシーの Playbook やロールを実行している場合は、:ref:`strategy <strategy_plugins>` としてデバッガーが有効になっていることがあります。この設定は、プレイレベル、ansible.cfg、または環境変数 ``ANSIBLE_STRATEGY=debug`` で行うことができます。以下に例を示します。" 5210 5211#: ../../rst/user_guide/playbooks_debugger.rst:118 5212msgid "Or in ansible.cfg::" 5213msgstr "または ansible.cfg で以下を行います。" 5214 5215#: ../../rst/user_guide/playbooks_debugger.rst:125 5216msgid "This backwards-compatible method, which matches Ansible versions before 2.5, may be removed in a future release." 5217msgstr "この後方互換性のある方法は、Ansible の 2.5 以前のバージョンに対応していますが、将来のリリースでは削除される可能性があります。" 5218 5219#: ../../rst/user_guide/playbooks_debugger.rst:128 5220msgid "Resolving errors in the debugger" 5221msgstr "デバッガーでエラーの解決" 5222 5223#: ../../rst/user_guide/playbooks_debugger.rst:130 5224msgid "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." 5225msgstr "Ansible がデバッガーを起動した後、7 つの :ref:`debugger コマンド <available_commands>` を使用して、Ansibleが遭遇したエラーを解決することができます。この Playbook の例では ``var1`` 変数を定義していますが、未定義の``wrong_var`` 変数を誤ってタスクで使用します。" 5226 5227#: ../../rst/user_guide/playbooks_debugger.rst:143 5228msgid "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." 5229msgstr "この Playbook を実行すると、Ansible はタスクの失敗時にデバッガーを呼び出します。デバッグプロンプトから、モジュール引数または変数を変更して、タスクを再度実行できます。" 5230 5231#: ../../rst/user_guide/playbooks_debugger.rst:178 5232msgid "Changing the task arguments in the debugger to use ``var1`` instead of ``wrong_var`` makes the task run successfully." 5233msgstr "デバッガでタスクの引数 ``wrong_var`` の代わりに``var1`` を使うように変更すると、タスクが正常に実行されます。" 5234 5235#: ../../rst/user_guide/playbooks_debugger.rst:183 5236msgid "Available debug commands" 5237msgstr "利用可能なデバッグコマンド" 5238 5239#: ../../rst/user_guide/playbooks_debugger.rst:185 5240msgid "You can use these seven commands at the debug prompt:" 5241msgstr "これらの 7 つのコマンドは、デバッグプロンプトで使用できます。" 5242 5243#: ../../rst/user_guide/playbooks_debugger.rst:191 5244msgid "Command" 5245msgstr "コマンド" 5246 5247#: ../../rst/user_guide/playbooks_debugger.rst:191 5248msgid "Shortcut" 5249msgstr "ショートカット" 5250 5251#: ../../rst/user_guide/playbooks_debugger.rst:191 5252msgid "Action" 5253msgstr "アクション" 5254 5255#: ../../rst/user_guide/playbooks_debugger.rst:193 5256msgid "print" 5257msgstr "印刷" 5258 5259#: ../../rst/user_guide/playbooks_debugger.rst:193 5260msgid "p" 5261msgstr "p" 5262 5263#: ../../rst/user_guide/playbooks_debugger.rst:193 5264msgid "Print information about the task" 5265msgstr "タスクに関する情報を出力する" 5266 5267#: ../../rst/user_guide/playbooks_debugger.rst:195 5268msgid "task.args[*key*] = *value*" 5269msgstr "task.args[*key*] = *value*" 5270 5271#: ../../rst/user_guide/playbooks_debugger.rst:195 5272#: ../../rst/user_guide/playbooks_debugger.rst:197 5273msgid "no shortcut" 5274msgstr "ショートカットなし" 5275 5276#: ../../rst/user_guide/playbooks_debugger.rst:195 5277msgid "Update module arguments" 5278msgstr "モジュール引数を更新する" 5279 5280#: ../../rst/user_guide/playbooks_debugger.rst:197 5281msgid "task_vars[*key*] = *value*" 5282msgstr "task_vars[*key*] = *value*" 5283 5284#: ../../rst/user_guide/playbooks_debugger.rst:197 5285msgid "Update task variables (you must ``update_task`` next)" 5286msgstr "タスク変数を更新する (次回 ``update_task`` する必要があります)" 5287 5288#: ../../rst/user_guide/playbooks_debugger.rst:199 5289msgid "update_task" 5290msgstr "update_task" 5291 5292#: ../../rst/user_guide/playbooks_debugger.rst:199 5293msgid "u" 5294msgstr "u" 5295 5296#: ../../rst/user_guide/playbooks_debugger.rst:199 5297msgid "Recreate a task with updated task variables" 5298msgstr "更新されたタスク変数でタスクを再作成する" 5299 5300#: ../../rst/user_guide/playbooks_debugger.rst:201 5301msgid "redo" 5302msgstr "redo" 5303 5304#: ../../rst/user_guide/playbooks_debugger.rst:201 5305msgid "r" 5306msgstr "r" 5307 5308#: ../../rst/user_guide/playbooks_debugger.rst:201 5309msgid "Run the task again" 5310msgstr "タスクを再度実行する" 5311 5312#: ../../rst/user_guide/playbooks_debugger.rst:203 5313msgid "continue" 5314msgstr "続行" 5315 5316#: ../../rst/user_guide/playbooks_debugger.rst:203 5317msgid "c" 5318msgstr "c" 5319 5320#: ../../rst/user_guide/playbooks_debugger.rst:203 5321msgid "Continue executing, starting with the next task" 5322msgstr "実行を継続する (次のタスクから開始)" 5323 5324#: ../../rst/user_guide/playbooks_debugger.rst:205 5325msgid "quit" 5326msgstr "終了" 5327 5328#: ../../rst/user_guide/playbooks_debugger.rst:205 5329msgid "q" 5330msgstr "q" 5331 5332#: ../../rst/user_guide/playbooks_debugger.rst:205 5333msgid "Quit the debugger" 5334msgstr "デバッガーを終了する" 5335 5336#: ../../rst/user_guide/playbooks_debugger.rst:209 5337msgid "For more details, see the individual descriptions and examples below." 5338msgstr "詳細は、以下の個別の説明および例を参照してください。" 5339 5340#: ../../rst/user_guide/playbooks_debugger.rst:214 5341msgid "Print command" 5342msgstr "コマンドを出力する" 5343 5344#: ../../rst/user_guide/playbooks_debugger.rst:216 5345msgid "``print *task/task.args/task_vars/host/result*`` prints information about the task::" 5346msgstr "``print *task/task.args/task_vars/host/result*`` は、タスクに関する情報を出力します。" 5347 5348#: ../../rst/user_guide/playbooks_debugger.rst:241 5349msgid "Update args command" 5350msgstr "args コマンドを更新する" 5351 5352#: ../../rst/user_guide/playbooks_debugger.rst:243 5353msgid "``task.args[*key*] = *value*`` updates a module argument. This sample playbook has an invalid package name::" 5354msgstr "``task.args[*key*] = *value*`` モジュール引数を更新します。このサンプル Playbook には無効なパッケージ名があります。" 5355 5356#: ../../rst/user_guide/playbooks_debugger.rst:254 5357msgid "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::" 5358msgstr "Playbook を実行すると、パッケージ名が無効であるためにエラーが発生し、Ansible がデバッガーを起動します。パッケージ名を修正するには、モジュールの引数を表示してから更新します。" 5359 5360#: ../../rst/user_guide/playbooks_debugger.rst:263 5361msgid "After you update the module argument, use ``redo`` to run the task again with the new args." 5362msgstr "モジュール引数を更新したら、``redo`` を使用して、新しい引数でタスクを再度実行します。" 5363 5364#: ../../rst/user_guide/playbooks_debugger.rst:268 5365msgid "Update vars command" 5366msgstr "vars コマンドの更新" 5367 5368#: ../../rst/user_guide/playbooks_debugger.rst:270 5369msgid "``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::" 5370msgstr "``task_vars[*key*] = *value*`` は、``task_vars`` を更新します。モジュール引数ではなくタスク変数を表示してから更新して、上記の Playbook を修正できます。" 5371 5372#: ../../rst/user_guide/playbooks_debugger.rst:280 5373msgid "After you update the task variables, you must use ``update_task`` to load the new variables before using ``redo`` to run the task again." 5374msgstr "タスク変数を更新したら、``redo`` を使用してタスクを再実行する前に、``update_task`` を使用して新しい変数を読み込む必要があります。" 5375 5376#: ../../rst/user_guide/playbooks_debugger.rst:283 5377msgid "In 2.5 this was updated from ``vars`` to ``task_vars`` to avoid conflicts with the ``vars()`` python function." 5378msgstr "これは、python 関数 ``vars()`` と競合しないように、2.5 で ``vars`` から ``task_vars`` に更新されました。" 5379 5380#: ../../rst/user_guide/playbooks_debugger.rst:288 5381msgid "Update task command" 5382msgstr "task コマンドの更新" 5383 5384#: ../../rst/user_guide/playbooks_debugger.rst:292 5385msgid "``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." 5386msgstr "``u`` または ``update_task`` は、更新されたタスク変数を持つ元のタスクデータ構造とテンプレートからタスクを再作成します。使用例は、エントリー:ref:`update_vars_command` を参照してください。" 5387 5388#: ../../rst/user_guide/playbooks_debugger.rst:297 5389msgid "Redo command" 5390msgstr "コマンドのやり直し" 5391 5392#: ../../rst/user_guide/playbooks_debugger.rst:299 5393msgid "``r`` or ``redo`` runs the task again." 5394msgstr "``r`` または ``redo`` はタスクを再実行します。" 5395 5396#: ../../rst/user_guide/playbooks_debugger.rst:304 5397msgid "Continue command" 5398msgstr "コマンドの続行" 5399 5400#: ../../rst/user_guide/playbooks_debugger.rst:306 5401msgid "``c`` or ``continue`` continues executing, starting with the next task." 5402msgstr "``c`` または ``continue`` は、次のタスクから開始して実行を継続します。" 5403 5404#: ../../rst/user_guide/playbooks_debugger.rst:311 5405msgid "Quit command" 5406msgstr "Quit コマンド" 5407 5408#: ../../rst/user_guide/playbooks_debugger.rst:313 5409msgid "``q`` or ``quit`` quits the debugger. The playbook execution is aborted." 5410msgstr "``q`` または ``quit`` はデバッガーを終了します。Playbook の実行は中止します。" 5411 5412#: ../../rst/user_guide/playbooks_debugger.rst:316 5413msgid "How the debugger interacts with the free strategy" 5414msgstr "デバッガーがフリーストラテジーとどのように相互作用するか" 5415 5416#: ../../rst/user_guide/playbooks_debugger.rst:318 5417msgid "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`." 5418msgstr "デフォルトの ``linear`` 戦略を有効にすると、Ansible はデバッガ―がアクティブな間は実行を停止し、``redo`` コマンドを入力した直後にデバッグされたタスクを実行します。しかし、``free`` ストラテジーを有効にすると、Ansible はすべてのホストを待たずに、別のホストでタスクが失敗する前に、あるホストで後のタスクをキューに入れることがあります。``free`` 戦略を使用すると、デバッガーがアクティブな間、Ansible は、タスクの照会や実行を行いません。ただし、キューに入れられたタスクはすべてキューに残り、デバッガーを終了するとすぐに実行されます。``redo`` を使用してデバッガーからタスクを再スケジュールすると、再スケジュールされたタスクの前にキューに入れられた他のタスクが実行する場合があります。ストラテジーの詳細については「:ref:`playbooks_strategies`」を参照してください。" 5419 5420#: ../../rst/user_guide/playbooks_debugger.rst:322 5421msgid ":ref:`playbooks_start_and_step`" 5422msgstr ":ref:`playbooks_start_and_step`" 5423 5424#: ../../rst/user_guide/playbooks_debugger.rst:323 5425msgid "Running playbooks while debugging or testing" 5426msgstr "デバッグ時またはテスト時の Playbook の実行" 5427 5428#: ../../rst/user_guide/playbooks_delegation.rst:4 5429msgid "Controlling where tasks run: delegation and local actions" 5430msgstr "タスクの実行場所の制御: 委譲およびローカルアクション" 5431 5432#: ../../rst/user_guide/playbooks_delegation.rst:6 5433msgid "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." 5434msgstr "デフォルトでは、Ansible はファクトを収集し、Playbook の ``hosts`` 行に一致するマシン上ですべてのタスクを実行します。このページでは、タスクを別のマシンやグループに委譲したり、ファクトを特定のマシンやグループに委譲したり、Playbook 全体をローカルで実行する方法を紹介します。これらの方法を用いることで、相互に関連する環境を正確かつ効率的に管理することができます。たとえば、Web サーバーを更新する際に、負荷分散したプールから一時的に Web サーバーを削除しないといけない場合があります。このタスクは、Web サーバー自身では実行できません。このタスクを localhost に委譲することで、すべてのタスクを同じプレイに収めることができます。" 5435 5436#: ../../rst/user_guide/playbooks_delegation.rst:12 5437msgid "Tasks that cannot be delegated" 5438msgstr "委譲できないタスク" 5439 5440#: ../../rst/user_guide/playbooks_delegation.rst:14 5441msgid "Some tasks always execute on the controller. These tasks, including ``include``, ``add_host``, and ``debug``, cannot be delegated." 5442msgstr "一部のタスクは常にコントローラーで実行します。これらのタスクには、``include``、``add_host``、および ``debug`` を含むタスクを委譲できません。" 5443 5444#: ../../rst/user_guide/playbooks_delegation.rst:19 5445msgid "Delegating tasks" 5446msgstr "タスクの委譲" 5447 5448#: ../../rst/user_guide/playbooks_delegation.rst:21 5449msgid "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::" 5450msgstr "あるホストで他のホストを参照しながらタスクを実行したい場合は、タスクに ``delegate_to`` キーワードを使用します。これは、負荷分散されたプールのノードを管理したり、障害発生時のウィンドウを制御するのに最適です。:ref:`serial <rolling_update_batch_size>` キーワードで委譲を使用すると、一度に実行するホストの数を制御することができます。" 5451 5452#: ../../rst/user_guide/playbooks_delegation.rst:41 5453msgid "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::" 5454msgstr "ここでは、1 番目と 3 番目のタスクを 127.0.0.1 で実行していますが、これは Ansible を実行しているマシンです。また、タスクごとに使用できる簡略化された構文があります (``local_action``)。以下は、上記と同じ Playbook ですが、127.0.0.1 に委譲するための短縮構文を使用します。" 5455 5456#: ../../rst/user_guide/playbooks_delegation.rst:55 5457msgid "You can use a local action to call 'rsync' to recursively copy files to the managed servers::" 5458msgstr "ローカルアクションを使用して「rsync」を呼び出し、管理対象のサーバーにファイルを再帰的にコピーすることができます。" 5459 5460#: ../../rst/user_guide/playbooks_delegation.rst:64 5461msgid "Note that you must have passphrase-less SSH keys or an ssh-agent configured for this to work, otherwise rsync asks for a passphrase." 5462msgstr "これが機能するためには、パスフレーズなしの SSH 鍵または ssh-agent が設定されていなければならないことに注意してください。そうでなければ、rsync はパスフレーズを要求します。" 5463 5464#: ../../rst/user_guide/playbooks_delegation.rst:66 5465msgid "To specify more arguments, use the following syntax::" 5466msgstr "引数をさらに指定する必要がある場合は、以下の構文を使用できます。" 5467 5468#: ../../rst/user_guide/playbooks_delegation.rst:80 5469msgid "The `ansible_host` variable reflects the host a task is delegated to." 5470msgstr "`ansible_host` 変数は、タスクが委譲されるホストを反映します。" 5471 5472#: ../../rst/user_guide/playbooks_delegation.rst:85 5473msgid "Delegating facts" 5474msgstr "ファクトの委譲" 5475 5476#: ../../rst/user_guide/playbooks_delegation.rst:87 5477msgid "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``::" 5478msgstr "Ansible のタスクを委譲することは、現実世界でタスクを委譲することと同じです。たとえ他の誰かがあなたの家に食料品を届けたとしても、あなたの食料品はあなたのものです。同様に、委譲されたタスクによって収集されたファクトは、デフォルトでは、ファクトを生成したホスト (委譲されたホスト) ではなく、`inventory_hostname` (現在のホスト) に割り当てられます。集めたファクトを現在のホストではなく委譲されたホストに割り当てるには、``delegate_facts`` を ``true`` に設定します。" 5479 5480#: ../../rst/user_guide/playbooks_delegation.rst:99 5481msgid "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`." 5482msgstr "このタスクは、プレイが app_servers グループを対象としているにもかかわらず、dbservers グループのマシンのファクトを収集し、それらのマシンにファクトを割り当てます。このようにして、たとえ dbservers がプレイの一部でなくても、あるいは `--limit` を使用して除外されていても、`hostvars['dbhost1']['ansible_default_ipv4']['address']` を調べることができます。" 5483 5484#: ../../rst/user_guide/playbooks_delegation.rst:104 5485msgid "Local playbooks" 5486msgstr "ローカルの Playbook" 5487 5488#: ../../rst/user_guide/playbooks_delegation.rst:106 5489msgid "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." 5490msgstr "SSH で接続するのではなく、リモートホスト上でローカルに Playbook を使用することが便利な場合があります。これは、crontab に Playbook を置くことで、システムの構成を保証するのに役立ちます。また、Anaconda のキックスタートなど、OS インストーラー内で Playbook を実行する場合にも使用できます。" 5491 5492#: ../../rst/user_guide/playbooks_delegation.rst:109 5493msgid "To run an entire playbook locally, just set the ``hosts:`` line to ``hosts: 127.0.0.1`` and then run the playbook like so::" 5494msgstr "Playbook 全体をローカルで実行するには、``hosts:`` 行を ``hosts: 127.0.0.1`` に設定し、次のように Playbook を実行します。" 5495 5496#: ../../rst/user_guide/playbooks_delegation.rst:113 5497msgid "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::" 5498msgstr "また、Playbook 内の他のプレイがデフォルトのリモート接続タイプを使用していても、1 つの Playbook のプレイでローカル接続を使用することもできます。" 5499 5500#: ../../rst/user_guide/playbooks_delegation.rst:121 5501msgid "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." 5502msgstr "接続先をローカルに設定し、ansible_python_interpreter が設定されていない場合、モジュールは /usr/bin/python で実行し、{{ ansible_playbook_python }} では実行されません。ansible_python_interpreter を必ず設定してください (host_vars/localhost.yml の「{{ ansible_playbook_python }}」など)。代わりに ``local_action`` または ``delegate_to: localhost`` を使用することで、この問題を回避できます。" 5503 5504#: ../../rst/user_guide/playbooks_delegation.rst:130 5505msgid "More ways to control how and where Ansible executes" 5506msgstr "Ansible の実行方法および場所を制御する方法" 5507 5508#: ../../rst/user_guide/playbooks_delegation.rst:131 5509msgid "`Ansible Examples on GitHub <https://github.com/ansible/ansible-examples>`_" 5510msgstr "`Ansible Examples on GitHub <https://github.com/ansible/ansible-examples>`_" 5511 5512#: ../../rst/user_guide/playbooks_delegation.rst:132 5513msgid "Many examples of full-stack deployments" 5514msgstr "フルスタックデプロイメントの例が多数あります。" 5515 5516#: ../../rst/user_guide/playbooks_environment.rst:4 5517msgid "Setting the remote environment" 5518msgstr "リモート環境の設定" 5519 5520#: ../../rst/user_guide/playbooks_environment.rst:8 5521msgid "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." 5522msgstr "プレイ、ブロック、またはタスクのレベルで ``environment`` キーワードを使用して、リモートホスト上のアクションに環境変数を設定することができます。このキーワードを使用すると、http リクエストを行うタスクでプロキシーの使用を有効にしたり、言語固有のバージョンマネージャーに必要な環境変数を設定したりすることができます。" 5523 5524#: ../../rst/user_guide/playbooks_environment.rst:10 5525msgid "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." 5526msgstr "プレイまたはブロックレベルで ``environment:`` を使用して値を設定すると、同じユーザーによって実行されるプレイまたはブロック内のタスクでのみ使用できます。``environment:`` キーワードは、Ansible 自体、Ansible の構成設定、他のユーザーの環境、ルックアップやフィルターなどの他のプラグインの実行には影響しません。``environment:`` で設定した変数は、プレイレベルで設定しても、自動的に Ansible のファクトにはなりません。これらの値を Ansible のファクトにするには、Playbook に明示的な ``gather_facts`` タスクを含め、そのタスクに ``environment`` キーワードを設定する必要があります。" 5527 5528#: ../../rst/user_guide/playbooks_environment.rst:16 5529msgid "Setting the remote environment in a task" 5530msgstr "タスクへのリモート環境の設定" 5531 5532#: ../../rst/user_guide/playbooks_environment.rst:18 5533msgid "You can set the environment directly at the task level::" 5534msgstr "タスクレベルで環境を直接指定することもできます。" 5535 5536#: ../../rst/user_guide/playbooks_environment.rst:32 5537msgid "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::" 5538msgstr "環境変数をプレイの変数として定義し、保存した Ansible 変数にアクセスするときにタスクからアクセスできることで、環境変数を再利用できます。" 5539 5540#: ../../rst/user_guide/playbooks_environment.rst:50 5541msgid "You can store environment settings for re-use in multiple playbooks by defining them in a group_vars file::" 5542msgstr "複数の Playbook に再使用する環境設定は、group_vars ファイルに定義することで保存できます。" 5543 5544#: ../../rst/user_guide/playbooks_environment.rst:61 5545msgid "You can set the remote environment at the play level::" 5546msgstr "プレイレベルでリモート環境を設定できます。" 5547 5548#: ../../rst/user_guide/playbooks_environment.rst:72 5549msgid "These examples show proxy settings, but you can provide any number of settings this way." 5550msgstr "これらの例ではプロキシー設定を示していますが、この設定をいくつでも提供できます。" 5551 5552#: ../../rst/user_guide/playbooks_environment.rst:75 5553msgid "Working with language-specific version managers" 5554msgstr "言語固有のバージョンマネージャーの使用" 5555 5556#: ../../rst/user_guide/playbooks_environment.rst:77 5557msgid "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::" 5558msgstr "言語固有のバージョンマネージャー (rbenv や nvmなど) の中には、これらのツールを使用する際に環境変数を設定する必要があります。これらのツールを手動で使用する場合、通常はスクリプトやシェル構成ファイルに追加した行から環境変数を設定します。Ansible では、プレイレベルで環境キーワードを使用してこれを行うことができます。" 5559 5560#: ../../rst/user_guide/playbooks_environment.rst:114 5561msgid "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." 5562msgstr "上の例では、``ansible_env`` を PATH の一部として使用しています。変数を ``ansible_env`` に基づかせるのはリスクがあります。Ansible はファクトを収集して ``ansible_env`` の値を生成するため、変数の値はファクトの収集時に Ansible が使用した remote_user や become_user に依存します。remote_user/become_user を変更した場合、``ansible-env`` の値は期待したものとは異なる可能性があります。" 5563 5564#: ../../rst/user_guide/playbooks_environment.rst:117 5565msgid "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." 5566msgstr "環境変数は、通常、(シェルプラグインに依存する) クリアテキストに渡されます。したがって、実行するモジュールにシークレットを渡す方法は推奨されません。" 5567 5568#: ../../rst/user_guide/playbooks_environment.rst:119 5569msgid "You can also specify the environment at the task level::" 5570msgstr "タスクレベルで環境を指定することもできます。" 5571 5572#: ../../rst/user_guide/playbooks_error_handling.rst:5 5573msgid "Error handling in playbooks" 5574msgstr "Playbook でのエラー処理" 5575 5576#: ../../rst/user_guide/playbooks_error_handling.rst:7 5577msgid "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." 5578msgstr "Ansible は、コマンドからゼロ以外の戻りコードを受け取った場合や、モジュールから失敗を受け取った場合、デフォルトでは、そのホストでの実行を停止し、他のホストで継続します。しかし、状況によっては異なる動作をさせたい場合があります。ゼロ以外の戻りコードが成功を示す場合もあります。あるホストで失敗したら、すべてのホストで実行を停止させたい場合もあります。Ansible には、このような状況に対応するためのツールや設定が用意されており、必要な動作、出力、レポートを得ることができます。" 5579 5580#: ../../rst/user_guide/playbooks_error_handling.rst:15 5581msgid "Ignoring failed commands" 5582msgstr "失敗したコマンドの無視" 5583 5584#: ../../rst/user_guide/playbooks_error_handling.rst:17 5585msgid "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::" 5586msgstr "デフォルトでは、Ansible は、ホストでタスクが失敗すると、ホストでタスクの実行を停止します。``ignore_errors`` を使用すると、障害が発生しても続行されます。" 5587 5588#: ../../rst/user_guide/playbooks_error_handling.rst:23 5589msgid "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." 5590msgstr "``ignore_errors`` ディレクティブは、タスクが実行可能で、「failed」という値を返す場合にのみ機能します。未定義の変数のエラー、接続の失敗、実行時の問題 (パッケージの欠落など)、構文エラーなどを Ansible に無視させるものではありません。" 5591 5592#: ../../rst/user_guide/playbooks_error_handling.rst:26 5593msgid "Ignoring unreachable host errors" 5594msgstr "到達不能なホストエラーを無視" 5595 5596#: ../../rst/user_guide/playbooks_error_handling.rst:30 5597msgid "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::" 5598msgstr "``ignore_unreachable`` キーワードで、ホストインスタンスが「UNREACHABLE」であることによるタスクの失敗を無視することができます。Ansible はタスクのエラーを無視しますが、到達不可能なホストに対して今後のタスクを実行し続けます。たとえば、タスクレベルでは以下のようになります。" 5599 5600#: ../../rst/user_guide/playbooks_error_handling.rst:39 5601msgid "And at the playbook level::" 5602msgstr "また、Playbook レベルでは以下を行います。" 5603 5604#: ../../rst/user_guide/playbooks_error_handling.rst:54 5605msgid "Resetting unreachable hosts" 5606msgstr "到達できないホストのリセット" 5607 5608#: ../../rst/user_guide/playbooks_error_handling.rst:56 5609msgid "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." 5610msgstr "Ansible はホストに接続できない場合、そのホストを「UNREACHABLE」とマークし、実行時にアクティブなホストのリストから削除します。`meta: clear_host_errors` を使用してすべてのホストを再有効化することで、後続のタスクが再びホストに到達しようとすることができます。" 5611 5612#: ../../rst/user_guide/playbooks_error_handling.rst:62 5613msgid "Handlers and failure" 5614msgstr "ハンドラーおよび失敗" 5615 5616#: ../../rst/user_guide/playbooks_error_handling.rst:64 5617msgid "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." 5618msgstr "Ansible は、各プレイの最後に :ref:`handlers <handlers>` を実行します。タスクがハンドラーに通知しても、プレイの後半で別のタスクが失敗すると、デフォルトではハンドラーはそのホスト上で **実行されず**、ホストが予期せぬ状態になる可能性があります。たとえば、タスクが設定ファイルを更新し、ハンドラーにサービスの再起動を通知したとします。同じプレイの後半でタスクが失敗した場合、設定ファイルは変更するかもしれませんが、サービスは再起動しません。" 5619 5620#: ../../rst/user_guide/playbooks_error_handling.rst:71 5621msgid "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.)" 5622msgstr "この動作は、``force_handlers: True`` をプレイに含めるか、``force_handlers = True`` を ansible.cfg に追加して、``--force-handlers`` コマンドラインオプションで変更できます。ハンドラーが強制的に実行すると、Ansible は通知されたすべてのハンドラーを、タスクが失敗したホストも含めてすべてのホストで実行します (ホストが到達不能になるなど、特定のエラーによってハンドラーの実行が妨げられる可能性があることに注意してください)。" 5623 5624#: ../../rst/user_guide/playbooks_error_handling.rst:80 5625msgid "Defining failure" 5626msgstr "障害の定義" 5627 5628#: ../../rst/user_guide/playbooks_error_handling.rst:82 5629msgid "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." 5630msgstr "Ansible では、``failed_when`` 条件分岐を使用して、各タスクで「失敗」の意味を定義することができます。Ansible のすべての条件分岐と同様に、複数の ``failed_when`` 条件のリストは暗黙の ``and`` で結合されており、これは *すべての* 条件が満たされたときにのみタスクが失敗することを意味します。いずれかの条件が満たされたときに失敗をトリガーしたい場合は、明示的な ``or`` 演算子を使用して文字列で条件を定義する必要があります。" 5631 5632#: ../../rst/user_guide/playbooks_error_handling.rst:84 5633msgid "You may check for failure by searching for a word or phrase in the output of a command::" 5634msgstr "コマンドの出力で単語またはフレーズを検索して、障害の有無を確認できます。" 5635 5636#: ../../rst/user_guide/playbooks_error_handling.rst:91 5637msgid "or based on the return code::" 5638msgstr "または、戻りコードに基いて確認できます。" 5639 5640#: ../../rst/user_guide/playbooks_error_handling.rst:98 5641msgid "You can also combine multiple conditions for failure. This task will fail if both conditions are true::" 5642msgstr "複数の条件を組み合わせて失敗させることもできます。このタスクは、両方の条件が真であれば失敗します。" 5643 5644#: ../../rst/user_guide/playbooks_error_handling.rst:107 5645msgid "If you want the task to fail when only one condition is satisfied, change the ``failed_when`` definition to::" 5646msgstr "条件が満たされたときにのみタスクが失敗する場合は、``failed_when`` 定義を以下のように変更します。" 5647 5648#: ../../rst/user_guide/playbooks_error_handling.rst:111 5649msgid "If you have too many conditions to fit neatly into one line, you can split it into a multi-line yaml value with ``>``::" 5650msgstr "条件が多すぎて 1 行にうまく収まらない場合は、``>`` を使用して、これを複数行の yaml 値に分割できます。" 5651 5652#: ../../rst/user_guide/playbooks_error_handling.rst:124 5653msgid "Defining \"changed\"" 5654msgstr "「変更済み」の定義" 5655 5656#: ../../rst/user_guide/playbooks_error_handling.rst:126 5657msgid "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::" 5658msgstr "Ansible では、``changed_when`` 条件式を使用して、特定のタスクがリモートノードを「変更」したときを定義することができます。これにより、戻りコードや出力に基づいて、変更を Ansible の統計で報告するかどうか、ハンドラーをトリガーするかどうかを決定することができます。Ansible のすべての条件式と同様に、複数の``changed_when`` 条件のリストは暗黙の ``and`` で結合されており、タスクは *すべての* 条件が満たされたときにのみ変更を報告することを意味します。いずれかの条件が満たされたときに変更を報告したい場合は、明示的な ``or`` 演算子を使用して文字列で条件を定義する必要があります。以下に例を示します。" 5659 5660#: ../../rst/user_guide/playbooks_error_handling.rst:139 5661msgid "You can also combine multiple conditions to override \"changed\" result::" 5662msgstr "複数の条件を組み合わせて「変更」の結果を上書きすることもできます。" 5663 5664#: ../../rst/user_guide/playbooks_error_handling.rst:149 5665msgid "See :ref:`controlling_what_defines_failure` for more conditional syntax examples." 5666msgstr "その他の条件付き構文例については、「:ref:`controlling_what_defines_failure`」を参照してください。" 5667 5668#: ../../rst/user_guide/playbooks_error_handling.rst:152 5669msgid "Ensuring success for command and shell" 5670msgstr "コマンドとシェルの成功の確認" 5671 5672#: ../../rst/user_guide/playbooks_error_handling.rst:154 5673msgid "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::" 5674msgstr ":ref:`command <command_module>` モジュールおよび :ref:`shell <shell_module>` モジュールは戻りコードを処理するため、正常な終了コードがゼロではないこまんどがある場合は、以下を行うことができます。" 5675 5676#: ../../rst/user_guide/playbooks_error_handling.rst:162 5677msgid "Aborting a play on all hosts" 5678msgstr "すべてのホストでプレイを中止" 5679 5680#: ../../rst/user_guide/playbooks_error_handling.rst:164 5681msgid "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." 5682msgstr "時には、1 つのホストでの失敗や、ある割合のホストでの失敗により、すべてのホストでのプレイ全体を中止させたいことがあります。``any_errors_fatal`` を使用すると、最初の失敗が発生した後にプレイの実行を停止することができます。より細かく制御するには、``max_fail_percentage`` を使用して、特定の割合のホストで失敗した後に実行を中止することができます。" 5683 5684#: ../../rst/user_guide/playbooks_error_handling.rst:167 5685msgid "Aborting on the first error: any_errors_fatal" 5686msgstr "最初のエラーで強制終了: any_errors_fatal" 5687 5688#: ../../rst/user_guide/playbooks_error_handling.rst:169 5689msgid "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::" 5690msgstr "``any_errors_fatal`` を設定し、タスクがエラーを返した場合、Ansible は現在のバッチ内のすべてのホストで致命的なタスクを終了し、すべてのホストでプレイの実行を停止します。後続のタスクやプレイは実行されません。致命的なエラーから回復するには、ブロックに :ref:`rescue section <block_error_handling>` を追加します。``any_errors_fatal`` は、プレイまたはブロックレベルで設定できます。" 5691 5692#: ../../rst/user_guide/playbooks_error_handling.rst:182 5693#, python-format 5694msgid "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::" 5695msgstr "この機能は、Playbook の実行を継続するために、すべてのタスクが 100％ 成功する必要がある場合に使用できます。たとえば、複数のデータセンターにあるマシンでサービスを実行し、ユーザーからのトラフィックをサービスに渡すためにロードバランサーを使用している場合は、メンテナンスのためにサービスを停止する前に、すべてのロードバランサーを無効にします。ロードバランサーを無効にするタスクに障害が発生しても、他のすべてのタスクを停止させるには、次のようにします。" 5696 5697#: ../../rst/user_guide/playbooks_error_handling.rst:207 5698msgid "In this example Ansible starts the software upgrade on the front ends only if all of the load balancers are successfully disabled." 5699msgstr "この例では、すべてのロードバランサーが正常に無効になっている場合にのみ、Ansible が、フロントエンドでソフトウェアのアップグレードを開始します。" 5700 5701#: ../../rst/user_guide/playbooks_error_handling.rst:212 5702msgid "Setting a maximum failure percentage" 5703msgstr "最大失敗率の設定" 5704 5705#: ../../rst/user_guide/playbooks_error_handling.rst:214 5706msgid "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::" 5707msgstr "デフォルトでは、Ansible はまだ失敗していないホストがある限り、タスクを実行し続けます。ローリングアップデートを実行する場合など、ある一定の失敗率に達したときにプレイを中断したい場合があります。これを可能にするには、プレイの最大失敗率を設定することができます。" 5708 5709#: ../../rst/user_guide/playbooks_error_handling.rst:221 5710msgid "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." 5711msgstr "``max_fail_percentage`` の設定は、:ref:`serial <rolling_update_batch_size>` と一緒に使用すると、各バッチに適用されます。上の例では、最初の (あるいは任意の) バッチに含まれる 10 台のサーバーのうち 3 台以上が故障した場合、残りのプレイは中止されます。" 5712 5713#: ../../rst/user_guide/playbooks_error_handling.rst:225 5714msgid "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." 5715msgstr "設定されたパーセンテージは、同等ではなく、超えなければなりません。たとえば、serialが 4 に設定されていて、2 つのシステムが故障したときにプレイを中止するタスクにしたい場合は、max_fail_percentage を 50 ではなく 49 に設定します。" 5716 5717#: ../../rst/user_guide/playbooks_error_handling.rst:228 5718msgid "Controlling errors in blocks" 5719msgstr "ブロックのエラーを制御" 5720 5721#: ../../rst/user_guide/playbooks_error_handling.rst:230 5722msgid "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." 5723msgstr "ブロックを使用してタスクエラーへの応答を定義することもできます。この方法は、多くのプログラミング言語での例外処理に似ています。詳細と例は、「:ref:`block_error_handling`」を参照してください。" 5724 5725#: ../../rst/user_guide/playbooks_error_handling.rst:238 5726#: ../../rst/user_guide/playbooks_filters.rst:1795 5727#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:730 5728#: ../../rst/user_guide/playbooks_lookups.rst:28 5729#: ../../rst/user_guide/playbooks_loops.rst:438 5730#: ../../rst/user_guide/playbooks_prompts.rst:109 5731#: ../../rst/user_guide/playbooks_reuse.rst:195 5732#: ../../rst/user_guide/playbooks_reuse_includes.rst:21 5733#: ../../rst/user_guide/playbooks_reuse_roles.rst:607 5734#: ../../rst/user_guide/playbooks_templating.rst:44 5735#: ../../rst/user_guide/playbooks_tests.rst:390 5736#: ../../rst/user_guide/playbooks_variables.rst:451 5737msgid ":ref:`playbooks_conditionals`" 5738msgstr ":ref:`playbooks_conditionals`" 5739 5740#: ../../rst/user_guide/playbooks_error_handling.rst:239 5741#: ../../rst/user_guide/playbooks_filters.rst:1796 5742#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:731 5743#: ../../rst/user_guide/playbooks_lookups.rst:29 5744#: ../../rst/user_guide/playbooks_loops.rst:439 5745#: ../../rst/user_guide/playbooks_prompts.rst:110 5746#: ../../rst/user_guide/playbooks_templating.rst:45 5747#: ../../rst/user_guide/playbooks_tests.rst:391 5748#: ../../rst/user_guide/playbooks_variables.rst:452 5749msgid "Conditional statements in playbooks" 5750msgstr "Playbook の条件付きステートメント" 5751 5752#: ../../rst/user_guide/playbooks_filters.rst:5 5753msgid "Using filters to manipulate data" 5754msgstr "フィルターを使用したデータの操作" 5755 5756#: ../../rst/user_guide/playbooks_filters.rst:7 5757msgid "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." 5758msgstr "フィルターを使用すると、JSON データを YAML データに変換したり、URL を分割してホスト名を抽出したり、文字列の SHA1 ハッシュを取得したり、整数を加算または乗算したりなど、さまざまなことができます。ここで紹介している Ansible 固有のフィルターを使用してデータを操作することもできますし、Jinja2 に同梱されている標準的なフィルターを使用することもできます。Jinja2 の公式テンプレートドキュメントの :ref:`組み込みフィルター <jinja2:builtin-filters>` のリストを参照してださい。また、:ref:`Python メソッド <jinja2:python-methods>` を使用してデータを変換することもできます。:ref:`カスタム Ansible フィルターをプラグインとして作成 <developing_filter_plugins>` することもできますが、通常は、誰もが使用できるように新しいフィルターを ansible-core リポジトリーに追加することが歓迎されています。" 5759 5760#: ../../rst/user_guide/playbooks_filters.rst:9 5761msgid "Because templating happens on the Ansible controller, **not** on the target host, filters execute on the controller and transform data locally." 5762msgstr "テンプレート化はターゲットホスト上 **ではなく**、Ansible コントローラー上で行われるため、フィルターはコントローラ上で実行し、データはローカルに変換されます。" 5763 5764#: ../../rst/user_guide/playbooks_filters.rst:15 5765msgid "Handling undefined variables" 5766msgstr "未定義変数の処理" 5767 5768#: ../../rst/user_guide/playbooks_filters.rst:17 5769msgid "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." 5770msgstr "フィルターは、デフォルトを指定したり、一部の変数を任意にしたりすることで、欠落している変数や未定義の変数を管理するのに役立ちます。ほとんどの未定義の変数を無視するように Ansibl eを設定した場合は、``mandatory`` フィルターを使用して、いくつかの変数を必要な値としてマークすることができます。" 5771 5772#: ../../rst/user_guide/playbooks_filters.rst:22 5773msgid "Providing default values" 5774msgstr "デフォルト値の指定" 5775 5776#: ../../rst/user_guide/playbooks_filters.rst:24 5777msgid "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::" 5778msgstr "Jinja2 の「default」フィルターを使用すれば、テンプレートの中で直接、変数のデフォルト値を指定することができます。変数が定義されていない場合に失敗するよりも優れたアプローチであることがよくあります。" 5779 5780#: ../../rst/user_guide/playbooks_filters.rst:28 5781msgid "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." 5782msgstr "上記の例では、変数「some_variable」が定義されていない場合、Ansible は「undefined variable」エラーを発生させて失敗するのではなく、デフォルト値 5 を使用します。ロール内で作業している場合は、``defaults/main.yml`` を追加して、ロール内の変数のデフォルト値を定義することもできます。" 5783 5784#: ../../rst/user_guide/playbooks_filters.rst:30 5785msgid "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." 5786msgstr "バージョン 2.8 から、Jinja で Undefined の値の属性にアクセスしようとすると、すぐにエラーが発生するのではなく、別の Undefined の値が返されます。これにより、中間値が定義されているかどうかわからない場合に、ネストされたデータ構造の中の値でデフォルトを簡単に使用することができるようになりました (つまり :code:`{{ foo.bar.baz | default('DEFAULT') }}`)。" 5787 5788#: ../../rst/user_guide/playbooks_filters.rst:33 5789msgid "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``::" 5790msgstr "変数が false または空の文字列に評価されるときにデフォルト値を使用する場合は、2 番目のパラメーターを ``true`` に設定する必要があります。" 5791 5792#: ../../rst/user_guide/playbooks_filters.rst:40 5793msgid "Making variables optional" 5794msgstr "変数の任意設定" 5795 5796#: ../../rst/user_guide/playbooks_filters.rst:42 5797msgid "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``::" 5798msgstr "デフォルトでは、Ansible はテンプレート式のすべての変数に値を要求します。しかし、特定の変数を任意にすることができます。たとえば、一部の項目ではシステムのデフォルト値を使用し、他の項目では値を制御することができます。変数を任意にするには、特殊変数 ``omit`` にデフォルト値を設定します。" 5799 5800#: ../../rst/user_guide/playbooks_filters.rst:55 5801msgid "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." 5802msgstr "この例では、``/tmp/foo`` ファイルおよび ``/tmp/bar`` ファイルのデフォルトモードはシステムの umask により決定されます。Ansible は ``mode`` の値を送信しません。3 番目のファイルである ``/tmp/baz`` だけが `mode=0444` オプションを受け取ります。" 5803 5804#: ../../rst/user_guide/playbooks_filters.rst:57 5805msgid "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." 5806msgstr "``default(omit)`` フィルターの後に追加のフィルターを「連鎖」させる場合は、代わりに ``\"{{ foo | default(None) | some_filter or omit }}\"`` のようにしてください。この例では、デフォルトの ``None`` (Python null) の値により、後続のフィルターが失敗し、ロジックの ``or omit`` 部分が誘発されます。``omit`` をこのように使用することは、連鎖させる後続のフィルターに非常に依存するため、試行錯誤が必要になります。" 5807 5808#: ../../rst/user_guide/playbooks_filters.rst:63 5809msgid "Defining mandatory values" 5810msgstr "必須値の定義" 5811 5812#: ../../rst/user_guide/playbooks_filters.rst:65 5813msgid "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::" 5814msgstr "未定義の変数を無視するように Ansible を設定する場合は、一部の値を必須として定義したい場合があります。デフォルトでは、Playbook またはコマンドの変数が未定義の場合、Ansible は失敗します。:ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` を ``false`` に設定することで、未定義の変数を許可するように Ansible を設定することができます。その場合は、一部の変数の定義を必須にしたい場合があります。これには次の方法があります。" 5815 5816#: ../../rst/user_guide/playbooks_filters.rst:69 5817msgid "The variable value will be used as is, but the template evaluation will raise an error if it is undefined." 5818msgstr "変数の値はそのまま使用されますが、定義されていない場合は、テンプレートの評価でエラーが発生します。" 5819 5820#: ../../rst/user_guide/playbooks_filters.rst:72 5821msgid "Defining different values for true/false/null (ternary)" 5822msgstr "true/false/null (三項) に異なる値を定義する" 5823 5824#: ../../rst/user_guide/playbooks_filters.rst:74 5825msgid "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)::" 5826msgstr "テストを作成し、そのテストが true を返したときに使用する値と、false を返したときに使用する値を定義することができます (バージョン 1.9 の新機能)。" 5827 5828#: ../../rst/user_guide/playbooks_filters.rst:78 5829msgid "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)::" 5830msgstr "さらに、true に使用する値を 1 つ定義し、false で 1 つの値、null で 3 番目の値を定義できます (バージョン 2.8 の新機能)。" 5831 5832#: ../../rst/user_guide/playbooks_filters.rst:83 5833msgid "Managing data types" 5834msgstr "データ型の管理" 5835 5836#: ../../rst/user_guide/playbooks_filters.rst:85 5837msgid "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." 5838msgstr "変数のデータ型の確認、変更、または設定を行う必要がある場合があります。たとえば、次のタスクでリストが必要なときに、登録済みの変数にディクショナリーが含まれていたり、Playbook でブール値が必要なときに、ユーザーの :ref:`prompt <playbooks_prompts>` が文字列を返したりすることがあります。データタイプの管理には、``type_debug``、``dict2items``、および ``items2dict`` の各フィルターを使用します。また、データ型自体を使用して、値を特定のデータ型としてキャストすることもできます。" 5839 5840#: ../../rst/user_guide/playbooks_filters.rst:88 5841msgid "Discovering the data type" 5842msgstr "データ型の検出" 5843 5844#: ../../rst/user_guide/playbooks_filters.rst:92 5845msgid "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::" 5846msgstr "変数の基礎となる Python の型がわからない場合は、``type_debug`` フィルターを使用して表示することができます。これはデバッグ時に特定の型の変数が必要になったときに便利です。" 5847 5848#: ../../rst/user_guide/playbooks_filters.rst:100 5849msgid "Transforming dictionaries into lists" 5850msgstr "ディクショナリーのリストへの変換" 5851 5852#: ../../rst/user_guide/playbooks_filters.rst:105 5853msgid "Use the ``dict2items`` filter to transform a dictionary into a list of items suitable for :ref:`looping <playbooks_loops>`::" 5854msgstr "``dict2items`` フィルターを使用して、ディクショナリーを :ref:`looping <playbooks_loops>` に適した項目のリストに変換します。" 5855 5856#: ../../rst/user_guide/playbooks_filters.rst:109 5857#: ../../rst/user_guide/playbooks_filters.rst:130 5858msgid "Dictionary data (before applying the ``dict2items`` filter)::" 5859msgstr "ディクショナリーデータ (``dict2items`` フィルターを適用する前)::" 5860 5861#: ../../rst/user_guide/playbooks_filters.rst:115 5862#: ../../rst/user_guide/playbooks_filters.rst:136 5863msgid "List data (after applying the ``dict2items`` filter)::" 5864msgstr "データを一覧表示 (``dict2items`` フィルターを適用した後)::" 5865 5866#: ../../rst/user_guide/playbooks_filters.rst:124 5867msgid "The ``dict2items`` filter is the reverse of the ``items2dict`` filter." 5868msgstr "``dict2items`` フィルターは、``items2dict`` フィルターの逆の効果があります。" 5869 5870#: ../../rst/user_guide/playbooks_filters.rst:126 5871msgid "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::" 5872msgstr "キー名を設定する場合は、``dict2items`` フィルターは 2 つのキーワード引数を受け入れます。``key_name`` 引数および ``value_name`` 引数を渡すと、リスト出力のキーの名前を設定します。" 5873 5874#: ../../rst/user_guide/playbooks_filters.rst:145 5875msgid "Transforming lists into dictionaries" 5876msgstr "リストのディクショナリーへの変換" 5877 5878#: ../../rst/user_guide/playbooks_filters.rst:149 5879msgid "Use the ``items2dict`` filter to transform a list into a dictionary, mapping the content into ``key: value`` pairs::" 5880msgstr "``items2dict`` フィルターを使用してリストをディクショナリーに変換し、コンテンツを ``key: value`` のペアにマッピングします。" 5881 5882#: ../../rst/user_guide/playbooks_filters.rst:153 5883msgid "List data (before applying the ``items2dict`` filter)::" 5884msgstr "データを一覧表示 (``items2dict`` フィルターを適用する前)::" 5885 5886#: ../../rst/user_guide/playbooks_filters.rst:161 5887msgid "Dictionary data (after applying the ``items2dict`` filter)::" 5888msgstr "ディクショナリーデータ (``items2dict`` フィルターを適用した後)::" 5889 5890#: ../../rst/user_guide/playbooks_filters.rst:166 5891msgid "The ``items2dict`` filter is the reverse of the ``dict2items`` filter." 5892msgstr "``items2dict`` フィルターは、``dict2items`` フィルターの逆の効果があります。" 5893 5894#: ../../rst/user_guide/playbooks_filters.rst:168 5895msgid "Not all lists use ``key`` to designate keys and ``value`` to designate values. For example::" 5896msgstr "すべてのリストで、キーの指定に ``key`` を使用し、値の指定に ``value`` を使用しているわけではありません。以下に例を示します。" 5897 5898#: ../../rst/user_guide/playbooks_filters.rst:178 5899msgid "In this example, you must pass the ``key_name`` and ``value_name`` arguments to configure the transformation. For example::" 5900msgstr "この例では、``key_name`` 引数と ``value_name`` 引数を渡すと、変換を設定する必要があります。以下に例を示します。" 5901 5902#: ../../rst/user_guide/playbooks_filters.rst:182 5903msgid "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``." 5904msgstr "これらの引数、またはリストに適した値を渡さない場合は、``KeyError: key`` または ``KeyError: my_typo`` が表示されます。" 5905 5906#: ../../rst/user_guide/playbooks_filters.rst:185 5907msgid "Forcing the data type" 5908msgstr "データ型を強制" 5909 5910#: ../../rst/user_guide/playbooks_filters.rst:187 5911msgid "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::" 5912msgstr "値を特定の型にキャストすることができます。たとえば、:ref:`vars_prompt <playbooks_prompts>` から「True」という入力を期待していて、Ansible にそれを文字列ではなくブール値として認識させたい場合は、次のようになります。" 5913 5914#: ../../rst/user_guide/playbooks_filters.rst:193 5915msgid "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::" 5916msgstr "ファクトに対して数学的な比較を実行し、Ansible が文字列ではなく整数として認識する場合は、以下を行います。" 5917 5918#: ../../rst/user_guide/playbooks_filters.rst:204 5919msgid "Formatting data: YAML and JSON" 5920msgstr "データのフォーマット: YAML および JSON" 5921 5922#: ../../rst/user_guide/playbooks_filters.rst:206 5923msgid "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::" 5924msgstr "テンプレート内のデータ構造を JSON 形式と YAML 形式との間で切り替えることができ、フォーマット化やインデント付け、データの読み込みなどのオプションも用意されています。基本的なフィルターは、時折、デバッグに役立ちます。" 5925 5926#: ../../rst/user_guide/playbooks_filters.rst:211 5927msgid "For human readable output, you can use::" 5928msgstr "人が判読できる出力にするには、以下を使用できます。" 5929 5930#: ../../rst/user_guide/playbooks_filters.rst:216 5931msgid "You can change the indentation of either format::" 5932msgstr "いずれかの形式のインデントを変更できます。" 5933 5934#: ../../rst/user_guide/playbooks_filters.rst:221 5935msgid "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::" 5936msgstr "``to_yaml`` フィルターおよび ``to_nice_yaml`` フィルターは、デフォルトで 80 記号の文字列長制限を持つ `PyYAML library`_ を使用しています。このため、80 番目の記号の後に予期せぬ改行が発生します (80 番目のシンボルの後に空白がある場合)。このような動作を回避し、長い行を生成するには、``width`` オプションを使用します。フィルターは Python 関数のプロキシーをサポートしていないため、``float(\"inf\")`` のような構文ではなく、ハードコードされた数値を使用して幅を定義する必要があります。以下に例を示します。" 5937 5938#: ../../rst/user_guide/playbooks_filters.rst:227 5939msgid "The filter does support passing through other YAML parameters. For a full list, see the `PyYAML documentation`_." 5940msgstr "フィルターは他の YAML パラメーターのパススルーをサポートします。完全な一覧は、「`PyYAML documentation`_」を参照してください。" 5941 5942#: ../../rst/user_guide/playbooks_filters.rst:229 5943msgid "If you are reading in some already formatted data::" 5944msgstr "すでにフォーマットされている一部のデータで読み取る場合::" 5945 5946#: ../../rst/user_guide/playbooks_filters.rst:234 5947#: ../../rst/user_guide/playbooks_filters.rst:268 5948msgid "for example::" 5949msgstr "たとえば、以下のようになります。" 5950 5951#: ../../rst/user_guide/playbooks_filters.rst:247 5952msgid "Filter `to_json` and Unicode support" 5953msgstr "`to_json` と Unicode サポートをフィルタリング" 5954 5955#: ../../rst/user_guide/playbooks_filters.rst:249 5956msgid "By default `to_json` and `to_nice_json` will convert data received to ASCII, so::" 5957msgstr "デフォルトでは、`to_json` および `to_nice_json` は、受診したデータを ASCII に変換するため、次のようになります。" 5958 5959#: ../../rst/user_guide/playbooks_filters.rst:253 5960msgid "will return::" 5961msgstr "以下が返ってきます。" 5962 5963#: ../../rst/user_guide/playbooks_filters.rst:257 5964msgid "To keep Unicode characters, pass the parameter `ensure_ascii=False` to the filter::" 5965msgstr "Unicode 文字を保持するには、パラメーター `ensure_ascii=False` をフィルターに渡します。" 5966 5967#: ../../rst/user_guide/playbooks_filters.rst:265 5968msgid "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." 5969msgstr "複数ドキュメントの YAML 文字列を解析するために、``from_yaml_all`` フィルターが提供されます。``from_yaml_all`` フィルターは解析された YAML ドキュメントのジェネレーターを返します。" 5970 5971#: ../../rst/user_guide/playbooks_filters.rst:281 5972msgid "Combining and selecting data" 5973msgstr "データの統合および選択" 5974 5975#: ../../rst/user_guide/playbooks_filters.rst:283 5976msgid "You can combine data from multiple sources and types, and select values from large data structures, giving you precise control over complex data." 5977msgstr "複数のソースやタイプのデータを組み合わせたり、大規模なデータ構造から値を選択したりすることで、複雑なデータを正確に制御することができます。" 5978 5979#: ../../rst/user_guide/playbooks_filters.rst:288 5980msgid "Combining items from multiple lists: zip and zip_longest" 5981msgstr "複数のリストからの項目の組み合わせ: zip および zip_longest" 5982 5983#: ../../rst/user_guide/playbooks_filters.rst:292 5984msgid "To get a list combining the elements of other lists use ``zip``::" 5985msgstr "他のリストの要素を組み合わせたリストを取得するには、``zip`` を使用します。" 5986 5987#: ../../rst/user_guide/playbooks_filters.rst:306 5988msgid "To always exhaust all lists use ``zip_longest``::" 5989msgstr "すべての一覧を常に使い切るには、``zip_longest`` を使用します。" 5990 5991#: ../../rst/user_guide/playbooks_filters.rst:314 5992msgid "Similarly to the output of the ``items2dict`` filter mentioned above, these filters can be used to construct a ``dict``::" 5993msgstr "上記の ``items2dict`` フィルターの出力と同様に、これらのフィルターを使用して ``dict`` を作成できます。" 5994 5995#: ../../rst/user_guide/playbooks_filters.rst:318 5996msgid "List data (before applying the ``zip`` filter)::" 5997msgstr "リストデータ (``zip`` フィルターを適用する前)::" 5998 5999#: ../../rst/user_guide/playbooks_filters.rst:327 6000msgid "Dictionary data (after applying the ``zip`` filter)::" 6001msgstr "ディクショナリーデータ (``zip`` フィルターを適用した後)::" 6002 6003#: ../../rst/user_guide/playbooks_filters.rst:333 6004msgid "Combining objects and subelements" 6005msgstr "オブジェクトとサブ要素の統合" 6006 6007#: ../../rst/user_guide/playbooks_filters.rst:337 6008msgid "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::" 6009msgstr "``subelements`` フィルターは、``subelements`` ルックアップと同様に、オブジェクトとそのオブジェクトのサブエレメントの値の積を生成します。これにより、テンプレートで使用する個々のサブエレメントを指定することができます。たとえば、以下のような式になります。" 6010 6011#: ../../rst/user_guide/playbooks_filters.rst:341 6012msgid "Data before applying the ``subelements`` filter::" 6013msgstr "``subelements`` フィルターの適用前のデータ::" 6014 6015#: ../../rst/user_guide/playbooks_filters.rst:357 6016msgid "Data after applying the ``subelements`` filter::" 6017msgstr "``subelements`` フィルターの適用後のデータ::" 6018 6019#: ../../rst/user_guide/playbooks_filters.rst:385 6020msgid "You can use the transformed data with ``loop`` to iterate over the same subelement for multiple objects::" 6021msgstr "変換したデータを ``loop`` とともに使用して、複数のオブジェクトに対して同じサブ要素を繰り返すことができます。" 6022 6023#: ../../rst/user_guide/playbooks_filters.rst:396 6024msgid "Combining hashes/dictionaries" 6025msgstr "ハッシュ/ディクショナリーの統合" 6026 6027#: ../../rst/user_guide/playbooks_filters.rst:400 6028msgid "The ``combine`` filter allows hashes to be merged. For example, the following would override keys in one hash::" 6029msgstr "``combine`` フィルターはハッシュをマージできます。たとえば、以下は 1 つのハッシュ内のキーをオーバーライドします。" 6030 6031#: ../../rst/user_guide/playbooks_filters.rst:404 6032msgid "The resulting hash would be::" 6033msgstr "生成されるハッシュは、以下のようになります。" 6034 6035#: ../../rst/user_guide/playbooks_filters.rst:408 6036msgid "The filter can also take multiple arguments to merge::" 6037msgstr "フィルターは複数の引数を使用してマージすることもできます。" 6038 6039#: ../../rst/user_guide/playbooks_filters.rst:413 6040msgid "In this case, keys in ``d`` would override those in ``c``, which would override those in ``b``, and so on." 6041msgstr "この場合、``d`` のキーは ``c`` のキーを上書きし、``b`` のキーも同様に上書きされます。" 6042 6043#: ../../rst/user_guide/playbooks_filters.rst:415 6044msgid "The filter also accepts two optional parameters: ``recursive`` and ``list_merge``." 6045msgstr "フィルターは、``recursive`` および ``list_merge`` の 2 つの任意のパラメーターも使用できます。" 6046 6047#: ../../rst/user_guide/playbooks_filters.rst:420 6048msgid "recursive" 6049msgstr "再帰" 6050 6051#: ../../rst/user_guide/playbooks_filters.rst:418 6052msgid "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``." 6053msgstr "ブール値で、デフォルトは ``False`` です。``combine`` が入れ子になったハッシュを再帰的にマージするかどうかを指定します。注: ``ansible.cfg`` の ``hash_behaviour`` 設定の値には **依存しません** 。" 6054 6055#: ../../rst/user_guide/playbooks_filters.rst:424 6056msgid "list_merge" 6057msgstr "list_merge" 6058 6059#: ../../rst/user_guide/playbooks_filters.rst:423 6060msgid "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." 6061msgstr "使用できる値は ``replace`` (デフォルト)、``keep``、``append``、``prepend``、``append_rp``、または ``prepend_rp`` です。ハッシュに配列/リストをマージする際に ``combine`` の動作を変更します。" 6062 6063#: ../../rst/user_guide/playbooks_filters.rst:440 6064msgid "If ``recursive=False`` (the default), nested hash aren't merged::" 6065msgstr "``recursive=False`` (デフォルト) の場合は、ネストされたハッシュがマージされません。" 6066 6067#: ../../rst/user_guide/playbooks_filters.rst:444 6068#: ../../rst/user_guide/playbooks_filters.rst:456 6069#: ../../rst/user_guide/playbooks_filters.rst:478 6070#: ../../rst/user_guide/playbooks_filters.rst:487 6071#: ../../rst/user_guide/playbooks_filters.rst:496 6072#: ../../rst/user_guide/playbooks_filters.rst:506 6073#: ../../rst/user_guide/playbooks_filters.rst:531 6074#: ../../rst/user_guide/playbooks_filters.rst:546 6075#: ../../rst/user_guide/playbooks_filters.rst:588 6076#: ../../rst/user_guide/playbooks_filters.rst:675 6077#: ../../rst/user_guide/playbooks_tests.rst:319 6078#: ../../rst/user_guide/playbooks_tests.rst:342 6079msgid "This would result in::" 6080msgstr "これにより、以下のようになります。" 6081 6082#: ../../rst/user_guide/playbooks_filters.rst:452 6083msgid "If ``recursive=True``, recurse into nested hash and merge their keys::" 6084msgstr "``recursive=True`` の場合は、ネストされたハッシュを再帰的に使用して、鍵をマージします。" 6085 6086#: ../../rst/user_guide/playbooks_filters.rst:465 6087msgid "If ``list_merge='replace'`` (the default), arrays from the right hash will \"replace\" the ones in the left hash::" 6088msgstr "``list_merge='replace'`` (デフォルト) の場合、右ハッシュの配列は左ハッシュの配列を「置き換え」ます。" 6089 6090#: ../../rst/user_guide/playbooks_filters.rst:483 6091msgid "If ``list_merge='keep'``, arrays from the left hash will be kept::" 6092msgstr "``list_merge='keep'`` の場合は、左のハッシュからの配列が保持されます。" 6093 6094#: ../../rst/user_guide/playbooks_filters.rst:492 6095msgid "If ``list_merge='append'``, arrays from the right hash will be appended to the ones in the left hash::" 6096msgstr "``list_merge='append'`` の場合は、右のハッシュからの配列が左のハッシュ内の配列に追加されます。" 6097 6098#: ../../rst/user_guide/playbooks_filters.rst:502 6099msgid "If ``list_merge='prepend'``, arrays from the right hash will be prepended to the ones in the left hash::" 6100msgstr "``list_merge='prepend'`` の場合は、右のハッシュからの配列が左のハッシュ内の配列の前に追加されます。" 6101 6102#: ../../rst/user_guide/playbooks_filters.rst:512 6103msgid "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::" 6104msgstr "``list_merge='append_rp'`` の場合は、右ハッシュの配列が、左ハッシュの配列に追加されます。左ハッシュの配列のうち、右ハッシュの対応する配列にもある要素は削除されます (「rp」は「remove present」の略)。両方のハッシュに存在しない重複した要素は保持されます。" 6105 6106#: ../../rst/user_guide/playbooks_filters.rst:542 6107msgid "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::" 6108msgstr "``list_merge='prepend_rp'`` の場合、動作は ``append_rp`` のものと似ていますが、右のハッシュ内の配列の要素の前に追加されます。" 6109 6110#: ../../rst/user_guide/playbooks_filters.rst:557 6111msgid "``recursive`` and ``list_merge`` can be used together::" 6112msgstr "``recursive`` および ``list_merge`` は一緒に使用できます。" 6113 6114#: ../../rst/user_guide/playbooks_filters.rst:611 6115msgid "Selecting values from arrays or hashtables" 6116msgstr "配列またはハッシュテーブルからの値の選択" 6117 6118#: ../../rst/user_guide/playbooks_filters.rst:615 6119msgid "The `extract` filter is used to map from a list of indices to a list of values from a container (hash or array)::" 6120msgstr "`extract` フィルターは、インデックスのリストから、コンテナー (ハッシュまたは配列) の値のリストへのマッピングに使用されます。" 6121 6122#: ../../rst/user_guide/playbooks_filters.rst:620 6123msgid "The results of the above expressions would be::" 6124msgstr "上記の式の結果は、以下のようになります。" 6125 6126#: ../../rst/user_guide/playbooks_filters.rst:625 6127msgid "The filter can take another argument::" 6128msgstr "フィルターは別の引数を取ることができます。" 6129 6130#: ../../rst/user_guide/playbooks_filters.rst:629 6131msgid "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'." 6132msgstr "これにより、グループ「x」のホスト一覧が `hostvars` で検索され、結果の `ec2_ip_address` を探します。最終結果は、グループ「x」のホストの IP アドレス一覧になります。" 6133 6134#: ../../rst/user_guide/playbooks_filters.rst:631 6135msgid "The third argument to the filter can also be a list, for a recursive lookup inside the container::" 6136msgstr "フィルターの第 3 引数にはリストを指定することもでき、コンテナー内の再帰的な検索が可能です。" 6137 6138#: ../../rst/user_guide/playbooks_filters.rst:635 6139msgid "This would return a list containing the value of `b['a']['x']['y']`." 6140msgstr "これにより、`b['a']['x']['y']` の値が含まれるリストが返されます。" 6141 6142#: ../../rst/user_guide/playbooks_filters.rst:638 6143msgid "Combining lists" 6144msgstr "リストの統合" 6145 6146#: ../../rst/user_guide/playbooks_filters.rst:640 6147msgid "This set of filters returns a list of combined lists." 6148msgstr "このフィルターセットは、組み合わせたリストを返します。" 6149 6150#: ../../rst/user_guide/playbooks_filters.rst:644 6151msgid "permutations" 6152msgstr "置換" 6153 6154#: ../../rst/user_guide/playbooks_filters.rst:645 6155msgid "To get permutations of a list::" 6156msgstr "リストの置換を取得するには、以下を実行します。" 6157 6158#: ../../rst/user_guide/playbooks_filters.rst:656 6159msgid "combinations" 6160msgstr "組み合わせ" 6161 6162#: ../../rst/user_guide/playbooks_filters.rst:657 6163msgid "Combinations always require a set size::" 6164msgstr "組み合わせには常にセットサイズが必要です。" 6165 6166#: ../../rst/user_guide/playbooks_filters.rst:663 6167msgid "Also see the :ref:`zip_filter`" 6168msgstr "また、「:ref:`zip_filter`」を参照してください。" 6169 6170#: ../../rst/user_guide/playbooks_filters.rst:666 6171msgid "products" 6172msgstr "製品" 6173 6174#: ../../rst/user_guide/playbooks_filters.rst:667 6175msgid "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." 6176msgstr "製品フィルターは、入力されたイテラブルの `cartesian product <https://docs.python.org/3/library/itertools.html#itertools.product>`_ を返します。これはジェネレータ式の入れ子になった for-loop とほぼ同じです。" 6177 6178#: ../../rst/user_guide/playbooks_filters.rst:682 6179msgid "Selecting JSON data: JSON queries" 6180msgstr "JSON データの選択: JSON クエリー" 6181 6182#: ../../rst/user_guide/playbooks_filters.rst:684 6183msgid "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." 6184msgstr "JSON 形式の複雑なデータ構造 (Ansible ファクトなど) から単一の要素やデータサブセットを選択するには、``json_query`` フィルターを使用します。``json_query`` フィルターを使用すると、複雑な JSON 構造を照会し、ループ構造を使用して反復処理することができます。" 6185 6186#: ../../rst/user_guide/playbooks_filters.rst:688 6187#: ../../rst/user_guide/playbooks_filters.rst:829 6188msgid "This filter has migrated to the `community.general <https://galaxy.ansible.com/community/general>`_ collection. Follow the installation instructions to install that collection." 6189msgstr "`community.general <https://galaxy.ansible.com/community/general>`_ フィルターはコレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" 6190 6191#: ../../rst/user_guide/playbooks_filters.rst:691 6192msgid "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 <http://jmespath.org/examples.html>`_." 6193msgstr "このフィルターを使用する前に、Ansible コントローラーに **jmespath** 依存関係を手動でインストールする必要があります。このフィルターは **jmespath** をベースに作られており、同じ構文を使用することができます。例については、`jmespath の例 <http://jmespath.org/examples.html>`_ を参照してください。" 6194 6195#: ../../rst/user_guide/playbooks_filters.rst:693 6196msgid "Consider this data structure::" 6197msgstr "このデータ構造を考えてみましょう。" 6198 6199#: ../../rst/user_guide/playbooks_filters.rst:742 6200msgid "To extract all clusters from this structure, you can use the following query::" 6201msgstr "この構造からすべてのクラスターを抽出するには、以下のクエリーを使用できます。" 6202 6203#: ../../rst/user_guide/playbooks_filters.rst:749 6204msgid "To extract all server names::" 6205msgstr "すべてのサーバー名を抽出するには、以下を実行します。" 6206 6207#: ../../rst/user_guide/playbooks_filters.rst:756 6208msgid "To extract ports from cluster1::" 6209msgstr "cluster1 からポートを抽出するには、以下を実行します。" 6210 6211#: ../../rst/user_guide/playbooks_filters.rst:765 6212msgid "You can use a variable to make the query more readable." 6213msgstr "変数を使用すると、クエリーの読み取りがより容易になります。" 6214 6215#: ../../rst/user_guide/playbooks_filters.rst:767 6216msgid "To print out the ports from cluster1 in a comma separated string::" 6217msgstr "cluster1 のポートをコンマ区切りの文字列で表示するには、以下を行います。" 6218 6219#: ../../rst/user_guide/playbooks_filters.rst:773 6220msgid "In the example above, quoting literals using backticks avoids escaping quotes and maintains readability." 6221msgstr "上の例では、リテラルを backtick で引用することで、引用符のエスケープを避け、読みやすさを維持しています。" 6222 6223#: ../../rst/user_guide/playbooks_filters.rst:775 6224msgid "You can use YAML `single quote escaping <https://yaml.org/spec/current.html#id2534365>`_::" 6225msgstr "YAML の `一重引用符のエスケープ <https://yaml.org/spec/current.html#id2534365>`_ を使用できます。" 6226 6227#: ../../rst/user_guide/playbooks_filters.rst:782 6228msgid "Escaping single quotes within single quotes in YAML is done by doubling the single quote." 6229msgstr "YAML の一重引用符内で一重引用符をエスケープする場合は、一重引用符を二重にします。" 6230 6231#: ../../rst/user_guide/playbooks_filters.rst:784 6232msgid "To get a hash map with all ports and names of a cluster::" 6233msgstr "クラスターのすべてのポートおよび名前を持つハッシュマップを取得するには、以下を行います。" 6234 6235#: ../../rst/user_guide/playbooks_filters.rst:793 6236msgid "To extract ports from all clusters with name starting with 'server1'::" 6237msgstr "「server1」で始まる名前の全クラスターからポートを抽出するには、以下を行います。" 6238 6239#: ../../rst/user_guide/playbooks_filters.rst:801 6240msgid "To extract ports from all clusters with name containing 'server1'::" 6241msgstr "「server1」を含む名前の全クラスターからポートを抽出するには、以下を行います。" 6242 6243#: ../../rst/user_guide/playbooks_filters.rst:809 6244msgid "while using ``starts_with`` and ``contains``, you have to use `` to_json | from_json `` filter for correct parsing of data structure." 6245msgstr "``starts_with`` および ``contains`` を使用する場合は、データ構造を正しく解析するために `` to_json | from_json `` フィルターを使用する必要があります。" 6246 6247#: ../../rst/user_guide/playbooks_filters.rst:813 6248msgid "Randomizing data" 6249msgstr "データのランダム化" 6250 6251#: ../../rst/user_guide/playbooks_filters.rst:815 6252msgid "When you need a randomly generated value, use one of these filters." 6253msgstr "ランダムに生成された値が必要な場合は、これらのフィルターのいずれかを使用します。" 6254 6255#: ../../rst/user_guide/playbooks_filters.rst:821 6256msgid "Random MAC addresses" 6257msgstr "ランダムな MAC アドレス" 6258 6259#: ../../rst/user_guide/playbooks_filters.rst:825 6260msgid "This filter can be used to generate a random MAC address from a string prefix." 6261msgstr "このフィルターは、文字列プレフィックスからランダムな MAC アドレスを生成するために使用できます。" 6262 6263#: ../../rst/user_guide/playbooks_filters.rst:831 6264msgid "To get a random MAC address from a string prefix starting with '52:54:00'::" 6265msgstr "文字列プレフィックス「52:54:00」で始まるランダムな MAC アドレスを取得するには、次のコマンドを実行します。" 6266 6267#: ../../rst/user_guide/playbooks_filters.rst:836 6268msgid "Note that if anything is wrong with the prefix string, the filter will issue an error." 6269msgstr "プレフィックスの文字列で不具合が生じた場合は、フィルターによりエラーが生じることに注意してください。" 6270 6271#: ../../rst/user_guide/playbooks_filters.rst:840 6272msgid "As of Ansible version 2.9, you can also initialize the random number generator from a seed to create random-but-idempotent MAC addresses::" 6273msgstr "Ansible バージョン 2.9 以降では、シードから乱数ジェネレーターを初期化し、ランダムで冪等な MAC アドレスを作成することもできます。" 6274 6275#: ../../rst/user_guide/playbooks_filters.rst:848 6276msgid "Random items or numbers" 6277msgstr "ランダムな項目または数字" 6278 6279#: ../../rst/user_guide/playbooks_filters.rst:850 6280msgid "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." 6281msgstr "Ansible の``random`` フィルターは、デフォルトの Jinja2 ランダムフィルターを拡張したもので、一連のアイテムからランダムな項目を返したり、範囲に基づいてランダムな数値を生成したりするのに使用できます。" 6282 6283#: ../../rst/user_guide/playbooks_filters.rst:852 6284msgid "To get a random item from a list::" 6285msgstr "リストからランダムなアイテムを取得するには、以下を実行します。" 6286 6287#: ../../rst/user_guide/playbooks_filters.rst:857 6288msgid "To get a random number between 0 (inclusive) and a specified integer (exclusive)::" 6289msgstr "0 (含む) から指定した整数 (除く) の間の乱数を取得するには、次のようにします。" 6290 6291#: ../../rst/user_guide/playbooks_filters.rst:862 6292msgid "To get a random number from 0 to 100 but in steps of 10::" 6293msgstr "0 から 100 までの 10 のステップで乱数を取得するには、以下を行います。" 6294 6295#: ../../rst/user_guide/playbooks_filters.rst:867 6296msgid "To get a random number from 1 to 100 but in steps of 10::" 6297msgstr "1 から 100 までの 10 のステップで乱数を取得するには、以下を行います。" 6298 6299#: ../../rst/user_guide/playbooks_filters.rst:874 6300msgid "You can initialize the random number generator from a seed to create random-but-idempotent numbers::" 6301msgstr "シードから乱数ジェネレーターを初期化し、ランダムで冪等な数字を作成できます。" 6302 6303#: ../../rst/user_guide/playbooks_filters.rst:880 6304#: ../../rst/user_guide/playbooks_filters.rst:903 6305#: ../../rst/user_guide/playbooks_filters.rst:1338 6306msgid "If you use the ``seed`` parameter, you will get a different result with Python 3 and Python 2. This may break procedures such as password generation when you upgrade the version of Python used on your Ansible controller." 6307msgstr "``seed`` パラメーターを使用した場合は、Python 3 と Python 2 で異なる結果が得られます。これにより、Ansible コントローラーで使用している Python のバージョンをアップグレードした場合は、パスワード生成などの手順が破綻する可能性があります。" 6308 6309#: ../../rst/user_guide/playbooks_filters.rst:883 6310msgid "Shuffling a list" 6311msgstr "リストのシャッフル" 6312 6313#: ../../rst/user_guide/playbooks_filters.rst:885 6314msgid "The ``shuffle`` filter randomizes an existing list, giving a different order every invocation." 6315msgstr "``shuffle`` フィルターは、既存のリストをランダム化し、呼び出しごとに異なる順序を提供します。" 6316 6317#: ../../rst/user_guide/playbooks_filters.rst:887 6318msgid "To get a random list from an existing list::" 6319msgstr "既存のリストからランダムなリストを取得するには、以下を実行します。" 6320 6321#: ../../rst/user_guide/playbooks_filters.rst:894 6322msgid "You can initialize the shuffle generator from a seed to generate a random-but-idempotent order::" 6323msgstr "シャッフルジェネレーターをシードから初期化して、ランダムで冪等な順序を生成することができます。" 6324 6325#: ../../rst/user_guide/playbooks_filters.rst:899 6326msgid "The shuffle filter returns a list whenever possible. If you use it with a non 'listable' item, the filter does nothing." 6327msgstr "シャッフルフィルターは可能な場合常にリストを返します。「リスト可能」ではない項目で使用すると、フィルターは何も行いません。" 6328 6329#: ../../rst/user_guide/playbooks_filters.rst:908 6330msgid "Managing list variables" 6331msgstr "リスト変数の管理" 6332 6333#: ../../rst/user_guide/playbooks_filters.rst:910 6334msgid "You can search for the minimum or maximum value in a list, or flatten a multi-level list." 6335msgstr "リストの最小値や最大値を検索したり、複数レベルのリストをフラットにすることができます。" 6336 6337#: ../../rst/user_guide/playbooks_filters.rst:912 6338msgid "To get the minimum value from list of numbers::" 6339msgstr "数値リストから最小値を取得するには、以下を実行します。" 6340 6341#: ../../rst/user_guide/playbooks_filters.rst:918 6342msgid "To get the minimum value in a list of objects::" 6343msgstr "オブジェクトのリストで最小値を取得するには、以下を実行します。" 6344 6345#: ../../rst/user_guide/playbooks_filters.rst:922 6346msgid "To get the maximum value from a list of numbers::" 6347msgstr "数値リストから最大値を取得するには、以下を実行します。" 6348 6349#: ../../rst/user_guide/playbooks_filters.rst:928 6350msgid "To get the maximum value in a list of objects::" 6351msgstr "オブジェクトのリストで最大値を取得するには、以下を実行します。" 6352 6353#: ../../rst/user_guide/playbooks_filters.rst:934 6354msgid "Flatten a list (same thing the `flatten` lookup does)::" 6355msgstr "リストをフラット化します (`flatten` ルックアップと同等)。" 6356 6357#: ../../rst/user_guide/playbooks_filters.rst:939 6358msgid "Flatten only the first level of a list (akin to the `items` lookup)::" 6359msgstr "リストの最初のレベルのみをフラット化します (`items` ルックアップと同等)。" 6360 6361#: ../../rst/user_guide/playbooks_filters.rst:947 6362msgid "Preserve nulls in a list, by default flatten removes them. ::" 6363msgstr "リストに null を保持します。デフォルトでは、フラット化はこれらを削除します。" 6364 6365#: ../../rst/user_guide/playbooks_filters.rst:956 6366msgid "Selecting from sets or lists (set theory)" 6367msgstr "セットまたはリストの中から選択 (理論の設定)" 6368 6369#: ../../rst/user_guide/playbooks_filters.rst:958 6370msgid "You can select or combine items from sets or lists." 6371msgstr "セットまたはリストから項目を選択または組み合わせることができます。" 6372 6373#: ../../rst/user_guide/playbooks_filters.rst:962 6374msgid "To get a unique set from a list::" 6375msgstr "リストから一意のセットを取得するには、以下を指定します。" 6376 6377#: ../../rst/user_guide/playbooks_filters.rst:968 6378msgid "To get a union of two lists::" 6379msgstr "2 つのリストを組み合わせて取得するには、以下を指定します。" 6380 6381#: ../../rst/user_guide/playbooks_filters.rst:975 6382msgid "To get the intersection of 2 lists (unique list of all items in both)::" 6383msgstr "2 つのリスト (両方の全項目の一意のリスト) で構成されるものを取得するには、以下を指定します。" 6384 6385#: ../../rst/user_guide/playbooks_filters.rst:982 6386msgid "To get the difference of 2 lists (items in 1 that don't exist in 2)::" 6387msgstr "2 つのリストの相違点を取得するには (2 に存在しない 1 の項目)、以下を指定します。" 6388 6389#: ../../rst/user_guide/playbooks_filters.rst:989 6390msgid "To get the symmetric difference of 2 lists (items exclusive to each list)::" 6391msgstr "2 つのリストの対称的な違いを取得する (各リストへの除外) には、以下を指定します。" 6392 6393#: ../../rst/user_guide/playbooks_filters.rst:999 6394msgid "Calculating numbers (math)" 6395msgstr "数字の計算 (数学)" 6396 6397#: ../../rst/user_guide/playbooks_filters.rst:1003 6398msgid "You can calculate logs, powers, and roots of numbers with Ansible filters. Jinja2 provides other mathematical functions like abs() and round()." 6399msgstr "Ansible のフィルターを使用して、対数、累乗、おより根を計算することができます。また、Jinja2 には abs() や round() などの数学関数も用意されています。" 6400 6401#: ../../rst/user_guide/playbooks_filters.rst:1005 6402msgid "Get the logarithm (default is e)::" 6403msgstr "対数を取得します (デフォルトは e)。" 6404 6405#: ../../rst/user_guide/playbooks_filters.rst:1010 6406msgid "Get the base 10 logarithm::" 6407msgstr "ベース 10 の対数を取得します。" 6408 6409#: ../../rst/user_guide/playbooks_filters.rst:1015 6410msgid "Give me the power of 2! (or 5)::" 6411msgstr "2 の累乗 (または 5)::" 6412 6413#: ../../rst/user_guide/playbooks_filters.rst:1020 6414msgid "Square root, or the 5th::" 6415msgstr "平方根または 5 番目::" 6416 6417#: ../../rst/user_guide/playbooks_filters.rst:1030 6418msgid "Managing network interactions" 6419msgstr "ネットワーク対話の管理" 6420 6421#: ../../rst/user_guide/playbooks_filters.rst:1032 6422msgid "These filters help you with common network tasks." 6423msgstr "これらのフィルターは、一般的なネットワークタスクの使用に役立ちます。" 6424 6425#: ../../rst/user_guide/playbooks_filters.rst:1036 6426msgid "These filters have migrated to the `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ collection. Follow the installation instructions to install that collection." 6427msgstr "これらのフィルターは `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" 6428 6429#: ../../rst/user_guide/playbooks_filters.rst:1041 6430msgid "IP address filters" 6431msgstr "IP アドレスフィルター" 6432 6433#: ../../rst/user_guide/playbooks_filters.rst:1045 6434msgid "To test if a string is a valid IP address::" 6435msgstr "文字列が有効な IP アドレスかどうかをテストするには、以下を実行します。" 6436 6437#: ../../rst/user_guide/playbooks_filters.rst:1049 6438msgid "You can also require a specific IP protocol version::" 6439msgstr "さらに、特定の IP プロトコルバージョンが必要です。" 6440 6441#: ../../rst/user_guide/playbooks_filters.rst:1054 6442msgid "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::" 6443msgstr "IP アドレスフィルターを使用して、IP アドレスから特定の情報を抽出することもできます。たとえば、CIDR から IP アドレス自体を取得するには、以下を使用します。" 6444 6445#: ../../rst/user_guide/playbooks_filters.rst:1060 6446msgid "More information about ``ipaddr`` filter and complete usage guide can be found in :ref:`playbooks_filters_ipaddr`." 6447msgstr "``ipaddr`` フィルターの詳細と完全な使用ガイドは、「:ref:`playbooks_filters_ipaddr`」にあります。" 6448 6449#: ../../rst/user_guide/playbooks_filters.rst:1066 6450msgid "Network CLI filters" 6451msgstr "ネットワーク CLI フィルター" 6452 6453#: ../../rst/user_guide/playbooks_filters.rst:1070 6454msgid "To convert the output of a network device CLI command into structured JSON output, use the ``parse_cli`` filter::" 6455msgstr "ネットワーク機器の CLI コマンドの出力を構造化された JSON 出力に変換するには、``parse_cli`` フィルターを使用します。" 6456 6457#: ../../rst/user_guide/playbooks_filters.rst:1075 6458msgid "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." 6459msgstr "``parse_cli`` フィルターは、spec ファイルを読み込み、コマンド出力を通して JSON 出力を返します。YAML の spec ファイルは、CLI 出力をどのように解析するかを定義します。" 6460 6461#: ../../rst/user_guide/playbooks_filters.rst:1078 6462msgid "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." 6463msgstr "spec ファイルは有効な形式の YAML でなければなりません。CLI の出力をどのように解析し、JSON データを返すかを定義します。以下は、``show vlan`` コマンドからの出力を解析する有効な spec ファイルの例です。" 6464 6465#: ../../rst/user_guide/playbooks_filters.rst:1100 6466#: ../../rst/user_guide/playbooks_filters.rst:1202 6467msgid "The spec file above will return a JSON data structure that is a list of hashes with the parsed VLAN information." 6468msgstr "上記の spec ファイルは、解析された VLAN 情報を持つハッシュのリストである JSON データ構造を返します。" 6469 6470#: ../../rst/user_guide/playbooks_filters.rst:1103 6471msgid "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." 6472msgstr "同じコマンドでも、鍵と値のディレクティブを使用することで、ハッシュに解析することができます。以下は、同じ ``show vlan`` コマンドを使用して出力をハッシュ値に解析する例です。" 6473 6474#: ../../rst/user_guide/playbooks_filters.rst:1126 6475msgid "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." 6476msgstr "CLI コマンドを解析するもう一つの一般的なユースケースは、大きなコマンドを解析可能なブロックに分割することです。これは、``start_block`` ディレクティブと ``end_block`` ディレクティブを使用して、コマンドを解析可能なブロックに分割することで行います。" 6477 6478#: ../../rst/user_guide/playbooks_filters.rst:1150 6479msgid "The example above will parse the output of ``show interface`` into a list of hashes." 6480msgstr "上の例では、``show interface`` の出力を解析して、ハッシュのリストを作成します。" 6481 6482#: ../../rst/user_guide/playbooks_filters.rst:1153 6483msgid "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::" 6484msgstr "ネットワークフィルターは、TextFSM ライブラリーを使用して CLI コマンドの出力の解析もサポートします。TextFSM で CLI 出力を解析するには、以下のフィルターを使用します。" 6485 6486#: ../../rst/user_guide/playbooks_filters.rst:1159 6487msgid "Use of the TextFSM filter requires the TextFSM library to be installed." 6488msgstr "TextFSM フィルターを使用するには、TextFSM ライブラリーをインストールする必要があります。" 6489 6490#: ../../rst/user_guide/playbooks_filters.rst:1162 6491msgid "Network XML filters" 6492msgstr "ネットワーク XML フィルター" 6493 6494#: ../../rst/user_guide/playbooks_filters.rst:1166 6495msgid "To convert the XML output of a network device command into structured JSON output, use the ``parse_xml`` filter::" 6496msgstr "ネットワークデバイスコマンドの XML 出力を構造化された JSON 出力に変換するには、``parse_xml`` フィルターを使用します。" 6497 6498#: ../../rst/user_guide/playbooks_filters.rst:1171 6499msgid "The ``parse_xml`` filter will load the spec file and pass the command output through formatted as JSON." 6500msgstr "``parse_xml`` フィルターは、spec ファイルを読み込み、JSON としてフォーマットされたコマンド出力を渡します。" 6501 6502#: ../../rst/user_guide/playbooks_filters.rst:1174 6503msgid "The spec file should be valid formatted YAML. It defines how to parse the XML output and return JSON data." 6504msgstr "仕様ファイルは有効な YAML 形式である必要があります。XML 出力を解析し、JSON データを返す方法を定義します。" 6505 6506#: ../../rst/user_guide/playbooks_filters.rst:1177 6507msgid "Below is an example of a valid spec file that will parse the output from the ``show vlan | display xml`` command." 6508msgstr "以下は、``show vlan | display xml`` コマンドの出力を解析するための有効な spec ファイルの例です。" 6509 6510#: ../../rst/user_guide/playbooks_filters.rst:1205 6511msgid "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." 6512msgstr "同じコマンドでも、鍵と値のディレクティブを使用することで、ハッシュに解析することができます。以下は、同じ ``show vlan | display xml`` コマンドを使用して出力をハッシュ値に解析する例です。" 6513 6514#: ../../rst/user_guide/playbooks_filters.rst:1233 6515msgid "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." 6516msgstr "``top`` の値は、XML ルートノードに対する相対的な XPath です。以下の XML 出力例では、``top`` の値は ``configuration/vlans/vlan`` であり、これはルートノード (<rpc-reply>) に対する相対的な XPath 式です。``top`` の値の ``configuration`` は最も外側のコンテナーノードであり、``vlan`` は最も内側のコンテナーノードです。" 6517 6518#: ../../rst/user_guide/playbooks_filters.rst:1239 6519msgid "``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``" 6520msgstr "``items`` は、ユーザー定義の名前を、要素を選択する XPath 式にマッピングするキーと値のペアのディクショナリーです。Xpath 式は、``top`` に含まれる XPath 値の値に対する相対値です。たとえば、spec ファイルの ``vlan_id`` はユーザー定義の名前で、その値 ``vlan-id`` は、``top`` に含まれる XPath の値に対する相対値です。" 6521 6522#: ../../rst/user_guide/playbooks_filters.rst:1244 6523msgid "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.::" 6524msgstr "XML タグの属性は、XPath 式を用いて抽出することができます。仕様書の ``state`` の値は、出力された XML の ``vlan`` タグの属性を取得するために使用される XPath 式です。" 6525 6526#: ../../rst/user_guide/playbooks_filters.rst:1260 6527msgid "For more information on supported XPath expressions, see `XPath Support <https://docs.python.org/2/library/xml.etree.elementtree.html#xpath-support>`_." 6528msgstr "サポートされる XPath 式の詳細は、「`XPath Support <https://docs.python.org/2/library/xml.etree.elementtree.html#xpath-support>`_」を参照してください。" 6529 6530#: ../../rst/user_guide/playbooks_filters.rst:1263 6531msgid "Network VLAN filters" 6532msgstr "ネットワーク VLAN フィルター" 6533 6534#: ../../rst/user_guide/playbooks_filters.rst:1267 6535msgid "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:" 6536msgstr "``vlan_parser`` フィルターを使用して、ソートされていない VLAN 整数のリストを、IOS のような VLAN リストのルールに従ってソートされた整数の文字列リストに変換します。このリストには以下のプロパティーがあります。" 6537 6538#: ../../rst/user_guide/playbooks_filters.rst:1270 6539msgid "Vlans are listed in ascending order." 6540msgstr "VLAN は昇順でリストされます。" 6541 6542#: ../../rst/user_guide/playbooks_filters.rst:1271 6543msgid "Three or more consecutive VLANs are listed with a dash." 6544msgstr "3 つ以上の連続した VLAN はダッシュ付きでリストされます。" 6545 6546#: ../../rst/user_guide/playbooks_filters.rst:1272 6547msgid "The first line of the list can be first_line_len characters long." 6548msgstr "リストの最初の行は、first_line_len 文字の長さになります。" 6549 6550#: ../../rst/user_guide/playbooks_filters.rst:1273 6551msgid "Subsequent list lines can be other_line_len characters." 6552msgstr "後続のリスト行は、other_line_len 文字になります。" 6553 6554#: ../../rst/user_guide/playbooks_filters.rst:1275 6555msgid "To sort a VLAN list::" 6556msgstr "VLAN リストをソートするには、以下を実行します。" 6557 6558#: ../../rst/user_guide/playbooks_filters.rst:1279 6559msgid "This example renders the following sorted list::" 6560msgstr "この例では、以下のソートリストを示しています。" 6561 6562#: ../../rst/user_guide/playbooks_filters.rst:1284 6563msgid "Another example Jinja template::" 6564msgstr "Jinja テンプレートの他の例::" 6565 6566#: ../../rst/user_guide/playbooks_filters.rst:1292 6567msgid "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." 6568msgstr "これにより、Cisco IOS タグ付きインターフェース上の VLAN リストを動的に生成することができます。インターフェースに必要な正確な VLAN の網羅的な生のリストを保存し、それを設定のために実際に生成されるであろう解析された IOS 出力と比較することができます。" 6569 6570#: ../../rst/user_guide/playbooks_filters.rst:1298 6571msgid "Encrypting and checksumming strings and passwords" 6572msgstr "文字列およびパスワードの暗号化およびチェックサム" 6573 6574#: ../../rst/user_guide/playbooks_filters.rst:1302 6575msgid "To get the sha1 hash of a string::" 6576msgstr "文字列の sha1 ハッシュを取得するには、次のようになります。" 6577 6578#: ../../rst/user_guide/playbooks_filters.rst:1307 6579msgid "To get the md5 hash of a string::" 6580msgstr "文字列の md5 ハッシュを取得するには、次のようになります。" 6581 6582#: ../../rst/user_guide/playbooks_filters.rst:1312 6583msgid "Get a string checksum::" 6584msgstr "文字列のチェックサムを取得します。" 6585 6586#: ../../rst/user_guide/playbooks_filters.rst:1317 6587msgid "Other hashes (platform dependent)::" 6588msgstr "その他のハッシュ (プラットフォームに依存)::" 6589 6590#: ../../rst/user_guide/playbooks_filters.rst:1321 6591msgid "To get a sha512 password hash (random salt)::" 6592msgstr "sha512 パスワードハッシュ (任意の salt) を取得するには、次のようになります。" 6593 6594#: ../../rst/user_guide/playbooks_filters.rst:1326 6595msgid "To get a sha256 password hash with a specific salt::" 6596msgstr "特定の salt を持つ sha256 パスワードハッシュを取得するには、次のようになります。" 6597 6598#: ../../rst/user_guide/playbooks_filters.rst:1331 6599msgid "An idempotent method to generate unique hashes per system is to use a salt that is consistent between runs::" 6600msgstr "システムごとに一意のハッシュを生成する冪等な方法は、実行間で一貫性のある salt を使用することです。" 6601 6602#: ../../rst/user_guide/playbooks_filters.rst:1340 6603msgid "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." 6604msgstr "利用可能なハッシュタイプは、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`` がインストールされていない場合のフォールバックとして使用されます。" 6605 6606#: ../../rst/user_guide/playbooks_filters.rst:1344 6607msgid "Some hash types allow providing a rounds parameter::" 6608msgstr "ハッシュタイプによっては、rounds パラメーターを指定できるものもあります。" 6609 6610#: ../../rst/user_guide/playbooks_filters.rst:1352 6611msgid "Manipulating text" 6612msgstr "テキストの操作" 6613 6614#: ../../rst/user_guide/playbooks_filters.rst:1354 6615msgid "Several filters work with text, including URLs, file names, and path names." 6616msgstr "いくつかのフィルターは、URL、ファイル名、パス名などのテキストを扱います。" 6617 6618#: ../../rst/user_guide/playbooks_filters.rst:1359 6619msgid "Adding comments to files" 6620msgstr "ファイルへのコメントの追加" 6621 6622#: ../../rst/user_guide/playbooks_filters.rst:1361 6623msgid "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::" 6624msgstr "``comment`` フィルターを使用すると、テンプレート内のテキストから、さまざまなコメントスタイルでファイル内にコメントを作成することができます。Ansible のデフォルトでは、``#`` を使用してコメント行を開始し、コメントテキストの上下に空白のコメント行を追加します。以下に例を示します。" 6625 6626#: ../../rst/user_guide/playbooks_filters.rst:1365 6627msgid "produces this output:" 6628msgstr "次の出力を生成します。" 6629 6630#: ../../rst/user_guide/playbooks_filters.rst:1373 6631msgid "Ansible offers styles for comments in C (``//...``), C block (``/*...*/``), Erlang (``%...``) and XML (``<!--...-->``)::" 6632msgstr "Ansibleでは、C (``//...``)、C ブロック (``/*...*/``)、Erlang (``%...``)、および XML (``<!--...-->``) のコメント用スタイルを提供しています。" 6633 6634#: ../../rst/user_guide/playbooks_filters.rst:1381 6635msgid "You can define a custom comment character. This filter::" 6636msgstr "カスタムのコメント文字を定義できます。このフィルターは、以下のようになります。" 6637 6638#: ../../rst/user_guide/playbooks_filters.rst:1385 6639msgid "produces:" 6640msgstr "生成:" 6641 6642#: ../../rst/user_guide/playbooks_filters.rst:1393 6643msgid "You can fully customize the comment style::" 6644msgstr "コメントスタイルを完全にカスタマイズすることもできます。" 6645 6646#: ../../rst/user_guide/playbooks_filters.rst:1397 6647msgid "That creates the following output:" 6648msgstr "これにより、以下の出力が作成されます。" 6649 6650#: ../../rst/user_guide/playbooks_filters.rst:1409 6651msgid "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:" 6652msgstr "フィルターは、Ansible 変数にも適用することもできます。たとえば、``ansible_managed`` 変数の出力をより読みやすくするために、``ansible.cfg`` ファイルの定義を以下のように変更します。" 6653 6654#: ../../rst/user_guide/playbooks_filters.rst:1423 6655msgid "and then use the variable with the `comment` filter::" 6656msgstr "次に、`comment` フィルターで変数を使用します。" 6657 6658#: ../../rst/user_guide/playbooks_filters.rst:1427 6659msgid "which produces this output:" 6660msgstr "これは、次の出力を生成します。" 6661 6662#: ../../rst/user_guide/playbooks_filters.rst:1441 6663msgid "URLEncode Variables" 6664msgstr "URLEncode 変数" 6665 6666#: ../../rst/user_guide/playbooks_filters.rst:1443 6667msgid "The ``urlencode`` filter quotes data for use in a URL path or query using UTF-8::" 6668msgstr "``urlencode`` フィルターは、URL パスを使用、または UTF-8 を使用したクエリーで使用するデータを引用します。" 6669 6670#: ../../rst/user_guide/playbooks_filters.rst:1449 6671msgid "Splitting URLs" 6672msgstr "URL の分割" 6673 6674#: ../../rst/user_guide/playbooks_filters.rst:1453 6675msgid "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::" 6676msgstr "``urlsplit`` フィルターは、URL からフラグメント、ホスト名、netloc、パスワード、パス、ポート、クエリー、スキーム、およびユーザー名を抽出します。引数がない場合は、すべてのフィールドのディクショナリーを返します。" 6677 6678#: ../../rst/user_guide/playbooks_filters.rst:1497 6679msgid "Searching strings with regular expressions" 6680msgstr "正規表現を使用した文字列の検索" 6681 6682#: ../../rst/user_guide/playbooks_filters.rst:1499 6683msgid "To search in a string or extract parts of a string with a regular expression, use the ``regex_search`` filter::" 6684msgstr "文字列の検索または正規表現で文字列の部分を抽出するには、``regex_search`` フィルターを使用します。" 6685 6686#: ../../rst/user_guide/playbooks_filters.rst:1522 6687msgid "To extract all occurrences of regex matches in a string, use the ``regex_findall`` filter::" 6688msgstr "文字列の中にある正規表現の一致のすべての出現箇所を抽出するには、``regex_findall`` フィルターを使用します。" 6689 6690#: ../../rst/user_guide/playbooks_filters.rst:1533 6691msgid "To replace text in a string with regex, use the ``regex_replace`` filter::" 6692msgstr "文字列のテキストを正規表現に置き換えるには、``regex_replace`` フィルターを使用します。" 6693 6694#: ../../rst/user_guide/playbooks_filters.rst:1556 6695msgid "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::" 6696msgstr "文字列全体に一致させたい場合に ``*`` を使用する場合は、必ず開始/終了アンカーで正規表現を折り返すようにしてください。たとえば、``^(.*)$`` は常に 1 つの結果のみに一致しますが、``(.*)`` はいくつかの Python バージョンでは文字列全体と最後に空の文字列に一致します。つまり 2 つの置換を行います。" 6697 6698#: ../../rst/user_guide/playbooks_filters.rst:1577 6699msgid "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 (``\\\\``)." 6700msgstr "ansible 2.0 より前のバージョンでは、(単純な「key=value」引数ではなく) ``regex_replace`` フィルターを YAML 引数内の変数に使用する場合は、後方参照 (たとえば ``\\\\1``) をバックスラッシュ 2 つ (``\\\\``) ではなく 4 つ (``\\\\\\\\``) でエスケープする必要がありました。" 6701 6702#: ../../rst/user_guide/playbooks_filters.rst:1581 6703msgid "To escape special characters within a standard Python regex, use the ``regex_escape`` filter (using the default ``re_type='python'`` option)::" 6704msgstr "標準の Python 正規表現内で特殊文字をエスケープするには、``regex_escape`` フィルターを使用します (デフォルトの ``re_type='python'`` オプションを使用)。" 6705 6706#: ../../rst/user_guide/playbooks_filters.rst:1588 6707msgid "To escape special characters within a POSIX basic regex, use the ``regex_escape`` filter with the ``re_type='posix_basic'`` option::" 6708msgstr "POSIX 基本正規表現内で特殊文字をエスケープするには、``regex_escape`` フィルターを ``re_type='posix_basic'`` オプションを付けて使用します。" 6709 6710#: ../../rst/user_guide/playbooks_filters.rst:1595 6711msgid "Managing file names and path names" 6712msgstr "ファイル名とパス名の管理" 6713 6714#: ../../rst/user_guide/playbooks_filters.rst:1597 6715msgid "To get the last name of a file path, like 'foo.txt' out of '/etc/asdf/foo.txt'::" 6716msgstr "「/etc/asdf/foo.txt」の「foo.txt」のように、ファイルパスの最後の名前を取得するには、以下を指定します。" 6717 6718#: ../../rst/user_guide/playbooks_filters.rst:1601 6719msgid "To get the last name of a windows style file path (new in version 2.0)::" 6720msgstr "ウィンドウスタイルのファイルパスの最後の名前を取得するには、以下を指定します (バージョン 2.0 の新機能)。" 6721 6722#: ../../rst/user_guide/playbooks_filters.rst:1605 6723msgid "To separate the windows drive letter from the rest of a file path (new in version 2.0)::" 6724msgstr "Windows ドライブの文字を残りのファイルパスから分離するには、以下を指定します (バージョン 2.0 の新機能)。" 6725 6726#: ../../rst/user_guide/playbooks_filters.rst:1609 6727msgid "To get only the windows drive letter::" 6728msgstr "Windows ドライブの文字のみを取得するには、以下を指定します。" 6729 6730#: ../../rst/user_guide/playbooks_filters.rst:1613 6731msgid "To get the rest of the path without the drive letter::" 6732msgstr "ドライブ文字なしで残りのパスを取得するには、以下を指定します。" 6733 6734#: ../../rst/user_guide/playbooks_filters.rst:1617 6735msgid "To get the directory from a path::" 6736msgstr "パスからディレクトリーを取得するには、以下を指定します。" 6737 6738#: ../../rst/user_guide/playbooks_filters.rst:1621 6739msgid "To get the directory from a windows path (new version 2.0)::" 6740msgstr "Windows パスからディレクトリーを取得するには、以下を指定します (バージョン 2.0 の新機能)。" 6741 6742#: ../../rst/user_guide/playbooks_filters.rst:1625 6743msgid "To expand a path containing a tilde (`~`) character (new in version 1.5)::" 6744msgstr "チルド (`~`) 文字を含むパスを拡張するには、以下を指定します (バージョン 1.5 の新機能)。" 6745 6746#: ../../rst/user_guide/playbooks_filters.rst:1629 6747msgid "To expand a path containing environment variables::" 6748msgstr "環境変数を含むパスを拡張するには、以下を指定します。" 6749 6750#: ../../rst/user_guide/playbooks_filters.rst:1633 6751msgid "`expandvars` expands local variables; using it on remote paths can lead to errors." 6752msgstr "`expandvars` は、ローカル変数を拡張します。リモートパスで使用するとエラーが発生する可能性があります。" 6753 6754#: ../../rst/user_guide/playbooks_filters.rst:1637 6755msgid "To get the real path of a link (new in version 1.8)::" 6756msgstr "リンクの実際のパスを取得するには、以下を指定します (バージョン 1.8 の新機能)。" 6757 6758#: ../../rst/user_guide/playbooks_filters.rst:1641 6759msgid "To get the relative path of a link, from a start point (new in version 1.7)::" 6760msgstr "リンクの相対パスを取得するには、開始点から以下を行います (バージョン 1.7 の新機能)。" 6761 6762#: ../../rst/user_guide/playbooks_filters.rst:1645 6763msgid "To get the root and extension of a path or file name (new in version 2.0)::" 6764msgstr "パスまたはファイル名のルートおよび拡張を取得するには、以下を指定します (バージョン 2.0 の新機能)。" 6765 6766#: ../../rst/user_guide/playbooks_filters.rst:1650 6767msgid "The ``splitext`` filter always returns a pair of strings. The individual components can be accessed by using the ``first`` and ``last`` filters::" 6768msgstr "``splitext`` フィルターは、常に文字列のペアを返します。個々のコンポーネントは、``first`` フィルターおよび ``last`` フィルターを使用してアクセスできます。" 6769 6770#: ../../rst/user_guide/playbooks_filters.rst:1658 6771msgid "To join one or more path components::" 6772msgstr "1 つ以上のパスコンポーネントを結合するには、以下を実行します。" 6773 6774#: ../../rst/user_guide/playbooks_filters.rst:1665 6775msgid "Manipulating strings" 6776msgstr "文字列の操作" 6777 6778#: ../../rst/user_guide/playbooks_filters.rst:1667 6779msgid "To add quotes for shell usage::" 6780msgstr "シェルの使用に引用符を追加するには、以下を行います。" 6781 6782#: ../../rst/user_guide/playbooks_filters.rst:1672 6783msgid "To concatenate a list into a string::" 6784msgstr "リストを文字列に連結するには、以下を指定します。" 6785 6786#: ../../rst/user_guide/playbooks_filters.rst:1676 6787msgid "To split a sting into a list::" 6788msgstr "文字列をリストに分割するには、以下を実行します。" 6789 6790#: ../../rst/user_guide/playbooks_filters.rst:1682 6791msgid "To work with Base64 encoded strings::" 6792msgstr "Base64 でエンコードされた文字列を使用するには、以下を指定します。" 6793 6794#: ../../rst/user_guide/playbooks_filters.rst:1687 6795msgid "As of version 2.6, you can define the type of encoding to use, the default is ``utf-8``::" 6796msgstr "バージョン 2.6 以降では、使用するエンコーディングのタイプを定義できます。デフォルトは ``utf-8`` です。" 6797 6798#: ../../rst/user_guide/playbooks_filters.rst:1692 6799msgid "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." 6800msgstr "``string`` フィルターは Python 2 でのみ必要です。エンコードするテキストがユニコード文字列であることを確認します。b64encode より前のフィルターを使用しないと、誤った値がエンコードされます。" 6801 6802#: ../../rst/user_guide/playbooks_filters.rst:1697 6803msgid "Managing UUIDs" 6804msgstr "UUID の管理" 6805 6806#: ../../rst/user_guide/playbooks_filters.rst:1699 6807msgid "To create a namespaced UUIDv5::" 6808msgstr "namespace を使用した UUIDv5 を作成するには、以下を実行します。" 6809 6810#: ../../rst/user_guide/playbooks_filters.rst:1705 6811msgid "To create a namespaced UUIDv5 using the default Ansible namespace '361E6D51-FAEC-444A-9079-341386DA8E2E'::" 6812msgstr "デフォルトの Ansible 名前空間「361E6D51-FAEC-444A-9079-341386DA8E2E2E」を使用して名前空間を指定した UUIDv5 を作成するには、以下を実行します。" 6813 6814#: ../../rst/user_guide/playbooks_filters.rst:1711 6815msgid "To make use of one attribute from each item in a list of complex variables, use the :func:`Jinja2 map filter <jinja2:map>`::" 6816msgstr "複雑な変数のリストで、各項目から 1 つの属性を使用するには、:func:`Jinja2 map filter <jinja2:map>` を使用します。" 6817 6818#: ../../rst/user_guide/playbooks_filters.rst:1717 6819msgid "Handling dates and times" 6820msgstr "日付と時刻の処理" 6821 6822#: ../../rst/user_guide/playbooks_filters.rst:1719 6823msgid "To get a date object from a string use the `to_datetime` filter::" 6824msgstr "文字列から日付オブジェクトを取得するには、`to_datetime` フィルターを使用します。" 6825 6826#: ../../rst/user_guide/playbooks_filters.rst:1731 6827msgid "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." 6828msgstr "Python 日付形式の文字列を使用する形式コードの全一覧は、https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior を参照してください。" 6829 6830#: ../../rst/user_guide/playbooks_filters.rst:1735 6831msgid "To format a date using a string (like with the shell date command), use the \"strftime\" filter::" 6832msgstr "文字列 (shell date コマンドの場合のように) を使用して日付をフォーマットするには、「strftime」フィルターを使用します。" 6833 6834#: ../../rst/user_guide/playbooks_filters.rst:1753 6835msgid "To get all string possibilities, check https://docs.python.org/3/library/time.html#time.strftime" 6836msgstr "すべての文字列の可能性を取得するには、https://docs.python.org/3/library/time.html#time.strftime を確認します。" 6837 6838#: ../../rst/user_guide/playbooks_filters.rst:1756 6839msgid "Getting Kubernetes resource names" 6840msgstr "Kubernetes リソース名の取得" 6841 6842#: ../../rst/user_guide/playbooks_filters.rst:1760 6843msgid "These filters have migrated to the `kuberernetes.core <https://galaxy.ansible.com/kubernetes/core>`_ collection. Follow the installation instructions to install that collection." 6844msgstr "これらのフィルターは `kuberernetes.core <https://galaxy.ansible.com/kubernetes/core>`_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" 6845 6846#: ../../rst/user_guide/playbooks_filters.rst:1762 6847msgid "Use the \"k8s_config_resource_name\" filter to obtain the name of a Kubernetes ConfigMap or Secret, including its hash::" 6848msgstr "「k8s_config_resource_name」フィルターを使用して、Kubernetes ConfigMap または Secret の名前を、そのハッシュを含めて取得します。" 6849 6850#: ../../rst/user_guide/playbooks_filters.rst:1767 6851msgid "This can then be used to reference hashes in Pod specifications::" 6852msgstr "これは、Pod 仕様のハッシュを参照するために使用できます。" 6853 6854#: ../../rst/user_guide/playbooks_filters.rst:1793 6855#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:726 6856#: ../../rst/user_guide/playbooks_loops.rst:432 6857#: ../../rst/user_guide/playbooks_strategies.rst:213 6858#: ../../rst/user_guide/playbooks_variables.rst:449 6859#: ../../rst/user_guide/windows_faq.rst:244 6860#: ../../rst/user_guide/windows_setup.rst:567 6861msgid ":ref:`about_playbooks`" 6862msgstr ":ref:`about_playbooks`" 6863 6864#: ../../rst/user_guide/playbooks_filters.rst:1799 6865#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:734 6866#: ../../rst/user_guide/playbooks_lookups.rst:32 6867#: ../../rst/user_guide/playbooks_reuse.rst:197 6868#: ../../rst/user_guide/playbooks_reuse_includes.rst:23 6869#: ../../rst/user_guide/playbooks_reuse_roles.rst:609 6870#: ../../rst/user_guide/playbooks_templating.rst:46 6871#: ../../rst/user_guide/playbooks_tests.rst:394 6872#: ../../rst/user_guide/playbooks_variables.rst:455 6873msgid ":ref:`playbooks_loops`" 6874msgstr ":ref:`playbooks_loops`" 6875 6876#: ../../rst/user_guide/playbooks_filters.rst:1800 6877#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:735 6878#: ../../rst/user_guide/playbooks_lookups.rst:33 6879#: ../../rst/user_guide/playbooks_templating.rst:47 6880#: ../../rst/user_guide/playbooks_tests.rst:395 6881#: ../../rst/user_guide/playbooks_variables.rst:456 6882msgid "Looping in playbooks" 6883msgstr "Playbook でのループ" 6884 6885#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:6 6886msgid "ipaddr filter" 6887msgstr "ipaddr フィルター" 6888 6889#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:10 6890msgid "``ipaddr()`` is a Jinja2 filter designed to provide an interface to the `netaddr`_ Python package from within Ansible. It can operate on strings or lists of items, test various data to check if they are valid IP addresses, and manipulate the input data to extract requested information. ``ipaddr()`` works with both IPv4 and IPv6 addresses in various forms. There are also additional functions available to manipulate IP subnets and MAC addresses." 6891msgstr "``ipaddr()`` は、`netaddr`_ Python パッケージへのインターフェースを Ansible 内から提供するように設計された Jinja2 フィルターです。文字列や項目のリストを操作したり、さまざまなデータが有効な IP アドレスであるかどうかをテストしたり、入力データを操作して要求された情報を抽出したりすることができます。``ipaddr()`` は、さまざまな形式の IPv4 と IPv6 の両方のアドレスを扱います。また、IP サブネットや MAC アドレスを操作するための追加機能も用意されています。" 6892 6893#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:19 6894msgid "The ``ipaddr()`` filter migrated to the `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ collection. Follow the installation instructions to install that collection." 6895msgstr "``ipaddr()`` フィルターは `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。" 6896 6897#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:21 6898msgid "To use this filter in Ansible, you need to install the `netaddr`_ Python library on a computer on which you use Ansible (it is not required on remote hosts). It can usually be installed with either your system package manager or using ``pip``::" 6899msgstr "このフィルターを Ansible で使用するには、Ansible を使用するコンピューターに `netaddr`_ Python ライブラリーをインストールする必要があります (リモートホストでは必要ありません)。通常は、システムのパッケージマネージャーか、``pip`` を使用してインストールできます。" 6900 6901#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:34 6902#: ../../rst/user_guide/playbooks_roles.rst:7 6903#: ../../rst/user_guide/windows_dsc.rst:5 6904#: ../../rst/user_guide/windows_usage.rst:9 6905#: ../../rst/user_guide/windows_winrm.rst:9 6906msgid "Topics" 6907msgstr "トピック" 6908 6909#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:37 6910msgid "Basic tests" 6911msgstr "基本的なテスト" 6912 6913#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:39 6914msgid "``ipaddr()`` is designed to return the input value if a query is True, and ``False`` if a query is False. This way it can be easily used in chained filters. To use the filter, pass a string to it:" 6915msgstr "``ipaddr()`` は、クエリーが True の場合は入力値を返し、False の場合は``False`` を返すように設計されています。これにより、連鎖したフィルターで簡単に使うことができます．このフィルターを使用するには、文字列を渡します。" 6916 6917#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:47 6918msgid "You can also pass the values as variables::" 6919msgstr "変数として値を渡すこともできます。" 6920 6921#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:51 6922msgid "Here are some example test results of various input strings::" 6923msgstr "以下は、さまざまな入力文字列のテスト結果の例です。" 6924 6925#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:69 6926msgid "Sometimes you need either IPv4 or IPv6 addresses. To filter only for a particular type, ``ipaddr()`` filter has two \"aliases\", ``ipv4()`` and ``ipv6()``." 6927msgstr "IPv4 アドレスまたは IPv6 アドレスのいずれかが必要になる場合があります。特定のタイプに対してフィルターで絞り込むため、``ipaddr()`` フィルターには ``ipv4()`` と ``ipv6()`` という 2 つの「エイリアス」があります。" 6928 6929#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:72 6930msgid "Example use of an IPv4 filter::" 6931msgstr "IPv4 フィルターの使用例:" 6932 6933#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:76 6934msgid "A similar example of an IPv6 filter::" 6935msgstr "同様の、IPv6 フィルターの使用例:" 6936 6937#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:80 6938msgid "Here's some example test results to look for IPv4 addresses::" 6939msgstr "以下は、IPv4 アドレスを検索するテスト結果の例です。" 6940 6941#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:88 6942msgid "And the same data filtered for IPv6 addresses::" 6943msgstr "IPv6 アドレスにフィルターが設定されたデータ:" 6944 6945#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:98 6946msgid "Filtering lists" 6947msgstr "リストへのフィルター設定" 6948 6949#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:100 6950msgid "You can filter entire lists - ``ipaddr()`` will return a list with values valid for a particular query::" 6951msgstr "リスト全体にフィルターを設定できます。``ipaddr()`` は、特定のクエリーに有効な値を持つリストを返します。" 6952 6953#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:117 6954msgid "Wrapping IPv6 addresses in [ ] brackets" 6955msgstr "[ ] 括弧で IPv6 アドレスのラッピング" 6956 6957#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:119 6958msgid "Some configuration files require IPv6 addresses to be \"wrapped\" in square brackets (``[ ]``). To accomplish that, you can use the ``ipwrap()`` filter. It will wrap all IPv6 addresses and leave any other strings intact::" 6959msgstr "一部の設定ファイルでは、IPv6 アドレスを角括弧 (``[ ]``) で「囲む」必要があります。これを行うには、``ipwrap()`` フィルターを使用することができます。これは、すべての IPv6 アドレスを囲み、その他の文字列はそのまま残します。" 6960 6961#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:126 6962msgid "As you can see, ``ipwrap()`` did not filter out non-IP address values, which is usually what you want when for example you are mixing IP addresses with hostnames. If you still want to filter out all non-IP address values, you can chain both filters together::" 6963msgstr "ご覧のように、``ipwrap()`` は、IP アドレス以外の値にフィルターを設定して除外していません。これは、IP アドレスとホスト名が混在している場合などに必要となるものです。それでもなお、IP アドレス以外のすべての値にフィルターを設定して除外したい場合は、両方のフィルターを連鎖させることができます。" 6964 6965#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:136 6966msgid "Basic queries" 6967msgstr "基本クエリー" 6968 6969#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:138 6970msgid "You can provide a single argument to each ``ipaddr()`` filter. The filter will then treat it as a query and return values modified by that query. Lists will contain only values that you are querying for." 6971msgstr "``ipaddr()`` の各フィルターには、1 つの引数を指定することができます。フィルターはそれをクエリーとして扱い、そのクエリーで変更された値を返します。リストには、クエリーで指定した値のみが含まれます。" 6972 6973#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:142 6974msgid "Types of queries include:" 6975msgstr "クエリーの種類は次のとおりです。" 6976 6977#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:144 6978msgid "query by name: ``ansible.netcommon.ipaddr('address')``, ``ansible.netcommon.ipv4('network')``;" 6979msgstr "名前によるクエリー: ``ansible.netcommon.ipaddr('address')``、``ansible.netcommon.ipv4('network')``" 6980 6981#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:145 6982msgid "query by CIDR range: ``ansible.netcommon.ipaddr('192.168.0.0/24')``, ``ansible.netcommon.ipv6('2001:db8::/32')``;" 6983msgstr "CIDR 範囲によるクエリー: ``ansible.netcommon.ipaddr('192.168.0.0/24')``、``ansible.netcommon.ipv6('2001:db8::/32')``" 6984 6985#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:146 6986msgid "query by index number: ``ansible.netcommon.ipaddr('1')``, ``ansible.netcommon.ipaddr('-1')``;" 6987msgstr "インデックス番号によるクエリー: ``ansible.netcommon.ipaddr('1')``、``ansible.netcommon.ipaddr('-1')``" 6988 6989#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:148 6990msgid "If a query type is not recognized, Ansible will raise an error." 6991msgstr "クエリータイプが認識されないと、Ansible はエラーを発生させます。" 6992 6993#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:152 6994msgid "Getting information about hosts and networks" 6995msgstr "ホストおよびネットワークに関する情報の取得" 6996 6997#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:154 6998#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:357 6999msgid "Here's our test list again::" 7000msgstr "ここでは、テストリストを再度使用します。" 7001 7002#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:159 7003msgid "Let's take the list above and get only those elements that are host IP addresses and not network ranges::" 7004msgstr "上のリストから、ネットワーク範囲ではなくホスト IP アドレスの要素だけを取り出してみましょう。" 7005 7006#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:165 7007msgid "As you can see, even though some values had a host address with a CIDR prefix, they were dropped by the filter. If you want host IP addresses with their correct CIDR prefixes (as is common with IPv6 addressing), you can use the ``ipaddr('host')`` filter::" 7008msgstr "ご覧のように、CIDR プレフィックスを持つホストアドレスを持つ値があっても、フィルターによって破棄されています。正しい CIDR プレフィックスを持つホスト IP アドレスが必要な場合 (IPv6 アドレスでは一般的) は、``ipaddr('host')`` フィルターを使用できます。" 7009 7010#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:173 7011msgid "Filtering by IP address type also works::" 7012msgstr "IP アドレスタイプによるフィルタリングも機能します。" 7013 7014#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:181 7015msgid "You can check if IP addresses or network ranges are accessible on a public Internet, or if they are in private networks::" 7016msgstr "IP アドレスやネットワーク範囲が、パブリックなインターネット上でアクセス可能か、プライベートなネットワーク上にあるかどうかを確認することができます。" 7017 7018#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:190 7019msgid "You can check which values are specifically network ranges::" 7020msgstr "特定のネットワーク範囲の値を確認できます。" 7021 7022#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:195 7023msgid "You can also check how many IP addresses can be in a certain range::" 7024msgstr "特定の範囲内にある IP アドレスの数を確認することもできます。" 7025 7026#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:200 7027msgid "By specifying a network range as a query, you can check if a given value is in that range::" 7028msgstr "クエリーにネットワークの範囲を指定することで、指定した値がその範囲内にあるかどうかを調べることができます。" 7029 7030#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:206 7031msgid "If you specify a positive or negative integer as a query, ``ipaddr()`` will treat this as an index and will return the specific IP address from a network range, in the 'host/prefix' format::" 7032msgstr "正または負の整数をクエリーとして指定すると、``ipaddr()`` はこれをインデックスとして扱い、ネットワークの範囲から特定の IP アドレスを「host/prefix」形式で返します。" 7033 7034#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:222 7035msgid "You can also select IP addresses from a range by their index, from the start or end of the range::" 7036msgstr "また、範囲内の IP アドレスを、範囲の最初または最後から、インデックスで選択することもできます。" 7037 7038#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:238 7039msgid "Getting information from host/prefix values" 7040msgstr "ホスト/プレフィックスの値からの情報の取得" 7041 7042#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:240 7043msgid "You frequently use a combination of IP addresses and subnet prefixes (\"CIDR\"), this is even more common with IPv6. The ``ansible.netcommon.ipaddr()`` filter can extract useful data from these prefixes." 7044msgstr "IP アドレスとサブネットプレフィックス (「CIDR」) の組み合わせが頻繁に使用されます。これは IPv6 ではより一般的です。``ansible.netcommon.ipaddr()`` フィルターは、これらのプレフィックスから有用なデータを抽出できます。" 7045 7046#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:244 7047msgid "Here's an example set of two host prefixes (with some \"control\" values)::" 7048msgstr "以下は、ホストプレフィックス (「制御」の値を含む) の例です。" 7049 7050#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:248 7051msgid "First, let's make sure that we only work with correct host/prefix values, not just subnets or single IP addresses::" 7052msgstr "まず、サブネットや単一の IP アドレスではなく、正しいホスト/プレフィックスの値のみを扱うことを確認しましょう。" 7053 7054#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:254 7055msgid "In Debian-based systems, the network configuration stored in the ``/etc/network/interfaces`` file uses a combination of IP address, network address, netmask and broadcast address to configure an IPv4 network interface. We can get these values from a single 'host/prefix' combination:" 7056msgstr "Debian ベースのシステムでは、``/etc/network/interfaces`` ファイルに保存されているネットワーク設定では、IP アドレス、ネットワークアドレス、ネットマスク、ブロードキャストアドレスの組み合わせを使用して、IPv4 ネットワークインターフェースを設定します。これらの値は、1つの「host/prefix」の組み合わせから得ることができます。" 7057 7058#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:273 7059msgid "In the above example, we needed to handle the fact that values were stored in a list, which is unusual in IPv4 networks, where only a single IP address can be set on an interface. However, IPv6 networks can have multiple IP addresses set on an interface:" 7060msgstr "上の例では、値がリストに格納されていることを処理する必要がありました。これは、1 つのインターフェースに 1 つの IP アドレスしか設定できない IPv4 ネットワークでは珍しいことです。しかし、IPv6 ネットワークでは、1 つのインターフェースに複数の IP アドレスを設定することができます。" 7061 7062#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:295 7063msgid "If needed, you can extract subnet and prefix information from the 'host/prefix' value:" 7064msgstr "必要な場合は、「host/prefix」値からサブネットおよびプレフィックス情報を抽出できます。" 7065 7066#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:306 7067msgid "Converting subnet masks to CIDR notation" 7068msgstr "サブネットマスクの CIDR 表記への変換" 7069 7070#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:308 7071msgid "Given a subnet in the form of network address and subnet mask, the ``ipaddr()`` filter can convert it into CIDR notation. This can be useful for converting Ansible facts gathered about network configuration from subnet masks into CIDR format::" 7072msgstr "ネットワークアドレスとサブネットマスクの形式でサブネットが与えられると、``ipaddr()`` フィルターはそれを CIDR 表記に変換することができます。これは、サブネットマスクからネットワーク構成について収集した Ansible のファクトを CIDR 形式に変換する際に便利です。" 7073 7074#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:323 7075msgid "First concatenate the network and netmask::" 7076msgstr "最初に、ネットワークとネットマスクを連結します。" 7077 7078#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:328 7079msgid "This result can be converted to canonical form with ``ipaddr()`` to produce a subnet in CIDR format::" 7080msgstr "これにより、``ipaddr()`` で正則形式に変換して、CIDR 形式でサブネットを生成できます。" 7081 7082#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:338 7083msgid "Getting information about the network in CIDR notation" 7084msgstr "CIDR 表記でのネットワーク情報の取得" 7085 7086#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:340 7087msgid "Given an IP address, the ``ipaddr()`` filter can produce the network address in CIDR notation. This can be useful when you want to obtain the network address from the IP address in CIDR format." 7088msgstr "IP アドレスを指定すると、``ipaddr()`` フィルターは、CIDR 表記のネットワークアドレスを生成することができます。これは、CIDR 形式の IP アドレスからネットワークアドレスを取得したい場合に便利です。" 7089 7090#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:343 7091msgid "Here's an example of IP address::" 7092msgstr "以下は IP アドレスの例です。" 7093 7094#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:348 7095msgid "This can be used to obtain the network address in CIDR notation format::" 7096msgstr "これは、CIDR 表記形式でネットワークアドレスを取得するのに使用できます。" 7097 7098#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:355 7099msgid "IP address conversion" 7100msgstr "IP アドレス変換" 7101 7102#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:362 7103msgid "You can convert IPv4 addresses into IPv6 addresses::" 7104msgstr "IPv4 アドレスを IPv6 アドレスに変換できます。" 7105 7106#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:367 7107msgid "Converting from IPv6 to IPv4 works very rarely::" 7108msgstr "IPv6 から IPv4 への変換はほとんど機能しません。" 7109 7110#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:372 7111msgid "But we can make a double conversion if needed::" 7112msgstr "ただし、必要に応じて二重変換を行うことができます。" 7113 7114#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:377 7115msgid "You can convert IP addresses to integers, the same way that you can convert integers into IP addresses::" 7116msgstr "整数を IP アドレスに変換するのと同じ方法で、IP アドレスを整数に変換することができます。" 7117 7118#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:383 7119msgid "You can convert IPv4 address to `Hexadecimal notation <https://en.wikipedia.org/wiki/Hexadecimal>`_ with optional delimiter::" 7120msgstr "任意の区切り文字を使用して、IPv4 アドレスを `16 進表記 <https://en.wikipedia.org/wiki/Hexadecimal>`_ に変換できます。" 7121 7122#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:390 7123msgid "You can convert IP addresses to PTR records::" 7124msgstr "IP アドレスを PTR レコードに変換できます。" 7125 7126#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:403 7127msgid "Converting IPv4 address to a 6to4 address" 7128msgstr "IPv4 アドレスの 6to4 アドレスへの変換" 7129 7130#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:405 7131msgid "A `6to4`_ tunnel is a way to access the IPv6 Internet from an IPv4-only network. If you have a public IPv4 address, you can automatically configure its IPv6 equivalent in the ``2002::/16`` network range. After conversion you will gain access to a ``2002:xxxx:xxxx::/48`` subnet which could be split into 65535 ``/64`` subnets if needed." 7132msgstr "`6to4`_ トンネルは、IPv4 のみのネットワークから IPv6 インターネットにアクセスするための手段です。パブリック IPv4 アドレスがある場合は、その IPv6 相当のアドレスを ``2002::/16`` ネットワーク範囲内に自動的に設定することができます。変換後は、``2002:xxxx:xxxx::/48`` サブネットへのアクセスが可能になり、必要に応じて 65535 ``/64`` サブネットに分割することができます。" 7133 7134#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:411 7135msgid "To convert your IPv4 address, just send it through the ``'6to4'`` filter. It will be automatically converted to a router address (with a ``::1/48`` host address)::" 7136msgstr "IPv4 アドレスを変換するには、``'6to4'`` フィルターに通すだけです。自動的にルーターアドレス (ホストアドレスは ``::1/48``) に変換されます。" 7137 7138#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:421 7139msgid "Finding IP addresses within a range" 7140msgstr "範囲内の IP アドレスの検索" 7141 7142#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:423 7143msgid "To find usable IP addresses within an IP range, try these ``ipaddr`` filters:" 7144msgstr "IP 範囲内で使用可能な IP アドレスを見つけるには、以下の ``ipaddr`` フィルターを試行します。" 7145 7146#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:425 7147msgid "To find the next usable IP address in a range, use ``next_usable`` ::" 7148msgstr "範囲内の次の使用可能な IP アドレスを見つけるには、``next_usable`` を使用します。" 7149 7150#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:430 7151msgid "To find the last usable IP address from a range, use ``last_usable``::" 7152msgstr "範囲から最後の使用可能な IP アドレスを見つけるには、``last_usable`` を使用します。" 7153 7154#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:435 7155msgid "To find the available range of IP addresses from the given network address, use ``range_usable``::" 7156msgstr "指定したネットワークアドレスから利用可能な IP アドレスの範囲を検索するには、``range_usable`` を使用します。" 7157 7158#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:440 7159msgid "To find the peer IP address for a point to point link, use ``peer``::" 7160msgstr "ポイントツーポイントのリンクのピア IP アドレスを検索するには、``peer`` を使用します。" 7161 7162#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:447 7163msgid "To return the nth ip from a network, use the filter ``nthhost``::" 7164msgstr "ネットワークから nth ip に戻るには、フィルター ``nthhost`` を使用します。" 7165 7166#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:452 7167msgid "``nthhost`` also supports a negative value::" 7168msgstr "``nthhost`` は、負の値もサポートします。" 7169 7170#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:457 7171msgid "To find the next nth usable IP address in relation to another within a range, use ``next_nth_usable`` In the example, ``next_nth_usable`` returns the second usable IP address for the given IP range::" 7172msgstr "範囲内の別の IP との関係で、次の n 番目に使用可能な IP アドレスを見つけるには、``next_nth_usable`` を使用します。この例では、``next_nth_usable`` が、指定の IP 範囲に 2 番目の使用可能な IP アドレスを返します。" 7173 7174#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:463 7175msgid "If there is no usable address, it returns an empty string::" 7176msgstr "使用可能なアドレスがない場合は、空の文字列を返します。" 7177 7178#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:468 7179msgid "Just like ``next_nth_ansible``, you have ``previous_nth_usable`` to find the previous usable address::" 7180msgstr "``next_nth_ansible`` と同様に ``previous_nth_usable`` があり、以前の使用可能なアドレスを見つけます。" 7181 7182#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:475 7183msgid "Testing if a address belong to a network range" 7184msgstr "アドレスがネットワーク範囲に属するかどうかのテスト" 7185 7186#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:477 7187msgid "The ``network_in_usable`` filter returns whether an address passed as an argument is usable in a network. Usable addresses are addresses that can be assigned to a host. The network ID and the broadcast address are not usable addresses.::" 7188msgstr "``network_in_usable`` フィルターは、引数として渡されたアドレスがネットワーク上で使用可能かどうかを返します。使用可能なアドレスとは、ホストに割り当てることができるアドレスです。ネットワーク ID やブロードキャストアドレスは使用可能なアドレスではありません。" 7189 7190#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:490 7191msgid "The ``network_in_network`` filter returns whether an address or a network passed as argument is in a network.::" 7192msgstr "``network_in_network`` フィルターは、引数として渡されたアドレスまたはネットワークがネットワーク内にあるかどうかを返します。" 7193 7194#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:505 7195msgid "To check whether multiple addresses belong to a network, use the ``reduce_on_network`` filter::" 7196msgstr "複数のアドレスがネットワークに属するかどうかを確認するには、``reduce_on_network`` フィルターを使用します。" 7197 7198#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:512 7199msgid "IP Math" 7200msgstr "IP 計算" 7201 7202#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:516 7203msgid "The ``ipmath()`` filter can be used to do simple IP math/arithmetic." 7204msgstr "``ipmath()`` フィルターは、単純な IP 計算/演算をするのに使用できます。" 7205 7206#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:518 7207msgid "Here are a few simple examples::" 7208msgstr "以下は簡単な例です。" 7209 7210#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:552 7211msgid "Subnet manipulation" 7212msgstr "サブネット操作" 7213 7214#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:554 7215msgid "The ``ipsubnet()`` filter can be used to manipulate network subnets in several ways." 7216msgstr "``ipsubnet()`` フィルターは、さまざまな方法でネットワークサブネットを操作するのに使用できます。" 7217 7218#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:556 7219msgid "Here is an example IP address and subnet::" 7220msgstr "IP アドレスとサブネットの例を以下に示します。" 7221 7222#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:561 7223msgid "To check if a given string is a subnet, pass it through the filter without any arguments. If the given string is an IP address, it will be converted into a subnet::" 7224msgstr "特定の文字列がサブネットであるかどうかを確認するには、引数なしでフィルターを渡します。指定の文字列が IP アドレスの場合は、サブネットに変換されます。" 7225 7226#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:571 7227msgid "If you specify a subnet size as the first parameter of the ``ipsubnet()`` filter, and the subnet size is **smaller than the current one**, you will get the number of subnets a given subnet can be split into::" 7228msgstr "``ipsubnet()`` フィルターの最初のパラメーターにサブネットサイズを指定し、そのサブネットサイズが **現在のものより小さい場合**、指定されたサブネットが分割できるサブネットの数が得られます。" 7229 7230#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:578 7231msgid "The second argument of the ``ipsubnet()`` filter is an index number; by specifying it you can get a new subnet with the specified size::" 7232msgstr "``ipsubnet()`` フィルターの第 2 引数はインデックス番号で、これを指定することで、指定したサイズの新しいサブネットを得ることができます。" 7233 7234#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:597 7235msgid "If you specify an IP address instead of a subnet, and give a subnet size as the first argument, the ``ipsubnet()`` filter will instead return the biggest subnet that contains that given IP address::" 7236msgstr "サブネットの代わりに IP アドレスを指定し、第 1 引数にサブネットサイズを指定した場合、``ipsubnet()`` フィルターは、代わりに指定された IP アドレスを含む最大のサブネットを返します。" 7237 7238#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:604 7239msgid "By specifying an index number as a second argument, you can select smaller and smaller subnets::" 7240msgstr "第 2 引数にインデックス番号を指定することで、より小さなサブネットを選択することができます。" 7241 7242#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:623 7243msgid "By specifying another subnet as a second argument, if the second subnet includes the first, you can determine the rank of the first subnet in the second ::" 7244msgstr "別のサブネットを 2 番目の引数として指定することで、2 番目のサブネットに最初のサブネットが含まれる場合は、2 番目のサブネットで最初のサブネットの順位を決定できます。" 7245 7246#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:642 7247msgid "If the second subnet doesn't include the first subnet, the ``ipsubnet()`` filter raises an error." 7248msgstr "2 つ目のサブネットに 1 つ目のサブネットが含まれていない場合、``ipsubnet()`` フィルターはエラーを出力します。" 7249 7250#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:645 7251msgid "You can use the ``ipsubnet()`` filter with the ``ipaddr()`` filter to, for example, split a given ``/48`` prefix into smaller ``/64`` subnets::" 7252msgstr "``ipsubnet()`` フィルターと ``ipaddr()`` フィルターを併用することで、たとえば、``/48`` プレフィックスをより小さな ``/64`` サブネットに分割することができます。" 7253 7254#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:651 7255msgid "Because of the size of IPv6 subnets, iteration over all of them to find the correct one may take some time on slower computers, depending on the size difference between the subnets." 7256msgstr "IPv6 サブネットはサイズが大きいため、正しいサブネットを見つけるためにすべてのサブネットを反復処理すると、遅いコンピューターではサブネット間のサイズ差に応じて時間がかかる場合があります。" 7257 7258#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:657 7259msgid "Subnet Merging" 7260msgstr "サブネットのマージ" 7261 7262#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:661 7263msgid "The ``cidr_merge()`` filter can be used to merge subnets or individual addresses into their minimal representation, collapsing overlapping subnets and merging adjacent ones wherever possible::" 7264msgstr "``cidr_merge()`` フィルターは、サブネットや個々のアドレスを最小の表現に統合するために使用することができ、重複するサブネットを折りたたみ、可能な限り隣接するサブネットをマージすることができます。" 7265 7266#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:671 7267msgid "Changing the action from 'merge' to 'span' will instead return the smallest subnet which contains all of the inputs::" 7268msgstr "アクションを「merge」から「span」に変更すると、代わりに入力のすべてを含む最小のサブネットを返します。" 7269 7270#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:682 7271msgid "MAC address filter" 7272msgstr "MAC アドレスフィルター" 7273 7274#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:684 7275msgid "You can use the ``hwaddr()`` filter to check if a given string is a MAC address or convert it between various formats. Examples::" 7276msgstr "``hwaddr()`` フィルターを使用して、与えられた文字列が MAC アドレスであるかどうかを確認したり、さまざまなフォーマット間で変換したりすることができます。以下に例を示します。" 7277 7278#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:702 7279msgid "The supported formats result in the following conversions for the ``1a:2b:3c:4d:5e:6f`` MAC address::" 7280msgstr "サポートされる形式により、以下の変換で、MAC アドレス ``1a:2b:3c:4d:5e:6f`` に対して、以下のような変換が行われます。" 7281 7282#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:714 7283msgid "Generate an IPv6 address in Stateless Configuration (SLAAC)" 7284msgstr "ステートレス設定 (SLAAC) で IPv6 アドレスを生成します。" 7285 7286#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:716 7287msgid "the filter ``slaac()`` generates an IPv6 address for a given network and a MAC Address in Stateless Configuration::" 7288msgstr "フィルター ``slaac()`` は、ステートレス設定の指定のネットワークおよび MAC アドレスに IPv6 アドレスを生成します。" 7289 7290#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:724 7291msgid "`ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_" 7292msgstr "`ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_" 7293 7294#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:725 7295msgid "Ansible network collection for common code" 7296msgstr "一般的なコードの Ansible ネットワークコレクション" 7297 7298#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:728 7299#: ../../rst/user_guide/playbooks_variables.rst:453 7300msgid ":ref:`playbooks_filters`" 7301msgstr ":ref:`playbooks_filters`" 7302 7303#: ../../rst/user_guide/playbooks_filters_ipaddr.rst:729 7304msgid "Introduction to Jinja2 filters and their uses" 7305msgstr "Jinja2 フィルターの概要およびその用途" 7306 7307#: ../../rst/user_guide/playbooks_handlers.rst:4 7308msgid "Handlers: running operations on change" 7309msgstr "ハンドラー: 変更時に実行する操作" 7310 7311#: ../../rst/user_guide/playbooks_handlers.rst:6 7312msgid "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. Each handler should have a globally unique name." 7313msgstr "マシンに変更が加えられたときにのみ、タスクを実行したい場合があります。たとえば、タスクがサービスの設定を更新した場合はサービスを再起動し、設定が変更していない場合には再起動しないようにしたい場合があります。Ansible では、このようなユースケースに対応するためにハンドラーを使用しています。ハンドラーは、通知されたときにのみ実行するタスクです。各ハンドラーには、グローバルに一意な名前を付ける必要があります。" 7314 7315#: ../../rst/user_guide/playbooks_handlers.rst:12 7316msgid "Handler example" 7317msgstr "ハンドラーの例" 7318 7319#: ../../rst/user_guide/playbooks_handlers.rst:14 7320msgid "This playbook, ``verify-apache.yml``, contains a single play with a handler::" 7321msgstr "この Playbook ``verify-apache.yml`` には、ハンドラーを使用した 1 つのプレイが含まれます。" 7322 7323#: ../../rst/user_guide/playbooks_handlers.rst:47 7324msgid "In this example playbook, the second task notifies the handler. A single task can notify more than one handler::" 7325msgstr "この Playbook の例では、2 番目のタスクがハンドラーに通知します。単一のタスクは複数のハンドラーに通知することができます。" 7326 7327#: ../../rst/user_guide/playbooks_handlers.rst:69 7328msgid "Controlling when handlers run" 7329msgstr "ハンドラーの実行時の制御" 7330 7331#: ../../rst/user_guide/playbooks_handlers.rst:71 7332msgid "By default, handlers run after all the tasks in a particular play have been completed. 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." 7333msgstr "デフォルトでは、ハンドラーは、特定のプレイにおけるすべてのタスクが完了した後に実行します。ハンドラーは、いくつのタスクが通知したかに関わらず、一度だけ実行するため、このアプローチは効率的です。たとえば、複数のタスクが設定ファイルを更新し、ハンドラーに Apache の再起動を通知した場合、Ansible は Apache を 1 回だけバウンスさせ、不要な再起動を回避します。" 7334 7335#: ../../rst/user_guide/playbooks_handlers.rst:73 7336msgid "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::" 7337msgstr "プレイの終了前にハンドラーを実行する必要がある場合は、Ansible アクションを実行する :ref:`meta module <meta_module>` を使用して、タスクをフラッシュします。" 7338 7339#: ../../rst/user_guide/playbooks_handlers.rst:85 7340msgid "The ``meta: flush_handlers`` task triggers any handlers that have been notified at that point in the play." 7341msgstr "``meta: flush_handlers`` タスクは、プレイのその時点で通知されたハンドラーを発生させます。" 7342 7343#: ../../rst/user_guide/playbooks_handlers.rst:88 7344msgid "Using variables with handlers" 7345msgstr "ハンドラーでの変数の使用" 7346 7347#: ../../rst/user_guide/playbooks_handlers.rst:90 7348msgid "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::" 7349msgstr "Ansible ハンドラーで変数を使用したい場合があります。たとえば、サービスの名前がディストリビューションによってわずかに異なる場合に、ターゲットマシンごとに再起動したサービスの正確な名前を出力するとします。ハンドラーの名前に変数を入れないでください。ハンドラー名は初期段階でテンプレート化されているため、Ansible では次のようなハンドラー名に利用できる値がない場合があります。" 7350 7351#: ../../rst/user_guide/playbooks_handlers.rst:96 7352msgid "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." 7353msgstr "ハンドラー名で使用される変数が利用できない場合は、プレイ全体が失敗します。変数 mid-play を変更すると、新しく作成されたハンドラーが **作成されません**。" 7354 7355#: ../../rst/user_guide/playbooks_handlers.rst:98 7356msgid "Instead, place variables in the task parameters of your handler. You can load the values using ``include_vars`` like this:" 7357msgstr "代わりに、ハンドラーのタスクパラメーターに変数を配置します。以下のように ``include_vars`` を使用して、値を読み込むことができます。" 7358 7359#: ../../rst/user_guide/playbooks_handlers.rst:112 7360msgid "Handlers can also \"listen\" to generic topics, and tasks can notify those topics as follows::" 7361msgstr "ハンドラーは一般的なトピックを「リッスン」することもでき、タスクは次のようにそれらのトピックに通知できます。" 7362 7363#: ../../rst/user_guide/playbooks_handlers.rst:132 7364msgid "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 3rd party roles from a shared source like Galaxy)." 7365msgstr "これにより、複数のハンドラーを簡単に発生させることができます。また、ハンドラーを名前から切り離すことで、Playbook やロール間でのハンドラーの共有が容易になります (特に Galaxy のような共有ソースからサードパーティーのロールを使用する場合)。" 7366 7367#: ../../rst/user_guide/playbooks_handlers.rst:137 7368msgid "Handlers always run in the order they are defined, not in the order listed in the notify-statement. This is also the case for handlers using `listen`." 7369msgstr "ハンドラーは、notify-statement に記載されている順番ではなく、常に定義されている順番で実行します。これは、`listen` を使用しているハンドラーにも当てはまります。" 7370 7371#: ../../rst/user_guide/playbooks_handlers.rst:138 7372msgid "Handler names and `listen` topics live in a global namespace." 7373msgstr "ハンドラー名と `listen` トピックは、グローバルな名前空間にあります。" 7374 7375#: ../../rst/user_guide/playbooks_handlers.rst:139 7376msgid "Handler names are templatable and `listen` topics are not." 7377msgstr "ハンドラー名は一時的なものですが、`listen` トピックは一時的ではありません。" 7378 7379#: ../../rst/user_guide/playbooks_handlers.rst:140 7380msgid "Use unique handler names. If you trigger more than one handler with the same name, the first one(s) get overwritten. Only the last one defined will run." 7381msgstr "ハンドラーの名前は一意にしてください。同じ名前で複数のハンドラーを発生させる場合、最初のハンドラーは上書きされます。最後に定義されたものだけが実行されます。" 7382 7383#: ../../rst/user_guide/playbooks_handlers.rst:141 7384msgid "You can notify a handler defined inside a static include." 7385msgstr "静的インクルードの中で定義されたハンドラーを通知することができます。" 7386 7387#: ../../rst/user_guide/playbooks_handlers.rst:142 7388msgid "You cannot notify a handler defined inside a dynamic include." 7389msgstr "動的なインクルード内で定義されたハンドラーを通知することはできません。" 7390 7391#: ../../rst/user_guide/playbooks_handlers.rst:143 7392msgid "A handler can not run import_role or include_role." 7393msgstr "ハンドラーは import_role または include_role を実行できません。" 7394 7395#: ../../rst/user_guide/playbooks_handlers.rst:145 7396msgid "When using handlers within roles, note that:" 7397msgstr "ロール内でハンドラーを使用する場合は、以下に注意してください。" 7398 7399#: ../../rst/user_guide/playbooks_handlers.rst:147 7400msgid "handlers notified within ``pre_tasks``, ``tasks``, and ``post_tasks`` sections are automatically flushed at the end of section where they were notified." 7401msgstr "``pre_tasks`` セクション、``tasks`` セクション、および ``post_tasks`` セクション内で通知されるハンドラーは、通知されたセクションの最後に自動的にフラッシュされます。" 7402 7403#: ../../rst/user_guide/playbooks_handlers.rst:148 7404msgid "handlers notified within ``roles`` section are automatically flushed at the end of ``tasks`` section, but before any ``tasks`` handlers." 7405msgstr "``roles``セクション内で通知されるハンドラーは、``tasks`` セクションの最後ではなく、``tasks`` ハンドラーの前に自動的にフラッシュされます。" 7406 7407#: ../../rst/user_guide/playbooks_handlers.rst:149 7408msgid "handlers are play scoped and as such can be used outside of the role they are defined in." 7409msgstr "ハンドラーはスコープのあるプレイであるため、ハンドラーは定義されているロールの外で使用できます。" 7410 7411#: ../../rst/user_guide/playbooks_intro.rst:6 7412msgid "Intro to playbooks" 7413msgstr "Playbook の概要" 7414 7415#: ../../rst/user_guide/playbooks_intro.rst:8 7416msgid "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." 7417msgstr "Ansible Playbook は、繰り返し使用可能で、再利用可能なシンプルな構成管理および複数マシンのデプロイメントシステムであり、複雑なアプリケーションのデプロイメントに適しています。Ansible で複数回タスクを実行する必要がある場合は、Playbook を作成してソースコントロール下に置きます。その後、Playbook を使用して、新しい設定をプッシュアウトしたり、リモートシステムの設定を確認したりすることができます。`ansible-examples リポジトリー <https://github.com/ansible/ansible-examples>`_ の Playbook には、多くの便利なテクニックが紹介されています。ドキュメントを読みながら、これらを別のタブで見てみるのもいいかもしれません。" 7418 7419#: ../../rst/user_guide/playbooks_intro.rst:10 7420msgid "Playbooks can:" 7421msgstr "Playbook は、以下のことができます。" 7422 7423#: ../../rst/user_guide/playbooks_intro.rst:12 7424msgid "declare configurations" 7425msgstr "宣言設定" 7426 7427#: ../../rst/user_guide/playbooks_intro.rst:13 7428msgid "orchestrate steps of any manual ordered process, on multiple sets of machines, in a defined order" 7429msgstr "複数のマシンセットで、手動で順序付けされたプロセスの手順を定義された順序で編成します。" 7430 7431#: ../../rst/user_guide/playbooks_intro.rst:14 7432msgid "launch tasks synchronously or :ref:`asynchronously <playbooks_async>`" 7433msgstr "タスクを同期または :ref:`非同期 <playbooks_async>` で起動" 7434 7435#: ../../rst/user_guide/playbooks_intro.rst:22 7436msgid "Playbook syntax" 7437msgstr "Playbook 構文" 7438 7439#: ../../rst/user_guide/playbooks_intro.rst:24 7440msgid "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." 7441msgstr "Playbook は最小限の構文で YAML 形式で表現されます。YAML に慣れていない方は、:ref:`yaml_syntax` の概要を参照してください。また、Playbook にきれいな YAML 構文を書くために、テキストエディター用のアドオンのインストールを検討してください (「:ref:`other_tools_and_programs`」を参照)。" 7442 7443#: ../../rst/user_guide/playbooks_intro.rst:26 7444msgid "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." 7445msgstr "Playbook は、1 つまたは複数の「プレイ」を順番に並べたものです。「Playbook」と「プレイ」という言葉は、スポーツに例えられています。各プレイは、Playbook の全体的な目標の一部を実行し、1 つまたは複数のタスクを実行します。各タスクは、Ansible モジュールを呼び出します。" 7446 7447#: ../../rst/user_guide/playbooks_intro.rst:29 7448msgid "Playbook execution" 7449msgstr "Playbook 実行" 7450 7451#: ../../rst/user_guide/playbooks_intro.rst:31 7452msgid "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:" 7453msgstr "Playbook は、上から下に向かって順番に実行されます。各プレイの中では、タスクも上から下の順に実行されます。複数の「プレイ」を持つ Playbook では、複数のマシンのデプロイメントを編成することができます。あるプレイを Web サーバーで実行した後、別のプレイをデータベースサーバーで実行し、さらに 3 つ目のプレイをネットワークインフラストラクチャーで実行するといった具合です。最低限、各プレイは 2 つのことを定義します。" 7454 7455#: ../../rst/user_guide/playbooks_intro.rst:33 7456msgid "the managed nodes to target, using a :ref:`pattern <intro_patterns>`" 7457msgstr ":ref:`pattern <intro_patterns>`を使用する管理ノードが対象である" 7458 7459#: ../../rst/user_guide/playbooks_intro.rst:34 7460msgid "at least one task to execute" 7461msgstr "実行すべき 1 つ以上のタスク" 7462 7463#: ../../rst/user_guide/playbooks_intro.rst:38 7464msgid "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`." 7465msgstr "Ansible 2.10 以降では、複数のコレクションに同じ名前のモジュールが含まれていることがあるため (例: ``user``)、正しいモジュールが選択されるように、Playbook で完全修飾コレクション名を使用することが推奨されます。「:ref:`collections_using_playbook`」を参照してください。" 7466 7467#: ../../rst/user_guide/playbooks_intro.rst:40 7468msgid "In this example, the first play targets the web servers; the second play targets the database servers::" 7469msgstr "この例では、第 1 のプレイは Web サーバーを対象とし、第 2 のプレイはデータベースサーバーを対象としています。" 7470 7471#: ../../rst/user_guide/playbooks_intro.rst:71 7472msgid "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." 7473msgstr "Playbook には、ホストラインとタスク以外の情報も含めることができます。たとえば、上記の Playbook では、各プレイに ``remote_user`` を設定しています。これは、SSH 接続用のユーザーアカウントです。Playbook、プレイ、またはタスクレベルで他の :ref:`playbook_keywords` を追加して、Ansible の動作に影響を与えることができます。Playbook のキーワードでは、:ref:`connection プラグイン <connection_plugins>` で、:ref:`特権昇格 <become>` を使用するかどうか、エラーをどのように処理するかなどを制御できます。さまざまな環境に対応するため、Ansible では、これらのパラメーターの多くをコマンドラインフラグ、Ansible の構成、またはインベントリーで設定することができます。これらのデータソースの :ref:`優先順位のルール <general_precedence_rules>` を学ぶことは、Ansible のエコシステムを拡張する際に役立ちます。" 7474 7475#: ../../rst/user_guide/playbooks_intro.rst:76 7476msgid "Task execution" 7477msgstr "タスクの実行" 7478 7479#: ../../rst/user_guide/playbooks_intro.rst:78 7480msgid "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." 7481msgstr "デフォルトでは、Ansible は、ホストパターンに一致するすべてのマシンに対して、各タスクを 1 つずつ順番に実行します。各タスクは、特定の引数を持つモジュールを実行します。タスクがすべてのターゲットマシンで実行すると、Ansible は次のタスクに移ります。このデフォルトの動作を変更するには、:ref:`ストラテジー <playbooks_strategies>` を使用します。各プレイの中で、Ansible は同じタスクディレクティブをすべてのホストに適用します。あるホストでタスクが失敗した場合、Ansible はそのホストを Playbook の残りの部分のローテーションから外します。" 7482 7483#: ../../rst/user_guide/playbooks_intro.rst:80 7484msgid "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." 7485msgstr "Playbook を実行すると、Ansible は接続に関する情報、すべてのプレイとタスクの ``name`` 行、各タスクが各マシンで成功したか失敗したか、および各タスクが各マシンで変更を行ったかどうかを返します。Playbook の実行の最後に、Ansible は、対象となったノードとそのパフォーマンスの概要を表示します。一般的な失敗と致命的な「到達不能」の通信試行は、カウントの中で分けて表示されます。" 7486 7487#: ../../rst/user_guide/playbooks_intro.rst:85 7488msgid "Desired state and 'idempotency'" 7489msgstr "希望の状態および「冪等性」" 7490 7491#: ../../rst/user_guide/playbooks_intro.rst:87 7492msgid "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." 7493msgstr "ほとんどの Ansible モジュールは、目的の最終状態がすでに達成されているかどうかを確認し、その状態が達成されている場合は何も実行せずに終了するため、タスクを繰り返しても最終状態は変わりません。このような動作をするモジュールは、しばしば「冪等性」と呼ばれます。Playbook を 1 回だけ実行しても、複数回実行しても、結果は同じになるはずです。しかし、すべての Playbook やすべてのモジュールがこのように動作するわけではありません。不安な場合は、実稼働環境で Playbook を複数回実行する前に、サンドボックス環境で Playbook をテストしてください。" 7494 7495#: ../../rst/user_guide/playbooks_intro.rst:92 7496msgid "Running playbooks" 7497msgstr "Playbook の実行" 7498 7499#: ../../rst/user_guide/playbooks_intro.rst:94 7500msgid "To run your playbook, use the :ref:`ansible-playbook` command::" 7501msgstr "Playbook を実行するには、:ref:`ansible-playbook` コマンドを使用します。" 7502 7503#: ../../rst/user_guide/playbooks_intro.rst:98 7504msgid "Use the ``--verbose`` flag when running your playbook to see detailed output from successful modules as well as unsuccessful ones." 7505msgstr "成功したモジュールと失敗したモジュールの詳細な出力を確認するには、Playbook の実行時に ``--verbose`` フラグを使用します。" 7506 7507#: ../../rst/user_guide/playbooks_intro.rst:103 7508msgid "Ansible-Pull" 7509msgstr "ansible-pull" 7510 7511#: ../../rst/user_guide/playbooks_intro.rst:105 7512msgid "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." 7513msgstr "ノードに設定をプッシュするのではなく、Ansible のアーキテクチャーを逆にして、ノードが中央の場所にチェックインするようにしたい場合は、以下を行うことができます。" 7514 7515#: ../../rst/user_guide/playbooks_intro.rst:108 7516msgid "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." 7517msgstr "``ansible-pull`` は小さなスクリプトで、git から設定方法をまとめたリポジトリーをチェックアウトし、その内容に対して ``ansible-playbook`` を実行します。" 7518 7519#: ../../rst/user_guide/playbooks_intro.rst:111 7520msgid "Assuming you load balance your checkout location, ``ansible-pull`` scales essentially infinitely." 7521msgstr "チェックアウトの場所を負荷分散する場合、``ansible-pull`` は基本的に無限にスケーリングを行います。" 7522 7523#: ../../rst/user_guide/playbooks_intro.rst:113 7524msgid "Run ``ansible-pull --help`` for details." 7525msgstr "詳細は、「``ansible-pull --help``」を参照してください。" 7526 7527#: ../../rst/user_guide/playbooks_intro.rst:115 7528msgid "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." 7529msgstr "また、プッシュモードからの crontab で ``ansible-pull`` を設定する際に利用可能な `優れた Playbook <https://github.com/ansible/ansible-examples/blob/master/language_features/ansible_pull.yml>`_ もあります。" 7530 7531#: ../../rst/user_guide/playbooks_intro.rst:118 7532msgid "Verifying playbooks" 7533msgstr "Playbook の検証" 7534 7535#: ../../rst/user_guide/playbooks_intro.rst:120 7536msgid "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." 7537msgstr "Playbook を実行する前に、構文エラーやその他の問題を検出するために、Playbook を検証したい場合があります。:ref:`ansible-playbook` コマンドには、``--check``、``--diff``、``--list-hosts``、``--list-tasks``、``--syntax-check`` など、検証のためのオプションが用意されています。「:ref:`validate-playbook-tools`」では、Playbook の検証とテストのための他のツールについて説明しています。" 7538 7539#: ../../rst/user_guide/playbooks_intro.rst:125 7540msgid "ansible-lint" 7541msgstr "ansible-lint" 7542 7543#: ../../rst/user_guide/playbooks_intro.rst:127 7544msgid "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:" 7545msgstr "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_ を使用すると、Playbook を実行する前に、Playbook に対する Ansible 固有の詳細なフィードバックを得ることができます。たとえば、このページの上位にある ``verify-apache.yml`` という Playbook に対して ``ansible-lint`` を実行すると、以下のような結果が得られます。" 7546 7547#: ../../rst/user_guide/playbooks_intro.rst:136 7548msgid "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." 7549msgstr "`ansible-lint デフォルトルール <https://docs.ansible.com/ansible-lint/rules/default_rules.html>`_ ページには、各エラーについて説明しています。``[403]`` については、Playbook で ``state: latest`` を ``state: present`` に変更することが推奨されます。" 7550 7551#: ../../rst/user_guide/playbooks_intro.rst:140 7552msgid "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_" 7553msgstr "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_" 7554 7555#: ../../rst/user_guide/playbooks_intro.rst:141 7556msgid "Learn how to test Ansible Playbooks syntax" 7557msgstr "Ansible Playbook 構文のテスト方法について" 7558 7559#: ../../rst/user_guide/playbooks_intro.rst:145 7560msgid "Tips for managing playbooks in the real world" 7561msgstr "実際の Playbook の管理に関するさまざまなヒント" 7562 7563#: ../../rst/user_guide/playbooks_intro.rst:149 7564msgid "Learn to extend Ansible by writing your own modules" 7565msgstr "独自のモジュールを作成して Ansible を拡張する方法について" 7566 7567#: ../../rst/user_guide/playbooks_intro.rst:153 7568msgid "Complete end-to-end playbook examples" 7569msgstr "完全なエンドツーエンド Playbook の例" 7570 7571#: ../../rst/user_guide/playbooks_lookups.rst:5 7572msgid "Lookups" 7573msgstr "検索 (lookup)" 7574 7575#: ../../rst/user_guide/playbooks_lookups.rst:7 7576msgid "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." 7577msgstr "lookup プラグインは、ファイル、データベース、キー/値ストア、API、その他のサービスなどの外部ソースからデータを取得します。すべてのテンプレート化と同様に、lookup は Ansible のコントロールマシン上で実行され、評価されます。Ansible では、lookup プラグインが返すデータを、標準のテンプレートシステムを使用して利用できるようにします。Ansible 2.5 以前、lookup はほとんどの場合、``with_<lookup>`` のループのための構成で間接的に使用されていました。Ansible 2.5 以降、lookup は Jinja2 の式の一部として、より明示的に使用されるようになり、``loop`` キーワードに供給されるようになりました。" 7578 7579#: ../../rst/user_guide/playbooks_lookups.rst:12 7580msgid "Using lookups in variables" 7581msgstr "変数での lookup の使用" 7582 7583#: ../../rst/user_guide/playbooks_lookups.rst:14 7584msgid "You can populate variables using lookups. Ansible evaluates the value each time it is executed in a task (or template)::" 7585msgstr "lookup を使用して変数を設定することができます。Ansible は、タスク (またはテンプレート) で実行されるたびに値を評価します。" 7586 7587#: ../../rst/user_guide/playbooks_lookups.rst:22 7588msgid "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``." 7589msgstr "ansible-core の lookup プラグインの詳細と一覧は、「:ref:`plugins_lookup`」を参照してください。また、lookup プラグインはコレクションにも含まれています。コントロールマシンにインストールされている lookup プラグインのリストは、``ansible-doc -l -t lookup`` コマンドで確認できます。" 7590 7591#: ../../rst/user_guide/playbooks_loops.rst:5 7592msgid "Loops" 7593msgstr "ループ" 7594 7595#: ../../rst/user_guide/playbooks_loops.rst:7 7596msgid "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." 7597msgstr "Ansible には、``loop``、``with_<lookup>``、および ``until`` というキーワードがあり、1 つのタスクを複数回実行することができます。一般的に使用されるループの例としては、:ref:`file module <file_module>` で複数のファイルやディレクトリーの所有権を変更する、:ref:`user module <user_module>` で複数のユーザーを作成する、特定の結果が得られるまでポーリングステップを繰り返すなどがあります。" 7598 7599#: ../../rst/user_guide/playbooks_loops.rst:11 7600msgid "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." 7601msgstr "Ansible 2.5 で ``loop`` を追加しました。``with_<lookup>`` は完全に置き換えるものではありませんが、ほとんどのユースケースで推奨されています。" 7602 7603#: ../../rst/user_guide/playbooks_loops.rst:12 7604msgid "We have not deprecated the use of ``with_<lookup>`` - that syntax will still be valid for the foreseeable future." 7605msgstr "``with_<lookup>`` の使用は非推奨になっていません。この構文は、今後も有効です。" 7606 7607#: ../../rst/user_guide/playbooks_loops.rst:13 7608msgid "We are looking to improve ``loop`` syntax - watch this page and the `changelog <https://github.com/ansible/ansible/tree/devel/changelogs>`_ for updates." 7609msgstr "``loop`` 構文を改善する場合は、このページと `changelog <https://github.com/ansible/ansible/tree/devel/changelogs>`_ で更新を確認します。" 7610 7611#: ../../rst/user_guide/playbooks_loops.rst:19 7612msgid "Comparing ``loop`` and ``with_*``" 7613msgstr "``loop`` と ``with_*`` の比較" 7614 7615#: ../../rst/user_guide/playbooks_loops.rst:21 7616msgid "The ``with_<lookup>`` keywords rely on :ref:`lookup_plugins` - even ``items`` is a lookup." 7617msgstr "``with_<lookup>`` キーワードは :ref:`lookup_plugins` に依存し、``items`` も lookup となります。" 7618 7619#: ../../rst/user_guide/playbooks_loops.rst:22 7620msgid "The ``loop`` keyword is equivalent to ``with_list``, and is the best choice for simple loops." 7621msgstr "``loop`` キーワードは ``with_list`` と同等であり、単純なループに最適です。" 7622 7623#: ../../rst/user_guide/playbooks_loops.rst:23 7624msgid "The ``loop`` keyword will not accept a string as input, see :ref:`query_vs_lookup`." 7625msgstr "``loop`` キーワードは文字列を入力として受け付けません。「:ref:`query_vs_lookup`」を参照してください。" 7626 7627#: ../../rst/user_guide/playbooks_loops.rst:24 7628msgid "Generally speaking, any use of ``with_*`` covered in :ref:`migrating_to_loop` can be updated to use ``loop``." 7629msgstr "通常、「:ref:`migrating_to_loop`」で対応している ``with_*`` を使用すると、``loop`` を使用するように更新できます。" 7630 7631#: ../../rst/user_guide/playbooks_loops.rst:25 7632msgid "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:" 7633msgstr "``with_items`` を ``loop`` に変更する際には、``with_items`` が暗黙の単一レベルのフラット化を行うため注意が必要です。正確な結果を得るためには、``flatten(1)`` と ``loop`` の併用が必要になる可能性があります。たとえば、次と同じ出力を得るには、" 7634 7635#: ../../rst/user_guide/playbooks_loops.rst:34 7636msgid "you would need::" 7637msgstr "以下が必要です。" 7638 7639#: ../../rst/user_guide/playbooks_loops.rst:38 7640msgid "Any ``with_*`` statement that requires using ``lookup`` within a loop should not be converted to use the ``loop`` keyword. For example, instead of doing:" 7641msgstr "ループ内で ``lookup`` を使用する必要のある ``with_*`` 文は、``loop`` キーワードを使用するように変換しないでください。たとえば、代わりに、以下を行います。" 7642 7643#: ../../rst/user_guide/playbooks_loops.rst:44 7644msgid "it's cleaner to keep::" 7645msgstr "保持する方が見た目がすっきりします。" 7646 7647#: ../../rst/user_guide/playbooks_loops.rst:51 7648msgid "Standard loops" 7649msgstr "標準ループ" 7650 7651#: ../../rst/user_guide/playbooks_loops.rst:54 7652msgid "Iterating over a simple list" 7653msgstr "シンプルなリストでの反復" 7654 7655#: ../../rst/user_guide/playbooks_loops.rst:56 7656msgid "Repeated tasks can be written as standard loops over a simple list of strings. You can define the list directly in the task::" 7657msgstr "繰り返されるタスクは、文字列の単純なリストに対する標準的なループとして記述できます。このリストはタスクの中で直接定義できます。" 7658 7659#: ../../rst/user_guide/playbooks_loops.rst:67 7660msgid "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::" 7661msgstr "変数ファイルでリストを定義するか、プレイの「vars」セクションで、タスク内のリストの名前を参照します。" 7662 7663#: ../../rst/user_guide/playbooks_loops.rst:71 7664msgid "Either of these examples would be the equivalent of::" 7665msgstr "これらの例のいずれも、以下と同等です。" 7666 7667#: ../../rst/user_guide/playbooks_loops.rst:85 7668msgid "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::" 7669msgstr "いくつかのプラグインでは、パラメーターにリストを直接渡すことができます。:ref:`yum <yum_module>` や :ref:`apt <apt_module>` など、ほとんどのパッケージングモジュールにこの機能があります。利用できる場合は、リストをパラメーターに渡す方が、タスクをループさせるよりも良いでしょう。以下に例を示します。" 7670 7671#: ../../rst/user_guide/playbooks_loops.rst:98 7672msgid "Check the :ref:`module documentation <modules_by_category>` to see if you can pass a list to any particular module's parameter(s)." 7673msgstr ":ref:`モジュールのドキュメント <modules_by_category>` で、特定モジュールのパラメーターにリストを渡すことができるかどうかを確認します。" 7674 7675#: ../../rst/user_guide/playbooks_loops.rst:101 7676msgid "Iterating over a list of hashes" 7677msgstr "ハッシュリストでの反復" 7678 7679#: ../../rst/user_guide/playbooks_loops.rst:103 7680msgid "If you have a list of hashes, you can reference subkeys in a loop. For example::" 7681msgstr "ハッシュリストがある場合は、ループでサブキーを参照できます。以下に例を示します。" 7682 7683#: ../../rst/user_guide/playbooks_loops.rst:114 7684msgid "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." 7685msgstr ":ref:`conditionals <playbooks_conditionals>` とループを組み合わせると、``when:`` 文は各項目について個別に処理されます。例は「:ref:`the_when_statement`」を参照してください。" 7686 7687#: ../../rst/user_guide/playbooks_loops.rst:118 7688msgid "Iterating over a dictionary" 7689msgstr "ディクショナリーでの反復" 7690 7691#: ../../rst/user_guide/playbooks_loops.rst:120 7692msgid "To loop over a dict, use the :ref:`dict2items <dict_filter>`:" 7693msgstr "ディクショナリーでループするには、:ref:`dict2items <dict_filter>` を使用します。" 7694 7695#: ../../rst/user_guide/playbooks_loops.rst:133 7696msgid "Here, we are iterating over `tag_data` and printing the key and the value from it." 7697msgstr "ここでは、`tag_data` を繰り返し処理し、キーと値を出力します。" 7698 7699#: ../../rst/user_guide/playbooks_loops.rst:136 7700msgid "Registering variables with a loop" 7701msgstr "ループによる変数の登録" 7702 7703#: ../../rst/user_guide/playbooks_loops.rst:138 7704msgid "You can register the output of a loop as a variable. For example::" 7705msgstr "ループの出力を変数として登録できます。たとえば、次のようになります。" 7706 7707#: ../../rst/user_guide/playbooks_loops.rst:147 7708msgid "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::" 7709msgstr "``register`` をループで使用すると、変数に配置されるデータ構造には、モジュールからのすべての応答のリストである ``results`` 属性が含まれます。これは、``register`` をループなしで使用したときに返されるデータ構造とは異なります。" 7710 7711#: ../../rst/user_guide/playbooks_loops.rst:186 7712msgid "Subsequent loops over the registered variable to inspect the results may look like::" 7713msgstr "登録済みの変数で後続のループを実行して結果を検査すると、以下のようになります。" 7714 7715#: ../../rst/user_guide/playbooks_loops.rst:194 7716msgid "During iteration, the result of the current item will be placed in the variable::" 7717msgstr "反復時に、現在の項目の結果は変数に配置されます。" 7718 7719#: ../../rst/user_guide/playbooks_loops.rst:207 7720msgid "Complex loops" 7721msgstr "複雑なループ" 7722 7723#: ../../rst/user_guide/playbooks_loops.rst:210 7724msgid "Iterating over nested lists" 7725msgstr "入れ子のリストでの反復" 7726 7727#: ../../rst/user_guide/playbooks_loops.rst:212 7728msgid "You can use Jinja2 expressions to iterate over complex lists. For example, a loop can combine nested lists::" 7729msgstr "Jinja2 の式を使用して、複雑なリストを繰り返し処理することができます。たとえば、ループは入れ子になったリストを組み合わせることができます。" 7730 7731#: ../../rst/user_guide/playbooks_loops.rst:226 7732msgid "Retrying a task until a condition is met" 7733msgstr "条件が満たされるまでタスクの再試行" 7734 7735#: ../../rst/user_guide/playbooks_loops.rst:230 7736msgid "You can use the ``until`` keyword to retry a task until a certain condition is met. Here's an example::" 7737msgstr "``until`` キーワードを使用すると、ある条件が満たされるまでタスクを再試行することができます。以下に例を示します。" 7738 7739#: ../../rst/user_guide/playbooks_loops.rst:239 7740msgid "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." 7741msgstr "このタスクは、各試行の間に 10 秒の遅延を置いて最大 5 回実行される。試行の結果、標準出力に「all systems go」と表示されていれば、タスクは成功です。「retries (再試行)」のデフォルト値は 3、「delay (遅延)」は 5 です。" 7742 7743#: ../../rst/user_guide/playbooks_loops.rst:241 7744msgid "To see the results of individual retries, run the play with ``-vv``." 7745msgstr "個別の再試行の結果を表示するには、``-vv`` でプレイを実行します。" 7746 7747#: ../../rst/user_guide/playbooks_loops.rst:243 7748msgid "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." 7749msgstr "``until`` を使用してタスクを実行し、結果を変数として登録する場合は、登録済み変数には「attempts」と呼ばれる鍵が含まれ、タスクの再試行回数を記録します。" 7750 7751#: ../../rst/user_guide/playbooks_loops.rst:245 7752msgid "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." 7753msgstr "タスクが再試行するには、``until`` パラメーターを設定する必要があります。``until`` が定義されていない場合は、``retries`` パラメーターの値が 1 に強制されます。" 7754 7755#: ../../rst/user_guide/playbooks_loops.rst:248 7756msgid "Looping over inventory" 7757msgstr "インベントリーのループ" 7758 7759#: ../../rst/user_guide/playbooks_loops.rst:250 7760msgid "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::" 7761msgstr "インベントリーやその一部だけをループさせるには、通常の ``loop`` に ``ansible_play_batch`` 変数や ``groups`` 変数を加えたものを使用することができます。" 7762 7763#: ../../rst/user_guide/playbooks_loops.rst:262 7764msgid "There is also a specific lookup plugin ``inventory_hostnames`` that can be used like this::" 7765msgstr "また、以下のような特定の lookup プラグイン ``inventory_hostnames`` も使用できます。" 7766 7767#: ../../rst/user_guide/playbooks_loops.rst:274 7768msgid "More information on the patterns can be found in :ref:`intro_patterns`." 7769msgstr "パターンの詳細は、「:ref:`intro_patterns`」を参照してください。" 7770 7771#: ../../rst/user_guide/playbooks_loops.rst:279 7772msgid "Ensuring list input for ``loop``: using ``query`` rather than ``lookup``" 7773msgstr "``loop`` のリスト入力の確保: ``lookup`` の代わりに ``query`` を使用" 7774 7775#: ../../rst/user_guide/playbooks_loops.rst:281 7776msgid "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." 7777msgstr "``loop`` キーワードは入力としてリストを必要としますが、``lookup`` キーワードはデフォルトでコンマで区切られた値の文字列を返すようになっています。Ansible 2.5 では、:ref:`query <query>` という名前の新しい Jinja2 関数が導入され、常にリストを返すようになりました。これにより、インターフェースがシンプルになり、``loop`` キーワードを使用した場合の lookup プラグインの出力がより予測しやすくなりました。" 7778 7779#: ../../rst/user_guide/playbooks_loops.rst:283 7780msgid "You can force ``lookup`` to return a list to ``loop`` by using ``wantlist=True``, or you can use ``query`` instead." 7781msgstr "``wantlist=True`` を使用すれば、``lookup`` がリストを ``loop`` に返すように強制したり、代わりに ``query`` を使用することもできます。" 7782 7783#: ../../rst/user_guide/playbooks_loops.rst:285 7784msgid "These examples do the same thing::" 7785msgstr "これらの例では、以下を行います。" 7786 7787#: ../../rst/user_guide/playbooks_loops.rst:295 7788msgid "Adding controls to loops" 7789msgstr "ループへのコントロールの追加" 7790 7791#: ../../rst/user_guide/playbooks_loops.rst:298 7792msgid "The ``loop_control`` keyword lets you manage your loops in useful ways." 7793msgstr "``loop_control`` キーワードを使用すると、ループを便利な方法で管理できます。" 7794 7795#: ../../rst/user_guide/playbooks_loops.rst:301 7796msgid "Limiting loop output with ``label``" 7797msgstr "``label`` を使用したループ出力の制限" 7798 7799#: ../../rst/user_guide/playbooks_loops.rst:304 7800msgid "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``::" 7801msgstr "複雑なデータ構造をループしていると、タスクのコンソール出力が膨大になることがあります。表示される出力を制限するには、``label`` ディレクティブと ``loop_control`` を使用します。" 7802 7803#: ../../rst/user_guide/playbooks_loops.rst:321 7804msgid "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." 7805msgstr "このタスクの出力には、複数行の ``{{ item }}`` 変数の内容全体ではなく、各 ``item`` の ``name`` フィールドのみが表示されます。" 7806 7807#: ../../rst/user_guide/playbooks_loops.rst:323 7808msgid "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." 7809msgstr "これはコンソール出力を読みやすくするためのもので、機密データを保護するものではありません。``loop`` に機密データがある場合は、``no_log: yes`` をタスクに設定して漏洩を防ぎます。" 7810 7811#: ../../rst/user_guide/playbooks_loops.rst:326 7812msgid "Pausing within a loop" 7813msgstr "ループ内での一時停止" 7814 7815#: ../../rst/user_guide/playbooks_loops.rst:329 7816msgid "To control the time (in seconds) between the execution of each item in a task loop, use the ``pause`` directive with ``loop_control``::" 7817msgstr "タスクループの各項目の実行間隔を (秒単位) で制御するには、``pause`` で ``loop_control`` ディレクティブを使用します。" 7818 7819#: ../../rst/user_guide/playbooks_loops.rst:343 7820msgid "Tracking progress through a loop with ``index_var``" 7821msgstr "``index_var`` のあるループでの進捗の追跡" 7822 7823#: ../../rst/user_guide/playbooks_loops.rst:346 7824msgid "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::" 7825msgstr "ループ内のどこにいるかを把握するには、``loop_control`` とともに ``index_var`` ディレクティブを使用します。このディレクティブは、現在のループのインデックスを格納する変数名を指定します。" 7826 7827#: ../../rst/user_guide/playbooks_loops.rst:358 7828msgid "`index_var` is 0 indexed." 7829msgstr "`index_var` は、0 インデックスです。" 7830 7831#: ../../rst/user_guide/playbooks_loops.rst:361 7832msgid "Defining inner and outer variable names with ``loop_var``" 7833msgstr "``loop_var`` を使用した内部変数名および外部変数名の定義" 7834 7835#: ../../rst/user_guide/playbooks_loops.rst:364 7836msgid "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``::" 7837msgstr "``include_tasks`` を使用すると、2 つのループタスクを入れ子にすることができます。ただし、Ansible のデフォルトでは、ループごとにループ変数 ``item`` が設定されます。これは、入れ子になった内側のループが、外側のループの ``item`` の値を上書きすることを意味します。``loop_var`` と ``loop_control`` を使用して、各ループの変数名を指定することができます。" 7838 7839#: ../../rst/user_guide/playbooks_loops.rst:385 7840msgid "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." 7841msgstr "定義されている変数を現在のループが使用していることを Ansible が検出すると、タスクが失敗するためにエラーが発生します。" 7842 7843#: ../../rst/user_guide/playbooks_loops.rst:388 7844msgid "Extended loop variables" 7845msgstr "拡張ループ変数" 7846 7847#: ../../rst/user_guide/playbooks_loops.rst:391 7848msgid "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." 7849msgstr "Ansible 2.8 では、ループ制御に ``extended`` オプションを使用することで、拡張されたループ情報を得ることができます。このオプションは、以下の情報を公開します。" 7850 7851#: ../../rst/user_guide/playbooks_loops.rst:394 7852msgid "Variable" 7853msgstr "変数" 7854 7855#: ../../rst/user_guide/playbooks_loops.rst:396 7856msgid "``ansible_loop.allitems``" 7857msgstr "``ansible_loop.allitems``" 7858 7859#: ../../rst/user_guide/playbooks_loops.rst:396 7860msgid "The list of all items in the loop" 7861msgstr "ループ内のすべての項目のリスト" 7862 7863#: ../../rst/user_guide/playbooks_loops.rst:397 7864msgid "``ansible_loop.index``" 7865msgstr "``ansible_loop.index``" 7866 7867#: ../../rst/user_guide/playbooks_loops.rst:397 7868msgid "The current iteration of the loop. (1 indexed)" 7869msgstr "ループの現在の反復 (1 インデックス化)" 7870 7871#: ../../rst/user_guide/playbooks_loops.rst:398 7872msgid "``ansible_loop.index0``" 7873msgstr "``ansible_loop.index0``" 7874 7875#: ../../rst/user_guide/playbooks_loops.rst:398 7876msgid "The current iteration of the loop. (0 indexed)" 7877msgstr "ループの現在の反復 (0 インデックス化)" 7878 7879#: ../../rst/user_guide/playbooks_loops.rst:399 7880msgid "``ansible_loop.revindex``" 7881msgstr "``ansible_loop.revindex``" 7882 7883#: ../../rst/user_guide/playbooks_loops.rst:399 7884msgid "The number of iterations from the end of the loop (1 indexed)" 7885msgstr "ループの最後からの反復回数 (1 インデックス化)" 7886 7887#: ../../rst/user_guide/playbooks_loops.rst:400 7888msgid "``ansible_loop.revindex0``" 7889msgstr "``ansible_loop.revindex0``" 7890 7891#: ../../rst/user_guide/playbooks_loops.rst:400 7892msgid "The number of iterations from the end of the loop (0 indexed)" 7893msgstr "ループの最後からの反復回数 (0 インデックス化)" 7894 7895#: ../../rst/user_guide/playbooks_loops.rst:401 7896msgid "``ansible_loop.first``" 7897msgstr "``ansible_loop.first``" 7898 7899#: ../../rst/user_guide/playbooks_loops.rst:401 7900msgid "``True`` if first iteration" 7901msgstr "最初の反復の場合は ``True``" 7902 7903#: ../../rst/user_guide/playbooks_loops.rst:402 7904msgid "``ansible_loop.last``" 7905msgstr "``ansible_loop.last``" 7906 7907#: ../../rst/user_guide/playbooks_loops.rst:402 7908msgid "``True`` if last iteration" 7909msgstr "最後の反復の場合は ``True``" 7910 7911#: ../../rst/user_guide/playbooks_loops.rst:403 7912msgid "``ansible_loop.length``" 7913msgstr "``ansible_loop.length``" 7914 7915#: ../../rst/user_guide/playbooks_loops.rst:403 7916msgid "The number of items in the loop" 7917msgstr "ループ内の項目数" 7918 7919#: ../../rst/user_guide/playbooks_loops.rst:404 7920msgid "``ansible_loop.previtem``" 7921msgstr "``ansible_loop.previtem``" 7922 7923#: ../../rst/user_guide/playbooks_loops.rst:404 7924msgid "The item from the previous iteration of the loop. Undefined during the first iteration." 7925msgstr "ループの前の反復の項目。最初の反復では未定義です。" 7926 7927#: ../../rst/user_guide/playbooks_loops.rst:405 7928msgid "``ansible_loop.nextitem``" 7929msgstr "``ansible_loop.nextitem``" 7930 7931#: ../../rst/user_guide/playbooks_loops.rst:405 7932msgid "The item from the following iteration of the loop. Undefined during the last iteration." 7933msgstr "ループの次の反復の項目。最初の反復では未定義です。" 7934 7935#: ../../rst/user_guide/playbooks_loops.rst:414 7936msgid "Accessing the name of your loop_var" 7937msgstr "loop_var の名前へのアクセス" 7938 7939#: ../../rst/user_guide/playbooks_loops.rst:417 7940msgid "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" 7941msgstr "Ansible 2.8 では、``ansible_loop_var`` 変数を使用して ``loop_control.loop_var`` に提供された値の名前を取得できます。" 7942 7943#: ../../rst/user_guide/playbooks_loops.rst:419 7944msgid "For role authors, writing roles that allow loops, instead of dictating the required ``loop_var`` value, you can gather the value via::" 7945msgstr "ロールの作成者は、必要な ``loop_var`` 値を指定する代わりに、ループを許可するロールを作成することで、次の方法で値を収集できます。" 7946 7947#: ../../rst/user_guide/playbooks_loops.rst:426 7948msgid "Migrating from with_X to loop" 7949msgstr "with_X から loop への移行" 7950 7951#: ../../rst/user_guide/shared_snippets/with2loop.txt:1 7952msgid "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``." 7953msgstr "ほとんどの場合、ループは、``with_X`` スタイルのループではなく、``loop`` キーワードで最適に機能します。``loop`` 構文は通常、``query`` や ``lookup`` の複雑な使用ではなく、フィルターを使用して表現できます。" 7954 7955#: ../../rst/user_guide/shared_snippets/with2loop.txt:3 7956msgid "These examples show how to convert many common ``with_`` style loops to ``loop`` and filters." 7957msgstr "以下の例では、一般的な ``with_`` スタイルのループを ``loop`` およびフィルターに変換する方法を示しています。" 7958 7959#: ../../rst/user_guide/shared_snippets/with2loop.txt:6 7960msgid "with_list" 7961msgstr "with_list" 7962 7963#: ../../rst/user_guide/shared_snippets/with2loop.txt:8 7964msgid "``with_list`` is directly replaced by ``loop``." 7965msgstr "``with_list`` は、直接 ``loop`` に置き換えられました。" 7966 7967#: ../../rst/user_guide/shared_snippets/with2loop.txt:27 7968msgid "with_items" 7969msgstr "with_items" 7970 7971#: ../../rst/user_guide/shared_snippets/with2loop.txt:29 7972msgid "``with_items`` is replaced by ``loop`` and the ``flatten`` filter." 7973msgstr "``with_items`` は、``loop`` および ``flatten`` フィルターに置き換えられました。" 7974 7975#: ../../rst/user_guide/shared_snippets/with2loop.txt:44 7976msgid "with_indexed_items" 7977msgstr "with_indexed_items" 7978 7979#: ../../rst/user_guide/shared_snippets/with2loop.txt:46 7980msgid "``with_indexed_items`` is replaced by ``loop``, the ``flatten`` filter and ``loop_control.index_var``." 7981msgstr "``with_indexed_items`` は、``loop``、``flatten`` フィルター、および ``loop_control.index_var`` に置き換えられました。" 7982 7983#: ../../rst/user_guide/shared_snippets/with2loop.txt:63 7984msgid "with_flattened" 7985msgstr "with_flattened" 7986 7987#: ../../rst/user_guide/shared_snippets/with2loop.txt:65 7988msgid "``with_flattened`` is replaced by ``loop`` and the ``flatten`` filter." 7989msgstr "``with_flattened`` は、``loop`` および ``flatten`` フィルターに置き換えられました。" 7990 7991#: ../../rst/user_guide/shared_snippets/with2loop.txt:80 7992msgid "with_together" 7993msgstr "with_together" 7994 7995#: ../../rst/user_guide/shared_snippets/with2loop.txt:82 7996msgid "``with_together`` is replaced by ``loop`` and the ``zip`` filter." 7997msgstr "``with_together`` は、``loop`` および ``zip`` フィルターに置き換えられました。" 7998 7999#: ../../rst/user_guide/shared_snippets/with2loop.txt:98 8000msgid "Another example with complex data" 8001msgstr "複雑なデータがある別の例" 8002 8003#: ../../rst/user_guide/shared_snippets/with2loop.txt:113 8004msgid "with_dict" 8005msgstr "with_dict" 8006 8007#: ../../rst/user_guide/shared_snippets/with2loop.txt:115 8008msgid "``with_dict`` can be substituted by ``loop`` and either the ``dictsort`` or ``dict2items`` filters." 8009msgstr "``with_dict`` は、``loop`` と、``dictsort`` または``dict2items`` のいずれかのフィルターに置き換えられました。" 8010 8011#: ../../rst/user_guide/shared_snippets/with2loop.txt:135 8012msgid "with_sequence" 8013msgstr "with_sequence" 8014 8015#: ../../rst/user_guide/shared_snippets/with2loop.txt:137 8016msgid "``with_sequence`` is replaced by ``loop`` and the ``range`` function, and potentially the ``format`` filter." 8017msgstr "``with_sequence`` は、``loop`` と``range`` の関数、そして潜在的には``format`` フィルターに置き換えられました。" 8018 8019#: ../../rst/user_guide/shared_snippets/with2loop.txt:153 8020msgid "with_subelements" 8021msgstr "with_subelements" 8022 8023#: ../../rst/user_guide/shared_snippets/with2loop.txt:155 8024msgid "``with_subelements`` is replaced by ``loop`` and the ``subelements`` filter." 8025msgstr "``with_subelements`` は、``loop`` および ``subelements`` フィルターに置き換えられました。" 8026 8027#: ../../rst/user_guide/shared_snippets/with2loop.txt:172 8028msgid "with_nested/with_cartesian" 8029msgstr "with_nested/with_cartesian" 8030 8031#: ../../rst/user_guide/shared_snippets/with2loop.txt:174 8032msgid "``with_nested`` and ``with_cartesian`` are replaced by loop and the ``product`` filter." 8033msgstr "``with_nested`` と``with_cartesian`` は、ループと ``product`` のフィルターに置き換えられました。" 8034 8035#: ../../rst/user_guide/shared_snippets/with2loop.txt:191 8036msgid "with_random_choice" 8037msgstr "with_random_choice" 8038 8039#: ../../rst/user_guide/shared_snippets/with2loop.txt:193 8040msgid "``with_random_choice`` is replaced by just use of the ``random`` filter, without need of ``loop``." 8041msgstr "``with_random_choice`` は、``random`` フィルターを使用するだけで、``loop`` を必要とせずに置き換えることができます。" 8042 8043#: ../../rst/user_guide/playbooks_module_defaults.rst:4 8044msgid "Module defaults" 8045msgstr "モジュールのデフォルト" 8046 8047#: ../../rst/user_guide/playbooks_module_defaults.rst:6 8048msgid "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." 8049msgstr "同じ引数で同じモジュールを頻繁に呼び出す場合は、``module_defaults`` キーワードを使用して、その特定のモジュールのデフォルト引数を定義すると便利です。" 8050 8051#: ../../rst/user_guide/playbooks_module_defaults.rst:8 8052msgid "Here is a basic example::" 8053msgstr "以下に基本的な例を示します。" 8054 8055#: ../../rst/user_guide/playbooks_module_defaults.rst:32 8056msgid "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::" 8057msgstr "``module_defaults`` キーワードは、プレイ、ブロック、およびタスクレベルで使用できます。タスクで明示的に指定されたモジュール引数は、そのモジュール引数に対して確立されたデフォルトを上書きします。" 8058 8059#: ../../rst/user_guide/playbooks_module_defaults.rst:42 8060msgid "You can remove any previously established defaults for a module by specifying an empty dict::" 8061msgstr "空のディクショナリーを指定することで、それまでに設定されたモジュールのデフォルトを削除することができます。" 8062 8063#: ../../rst/user_guide/playbooks_module_defaults.rst:52 8064msgid "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." 8065msgstr "プレイレベルで設定されるモジュールのデフォルト (``include_role`` または ``import_role`` を使用する際のブロックまたはタスクのレベル) は、使用されるロールに適用されます。これにより、ロールで予期しない動作が発生する可能性があります。" 8066 8067#: ../../rst/user_guide/playbooks_module_defaults.rst:54 8068msgid "Here are some more realistic use cases for this feature." 8069msgstr "この機能のより実用的なユースケースを以下に示します。" 8070 8071#: ../../rst/user_guide/playbooks_module_defaults.rst:56 8072msgid "Interacting with an API that requires auth::" 8073msgstr "認証をを必要とする API との対話:" 8074 8075#: ../../rst/user_guide/playbooks_module_defaults.rst:77 8076msgid "Setting a default AWS region for specific EC2-related modules::" 8077msgstr "特定の EC2 関連のモジュールにデフォルトの AWS リージョンを設定します。" 8078 8079#: ../../rst/user_guide/playbooks_module_defaults.rst:93 8080msgid "Module defaults groups" 8081msgstr "モジュールのデフォルトグループ" 8082 8083#: ../../rst/user_guide/playbooks_module_defaults.rst:97 8084msgid "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." 8085msgstr "Ansible 2.7 では、共通のパラメーターセットを持つモジュールをまとめて表示するプレビューステータス機能が追加されました。これにより、クラウドモジュールなどの API ベースのモジュールを多用する Playbook の作成が容易になります。" 8086 8087#: ../../rst/user_guide/playbooks_module_defaults.rst:100 8088msgid "Group" 8089msgstr "グループ" 8090 8091#: ../../rst/user_guide/playbooks_module_defaults.rst:100 8092msgid "Purpose" 8093msgstr "目的" 8094 8095#: ../../rst/user_guide/playbooks_module_defaults.rst:100 8096msgid "Ansible Version" 8097msgstr "Ansible バージョン" 8098 8099#: ../../rst/user_guide/playbooks_module_defaults.rst:102 8100msgid "aws" 8101msgstr "aws" 8102 8103#: ../../rst/user_guide/playbooks_module_defaults.rst:102 8104msgid "Amazon Web Services" 8105msgstr "Amazon Web Services" 8106 8107#: ../../rst/user_guide/playbooks_module_defaults.rst:102 8108#: ../../rst/user_guide/playbooks_module_defaults.rst:104 8109#: ../../rst/user_guide/playbooks_module_defaults.rst:106 8110msgid "2.7" 8111msgstr "2.7" 8112 8113#: ../../rst/user_guide/playbooks_module_defaults.rst:104 8114msgid "azure" 8115msgstr "azure" 8116 8117#: ../../rst/user_guide/playbooks_module_defaults.rst:104 8118msgid "Azure" 8119msgstr "Azure" 8120 8121#: ../../rst/user_guide/playbooks_module_defaults.rst:106 8122msgid "gcp" 8123msgstr "gcp" 8124 8125#: ../../rst/user_guide/playbooks_module_defaults.rst:106 8126msgid "Google Cloud Platform" 8127msgstr "Google Cloud Platform" 8128 8129#: ../../rst/user_guide/playbooks_module_defaults.rst:108 8130msgid "k8s" 8131msgstr "k8s" 8132 8133#: ../../rst/user_guide/playbooks_module_defaults.rst:108 8134msgid "Kubernetes" 8135msgstr "Kubernetes" 8136 8137#: ../../rst/user_guide/playbooks_module_defaults.rst:108 8138#: ../../rst/user_guide/playbooks_module_defaults.rst:110 8139msgid "2.8" 8140msgstr "2.8" 8141 8142#: ../../rst/user_guide/playbooks_module_defaults.rst:110 8143msgid "os" 8144msgstr "os" 8145 8146#: ../../rst/user_guide/playbooks_module_defaults.rst:110 8147msgid "OpenStack" 8148msgstr "OpenStack" 8149 8150#: ../../rst/user_guide/playbooks_module_defaults.rst:112 8151msgid "acme" 8152msgstr "acme" 8153 8154#: ../../rst/user_guide/playbooks_module_defaults.rst:112 8155msgid "ACME" 8156msgstr "ACME" 8157 8158#: ../../rst/user_guide/playbooks_module_defaults.rst:112 8159#: ../../rst/user_guide/playbooks_module_defaults.rst:114 8160#: ../../rst/user_guide/playbooks_module_defaults.rst:116 8161#: ../../rst/user_guide/playbooks_module_defaults.rst:118 8162msgid "2.10" 8163msgstr "2.10" 8164 8165#: ../../rst/user_guide/playbooks_module_defaults.rst:114 8166msgid "docker*" 8167msgstr "docker*" 8168 8169#: ../../rst/user_guide/playbooks_module_defaults.rst:114 8170msgid "Docker" 8171msgstr "Docker" 8172 8173#: ../../rst/user_guide/playbooks_module_defaults.rst:116 8174msgid "ovirt" 8175msgstr "ovirt" 8176 8177#: ../../rst/user_guide/playbooks_module_defaults.rst:116 8178msgid "oVirt" 8179msgstr "oVirt" 8180 8181#: ../../rst/user_guide/playbooks_module_defaults.rst:118 8182msgid "vmware" 8183msgstr "vmware" 8184 8185#: ../../rst/user_guide/playbooks_module_defaults.rst:118 8186msgid "VMware" 8187msgstr "VMware" 8188 8189#: ../../rst/user_guide/playbooks_module_defaults.rst:121 8190msgid "The `docker_stack <docker_stack_module>`_ module is not included in the ``docker`` defaults group." 8191msgstr "`docker_stack <docker_stack_module>`_ モジュールは、``docker`` デフォルトグループには含まれません。" 8192 8193#: ../../rst/user_guide/playbooks_module_defaults.rst:123 8194msgid "Use the groups with ``module_defaults`` by prefixing the group name with ``group/`` - for example ``group/aws``." 8195msgstr "グループ名の前に ``group/`` を追加して (例: ``group/aws``)、``module_defaults`` でグループを使用します。" 8196 8197#: ../../rst/user_guide/playbooks_module_defaults.rst:125 8198msgid "In a playbook, you can set module defaults for whole groups of modules, such as setting a common AWS region." 8199msgstr "Playbook では、一般的な AWS リージョンの設定など、モジュールのグループ全体にモジュールのデフォルトを設定できます。" 8200 8201#: ../../rst/user_guide/playbooks_prompts.rst:5 8202msgid "Interactive input: prompts" 8203msgstr "インタラクティブな入力: prompt" 8204 8205#: ../../rst/user_guide/playbooks_prompts.rst:7 8206msgid "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." 8207msgstr "Playbook でユーザーに特定の入力を促したい場合は、「vars_prompt」セクションを追加します。ユーザーに変数の入力を促すことで、パスワードのような機密データの記録を回避することができます。セキュリティーのほかに、プロンプトは柔軟性をサポートします。たとえば、1 つの Playbook を複数のソフトウェアリリースで使用する場合は、特定のリリースバージョンの入力を促すことができます。" 8208 8209#: ../../rst/user_guide/playbooks_prompts.rst:12 8210msgid "Here is a most basic example::" 8211msgstr "以下は最も基本的な例です。" 8212 8213#: ../../rst/user_guide/playbooks_prompts.rst:31 8214msgid "The user input is hidden by default but it can be made visible by setting ``private: no``." 8215msgstr "ユーザー入力はデフォルトでは表示されませんが、``private: no`` を設定することで表示できます。" 8216 8217#: ../../rst/user_guide/playbooks_prompts.rst:34 8218msgid "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 Tower). See :ref:`passing_variables_on_the_command_line`." 8219msgstr "個別の ``vars_prompt`` 変数の入力を求めるプロンプトは、コマンドラインの ``--extra-vars`` オプションですでに定義されている変数や、非対話的なセッション (cron や Ansible Tower など) から実行する場合に省略されます。「:ref:`passing_variables_on_the_command_line`」を参照してください。" 8220 8221#: ../../rst/user_guide/playbooks_prompts.rst:36 8222msgid "If you have a variable that changes infrequently, you can provide a default value that can be overridden::" 8223msgstr "まれに変更する変数がある場合は、上書きできるデフォルト値を指定できます。" 8224 8225#: ../../rst/user_guide/playbooks_prompts.rst:45 8226msgid "Encrypting values supplied by ``vars_prompt``" 8227msgstr "``vars_prompt`` により提供される値の暗号化" 8228 8229#: ../../rst/user_guide/playbooks_prompts.rst:47 8230msgid "You can encrypt the entered value so you can use it, for instance, with the user module to define a password::" 8231msgstr "入力値を暗号化して、たとえばユーザーモジュールを使用してパスワードを定義できます。" 8232 8233#: ../../rst/user_guide/playbooks_prompts.rst:58 8234msgid "If you have `Passlib <https://passlib.readthedocs.io/en/stable/>`_ installed, you can use any crypt scheme the library supports:" 8235msgstr "`Passlib <https://passlib.readthedocs.io/en/stable/>`_ をインストールしている場合は、ライブラリーがサポートする任意の crypt スキームを使用できます。" 8236 8237#: ../../rst/user_guide/playbooks_prompts.rst:60 8238msgid "*des_crypt* - DES Crypt" 8239msgstr "*des_crypt* - DES Crypt" 8240 8241#: ../../rst/user_guide/playbooks_prompts.rst:61 8242msgid "*bsdi_crypt* - BSDi Crypt" 8243msgstr "*bsdi_crypt* - BSDi Crypt" 8244 8245#: ../../rst/user_guide/playbooks_prompts.rst:62 8246msgid "*bigcrypt* - BigCrypt" 8247msgstr "*bigcrypt* - BigCrypt" 8248 8249#: ../../rst/user_guide/playbooks_prompts.rst:63 8250msgid "*crypt16* - Crypt16" 8251msgstr "*crypt16* - Crypt16" 8252 8253#: ../../rst/user_guide/playbooks_prompts.rst:64 8254#: ../../rst/user_guide/playbooks_prompts.rst:87 8255msgid "*md5_crypt* - MD5 Crypt" 8256msgstr "*md5_crypt* - MD5 Crypt" 8257 8258#: ../../rst/user_guide/playbooks_prompts.rst:65 8259#: ../../rst/user_guide/playbooks_prompts.rst:86 8260msgid "*bcrypt* - BCrypt" 8261msgstr "*bcrypt* - BCrypt" 8262 8263#: ../../rst/user_guide/playbooks_prompts.rst:66 8264msgid "*sha1_crypt* - SHA-1 Crypt" 8265msgstr "*sha1_crypt* - SHA-1 Crypt" 8266 8267#: ../../rst/user_guide/playbooks_prompts.rst:67 8268msgid "*sun_md5_crypt* - Sun MD5 Crypt" 8269msgstr "*sun_md5_crypt* - Sun MD5 Crypt" 8270 8271#: ../../rst/user_guide/playbooks_prompts.rst:68 8272#: ../../rst/user_guide/playbooks_prompts.rst:88 8273msgid "*sha256_crypt* - SHA-256 Crypt" 8274msgstr "*sha256_crypt* - SHA-256 Crypt" 8275 8276#: ../../rst/user_guide/playbooks_prompts.rst:69 8277#: ../../rst/user_guide/playbooks_prompts.rst:89 8278msgid "*sha512_crypt* - SHA-512 Crypt" 8279msgstr "*sha512_crypt* - SHA-512 Crypt" 8280 8281#: ../../rst/user_guide/playbooks_prompts.rst:70 8282msgid "*apr_md5_crypt* - Apache's MD5-Crypt variant" 8283msgstr "*apr_md5_crypt* - Apache's MD5-Crypt variant" 8284 8285#: ../../rst/user_guide/playbooks_prompts.rst:71 8286msgid "*phpass* - PHPass' Portable Hash" 8287msgstr "*phpass* - PHPass' Portable Hash" 8288 8289#: ../../rst/user_guide/playbooks_prompts.rst:72 8290msgid "*pbkdf2_digest* - Generic PBKDF2 Hashes" 8291msgstr "*pbkdf2_digest* - Generic PBKDF2 Hashes" 8292 8293#: ../../rst/user_guide/playbooks_prompts.rst:73 8294msgid "*cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash" 8295msgstr "*cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash" 8296 8297#: ../../rst/user_guide/playbooks_prompts.rst:74 8298msgid "*dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash" 8299msgstr "*dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash" 8300 8301#: ../../rst/user_guide/playbooks_prompts.rst:75 8302msgid "*scram* - SCRAM Hash" 8303msgstr "*scram* - SCRAM Hash" 8304 8305#: ../../rst/user_guide/playbooks_prompts.rst:76 8306msgid "*bsd_nthash* - FreeBSD's MCF-compatible nthash encoding" 8307msgstr "*bsd_nthash* - FreeBSD's MCF 互換の nthash エンコーディング" 8308 8309#: ../../rst/user_guide/playbooks_prompts.rst:78 8310msgid "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." 8311msgstr "使用できるパラメーターは「salt」または「salt_size」のみです。「salt」を定義して独自のソルトを使用することも、「salt_size」を使用して自動的に生成されるソルトを使用することもできます。デフォルトでは、Ansible はサイズ 8 の salt を生成します。" 8312 8313#: ../../rst/user_guide/playbooks_prompts.rst:84 8314msgid "If you do not have Passlib installed, Ansible uses the `crypt <https://docs.python.org/2/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:" 8315msgstr "Passlib がインストールされていない場合、Ansible はフォールバックとして `crypt <https://docs.python.org/2/library/crypt.html>`_ ライブラリーを使用します。Ansible は最大で 4 つの暗号方式をサポートしていますが、プラットフォームによっては最大で以下の暗号方式をサポートしています。" 8316 8317#: ../../rst/user_guide/playbooks_prompts.rst:95 8318msgid "Allowing special characters in ``vars_prompt`` values" 8319msgstr "``vars_prompt`` 値での特殊文字の許可" 8320 8321#: ../../rst/user_guide/playbooks_prompts.rst:97 8322msgid "Some special characters, such as ``{`` and ``%`` can create templating errors. If you need to accept special characters, use the ``unsafe`` option::" 8323msgstr "``{`` や ``%`` などの特殊文字は、テンプレートエラーの作成が可能です。特殊文字を受け入れる必要がある場合は、``unsafe`` オプションを使用します。" 8324 8325#: ../../rst/user_guide/playbooks_python_version.rst:5 8326msgid "Python3 in templates" 8327msgstr "テンプレート内の Python3" 8328 8329#: ../../rst/user_guide/playbooks_python_version.rst:7 8330msgid "Ansible uses Jinja2 to leverage 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." 8331msgstr "Ansible は Jinja2 を使用して、テンプレートや変数に Python のデータ型や標準関数を活用しています。これらのデータ型や標準関数を利用することで、データに対して豊富な操作を行うことができます。ただし、テンプレートを使用する場合は、Python のバージョンによる違いに注意する必要があります。" 8332 8333#: ../../rst/user_guide/playbooks_python_version.rst:11 8334msgid "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." 8335msgstr "これらのトピックは、Python2 と Python3 の両方で動作するテンプレートをデザインするのに役立ちます。また、Python2 から Python3 へのアップグレードの際にも役立つでしょう。Python2 や Python3 にアップグレードしても、通常は Jinja2 のテンプレートに影響を与えるような変更はありません。" 8336 8337#: ../../rst/user_guide/playbooks_python_version.rst:16 8338msgid "Dictionary views" 8339msgstr "ディクショナリービュー" 8340 8341#: ../../rst/user_guide/playbooks_python_version.rst:18 8342msgid "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." 8343msgstr "Python2 では、:meth:`dict.keys`、:meth:`dict.values`、および :meth:`dict.items` メソッドはリストを返します。Jinja2 は、Ansible がリストに戻ってきた文字列表現で Ansible に返します。" 8344 8345#: ../../rst/user_guide/playbooks_python_version.rst:22 8346msgid "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:list>` filter whenever using :meth:`dict.keys`, :meth:`dict.values`, or :meth:`dict.items`::" 8347msgstr "Python3 では、これらのメソッドは :ref:`dictionary view <python3:dict-views>` オブジェクトを返します。Jinja2 がディクショナリービューに返す文字列表現は、Ansible ではリストに解析し直すことができません。しかし、:meth:`dict.keys`、:meth:`dict.values`、または :meth:`dict.items` を使用する際には必ず :func:`list <jinja2:list>` フィルターを使用することで、簡単に移植することができます。" 8348 8349#: ../../rst/user_guide/playbooks_python_version.rst:43 8350msgid "dict.iteritems()" 8351msgstr "dict.iteritems()" 8352 8353#: ../../rst/user_guide/playbooks_python_version.rst:45 8354msgid "Python2 dictionaries have :meth:`~dict.iterkeys`, :meth:`~dict.itervalues`, and :meth:`~dict.iteritems` methods." 8355msgstr "Python2 ディクショナリーには、:meth:`~dict.iterkeys` メソッド、:meth:`~dict.itervalues` メソッド、および :meth:`~dict.iteritems` メソッドがあります。" 8356 8357#: ../../rst/user_guide/playbooks_python_version.rst:47 8358msgid "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::" 8359msgstr "Python3 ディクショナリーにはこれらのメソッドがありません。:meth:`dict.keys`、:meth:`dict.values`、および :meth:`dict.items` を使用して、Playbook およびテンプレートを Python2 と Python3 の両方に対応させてください。" 8360 8361#: ../../rst/user_guide/playbooks_python_version.rst:62 8362msgid "The :ref:`pb-py-compat-dict-views` entry for information on why the :func:`list filter <jinja2:list>` is necessary here." 8363msgstr "ここで :func:`list filter <jinja2:list>` が必要な理由は、:ref:`pb-py-compat-dict-views` エントリーを参照してください。" 8364 8365#: ../../rst/user_guide/playbooks_reuse.rst:5 8366msgid "Re-using Ansible artifacts" 8367msgstr "Ansible アーティファクトの再利用" 8368 8369#: ../../rst/user_guide/playbooks_reuse.rst:7 8370msgid "You can write a simple playbook in one very large file, and most users learn the one-file approach first. However, breaking tasks up into different 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, you can re-use them in many playbooks while only maintaining them in one place." 8371msgstr "簡単な Playbook を非常に大きな 1 つのファイルに書くことができるため、ほとんどのユーザーはまず 1 つのファイルを使用した方法を学びます。しかし、タスクを異なるファイルに分割することは、複雑なタスクのセットを整理して再利用するための優れた方法です。小さく分散されたアーティファクトを使用して、同じ変数、タスク、プレイを複数の Playbook で再利用し、異なるユースケースに対応することができます。分散されたアーティファクトは、複数の親 Playbook にまたがって使用することも、1 つの Playbook 内で複数回使用することもできます。たとえば、複数の Playbook の一部として顧客データベースを更新する場合があります。データベースの更新に関連するすべてのタスクをタスクファイルにまとめておけば、それらを 1 カ所で管理するだけで、多くの Playbook で再利用することができます。" 8372 8373#: ../../rst/user_guide/playbooks_reuse.rst:13 8374msgid "Creating re-usable files and roles" 8375msgstr "再利用可能なファイルおよびロールの作成" 8376 8377#: ../../rst/user_guide/playbooks_reuse.rst:15 8378msgid "Ansible offers four distributed, re-usable artifacts: variables files, task files, playbooks, and roles." 8379msgstr "Ansible は、変数ファイル、タスクファイル、Playbook、およびロールの 4 つに分散した再利用可能なアーティファクトを提供します。" 8380 8381#: ../../rst/user_guide/playbooks_reuse.rst:17 8382msgid "A variables file contains only variables." 8383msgstr "変数ファイルには変数のみが含まれます。" 8384 8385#: ../../rst/user_guide/playbooks_reuse.rst:18 8386msgid "A task file contains only tasks." 8387msgstr "タスクファイルにはタスクのみが含まれます。" 8388 8389#: ../../rst/user_guide/playbooks_reuse.rst:19 8390msgid "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." 8391msgstr "Playbook には、少なくとも 1 つのプレイが含まれており、変数、タスク、その他のコンテンツを含むことができます。厳密に焦点を絞った Playbook は再利用できますが、動的にではなく静的にしか再利用できません。" 8392 8393#: ../../rst/user_guide/playbooks_reuse.rst:20 8394msgid "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." 8395msgstr "ロールには、関連するタスク、変数、デフォルト、ハンドラー、さらにはモジュールや他のプラグインのセットが、定義されたファイルツリーに格納されています。変数ファイル、タスクファイル、Playbook とは異なり、ロールは Ansible Galaxy で簡単にアップロードして共有することができます。ロールの作成と使用の詳細については、「:ref:`playbooks_reuse_roles`」を参照してください。" 8396 8397#: ../../rst/user_guide/playbooks_reuse.rst:25 8398msgid "Re-using playbooks" 8399msgstr "Playbook の再利用" 8400 8401#: ../../rst/user_guide/playbooks_reuse.rst:27 8402msgid "You can incorporate multiple playbooks into a main playbook. However, you can only use imports to re-use playbooks. For example:" 8403msgstr "複数の Playbook をメインの Playbook に組み込むことができますが、インポートのみを使用して Playbook を再使用できます。以下に例を示します。" 8404 8405#: ../../rst/user_guide/playbooks_reuse.rst:34 8406msgid "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." 8407msgstr "インポートでは、他の Playbook に静的に Playbook を組み込みます。Ansible は、インポートした各 Playbook 内のプレイやタスクを、メインの Playbook で直接定義した場合と同様に、リストに記載された順に実行します。" 8408 8409#: ../../rst/user_guide/playbooks_reuse.rst:37 8410msgid "Re-using files and roles" 8411msgstr "ファイルおよびロールの再利用" 8412 8413#: ../../rst/user_guide/playbooks_reuse.rst:39 8414msgid "Ansible offers two ways to re-use files and roles in a playbook: dynamic and static." 8415msgstr "Ansible は、Playbook でファイルとロールを再利用する 2 つの方法 (動的および静的) を提供します。" 8416 8417#: ../../rst/user_guide/playbooks_reuse.rst:41 8418msgid "For dynamic re-use, add an ``include_*`` task in the tasks section of a play:" 8419msgstr "動的再利用には、プレイの tasks セクションに ``include_*`` タスクを追加します。" 8420 8421#: ../../rst/user_guide/playbooks_reuse.rst:43 8422msgid ":ref:`include_role <include_role_module>`" 8423msgstr ":ref:`include_role <include_role_module>`" 8424 8425#: ../../rst/user_guide/playbooks_reuse.rst:44 8426msgid ":ref:`include_tasks <include_tasks_module>`" 8427msgstr ":ref:`include_tasks <include_tasks_module>`" 8428 8429#: ../../rst/user_guide/playbooks_reuse.rst:45 8430msgid ":ref:`include_vars <include_vars_module>`" 8431msgstr ":ref:`include_vars <include_vars_module>`" 8432 8433#: ../../rst/user_guide/playbooks_reuse.rst:47 8434msgid "For static re-use, add an ``import_*`` task in the tasks section of a play:" 8435msgstr "静的な再利用の場合は、プレイの tasks セクションに ``import_*`` タスクを追加します。" 8436 8437#: ../../rst/user_guide/playbooks_reuse.rst:49 8438msgid ":ref:`import_role <import_role_module>`" 8439msgstr ":ref:`import_role <import_role_module>`" 8440 8441#: ../../rst/user_guide/playbooks_reuse.rst:50 8442msgid ":ref:`import_tasks <import_tasks_module>`" 8443msgstr ":ref:`import_tasks <import_tasks_module>`" 8444 8445#: ../../rst/user_guide/playbooks_reuse.rst:52 8446msgid "Task include and import statements can be used at arbitrary depth." 8447msgstr "タスクの include 文および import 文は任意の深さで使用できます。" 8448 8449#: ../../rst/user_guide/playbooks_reuse.rst:54 8450msgid "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." 8451msgstr "プレイレベルで裸の :ref:`roles <roles_keyword>` キーワードを使用して、ロールを静的に Playbook に組み込むことは可能です。しかし、かつてタスクファイルと Playbook レベルのインクルードの両方に使用されていた裸の :ref:`include <include_module>` キーワードは、現在では非推奨となっています。" 8452 8453#: ../../rst/user_guide/playbooks_reuse.rst:57 8454msgid "Includes: dynamic re-use" 8455msgstr "インクルード: 動的再利用" 8456 8457#: ../../rst/user_guide/playbooks_reuse.rst:59 8458msgid "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." 8459msgstr "ロール、タスク、または変数をインクルードすると、Playbook に動的に追加されます。Ansible は、Playbook に同梱されるインクルードファイルやロールを処理するため、インクルードタスクは、トップレベルの Playbook 内の以前のタスクの結果によって影響を受ける可能性があります。インクルードされるロールやタスクは、ハンドラーと同様、トップレベルの Playbook 内の他のタスクの結果に応じて、実行されたりされなかったりします。" 8460 8461#: ../../rst/user_guide/playbooks_reuse.rst:61 8462msgid "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." 8463msgstr "``include_*`` 文を使用する主な利点はループです。インクルードでループが使用されると、インクルードされたタスクまたはロールがループの各項目に対して 1 回実行されます。" 8464 8465#: ../../rst/user_guide/playbooks_reuse.rst:63 8466msgid "You can pass variables into includes. See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence." 8467msgstr "変数をインクルードに渡すことができます。変数の継承と優先順位の詳細は、「:ref:`ansible_variable_precedence`」を参照してください。" 8468 8469#: ../../rst/user_guide/playbooks_reuse.rst:66 8470msgid "Imports: static re-use" 8471msgstr "インポート: 静的再利用" 8472 8473#: ../../rst/user_guide/playbooks_reuse.rst:68 8474msgid "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." 8475msgstr "ロール、タスク、または Playbook をインポートすると、それらが静的に Playbook に追加されます。Ansible は、インポートされたファイルやロールを Playbook 内のタスクを実行する前に前処理するため、インポートされたコンテンツがトップレベルの Playbook 内の他のタスクの影響を受けることはありません。" 8476 8477#: ../../rst/user_guide/playbooks_reuse.rst:70 8478msgid "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:" 8479msgstr "インポートには変数を渡すことができます。インポートしたファイルを 1 つの Playbook で複数回実行する場合は、変数を渡す必要があります。以下に例を示します。" 8480 8481#: ../../rst/user_guide/playbooks_reuse.rst:87 8482msgid "See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence." 8483msgstr "変数の継承および優先順位に関する詳細は、「:ref:`ansible_variable_precedence`」を参照してください。" 8484 8485#: ../../rst/user_guide/playbooks_reuse.rst:92 8486msgid "Comparing includes and imports: dynamic and static re-use" 8487msgstr "インクルードとインポートの比較: 動的再利用および静的再利用" 8488 8489#: ../../rst/user_guide/playbooks_reuse.rst:94 8490msgid "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." 8491msgstr "分散した Ansible のアーティファクトを再利用する方法には、それぞれ利点と制限があります。一部の Playbook では動的再利用を行い、他の Playbook では静的再利用を行うことができます。1 つの Playbook で動的再利用と静的再利用の両方を使用することもできますが、Playbook ごとに 1 つのアプローチを選択するのが最善です。静的再利用と動的再利用を混在させると、診断が困難なバグが Playbook に発生する可能性があります。この表で主な違いをまとめています。作成する Playbook ごとに最適な方法を選択してください。" 8492 8493#: ../../rst/user_guide/playbooks_reuse.rst:100 8494msgid "Include_*" 8495msgstr "Include_*" 8496 8497#: ../../rst/user_guide/playbooks_reuse.rst:100 8498msgid "Import_*" 8499msgstr "Import_*" 8500 8501#: ../../rst/user_guide/playbooks_reuse.rst:102 8502msgid "Type of re-use" 8503msgstr "再利用の種類" 8504 8505#: ../../rst/user_guide/playbooks_reuse.rst:102 8506msgid "Dynamic" 8507msgstr "動的" 8508 8509#: ../../rst/user_guide/playbooks_reuse.rst:102 8510msgid "Static" 8511msgstr "静的" 8512 8513#: ../../rst/user_guide/playbooks_reuse.rst:104 8514msgid "When processed" 8515msgstr "処理時" 8516 8517#: ../../rst/user_guide/playbooks_reuse.rst:104 8518msgid "At runtime, when encountered" 8519msgstr "ランタイム時に (発生した場合)" 8520 8521#: ../../rst/user_guide/playbooks_reuse.rst:104 8522msgid "Pre-processed during playbook parsing" 8523msgstr "Playbook の解析中に事前処理" 8524 8525#: ../../rst/user_guide/playbooks_reuse.rst:106 8526msgid "Task or play" 8527msgstr "タスクまたはプレイ" 8528 8529#: ../../rst/user_guide/playbooks_reuse.rst:106 8530msgid "All includes are tasks" 8531msgstr "インクルードはすべてタスク" 8532 8533#: ../../rst/user_guide/playbooks_reuse.rst:106 8534msgid "``import_playbook`` cannot be a task" 8535msgstr "``import_playbook`` タスクにすることはできない" 8536 8537#: ../../rst/user_guide/playbooks_reuse.rst:108 8538msgid "Task options" 8539msgstr "タスクオプション" 8540 8541#: ../../rst/user_guide/playbooks_reuse.rst:108 8542msgid "Apply only to include task itself" 8543msgstr "タスク自体を含める場合にのみ適用" 8544 8545#: ../../rst/user_guide/playbooks_reuse.rst:108 8546msgid "Apply to all child tasks in import" 8547msgstr "インポート中のすべての子タスクに適用" 8548 8549#: ../../rst/user_guide/playbooks_reuse.rst:110 8550msgid "Calling from loops" 8551msgstr "ループからの呼び出し" 8552 8553#: ../../rst/user_guide/playbooks_reuse.rst:110 8554msgid "Executed once for each loop item" 8555msgstr "各ループ項目に対して 1 回実行" 8556 8557#: ../../rst/user_guide/playbooks_reuse.rst:110 8558msgid "Cannot be used in a loop" 8559msgstr "ループでは使用できない" 8560 8561#: ../../rst/user_guide/playbooks_reuse.rst:112 8562msgid "Using ``--list-tags``" 8563msgstr "``--list-tags`` の使用" 8564 8565#: ../../rst/user_guide/playbooks_reuse.rst:112 8566msgid "Tags within includes not listed" 8567msgstr "掲載されていないインクルード内のタグ" 8568 8569#: ../../rst/user_guide/playbooks_reuse.rst:112 8570msgid "All tags appear with ``--list-tags``" 8571msgstr "すべてのタグが ``--list-tags`` で表示" 8572 8573#: ../../rst/user_guide/playbooks_reuse.rst:114 8574msgid "Using ``--list-tasks``" 8575msgstr "``--list-tasks`` の使用" 8576 8577#: ../../rst/user_guide/playbooks_reuse.rst:114 8578msgid "Tasks within includes not listed" 8579msgstr "リストにないインクルード内のタスク" 8580 8581#: ../../rst/user_guide/playbooks_reuse.rst:114 8582msgid "All tasks appear with ``--list-tasks``" 8583msgstr "すべてのタスクが ``--list-tasks`` で表示" 8584 8585#: ../../rst/user_guide/playbooks_reuse.rst:116 8586msgid "Notifying handlers" 8587msgstr "ハンドラーの通知" 8588 8589#: ../../rst/user_guide/playbooks_reuse.rst:116 8590msgid "Cannot trigger handlers within includes" 8591msgstr "インクルード内でハンドラーをトリガーできない" 8592 8593#: ../../rst/user_guide/playbooks_reuse.rst:116 8594msgid "Can trigger individual imported handlers" 8595msgstr "インポートした個別のハンドラーをトリガーできる" 8596 8597#: ../../rst/user_guide/playbooks_reuse.rst:118 8598msgid "Using ``--start-at-task``" 8599msgstr "``--start-at-task`` の使用" 8600 8601#: ../../rst/user_guide/playbooks_reuse.rst:118 8602msgid "Cannot start at tasks within includes" 8603msgstr "インクルード内のタスクで開始できない" 8604 8605#: ../../rst/user_guide/playbooks_reuse.rst:118 8606msgid "Can start at imported tasks" 8607msgstr "インポートされたタスクから始められる" 8608 8609#: ../../rst/user_guide/playbooks_reuse.rst:120 8610msgid "Using inventory variables" 8611msgstr "インベントリー変数の使用" 8612 8613#: ../../rst/user_guide/playbooks_reuse.rst:120 8614msgid "Can ``include_*: {{ inventory_var }}``" 8615msgstr "``include_*: {{ inventory_var }}`` が使用できる" 8616 8617#: ../../rst/user_guide/playbooks_reuse.rst:120 8618msgid "Cannot ``import_*: {{ inventory_var }}``" 8619msgstr "``import_*: {{ inventory_var }}`` が使用できない" 8620 8621#: ../../rst/user_guide/playbooks_reuse.rst:122 8622msgid "With playbooks" 8623msgstr "Playbook の使用" 8624 8625#: ../../rst/user_guide/playbooks_reuse.rst:122 8626msgid "No ``include_playbook``" 8627msgstr "``include_playbook`` なし" 8628 8629#: ../../rst/user_guide/playbooks_reuse.rst:122 8630msgid "Can import full playbooks" 8631msgstr "完全な Playbook をインポートできる" 8632 8633#: ../../rst/user_guide/playbooks_reuse.rst:124 8634msgid "With variables files" 8635msgstr "変数ファイルの使用" 8636 8637#: ../../rst/user_guide/playbooks_reuse.rst:124 8638msgid "Can include variables files" 8639msgstr "変数ファイルを含めることができる" 8640 8641#: ../../rst/user_guide/playbooks_reuse.rst:124 8642msgid "Use ``vars_files:`` to import variables" 8643msgstr "``vars_files:`` を使用して変数をインポート" 8644 8645#: ../../rst/user_guide/playbooks_reuse.rst:130 8646msgid "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." 8647msgstr "また、リソースの消費やパフォーマンスに大きな違いがあり、インポートは非常に柔軟で高速ですが、インクルードには多くの管理と会計が必要になります。" 8648 8649#: ../../rst/user_guide/playbooks_reuse.rst:134 8650msgid "Re-using tasks as handlers" 8651msgstr "タスクをハンドラーとして再利用" 8652 8653#: ../../rst/user_guide/playbooks_reuse.rst:136 8654msgid "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:" 8655msgstr "Playbook の :ref:`handlers` セクションでインクルードおよびインポートを使用することもできます。たとえば、Apache の再起動方法を定義する場合は、すべての Playbook に対して一度だけ設定する必要があります。``restarts.yml`` ファイルを以下のように行うことができます。" 8656 8657#: ../../rst/user_guide/playbooks_reuse.rst:151 8658msgid "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." 8659msgstr "ハンドラーはインポートとインクルードのどちらからでも起動できますが、その手順は再利用の方法ごとに異なります。ファイルをインクルードする場合は、インクルード自体を通知する必要があり、これにより ``restarts.yml`` のすべてのタスクが発生します。ファイルをインポートする場合は、``restarts.yml`` 内の個々のタスクを通知する必要があります。直接的なタスクやハンドラーと、インクルードまたはインポートされたタスクやハンドラーを混在させることができます。" 8660 8661#: ../../rst/user_guide/playbooks_reuse.rst:154 8662msgid "Triggering included (dynamic) handlers" 8663msgstr "インクルード (動的) ハンドラーのトリガー" 8664 8665#: ../../rst/user_guide/playbooks_reuse.rst:156 8666msgid "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:" 8667msgstr "インクルードはランタイムに実行されるため、インクルードの名前はプレイの実行中に存在しますが、インクルードされたタスクはインクルード自体がトリガーされるまで存在しません。``Restart apache`` タスクを動的再利用で使用するには、インクルード自体の名前を参照します。この方法では、インクルードファイル内のすべてのタスクがハンドラーとしてトリガーされます。たとえば、上に示したタスクファイルでは、以下のようになります。" 8668 8669#: ../../rst/user_guide/playbooks_reuse.rst:170 8670msgid "Triggering imported (static) handlers" 8671msgstr "インポートされた (静的) ハンドラーのトリガー" 8672 8673#: ../../rst/user_guide/playbooks_reuse.rst:172 8674msgid "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:" 8675msgstr "インポートは再生開始前に処理されるため、インポートの名前は再生実行中には存在しませんが、インポートされた各タスクの名前は存在します。``Restart apache`` タスクを静的に再利用して使用するには、インポートされたファイル内の各タスクの名前を参照する必要があります。たとえば、上述のタスクファイルであれば、以下のようになります。" 8676 8677#: ../../rst/user_guide/playbooks_reuse.rst:189 8678msgid ":ref:`utilities_modules`" 8679msgstr ":ref:`utilities_modules`" 8680 8681#: ../../rst/user_guide/playbooks_reuse.rst:190 8682msgid "Documentation of the ``include*`` and ``import*`` modules discussed here." 8683msgstr "ここで説明する ``include*`` モジュールおよび ``import*`` モジュールに関するドキュメント" 8684 8685#: ../../rst/user_guide/playbooks_reuse.rst:192 8686#: ../../rst/user_guide/playbooks_reuse_includes.rst:16 8687#: ../../rst/user_guide/playbooks_reuse_roles.rst:602 8688#: ../../rst/user_guide/playbooks_roles.rst:16 8689msgid "Review the basic Playbook language features" 8690msgstr "基本的な Playbook 言語機能の確認" 8691 8692#: ../../rst/user_guide/playbooks_reuse.rst:194 8693#: ../../rst/user_guide/playbooks_reuse_includes.rst:20 8694msgid "All about variables in playbooks" 8695msgstr "Playbook の変数の詳細のすべて" 8696 8697#: ../../rst/user_guide/playbooks_reuse.rst:196 8698#: ../../rst/user_guide/playbooks_reuse_includes.rst:22 8699#: ../../rst/user_guide/playbooks_reuse_roles.rst:608 8700msgid "Conditionals in playbooks" 8701msgstr "Playbook の条件" 8702 8703#: ../../rst/user_guide/playbooks_reuse.rst:198 8704#: ../../rst/user_guide/playbooks_reuse_includes.rst:24 8705#: ../../rst/user_guide/playbooks_reuse_roles.rst:610 8706msgid "Loops in playbooks" 8707msgstr "Playbook のループ" 8708 8709#: ../../rst/user_guide/playbooks_reuse.rst:201 8710#: ../../rst/user_guide/playbooks_reuse_roles.rst:597 8711#: ../../rst/user_guide/playbooks_roles.rst:13 8712msgid ":ref:`ansible_galaxy`" 8713msgstr ":ref:`ansible_galaxy`" 8714 8715#: ../../rst/user_guide/playbooks_reuse.rst:202 8716#: ../../rst/user_guide/playbooks_roles.rst:14 8717msgid "How to share roles on galaxy, role management" 8718msgstr "Galaxy (ロール管理) におけるロールの共有方法" 8719 8720#: ../../rst/user_guide/playbooks_reuse.rst:203 8721#: ../../rst/user_guide/playbooks_reuse_includes.rst:29 8722#: ../../rst/user_guide/playbooks_reuse_roles.rst:617 8723msgid "`GitHub Ansible examples <https://github.com/ansible/ansible-examples>`_" 8724msgstr "`GitHub Ansible の例 <https://github.com/ansible/ansible-examples>`_" 8725 8726#: ../../rst/user_guide/playbooks_reuse.rst:204 8727#: ../../rst/user_guide/playbooks_reuse_includes.rst:30 8728#: ../../rst/user_guide/playbooks_reuse_roles.rst:618 8729msgid "Complete playbook files from the GitHub project source" 8730msgstr "Github プロジェクトソースの完全な Playbook ファイル" 8731 8732#: ../../rst/user_guide/playbooks_reuse_includes.rst:6 8733msgid "Including and importing" 8734msgstr "インクルードおよびインポート" 8735 8736#: ../../rst/user_guide/playbooks_reuse_includes.rst:8 8737msgid "The content on this page has been moved to :ref:`playbooks_reuse`." 8738msgstr "このページのコンテンツは :ref:`playbooks_reuse` に移動しました。" 8739 8740#: ../../rst/user_guide/playbooks_reuse_roles.rst:5 8741msgid "Roles" 8742msgstr "ロール" 8743 8744#: ../../rst/user_guide/playbooks_reuse_roles.rst:7 8745msgid "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." 8746msgstr "ロールを使用すると、既知のファイル構造に基づいて、関連の変数、ファイル、タスク、ハンドラー、およびその他の Ansible アーティファクトを自動的に読み込むことができます。ロール内のコンテンツをグループ化した後、簡単に再利用でき、他のユーザーと共有できます。" 8747 8748#: ../../rst/user_guide/playbooks_reuse_roles.rst:13 8749msgid "Role directory structure" 8750msgstr "ロールのディレクトリー構造" 8751 8752#: ../../rst/user_guide/playbooks_reuse_roles.rst:15 8753msgid "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:" 8754msgstr "Ansible ロールには、8 つの主要な標準ディレクトリーを持つ定義されたディレクトリー構造があります。各ロールには、ディレクトリーを少なくとも 1 つ含める必要があります。ロールが使用されないディレクトリーは除外できます。以下に例を示します。" 8755 8756#: ../../rst/user_guide/playbooks_reuse_roles.rst:38 8757msgid "By default Ansible will look in each directory within a role for a ``main.yml`` file for relevant content (also ``main.yaml`` and ``main``):" 8758msgstr "デフォルトでは、Ansible はロール内の各ディレクトリーで、関連するコンテンツ (``main.yaml`` および ``main``) について ``main.yml`` ファイルを検索します。" 8759 8760#: ../../rst/user_guide/playbooks_reuse_roles.rst:40 8761msgid "``tasks/main.yml`` - the main list of tasks that the role executes." 8762msgstr "``tasks/main.yml`` - ロールが実行するタスクの主なリスト。" 8763 8764#: ../../rst/user_guide/playbooks_reuse_roles.rst:41 8765msgid "``handlers/main.yml`` - handlers, which may be used within or outside this role." 8766msgstr "``handlers/main.yml`` - このロール内外で使用できるハンドラー。" 8767 8768#: ../../rst/user_guide/playbooks_reuse_roles.rst:42 8769msgid "``library/my_module.py`` - modules, which may be used within this role (see :ref:`embedding_modules_and_plugins_in_roles` for more information)." 8770msgstr "``library/my_module.py`` - このロール内で使用できるモジュール (詳細は「:ref:`embedding_modules_and_plugins_in_roles`」を参照)。" 8771 8772#: ../../rst/user_guide/playbooks_reuse_roles.rst:43 8773msgid "``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." 8774msgstr "``defaults/main.yml`` - ロールのデフォルト変数 (詳細は「:ref:`playbooks_variables`」を参照)。これらの変数には、利用可能な変数の中で一番低い優先順位があり、インベントリー変数など、他の変数で簡単に上書きできます。" 8775 8776#: ../../rst/user_guide/playbooks_reuse_roles.rst:44 8777msgid "``vars/main.yml`` - other variables for the role (see :ref:`playbooks_variables` for more information)." 8778msgstr "``vars/main.yml`` - ロールの他の変数 (詳細は :ref:`playbooks_variables` を参照)。" 8779 8780#: ../../rst/user_guide/playbooks_reuse_roles.rst:45 8781msgid "``files/main.yml`` - files that the role deploys." 8782msgstr "``files/main.yml`` - ロールがデプロイするファイル。" 8783 8784#: ../../rst/user_guide/playbooks_reuse_roles.rst:46 8785msgid "``templates/main.yml`` - templates that the role deploys." 8786msgstr "``templates/main.yml`` - ロールがデプロイするテンプレート。" 8787 8788#: ../../rst/user_guide/playbooks_reuse_roles.rst:47 8789msgid "``meta/main.yml`` - metadata for the role, including role dependencies." 8790msgstr "``meta/main.yml`` - ロールの依存関係を含むロールのメタデータ。" 8791 8792#: ../../rst/user_guide/playbooks_reuse_roles.rst:49 8793msgid "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:" 8794msgstr "他の YAML ファイルを一部のディレクトリーに追加できます。たとえば、プラットフォーム固有のタスクを別々のファイルに配置し、それらを ``tasks/main.yml`` ファイルで参照できます。" 8795 8796#: ../../rst/user_guide/playbooks_reuse_roles.rst:74 8797msgid "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." 8798msgstr "ロールには、``library`` と呼ばれるディレクトリーにモジュールおよびその他のプラグインタイプが含まれる場合があります。詳細は、以下の「:ref:`embedding_modules_and_plugins_in_roles`」を参照してください。" 8799 8800#: ../../rst/user_guide/playbooks_reuse_roles.rst:79 8801msgid "Storing and finding roles" 8802msgstr "ロールの保存および検索" 8803 8804#: ../../rst/user_guide/playbooks_reuse_roles.rst:81 8805msgid "By default, Ansible looks for roles in two locations:" 8806msgstr "デフォルトでは、Ansible は 2 つの場所でロールを検索します。" 8807 8808#: ../../rst/user_guide/playbooks_reuse_roles.rst:83 8809msgid "in a directory called ``roles/``, relative to the playbook file" 8810msgstr "``roles/`` という名前のディレクトリー (Playbook ファイルへの相対パス) で" 8811 8812#: ../../rst/user_guide/playbooks_reuse_roles.rst:84 8813msgid "in ``/usr/local/etc/ansible/roles``" 8814msgstr "``/usr/local/etc/ansible/roles`` で" 8815 8816#: ../../rst/user_guide/playbooks_reuse_roles.rst:86 8817msgid "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." 8818msgstr "ロールを別の場所に保存する場合は、Ansible がロールを見つけることができるように、:ref:`roles_path <DEFAULT_ROLES_PATH>` 設定オプションを設定します。共有ロールを 1 つの場所にチェックインすることで、複数の Playbook で簡単に使用できます。ansible.cfg の設定に関する詳細は、「:ref:`intro_configuration`」を参照してください。" 8819 8820#: ../../rst/user_guide/playbooks_reuse_roles.rst:88 8821msgid "Alternatively, you can call a role with a fully qualified path:" 8822msgstr "または、完全修飾パスでロールを呼び出すことができます。" 8823 8824#: ../../rst/user_guide/playbooks_reuse_roles.rst:98 8825msgid "Using roles" 8826msgstr "ロールの使用" 8827 8828#: ../../rst/user_guide/playbooks_reuse_roles.rst:100 8829msgid "You can use roles in three ways:" 8830msgstr "以下の 3 つの方法でロールを使用できます。" 8831 8832#: ../../rst/user_guide/playbooks_reuse_roles.rst:102 8833msgid "at the play level with the ``roles`` option: This is the classic way of using roles in a play." 8834msgstr "``roles`` オプションを使用してプレイレベルで: プレイでロールを使用する従来の方式です。" 8835 8836#: ../../rst/user_guide/playbooks_reuse_roles.rst:103 8837msgid "at the tasks level with ``include_role``: You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``." 8838msgstr "``include_role`` を使用してタスクレベルで: ``include_role`` を使用してプレイの ``tasks`` セクションのどこからでもロールを動的に再利用できます。" 8839 8840#: ../../rst/user_guide/playbooks_reuse_roles.rst:104 8841msgid "at the tasks level with ``import_role``: You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``." 8842msgstr "``import_role`` を使用してタスクレベルで: ``import_role`` を使用してプレイの ``tasks`` セクションのどこからでもロールを静的に再利用できます。" 8843 8844#: ../../rst/user_guide/playbooks_reuse_roles.rst:109 8845msgid "Using roles at the play level" 8846msgstr "プレイレベルでのロールの使用" 8847 8848#: ../../rst/user_guide/playbooks_reuse_roles.rst:111 8849msgid "The classic (original) way to use roles is with the ``roles`` option for a given play:" 8850msgstr "ロールを使用する従来の (元の) 方法は、特定のプレイの ``roles`` オプションを使用して行います。" 8851 8852#: ../../rst/user_guide/playbooks_reuse_roles.rst:121 8853msgid "When you use the ``roles`` option at the play level, for each role 'x':" 8854msgstr "プレイレベルで ``roles`` オプションを使用する場合は、各ロール「x」に対して以下のように設定します。" 8855 8856#: ../../rst/user_guide/playbooks_reuse_roles.rst:123 8857msgid "If roles/x/tasks/main.yml exists, Ansible adds the tasks in that file to the play." 8858msgstr "roles/x/tasks/main.yml が存在する場合、Ansible はそのファイルのタスクをプレイに追加します。" 8859 8860#: ../../rst/user_guide/playbooks_reuse_roles.rst:124 8861msgid "If roles/x/handlers/main.yml exists, Ansible adds the handlers in that file to the play." 8862msgstr "roles/x/handlers/main.yml が存在する場合、Ansible はそのファイルのハンドラーをプレイに追加します。" 8863 8864#: ../../rst/user_guide/playbooks_reuse_roles.rst:125 8865msgid "If roles/x/vars/main.yml exists, Ansible adds the variables in that file to the play." 8866msgstr "roles/x/vars/main.yml が存在する場合、Ansible はそのファイルの変数をプレイに追加します。" 8867 8868#: ../../rst/user_guide/playbooks_reuse_roles.rst:126 8869msgid "If roles/x/defaults/main.yml exists, Ansible adds the variables in that file to the play." 8870msgstr "roles/x/defaults/main.yml が存在する場合、Ansible はそのファイルの変数をプレイに追加します。" 8871 8872#: ../../rst/user_guide/playbooks_reuse_roles.rst:127 8873msgid "If roles/x/meta/main.yml exists, Ansible adds any role dependencies in that file to the list of roles." 8874msgstr "roles/x/meta/main.yml が存在する場合、Ansible はそのファイル内のすべてのロールの依存関係をロールのリストに追加します。" 8875 8876#: ../../rst/user_guide/playbooks_reuse_roles.rst:128 8877msgid "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." 8878msgstr "コピー、スクリプト、テンプレート、またはインクルードタスク (ロール内) は、相対パスや絶対パスを必要とせずに roles/x/{files,templates,tasks}/ (ディレクトリーはタスクに依存します) のファイルを参照できます。" 8879 8880#: ../../rst/user_guide/playbooks_reuse_roles.rst:130 8881msgid "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 your playbook in this order:" 8882msgstr "プレイレベルで ``roles`` オプションを使用すると、Ansible はロールを静的インポートとして処理し、Playbook の解析時に処理します。Ansible は以下の順序で Playbook を実行します。" 8883 8884#: ../../rst/user_guide/playbooks_reuse_roles.rst:132 8885msgid "Any ``pre_tasks`` defined in the play." 8886msgstr "プレイに定義されているすべての ``pre_tasks``。" 8887 8888#: ../../rst/user_guide/playbooks_reuse_roles.rst:133 8889msgid "Any handlers triggered by pre_tasks." 8890msgstr "ハンドラーは、pre_tasks により誘発されます。" 8891 8892#: ../../rst/user_guide/playbooks_reuse_roles.rst:134 8893msgid "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." 8894msgstr "``roles:`` に一覧表示される順序で、各ロールがリストされます。ロールの ``meta/main.yml`` で定義されたロール依存関係は、タグのフィルタリングおよび条件に基づいて最初に実行されます。詳細は、「:ref:`role_dependencies`」を参照してください。" 8895 8896#: ../../rst/user_guide/playbooks_reuse_roles.rst:135 8897msgid "Any ``tasks`` defined in the play." 8898msgstr "プレイに定義されているすべての ``tasks``。" 8899 8900#: ../../rst/user_guide/playbooks_reuse_roles.rst:136 8901msgid "Any handlers triggered by the roles or tasks." 8902msgstr "ロールやタスクによってトリガーされるすべてのハンドラー。" 8903 8904#: ../../rst/user_guide/playbooks_reuse_roles.rst:137 8905msgid "Any ``post_tasks`` defined in the play." 8906msgstr "プレイに定義されているすべての ``post_tasks``。" 8907 8908#: ../../rst/user_guide/playbooks_reuse_roles.rst:138 8909msgid "Any handlers triggered by post_tasks." 8910msgstr "ハンドラーは、post_tasks により誘発されます。" 8911 8912#: ../../rst/user_guide/playbooks_reuse_roles.rst:141 8913msgid "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." 8914msgstr "ロール内のタスクにタグを使用する場合は、pre_tasks、post_tasks、およびロールの依存関係にもタグを付けて、それらも渡すようにしてください。特に、事前または事後のタスクおよびロールの依存関係が、停止時のウィンドウ制御や負荷分散の監視に使用されている場合は、そのようにしてください。タグの追加と使用の詳細は、「:ref:`tags`」を参照してください。" 8915 8916#: ../../rst/user_guide/playbooks_reuse_roles.rst:143 8917msgid "You can pass other keywords to the ``roles`` option:" 8918msgstr "他のキーワードを ``roles`` オプションに渡すことができます。" 8919 8920#: ../../rst/user_guide/playbooks_reuse_roles.rst:162 8921msgid "When you add a tag to the ``role`` option, Ansible applies the tag to ALL tasks within the role." 8922msgstr "タグを ``role`` オプションに追加すると、Ansible はタグをロール内のすべてのタスクに適用します。" 8923 8924#: ../../rst/user_guide/playbooks_reuse_roles.rst:164 8925msgid "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`." 8926msgstr "Playbook の ``roles:`` セクションで ``vars:`` を使用すると、変数がプレイ変数に追加され、ロールの前後にプレイ内のすべてのタスクで利用できるようになります。この動作は :ref:`DEFAULT_PRIVATE_ROLE_VARS` で変更できます。" 8927 8928#: ../../rst/user_guide/playbooks_reuse_roles.rst:167 8929msgid "Including roles: dynamic reuse" 8930msgstr "ロールの追加: 動的な再利用" 8931 8932#: ../../rst/user_guide/playbooks_reuse_roles.rst:169 8933msgid "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 playbook, 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." 8934msgstr "``include_role`` を使用すると、プレイの ``tasks`` セクション内の任意の場所でロールを動的に再利用することができます。``roles`` セクションで追加されたロールは Playbook 内の他のタスクよりも先に実行されますが、含まれるロールは定義された順に実行されます。``include_role`` のタスクの前に他のタスクがある場合は、他のタスクが先に実行します。" 8935 8936#: ../../rst/user_guide/playbooks_reuse_roles.rst:171 8937msgid "To include a role:" 8938msgstr "ロールを指定するには、以下を実行します。" 8939 8940#: ../../rst/user_guide/playbooks_reuse_roles.rst:190 8941msgid "You can pass other keywords, including variables and tags, when including roles:" 8942msgstr "ロールを含める際には、変数やタグなど、他のキーワードを渡すことができます。" 8943 8944#: ../../rst/user_guide/playbooks_reuse_roles.rst:206 8945msgid "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." 8946msgstr "``include_role`` タスクに :ref:`tag <tags>` を追加すると、Ansible はインクルード自体に `only` というタグを適用します。つまり、``--tags`` を渡して、ロールから選択されたタスクのみを実行することができます。ただし、それらのタスク自体が include 文と同じタグを持っている場合に限ります。詳細は、「:ref:`selective_reuse`」を参照してください。" 8947 8948#: ../../rst/user_guide/playbooks_reuse_roles.rst:208 8949msgid "You can conditionally include a role:" 8950msgstr "ロールを条件付きで含めることができます。" 8951 8952#: ../../rst/user_guide/playbooks_reuse_roles.rst:221 8953msgid "Importing roles: static reuse" 8954msgstr "ロールのインポート: 静的再利用" 8955 8956#: ../../rst/user_guide/playbooks_reuse_roles.rst:223 8957msgid "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:" 8958msgstr "``import_role`` を使用してプレイの ``tasks`` セクションの任意の場所に、ロールを静的に再利用できます。動作は、``roles`` キーワードの使用と同じです。以下に例を示します。" 8959 8960#: ../../rst/user_guide/playbooks_reuse_roles.rst:242 8961msgid "You can pass other keywords, including variables and tags, when importing roles:" 8962msgstr "ロールをインポートする際には、変数やタグなど、他のキーワードを渡すことができます。" 8963 8964#: ../../rst/user_guide/playbooks_reuse_roles.rst:257 8965msgid "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." 8966msgstr "タグを ``import_role`` 文に追加すると、Ansible はタグをロール内の `all` タスクに適用します。詳細は、「:ref:`tag_inheritance`」を参照してください。" 8967 8968#: ../../rst/user_guide/playbooks_reuse_roles.rst:260 8969msgid "Role argument validation" 8970msgstr "ロール引数を検証する" 8971 8972#: ../../rst/user_guide/playbooks_reuse_roles.rst:262 8973msgid "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." 8974msgstr "バージョン 2.11 以降では、引数の仕様に基づいてロールの引数検証を有効にすることができます。この仕様は、``meta/argument_specs.yml`` ファイル (または ``.yaml`` ファイル拡張子) で定義されます。この引数仕様が定義されると、ロール実行の最初に新しいタスクが挿入され、仕様に対して、ロールに指定したパラメーターを検証します。パラメーターの検証に失敗した場合は、ロールの実行が失敗します。" 8975 8976#: ../../rst/user_guide/playbooks_reuse_roles.rst:270 8977msgid "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." 8978msgstr "Ansible は、ロールの ``meta/main.yml`` ファイルで定義されるロールの仕様もサポートしますが、このファイル内の仕様を定義するロールは 2.11 未満のバージョンでは動作しません。そのため、``meta/argument_specs.yml`` ファイルを使用して後方互換性を維持することが推奨されます。" 8979 8980#: ../../rst/user_guide/playbooks_reuse_roles.rst:276 8981msgid "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." 8982msgstr ":ref:`dependencies <role_dependencies>` を定義しているロールにロールの引数検証が使用されている場合は、依存するロールの引数検証が失敗しても、それらの依存関係の検証は依存するロールの前に実行します。" 8983 8984#: ../../rst/user_guide/playbooks_reuse_roles.rst:281 8985msgid "Specification format" 8986msgstr "仕様の形式" 8987 8988#: ../../rst/user_guide/playbooks_reuse_roles.rst:283 8989msgid "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." 8990msgstr "ロール引数の指定は、ロール ``meta/argument_specs.yml`` ファイルの上位の ``argument_specs`` ブロックで定義する必要があります。すべてのフィールドは小文字になります。" 8991 8992#: ../../rst/user_guide/playbooks_reuse_roles.rst 8993msgid "entry-point-name" 8994msgstr "entry-point-name" 8995 8996#: ../../rst/user_guide/playbooks_reuse_roles.rst:288 8997msgid "The name of the role entry point." 8998msgstr "ロールエントリーポイントの名前。" 8999 9000#: ../../rst/user_guide/playbooks_reuse_roles.rst:289 9001msgid "This should be ``main`` in the case of an unspecified entry point." 9002msgstr "これは、エントリーポイントが未指定の場合は ``main`` である必要があります。" 9003 9004#: ../../rst/user_guide/playbooks_reuse_roles.rst:290 9005msgid "This will be the base name of the tasks file to execute, with no ``.yml`` or ``.yaml`` file extension." 9006msgstr "これは、ファイル拡張子 ``.yml`` または ``.yaml`` のない、実行するタスクファイルのベース名です。" 9007 9008#: ../../rst/user_guide/playbooks_reuse_roles.rst 9009msgid "short_description" 9010msgstr "short_description" 9011 9012#: ../../rst/user_guide/playbooks_reuse_roles.rst:294 9013msgid "A short, one-line description of the entry point." 9014msgstr "エントリーポイントの 1 行の短い説明。" 9015 9016#: ../../rst/user_guide/playbooks_reuse_roles.rst:295 9017msgid "The ``short_description`` is displayed by ``ansible-doc -t role -l``." 9018msgstr "``short_description`` は、``ansible-doc -t role -l`` に表示されます。" 9019 9020#: ../../rst/user_guide/playbooks_reuse_roles.rst 9021msgid "description" 9022msgstr "description" 9023 9024#: ../../rst/user_guide/playbooks_reuse_roles.rst:299 9025msgid "A longer description that may contain multiple lines." 9026msgstr "複数の行が含まれる可能性のある長い説明。" 9027 9028#: ../../rst/user_guide/playbooks_reuse_roles.rst 9029msgid "author" 9030msgstr "author" 9031 9032#: ../../rst/user_guide/playbooks_reuse_roles.rst:303 9033msgid "Name of the entry point authors." 9034msgstr "エントリーポイント作成者の名前。" 9035 9036#: ../../rst/user_guide/playbooks_reuse_roles.rst:304 9037msgid "Use a multi-line list if there is more than one author." 9038msgstr "作成者が複数になる場合は、複数行のリストを使用します。" 9039 9040#: ../../rst/user_guide/playbooks_reuse_roles.rst 9041msgid "options" 9042msgstr "options" 9043 9044#: ../../rst/user_guide/playbooks_reuse_roles.rst:308 9045msgid "Options are often called \"parameters\" or \"arguments\". This section defines those options." 9046msgstr "オプションは、しばしば「パラメーター」や「引数」と呼ばれます。このセクションでは、それらのオプションを定義します。" 9047 9048#: ../../rst/user_guide/playbooks_reuse_roles.rst:309 9049msgid "For each role option (argument), you may include:" 9050msgstr "各ロールオプション (引数) に以下を含めることができます。" 9051 9052#: ../../rst/user_guide/playbooks_reuse_roles.rst 9053msgid "option-name" 9054msgstr "option-name" 9055 9056#: ../../rst/user_guide/playbooks_reuse_roles.rst:313 9057msgid "The name of the option/argument." 9058msgstr "オプション/引数の名前。" 9059 9060#: ../../rst/user_guide/playbooks_reuse_roles.rst:317 9061msgid "Detailed explanation of what this option does. It should be written in full sentences." 9062msgstr "* このオプションの機能の詳細な説明。これは、完全な文章で記述する必要があります。" 9063 9064#: ../../rst/user_guide/playbooks_reuse_roles.rst 9065msgid "type" 9066msgstr "type" 9067 9068#: ../../rst/user_guide/playbooks_reuse_roles.rst:321 9069msgid "The data type of the option. Default is ``str``." 9070msgstr "オプションのデータタイプ。デフォルトは ``str`` です。" 9071 9072#: ../../rst/user_guide/playbooks_reuse_roles.rst:322 9073msgid "If an option is of type ``list``, ``elements`` should be specified." 9074msgstr "オプションが ``list`` タイプの場合は、``elements`` を指定する必要があります。" 9075 9076#: ../../rst/user_guide/playbooks_reuse_roles.rst 9077msgid "required" 9078msgstr "必須" 9079 9080#: ../../rst/user_guide/playbooks_reuse_roles.rst:326 9081msgid "Only needed if ``true``." 9082msgstr "``true`` の場合にのみ必要です。" 9083 9084#: ../../rst/user_guide/playbooks_reuse_roles.rst:327 9085msgid "If missing, the option is not required." 9086msgstr "見つからない場合、そのオプションは必要ありません。" 9087 9088#: ../../rst/user_guide/playbooks_reuse_roles.rst 9089msgid "default" 9090msgstr "default" 9091 9092#: ../../rst/user_guide/playbooks_reuse_roles.rst:331 9093msgid "If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing)." 9094msgstr "``required`` が false もしくは指定されていない場合は、``default`` を指定できます (見つからない場合は「null」と見なされます)。" 9095 9096#: ../../rst/user_guide/playbooks_reuse_roles.rst:332 9097msgid "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``." 9098msgstr "ドキュメントのデフォルト値が、コードのデフォルト値と一致していることを確認します。ロール変数の実際のデフォルトは常に ``defaults/main.yml`` から取得されます。" 9099 9100#: ../../rst/user_guide/playbooks_reuse_roles.rst:334 9101msgid "The default field must not be listed as part of the description, unless it requires additional information or conditions." 9102msgstr "追加の情報や条件が必要な場合を除き、デフォルトのフィールドは、説明の一部として記載しないでください。" 9103 9104#: ../../rst/user_guide/playbooks_reuse_roles.rst:335 9105msgid "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." 9106msgstr "オプションがブール値の場合は、Ansible が認識する任意のブール値 (true/false、yes/no など) を使用できます。オプションのコンテキストで読み取りが適切であればこれを選択します。" 9107 9108#: ../../rst/user_guide/playbooks_reuse_roles.rst 9109msgid "choices" 9110msgstr "choices" 9111 9112#: ../../rst/user_guide/playbooks_reuse_roles.rst:340 9113msgid "List of option values." 9114msgstr "* オプション値のリスト。" 9115 9116#: ../../rst/user_guide/playbooks_reuse_roles.rst:341 9117msgid "Should be absent if empty." 9118msgstr "空欄の場合は指定なしになります。" 9119 9120#: ../../rst/user_guide/playbooks_reuse_roles.rst 9121msgid "elements" 9122msgstr "elements" 9123 9124#: ../../rst/user_guide/playbooks_reuse_roles.rst:345 9125msgid "Specifies the data type for list elements when type is ``list``." 9126msgstr "タイプが ``list`` の場合に、リスト要素のデータ型を指定します。" 9127 9128#: ../../rst/user_guide/playbooks_reuse_roles.rst:349 9129msgid "If this option takes a dict or list of dicts, you can define the structure here." 9130msgstr "このオプションがディクショナリーまたはディクショナリーの一覧を取る場合は、ここで構造を定義できます。" 9131 9132#: ../../rst/user_guide/playbooks_reuse_roles.rst:352 9133msgid "Sample specification" 9134msgstr "サンプル仕様" 9135 9136#: ../../rst/user_guide/playbooks_reuse_roles.rst:387 9137msgid "Running a role multiple times in one playbook" 9138msgstr "1 つの Playbook でロールを複数回実行する" 9139 9140#: ../../rst/user_guide/playbooks_reuse_roles.rst:389 9141msgid "Ansible only executes each role once, 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:" 9142msgstr "Ansible は、ロールに定義されているパラメーターが定義ごとに異なる場合を除き、各ロールを複数回定義しても 1 回しか実行しません。たとえば、Ansible は次のようなプレイで ``foo`` というロールを 1 回だけ実行します。" 9143 9144#: ../../rst/user_guide/playbooks_reuse_roles.rst:400 9145msgid "You have two options to force Ansible to run a role more than once." 9146msgstr "Ansible が複数のロールを強制的に実行するオプションは 2 つあります。" 9147 9148#: ../../rst/user_guide/playbooks_reuse_roles.rst:403 9149msgid "Passing different parameters" 9150msgstr "異なるパラメーターを渡す" 9151 9152#: ../../rst/user_guide/playbooks_reuse_roles.rst:405 9153msgid "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." 9154msgstr "各ロール定義で異なるパラメーターを渡すと、Ansible はそのロールを複数回実行します。異なる変数値を提供することは、異なるロールパラメーターを渡すこととは異なります。``import_role`` および ``include_role`` はロールパラメーターを受け入れないため、この動作には ``roles`` キーワードを使用する必要があります。" 9155 9156#: ../../rst/user_guide/playbooks_reuse_roles.rst:407 9157msgid "This playbook runs the ``foo`` role twice:" 9158msgstr "この Playbook では、``foo`` ロールが 2 回実行されます。" 9159 9160#: ../../rst/user_guide/playbooks_reuse_roles.rst:417 9161msgid "This syntax also runs the ``foo`` role twice;" 9162msgstr "この構文は、``foo`` ロールを 2 回実行します。" 9163 9164#: ../../rst/user_guide/playbooks_reuse_roles.rst:429 9165msgid "In these examples, Ansible runs ``foo`` twice because each role definition has different parameters." 9166msgstr "これらの例では、各ロール定義のパラメーターが異なるため、Ansible は ``foo`` を 2 回実行します。" 9167 9168#: ../../rst/user_guide/playbooks_reuse_roles.rst:432 9169msgid "Using ``allow_duplicates: true``" 9170msgstr "``allow_duplicates: true`` の使用" 9171 9172#: ../../rst/user_guide/playbooks_reuse_roles.rst:434 9173msgid "Add ``allow_duplicates: true`` to the ``meta/main.yml`` file for the role:" 9174msgstr "ロールの ``meta/main.yml`` ファイルに ``allow_duplicates: true`` を追加します。" 9175 9176#: ../../rst/user_guide/playbooks_reuse_roles.rst:449 9177msgid "In this example, Ansible runs ``foo`` twice because we have explicitly enabled it to do so." 9178msgstr "この例では、Ansible が ``foo`` を2回実行していますが、これは明示的に実行できるようにしたためです。" 9179 9180#: ../../rst/user_guide/playbooks_reuse_roles.rst:454 9181msgid "Using role dependencies" 9182msgstr "ロール依存関係の使用" 9183 9184#: ../../rst/user_guide/playbooks_reuse_roles.rst:456 9185msgid "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." 9186msgstr "ロールの依存関係により、あるロールを使用する際に他のロールを自動的に取り込むことができます。Ansible は、ロールをインクルードまたはインポートする際にロールの依存関係を実行しません。Ansible でロールの依存関係を実行したい場合は、``roles`` キーワードを使用する必要があります。" 9187 9188#: ../../rst/user_guide/playbooks_reuse_roles.rst:458 9189msgid "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." 9190msgstr "ロールの依存関係は前提条件であり、真の依存関係ではありません。また、ロールは親子関係を持ちません。Ansible はリストアップされたすべてのロールを読み込み、``dependencies`` にリストアップされたロールを最初に実行し、次にそれらをリストアップしたロールを実行します。play オブジェクトは、``dependencies`` のリストで呼び出されるロールを含め、すべてのロールの親です。" 9191 9192#: ../../rst/user_guide/playbooks_reuse_roles.rst:460 9193msgid "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:" 9194msgstr "ロールの依存関係は、ロールディレクトリー内の ``meta/main.yml`` ファイルに保存されます。このファイルには、指定されたロールの前に挿入するロールとパラメーターの一覧を含める必要があります。以下に例を示します。" 9195 9196#: ../../rst/user_guide/playbooks_reuse_roles.rst:478 9197msgid "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``." 9198msgstr "Ansible は、``dependencies`` に記載されているロールを、それを記載しているロールの前に常に実行します。``roles`` キーワードを使用すると、Ansible はこのパターンを再帰的に実行します。たとえば、ロール ``foo`` を ``roles:`` の下にリストし、ロール ``foo`` が meta/main.yml ファイルの ``dependencies`` の下にロール ``bar`` をリストし、ロール ``bar`` が meta/main.yml の ``dependencies`` の下にロール ``baz`` をリストしている場合、Ansibleは ``baz``、``bar``、``foo`` の順に実行します。" 9199 9200#: ../../rst/user_guide/playbooks_reuse_roles.rst:481 9201msgid "Running role dependencies multiple times in one playbook" 9202msgstr "1 つの Playbook でロールの依存関係を複数回実行する" 9203 9204#: ../../rst/user_guide/playbooks_reuse_roles.rst:483 9205msgid "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 playbook 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." 9206msgstr "Ansible は、``roles:`` に記載されている重複したロールのように、重複したロールの依存関係を扱います。Ansible は、ロールに定義されたパラメーター、タグ、または when 句が定義ごとに異なる場合を除き、複数回定義されていてもロールの依存関係を 1 回のみ実行します。Playbook 内の 2 つのロールが両方とも依存関係として 3 番目のロールをリストしている場合、Ansible は、複数回実行するロールで異なるパラメーター、タグ、when 句を渡すか、``allow_duplicates: true`` を使用しない限り、そのロールの依存関係を 1 回のみ実行します。詳細は、「:ref:`Galaxy ロール依存関係 <galaxy_dependencies>`」を参照してください。" 9207 9208#: ../../rst/user_guide/playbooks_reuse_roles.rst:487 9209msgid "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." 9210msgstr "ロールの重複排除は、親ロールの呼び出し署名を参照しません。さらに、ロールパラメーターの代わりに ``vars:`` を使用する場合は、変数のスコープを変更するという副作用があります。``vars:`` を使用すると、それらの変数がプレイレベルで対象となります。以下の例では、``vars:`` を使用すると、それ以前に呼び出されたロールを含め、プレー全体を通して ``n`` が ``4`` として定義されることになります。" 9211 9212#: ../../rst/user_guide/playbooks_reuse_roles.rst:489 9213msgid "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." 9214msgstr "上記に加えて、ユーザーは変数評価の前にロールの重複排除が行われることに注意する必要があります。つまり、:term:`Lazy Evaluation` は、一見異なるロールの呼び出しを等価にして、ロールが複数回実行されるのを防ぐことができます。" 9215 9216#: ../../rst/user_guide/playbooks_reuse_roles.rst:492 9217msgid "For example, a role named ``car`` depends on a role named ``wheel`` as follows:" 9218msgstr "たとえば、``car`` という名前のロールは、以下のように ``wheel`` という名前のロールに依存します。" 9219 9220#: ../../rst/user_guide/playbooks_reuse_roles.rst:507 9221msgid "And the ``wheel`` role depends on two roles: ``tire`` and ``brake``. The ``meta/main.yml`` for wheel would then contain the following:" 9222msgstr "そして、``wheel`` のロールは、``tire`` と ``brake`` の 2 つのロールに依存します。このため、wheel 用の ``meta/main.yml`` は以下のようになります。" 9223 9224#: ../../rst/user_guide/playbooks_reuse_roles.rst:516 9225msgid "And the ``meta/main.yml`` for ``tire`` and ``brake`` would contain the following:" 9226msgstr "そして、「``tire``」および「``brake``」の「``meta/main.yml``」には、次のような内容が含まれています。" 9227 9228#: ../../rst/user_guide/playbooks_reuse_roles.rst:523 9229msgid "The resulting order of execution would be as follows:" 9230msgstr "その結果作成される実行順序は以下のようになります。" 9231 9232#: ../../rst/user_guide/playbooks_reuse_roles.rst:536 9233msgid "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." 9234msgstr "``allow_duplicates: true`` をロール依存で使用するには、それをリストしているロールではなく、``dependencies`` の下にリストされているロールに対して指定する必要があります。上記の例では、``allow_duplicates: true`` は、``tire`` ロールおよび ``brake`` ロールの ``meta/main.yml`` に表示されます。``wheel`` ロールは、``car`` で定義された各インスタンスが異なるパラメーター値を使用するため、``allow_duplicates: true`` を必要としません。" 9235 9236#: ../../rst/user_guide/playbooks_reuse_roles.rst:539 9237msgid "See :ref:`playbooks_variables` for details on how Ansible chooses among variable values defined in different places (variable inheritance and scope)." 9238msgstr "Ansible が異なる場所 (変数継承およびスコープ) で定義される変数の値間で Ansible が選択する方法の詳細については、「:ref:`playbooks_variables`」を参照してください。" 9239 9240#: ../../rst/user_guide/playbooks_reuse_roles.rst:544 9241msgid "Embedding modules and plugins in roles" 9242msgstr "ロールでのモジュールおよびプラグインの埋め込み" 9243 9244#: ../../rst/user_guide/playbooks_reuse_roles.rst:546 9245msgid "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." 9246msgstr "カスタムモジュール (:ref:`developing_modules` 参照) やプラグイン (:ref:`developing_plugins` 参照) を作成した場合は、ロールの一部として配布したい場合があります。たとえば、社内のソフトウェアを設定するためのモジュールを作成し、組織内の他の人にもこのモジュールを使用してほしいにも関わらず、Ansible のライブラリーパスを設定する方法を全員に開示したくない場合は、internal_config ロールにモジュールを含めることができます。" 9247 9248#: ../../rst/user_guide/playbooks_reuse_roles.rst:548 9249msgid "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." 9250msgstr "モジュールやプラグインをロールに追加するには、ロールの「tasks」および「handlers」構造の横に、「library」という名前のディレクトリーを追加し、その「library」ディレクトリー内にモジュールを直接インクルードします。" 9251 9252#: ../../rst/user_guide/playbooks_reuse_roles.rst:551 9253msgid "Assuming you had this:" 9254msgstr "以下があるとします。" 9255 9256#: ../../rst/user_guide/playbooks_reuse_roles.rst:561 9257msgid "The module will be usable in the role itself, as well as any roles that are called *after* this role, as follows:" 9258msgstr "モジュールは、次のように、ロール自体、およびこのロールの *後に* 呼び出されるすべてのロールで使用できます。" 9259 9260#: ../../rst/user_guide/playbooks_reuse_roles.rst:572 9261msgid "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." 9262msgstr "必要に応じて、ロールにモジュールを埋め込み、Ansible のコアディストリビューションのモジュールを変更することもできます。たとえば、モジュールをコピーし、そのコピーをロールに埋め込むことで、特定のモジュールの開発バージョンを実稼働リリースの前に使用することができます。コアコンポーネントでは API シグネチャーが変更する可能性があり、この回避策は動作が保証されていないため、この方法は慎重に使用してください。" 9263 9264#: ../../rst/user_guide/playbooks_reuse_roles.rst:574 9265msgid "The same mechanism can be used to embed and distribute plugins in a role, using the same schema. For example, for a filter plugin:" 9266msgstr "同じスキーマを使用して、ロールにプラグインを埋め込んだり配布したりすることもできます。たとえば、フィルタープラグインの場合は、以下のようになります。" 9267 9268#: ../../rst/user_guide/playbooks_reuse_roles.rst:584 9269msgid "These filters can then be used in a Jinja template in any role called after 'my_custom_filter'." 9270msgstr "これらのフィルターは、Jinja のテンプレートで、「my_custom_filter」の後に呼ばれる任意のロールで使用することができます。" 9271 9272#: ../../rst/user_guide/playbooks_reuse_roles.rst:587 9273msgid "Sharing roles: Ansible Galaxy" 9274msgstr "ロールの共有: Ansible Galaxy" 9275 9276#: ../../rst/user_guide/playbooks_reuse_roles.rst:589 9277msgid "`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." 9278msgstr "`Ansible Galaxy <https://galaxy.ansible.com>`_ は、コミュニティーで開発されたあらゆる種類の Ansible ロールを検索、ダウンロード、評価、およびレビューする無料サイトで、ここで自動化プロジェクトをすぐに開始するための優れた方法です。" 9279 9280#: ../../rst/user_guide/playbooks_reuse_roles.rst:591 9281msgid "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." 9282msgstr "クライアント ``ansible-galaxy`` は、Ansible に含まれています。Galaxy クライアントを使用すると、Ansible Galaxy からロールをダウンロードでき、独自のロールを作成する優れたデフォルトのフレームワークも提供します。" 9283 9284#: ../../rst/user_guide/playbooks_reuse_roles.rst:593 9285msgid "Read the `Ansible Galaxy documentation <https://galaxy.ansible.com/docs/>`_ page for more information" 9286msgstr "詳細は、`Ansible Galaxy ドキュメント <https://galaxy.ansible.com/docs/>`_ ページを参照してください。" 9287 9288#: ../../rst/user_guide/playbooks_reuse_roles.rst:598 9289msgid "How to create new roles, share roles on Galaxy, role management" 9290msgstr "新規ロールの作成、Galaxy でのロールの共有、およびロールの管理の方法" 9291 9292#: ../../rst/user_guide/playbooks_reuse_roles.rst:606 9293msgid "Variables in playbooks" 9294msgstr "Playbook の変数" 9295 9296#: ../../rst/user_guide/playbooks_reuse_roles.rst:611 9297msgid ":ref:`tags`" 9298msgstr ":ref:`tags`" 9299 9300#: ../../rst/user_guide/playbooks_reuse_roles.rst:612 9301msgid "Using tags to select or skip roles/tasks in long playbooks" 9302msgstr "タグを使用した長い Playbook でロール/タスクの選択またはスキップ" 9303 9304#: ../../rst/user_guide/playbooks_reuse_roles.rst:616 9305msgid "Extending Ansible by writing your own modules" 9306msgstr "独自のモジュールを作成して Ansible を拡張" 9307 9308#: ../../rst/user_guide/playbooks_roles.rst:4 9309msgid "Playbook Roles and Include Statements" 9310msgstr "Playbook ロールおよび Include 文" 9311 9312#: ../../rst/user_guide/playbooks_roles.rst:9 9313msgid "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." 9314msgstr "Playbook のロールおよびインクルードに関するドキュメントが移動しました。新しい場所は「:ref:`playbooks_reuse`」です。このページに直接作成したリンクを更新してください。" 9315 9316#: ../../rst/user_guide/playbooks_roles.rst:17 9317msgid ":ref:`playbooks_reuse`" 9318msgstr ":ref:`playbooks_reuse`" 9319 9320#: ../../rst/user_guide/playbooks_roles.rst:18 9321msgid "Creating reusable Playbooks." 9322msgstr "再利用可能な Playbook の作成" 9323 9324#: ../../rst/user_guide/playbooks_special_topics.rst:6 9325msgid "Advanced playbooks features" 9326msgstr "Playbook の高度な機能" 9327 9328#: ../../rst/user_guide/playbooks_special_topics.rst:8 9329msgid "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." 9330msgstr "このページは使用されなくなりました。Playbook に関連するすべてのトピックへのリンクは、:ref:`メインのユーザーガイドのインデックスページ <user_guide_index>` を参照してください。このページに直接リンクを張っている場合は更新してください。" 9331 9332#: ../../rst/user_guide/playbooks_startnstep.rst:5 9333msgid "Executing playbooks for troubleshooting" 9334msgstr "トラブルシューティングのための Playbook の実行" 9335 9336#: ../../rst/user_guide/playbooks_startnstep.rst:7 9337msgid "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." 9338msgstr "新しいプレイをテストしたり、Playbook をデバッグしたりする際に、同じプレイを複数回実行しないといけない場合があります。これを効率的に行うために、Ansible では Playbook の実行方法として、start-at-task モードと step モードの 2 種類を用意しています。" 9339 9340#: ../../rst/user_guide/playbooks_startnstep.rst:12 9341msgid "start-at-task" 9342msgstr "start-at-task" 9343 9344#: ../../rst/user_guide/playbooks_startnstep.rst:14 9345msgid "To start executing your playbook at a particular task (usually the task that failed on the previous run), use the ``--start-at-task`` option::" 9346msgstr "特定のタスク (通常は直前の実行で失敗したタスク) で Playbook の実行を開始するには、``--start-at-task`` オプションを使用します。" 9347 9348#: ../../rst/user_guide/playbooks_startnstep.rst:18 9349msgid "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`." 9350msgstr "この例では、Ansible は「install packages」という名前のタスクで Playbook の実行を開始します。この機能は、動的に再利用されるロールやタスク内のタスク (``include_*``) では動作しません。「:ref:`dynamic_vs_static`」を参照してください。" 9351 9352#: ../../rst/user_guide/playbooks_startnstep.rst:23 9353msgid "Step mode" 9354msgstr "step モード" 9355 9356#: ../../rst/user_guide/playbooks_startnstep.rst:25 9357msgid "To execute a playbook interactively, use ``--step``::" 9358msgstr "Playbook を対話的に実行するには、``--step`` を使用します。" 9359 9360#: ../../rst/user_guide/playbooks_startnstep.rst:29 9361msgid "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::" 9362msgstr "このオプションを使用すると、Ansible は各タスクで停止し、そのタスクを実行すべきかどうかを尋ねます。たとえば、「configure ssh」という名前のタスクがあった場合、Playbook の実行は停止し、次のように尋ねてきます。" 9363 9364#: ../../rst/user_guide/playbooks_startnstep.rst:33 9365msgid "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." 9366msgstr "「y」と答えてタスクを実行し、「n」と答えてタスクをスキップし、「c」と応えて step モードを終了し、残りのタスクをすべて実行します。" 9367 9368#: ../../rst/user_guide/playbooks_startnstep.rst:39 9369msgid ":ref:`playbook_debugger`" 9370msgstr ":ref:`playbook_debugger`" 9371 9372#: ../../rst/user_guide/playbooks_startnstep.rst:40 9373msgid "Using the Ansible debugger" 9374msgstr "Ansible デバッガーの使用" 9375 9376#: ../../rst/user_guide/playbooks_strategies.rst:4 9377msgid "Controlling playbook execution: strategies and more" 9378msgstr "Playbook の実行の制御: strategy など" 9379 9380#: ../../rst/user_guide/playbooks_strategies.rst:6 9381msgid "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``." 9382msgstr "デフォルトでは、Ansible はプレイの影響を受けるすべてのホストで各タスクを実行してから、任意のホストで次のタスクを開始し、5 つのフォークを使用します。このデフォルトの動作を変更する場合は、別のストラテジープラグインを使用するか、フォーク数を変更するか、``serial`` のようなキーワードのいずれかを適用することができます。" 9383 9384#: ../../rst/user_guide/playbooks_strategies.rst:12 9385msgid "Selecting a strategy" 9386msgstr "ストラテジーの選択" 9387 9388#: ../../rst/user_guide/playbooks_strategies.rst:13 9389msgid "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::" 9390msgstr "上述のデフォルトの動作は :ref:`線形ストラテジー<linear_strategy>` です。Ansible には、:ref:`デバッグストラテジー<debug_strategy>` (:ref:`playbook_debugger` も参照) や :ref:`フリーストラテジー<free_strategy>` など、他のストラテジーも用意されています。フリーストラテジーでは、各ホストがプレイが終了するまでできるだけ速く実行することができます。" 9391 9392#: ../../rst/user_guide/playbooks_strategies.rst:20 9393msgid "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::" 9394msgstr "上記のように各プレイに異なるストラテジーを選択するか、``defaults`` stanza の ``ansible.cfg`` で優先されるストラテジーをグローバルに設定できます。" 9395 9396#: ../../rst/user_guide/playbooks_strategies.rst:25 9397msgid "All strategies are implemented as :ref:`strategy plugins<strategy_plugins>`. Please review the documentation for each strategy plugin for details on how it works." 9398msgstr "すべてのストラテジーは :ref:`strategy プラグイン<strategy_plugins>` として実装されます。その仕組みの詳細は、各 strategy プラグインのドキュメントを参照してください。" 9399 9400#: ../../rst/user_guide/playbooks_strategies.rst:28 9401msgid "Setting the number of forks" 9402msgstr "フォークの数の設定" 9403 9404#: ../../rst/user_guide/playbooks_strategies.rst:29 9405msgid "If you have the processing power available and want to use more forks, you can set the number in ``ansible.cfg``::" 9406msgstr "利用可能な処理能力があり、さらに多くのフォークを使用する場合は、``ansible.cfg`` で数値を設定できます。" 9407 9408#: ../../rst/user_guide/playbooks_strategies.rst:34 9409msgid "or pass it on the command line: `ansible-playbook -f 30 my_playbook.yml`." 9410msgstr "または、コマンドラインで渡します (`ansible-playbook -f 30 my_playbook.yml`)。" 9411 9412#: ../../rst/user_guide/playbooks_strategies.rst:37 9413msgid "Using keywords to control execution" 9414msgstr "キーワードを使用した実行の制御" 9415 9416#: ../../rst/user_guide/playbooks_strategies.rst:39 9417msgid "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." 9418msgstr "ストラテジーだけでなく、いくつかの :ref:`キーワード<playbook_keywords>` もプレイの実行に影響を与えます。``serial`` では、一度に管理したいホストの数、割合、またはリストを設定できます。Ansible は、指定した数または割合のホストでプレイを完了してから、次のホストのバッチを開始します。``throttle`` で、ブロックやタスクに割り当てられるワーカーの数を制限することができます。``order`` で、Ansible がグループ内の次のホストを選択して実行する方法を制御できます。``run_once`` を使用して、1 つのタスクを 1 つのホストで実行することができます。これらのキーワードはストラテジーではなく、プレイ、ブロック、またはタスクに適用されるディレクティブやオプションです。" 9419 9420#: ../../rst/user_guide/playbooks_strategies.rst:44 9421msgid "Setting the batch size with ``serial``" 9422msgstr "``serial`` を使用してバッチサイズの設定" 9423 9424#: ../../rst/user_guide/playbooks_strategies.rst:46 9425msgid "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::" 9426msgstr "デフォルトでは、Ansible は、各プレイの ``hosts:`` フィールドで設定した :ref:`pattern <intro_patterns>` のすべてのホストに対して並行して実行します。ローリングアップデート中など、一度に数台のマシンのみを管理する場合は、``serial`` キーワードを使用して、Ansible が一度に管理するホストの数を定義できます。" 9427 9428#: ../../rst/user_guide/playbooks_strategies.rst:60 9429msgid "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::" 9430msgstr "上の例では、「webservers」というグループに 6 台のホストがあった場合、Ansible はそのうちの 3 台のホストでプレイを完全に (両方のタスクを) 実行してから、次の 3 台のホストに移ります。" 9431 9432#: ../../rst/user_guide/playbooks_strategies.rst:96 9433msgid "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::" 9434msgstr "``serial`` キーワードでパーセンテージを指定することもできます。Ansible は、プレイ内のホストの合計数にパーセンテージを適用して、パスごとのホスト数を決定します。" 9435 9436#: ../../rst/user_guide/playbooks_strategies.rst:103 9437msgid "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." 9438msgstr "ホストの数がパスの数に等しく分配されない場合は、最後のパスには残りの数が含まれます。この例では、webservers グループに 20 台のホストがある場合、最初のバッチには 6 台のホストが、2 番目のバッチには 6 台のホストが、3 番目のバッチには 6 台のホストが、そして最後のバッチには 2 台のホストが含まれます。" 9439 9440#: ../../rst/user_guide/playbooks_strategies.rst:105 9441msgid "You can also specify batch sizes as a list. For example::" 9442msgstr "また、バッチサイズをリストとして指定することもできます。以下に例を示します。" 9443 9444#: ../../rst/user_guide/playbooks_strategies.rst:115 9445msgid "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." 9446msgstr "上記の例では、最初のバッチには 1 台のホストが含まれ、次のバッチには 5 台のホストが含まれ、(ホストが残っていれば) その後のすべてのバッチには 10 台のホストが含まれるか、または 10 台未満のホストが残っていれば、残りのすべてのホストが含まれることになります。" 9447 9448#: ../../rst/user_guide/playbooks_strategies.rst:117 9449msgid "You can list multiple batch sizes as percentages::" 9450msgstr "複数のバッチサイズをパーセンテージとして一覧表示できます。" 9451 9452#: ../../rst/user_guide/playbooks_strategies.rst:127 9453msgid "You can also mix and match the values::" 9454msgstr "値を混在させたり、一致させることもできます。" 9455 9456#: ../../rst/user_guide/playbooks_strategies.rst:138 9457msgid "No matter how small the percentage, the number of hosts per pass will always be 1 or greater." 9458msgstr "パーセンテージを小さくしても、各パスのホスト数は常に 1 以上になります。" 9459 9460#: ../../rst/user_guide/playbooks_strategies.rst:141 9461msgid "Restricting execution with ``throttle``" 9462msgstr "``throttle`` で実行を制限" 9463 9464#: ../../rst/user_guide/playbooks_strategies.rst:143 9465msgid "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::" 9466msgstr "``throttle`` キーワードは、特定のタスクに対するワーカーの数を制限します。これは、ブロックおよびタスクのレベルで設定できます。``throttle`` を使用して、CPU に負荷がかかる可能性のあるタスクや、レート制限 API と相互作用するタスクを制限します。" 9467 9468#: ../../rst/user_guide/playbooks_strategies.rst:149 9469msgid "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." 9470msgstr "すでにフォークの数や並列実行するマシンの数を制限している場合は、``throttle`` でワーカーの数を減らすことはできますが、増やすことはできません。つまり、それを合わせて使用する場合に効果を得るためには、``throttle`` の設定が ``forks`` や ``serial`` の設定よりも低くなければなりません。" 9471 9472#: ../../rst/user_guide/playbooks_strategies.rst:152 9473msgid "Ordering execution based on inventory" 9474msgstr "インベントリーに基づく実行の順序付け" 9475 9476#: ../../rst/user_guide/playbooks_strategies.rst:154 9477msgid "The ``order`` keyword controls the order in which hosts are run. Possible values for order are:" 9478msgstr "``order`` キーワードは、ホストが実行する順序を制御します。order に指定できる値は次のとおりです。" 9479 9480#: ../../rst/user_guide/playbooks_strategies.rst:156 9481msgid "inventory:" 9482msgstr "inventory:" 9483 9484#: ../../rst/user_guide/playbooks_strategies.rst:157 9485msgid "(default) The order provided in the inventory" 9486msgstr "(デフォルト) インベントリーで指定する順序" 9487 9488#: ../../rst/user_guide/playbooks_strategies.rst:158 9489msgid "reverse_inventory:" 9490msgstr "reverse_inventory:" 9491 9492#: ../../rst/user_guide/playbooks_strategies.rst:159 9493msgid "The reverse of the order provided by the inventory" 9494msgstr "インベントリーにより指定される順序の逆順" 9495 9496#: ../../rst/user_guide/playbooks_strategies.rst:160 9497msgid "sorted:" 9498msgstr "sorted:" 9499 9500#: ../../rst/user_guide/playbooks_strategies.rst:161 9501msgid "Sorted alphabetically sorted by name" 9502msgstr "名前をアルファベット順で並べ替えます。" 9503 9504#: ../../rst/user_guide/playbooks_strategies.rst:162 9505msgid "reverse_sorted:" 9506msgstr "reverse_sorted:" 9507 9508#: ../../rst/user_guide/playbooks_strategies.rst:163 9509msgid "Sorted by name in reverse alphabetical order" 9510msgstr "アルファベットの逆順で名前がソートされます。" 9511 9512#: ../../rst/user_guide/playbooks_strategies.rst:165 9513msgid "shuffle:" 9514msgstr "shuffle:" 9515 9516#: ../../rst/user_guide/playbooks_strategies.rst:165 9517msgid "Randomly ordered on each run" 9518msgstr "実行ごとにランダムに順序付けられます。" 9519 9520#: ../../rst/user_guide/playbooks_strategies.rst:167 9521msgid "Other keywords that affect play execution include ``ignore_errors``, ``ignore_unreachable``, and ``any_errors_fatal``. These options are documented in :ref:`playbooks_error_handling`." 9522msgstr "プレイの実行に影響する他のキーワードには、``ignore_errors``、``ignore_unreachable``、および ``any_errors_fatal`` が含まれます。これらのオプションは、「:ref:`playbooks_error_handling`」に記載されています。" 9523 9524#: ../../rst/user_guide/playbooks_strategies.rst:172 9525msgid "Running on a single machine with ``run_once``" 9526msgstr "シングルマシンで、``run_once`` で動作します。" 9527 9528#: ../../rst/user_guide/playbooks_strategies.rst:174 9529msgid "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::" 9530msgstr "ホストのバッチの最初のホストでタスクを実行する場合は、そのタスクで ``run_once`` を true に設定します。" 9531 9532#: ../../rst/user_guide/playbooks_strategies.rst:188 9533msgid "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::" 9534msgstr "Ansible は、現在のバッチの最初のホストでこのタスクを実行し、すべての結果とファクトを同じバッチのすべてのホストに適用します。この方法は、次のような条件をタスクに適用することに似ています。" 9535 9536#: ../../rst/user_guide/playbooks_strategies.rst:193 9537msgid "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::" 9538msgstr "ただし、``run_once`` では、結果はすべてのホストに適用されます。バッチの最初のホストではなく、特定のホストでタスクを実行するには、タスクを次のように委譲します。" 9539 9540#: ../../rst/user_guide/playbooks_strategies.rst:199 9541msgid "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." 9542msgstr ":ref:`委譲 <playbooks_delegation>` の場合と同様、アクションは委譲されたホストで実行されますが、情報はタスクの元のホストの情報になります。" 9543 9544#: ../../rst/user_guide/playbooks_strategies.rst:202 9545msgid "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." 9546msgstr "``serial`` と併用すると、``run_once`` とマークされたタスクは、*各* シリアルバッチの中の 1 台のホストで実行します。タスクが ``serial`` モードに関係なく 1 回だけ実行する必要がある場合は、:code:`when: inventory_hostname == ansible_play_hosts_all[0]` コンストラクトを使用します。" 9547 9548#: ../../rst/user_guide/playbooks_strategies.rst:206 9549msgid "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." 9550msgstr "条件 (つまり `when:`) は、「first host」の変数を使用して、タスクが実行されるかどうかを判断し、他のホストはテストされません。" 9551 9552#: ../../rst/user_guide/playbooks_strategies.rst:209 9553msgid "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." 9554msgstr "すべてのホストにファクトを設定するデフォルトの動作を回避する場合は、特定のタスクまたはブロックに ``delegate_facts: True`` を設定します。" 9555 9556#: ../../rst/user_guide/playbooks_strategies.rst:215 9557msgid ":ref:`playbooks_delegation`" 9558msgstr ":ref:`playbooks_delegation`" 9559 9560#: ../../rst/user_guide/playbooks_strategies.rst:216 9561msgid "Running tasks on or assigning facts to specific machines" 9562msgstr "特定マシンでのタスクの実行、または特定マシンへのファクトの割り当て" 9563 9564#: ../../rst/user_guide/playbooks_tags.rst:5 9565msgid "Tags" 9566msgstr "タグ" 9567 9568#: ../../rst/user_guide/playbooks_tags.rst:7 9569msgid "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:" 9570msgstr "大規模な Playbook を使用する場合は、Playbook 全体を実行するのではなく、特定の部分だけを実行すると便利な場合があります。これを実現するには、Ansible のタグを使用します。タグを使用して選択したタスクを実行またはスキップするには、2 つのステップがあります。" 9571 9572#: ../../rst/user_guide/playbooks_tags.rst:9 9573msgid "Add tags to your tasks, either individually or with tag inheritance from a block, play, role, or import." 9574msgstr "タスクにタグを追加するには、個別にタグを追加するか、ブロック、プレイ、ロール、またはインポートからタグを継承する必要があります。" 9575 9576#: ../../rst/user_guide/playbooks_tags.rst:10 9577msgid "Select or skip tags when you run your playbook." 9578msgstr "Playbook の実行時にタグを選択またはスキップします。" 9579 9580#: ../../rst/user_guide/playbooks_tags.rst:16 9581msgid "Adding tags with the tags keyword" 9582msgstr "tags キーワードを使用したタグの追加" 9583 9584#: ../../rst/user_guide/playbooks_tags.rst:18 9585msgid "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." 9586msgstr "タグは、単一のタスクまたはインクルードに追加できます。また、ブロック、プレイ、ロール、またはインポートのレベルでタグを定義することで、複数のタスクにタグを追加することもできます。``tags`` キーワードは、これらすべてのユースケースに対応しています。``tags`` キーワードは、常にタグを定義してタスクに追加しますが、実行するタスクの選択やスキップは行いません。タグに基づいてタスクを選択またはスキップできるのは、Playbook の実行時にコマンドラインで行う場合のみです。詳細は、「:ref:`using_tags`」を参照してください。" 9587 9588#: ../../rst/user_guide/playbooks_tags.rst:21 9589msgid "Adding tags to individual tasks" 9590msgstr "個別タスクへのタグの追加" 9591 9592#: ../../rst/user_guide/playbooks_tags.rst:23 9593msgid "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:" 9594msgstr "最も簡単なレベルでは、個々のタスクに 1 つまたは複数のタグを適用できます。タグは、Playbook 内、タスクファイル内、またはロール内のタスクに追加できます。以下は、2 つのタスクに異なるタグを付ける例です。" 9595 9596#: ../../rst/user_guide/playbooks_tags.rst:45 9597msgid "You can apply the same tag to more than one individual task. This example tags several tasks with the same tag, \"ntp\":" 9598msgstr "同じタグを複数の個別タスクに適用できます。この例では、同じタグ「ntp」を使用して、複数のタスクにタグを付けることができます。" 9599 9600#: ../../rst/user_guide/playbooks_tags.rst:81 9601msgid "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." 9602msgstr "``--tags ntp`` を使用して、この 4 つのタスクを Playbook で実行した場合、Ansible は ``ntp`` のタグが付いた 3 つのタスクを実行し、タグが付いていない 1 つのタスクをスキップします。" 9603 9604#: ../../rst/user_guide/playbooks_tags.rst:86 9605msgid "Adding tags to includes" 9606msgstr "インクルードするタグの追加" 9607 9608#: ../../rst/user_guide/playbooks_tags.rst:88 9609msgid "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." 9610msgstr "タグは、Playbook 内の動的インクルードにタグを適用できます。個々のタスクのタグと同様に、``include_*`` タスクのタグは、インクルード自体にのみ適用され、インクルードされたファイルやロール内のタスクには適用されません。動的インクルードに ``mytag`` を追加し、その Playbook を ``--tags mytag`` で実行すると、Ansible はインクルード自体を実行し、``mytag`` でタグ付けされたインクルードファイルまたはロール内のタスクを実行し、そのタグのないインクルードファイルまたはロール内のタスクをスキップします。詳細は「:ref:`selective_reuse`」を参照してください。" 9611 9612#: ../../rst/user_guide/playbooks_tags.rst:90 9613msgid "You add tags to includes the same way you add tags to any other task:" 9614msgstr "タグを追加して、他のタスクにタグを追加する方法と同じ方法でインクルードします。" 9615 9616#: ../../rst/user_guide/playbooks_tags.rst:101 9617msgid "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:" 9618msgstr "タグは、ロールの動的インクルードにのみ追加できます。この例では、``foo`` タグは ``bar`` ロール内のタスクに適用 `されません`。" 9619 9620#: ../../rst/user_guide/playbooks_tags.rst:114 9621msgid "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." 9622msgstr "プレイ、ブロック、``role`` キーワード、および静的なインポートでは、Ansible はタグ継承を適用し、定義したタグをプレイ、ブロック、ロール、またはインポートしたファイル内のすべてのタスクに追加します。しかし、``include_role`` や ``include_tasks`` のような動的再利用では、タグの継承は *適用されません*。動的再利用 (インクルード) では、定義したタグはインクルード自体にのみ適用されます。タグの継承が必要な場合は、静的インポートを使用してください。Playbook の他の部分がインクルードを使用しているためにインポートを使用できない場合は、この動作を回避する方法について「:ref:`apply_keyword`」を参照してください。" 9623 9624#: ../../rst/user_guide/playbooks_tags.rst:119 9625msgid "Tag inheritance: adding tags to multiple tasks" 9626msgstr "タグの継承: 複数のタスクへのタグの追加" 9627 9628#: ../../rst/user_guide/playbooks_tags.rst:121 9629msgid "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." 9630msgstr "すべてのタスクに ``tags`` 行を追加することなく、複数のタスクに同じタグを適用したい場合は、プレイやブロックのレベル、またはロールの追加やファイルのインポートの際にタグを定義することができます。Ansible は、依存関係の連鎖の下にあるタグをすべての子タスクに適用します。ロールやインポートの場合、Ansible は ``roles`` セクションやインポートで設定されたタグを、ロールやインポートしたファイル内の個々のタスクやブロックに設定されたタグに追加します。これを「タグの継承」と呼びます。タグの継承は、すべてのタスクにタグを付ける必要がないため便利です。ただし、タグはタスクに個別に適用されます。" 9631 9632#: ../../rst/user_guide/playbooks_tags.rst:124 9633msgid "Adding tags to blocks" 9634msgstr "ブロックへのタグの追加" 9635 9636#: ../../rst/user_guide/playbooks_tags.rst:126 9637msgid "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:" 9638msgstr "プレイ中のタスクのすべてではなく、多くのタスクにタグを適用したい場合は、:ref:`ブロック <playbooks_blocks>` を使用し、そのレベルでタグを定義します。たとえば、上で紹介した NTP の例を編集して、ブロックを使用することができます。" 9639 9640#: ../../rst/user_guide/playbooks_tags.rst:162 9641msgid "Adding tags to plays" 9642msgstr "プレイへのタグの追加" 9643 9644#: ../../rst/user_guide/playbooks_tags.rst:164 9645msgid "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:" 9646msgstr "プレイの中のすべてのタスクに同じタグを付ける必要がある場合は、プレイのレベルでタグを追加することができます。たとえば、NTP タスクだけのプレイがあった場合は、プレイ全体にタグを付けることができます。" 9647 9648#: ../../rst/user_guide/playbooks_tags.rst:195 9649msgid "Adding tags to roles" 9650msgstr "ロールへのタグの追加" 9651 9652#: ../../rst/user_guide/playbooks_tags.rst:197 9653msgid "There are three ways to add tags to roles:" 9654msgstr "ロールにタグを追加するには、3 つの方法があります。" 9655 9656#: ../../rst/user_guide/playbooks_tags.rst:199 9657msgid "Add the same tag or tags to all tasks in the role by setting tags under ``roles``. See examples in this section." 9658msgstr "``roles`` セクションにタグを設定して、ロールのすべてのタスクに同じタグを追加します。本セクションの例を参照してください。" 9659 9660#: ../../rst/user_guide/playbooks_tags.rst:200 9661msgid "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`." 9662msgstr "Playbook の静的 ``import_role`` にタグを設定して、ロール内のすべてのタスクに同じタグを追加します。「:ref:`tags_on_imports`」の例を参照してください。" 9663 9664#: ../../rst/user_guide/playbooks_tags.rst:201 9665msgid "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." 9666msgstr "ロール自体の中の個々のタスクやブロックにタグを追加します。これは、ロール内の一部のタスクを選択またはスキップすることができる唯一の方法です。ロール内のタスクを選択またはスキップするには、個々のタスクまたはブロックにタグを設定し、Playbook で動的な ``include_role`` を使用して、同じタグをインクルードに追加する必要があります。この方法で``--tags foo`` を付けて Playbook を実行すると、Ansible はインクルード自体に加えて、タグ ``foo`` を持つロール内のタスクを実行します。詳細は、「:ref:`tags_on_includes`」を参照してください。" 9667 9668#: ../../rst/user_guide/playbooks_tags.rst:203 9669msgid "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:" 9670msgstr "``roles`` キーワードを使用して Playbook にロールを静的に組み込むと、Ansible は定義したタグをロール内のすべてのタスクに追加します。たとえば、以下のようになります。" 9671 9672#: ../../rst/user_guide/playbooks_tags.rst:213 9673msgid "or:" 9674msgstr "または" 9675 9676#: ../../rst/user_guide/playbooks_tags.rst:230 9677msgid "Adding tags to imports" 9678msgstr "インポートへのタグの追加" 9679 9680#: ../../rst/user_guide/playbooks_tags.rst:232 9681msgid "You can also apply a tag or tags to all the tasks imported by the static ``import_role`` and ``import_tasks`` statements:" 9682msgstr "また、静的な ``import_role`` 文や ``import_tasks`` 文によりインポートされたすべてのタスクに、タグを適用することもできます。" 9683 9684#: ../../rst/user_guide/playbooks_tags.rst:253 9685msgid "Tag inheritance for includes: blocks and the ``apply`` keyword" 9686msgstr "インクルードのタグ継承: ブロックおよび ``apply`` キーワード" 9687 9688#: ../../rst/user_guide/playbooks_tags.rst:255 9689msgid "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." 9690msgstr "デフォルトでは、Ansible は :ref:`タグ継承 <tag_inheritance>` を適用せず、``include_role`` および ``include_tasks`` を使用した動的再利用を行います。タグをインクルードに追加すると、タグはインクルード自体にのみ適用され、インクルードしたファイルやロール内のタスクには適用されません。これにより、ロールやタスクファイル内の選択したタスクを実行することができます。Playbook を実行する際には、「:ref:`selective_reuse`」を参照してください。" 9691 9692#: ../../rst/user_guide/playbooks_tags.rst:257 9693msgid "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:" 9694msgstr "タグの継承が必要な場合は、おそらくインポートを使用したいと思うでしょう。ただし、1 つの Playbook でインクルードとインポートの両方を使用すると、診断が困難なバグが発生する可能性があります。このような理由から、Playbook で ``include_*`` を使用してロールやタスクを再利用している場合に、1 つのインクルードでタグの継承が必要な場合、Ansible には 2 つの回避策があります。``apply`` キーワードを使用することができます。" 9695 9696#: ../../rst/user_guide/playbooks_tags.rst:270 9697msgid "Or you can use a block:" 9698msgstr "または、以下のブロックを使用できます。" 9699 9700#: ../../rst/user_guide/playbooks_tags.rst:282 9701msgid "Special tags: always and never" 9702msgstr "特別なタグ: always および never" 9703 9704#: ../../rst/user_guide/playbooks_tags.rst:284 9705msgid "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``)." 9706msgstr "Ansible は、特別な動作のために、always と never という 2 つのタグ名を予約しています。``always`` タグをタスクやプレイに割り当てると、Ansible は特にスキップしない限り、常にそのタスクやプレイを実行します (``--skip-tags always``)。" 9707 9708#: ../../rst/user_guide/playbooks_tags.rst:286 9709#: ../../rst/user_guide/playbooks_tags.rst:316 9710msgid "For example:" 9711msgstr "たとえば、以下のようになります。" 9712 9713#: ../../rst/user_guide/playbooks_tags.rst:304 9714msgid "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``." 9715msgstr "ファクト収集には、デフォルトで「always」というタグが付けられています。タグを適用した後、``--tags`` で別のタグを使用したり、``--skip-tags`` で同じタグを使用した場合に限りスキップされます。" 9716 9717#: ../../rst/user_guide/playbooks_tags.rst:309 9718msgid "The role argument specification validation task is tagged with 'always' by default. This validation will be skipped if you use ``--skip-tags always``." 9719msgstr "ロール引数の検証タスクは、デフォルトで「always」でタグ付けされます。``--skip-tags always`` を使用する場合は検証がスキップされます。" 9720 9721#: ../../rst/user_guide/playbooks_tags.rst:314 9722msgid "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``)." 9723msgstr "``never`` タグをタスクまたはプレイに割り当てると、特に要求しない限り (``--tags never``)、Ansible はそのタスクまたはプレイをスキップします。" 9724 9725#: ../../rst/user_guide/playbooks_tags.rst:326 9726msgid "The rarely-used debug task in the example above only runs when you specifically request the ``debug`` or ``never`` tags." 9727msgstr "上記の例では、ほとんど使用されないデバッグタスクは、``debug`` タグまたは ``never`` タグを特別に要求した場合にのみ実行します。" 9728 9729#: ../../rst/user_guide/playbooks_tags.rst:331 9730msgid "Selecting or skipping tags when you run a playbook" 9731msgstr "Playbook の実行時にタグの選択または省略" 9732 9733#: ../../rst/user_guide/playbooks_tags.rst:333 9734msgid "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." 9735msgstr "タスク、インクルード、ブロック、プレイ、ロール、およびインポートにタグを追加したら、:ref:`ansible-playbook` を実行する際に、タグに基づいてタスクを選択的に実行またはスキップすることができます。Ansible は、コマンドラインで指定したタグと一致するタグを持つすべてのタスクを実行またはスキップします。ブロックやプレイのレベルで、``roles`` またはインポートを使用してタグを追加した場合、そのタグはブロック、プレイ、ロール、もしくはインポートされたロールまたはファイル内のすべてのタスクに適用されます。多くのタグを持つロールがあり、ロールのサブセットを異なるタイミングで呼び出したい場合は、:ref:`動的インクルードで使用する <selective_reuse>` か、ロールを複数のロールに分割してください。" 9736 9737#: ../../rst/user_guide/playbooks_tags.rst:335 9738msgid ":ref:`ansible-playbook` offers five tag-related command-line options:" 9739msgstr ":ref:`ansible-playbook` は、タグ関連のコマンドラインオプションを 5 つ提供します。" 9740 9741#: ../../rst/user_guide/playbooks_tags.rst:337 9742msgid "``--tags all`` - run all tasks, ignore tags (default behavior)" 9743msgstr "``--tags all`` - すべてのタスクを実行し、タグを無視します (デフォルトの動作)。" 9744 9745#: ../../rst/user_guide/playbooks_tags.rst:338 9746msgid "``--tags [tag1, tag2]`` - run only tasks with either the tag ``tag1`` or the tag ``tag2``" 9747msgstr "``--tags [tag1, tag2]`` - ``tag1`` タグまたは ``tag2`` タグのいずれかでのみタスクを実行します。" 9748 9749#: ../../rst/user_guide/playbooks_tags.rst:339 9750msgid "``--skip-tags [tag3, tag4]`` - run all tasks except those with either the tag ``tag3`` or the tag ``tag4``" 9751msgstr "``--skip-tags [tag3, tag4]`` - ``tag3`` タグまたは ``tag4`` タグのいずれかが指定されたタスク以外のすべてのタスクを実行します。" 9752 9753#: ../../rst/user_guide/playbooks_tags.rst:340 9754msgid "``--tags tagged`` - run only tasks with at least one tag" 9755msgstr "``--tags tagged`` - 1 つ以上のタグでタスクのみを実行します。" 9756 9757#: ../../rst/user_guide/playbooks_tags.rst:341 9758msgid "``--tags untagged`` - run only tasks with no tags" 9759msgstr "``--tags untagged`` - タグなしでタスクのみを実行します。" 9760 9761#: ../../rst/user_guide/playbooks_tags.rst:343 9762msgid "For example, to run only tasks and blocks tagged ``configuration`` and ``packages`` in a very long playbook:" 9763msgstr "たとえば、非常に長い Playbook で、タスクと、``configuration`` および ``packages`` のタグが付けられたブロックのみを実行するには、以下のコマンドを実行します。" 9764 9765#: ../../rst/user_guide/playbooks_tags.rst:349 9766msgid "To run all tasks except those tagged ``packages``:" 9767msgstr "``packages`` のタグが付いたタスク以外のすべてのタスクを実行するには、以下を実行します。" 9768 9769#: ../../rst/user_guide/playbooks_tags.rst:356 9770msgid "Previewing the results of using tags" 9771msgstr "タグの使用結果のプレビュー" 9772 9773#: ../../rst/user_guide/playbooks_tags.rst:358 9774msgid "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:" 9775msgstr "ロールや Playbook を実行する際、どのタスクがどのタグを持っているのか、あるいはどのタグが存在するのかを知らない、あるいは覚えていない場合があります。Ansible では、タグ付き Playbookの管理に役立つ :ref:`ansible-playbook` にコマンドラインフラグを 2 つ提供しています。" 9776 9777#: ../../rst/user_guide/playbooks_tags.rst:360 9778msgid "``--list-tags`` - generate a list of available tags" 9779msgstr "``--list-tags`` - 利用可能なタグのリストを生成します。" 9780 9781#: ../../rst/user_guide/playbooks_tags.rst:361 9782msgid "``--list-tasks`` - when used with ``--tags tagname`` or ``--skip-tags tagname``, generate a preview of tagged tasks" 9783msgstr "``--list-tasks`` - ``--tags tagname`` または ``--skip-tags tagname`` と併用すると、タグ付けされたタスクのプレビューを生成します。" 9784 9785#: ../../rst/user_guide/playbooks_tags.rst:363 9786msgid "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:" 9787msgstr "たとえば、Playbook、ロール、またはタスクファイルの中で、設定タスクのタグが ``config`` か ``conf`` かがわからない場合は、タスクを実行せずに利用可能なタグをすべて表示することができます。" 9788 9789#: ../../rst/user_guide/playbooks_tags.rst:369 9790msgid "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." 9791msgstr "``configuration`` と ``packages`` のタグを持つタスクがわからない場合は、これらのタグを渡して ``--list-tasks`` を追加します。Ansible はタスクをリストアップしますが、実行はしません。" 9792 9793#: ../../rst/user_guide/playbooks_tags.rst:375 9794msgid "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." 9795msgstr "これらのコマンドラインフラグには、動的インクルードされたファイルやロール内のタグやタスクを表示することができないという制限があります。静的インポートと動的インクルードの違いについての詳細は、「:ref:`dynamic_vs_static`」を参照してください。" 9796 9797#: ../../rst/user_guide/playbooks_tags.rst:380 9798msgid "Selectively running tagged tasks in re-usable files" 9799msgstr "再利用可能なファイルでタグ付けされたタスクを選択的に実行" 9800 9801#: ../../rst/user_guide/playbooks_tags.rst:382 9802msgid "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:" 9803msgstr "タスクやブロックのレベルでタグが定義されているロールやタスクファイルがある場合は、静的インポートの代わりに動的インクルードを使用すると、Playbook 内のタグ付きタスクを選択的に実行したりスキップしたりすることができます。インクルードされるタスクと include 文自体には、同じタグを使用する必要があります。たとえば、タグ付きのタスクとタグなしのタスクを含むファイルを作成する場合は、以下のようになります。" 9804 9805#: ../../rst/user_guide/playbooks_tags.rst:405 9806msgid "And you might include the tasks file above in a playbook:" 9807msgstr "また、Playbook に上記のタスクファイルを含めることができます。" 9808 9809#: ../../rst/user_guide/playbooks_tags.rst:417 9810msgid "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." 9811msgstr "``ansible-playbook -i hosts myplaybook.yml --tags \"mytag\"`` を使用して Playbook を実行すると、Ansible はタグのないタスクを省略し、タグ付けされた個別のタスクを実行し、ブロック内の 2 つのタスクを実行します。" 9812 9813#: ../../rst/user_guide/playbooks_tags.rst:420 9814msgid "Configuring tags globally" 9815msgstr "タグのグローバル設定" 9816 9817#: ../../rst/user_guide/playbooks_tags.rst:422 9818msgid "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." 9819msgstr "デフォルトで特定のタグを実行するか、スキップする場合は、Ansible 設定で :ref:`TAGS_RUN` オプションおよび :ref:`TAGS_SKIP` オプションを使用してこれらのデフォルトを設定できます。" 9820 9821#: ../../rst/user_guide/playbooks_templating.rst:5 9822msgid "Templating (Jinja2)" 9823msgstr "テンプレート作成 (Jinja2)" 9824 9825#: ../../rst/user_guide/playbooks_templating.rst:7 9826msgid "Ansible uses Jinja2 templating to enable dynamic expressions and access to variables. Ansible includes a lot of specialized filters and tests for templating. You can use all the :ref:`standard filters and tests <jinja2:builtin-filters>` included in Jinja2 as well. Ansible also offers a new plugin type: :ref:`lookup_plugins`." 9827msgstr "Ansible は Jinja2 のテンプレートを使用して、動的な表現や変数へのアクセスを可能にしています。Ansible には、テンプレート化に特化したフィルターやテストが多数含まれています。Jinja2 に含まれる :ref:`標準フィルターおよびテスト <jinja2:builtin-filters>` もすべて使用することができます。また、Ansible では、新しいプラグインタイプ :ref:`lookup_plugins` も提供します。" 9828 9829#: ../../rst/user_guide/playbooks_templating.rst:9 9830msgid "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." 9831msgstr "テンプレート化はすべて、タスクが送信されターゲットマシンで実行する **前** に、Ansible のコントローラーで行われます。このアプローチにより、ターゲットでのパッケージ要件を最小限に抑えることができます (jinja2 はコントローラーでのみ必要です)。また、Ansible がターゲットマシンに渡すデータの量も制限されます。Ansible は、コントローラーですべてのデータを渡してターゲットで解析するのではなく、コントローラーでテンプレートを解析し、各タスクに必要な情報だけをターゲットマシンに渡します。" 9832 9833#: ../../rst/user_guide/playbooks_templating.rst:25 9834msgid "Get the current time" 9835msgstr "現在の時間を取得" 9836 9837#: ../../rst/user_guide/playbooks_templating.rst:29 9838msgid "The ``now()`` Jinja2 function retrieves a Python datetime object or a string representation for the current time." 9839msgstr "Jinja2 関数 ``now()`` は、Python の datetime オブジェクトまたは現在の時間を表す文字列を取得します。" 9840 9841#: ../../rst/user_guide/playbooks_templating.rst:31 9842msgid "The ``now()`` function supports 2 arguments:" 9843msgstr "``now()`` 関数は、2 つの引数をサポートします。" 9844 9845#: ../../rst/user_guide/playbooks_templating.rst:34 9846msgid "utc" 9847msgstr "utc" 9848 9849#: ../../rst/user_guide/playbooks_templating.rst:34 9850msgid "Specify ``True`` to get the current time in UTC. Defaults to ``False``." 9851msgstr "UTC で現在の時間を取得するには、``True`` を指定します。デフォルトは ``False`` です。" 9852 9853#: ../../rst/user_guide/playbooks_templating.rst:38 9854msgid "fmt" 9855msgstr "fmt" 9856 9857#: ../../rst/user_guide/playbooks_templating.rst:37 9858msgid "Accepts a `strftime <https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior>`_ string that returns a formatted date time string." 9859msgstr "`strftime <https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior>`_ の文字列を受け取り、形式化された日時文字列を返します。" 9860 9861#: ../../rst/user_guide/playbooks_tests.rst:5 9862msgid "Tests" 9863msgstr "テスト" 9864 9865#: ../../rst/user_guide/playbooks_tests.rst:7 9866msgid "`Tests <http://jinja.pocoo.org/docs/dev/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." 9867msgstr "Jinja の `テスト <http://jinja.pocoo.org/docs/dev/templates/#tests>`_ は、テンプレート式を評価して、True または False を返します。Jinja にはこれらの多くが同梱されています。Jinja の公式テンプレートドキュメントの「`builtin tests`_」をご覧ください。" 9868 9869#: ../../rst/user_guide/playbooks_tests.rst:9 9870msgid "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." 9871msgstr "テストとフィルターの主な違いは、Jinja のテストは比較に使用されるのに対し、フィルターはデータ操作に使用され、Jinja では用途が異なります。テストは、``map()`` や ``select()`` のように、リスト内の項目を選択するリスト処理フィルターにも使用できます。" 9872 9873#: ../../rst/user_guide/playbooks_tests.rst:11 9874msgid "Like all templating, tests always execute on the Ansible controller, **not** on the target of a task, as they test local data." 9875msgstr "すべてのテンプレートと同様、テストは常に、ローカルデータをテストする際にタスクのターゲットでは **なく**、Ansible コントローラーで実行されます。" 9876 9877#: ../../rst/user_guide/playbooks_tests.rst:13 9878msgid "In addition to those Jinja2 tests, Ansible supplies a few more and users can easily create their own." 9879msgstr "このような Jinja2 テストに加えて、Ansible はより多くのものを提供しており、ユーザーは独自のテストを簡単に作成できます。" 9880 9881#: ../../rst/user_guide/playbooks_tests.rst:21 9882msgid "Test syntax" 9883msgstr "テストの構文" 9884 9885#: ../../rst/user_guide/playbooks_tests.rst:23 9886msgid "`Test syntax <http://jinja.pocoo.org/docs/dev/templates/#tests>`_ varies from `filter syntax <http://jinja.pocoo.org/docs/dev/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." 9887msgstr "`テストの構文 <http://jinja.pocoo.org/docs/dev/templates/#tests>` は、`フィルターの構文 <http://jinja.pocoo.org/docs/dev/templates/#filters>`_ (``variable | filter``) と異なります。これまで Ansible は、テストを jinja テストと jinja フィルターの両方に登録し、filter 構文を使用して参照できるようにしてきました。" 9888 9889#: ../../rst/user_guide/playbooks_tests.rst:25 9890msgid "As of Ansible 2.5, using a jinja test as a filter will generate a warning." 9891msgstr "Ansible 2.5 の時点では、jinja テストをフィルターとして使用すると警告が生成されます。" 9892 9893#: ../../rst/user_guide/playbooks_tests.rst:27 9894msgid "The syntax for using a jinja test is as follows::" 9895msgstr "jinja テストを使用するための構文は、以下のとおりです。" 9896 9897#: ../../rst/user_guide/playbooks_tests.rst:31 9898msgid "Such as::" 9899msgstr "例::" 9900 9901#: ../../rst/user_guide/playbooks_tests.rst:38 9902msgid "Testing strings" 9903msgstr "文字列のテスト" 9904 9905#: ../../rst/user_guide/playbooks_tests.rst:40 9906msgid "To match strings against a substring or a regular expression, use the ``match``, ``search`` or ``regex`` tests::" 9907msgstr "サブ文字列または正規表現に対して文字列と一致させるには、「``match``」、「``search``」、または「``regex``」を使用します。" 9908 9909#: ../../rst/user_guide/playbooks_tests.rst:62 9910msgid "``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>`_." 9911msgstr "``match`` は、文字列の先頭でパターンを見つけた場合に成功し、``search`` は、文字列内の任意の場所でパターンを見つけた場合に成功します。デフォルトでは、``regex`` は ``search`` のように動作しますが、``regex`` は ``match_type`` キーワード引数を渡すことで、他のテストも実行するように構成することができます。特に、``match_type`` は、検索を実行する際に使用される ``re`` メソッドを決定します。完全なリストは、`こちら <https://docs.python.org/3/library/re.html#regular-expression-objects>`_ にある関連 Python ドキュメントを参照してください。" 9912 9913#: ../../rst/user_guide/playbooks_tests.rst:64 9914msgid "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." 9915msgstr "すべての文字列テストは、任意の ``ignorecase`` 引数および ``multiline`` 引数を取ります。これらは、Python の ``re`` ライブラリーからそれぞれ ``re.I`` および ``re.M`` に対応します。" 9916 9917#: ../../rst/user_guide/playbooks_tests.rst:69 9918msgid "Vault" 9919msgstr "Vault" 9920 9921#: ../../rst/user_guide/playbooks_tests.rst:73 9922msgid "You can test whether a variable is an inline single vault encrypted value using the ``vault_encrypted`` test." 9923msgstr "変数がインラインの 1 つの vault で暗号化された値であるかどうかは、``vault_encrypted`` テストでテストできます。" 9924 9925#: ../../rst/user_guide/playbooks_tests.rst:93 9926msgid "Testing truthiness" 9927msgstr "真偽の検証" 9928 9929#: ../../rst/user_guide/playbooks_tests.rst:97 9930msgid "As of Ansible 2.10, you can now perform Python like truthy and falsy checks." 9931msgstr "Ansible 2.10 以降では、Python を真偽チェックのように実行できるようになりました。" 9932 9933#: ../../rst/user_guide/playbooks_tests.rst:113 9934msgid "Additionally, the ``truthy`` and ``falsy`` tests accept an optional parameter called ``convert_bool`` that will attempt to convert boolean indicators to actual booleans." 9935msgstr "また、``truthy`` テストおよび ``falsy`` テストは、ブール値インジケーターを実際のブール値に変換しようとする ``convert_bool`` と呼ばれる任意のパラメーターを受け入れます。" 9936 9937#: ../../rst/user_guide/playbooks_tests.rst:133 9938msgid "Comparing versions" 9939msgstr "バージョンの比較" 9940 9941#: ../../rst/user_guide/playbooks_tests.rst:137 9942msgid "In 2.5 ``version_compare`` was renamed to ``version``" 9943msgstr "2.5 では、``version_compare`` の名前が ``version`` に変更されました。" 9944 9945#: ../../rst/user_guide/playbooks_tests.rst:139 9946msgid "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." 9947msgstr "``ansible_facts['distribution_version']`` のバージョンが「12.04」以上かどうかを確認するなど、バージョン番号を比較するには、``version`` テストを使用します。" 9948 9949#: ../../rst/user_guide/playbooks_tests.rst:142 9950msgid "The ``version`` test can also be used to evaluate the ``ansible_facts['distribution_version']``::" 9951msgstr "``version`` テストを使用して ``ansible_facts['distribution_version']`` を評価することもできます。" 9952 9953#: ../../rst/user_guide/playbooks_tests.rst:146 9954msgid "If ``ansible_facts['distribution_version']`` is greater than or equal to 12.04, this test returns True, otherwise False." 9955msgstr "``ansible_facts['distribution_version']`` が 12.04 以上の場合は、このテストで True が返り、それ以外の場合は False が返ります。" 9956 9957#: ../../rst/user_guide/playbooks_tests.rst:148 9958msgid "The ``version`` test accepts the following operators::" 9959msgstr "``version`` テストでは、以下の演算子を受け入れます。" 9960 9961#: ../../rst/user_guide/playbooks_tests.rst:152 9962msgid "This test also accepts a 3rd parameter, ``strict`` which defines if strict version parsing as defined by ``distutils.version.StrictVersion`` should be used. The default is ``False`` (using ``distutils.version.LooseVersion``), ``True`` enables strict version parsing::" 9963msgstr "このテストは、3 番目のパラメーター ``strict`` も受け入れます。これは、``distutils.version.StrictVersion`` で定義された厳格なバージョン解析機能を使用できます。デフォルトは ``False`` (``distutils.version.LooseVersion`` を使用) で、``True`` は、厳格なバージョン解析を有効にします。" 9964 9965#: ../../rst/user_guide/playbooks_tests.rst:156 9966msgid "As of Ansible 2.11 the ``version`` test accepts a ``version_type`` parameter which is mutually exclusive with ``strict``, and accepts the following values::" 9967msgstr "Ansible 2.11 の時点で、``version`` テストは ``strict`` と相互に排他的な ``version_type`` パラメーターを受け入れ、以下の値を受け入れます。" 9968 9969#: ../../rst/user_guide/playbooks_tests.rst:160 9970msgid "Using ``version_type`` to compare a semantic version would be achieved like the following::" 9971msgstr "``version_type`` を使用してセマンティックバージョンを比較すると、以下のように実行されます。" 9972 9973#: ../../rst/user_guide/playbooks_tests.rst:164 9974msgid "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>`_::" 9975msgstr "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>`_ で説明されているように ``{{ }}`` を使用しないでください。" 9976 9977#: ../../rst/user_guide/playbooks_tests.rst:177 9978msgid "Set theory tests" 9979msgstr "セット理論テスト" 9980 9981#: ../../rst/user_guide/playbooks_tests.rst:181 9982msgid "In 2.5 ``issubset`` and ``issuperset`` were renamed to ``subset`` and ``superset``" 9983msgstr "2.5 では、``issubset`` および ``issuperset`` の名前が ``subset`` および ``superset`` に変更されました。" 9984 9985#: ../../rst/user_guide/playbooks_tests.rst:183 9986msgid "To see if a list includes or is included by another list, you can use 'subset' and 'superset'::" 9987msgstr "リストに別のリストが含まれているか、またはリストが別のリストに含まれているかを確認するには、「subset」および「superset」を使用します。" 9988 9989#: ../../rst/user_guide/playbooks_tests.rst:200 9990msgid "Testing if a list contains a value" 9991msgstr "リストに値が含まれるかどうかのテスト" 9992 9993#: ../../rst/user_guide/playbooks_tests.rst:204 9994msgid "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::" 9995msgstr "Ansible には、Jinja2 が提供する ``in`` テストとは逆に、同様の動作をする ``contains`` テストが含まれています。``contains`` テストは、フィルターの ``select``、``reject``、``selectattr``、および ``rejectattr`` で動作するように設計されています。" 9996 9997#: ../../rst/user_guide/playbooks_tests.rst:236 9998msgid "Testing if a list value is True" 9999msgstr "リスト値が True の場合のテスト" 10000 10001#: ../../rst/user_guide/playbooks_tests.rst:238 10002msgid "You can use `any` and `all` to check if any or all elements in a list are true or not::" 10003msgstr "`any` および `all` を使用して、リスト内の一部またはすべての要素が true かどうかを確認できます。" 10004 10005#: ../../rst/user_guide/playbooks_tests.rst:261 10006msgid "Testing paths" 10007msgstr "パスのテスト" 10008 10009#: ../../rst/user_guide/playbooks_tests.rst:263 10010msgid "In 2.5 the following tests were renamed to remove the ``is_`` prefix" 10011msgstr "2.5 では、以下のテストの名前が変更になり、``is_`` プレフィックスが削除されました。" 10012 10013#: ../../rst/user_guide/playbooks_tests.rst:265 10014msgid "The following tests can provide information about a path on the controller::" 10015msgstr "以下のテストは、コントローラー上のパスに関する情報を提供します。" 10016 10017#: ../../rst/user_guide/playbooks_tests.rst:296 10018msgid "Testing size formats" 10019msgstr "サイズ形式のテスト" 10020 10021#: ../../rst/user_guide/playbooks_tests.rst:298 10022msgid "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." 10023msgstr "``human_readable`` 関数および ``human_to_bytes`` 関数を使用すると、Playbook をテストして、タスクで適切なサイズの形式を使用しているかどうか、また、コンピューターにはバイト形式、およびユーザーには人間が判読可能な形式を提供しているかどうかを確認することができます。" 10024 10025#: ../../rst/user_guide/playbooks_tests.rst:303 10026msgid "Human readable" 10027msgstr "人間が読み取り可能" 10028 10029#: ../../rst/user_guide/playbooks_tests.rst:305 10030msgid "Asserts whether the given string is human readable or not." 10031msgstr "指定の文字列が人が判読できるかどうかをアサートします。" 10032 10033#: ../../rst/user_guide/playbooks_tests.rst:324 10034msgid "Human to bytes" 10035msgstr "人間からバイト" 10036 10037#: ../../rst/user_guide/playbooks_tests.rst:326 10038msgid "Returns the given string in the Bytes format." 10039msgstr "指定した文字列をバイト形式で返します。" 10040 10041#: ../../rst/user_guide/playbooks_tests.rst:350 10042msgid "Testing task results" 10043msgstr "タスク結果のテスト" 10044 10045#: ../../rst/user_guide/playbooks_tests.rst:352 10046msgid "The following tasks are illustrative of the tests meant to check the status of tasks::" 10047msgstr "以下のタスクは、タスクのステータスを確認するためのテストを示しています。" 10048 10049#: ../../rst/user_guide/playbooks_tests.rst:381 10050msgid "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." 10051msgstr "2.1 以降、文法を厳密にする必要がある場合に、success、failure、change、および skip を使用して、文法が一致するようにすることもできます。" 10052 10053#: ../../rst/user_guide/playbooks_variables.rst:5 10054msgid "Using Variables" 10055msgstr "変数の使用" 10056 10057#: ../../rst/user_guide/playbooks_variables.rst:7 10058msgid "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." 10059msgstr "Ansible は変数を使用してシステム間の違いを管理します。Ansible では、1 つのコマンドで複数の異なるシステム上でタスクや Playbook を実行することができます。これらの異なるシステム間の差異を表現するために、リストやディクショナリーなどの標準的な YAML 構文で変数を作成できます。これらの変数は、Playbook、:ref:`インベントリー <intro_inventory>`、再利用可能な :ref:`ファイル <playbooks_reuse>`、または :ref:`ロール <playbooks_reuse_roles>`、またはコマンドラインで定義できます。また、タスクの戻り値を新しい変数として登録することで、Playbook の実行中に変数を作成することもできます。" 10060 10061#: ../../rst/user_guide/playbooks_variables.rst:9 10062msgid "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." 10063msgstr "ファイルで定義したり、コマンドラインで渡したり、タスクの戻り値を新しい変数として登録したりして変数を作成した後は、その変数をモジュールの引数、:ref:`conditional \"when\" statements <playbooks_conditionals>`、:ref:`templates <playbooks_templating>`、および :ref:`loops <playbooks_loops>` で使用することができます。`ansible-examples github repository <https://github.com/ansible/ansible-examples>`_ には、Ansible での変数の使用例が多数掲載されています。" 10064 10065#: ../../rst/user_guide/playbooks_variables.rst:11 10066msgid "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." 10067msgstr "このページの概念と例を理解したら、リモートシステムから取得する変数である :ref:`Ansible facts <vars_and_facts>` を確認します。" 10068 10069#: ../../rst/user_guide/playbooks_variables.rst:19 10070msgid "Creating valid variable names" 10071msgstr "有効な変数名の作成" 10072 10073#: ../../rst/user_guide/playbooks_variables.rst:21 10074msgid "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." 10075msgstr "すべての文字列が有効な Ansible の変数名になるわけではありません。変数名には、文字、数字、アンダースコアのみを含めることができます。`Python キーワード`_ または :ref:`playbook キーワード<playbook_keywords>` は有効な変数名ではありません。変数名は、数字で始めることはできません。" 10076 10077#: ../../rst/user_guide/playbooks_variables.rst:23 10078msgid "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." 10079msgstr "変数名はアンダースコアで始めることができます。多くのプログラミング言語では、アンダースコアで始まる変数はプライベートです。Ansible ではこれは当てはまりません。アンダースコアで始まる変数は、他の変数とまったく同じように扱われます。プライバシーやセキュリティーのために、この規約に依存しないでください。" 10080 10081#: ../../rst/user_guide/playbooks_variables.rst:25 10082msgid "This table gives examples of valid and invalid variable names:" 10083msgstr "この表は、有効かつ無効な変数名の例を紹介します。" 10084 10085#: ../../rst/user_guide/playbooks_variables.rst:31 10086msgid "Valid variable names" 10087msgstr "有効な変数名" 10088 10089#: ../../rst/user_guide/playbooks_variables.rst:31 10090msgid "Not valid" 10091msgstr "有効ではない" 10092 10093#: ../../rst/user_guide/playbooks_variables.rst:33 10094msgid "``foo``" 10095msgstr "``foo``" 10096 10097#: ../../rst/user_guide/playbooks_variables.rst:33 10098msgid "``*foo``, `Python keywords`_ such as ``async`` and ``lambda``" 10099msgstr "``*foo``、`Python キーワード`_ (``async``、``lambda`` など)" 10100 10101#: ../../rst/user_guide/playbooks_variables.rst:35 10102msgid "``foo_env``" 10103msgstr "``foo_env``" 10104 10105#: ../../rst/user_guide/playbooks_variables.rst:35 10106msgid ":ref:`playbook keywords<playbook_keywords>` such as ``environment``" 10107msgstr "``environment`` などの :ref:`playbook キーワード<playbook_keywords>`" 10108 10109#: ../../rst/user_guide/playbooks_variables.rst:37 10110msgid "``foo_port``" 10111msgstr "``foo_port``" 10112 10113#: ../../rst/user_guide/playbooks_variables.rst:37 10114msgid "``foo-port``, ``foo port``, ``foo.port``" 10115msgstr "``foo-port``、``foo port``、``foo.port``" 10116 10117#: ../../rst/user_guide/playbooks_variables.rst:39 10118msgid "``foo5``, ``_foo``" 10119msgstr "``foo5``、``_foo``" 10120 10121#: ../../rst/user_guide/playbooks_variables.rst:39 10122msgid "``5foo``, ``12``" 10123msgstr "``5foo``、``12``" 10124 10125#: ../../rst/user_guide/playbooks_variables.rst:45 10126msgid "Simple variables" 10127msgstr "単純な変数" 10128 10129#: ../../rst/user_guide/playbooks_variables.rst:47 10130msgid "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`." 10131msgstr "単純変数は、変数名と 1 つの値を組み合わせたものです。この構文 (および後述のリストやディレクトリーの構文) は、さまざまな場所で使用できます。インベントリー、Playbook、再利用可能なファイル、ロール、コマンドラインでの変数設定の詳細については、「:ref:`setting_variables`」を参照してください。" 10132 10133#: ../../rst/user_guide/playbooks_variables.rst:50 10134msgid "Defining simple variables" 10135msgstr "簡単な変数の定義" 10136 10137#: ../../rst/user_guide/playbooks_variables.rst:52 10138msgid "You can define a simple variable using standard YAML syntax. For example::" 10139msgstr "標準の YAML 構文を使用して単純な変数を定義できます。以下に例を示します。" 10140 10141#: ../../rst/user_guide/playbooks_variables.rst:57 10142msgid "Referencing simple variables" 10143msgstr "単純な変数の参照" 10144 10145#: ../../rst/user_guide/playbooks_variables.rst:59 10146msgid "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::" 10147msgstr "変数を定義した後は、Jinja2 の構文を使用して変数を参照します。Jinja2 の変数には二重の中括弧が使用されます。たとえば、``My amp goes to {{ max_amp_value }}`` という式は、最も基本的な形の変数置換を示しています。Playbook では、Jinja2 構文を使用できます。以下に例を示します。" 10148 10149#: ../../rst/user_guide/playbooks_variables.rst:65 10150msgid "In this example, the variable defines the location of a file, which can vary from one system to another." 10151msgstr "この例では、変数がファイルの場所を定義していますが、これはシステムごとに異なる可能性があります。" 10152 10153#: ../../rst/user_guide/playbooks_variables.rst:69 10154msgid "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." 10155msgstr "Ansible では、:ref:`templates <playbooks_templating>` で Jinja2 のループや条件分岐を使用できますが、Playbook では使用できません。タスクのループを作成することはできません。Ansible の Playbook は純粋に機械で解析可能な YAML です。" 10156 10157#: ../../rst/user_guide/playbooks_variables.rst:74 10158msgid "When to quote variables (a YAML gotcha)" 10159msgstr "変数を引用するタイミング (YAML に関する注意点)" 10160 10161#: ../../rst/user_guide/playbooks_variables.rst:76 10162msgid "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." 10163msgstr "値を ``{{ foo }}`` で始めた場合、有効な YAML 構文を作成するためには式全体を引用しなければなりません。式全体を引用符で囲まないと、YAML パーサーはその構文を解釈できません。それは変数かもしれないし、YAML ディレクトリーの始まりかもしれません。YAML の記述方法については、「:ref:`yaml_syntax`」のドキュメントを参照してください。" 10164 10165#: ../../rst/user_guide/playbooks_variables.rst:78 10166msgid "If you use a variable without quotes like this::" 10167msgstr "引用符なしの変数を使用する場合は、以下のようになります。" 10168 10169#: ../../rst/user_guide/playbooks_variables.rst:84 10170msgid "You will see: ``ERROR! Syntax Error while loading YAML.`` If you add quotes, Ansible works correctly::" 10171msgstr "``ERROR! Syntax Error while loading YAML.`` を参照してください。引用符を追加すると、Ansible が正常に機能します。" 10172 10173#: ../../rst/user_guide/playbooks_variables.rst:93 10174msgid "List variables" 10175msgstr "リスト変数" 10176 10177#: ../../rst/user_guide/playbooks_variables.rst:95 10178msgid "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." 10179msgstr "リスト変数は、変数名と複数の値を組み合わせたものです。複数の値は、項目別のリストとして、または角括弧 ``[]`` の中にコンマで区切って格納できます。" 10180 10181#: ../../rst/user_guide/playbooks_variables.rst:98 10182msgid "Defining variables as lists" 10183msgstr "変数をリストとして定義" 10184 10185#: ../../rst/user_guide/playbooks_variables.rst:100 10186msgid "You can define variables with multiple values using YAML lists. For example::" 10187msgstr "YAML リストを使用して、複数の値で変数を定義できます。以下に例を示します。" 10188 10189#: ../../rst/user_guide/playbooks_variables.rst:108 10190msgid "Referencing list variables" 10191msgstr "リスト変数の参照" 10192 10193#: ../../rst/user_guide/playbooks_variables.rst:110 10194msgid "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::" 10195msgstr "リスト (配列とも呼ばれる) として定義された変数を使用する場合は、そのリストから個々の特定のフィールドを使用することができます。リストの最初の項目は項目 0、2 番目の項目は項目 1 です。以下に例を示します。" 10196 10197#: ../../rst/user_guide/playbooks_variables.rst:114 10198msgid "The value of this expression would be \"northeast\"." 10199msgstr "この式の値は「northeast」になります。" 10200 10201#: ../../rst/user_guide/playbooks_variables.rst:119 10202msgid "Dictionary variables" 10203msgstr "ディクショナリー変数" 10204 10205#: ../../rst/user_guide/playbooks_variables.rst:121 10206msgid "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." 10207msgstr "ディクショナリーは、データをキーと値のペアに保存します。通常、ディクショナリーは ID またはユーザープロファイルに含まれる情報などの関連データを保存するために使用されます。" 10208 10209#: ../../rst/user_guide/playbooks_variables.rst:124 10210msgid "Defining variables as key:value dictionaries" 10211msgstr "変数を key:value ディクショナリーとして定義" 10212 10213#: ../../rst/user_guide/playbooks_variables.rst:126 10214msgid "You can define more complex variables using YAML dictionaries. A YAML dictionary maps keys to values. For example::" 10215msgstr "YAML ディクショナリーを使用してより複雑な変数を定義できます。YAML ディクショナリーはキーを値にマッピングします。以下に例を示します。" 10216 10217#: ../../rst/user_guide/playbooks_variables.rst:133 10218msgid "Referencing key:value dictionary variables" 10219msgstr "key:value ディクショナリー変数の参照" 10220 10221#: ../../rst/user_guide/playbooks_variables.rst:135 10222msgid "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::" 10223msgstr "key:value ディクショナリー (ハッシュとも呼ばれます) として定義された変数を使用する場合は、括弧表記またはドット表記のいずれかを使用して、そのディクショナリーの個々の特定のフィールドを使用できます。" 10224 10225#: ../../rst/user_guide/playbooks_variables.rst:140 10226msgid "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:" 10227msgstr "これらの例では、どちらも同じ値 (「one」) を参照しています。括弧表記は常に有効です。ドット表記では、一部のキーが python ディクショナリーの属性やメソッドと衝突するため、問題が生じます。2 つのアンダースコアで始まって終わるキー (python では特別な意味を持つものとして予約されています) や、既知の公開属性を使用する場合は、括弧表記を使用してください。" 10228 10229#: ../../rst/user_guide/playbooks_variables.rst:142 10230msgid "``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``." 10231msgstr "``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``" 10232 10233#: ../../rst/user_guide/playbooks_variables.rst:147 10234msgid "Registering variables" 10235msgstr "変数の登録" 10236 10237#: ../../rst/user_guide/playbooks_variables.rst:149 10238msgid "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::" 10239msgstr "タスクキーワード ``register`` を使用して、Ansible タスクの出力から変数を作成することができます。登録した変数は、プレイ中の後続のタスクで使用することができます。以下に例を示します。" 10240 10241#: ../../rst/user_guide/playbooks_variables.rst:164 10242msgid "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``." 10243msgstr "登録された変数を後のタスクの条件で使用する例は、「:ref:`playbooks_conditionals`」を参照してください。登録した変数には、単純な変数、リスト変数、ディクショナリー変数、複雑にネストしたデータ構造などがあります。各モジュールのドキュメントには、そのモジュールの戻り値を説明した ``RETURN`` セクションがあります。特定のタスクの値を確認するには、``-v`` で Playbook を実行します。" 10244 10245#: ../../rst/user_guide/playbooks_variables.rst:166 10246msgid "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." 10247msgstr "登録された変数はメモリーに保存されます。登録された変数を将来のプレイで使用するためにキャッシュすることはできません。登録された変数は、現在の Playbook の残りの実行中、ホスト上でのみ有効です。" 10248 10249#: ../../rst/user_guide/playbooks_variables.rst:168 10250msgid "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." 10251msgstr "登録された変数は、ホストレベルの変数です。ループのあるタスクで変数を登録すると、登録された変数にはループ内の各項目の値が入ります。ループ中に変数に置かれたデータ構造には、``results`` 属性、つまりモジュールからの全応答のリストが含まれます。この動作の詳細な例については、ループで登録の使用に関する「:ref:`playbooks_loops`」セクションを参照してください。" 10252 10253#: ../../rst/user_guide/playbooks_variables.rst:170 10254msgid "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." 10255msgstr "タスクが失敗またはスキップしても、タグに基づいてタスクがスキップされていない限り、Ansible は失敗またはスキップのステータスで変数を登録します。タグの追加および使用に関する情報は、「:ref:`tags`」を参照してください。" 10256 10257#: ../../rst/user_guide/playbooks_variables.rst:175 10258msgid "Referencing nested variables" 10259msgstr "ネストされた変数の参照" 10260 10261#: ../../rst/user_guide/playbooks_variables.rst:177 10262msgid "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::" 10263msgstr "多くの登録された変数 (および :ref:`facts <vars_and_facts>`) は、ネストされた YAML または JSON データ構造です。これらのネストしたデータ構造の値には、単純な ``{{ foo }}`` の構文ではアクセスできません。括弧表記またはドット表記のいずれかを使用する必要があります。たとえば、括弧表記を使用してファクトから IP アドレスを参照するには、以下を行います。" 10264 10265#: ../../rst/user_guide/playbooks_variables.rst:181 10266msgid "To reference an IP address from your facts using the dot notation::" 10267msgstr "ドット表記を使用してファクトから IP アドレスを参照するには、以下を実行します。" 10268 10269#: ../../rst/user_guide/playbooks_variables.rst:189 10270msgid "Transforming variables with Jinja2 filters" 10271msgstr "Jinja2 フィルターを使用した変数の変換" 10272 10273#: ../../rst/user_guide/playbooks_variables.rst:191 10274msgid "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`." 10275msgstr "Jinja2 のフィルターは、テンプレート式内の変数の値を変換することができます。たとえば、``capitalize`` フィルターは、渡された値をすべて大文字にします。``to_yaml`` フィルターおよび ``to_json`` フィルターは、変数の値の形式を変更します。Jinja2 には多くの `built-in フィルター <https://jinja.palletsprojects.com/templates/#builtin-filters>`_ があり、Ansible にはさらに多くのフィルターが用意されています。フィルターのその他の例については、「:ref:`playbooks_filters`」を参照してください。" 10276 10277#: ../../rst/user_guide/playbooks_variables.rst:196 10278msgid "Where to set variables" 10279msgstr "変数を設定する場所" 10280 10281#: ../../rst/user_guide/playbooks_variables.rst:198 10282msgid "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>`." 10283msgstr "変数は、インベントリー、Playbook、再利用可能ファイル、ロール、コマンドラインなど、さまざまな場所で定義することができます。Ansible は、検出可能なすべての変数を読み込み、:ref:`変数の優先順位ルール <ansible_variable_precedence>` に基づいて適用する変数を選択します。" 10284 10285#: ../../rst/user_guide/playbooks_variables.rst:203 10286msgid "Defining variables in inventory" 10287msgstr "インベントリーでの変数の定義" 10288 10289#: ../../rst/user_guide/playbooks_variables.rst:205 10290msgid "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." 10291msgstr "個々のホストごとに異なる変数を定義したり、インベントリー内のホストグループに共有変数を設定することができます。たとえば、``[Boston]`` グループのすべてのマシンが NTP サーバーとして「boston.ntp.example.com」を使用する場合は、グループ変数を設定することができます。:ref:`intro_inventory` ページには、インベントリーで :ref:`host variables <host_variables>` および :ref:`group variables <group_variables>` を設定するための詳細が記載されています。" 10292 10293#: ../../rst/user_guide/playbooks_variables.rst:210 10294msgid "Defining variables in a play" 10295msgstr "プレイでの変数の定義" 10296 10297#: ../../rst/user_guide/playbooks_variables.rst:212 10298msgid "You can define variables directly in a playbook play::" 10299msgstr "変数は Playbook プレイで直接定義できます。" 10300 10301#: ../../rst/user_guide/playbooks_variables.rst:218 10302msgid "When you define variables in a play, they are only visible to tasks executed in that play." 10303msgstr "プレイで変数を定義すると、そのプレイで実行しているタスクでのみ表示されます。" 10304 10305#: ../../rst/user_guide/playbooks_variables.rst:224 10306msgid "Defining variables in included files and roles" 10307msgstr "インクルードファイルおよびロールでの変数の定義" 10308 10309#: ../../rst/user_guide/playbooks_variables.rst:226 10310msgid "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`." 10311msgstr "変数は、再利用可能な変数ファイルや再利用可能なロールに定義することができます。再利用可能な変数ファイルに変数を定義すると、機密性の高い変数が Playbook から分離されます。この分離により、パスワードなどの機密情報や個人情報を流出させることなく、ソースコントロールソフトウェアに Playbook を保存したり、Playbook を共有したりすることができます。再利用可能なファイルやロールの作成は、「:ref:`playbooks_reuse`」を参照してください。" 10312 10313#: ../../rst/user_guide/playbooks_variables.rst:228 10314msgid "This example shows how you can include variables defined in an external file::" 10315msgstr "この例は、外部ファイルで定義された変数を追加する方法を示しています。" 10316 10317#: ../../rst/user_guide/playbooks_variables.rst:244 10318msgid "The contents of each variables file is a simple YAML dictionary. For example::" 10319msgstr "各変数ファイルの内容は、単純な YAML ディクショナリーです。以下に例を示します。" 10320 10321#: ../../rst/user_guide/playbooks_variables.rst:252 10322msgid "You can keep per-host and per-group variables in similar files. To learn about organizing your variables, see :ref:`splitting_out_vars`." 10323msgstr "ホスト別およびグループ別の変数を同様のファイルに維持することができます。変数を整理する方法は、「:ref:`splitting_out_vars`」を参照してください。" 10324 10325#: ../../rst/user_guide/playbooks_variables.rst:257 10326msgid "Defining variables at runtime" 10327msgstr "ランタイム時の変数の定義" 10328 10329#: ../../rst/user_guide/playbooks_variables.rst:259 10330msgid "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." 10331msgstr "Playbook の実行時に変数を定義するには、コマンドラインで ``--extra-vars`` (または ``-e``) 引数を使用して変数を渡します。また、``vars_prompt`` (:ref:`playbooks_prompts` 参照) でユーザーの入力を要求することもできます。コマンドラインで変数を渡すときは、以下のいずれかの形式で、1 つまたは複数の変数を含む一重引用符で囲まれた文字列を使用します。" 10332 10333#: ../../rst/user_guide/playbooks_variables.rst:262 10334msgid "key=value format" 10335msgstr "key=value 形式" 10336 10337#: ../../rst/user_guide/playbooks_variables.rst:264 10338msgid "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." 10339msgstr "``key=value`` 構文を使用して渡される値は文字列として解釈されます。ブール値、整数、浮動小数点、リストなど、文字列以外の値を渡す必要がある場合は、JSON 形式を使用します。" 10340 10341#: ../../rst/user_guide/playbooks_variables.rst:271 10342msgid "JSON string format" 10343msgstr "JSON 文字列の形式" 10344 10345#: ../../rst/user_guide/playbooks_variables.rst:278 10346msgid "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::" 10347msgstr "``--extra-vars`` で変数を渡す場合には、マークアップ (JSON など) とシェルの両方で、引用符やその他の特殊文字を適切にエスケープする必要があります。" 10348 10349#: ../../rst/user_guide/playbooks_variables.rst:284 10350msgid "If you have a lot of special characters, use a JSON or YAML file containing the variable definitions." 10351msgstr "特殊文字が多数ある場合は、変数定義を含む JSON ファイルまたは YAML ファイルを使用します。" 10352 10353#: ../../rst/user_guide/playbooks_variables.rst:287 10354msgid "vars from a JSON or YAML file" 10355msgstr "JSON ファイルまたは YAML ファイルの変数" 10356 10357#: ../../rst/user_guide/playbooks_variables.rst:297 10358msgid "Variable precedence: Where should I put a variable?" 10359msgstr "変数の優先順位: 変数をどこに置くべきか" 10360 10361#: ../../rst/user_guide/playbooks_variables.rst:299 10362msgid "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." 10363msgstr "同じ名前の複数の変数をさまざまな場所に設定することができます。これを行うと、Ansible は検出可能なすべての変数を読み込み、次に変数の優先順位に基づいて適用する変数を選択します。つまり、異なる変数が一定の順序で互いに上書きされます。" 10364 10365#: ../../rst/user_guide/playbooks_variables.rst:301 10366msgid "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`." 10367msgstr "変数の定義に関するガイドライン (特定のタイプの変数をどこで定義するか) に合意したチームやプロジェクトは、通常、変数の優先順位に関する懸念を回避することができます。各変数は、一箇所で定義することが推奨されます。どこで変数を定義するかを把握し、簡潔さを保ってください。例については、「:ref:`variable_examples`」を参照してください。" 10368 10369#: ../../rst/user_guide/playbooks_variables.rst:303 10370msgid "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`." 10371msgstr "変数で設定できる動作パラメーターの中には、Ansible の構成、コマンドラインオプション、および Playbook キーワードで設定できるものがあります。たとえば、Ansible がリモートデバイスへの接続に使用するユーザーは、変数では ``ansible_user``、構成ファイルでは``DEFAULT_REMOTE_USER``、コマンドラインオプションでは ``-u`` 、Playbook キーワードでは ``remote_user`` で定義できます。変数と別の方法で同じパラメーターを定義した場合は、変数が別の設定を上書きします。この方法では、ホスト固有の設定がより一般的な設定を上書きします。これらのさまざまな設定の優先順位の例や詳細は、「:ref:`general_precedence_rules`」を参照してください。" 10372 10373#: ../../rst/user_guide/playbooks_variables.rst:306 10374msgid "Understanding variable precedence" 10375msgstr "変数の優先順位について" 10376 10377#: ../../rst/user_guide/playbooks_variables.rst:308 10378msgid "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):" 10379msgstr "Ansible では変数の優先順位を適用しており、それを利用できる場合があります。ここでは、優先順位の低いものから高いものまでを紹介します (最後に挙げた変数が他のすべての変数を上書きします)。" 10380 10381#: ../../rst/user_guide/playbooks_variables.rst:310 10382msgid "command line values (for example, ``-u my_user``, these are not variables)" 10383msgstr "コマンドラインの値 (例: ``-u my_user`` (これらは変数ではありません))" 10384 10385#: ../../rst/user_guide/playbooks_variables.rst:311 10386msgid "role defaults (defined in role/defaults/main.yml) [1]_" 10387msgstr "ロールのデフォルト(role/defaults/main.yml で定義) [1]_" 10388 10389#: ../../rst/user_guide/playbooks_variables.rst:312 10390msgid "inventory file or script group vars [2]_" 10391msgstr "インベントリーファイルまたはスクリプトのグループ変数 [2]_" 10392 10393#: ../../rst/user_guide/playbooks_variables.rst:313 10394msgid "inventory group_vars/all [3]_" 10395msgstr "インベントリー group_vars/all [3]_" 10396 10397#: ../../rst/user_guide/playbooks_variables.rst:314 10398msgid "playbook group_vars/all [3]_" 10399msgstr "playbook group_vars/all [3]_" 10400 10401#: ../../rst/user_guide/playbooks_variables.rst:315 10402msgid "inventory group_vars/* [3]_" 10403msgstr "インベントリー group_vars/* [3]_" 10404 10405#: ../../rst/user_guide/playbooks_variables.rst:316 10406msgid "playbook group_vars/* [3]_" 10407msgstr "playbook group_vars/* [3]_" 10408 10409#: ../../rst/user_guide/playbooks_variables.rst:317 10410msgid "inventory file or script host vars [2]_" 10411msgstr "インベントリーファイルまたはスクリプトホスト変数 [2]_" 10412 10413#: ../../rst/user_guide/playbooks_variables.rst:318 10414msgid "inventory host_vars/* [3]_" 10415msgstr "インベントリー host_vars/* [3]_" 10416 10417#: ../../rst/user_guide/playbooks_variables.rst:319 10418msgid "playbook host_vars/* [3]_" 10419msgstr "playbook host_vars/* [3]_" 10420 10421#: ../../rst/user_guide/playbooks_variables.rst:320 10422msgid "host facts / cached set_facts [4]_" 10423msgstr "ホストファクト / キャッシュ済み set_facts [4]_" 10424 10425#: ../../rst/user_guide/playbooks_variables.rst:321 10426msgid "play vars" 10427msgstr "プレイ変数" 10428 10429#: ../../rst/user_guide/playbooks_variables.rst:322 10430msgid "play vars_prompt" 10431msgstr "play vars_prompt" 10432 10433#: ../../rst/user_guide/playbooks_variables.rst:323 10434msgid "play vars_files" 10435msgstr "play vars_files" 10436 10437#: ../../rst/user_guide/playbooks_variables.rst:324 10438msgid "role vars (defined in role/vars/main.yml)" 10439msgstr "role 変数 (role/vars/main.yml で定義)" 10440 10441#: ../../rst/user_guide/playbooks_variables.rst:325 10442msgid "block vars (only for tasks in block)" 10443msgstr "ブロック変数 (ブロックのタスクにのみ適用)" 10444 10445#: ../../rst/user_guide/playbooks_variables.rst:326 10446msgid "task vars (only for the task)" 10447msgstr "タスク変数 (タスク専用)" 10448 10449#: ../../rst/user_guide/playbooks_variables.rst:327 10450#: ../../rst/user_guide/windows_faq.rst:166 10451msgid "include_vars" 10452msgstr "include_vars" 10453 10454#: ../../rst/user_guide/playbooks_variables.rst:328 10455msgid "set_facts / registered vars" 10456msgstr "set_facts / 登録変数" 10457 10458#: ../../rst/user_guide/playbooks_variables.rst:329 10459msgid "role (and include_role) params" 10460msgstr "role (および include_role) パラメーター" 10461 10462#: ../../rst/user_guide/playbooks_variables.rst:330 10463msgid "include params" 10464msgstr "include パラメーター" 10465 10466#: ../../rst/user_guide/playbooks_variables.rst:331 10467msgid "extra vars (for example, ``-e \"user=my_user\"``)(always win precedence)" 10468msgstr "追加の変数 (例: ``-e \"user=my_user\"``)(常に優先されます)" 10469 10470#: ../../rst/user_guide/playbooks_variables.rst:333 10471msgid "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." 10472msgstr "一般的に、Ansible は、より新しく、より積極的に、より明確なスコープで定義された変数を優先します。ロール内の defaults フォルダーにある変数は簡単に上書きされます。ロールの vars ディレクトリーにあるものは、名前空間内のその変数の以前のバージョンを上書きします。ホストおよび/またはインベントリー変数はロールのデフォルトを上書きしますが、vars ディレクトリーや ``include_vars`` タスクなどの明示的なインクルードはインベントリー変数を上書きします。" 10473 10474#: ../../rst/user_guide/playbooks_variables.rst:335 10475msgid "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`." 10476msgstr "Ansible は、インベントリーに設定した異なる変数をマージして、より特定の設定がより一般的な設定を上書きするようにします。たとえば、group_var として指定した ``ansible_ssh_user`` は、host_var として指定した ``ansible_user`` により上書きされます。インベントリーで設定された変数の優先順位の詳細については、「:ref:`how_we_merge`」を参照してください。" 10477 10478#: ../../rst/user_guide/playbooks_variables.rst:338 10479msgid "Footnotes" 10480msgstr "注記" 10481 10482#: ../../rst/user_guide/playbooks_variables.rst:339 10483msgid "Tasks in each role see their own role's defaults. Tasks defined outside of a role see the last role's defaults." 10484msgstr "各ロールのタスクには、それぞれのロールのデフォルト値が表示されます。ロールの外で定義されたタスクには、最後のロールのデフォルトが表示されます。" 10485 10486#: ../../rst/user_guide/playbooks_variables.rst:340 10487msgid "Variables defined in inventory file or provided by dynamic inventory." 10488msgstr "インベントリーファイルで定義される変数、または動的インベントリーで指定される変数。" 10489 10490#: ../../rst/user_guide/playbooks_variables.rst:341 10491msgid "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." 10492msgstr "「vars プラグイン」と、Ansible に同梱されるデフォルトの vars プラグインにより追加される host_vars および group_vars が含まれるインクルード変数。" 10493 10494#: ../../rst/user_guide/playbooks_variables.rst:342 10495msgid "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." 10496msgstr "set_facts のキャッシュ可能なオプションを使用して作成すると、変数がプレイに優先されますが、キャッシュからのホストのファクトと同様に優先されます。" 10497 10498#: ../../rst/user_guide/playbooks_variables.rst:345 10499msgid "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." 10500msgstr "どのセクションでも、変数を再定義すると前のインスタンスが上書きされます。複数のグループが同じ変数を持っている場合は、最後に読み込まれたものが優先されます。プレイ中の ``vars:`` のセクションで変数を 2 回定義した場合は、2 回目の変数が優先されます。" 10501 10502#: ../../rst/user_guide/playbooks_variables.rst:348 10503msgid "The previous describes the default config ``hash_behaviour=replace``, switch to ``merge`` to only partially overwrite." 10504msgstr "以前は、デフォルトの設定 ``hash_behaviour=replace`` を説明し、``merge`` に切り替えてを部分的に上書きします。" 10505 10506#: ../../rst/user_guide/playbooks_variables.rst:353 10507msgid "Scoping variables" 10508msgstr "変数のスコープ設定" 10509 10510#: ../../rst/user_guide/playbooks_variables.rst:355 10511msgid "You can decide where to set a variable based on the scope you want that value to have. Ansible has three main scopes:" 10512msgstr "変数をどこに設定するかは、その値が持つべきスコープに基づいて決めることができます。Ansible には大きく分けて 3 つのスコープがあります。" 10513 10514#: ../../rst/user_guide/playbooks_variables.rst:357 10515msgid "Global: this is set by config, environment variables and the command line" 10516msgstr "グローバル: これは、設定、環境変数、およびコマンドラインで設定されます。" 10517 10518#: ../../rst/user_guide/playbooks_variables.rst:358 10519msgid "Play: each play and contained structures, vars entries (vars; vars_files; vars_prompt), role defaults and vars." 10520msgstr "プレイ: 各プレイおよび含まれる構造、変数エントリー (vars、vars_files、vars_prompt)、ロールのデフォルトおよび変数。" 10521 10522#: ../../rst/user_guide/playbooks_variables.rst:359 10523msgid "Host: variables directly associated to a host, like inventory, include_vars, facts or registered task outputs" 10524msgstr "ホスト: インベントリー、include_vars、ファクト、または登録されたタスクの出力などのホストに直接関連付けられる変数" 10525 10526#: ../../rst/user_guide/playbooks_variables.rst:361 10527msgid "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." 10528msgstr "テンプレート内では、ホストのスコープ内にあるすべての変数と、登録済みの変数、ファクト、およびマジック変数に自動的にアクセスできます。" 10529 10530#: ../../rst/user_guide/playbooks_variables.rst:366 10531msgid "Tips on where to set variables" 10532msgstr "変数を設定する場所に関するヒント" 10533 10534#: ../../rst/user_guide/playbooks_variables.rst:368 10535msgid "You should choose where to define a variable based on the kind of control you might want over values." 10536msgstr "変数を定義する場所は、値をどのように制御するかによって選択する必要があります。" 10537 10538#: ../../rst/user_guide/playbooks_variables.rst:370 10539msgid "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." 10540msgstr "地理や動作を扱うインベントリーに変数を設定します。グループは、ホストにロールをマッピングするエンティティーであることが多いため、ロールに変数を定義する代わりに、グループに変数を設定することができます。子グループが親グループを上書きし、ホスト変数がグループ変数を上書きすることを忘れないでください。ホスト変数とグループ変数の設定の詳細は、「:ref:`define_variables_in_inventory`」を参照してください。" 10541 10542#: ../../rst/user_guide/playbooks_variables.rst:372 10543msgid "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 :ref:`ansible_tower` from the UI or API::" 10544msgstr "``group_vars/all`` ファイルで共通のデフォルトを設定します。インベントリーでホスト変数とグループ変数を整理する方法の詳細については、「:ref:`splitting_out_vars`」を参照してください。グループ変数は通常、インベントリーファイルと一緒に置かれますが、動的インベントリー (:ref:`intro_dynamic_inventory` を参照) で返されたり、UI や API から :ref:`ansible_tower` で定義することもできます。" 10545 10546#: ../../rst/user_guide/playbooks_variables.rst:379 10547msgid "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``::" 10548msgstr "``group_vars/my_location`` ファイルにロケーション固有の変数を設定します。すべてのグループは ``all`` グループの子であるため、ここに設定される変数は ``group_vars/all`` で設定した変数を上書きします。" 10549 10550#: ../../rst/user_guide/playbooks_variables.rst:385 10551msgid "If one host used a different NTP server, you could set that in a host_vars file, which would override the group variable::" 10552msgstr "1 つのホストが別の NTP サーバーを使用している場合は、host_vars ファイルにそのホストを設定できます。これにより、グループ変数が上書きされます。" 10553 10554#: ../../rst/user_guide/playbooks_variables.rst:391 10555msgid "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::" 10556msgstr "未定義な変数エラーを防ぐために、ロールにデフォルト値を設定します。ロールを共有している場合、他のユーザーは、``roles/x/defaults/main.yml`` ファイルで追加した妥当なデフォルト値を信頼するか、インベントリーやコマンドラインで簡単にその値を上書きすることができます。詳細は、「:ref:`playbooks_reuse_roles`」を参照してください。以下に例を示します。" 10557 10558#: ../../rst/user_guide/playbooks_variables.rst:398 10559msgid "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``::" 10560msgstr "ロールに変数を設定することで、値がそのロールで使用され、インベントリー変数で上書きされないようにします。ロールを他の人と共有していない場合は、ポートなどのアプリ固有の動作を、このように ``roles/x/vars/main.yml`` で定義できます。他の人とロールを共有している場合は、ここに変数を置くことで上書きされにくくなります。ただし、ロールにパラメーターを渡したり、``-e`` で変数を設定したりすれば、上書きされる可能性はあります。" 10561 10562#: ../../rst/user_guide/playbooks_variables.rst:405 10563msgid "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::" 10564msgstr "明確さ、柔軟性、および可視性を最大化するためにロールを呼び出す場合は、パラメーターとして変数を渡します。この方法では、ロールに存在するデフォルトを上書きします。以下に例を示します。" 10565 10566#: ../../rst/user_guide/playbooks_variables.rst:412 10567msgid "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::" 10568msgstr "この Playbook を読むと、変数の設定やデフォルトの上書きを選択したことがわかります。また、複数の値を渡すことができるため、同じロールを複数回実行することができます。詳細は「:ref:`run_role_twice`」を参照してください。以下に例を示します。" 10569 10570#: ../../rst/user_guide/playbooks_variables.rst:428 10571msgid "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::" 10572msgstr "1 つのロールに設定された変数は、後のロールで使用できます。変数は、``roles/common_settings/vars/main.yml`` ファイルに設定して、他のロールや Playbook の他の場所で使用します。" 10573 10574#: ../../rst/user_guide/playbooks_variables.rst:437 10575msgid "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." 10576msgstr "変数の名前空間化の必要性を回避するために、いくつかの保護機能があります。この例では、「common_settings」で定義された変数は「something」と「something_else」のタスクで使用できますが、「common_settings」で foo が 20 に設定されていても、「something」のタスクでは foo が 12 に設定されています。" 10577 10578#: ../../rst/user_guide/playbooks_variables.rst:440 10579msgid "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." 10580msgstr "変数の優先順位を気にするのではなく、変数をどこに設定するかを決める際には、どれだけ簡単に、あるいはどれだけ頻繁に変数を上書きしたいかを考えることが推奨されます。他の変数がどのように定義されているかわからず、特定の値が必要な場合は、``--extra-vars`` (``-e``) を使用して、他のすべての変数を上書きします。" 10581 10582#: ../../rst/user_guide/playbooks_variables.rst:443 10583msgid "Using advanced variable syntax" 10584msgstr "高度な変数構文の使用" 10585 10586#: ../../rst/user_guide/playbooks_variables.rst:445 10587msgid "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`." 10588msgstr "変数を宣言するのに使用される高度な YAML 構文、および Ansible により使用される YAML ファイルにあるデータに対する制御の詳細は、「:ref:`playbooks_advanced_syntax`」を参照してください。" 10589 10590#: ../../rst/user_guide/playbooks_variables.rst:454 10591msgid "Jinja2 filters and their uses" 10592msgstr "Jinja2 フィルターおよびその使用" 10593 10594#: ../../rst/user_guide/playbooks_variables.rst:461 10595msgid ":ref:`special_variables`" 10596msgstr ":ref:`special_variables`" 10597 10598#: ../../rst/user_guide/playbooks_variables.rst:462 10599msgid "List of special variables" 10600msgstr "特殊な変数のリスト" 10601 10602#: ../../rst/user_guide/playbooks_vars_facts.rst:5 10603msgid "Discovering variables: facts and magic variables" 10604msgstr "変数の検出: ファクトおよびマジック変数" 10605 10606#: ../../rst/user_guide/playbooks_vars_facts.rst:7 10607msgid "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." 10608msgstr "Ansible では、リモートシステムや Ansible 自体に関する情報を含む特定の変数を取得または検出を行うことができます。リモートシステムに関連する変数をファクトと呼びます。ファクトを使用すると、あるシステムの動作や状態を他のシステムの設定値として使用することができます。たとえば、あるシステムの IP アドレスを、他のシステムの設定値として使用することができます。Ansible に関連する変数をマジック変数と呼びます。" 10609 10610#: ../../rst/user_guide/playbooks_vars_facts.rst:13 10611msgid "Ansible facts" 10612msgstr "Ansible ファクト" 10613 10614#: ../../rst/user_guide/playbooks_vars_facts.rst:15 10615msgid "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::" 10616msgstr "Ansible のファクトは、オペレーティングシステム、IP アドレス、添付のファイルシステムなど、リモートシステムに関連するデータです。このデータには、``ansible_facts`` という変数でアクセスできます。デフォルトでは、一部の Ansible ファクトは、``ansible_`` というプレフィックスを持つトップレベルの変数としてアクセスすることもできます。この動作は、:ref:`INJECT_FACTS_AS_VARS` の設定で無効にすることができます。利用可能なすべてのファクトを表示するには、このタスクをプレイに追加します。" 10617 10618#: ../../rst/user_guide/playbooks_vars_facts.rst:21 10619msgid "To see the 'raw' information as gathered, run this command at the command line::" 10620msgstr "収集された「生」の情報を見るには、コマンドラインで次のコマンドを実行します。" 10621 10622#: ../../rst/user_guide/playbooks_vars_facts.rst:25 10623msgid "Facts include a large amount of variable data, which may look like this:" 10624msgstr "ファクトには大量の変数データが含まれており、それは次のようなものです。" 10625 10626#: ../../rst/user_guide/playbooks_vars_facts.rst:486 10627msgid "You can reference the model of the first disk in the facts shown above in a template or playbook as::" 10628msgstr "上記のファクトの最初のディスクのモデルをテンプレートまたは Playbook で参照できます。" 10629 10630#: ../../rst/user_guide/playbooks_vars_facts.rst:490 10631msgid "To reference the system hostname::" 10632msgstr "システムのホスト名を参照するには、以下を実行します。" 10633 10634#: ../../rst/user_guide/playbooks_vars_facts.rst:494 10635msgid "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." 10636msgstr "ファクトは、条件式 (:ref:`playbooks_conditionals` を参照) やテンプレートでも使用できます。また、ファクトを使用して、特定の条件に一致するホストの動的なグループを作成することもできます。詳細は、:ref:`group_by モジュール <group_by_module>` のドキュメントを参照してください。" 10637 10638#: ../../rst/user_guide/playbooks_vars_facts.rst:499 10639msgid "Package requirements for fact gathering" 10640msgstr "ファクト収集のパッケージ要件" 10641 10642#: ../../rst/user_guide/playbooks_vars_facts.rst:501 10643msgid "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:" 10644msgstr "一部のディストリビューションでは、ファクトの収集をサポートするパッケージがデフォルトでインストールされていないため、ファクトの値が見つからなかったり、ファクトがデフォルト値に設定されたりすることがあります。OS のパッケージマネージャーを使用して、リモートホストに必要なパッケージをインストールすることができます。既知の依存関係には以下のものがあります。" 10645 10646#: ../../rst/user_guide/playbooks_vars_facts.rst:503 10647msgid "Linux Network fact gathering - Depends on the ``ip`` binary, commonly included in the ``iproute2`` package." 10648msgstr "Linux ネットワークファクト収集 - 一般的に ``iproute2`` パッケージに含まれる ``ip`` バイナリーによって異なります。" 10649 10650#: ../../rst/user_guide/playbooks_vars_facts.rst:508 10651msgid "Caching facts" 10652msgstr "ファクトのキャッシュ" 10653 10654#: ../../rst/user_guide/playbooks_vars_facts.rst:510 10655msgid "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::" 10656msgstr "登録された変数と同様に、ファクトはデフォルトでメモリーに保存されます。ただし、登録された変数とは異なり、ファクトは独立して収集し、繰り返し使用するためにキャッシュすることができます。キャッシュされたファクトを使用すると、Ansible が 2 つ目のシステムで現在のプレイを最初に実行した場合でも、1 つのシステムのファクトを参照して 2 つ目のシステムを設定することができます。以下に例を示します。" 10657 10658#: ../../rst/user_guide/playbooks_vars_facts.rst:514 10659msgid "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." 10660msgstr "キャッシュ処理は、キャッシュプラグインによって制御されます。デフォルトでは、Ansible はメモリーキャッシュプラグインを使用し、現在の Playbook の実行期間中、メモリーにファクトを保存します。Ansible のファクトを繰り返し使用するために保持するには、別のキャッシュプラグインを選択します。詳細は「:ref:`cache_plugins`」を参照してください。" 10661 10662#: ../../rst/user_guide/playbooks_vars_facts.rst:516 10663msgid "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." 10664msgstr "ファクトキャッシュ処理はパフォーマンスを向上させます。何千台ものホストを管理している場合は、ファクトキャッシュ処理を毎晩実行するように設定し、小規模なサーバ群の設定を 1 日中定期的に管理することができます。キャッシュされたファクトがあれば、少数のサーバーしか管理していなくても、すべてのホストに関する変数および情報にアクセスすることができます。" 10665 10666#: ../../rst/user_guide/playbooks_vars_facts.rst:521 10667msgid "Disabling facts" 10668msgstr "ファクトの無効化" 10669 10670#: ../../rst/user_guide/playbooks_vars_facts.rst:523 10671msgid "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::" 10672msgstr "デフォルトでは、Ansible は各プレイの開始時にファクトを収集します。ファクトを収集する必要がない場合 (たとえば、システムに関する情報をすべて一元的に把握している場合) は、プレイレベルでのファクト収集をオフにすることで、スケーラビリティーを向上させることができます。ファクトを無効にすると、非常に多数のシステムを使用するプッシュモードや、実験的なプラットフォームで Ansible を使用している場合に、特にパフォーマンスが向上することがあります。ファクトの収集を無効にするには、以下を行います。" 10673 10674#: ../../rst/user_guide/playbooks_vars_facts.rst:529 10675msgid "Adding custom facts" 10676msgstr "カスタムファクトの追加" 10677 10678#: ../../rst/user_guide/playbooks_vars_facts.rst:531 10679msgid "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." 10680msgstr "Ansible のセットアップモジュールは、各ホストに関する標準的なファクトのセットを自動的に検出します。ファクトにカスタム値を追加したい場合は、カスタムファクトモジュールを記述したり、``ansible.builtin.set_fact`` タスクで一時的なファクトを設定したり、facts.d ディレクトリーを使用して恒久的なカスタムファクトを提供したりすることができます。" 10681 10682#: ../../rst/user_guide/playbooks_vars_facts.rst:536 10683msgid "facts.d or local facts" 10684msgstr "facts.d またはローカルファクト" 10685 10686#: ../../rst/user_guide/playbooks_vars_facts.rst:540 10687msgid "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." 10688msgstr "静的なカスタムファクトは、静的ファイルを facts.d に追加することで追加でき、動的なファクトは実行可能なスクリプトを facts.d に追加することで追加できます。たとえば、facts.d でスクリプトを作成して実行することにより、ホスト上のすべてのユーザーのリストをファクトに追加できます。" 10689 10690#: ../../rst/user_guide/playbooks_vars_facts.rst:542 10691msgid "To use facts.d, create an ``/usr/local/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." 10692msgstr "facts.d を使用するには、リモートホストまたはホスト上に ``/usr/local/etc/ansible/facts.d`` ディレクトリーを作成します。別のディレクトリーを使用する場合は、そのディレクトリーを作成し、プレイキーワード ``fact_path`` を使用して指定します。このディレクトリーにファイルを追加して、カスタムファクトを提供します。すべてのファイル名は、``.fact`` で終わる必要があります。ファイルには、JSON、INI、または JSON を返す実行可能ファイルを使用できます。" 10693 10694#: ../../rst/user_guide/playbooks_vars_facts.rst:544 10695msgid "To add static facts, simply add a file with the ``.fact`` extension. For example, create ``/usr/local/etc/ansible/facts.d/preferences.fact`` with this content::" 10696msgstr "静的ファクトを追加するには、``.fact`` 拡張子を持つファイルを追加するだけです。たとえば、以下の内容で ``/usr/local/etc/ansible/facts.d/preferences.fact`` を作成します。" 10697 10698#: ../../rst/user_guide/playbooks_vars_facts.rst:550 10699msgid "Make sure the file is not executable as this will break the ``ansible.builtin.setup`` module." 10700msgstr "``ansible.builtin.setup`` モジュールが壊れるため、このファイルが実行ファイルではないことを確認してください。" 10701 10702#: ../../rst/user_guide/playbooks_vars_facts.rst:552 10703msgid "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::" 10704msgstr "次回、ファクト収集が実行されると、ファクトには、``asdf`` と``bar`` をメンバーとする ``general`` という名前のハッシュ変数ファクトが含まれるようになります。これを検証するには、次のように実行します。" 10705 10706#: ../../rst/user_guide/playbooks_vars_facts.rst:556 10707msgid "And you will see your custom fact added::" 10708msgstr "これにより、カスタムファクトが追加されているのが確認できます。" 10709 10710#: ../../rst/user_guide/playbooks_vars_facts.rst:567 10711msgid "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::" 10712msgstr "ansible_local 名前空間は、facts.d で作成されたカスタムファクトと、システムファクトや Playbook 内の他の場所で定義された変数を分離し、変数が互いに上書きされないようにします。このカスタムファクトには、テンプレートや Playbook で次のようにアクセスできます。" 10713 10714#: ../../rst/user_guide/playbooks_vars_facts.rst:571 10715msgid "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." 10716msgstr "鍵と値のペアの鍵の部分は、ansible_local 変数内で小文字に変換されます。上記の例では、ini ファイルの ``[general]`` セクションに``XYZ=3`` が含まれていた場合は、``{{ ansible_local['preferences']['general']['XYZ'] }}`` ではなく、``{{ ansible_local['preferences']['general']['xyz'] }}`` としてアクセスすることになります。これは、Ansible が Python の`ConfigParser`_ を使用して、すべてのオプション名を `optionxform`_ メソッドに渡しており、このメソッドのデフォルトの実装では、オプション名が小文字に変換されるためです。" 10717 10718#: ../../rst/user_guide/playbooks_vars_facts.rst:576 10719msgid "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:" 10720msgstr "facts.d を使用して、リモートホスト上でスクリプトを実行し、ansible_local 名前空間に動的なカスタムファクトを生成することもできます。たとえば、リモートホストに存在するすべてのユーザーのリストを、そのホストに関するファクトとして生成することができます。facts.d を使用して動的なカスタムファクトを生成するには、以下の手順に従います。" 10721 10722#: ../../rst/user_guide/playbooks_vars_facts.rst:578 10723msgid "Write and test a script to generate the JSON data you want." 10724msgstr "スクリプトを作成してテストして、必要な JSON データを生成します。" 10725 10726#: ../../rst/user_guide/playbooks_vars_facts.rst:579 10727msgid "Save the script in your facts.d directory." 10728msgstr "スクリプトを facts.d ディレクトリーに保存します。" 10729 10730#: ../../rst/user_guide/playbooks_vars_facts.rst:580 10731msgid "Make sure your script has the ``.fact`` file extension." 10732msgstr "スクリプトに ``.fact`` ファイル拡張子があることを確認します。" 10733 10734#: ../../rst/user_guide/playbooks_vars_facts.rst:581 10735msgid "Make sure your script is executable by the Ansible connection user." 10736msgstr "スクリプトが Ansible 接続ユーザーによって実行可能であることを確認します。" 10737 10738#: ../../rst/user_guide/playbooks_vars_facts.rst:582 10739msgid "Gather facts to execute the script and add the JSON output to ansible_local." 10740msgstr "スクリプトを実行するファクトを収集し、JSON 出力を ansible_local に追加します。" 10741 10742#: ../../rst/user_guide/playbooks_vars_facts.rst:584 10743msgid "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::" 10744msgstr "デフォルトでは、ファクトの収集は各プレイの開始時に一度だけ実行します。Playbook で facts.d を使用してカスタムファクトを作成すると、ファクトを収集する次のプレイで使用できるようになります。作成したのと同じプレイで使用したい場合は、セットアップモジュールを明示的に再実行する必要があります。以下に例を示します。" 10745 10746#: ../../rst/user_guide/playbooks_vars_facts.rst:604 10747msgid "If you use this pattern frequently, a custom facts module would be more efficient than facts.d." 10748msgstr "このパターンを頻繁に使用すると、カスタムファクトモジュールは facts.d よりも効率が上がります。" 10749 10750#: ../../rst/user_guide/playbooks_vars_facts.rst:609 10751msgid "Information about Ansible: magic variables" 10752msgstr "Ansible に関する情報: マジック変数" 10753 10754#: ../../rst/user_guide/playbooks_vars_facts.rst:611 10755msgid "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." 10756msgstr "使用している Python のバージョン、インベントリー内のホストやグループ、Playbook やロールのディレクトリーなど、Ansible の操作に関する情報は、「マジック」変数を使用してアクセスすることができます。接続変数と同様に、マジック変数は :ref:`special_variables` です。マジック変数の名前は予約済みです。これらの名前で変数を設定しないでください。変数 ``environment`` も予約済みです。" 10757 10758#: ../../rst/user_guide/playbooks_vars_facts.rst:613 10759msgid "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." 10760msgstr "最も一般的に使用されるマジック変数は、``hostvars``、``groups``、``group_names``、および ``inventory_hostname`` です。``hostvars`` を使用すると、Playbook 内の任意の時点で、プレイ内の任意のホストに対して定義された変数にアクセスできます。``hostvars`` 変数を使用して Ansible のファクトにアクセスすることもできますが、ファクトを収集 (またはキャッシュ) した後でなければなりません。" 10761 10762#: ../../rst/user_guide/playbooks_vars_facts.rst:615 10763msgid "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::" 10764msgstr "他のノードの「ファクト」の値や、他のノードに割り当てられたインベントリー変数の値を使用してデータベースサーバーを設定する場合は、テンプレートやアクション行で ``hostvars`` を使用することができます。" 10765 10766#: ../../rst/user_guide/playbooks_vars_facts.rst:619 10767msgid "With ``groups``, a list of all the groups (and hosts) in the inventory, you can enumerate all hosts within a group. For example:" 10768msgstr "``groups`` では、インベントリー内のすべてのグループ (およびホスト) のリストで、グループ内のすべてのホストを列挙できます。以下に例を示します。" 10769 10770#: ../../rst/user_guide/playbooks_vars_facts.rst:627 10771msgid "You can use ``groups`` and ``hostvars`` together to find all the IP addresses in a group." 10772msgstr "``groups`` と ``hostvars`` を一緒に使用して、グループ内のすべての IP アドレスを探すことができます。" 10773 10774#: ../../rst/user_guide/playbooks_vars_facts.rst:635 10775msgid "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." 10776msgstr "この方法を使用して、フロントエンドプロキシーサーバーがアプリサーバーグループ内のすべてのホストを指すようにしたり、サーバー間に正しいファイアウォールルールを設定したりできます。テンプレートに入力するタスクの前に、ファクトをキャッシュするか、それらのホストのファクトを収集する必要があります。" 10777 10778#: ../../rst/user_guide/playbooks_vars_facts.rst:637 10779msgid "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:" 10780msgstr "``group_names`` では、現在のホストが置かれているすべてのグループのリスト (配列) は、ホストのグループメンバーシップ (またはロール) に基づいて異なるテンプレートファイルを作成できます。" 10781 10782#: ../../rst/user_guide/playbooks_vars_facts.rst:645 10783msgid "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." 10784msgstr "ファクト収集が無効になっているときには、``ansible_hostname`` の代わりに、インベントリーで設定されたホストの名前であるマジック変数 ``inventory_hostname`` を使用できます。長い FQDN がある場合には、最初のピリオドまでの部分を含み、ドメインの残りの部分を含まない ``inventory_hostname_short`` を使用することができます。" 10785 10786#: ../../rst/user_guide/playbooks_vars_facts.rst:647 10787msgid "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." 10788msgstr "その他の有用なマジック変数は、現在のプレイや Playbook を参照します。これらの変数は、複数のホスト名でテンプレートを埋めるときや、ロードバランサーのルールにリストを注入するときに便利です。" 10789 10790#: ../../rst/user_guide/playbooks_vars_facts.rst:649 10791msgid "``ansible_play_hosts`` is the list of all hosts still active in the current play." 10792msgstr "``ansible_play_hosts`` は、現在のプレイでアクティブなままになっているすべてのホストの完全なリストです。" 10793 10794#: ../../rst/user_guide/playbooks_vars_facts.rst:651 10795msgid "``ansible_play_batch`` is a list of hostnames that are in scope for the current 'batch' of the play." 10796msgstr "``ansible_play_batch`` は、現在のプレイの「バッチ」の範囲内にあるホスト名のリストです。" 10797 10798#: ../../rst/user_guide/playbooks_vars_facts.rst:653 10799msgid "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``)." 10800msgstr "バッチサイズは ``serial`` で定義されます。設定されていない場合は、プレイ全体に相当するようになります (``ansible_play_hosts`` と同じになります)。" 10801 10802#: ../../rst/user_guide/playbooks_vars_facts.rst:655 10803msgid "``ansible_playbook_python`` is the path to the python executable used to invoke the Ansible command line tool." 10804msgstr "``ansible_playbook_python`` は、Ansible コマンドラインツールを起動するのに使用される Python 実行ファイルへのパスです。" 10805 10806#: ../../rst/user_guide/playbooks_vars_facts.rst:657 10807msgid "``inventory_dir`` is the pathname of the directory holding Ansible's inventory host file." 10808msgstr "``inventory_dir`` は、Ansible のインベントリーホストファイルを保持するディレクトリーのパス名です。" 10809 10810#: ../../rst/user_guide/playbooks_vars_facts.rst:659 10811msgid "``inventory_file`` is the pathname and the filename pointing to the Ansible's inventory host file." 10812msgstr "``inventory_file`` は、Ansible のインベントリーホストファイルを参照するパス名とファイル名です。" 10813 10814#: ../../rst/user_guide/playbooks_vars_facts.rst:661 10815msgid "``playbook_dir`` contains the playbook base directory." 10816msgstr "``playbook_dir`` には Playbook のベースディレクトリーが含まれます。" 10817 10818#: ../../rst/user_guide/playbooks_vars_facts.rst:663 10819msgid "``role_path`` contains the current role's pathname and only works inside a role." 10820msgstr "``role_path`` には現在のロールのパス名が含まれ、ロール内でのみ動作します。" 10821 10822#: ../../rst/user_guide/playbooks_vars_facts.rst:665 10823msgid "``ansible_check_mode`` is a boolean, set to ``True`` if you run Ansible with ``--check``." 10824msgstr "``ansible_check_mode`` が ``--check`` で Ansible を実行する場合は ``True`` に設定します。" 10825 10826#: ../../rst/user_guide/playbooks_vars_facts.rst:670 10827msgid "Ansible version" 10828msgstr "Ansible version" 10829 10830#: ../../rst/user_guide/playbooks_vars_facts.rst:674 10831msgid "To adapt playbook behavior to different versions of Ansible, you can use the variable ``ansible_version``, which has the following structure::" 10832msgstr "Playbook の動作をさまざまなバージョンの Ansible に適用するには、``ansible_version`` 変数を使用できます。この変数には、以下の構造があります。" 10833 10834#: ../../rst/user_guide/playbooks_vault.rst:4 10835msgid "Using vault in playbooks" 10836msgstr "Playbook での Vault の使用" 10837 10838#: ../../rst/user_guide/playbooks_vault.rst:6 10839msgid "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." 10840msgstr "Ansible Vault に関するドキュメントが移動しました。新しい場所は「:ref:`vault`」です。このページに直接作成した可能性のあるリンクを更新してください。" 10841 10842#: ../../rst/user_guide/plugin_filtering_config.rst:4 10843msgid "Rejecting modules" 10844msgstr "モジュールの拒否" 10845 10846#: ../../rst/user_guide/plugin_filtering_config.rst:6 10847msgid "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:`/usr/local/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:" 10848msgstr "特定のモジュールの使用を回避したい場合は、そのモジュールを拒否リストに追加して、Ansible がそのモジュールを読み込まないようにすることができます。プラグインを拒否するには、yaml 設定ファイルを作成します。このファイルのデフォルトの場所は :file:`/usr/local/etc/ansible/plugin_filters.yml` です。ansible.cfg の ``defaults`` セクションにある :ref:`PLUGIN_FILTERS_CFG` の設定を使用して、拒否リストの別のパスを選択できます。以下に拒否リストの例を示します。" 10849 10850#: ../../rst/user_guide/plugin_filtering_config.rst:18 10851msgid "The file contains two fields:" 10852msgstr "このファイルには、2 つのフィールドが含まれています。" 10853 10854#: ../../rst/user_guide/plugin_filtering_config.rst:20 10855msgid "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\"``" 10856msgstr "将来的に後方互換性を保ちながら形式を更新できるようにするファイルのバージョン。現在のバージョンは ``\"1.0\"`` 文字列とします。" 10857 10858#: ../../rst/user_guide/plugin_filtering_config.rst:22 10859msgid "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." 10860msgstr "拒否するモジュールのリスト。Ansible は、モジュールを検索してタスクを呼び出すときに、このリストのモジュールを読み込みません。" 10861 10862#: ../../rst/user_guide/plugin_filtering_config.rst:26 10863msgid "The ``stat`` module is required for Ansible to run. Do not add this module to your reject list." 10864msgstr "Ansible を実行するには、``stat`` モジュールが必要です。このモジュールを拒否リストに追加しないでください。" 10865 10866#: ../../rst/user_guide/quickstart.rst:4 10867msgid "Ansible Quickstart Guide" 10868msgstr "Ansible クイックスタートガイド" 10869 10870#: ../../rst/user_guide/quickstart.rst:6 10871msgid "We've recorded a short video that introduces Ansible." 10872msgstr "Ansible を紹介する短い動画を作成しました。" 10873 10874#: ../../rst/user_guide/quickstart.rst:8 10875msgid "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." 10876msgstr "`クイックスタートの動画 <https://www.ansible.com/resources/videos/quick-start-video>`_ は約 13 分で、Ansible が何をするのか、どのように使用するのかなど、Ansible を高レベルで紹介しています。また、Ansible のエコシステムにおける他の製品についてもご紹介します。" 10877 10878#: ../../rst/user_guide/quickstart.rst:11 10879msgid "Enjoy, and be sure to visit the rest of the documentation to learn more." 10880msgstr "動画をお楽しみください。より詳細な説明は、本ガイドをご覧ください。" 10881 10882#: ../../rst/user_guide/quickstart.rst:15 10883msgid "`A system administrators guide to getting started with Ansible <https://www.redhat.com/en/blog/system-administrators-guide-getting-started-ansible-fast>`_" 10884msgstr "`A system administrators guide to getting started with Ansible <https://www.redhat.com/en/blog/system-administrators-guide-getting-started-ansible-fast>`_" 10885 10886#: ../../rst/user_guide/quickstart.rst:16 10887msgid "A step by step introduction to Ansible" 10888msgstr "Ansible の概要 (ステップバイステップ)" 10889 10890#: ../../rst/user_guide/quickstart.rst:17 10891msgid "`Ansible Automation for SysAdmins <https://opensource.com/downloads/ansible-quickstart>`_" 10892msgstr "`Ansible Automation for SysAdmins <https://opensource.com/downloads/ansible-quickstart>`_" 10893 10894#: ../../rst/user_guide/quickstart.rst:18 10895msgid "A downloadable guide for getting started with Ansible" 10896msgstr "Ansible を使い始めるためのダウンロード可能なガイド" 10897 10898#: ../../rst/user_guide/quickstart.rst:19 10899msgid ":ref:`network_getting_started`" 10900msgstr ":ref:`network_getting_started`" 10901 10902#: ../../rst/user_guide/quickstart.rst:20 10903msgid "A guide for network engineers using Ansible for the first time" 10904msgstr "はじめて Ansible を使用するネットワークエンジニアのためのガイド" 10905 10906#: ../../rst/user_guide/sample_setup.rst:5 10907msgid "Sample Ansible setup" 10908msgstr "Ansible 設定の例" 10909 10910#: ../../rst/user_guide/sample_setup.rst:7 10911msgid "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!)." 10912msgstr "ここまで、Playbook、インベントリー、ロール、および変数について学んできました。このセクションでは、これらの要素をまとめて、Web サービスを自動化するためのセットアップのサンプルを紹介します。これらのパターンを示す Playbook の例は、`ansible-examples リポジトリー <https://github.com/ansible/ansible-examples>`_ を参照してください (注: 最新のリリースではすべての機能を使用していない場合がありますが、それでも優れた参考資料となります)。" 10913 10914#: ../../rst/user_guide/sample_setup.rst:9 10915msgid "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." 10916msgstr "サンプルの設定では、Playbook、ロール、インベントリー、変数ファイルを機能別に整理し、プレイやタスクのレベルでタグを付けて、より詳細にコントロールしています。これは強力で柔軟なアプローチですが、Ansible のコンテンツを整理する方法は他にもあります。Ansible の使用方法は、私たちのニーズでははなく、使用する人や組織のニーズに合わせる必要があります。したがって、このアプローチを自由に変更して、コンテンツを適切に整理してください。" 10917 10918#: ../../rst/user_guide/sample_setup.rst:15 10919msgid "Sample directory layout" 10920msgstr "ディレクトリーレイアウトの例" 10921 10922#: ../../rst/user_guide/sample_setup.rst:17 10923msgid "This layout organizes most tasks in roles, with a single inventory file for each environment and a few playbooks in the top-level directory::" 10924msgstr "このレイアウトでは、ほとんどのタスクがロールごとに整理されており、環境ごとに 1 つのインベントリーファイルを作成し、トップレベルのディレクトリーにいくつかの Playbook を置いています。" 10925 10926#: ../../rst/user_guide/sample_setup.rst:67 10927msgid "Alternative directory layout" 10928msgstr "代替ディレクトリーレイアウト" 10929 10930#: ../../rst/user_guide/sample_setup.rst:69 10931msgid "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::" 10932msgstr "また、``group_vars``/``host_vars`` を含む各インベントリーファイルを別のディレクトリーに置くこともできます。これは、``group_vars``/``host_vars`` が異なる環境であまり共通していない場合に特に有効です。レイアウトは以下のようになります。" 10933 10934#: ../../rst/user_guide/sample_setup.rst:104 10935msgid "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`." 10936msgstr "このレイアウトにより、大規模な環境にも柔軟に対応することができ、異なる環境間でインベントリー変数を完全に分離することができます。しかし、この方法では、ファイル数が多くなるため、メンテナンスが難しくなります。グループ変数とホスト変数の整理の詳細は、「:ref:`splitting_out_vars`」を参照してください。" 10937 10938#: ../../rst/user_guide/sample_setup.rst:109 10939msgid "Sample group and host variables" 10940msgstr "グループ変数およびホスト変数の例" 10941 10942#: ../../rst/user_guide/sample_setup.rst:111 10943msgid "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::" 10944msgstr "これらのグループ変数とホスト変数のサンプルファイルには、各マシンやマシングループに適用される変数の値が記録されています。たとえば、アトランタのデータセンターには独自の NTP サーバーがあるため、ntp.conf を設定する際には、それらを使用する必要があります。" 10945 10946#: ../../rst/user_guide/sample_setup.rst:118 10947msgid "Similarly, the webservers have some configuration that does not apply to the database servers::" 10948msgstr "同様に、Web サーバーには、データベースサーバーには適用されない以下のような設定があります。" 10949 10950#: ../../rst/user_guide/sample_setup.rst:125 10951msgid "Default values, or values that are universally true, belong in a file called group_vars/all::" 10952msgstr "デフォルト値または汎用的に true である値がある場合は、それらを group_vars/all というファイルに配置します。" 10953 10954#: ../../rst/user_guide/sample_setup.rst:132 10955msgid "If necessary, you can define specific hardware variance in systems in a host_vars file::" 10956msgstr "必要に応じて、システムの特定のハードウェアの差異を host_vars ファイルに定義することができます。" 10957 10958#: ../../rst/user_guide/sample_setup.rst:139 10959msgid "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." 10960msgstr "繰り返しになりますが、:ref:`dynamic inventory <dynamic_inventory>` を使用している場合、Ansible は多くの動的グループを自動的に作成します。つまり、「class:webserver」のようなタグは、「group_vars/ec2_tag_class_webserver」ファイルから変数を自動的に読み込むことになります。" 10961 10962#: ../../rst/user_guide/sample_setup.rst:144 10963msgid "Sample playbooks organized by function" 10964msgstr "関数別に整理された Playbook のサンプル" 10965 10966#: ../../rst/user_guide/sample_setup.rst:146 10967msgid "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::" 10968msgstr "この設定では、1 つの Playbook ですべてのインフラストラクチャーを定義することができます。Playbook site.yml は、Web サーバー用とデータベースサーバー用の 2 つの Playbook をインポートしています。" 10969 10970#: ../../rst/user_guide/sample_setup.rst:153 10971msgid "The webservers.yml file, also at the top level, maps the configuration of the webservers group to the roles related to the webservers group::" 10972msgstr "同じく最上位にある webservers.yml ファイルは、webservers グループの設定を、webservers グループに関連するロールにマッピングします。" 10973 10974#: ../../rst/user_guide/sample_setup.rst:162 10975msgid "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::" 10976msgstr "この設定により、site.yml を実行してインフラストラクチャー全体を設定したり、webservers.yml を実行してサブセットを設定したりすることができます。これは、Ansible の「--limit」パラメーターに似ていますが、もう少し明確になっています。" 10977 10978#: ../../rst/user_guide/sample_setup.rst:170 10979msgid "Sample task and handler files in a function-based role" 10980msgstr "関数ベースのロール内のタスクおよびハンドラーファイルのサンプル" 10981 10982#: ../../rst/user_guide/sample_setup.rst:172 10983msgid "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::" 10984msgstr "Ansible は、ロールのサブディレクトリーにある ``main.yml`` ファイルを読み込みます。このサンプルの ``tasks/main.yml`` ファイルは、NTP を設定するというシンプルなものですが、必要に応じてもっと多くのことができます。" 10985 10986#: ../../rst/user_guide/sample_setup.rst:198 10987msgid "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::" 10988msgstr "ハンドラーファイルの例を紹介します。レビューとして、ハンドラーは特定のタスクが変更を報告したときにのみ起動し、各プレイの最後に実行します。" 10989 10990#: ../../rst/user_guide/sample_setup.rst:208 10991msgid "See :ref:`playbooks_reuse_roles` for more information." 10992msgstr "詳細は、「:ref:`playbooks_reuse_roles`」を参照してください。" 10993 10994#: ../../rst/user_guide/sample_setup.rst:214 10995msgid "What the sample setup enables" 10996msgstr "設定例の有効化" 10997 10998#: ../../rst/user_guide/sample_setup.rst:216 10999msgid "The basic organizational structure described above enables a lot of different automation options. To reconfigure your entire infrastructure::" 11000msgstr "上記の基本的な組織構造により、多くの異なる自動化オプションが可能になります。インフラ全体を再構成するには、以下のようになります。" 11001 11002#: ../../rst/user_guide/sample_setup.rst:220 11003msgid "To reconfigure NTP on everything::" 11004msgstr "全面的に NTP を再設定するには、以下を実行します。" 11005 11006#: ../../rst/user_guide/sample_setup.rst:224 11007msgid "To reconfigure only the webservers::" 11008msgstr "Web サーバーのみを再設定するには、以下を実行します。" 11009 11010#: ../../rst/user_guide/sample_setup.rst:228 11011msgid "To reconfigure only the webservers in Boston::" 11012msgstr "Boston で Web サーバーのみを再設定するには、以下を実行します。" 11013 11014#: ../../rst/user_guide/sample_setup.rst:232 11015msgid "To reconfigure only the first 10 webservers in Boston, and then the next 10::" 11016msgstr "Boston で最初の 10 台のウェブサーバーだけを再設定し、次の10台は、以下のようにします。" 11017 11018#: ../../rst/user_guide/sample_setup.rst:237 11019msgid "The sample setup also supports basic ad hoc commands::" 11020msgstr "設定例では、基本的なアドホックコマンドもサポートします。" 11021 11022#: ../../rst/user_guide/sample_setup.rst:242 11023msgid "To discover what tasks would run or what hostnames would be affected by a particular Ansible command::" 11024msgstr "実行するタスクまたは特定の Ansible コマンドの影響を受けるホスト名を検出するには、以下を実行します。" 11025 11026#: ../../rst/user_guide/sample_setup.rst:253 11027msgid "Organizing for deployment or configuration" 11028msgstr "デプロイメントまたは設定の整理" 11029 11030#: ../../rst/user_guide/sample_setup.rst:255 11031msgid "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." 11032msgstr "このサンプルでは、典型的な構成トポロジーをモデル化しています。複数階層のデプロイメントを行う場合は、アプリケーションを展開するために階層間を行き来する Playbook が追加されることがあります。この場合、「site.yml」には「deploy_exampledotcom.yml」などの Playbook が追加されますが、一般的な概念は変わりません。Ansible では、デプロイと設定を同じツールで行うことができるため、グループを再利用したり、OS の設定をアプリのデプロイとは別の Playbook やロールにまとめたりすることが考えられます。" 11033 11034#: ../../rst/user_guide/sample_setup.rst:259 11035msgid "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." 11036msgstr "「Playbook」をスポーツに例えて考えてみましょう。すべてのインフラストラクチャーに対して使用する 1 セットのプレイと、時と場合に応じて使用する状況に応じたプレイがあります。" 11037 11038#: ../../rst/user_guide/sample_setup.rst:264 11039msgid "Using local Ansible modules" 11040msgstr "ローカル Ansible モジュールの使用" 11041 11042#: ../../rst/user_guide/sample_setup.rst:266 11043msgid "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." 11044msgstr "Playbook が YAML ファイルに相対する :file:`./library` ディレクトリーを持っている場合は、このディレクトリーを使用して、自動的に Ansible モジュールパスに含まれる Ansible モジュールを追加することができます。これは、Playbook に付随するモジュールをまとめておくのに最適な方法です。これは、このセクションの最初にあるディレクトリー構造の例で示されています。" 11045 11046#: ../../rst/user_guide/vault.rst:5 ../../rst/user_guide/vault.rst:120 11047msgid "Encrypting content with Ansible Vault" 11048msgstr "Ansible Vault を使用したコンテンツの暗号化" 11049 11050#: ../../rst/user_guide/vault.rst:7 11051msgid "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." 11052msgstr "Ansible Vault は変数やファイルを暗号化するため、パスワードや鍵などの機密コンテンツを Playbook やロールの中で平文のまま放置することなく保護することができます。Ansible Vault を使用するには、コンテンツを暗号化および復号化するための 1 つ以上のパスワードが必要です。シークレットマネージャーなどのサードパーティーツールに Vault のパスワードを保存している場合は、そのパスワードにアクセスするためのスクリプトが必要です。:ref:`ansible-vault` コマンドラインツールでパスワードを使用して、暗号化された変数の作成と表示、暗号化されたファイルの作成、既存のファイルの暗号化、またはファイルの編集、鍵の再設定、復号を行います。また、暗号化されたコンテンツをソースコントロール下に置き、より安全に共有することができます。" 11053 11054#: ../../rst/user_guide/vault.rst:10 11055msgid "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." 11056msgstr "Ansible Vault による暗号化は、「静止状態のデータ」のみを保護します。コンテンツが復号化された後 (「使用中のデータ」)、プレイやプラグインの作者は、秘密の漏洩を回避する責任があります。出力の隠蔽に関する詳細は「:ref:`no_log <keep_secret_data>`」を、Ansible Vault で使用するエディターのセキュリティーに関する考慮点は「:ref:`vault_securing_editor`」を参照してください。" 11057 11058#: ../../rst/user_guide/vault.rst:12 11059msgid "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." 11060msgstr "暗号化された変数やファイルは、暗号化に使用したパスワードを入力することで、アドホックコマンドや Playbook で使用することができます。``ansible.cfg`` ファイルを変更して、パスワードファイルの場所を指定したり、常にパスワードの入力を促すようにすることができます。" 11061 11062#: ../../rst/user_guide/vault.rst:18 11063msgid "Managing vault passwords" 11064msgstr "Vault パスワードの管理" 11065 11066#: ../../rst/user_guide/vault.rst:20 11067msgid "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:" 11068msgstr "暗号化されたコンテンツを管理するには、Vault のパスワードを管理するためのストラテジーを立てるとよいでしょう。Vault パスワードは任意の文字列です。Vault パスワードを作成するための特別なコマンドはありません。しかし、Vault 保管庫パスワードを管理する必要があります。Ansible Vault で変数やファイルを暗号化する際は、毎回パスワードを入力する必要があります。暗号化された変数やファイルをコマンドや Playbook で使用する際には、暗号化に使用したのと同じパスワードを提供する必要があります。Vault のパスワードを管理するためのストラテジーを立てるには、次の 2 つの質問から始めます。" 11069 11070#: ../../rst/user_guide/vault.rst:22 11071msgid "Do you want to encrypt all your content with the same password, or use different passwords for different needs?" 11072msgstr "同じパスワードですべてのコンテンツを暗号化する必要があるか、異なるニーズに合わせて異なるパスワードを使用しますか？" 11073 11074#: ../../rst/user_guide/vault.rst:23 11075msgid "Where do you want to store your password or passwords?" 11076msgstr "パスワードをどこに保存しますか。" 11077 11078#: ../../rst/user_guide/vault.rst:26 11079msgid "Choosing between a single password and multiple passwords" 11080msgstr "1 つのパスワードと複数のパスワードの選択" 11081 11082#: ../../rst/user_guide/vault.rst:28 11083msgid "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." 11084msgstr "少人数のチームや機密性の高い値が少ない場合は、Ansible Vault で暗号化するすべてのものに 1 つのパスワードを使用することができます。Vault のパスワードは、後述するようにファイルやシークレットマネージャーに安全に保管してください。" 11085 11086#: ../../rst/user_guide/vault.rst:30 11087msgid "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." 11088msgstr "チームの規模が大きかったり、機密性の高い値が多い場合は、複数のパスワードを使用することができます。たとえば、ユーザーやアクセスレベルごとに異なるパスワードを使用することができます。必要に応じて、暗号化されたファイルごと、ディレクトリーごと、あるいは環境ごとに異なるパスワードが必要になる場合があります。たとえば、開発環境用と実稼働環境用の 2 つの vars ファイルを含む Playbook を作成し、2 つの異なるパスワードで暗号化する場合などです。Playbook を実行する際には、Vault ID を使用して、対象となる環境に適した Vault パスワードを選択します。" 11089 11090#: ../../rst/user_guide/vault.rst:35 11091msgid "Managing multiple passwords with vault IDs" 11092msgstr "vault ID を使用した複数パスワードの管理" 11093 11094#: ../../rst/user_guide/vault.rst:37 11095msgid "If you use multiple vault passwords, you can differentiate one password from another with vault IDs. You use the vault ID in three ways:" 11096msgstr "複数の vault パスワードを使用する場合は、vault ID から別のパスワードを区別することができます。以下の 3 つの方法で vault ID を使用します。" 11097 11098#: ../../rst/user_guide/vault.rst:39 11099msgid "Pass it with :option:`--vault-id <ansible-playbook --vault-id>` to the :ref:`ansible-vault` command when you create encrypted content" 11100msgstr "暗号化されたコンテンツの作成時に、:option:`--vault-id <ansible-playbook --vault-id>` を :ref:`ansible-vault` コマンドに渡します。" 11101 11102#: ../../rst/user_guide/vault.rst:40 11103msgid "Include it wherever you store the password for that vault ID (see :ref:`storing_vault_passwords`)" 11104msgstr "その vault ID のパスワードを保存する場所を追加します (:ref:`storing_vault_passwords` を参照)。" 11105 11106#: ../../rst/user_guide/vault.rst:41 11107msgid "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" 11108msgstr "vault ID で暗号化されたコンテンツを使用する Playbook を実行する際に、これを :option:`--vault-id <ansible-playbook --vault-id>` で :ref:`ansible-playbook` コマンドに渡します。" 11109 11110#: ../../rst/user_guide/vault.rst:43 11111msgid "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::" 11112msgstr ":ref:`ansible-vault` コマンドのオプションとして Vault ID を渡すと、暗号化されたコンテンツにラベル (ヒントやニックネーム) が追加されます。このラベルは、どのパスワードを使用して暗号化したかを記録します。暗号化された変数やファイルは、ヘッダーに平文で Vault ID ラベルを含みます。Vault ID は暗号化されたコンテンツの前の最後の要素です。以下に例を示します。" 11113 11114#: ../../rst/user_guide/vault.rst:53 11115msgid "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:" 11116msgstr "ラベルに加えて、関連するパスワードのソースを提供する必要があります。ソースは、Vault パスワードをどのように保存するかによって、プロンプト、ファイル、またはスクリプトになります。パターンは次のようになります。" 11117 11118#: ../../rst/user_guide/vault.rst:59 11119msgid "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." 11120msgstr "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>` と一緒に使用することができます。パターンは、暗号化されたコンテンツを作成するときと同じで、一致するパスワードのラベルとソースを含めます。" 11121 11122#: ../../rst/user_guide/vault.rst:61 11123msgid "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." 11124msgstr "Vault ID でコンテンツを暗号化する例と、Vault ID で暗号化されたコンテンツを使用する例については、以下を参照してください。:option:`--vault-id <ansible-playbook --vault-id>` オプションは、:ref:`ansible-vault`、:ref:`ansible-playbook` など、Vault と相互作用するすべての Ansible コマンドで動作します。" 11125 11126#: ../../rst/user_guide/vault.rst:64 11127msgid "Limitations of vault IDs" 11128msgstr "vault ID の制限" 11129 11130#: ../../rst/user_guide/vault.rst:66 11131msgid "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." 11132msgstr "Ansible は、特定の Vault ID ラベルを使用するたびに同じパスワードを使用することを強制しません。異なる変数やファイルを、同じ Vault ID ラベルで異なるパスワードで暗号化することができます。これは通常、プロンプトでパスワードを入力して間違えた場合に起こります。意図的に、同じ Vault ID ラベルで異なるパスワードを使用することは可能です。たとえば、各ラベルを、単一のパスワードではなく、パスワードのクラスへの参照として使用することができます。このシナリオでは、どの特定のパスワードまたはファイルを使用するかを常にコンテキストで知っておく必要があります。しかし、誤って同じ Vault ID ラベルと異なるパスワードを持つ 2 つのファイルを暗号化してしまう可能性が高くなります。誤って同じラベルで異なるパスワードの 2 つのファイルを暗号化してしまった場合は、1つのファイルで :ref:`rekey <rekeying_files>` を行って問題を解決できます。" 11133 11134#: ../../rst/user_guide/vault.rst:69 11135msgid "Enforcing vault ID matching" 11136msgstr "Vault ID 一致の強制" 11137 11138#: ../../rst/user_guide/vault.rst:71 11139msgid "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." 11140msgstr "デフォルトでは、Vault ID ラベルは、変数やファイルの暗号化にどのパスワードを使用したかを思い出させるためのヒントに過ぎません。Ansible は、暗号化されたコンテンツのヘッダーにある vault ID が、コンテンツの使用時に提供した Vault ID と一致するかどうかはチェックしません。Ansible は、提供したパスワードで暗号化されたコマンドまたは Playbook によって呼び出されたすべてのファイルおよび変数を復号します。暗号化されたコンテンツをチェックし、コンテンツに含まれる Vault ID が ``--vault-id`` で提供したものと一致した場合にのみ暗号化を解除するには、設定オプション :ref:`DEFAULT_VAULT_ID_MATCH` を設定します。:ref:`DEFAULT_VAULT_ID_MATCH` を設定すると、各パスワードは同じラベルで暗号化されたデータの復号にのみ使用されます。これは効率的で予測可能であり、異なる値が異なるパスワードで暗号化された場合のエラーを減らすことができます。" 11141 11142#: ../../rst/user_guide/vault.rst:74 11143msgid "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." 11144msgstr ":ref:`DEFAULT_VAULT_ID_MATCH` の設定が有効になっている場合でも、特定の vault ID ラベルを使用するたびに、Ansible は同じパスワードの使用を強制しません。" 11145 11146#: ../../rst/user_guide/vault.rst:79 11147msgid "Storing and accessing vault passwords" 11148msgstr "Vault パスワードの保存およびアクセス" 11149 11150#: ../../rst/user_guide/vault.rst:81 11151msgid "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." 11152msgstr "Valut パスワードを記憶したり、Valut パスワードを任意のソースから手動でコピーしてコマンドラインプロンプトに貼り付けたりすることもできますが、ほとんどのユーザーは安全に保管し、必要に応じて Ansible 内からアクセスします。Ansible 内で機能する Valut パスワードの保管方法には、ファイルに保管する方法と、システムキーリングやシークレットマネージャーなどのサードパーティーツールに保管する方法があります。サードパーティーのツールにパスワードを保存する場合、Ansible 内からパスワードを取得するには、Vault パスワードクライアントスクリプトが必要です。" 11153 11154#: ../../rst/user_guide/vault.rst:84 11155msgid "Storing passwords in files" 11156msgstr "パスワードのファイルへの保存" 11157 11158#: ../../rst/user_guide/vault.rst:86 11159msgid "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." 11160msgstr "Vault のパスワードをファイルに保存するには、ファイルの 1 行にパスワードを文字列で入力します。ファイルのパーミッションが適切であることを確認してください。パスワードファイルをソースコントロールに追加しないでください。" 11161 11162#: ../../rst/user_guide/vault.rst:91 11163msgid "Storing passwords in third-party tools with vault password client scripts" 11164msgstr "Vault パスワードクライアントスクリプトを使用したサードパーティーツールへのパスワードの保存" 11165 11166#: ../../rst/user_guide/vault.rst:93 11167msgid "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." 11168msgstr "Valut パスワードは、システムキーリング、データベース、またはシークレットマネージャーに保存し、Valut パスワードクライアントスクリプトを使用して Ansible 内から取り出すことができます。パスワードは 1 行の文字列として入力します。パスワードに Vault ID がある場合は、パスワード保存ツールと連携する方法で保存します。" 11169 11170#: ../../rst/user_guide/vault.rst:95 11171msgid "To create a vault password client script:" 11172msgstr "Vault パスワードクライアントスクリプトを作成するには、以下のようにします。" 11173 11174#: ../../rst/user_guide/vault.rst:97 11175msgid "Create a file with a name ending in either ``-client`` or ``-client.EXTENSION``" 11176msgstr "名前が ``-client`` または ``-client.EXTENSION`` で終わるファイルを作成します。" 11177 11178#: ../../rst/user_guide/vault.rst:98 11179msgid "Make the file executable" 11180msgstr "ファイルを実行可能な状態にする" 11181 11182#: ../../rst/user_guide/vault.rst:102 11183msgid "Within the script itself:" 11184msgstr "スクリプト自体:" 11185 11186#: ../../rst/user_guide/vault.rst:100 11187msgid "Print the passwords to standard output" 11188msgstr "標準出力にパスワードを出力します" 11189 11190#: ../../rst/user_guide/vault.rst:101 11191msgid "Accept a ``--vault-id`` option" 11192msgstr "``--vault-id`` オプションを受け入れる" 11193 11194#: ../../rst/user_guide/vault.rst:102 11195msgid "If the script prompts for data (for example, a database password), send the prompts to standard error" 11196msgstr "スクリプトがデータを要求する場合 (例; データベースパスワード) には、プロンプトを標準エラーに送信します。" 11197 11198#: ../../rst/user_guide/vault.rst:104 11199msgid "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:" 11200msgstr "サードパーティーのツールに保存されている Vault パスワードを使用する Playbook を実行する場合は、``--vault-id`` フラグ内でスクリプトをソースとして指定します。以下を例に示します。" 11201 11202#: ../../rst/user_guide/vault.rst:110 11203msgid "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:" 11204msgstr "Ansible はクライアントスクリプトを ``--vault-id`` オプション付きで実行するため、スクリプトは指定された Vault ID ラベルを知ることができます。たとえば、シークレットマネージャーからパスワードを読み込むスクリプトは、Vault ID ラベルを使用して、「dev」または「prod」のいずれかのパスワードを選択できます。上記のコマンドの例では、クライアントスクリプトの実行結果は次のようになります。" 11205 11206#: ../../rst/user_guide/vault.rst:116 11207msgid "For an example of a client script that loads passwords from the system keyring, see :file:`contrib/vault/vault-keyring-client.py`." 11208msgstr "システムキーリングからパスワードを読み込むクライアントスクリプトの例は、:file:`contrib/vault/vault-keyring-client.py` を参照してください。" 11209 11210#: ../../rst/user_guide/vault.rst:122 11211msgid "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:" 11212msgstr "Vault のパスワードを管理および保管するためのストラテジーができたら、コンテンツの暗号化を開始しましょう。Ansible Vault では、変数とファイルの 2 種類のコンテンツを暗号化することができます。暗号化されたコンテンツには、必ず ``!vault`` タグが含まれています。これは、コンテンツの復号が必要であることを Ansible と YAML に伝えるもので、複数行の文字列を可能にする ``|`` 文字も含まれています。``--vault-id`` で作成された暗号化コンテンツには、Vault ID ラベルも含まれます。Ansible Vault で暗号化されたコンテンツの暗号化プロセスと形式の詳細は、「:ref:`vault_format`」を参照してください。この表は、暗号化された変数と暗号化されたファイルの主な違いを示しています。" 11213 11214#: ../../rst/user_guide/vault.rst:128 11215msgid "Encrypted variables" 11216msgstr "暗号化された変数" 11217 11218#: ../../rst/user_guide/vault.rst:128 11219msgid "Encrypted files" 11220msgstr "暗号化されたファイル" 11221 11222#: ../../rst/user_guide/vault.rst:130 11223msgid "How much is encrypted?" 11224msgstr "どのくらい暗号化されているのか。" 11225 11226#: ../../rst/user_guide/vault.rst:130 11227msgid "Variables within a plaintext file" 11228msgstr "平文ファイル内の変数" 11229 11230#: ../../rst/user_guide/vault.rst:130 11231msgid "The entire file" 11232msgstr "ファイル全体" 11233 11234#: ../../rst/user_guide/vault.rst:132 11235msgid "When is it decrypted?" 11236msgstr "復号するタイミング" 11237 11238#: ../../rst/user_guide/vault.rst:132 11239msgid "On demand, only when needed" 11240msgstr "オンデマンドで (必要な場合にのみ)" 11241 11242#: ../../rst/user_guide/vault.rst:132 11243msgid "Whenever loaded or referenced [#f1]_" 11244msgstr "読み込みまたは参照する場合 [#f1]_" 11245 11246#: ../../rst/user_guide/vault.rst:134 11247msgid "What can be encrypted?" 11248msgstr "暗号化できるもの。" 11249 11250#: ../../rst/user_guide/vault.rst:134 11251msgid "Only variables" 11252msgstr "変数のみ" 11253 11254#: ../../rst/user_guide/vault.rst:134 11255msgid "Any structured data file" 11256msgstr "構造化データファイル" 11257 11258#: ../../rst/user_guide/vault.rst:138 11259msgid "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." 11260msgstr "Ansible は、ファイルを復号しない限り、暗号化されたファイルからコンテンツを必要とするかどうかを認識できないため、Playbook およびロールで参照される暗号化されたファイルをすべて復号します。" 11261 11262#: ../../rst/user_guide/vault.rst:144 11263msgid "Encrypting individual variables with Ansible Vault" 11264msgstr "Ansible Vault による個々の変数の暗号化" 11265 11266#: ../../rst/user_guide/vault.rst:146 11267msgid "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`." 11268msgstr ":ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` コマンドを使用して、YAML ファイル内で 1 つの値を暗号化することができます。vault を使用した変数を安全に表示できる方法は、「:ref:`tip_for_variables_and_vaults`」を参照してください。" 11269 11270#: ../../rst/user_guide/vault.rst:149 11271msgid "Advantages and disadvantages of encrypting variables" 11272msgstr "変数を暗号化することの利点および欠点" 11273 11274#: ../../rst/user_guide/vault.rst:151 11275msgid "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." 11276msgstr "変数レベルの暗号化では、ファイルを簡単に読み取ることができます。平文の変数と暗号化された変数を混在させることができ、プレイやロールの中でインラインでも使用できます。しかし、パスワードのローテーションはファイルレベルの暗号化のように簡単ではありません。で暗号化された変数に :ref:`鍵の再設定 <rekeying_files>` は使用できません。また、変数レベルの暗号化は変数に対してのみ機能します。タスクやその他のコンテンツを暗号化したい場合は、ファイル全体を暗号化する必要があります。" 11277 11278#: ../../rst/user_guide/vault.rst:156 11279msgid "Creating encrypted variables" 11280msgstr "暗号化されたファイルの作成" 11281 11282#: ../../rst/user_guide/vault.rst:158 11283msgid "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:" 11284msgstr ":ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` コマンドは、入力 (もしくはコピーまたは生成) した文字列を暗号化して、Playbook、ロール、変数ファイルに含めることができる形式にします。基本的な暗号化変数を作成するには、:ref:`ansible-vault encrypt_string <ansible_vault_encrypt_string>` コマンドに 3 つのオプションを渡します。" 11285 11286#: ../../rst/user_guide/vault.rst:160 11287msgid "a source for the vault password (prompt, file, or script, with or without a vault ID)" 11288msgstr "vault パスワードのソース (プロンプト、ファイル、またはスクリプト、vault ID ありまたはなし)" 11289 11290#: ../../rst/user_guide/vault.rst:161 11291msgid "the string to encrypt" 11292msgstr "暗号化する文字列" 11293 11294#: ../../rst/user_guide/vault.rst:162 11295msgid "the string name (the name of the variable)" 11296msgstr "文字列名 (変数の名前)" 11297 11298#: ../../rst/user_guide/vault.rst:164 11299msgid "The pattern looks like this:" 11300msgstr "パターンは以下のようになります。" 11301 11302#: ../../rst/user_guide/vault.rst:170 11303msgid "For example, to encrypt the string 'foobar' using the only password stored in 'a_password_file' and name the variable 'the_secret':" 11304msgstr "たとえば、「a_password_file」に保存されたパスワードのみを使用して文字列を「foobar」を暗号化する際に、変数「the_secret」に名前を付けます。" 11305 11306#: ../../rst/user_guide/vault.rst:176 ../../rst/user_guide/vault.rst:192 11307msgid "The command above creates this content::" 11308msgstr "上記のコマンドにより、以下のような内容が作成されます。" 11309 11310#: ../../rst/user_guide/vault.rst:186 11311msgid "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':" 11312msgstr "文字列「foooodev」を暗号化するには、Vault ID ラベル「dev」に「a_password_file」に格納されている「dev」の Vault パスワードを追加し、暗号化された変数「the_dev_secret」を呼び出します。" 11313 11314#: ../../rst/user_guide/vault.rst:202 11315msgid "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':" 11316msgstr "標準入力から読み込んだ文字列「letmein」を暗号化するために、`a_password_file` に保存されている「dev」の Vault のパスワードを使用してVault ID「dev」を追加し、変数に「db_password」という名前を付けます。" 11317 11318#: ../../rst/user_guide/vault.rst:210 11319msgid "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." 11320msgstr "秘密の内容をコマンドラインで直接入力すると (プロンプトなし)、シェルの履歴に秘密の文字列が残ります。テスト時以外はこのようなことをしないでください。" 11321 11322#: ../../rst/user_guide/vault.rst:212 11323msgid "The command above creates this output::" 11324msgstr "上記のコマンドにより、以下が出力されます。" 11325 11326#: ../../rst/user_guide/vault.rst:223 11327msgid "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':" 11328msgstr "暗号化する文字列の入力を求められるので、「a_password_file」の「dev」の Vault パスワードで暗号化し、変数名を「new_user_password」とし、Vault ID ラベル「dev」を付与します。" 11329 11330#: ../../rst/user_guide/vault.rst:229 11331msgid "The command above triggers this prompt:" 11332msgstr "上記のコマンドにより、以下のプロンプトがトリガーされます。" 11333 11334#: ../../rst/user_guide/vault.rst:235 11335msgid "Type the string to encrypt (for example, 'hunter2'), hit ctrl-d, and wait." 11336msgstr "暗号化する文字列 (「hunter2」など)、ctrl-d を押してお待ちください。" 11337 11338#: ../../rst/user_guide/vault.rst:239 11339msgid "Do not press ``Enter`` after supplying the string to encrypt. That will add a newline to the encrypted value." 11340msgstr "暗号化する文字列を指定した後に ``Enter`` を押さないでください。暗号化された値に改行を追加します。" 11341 11342#: ../../rst/user_guide/vault.rst:241 11343msgid "The sequence above creates this output::" 11344msgstr "上記のシーケンスにより、以下のような出力が作成されます。" 11345 11346#: ../../rst/user_guide/vault.rst:251 11347msgid "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." 11348msgstr "上記の例の出力を、将来使用するために、任意の Playbook、変数ファイル、またはロールに追加することができます。暗号化された変数は、平文の変数よりもサイズが大きくなりますが、機密性の高いコンテンツを保護する一方で、Playbook、変数ファイル、またはロールの残りの部分は平文のままなので、簡単に読み取ることができます。" 11349 11350#: ../../rst/user_guide/vault.rst:254 11351msgid "Viewing encrypted variables" 11352msgstr "暗号化された変数の表示" 11353 11354#: ../../rst/user_guide/vault.rst:256 11355msgid "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:" 11356msgstr "暗号化された変数の元の値は、デバッグモジュールを使用して見ることができます。その際には、変数の暗号化に使用したパスワードを渡す必要があります。たとえば、上記の最後の例で作成した変数を「vars.yml」というファイルに保存した場合、その変数の暗号化されていない値を見るには次のようにします。" 11357 11358#: ../../rst/user_guide/vault.rst:268 11359msgid "Encrypting files with Ansible Vault" 11360msgstr "Ansible Vault によるファイルの暗号化" 11361 11362#: ../../rst/user_guide/vault.rst:270 11363msgid "Ansible Vault can encrypt any structured data file used by Ansible, including:" 11364msgstr "Ansible Vault は、Ansible が使用するあらゆる構造化データファイルを暗号化することができます。以下に例を示します。" 11365 11366#: ../../rst/user_guide/vault.rst:272 11367msgid "group variables files from inventory" 11368msgstr "インベントリーからのグループ変数ファイル" 11369 11370#: ../../rst/user_guide/vault.rst:273 11371msgid "host variables files from inventory" 11372msgstr "インベントリーからのホスト変数ファイル" 11373 11374#: ../../rst/user_guide/vault.rst:274 11375msgid "variables files passed to ansible-playbook with ``-e @file.yml`` or ``-e @file.json``" 11376msgstr "``-e @file.yml`` または ``-e @file.json`` で ansible-playbook に渡される変数ファイル" 11377 11378#: ../../rst/user_guide/vault.rst:275 11379msgid "variables files loaded by ``include_vars`` or ``vars_files``" 11380msgstr "``include_vars`` または ``vars_files`` により読み込まれた変数ファイル" 11381 11382#: ../../rst/user_guide/vault.rst:276 11383msgid "variables files in roles" 11384msgstr "ロールの変数ファイル" 11385 11386#: ../../rst/user_guide/vault.rst:277 11387msgid "defaults files in roles" 11388msgstr "ロール内のデフォルトファイル" 11389 11390#: ../../rst/user_guide/vault.rst:278 11391msgid "tasks files" 11392msgstr "tasks ファイル" 11393 11394#: ../../rst/user_guide/vault.rst:279 11395msgid "handlers files" 11396msgstr "ハンドラーファイル" 11397 11398#: ../../rst/user_guide/vault.rst:280 11399msgid "binary files or other arbitrary files" 11400msgstr "バイナリーファイルまたはその他の任意のファイル" 11401 11402#: ../../rst/user_guide/vault.rst:282 11403msgid "The full file is encrypted in the vault." 11404msgstr "完全なファイルは vault で暗号化されます。" 11405 11406#: ../../rst/user_guide/vault.rst:286 11407msgid "Ansible Vault uses an editor to create or modify encrypted files. See :ref:`vault_securing_editor` for some guidance on securing the editor." 11408msgstr "Ansible Vault はエディターを使用して暗号化されたファイルの作成または変更します。エディターのセキュリティー保護に関するいくつかのガイダンスは、「:ref:`vault_securing_editor`」を参照してください。" 11409 11410#: ../../rst/user_guide/vault.rst:290 11411msgid "Advantages and disadvantages of encrypting files" 11412msgstr "ファイルを暗号化することの利点および欠点" 11413 11414#: ../../rst/user_guide/vault.rst:292 11415msgid "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." 11416msgstr "ファイルレベルの暗号化は簡単に使用できます。暗号化されたファイルのパスワードローテーションは、:ref:`rekey <rekeying_files>` コマンドで簡単に行うことができます。ファイルを暗号化すると、センシティブな値だけでなく、使用する変数の名前も隠すことができます。しかし、ファイルレベルの暗号化では、ファイルの内容に簡単にアクセスして読むことができなくなります。これは暗号化されたタスクファイルでは問題になるかもしれません。変数ファイルを暗号化する場合は、これらの変数への参照を暗号化されていないファイルに保持する 1 つの方法については、「:ref:`tip_for_variables_and_vaults`」を参照してください。Ansible は、暗号化されたファイルを読み込んだり参照したりする際には、常に暗号化されたファイル全体を復号します。これは、Ansible は復号しない限りコンテンツが必要かどうかを知ることができないからです。" 11417 11418#: ../../rst/user_guide/vault.rst:297 11419msgid "Creating encrypted files" 11420msgstr "暗号化されたファイルの作成" 11421 11422#: ../../rst/user_guide/vault.rst:299 11423msgid "To create a new encrypted data file called 'foo.yml' with the 'test' vault password from 'multi_password_file':" 11424msgstr "「multi_password_file」の Vault \"パスワード「test」を使って、「foo.yml」という名前の新しい暗号化データファイルを作成するには、以下を行います。" 11425 11426#: ../../rst/user_guide/vault.rst:305 11427msgid "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:" 11428msgstr "このツールは、エディター ($EDITOR で定義したエディターがなんであれ、デフォルトは vi) を起動します。コンテンツを追加します。エディターセッションを終了すると、ファイルは暗号化されたデータとして保存されます。ファイルのヘッダーには、作成時に使用した Vault ID が反映されます。" 11429 11430#: ../../rst/user_guide/vault.rst:311 11431msgid "To create a new encrypted data file with the vault ID 'my_new_password' assigned to it and be prompted for the password:" 11432msgstr "Vault ID「my_new_password」が割り当てられた新しい暗号化データファイルを作成し、パスワードの入力を求められるようにするには、以下を行います。" 11433 11434#: ../../rst/user_guide/vault.rst:317 11435msgid "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." 11436msgstr "ここでも、エディターのファイルにコンテンツを追加して保存します。プロンプトで作成した新しいパスワードを必ず保存し、そのファイルを復号するときに見つけられるようにしてください。" 11437 11438#: ../../rst/user_guide/vault.rst:322 11439msgid "Encrypting existing files" 11440msgstr "既存ファイルの暗号化" 11441 11442#: ../../rst/user_guide/vault.rst:324 11443msgid "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:" 11444msgstr "既存ファイルを暗号化するには、:ref:`ansible-vault encrypt <ansible_vault_encrypt>` コマンドを使用します。このコマンドは、一度に複数のファイルで動作します。以下に例を示します。" 11445 11446#: ../../rst/user_guide/vault.rst:330 11447msgid "To encrypt existing files with the 'project' ID and be prompted for the password:" 11448msgstr "「プロジェクト」IDで既存のファイルを暗号化し、パスワードの入力を求めるプロンプトを表示するには、以下のようになります。" 11449 11450#: ../../rst/user_guide/vault.rst:340 11451msgid "Viewing encrypted files" 11452msgstr "暗号化されたファイルの表示" 11453 11454#: ../../rst/user_guide/vault.rst:342 11455msgid "To view the contents of an encrypted file without editing it, you can use the :ref:`ansible-vault view <ansible_vault_view>` command:" 11456msgstr "暗号化されたファイルの内容を編集せずに表示する場合は、:ref:`ansible-vault view <ansible_vault_view>` コマンドを使用できます。" 11457 11458#: ../../rst/user_guide/vault.rst:352 11459msgid "Editing encrypted files" 11460msgstr "暗号化されたファイルの編集" 11461 11462#: ../../rst/user_guide/vault.rst:354 11463msgid "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:" 11464msgstr "暗号化されたファイルをその場で編集するには、:ref:`ansible-vault edit <ansible_vault_edit>` コマンドを使用します。このコマンドは、ファイルを一時的なファイルに復号し、内容を編集できるようにした後、内容を保存して再度暗号化し、エディターを閉じるときに一時的なファイルを削除します。以下に例を示します。" 11465 11466#: ../../rst/user_guide/vault.rst:360 11467msgid "To edit a file encrypted with the ``vault2`` password file and assigned the vault ID ``pass2``:" 11468msgstr "「``vault2``」パスワードファイルで暗号化され、vault ID「``pass2``」を割り当てたファイルを編集するには、以下を実行します。" 11469 11470#: ../../rst/user_guide/vault.rst:370 11471msgid "Changing the password and/or vault ID on encrypted files" 11472msgstr "暗号化されたファイルのパスワードまたは vault ID の変更" 11473 11474#: ../../rst/user_guide/vault.rst:372 11475msgid "To change the password on an encrypted file or files, use the :ref:`rekey <ansible_vault_rekey>` command:" 11476msgstr "暗号化された 1 つまたは複数のファイルのパスワードを変更するには、:ref:`rekey <ansible_vault_rekey>` コマンドを使用します。" 11477 11478#: ../../rst/user_guide/vault.rst:378 11479msgid "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:" 11480msgstr "このコマンドは、複数のデータファイルの鍵を一度に設定することができ、元のパスワードと新しいパスワードを要求します。鍵を一度に設定したファイルに別の ID を設定するには、新しい ID を ``--new-vault-id`` に渡します。たとえば、「ppold」ファイルから「preprod1」の Vault ID で暗号化されたファイルのリストを Vault ID「preprod2」に鍵を再設定し、新しいパスワードの入力を求められる場合です。" 11481 11482#: ../../rst/user_guide/vault.rst:388 11483msgid "Decrypting encrypted files" 11484msgstr "暗号化されたファイルの復号化" 11485 11486#: ../../rst/user_guide/vault.rst:390 11487msgid "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." 11488msgstr "暗号化されたファイルがあり、そのファイルを暗号化したままにしておきたくない場合は、:ref:`ansible-vault decrypt <ansible_vault_decrypt>` コマンドを実行することで永久に暗号化を解除することができます。このコマンドは暗号化されていないファイルをディスクに保存するため、代わりに :ref:`edit <ansible_vault_edit>` を使用しないようにしてください。" 11489 11490#: ../../rst/user_guide/vault.rst:400 11491msgid "Steps to secure your editor" 11492msgstr "エディターを確保するための手順" 11493 11494#: ../../rst/user_guide/vault.rst:402 11495msgid "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." 11496msgstr "Ansible Vault は、設定されたエディターに依存しており、これが情報漏えいの原因となることがあります。ほとんどのエディターには、データの損失を防ぐ方法がありますが、通常は、秘密のコピーが平文で保存されている可能性のある追加の平文ファイルに依存しています。エディターのドキュメントを参照して、セキュアなデータの開示を回避するようにエディターを設定してください。以下のセクションでは、一般的なエディターに関するガイダンスを提供していますが、エディターのセキュリティーを確保するための完全なガイドと考えるべきではありません。" 11497 11498#: ../../rst/user_guide/vault.rst:406 11499msgid "vim" 11500msgstr "vim" 11501 11502#: ../../rst/user_guide/vault.rst:408 11503msgid "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." 11504msgstr "以下の ``vim`` オプションをコマンドモードで設定することで、情報漏えいのケースを回避することができます。特にプラグインを使用している場合など、セキュリティーを確保するために変更しなければならない設定が他にもあるかもしれないため、``vim`` のドキュメントを参照してください。" 11505 11506#: ../../rst/user_guide/vault.rst:411 11507msgid "Disable swapfiles that act like an autosave in case of crash or interruption." 11508msgstr "クラッシュまたは中断が発生した場合に自動保存として機能する swapfiles を無効にします。" 11509 11510#: ../../rst/user_guide/vault.rst:417 ../../rst/user_guide/vault.rst:451 11511msgid "Disable creation of backup files." 11512msgstr "バックアップファイルの作成を無効にします。" 11513 11514#: ../../rst/user_guide/vault.rst:424 11515msgid "Disable the viminfo file from copying data from your current session." 11516msgstr "viminfo ファイルを無効にして、現在のセッションからデータをコピーします。" 11517 11518#: ../../rst/user_guide/vault.rst:430 11519msgid "Disable copying to the system clipboard." 11520msgstr "システムクリップボードへのコピーを無効にします。" 11521 11522#: ../../rst/user_guide/vault.rst:437 11523msgid "You can optionally add these settings in ``.vimrc`` for all files, or just specific paths or extensions. See the ``vim`` manual for details." 11524msgstr "必要に応じて、すべてのファイルまたは特定のパスまたは拡張の ``.vimrc`` にこれらの設定を追加できます。詳細は、``vim`` マニュアルを参照してください。" 11525 11526#: ../../rst/user_guide/vault.rst:441 11527msgid "Emacs" 11528msgstr "Emacs" 11529 11530#: ../../rst/user_guide/vault.rst:443 11531msgid "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." 11532msgstr "以下の Emacs オプションを設定することで、情報漏えいのケースを回避することができます。特にプラグインを使用する場合には、セキュリティーを確保するために変更する必要がある設定が他にもあるかもしれないため、Emacs のドキュメントを参照してください。" 11533 11534#: ../../rst/user_guide/vault.rst:445 11535msgid "Do not copy data to the system clipboard." 11536msgstr "データをシステムクリップボードにコピーしないでください。" 11537 11538#: ../../rst/user_guide/vault.rst:457 11539msgid "Disable autosave files." 11540msgstr "自動保存ファイルを無効にします。" 11541 11542#: ../../rst/user_guide/vault.rst:468 11543msgid "Using encrypted variables and files" 11544msgstr "暗号化された変数とファイルの使用" 11545 11546#: ../../rst/user_guide/vault.rst:470 11547msgid "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." 11548msgstr "暗号化された変数やファイルを使用するタスクや Playbook を実行する際には、変数やファイルを復号するためのパスワードを提供する必要があります。これは、コマンドラインまたは Playbook 自体の中で行うことができます。" 11549 11550#: ../../rst/user_guide/vault.rst:473 11551msgid "Passing a single password" 11552msgstr "単一のパスワードを渡す" 11553 11554#: ../../rst/user_guide/vault.rst:475 11555msgid "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." 11556msgstr "タスクや Playbook が必要とするすべての暗号化された変数やファイルが単一のパスワードを使用する場合は、CLI オプション :option:`--ask-vault-pass <ansible-playbook --ask-vault-pass>` または :option:`--vault-password-file <ansible-playbook --vault-password-file>` を使用できます。" 11557 11558#: ../../rst/user_guide/vault.rst:477 ../../rst/user_guide/vault.rst:545 11559msgid "To prompt for the password:" 11560msgstr "パスワードを要求する場合は、以下のようになります。" 11561 11562#: ../../rst/user_guide/vault.rst:483 11563msgid "To retrieve the password from the :file:`/path/to/my/vault-password-file` file:" 11564msgstr ":file:`/path/to/my/vault-password-file` ファイルからパスワードを取得するには、以下を行います。" 11565 11566#: ../../rst/user_guide/vault.rst:489 11567msgid "To get the password from the vault password client script :file:`my-vault-password-client.py`:" 11568msgstr "実行スクリプト :file:`my-vault-password-client.py` から vault パスワードを取得する場合は、以下のようになります。" 11569 11570#: ../../rst/user_guide/vault.rst:499 11571msgid "Passing vault IDs" 11572msgstr "Vault ID を渡す" 11573 11574#: ../../rst/user_guide/vault.rst:501 11575msgid "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." 11576msgstr ":option:`--vault-id <ansible-playbook --vault-id>` オプションを使用して、vault ラベルで単一のパスワードを渡すこともできます。このアプローチは、1 つのインベントリー内で複数の vault を使用している場合はより明確になります。" 11577 11578#: ../../rst/user_guide/vault.rst:503 11579msgid "To prompt for the password for the 'dev' vault ID:" 11580msgstr "vault ID「dev」のパスワードを要求する場合は、次のようになります。" 11581 11582#: ../../rst/user_guide/vault.rst:509 11583msgid "To retrieve the password for the 'dev' vault ID from the :file:`dev-password` file:" 11584msgstr "「dev」の Vault ID のパスワードを :file:`dev-password` のファイルから取得するには、以下を行います。" 11585 11586#: ../../rst/user_guide/vault.rst:515 11587msgid "To get the password for the 'dev' vault ID from the vault password client script :file:`my-vault-password-client.py`:" 11588msgstr "実行スクリプト :file:`my-vault-password-client.py` から vault ID 「dev」のパスワードを取得する場合は次のようになります。" 11589 11590#: ../../rst/user_guide/vault.rst:522 11591msgid "Passing multiple vault passwords" 11592msgstr "複数の vault パスワードを渡す" 11593 11594#: ../../rst/user_guide/vault.rst:524 11595msgid "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:" 11596msgstr "タスクや Playbook で、異なる Vault ID で暗号化した複数の暗号化された変数やファイルが必要な場合は、:option:`--vault-id <ansible-playbook --vault-id>` オプションを使用し、複数の ``--vault-id`` オプションを渡して Vault ID (「dev」、「prod」、「cloud」、「db」) とパスワードのソース (プロンプト、ファイル、スクリプト) を指定する必要があります。たとえば、ファイルから読み込んだ「dev」のパスワードを使用し、「prod」のパスワードを求めるプロンプトを表示する場合などです。" 11597 11598#: ../../rst/user_guide/vault.rst:530 11599msgid "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." 11600msgstr "デフォルトでは、Vault ID ラベル (dev、prodなど) はヒントでしかありません。Ansible は、各パスワードで Vault のコンテンツの復号を試みます。暗号化されたデータと同じラベルのパスワードが最初に試行され、その後、コマンドラインで指定された順に各 Vault シークレットが試行されます。" 11601 11602#: ../../rst/user_guide/vault.rst:532 11603msgid "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." 11604msgstr "暗号化されたデータにラベルがない場合、またはラベルが提供されたラベルのどれとも一致しない場合、パスワードは指定された順に試行されます。上の例では、「dev」パスワードが最初に試行され、次に「prod」パスワードが試行されます。これは、Ansible がどの Vault ID が何かの暗号化に使用されているかを知らない場合のためです。" 11605 11606#: ../../rst/user_guide/vault.rst:535 11607msgid "Using ``--vault-id`` without a vault ID" 11608msgstr "vault ID なしで ``--vault-id`` を使用" 11609 11610#: ../../rst/user_guide/vault.rst:537 11611msgid "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." 11612msgstr ":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>` と同等であるため、ほとんど使用されません。" 11613 11614#: ../../rst/user_guide/vault.rst:539 11615msgid "For example, to use a password file :file:`dev-password`:" 11616msgstr "たとえば、パスワードファイル `dev-password` を使用する場合は、以下のようになります。" 11617 11618#: ../../rst/user_guide/vault.rst:551 11619msgid "To get the password from an executable script :file:`my-vault-password-client.py`:" 11620msgstr "実行スクリプト :file:`my-vault-password-client.py` からパスワードを取得する場合は、以下のようになります。" 11621 11622#: ../../rst/user_guide/vault.rst:559 11623msgid "Configuring defaults for using encrypted content" 11624msgstr "暗号化されたコンテンツを使用するためのデフォルトの設定" 11625 11626#: ../../rst/user_guide/vault.rst:562 11627msgid "Setting a default vault ID" 11628msgstr "デフォルトの Vault ID の設定" 11629 11630#: ../../rst/user_guide/vault.rst:564 11631msgid "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." 11632msgstr "ある 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>` を渡すことと同じです。" 11633 11634#: ../../rst/user_guide/vault.rst:567 11635msgid "Setting a default password source" 11636msgstr "デフォルトのパスワードソースの設定" 11637 11638#: ../../rst/user_guide/vault.rst:569 11639msgid "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." 11640msgstr "ある Vault パスワードファイルを他のファイルよりも頻繁に使用する場合は、:ref:`DEFAULT_VAULT_PASSWORD_FILE` 設定オプションまたは環境変数 :envvar:`ANSIBLE_VAULT_PASSWORD_FILE` を設定して、そのファイルを指定することができます。たとえば、``ANSIBLE_VAULT_PASSWORD_FILE=~/.vault_pass.txt`` を設定すると、Ansible は自動的にそのファイル内のパスワードを検索します。これは、たとえば、Jenkins などの継続的インテグレーションシステムから Ansible を使用する場合に便利です。" 11641 11642#: ../../rst/user_guide/vault.rst:572 11643msgid "When are encrypted files made visible?" 11644msgstr "暗号化ファイルをいつ表示するか。" 11645 11646#: ../../rst/user_guide/vault.rst:574 11647msgid "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." 11648msgstr "一般的に、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 パスワードを供給していることが前提です)。この動作は意図されたものであり、便利なものです。設定ファイルやテンプレートを暗号化して、設定の詳細を共有しないようにすることができますが、その設定を環境内のサーバーにコピーするときには、ローカルのユーザーやプロセスがアクセスできるように、暗号化を解除したいものです。" 11649 11650#: ../../rst/user_guide/vault.rst:579 11651msgid "Speeding up Ansible Vault" 11652msgstr "Ansible Vault のスピードアップ" 11653 11654#: ../../rst/user_guide/vault.rst:581 11655msgid "If you have many encrypted files, decrypting them at startup may cause a perceptible delay. To speed this up, install the cryptography package:" 11656msgstr "多くの暗号化されたファイルがある場合、起動時にそれらを復号化すると、知覚できるほどの遅延が生じることがあります。これを高速化するには、暗号化パッケージをインストールします。" 11657 11658#: ../../rst/user_guide/vault.rst:591 11659msgid "Format of files encrypted with Ansible Vault" 11660msgstr "Ansible Vault で暗号化されたファイルの形式" 11661 11662#: ../../rst/user_guide/vault.rst:593 11663msgid "Ansible Vault creates UTF-8 encoded txt files. The file format includes a newline terminated header. For example::" 11664msgstr "Ansible Vault は、UTF-8 でエンコードされたテキストファイルを作成します。ファイル形式には、改行で終了するヘッダーが含まれます。以下に例を示します。" 11665 11666#: ../../rst/user_guide/vault.rst:597 11667msgid "or::" 11668msgstr "または::" 11669 11670#: ../../rst/user_guide/vault.rst:601 11671msgid "The header contains up to four elements, separated by semi-colons (``;``)." 11672msgstr "ヘッダーには、セミコロン (``;``) で区切られた最大 4 つの要素が含まれます。" 11673 11674#: ../../rst/user_guide/vault.rst:603 11675msgid "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())." 11676msgstr "形式 ID (``$ANSIBLE_VAULT``)。現在、``$ANSIBLE_VAULT`` は唯一の有効な形式 ID です。フォーマット ID は、(vault.is_encrypted_file() を介して) Ansible Vault で暗号化されているコンテンツを識別します。" 11677 11678#: ../../rst/user_guide/vault.rst:605 11679msgid "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')." 11680msgstr "Vault 形式バージョン (``1.X``) です。現在、サポートされているすべてのバージョンの Ansible では、ラベル付きの Vault IDが指定された場合は、デフォルトで「1.1」または「1.2」になります。「1.0」形式は読み込みのみサポートしています (書き込み時には自動的に「1.1」形式に変換されます)。形式のバージョンは、現在、正確な文字列の比較としてのみ使用されています (バージョン番号は現在「比較」されません)。" 11681 11682#: ../../rst/user_guide/vault.rst:607 11683msgid "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'." 11684msgstr "データの暗号化に使用される暗号アルゴリズム (``AES256``)。現在、``AES256`` が唯一サポートされている暗号アルゴリズムです。Vault 形式 1.0 では「AES」を使用していましたが、現在のコードでは常に「AES256」を使用します。" 11685 11686#: ../../rst/user_guide/vault.rst:609 11687msgid "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``." 11688msgstr "データの暗号化に使用される vault ID ラベル (任意: ``vault-id-label``) は、``--vault-id dev@prompt`` でファイルを暗号化する場合、vault-id-label が ``dev`` になります。" 11689 11690#: ../../rst/user_guide/vault.rst:611 11691msgid "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." 11692msgstr "注: 将来的には、ヘッダーが変更する可能性があります。形式 ID と形式バージョンの後のフィールドは、形式のバージョンに依存しており、将来の Vault 形式のバージョンでは、暗号アルゴリズムのオプションやフィールドが追加される可能性があります。" 11693 11694#: ../../rst/user_guide/vault.rst:613 11695msgid "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." 11696msgstr "ファイルの残りの内容は「vaulttext」です。vaulttext は、暗号化された暗号文のテキスト装甲版です。各行の幅は 80 文字です。ただし、最終行は短くなる場合があります。" 11697 11698#: ../../rst/user_guide/vault.rst:617 11699msgid "Ansible Vault payload format 1.1 - 1.2" 11700msgstr "Ansible Vault ペイロード形式 1.1-1.2" 11701 11702#: ../../rst/user_guide/vault.rst:619 11703msgid "The vaulttext is a concatenation of the ciphertext and a SHA256 digest with the result 'hexlifyied'." 11704msgstr "vault テキストは、暗号化テキストと SHA256 ダイジェストを連結したもので、結果は「hexlifyied」です。" 11705 11706#: ../../rst/user_guide/vault.rst:621 11707msgid "'hexlify' refers to the ``hexlify()`` method of the Python Standard Library's `binascii <https://docs.python.org/3/library/binascii.html>`_ module." 11708msgstr "「hexlify」は、Python 標準ライブラリーの `binascii <https://docs.python.org/3/library/binascii.html>`_ モジュールの ``hexlify()`` メソッドを指します。" 11709 11710#: ../../rst/user_guide/vault.rst:623 11711msgid "hexlify()'ed result of:" 11712msgstr "hexlify() が行われた結果:" 11713 11714#: ../../rst/user_guide/vault.rst:625 11715msgid "hexlify()'ed string of the salt, followed by a newline (``0x0a``)" 11716msgstr "hexlify() で編集されたソルトの文字列とそれに続く改行 (``0x0a``)。" 11717 11718#: ../../rst/user_guide/vault.rst:626 11719msgid "hexlify()'ed string of the crypted HMAC, followed by a newline. The HMAC is:" 11720msgstr "hexlify() で暗号化された HMAC の文字列の後に、改行を入れます。その HMAC は以下のようになります。" 11721 11722#: ../../rst/user_guide/vault.rst:628 11723msgid "a `RFC2104 <https://www.ietf.org/rfc/rfc2104.txt>`_ style HMAC" 11724msgstr "`RFC2104 <https://www.ietf.org/rfc/rfc2104.txt>`_ スタイルの HMAC" 11725 11726#: ../../rst/user_guide/vault.rst:630 11727msgid "inputs are:" 11728msgstr "入力は次のとおりです。" 11729 11730#: ../../rst/user_guide/vault.rst:632 11731msgid "The AES256 encrypted ciphertext" 11732msgstr "AES256 で暗号化した暗号文" 11733 11734#: ../../rst/user_guide/vault.rst:633 11735msgid "A PBKDF2 key. This key, the cipher key, and the cipher IV are generated from:" 11736msgstr "PBKDF2 キー。このキー、暗号キー、および暗号 IV を生成します。" 11737 11738#: ../../rst/user_guide/vault.rst:635 11739msgid "the salt, in bytes" 11740msgstr "バイト単位のソルト" 11741 11742#: ../../rst/user_guide/vault.rst:636 11743msgid "10000 iterations" 11744msgstr "10000 回の繰り返し" 11745 11746#: ../../rst/user_guide/vault.rst:637 11747msgid "SHA256() algorithm" 11748msgstr "SHA256() アルゴリズム" 11749 11750#: ../../rst/user_guide/vault.rst:638 11751msgid "the first 32 bytes are the cipher key" 11752msgstr "最初の 32 バイトは暗号キーです。" 11753 11754#: ../../rst/user_guide/vault.rst:639 11755msgid "the second 32 bytes are the HMAC key" 11756msgstr "2 番目の 32 バイトは HMAC キーです。" 11757 11758#: ../../rst/user_guide/vault.rst:640 11759msgid "remaining 16 bytes are the cipher IV" 11760msgstr "残りの 16 バイトは暗号 IV です。" 11761 11762#: ../../rst/user_guide/vault.rst:642 11763msgid "hexlify()'ed string of the ciphertext. The ciphertext is:" 11764msgstr "暗号文の hexlify() が行われた文字列です。暗号文は以下のようになります。" 11765 11766#: ../../rst/user_guide/vault.rst:644 11767msgid "AES256 encrypted data. The data is encrypted using:" 11768msgstr "AES256 で暗号化されたデータです。データは次を使用して暗号化されます。" 11769 11770#: ../../rst/user_guide/vault.rst:646 11771msgid "AES-CTR stream cipher" 11772msgstr "AES-CTR ストリーム暗号" 11773 11774#: ../../rst/user_guide/vault.rst:647 11775msgid "cipher key" 11776msgstr "暗号鍵" 11777 11778#: ../../rst/user_guide/vault.rst:648 11779msgid "IV" 11780msgstr "IV" 11781 11782#: ../../rst/user_guide/vault.rst:649 11783msgid "a 128 bit counter block seeded from an integer IV" 11784msgstr "整数 IV から確認された 128 ビットカウンターブロック" 11785 11786#: ../../rst/user_guide/vault.rst:650 11787msgid "the plaintext" 11788msgstr "平文" 11789 11790#: ../../rst/user_guide/vault.rst:652 11791msgid "the original plaintext" 11792msgstr "元の平文" 11793 11794#: ../../rst/user_guide/vault.rst:653 11795msgid "padding up to the AES256 blocksize. (The data used for padding is based on `RFC5652 <https://tools.ietf.org/html/rfc5652#section-6.3>`_)" 11796msgstr "AES256 ブロックサイズまでのパディング (パディングに使用するデータは `RFC5652 <https://tools.ietf.org/html/rfc5652#section-6.3>`_ に基づいています)" 11797 11798#: ../../rst/user_guide/windows.rst:4 11799msgid "Windows Guides" 11800msgstr "Windows ガイド" 11801 11802#: ../../rst/user_guide/windows.rst:6 11803msgid "The following sections provide information on managing Windows hosts with Ansible." 11804msgstr "以下のセクションでは、Ansible を使用した Windows ホストの管理を説明します。" 11805 11806#: ../../rst/user_guide/windows.rst:9 11807msgid "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." 11808msgstr "Windows は POSIX に準拠していない OS であるため、Ansible の動作方法と Windows の動作方法には違いがあります。このガイドでは、Linux/Unix ホストと Windows を実行するホストの違いを紹介します。" 11809 11810#: ../../rst/user_guide/windows_dsc.rst:2 11811msgid "Desired State Configuration" 11812msgstr "Desired State Configuration" 11813 11814#: ../../rst/user_guide/windows_dsc.rst:8 11815msgid "What is Desired State Configuration?" 11816msgstr "Desired State Configuration とは" 11817 11818#: ../../rst/user_guide/windows_dsc.rst:9 11819msgid "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 leverage existing DSC resources when interacting with a Windows host." 11820msgstr "Desired State Configuration (DSC) は、PowerShell に組み込まれたツールで、コードによって Windows ホストのセットアップを定義するために使用することができます。DSC の全体的な目的は Ansible と同じですが、実行方法が異なるだけです。Ansible 2.4 からは、``win_dsc`` モジュールが追加され、Windows ホストとのやりとりの際に、既存の DSC リソースを活用することができます。" 11821 11822#: ../../rst/user_guide/windows_dsc.rst:15 11823msgid "More details on DSC can be viewed at `DSC Overview <https://docs.microsoft.com/en-us/powershell/scripting/dsc/overview/overview>`_." 11824msgstr "DSC の詳細は「`DSC Overview <https://docs.microsoft.com/en-us/powershell/scripting/dsc/overview/overview>`_」を参照してください。" 11825 11826#: ../../rst/user_guide/windows_dsc.rst:18 11827#: ../../rst/user_guide/windows_setup.rst:11 11828msgid "Host Requirements" 11829msgstr "ホスト要件" 11830 11831#: ../../rst/user_guide/windows_dsc.rst:19 11832msgid "To use the ``win_dsc`` module, a Windows host must have PowerShell v5.0 or newer installed. All supported hosts, except for Windows Server 2008 (non R2) can be upgraded to PowerShell v5." 11833msgstr "``win_dsc`` モジュールを使用するには、Windows ホストに PowerShell v5.0 以降がインストールされている必要があります。Windows Server 2008 (R2 以外) を除くすべてのサポート対象ホストは、PowerShell v5.0 にアップグレードすることができます。" 11834 11835#: ../../rst/user_guide/windows_dsc.rst:23 11836msgid "Once the PowerShell requirements have been met, using DSC is as simple as creating a task with the ``win_dsc`` module." 11837msgstr "PowerShell の要件を満たしていれば、DSC を使用することは、``win_dsc`` モジュールでタスクを作成するのと同じぐらい簡単です。" 11838 11839#: ../../rst/user_guide/windows_dsc.rst:27 11840msgid "Why Use DSC?" 11841msgstr "DSC を使用する理由" 11842 11843#: ../../rst/user_guide/windows_dsc.rst:28 11844msgid "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." 11845msgstr "DSC と Ansible モジュールには、リソースの状態を定義して保証するという共通の目的があります。このため、DSC `ファイルリソース <https://docs.microsoft.com/en-us/powershell/scripting/dsc/reference/resources/windows/fileresource>`_ や Ansible``win_file`` のようなリソースを使用して、同じ結果を得ることができます。どちらを使用するかは、シナリオによって異なります。" 11846 11847#: ../../rst/user_guide/windows_dsc.rst:34 11848msgid "Reasons for using an Ansible module over a DSC resource:" 11849msgstr "DSC リソースで Ansible モジュールを使用する理由:" 11850 11851#: ../../rst/user_guide/windows_dsc.rst:36 11852msgid "The host does not support PowerShell v5.0, or it cannot easily be upgraded" 11853msgstr "ホストが PowerShell v5.0 をサポートしていない、または簡単にアップグレードできない。" 11854 11855#: ../../rst/user_guide/windows_dsc.rst:37 11856msgid "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" 11857msgstr "DSC リソースは、Ansible モジュールに存在する機能を提供しません。たとえば、win_regedit は ``REG_NONE`` のプロパティータイプを管理できますが、DSC ``Registry`` リソースではできません。" 11858 11859#: ../../rst/user_guide/windows_dsc.rst:40 11860msgid "DSC resources have limited check mode support, while some Ansible modules have better checks" 11861msgstr "DSC のリソースは確認モードのサポートが限られているが、Ansible モジュールの中にはより優れたチェック機能を持つものがある" 11862 11863#: ../../rst/user_guide/windows_dsc.rst:42 11864msgid "DSC resources do not support diff mode, while some Ansible modules do" 11865msgstr "DSC リソースでは差分モードがサポートされないが、一部の Ansible モジュールではサポートされる。" 11866 11867#: ../../rst/user_guide/windows_dsc.rst:43 11868msgid "Custom resources require further installation steps to be run on the host beforehand, while Ansible modules are built-in to Ansible" 11869msgstr "カスタムリソースでは、事前にホスト上で追加のインストール手順を実行する必要がありますが、Ansible モジュールは Ansible に組み込まれています。" 11870 11871#: ../../rst/user_guide/windows_dsc.rst:45 11872msgid "There are bugs in a DSC resource where an Ansible module works" 11873msgstr "Ansible モジュールが機能する DSC リソースにバグがある。" 11874 11875#: ../../rst/user_guide/windows_dsc.rst:47 11876msgid "Reasons for using a DSC resource over an Ansible module:" 11877msgstr "Ansible モジュールで DSC リソースを使用する理由:" 11878 11879#: ../../rst/user_guide/windows_dsc.rst:49 11880msgid "The Ansible module does not support a feature present in a DSC resource" 11881msgstr "Ansible モジュールは、DSC リソースに存在する機能をサポートしません。" 11882 11883#: ../../rst/user_guide/windows_dsc.rst:50 11884msgid "There is no Ansible module available" 11885msgstr "利用可能な Ansible モジュールはありません。" 11886 11887#: ../../rst/user_guide/windows_dsc.rst:51 11888msgid "There are bugs in an existing Ansible module" 11889msgstr "既存の Ansible モジュールにバグがある。" 11890 11891#: ../../rst/user_guide/windows_dsc.rst:53 11892msgid "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." 11893msgstr "つまるところ、タスクが DSC で実行されるか Ansible モジュールで実行されるかは重要ではありません。重要なのは、タスクが正しく実行され、Playbook が読めることです。Ansible よりも DSC の方を使用した経験があり、それで問題が解決するのであれば、そのタスクには DSC を使用すると良いでしょう。" 11894 11895#: ../../rst/user_guide/windows_dsc.rst:59 11896msgid "How to Use DSC?" 11897msgstr "DSC の使用方法" 11898 11899#: ../../rst/user_guide/windows_dsc.rst:60 11900msgid "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>`_." 11901msgstr "``win_dsc`` モジュールは、管理しているリソースに応じて変化するように、自由形式のオプションを取り入れています。組み込まれているリソースのリストは「`リソース <https://docs.microsoft.com/en-us/powershell/scripting/dsc/resources/resources>`_」を参照してください。" 11902 11903#: ../../rst/user_guide/windows_dsc.rst:64 11904msgid "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:" 11905msgstr "`Registry <https://docs.microsoft.com/en-us/powershell/scripting/dsc/reference/resources/windows/registryresource>`_ リソースを例にとると、これは Microsoft が文書化したDSCの定義です。" 11906 11907#: ../../rst/user_guide/windows_dsc.rst:81 11908msgid "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." 11909msgstr "タスクを定義する際には、使用する DSC リソースを ``resource_name`` に設定する必要があります。この場合、``resource_name`` は ``Registry`` に設定する必要があります。``module_version`` はインストールされている DSC リソースの特定のバージョンを参照することができますが、空白にするとデフォルトで最新のバージョンになります。その他のオプションは ``Key`` や ``ValueName`` のようにリソースを定義するためのパラメーターになります。タスクのオプションは大文字小文字を区別しませんが、DSC リソースのオプションと Ansible の``win_dsc`` のオプションを区別しやすくするために、大文字小文字をそのままにしておくことが推奨されます。" 11910 11911#: ../../rst/user_guide/windows_dsc.rst:90 11912msgid "This is what the Ansible task version of the above DSC Registry resource would look like:" 11913msgstr "上記の DSC レジストリーリソースの Ansible タスクバージョンは、以下のようになります。" 11914 11915#: ../../rst/user_guide/windows_dsc.rst:102 11916msgid "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:" 11917msgstr "Ansible 2.8 より、``win_dsc`` モジュールは、Ansible からの入力オプションを DSC 定義で自動的に検証します。つまり、オプション名が間違っていたり、必須オプションが設定されていなかったり、値が有効な選択肢でなかったりすると、Ansible は失敗します。Ansible を冗長レベル 3 以上 (``-vvv``) で実行した場合、戻り値には、指定された ``resource_name`` に基づいて可能な呼び出しオプションが含まれます。以下は、上記の ``Registry`` タスクの呼び出し出力の例です。" 11918 11919#: ../../rst/user_guide/windows_dsc.rst:157 11920msgid "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." 11921msgstr "``invocation.module_args`` キーは、設定された実際の値と、設定されなかった他の可能な値を表示します。残念ながら DSC プロパティーのデフォルト値は表示されず、Ansible タスクで設定された値のみが表示されます。``*_password`` オプションは、セキュリティー上の理由から出力ではマスクされます。他に機密性の高いモジュールオプションがある場合は、タスクに ``no_log: True`` を設定して、すべてのタスク出力がログに記録されないようにしてください。" 11922 11923#: ../../rst/user_guide/windows_dsc.rst:166 11924msgid "Property Types" 11925msgstr "プロパティータイプ" 11926 11927#: ../../rst/user_guide/windows_dsc.rst:167 11928msgid "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[]]``) this require certain rules." 11929msgstr "各 DSC リソースプロパティーには、それに関連付けられたタイプがあります。Ansible は、実行時に定義されたオプションを正しい型に変換しようとします。``[string]`` や ``[bool]`` のような単純な型では、これは単純な操作ですが、``[PSCredential]`` や配列 (``[string[]]`` など) のような複雑な型では、特定のルールが必要です。" 11930 11931#: ../../rst/user_guide/windows_dsc.rst:174 11932msgid "PSCredential" 11933msgstr "PSCredential" 11934 11935#: ../../rst/user_guide/windows_dsc.rst:175 11936msgid "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:" 11937msgstr "``[PSCredential]`` オブジェクトは認証情報を安全な方法で保存するために使用されますが、Ansible にはこれを JSON でシリアル化する方法がありません。DSC PSCredential プロパティーを設定するには、そのパラメーターの定義に、ユーザ名とパスワードをそれぞれ ``_username`` と``_password`` をサフィックスにした 2 つのエントリーを追加する必要があります。たとえば、以下のようになります。" 11938 11939#: ../../rst/user_guide/windows_dsc.rst:189 11940msgid "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." 11941msgstr "2.8 より古いバージョンの Ansible では、Ansible のタスク定義に ``no_log: yes`` を設定して、使用する認証情報がログファイルまたはコンソールの出力に保存されないようにする必要があります。" 11942 11943#: ../../rst/user_guide/windows_dsc.rst:193 11944msgid "A ``[PSCredential]`` is defined with ``EmbeddedInstance(\"MSFT_Credential\")`` in a DSC resource MOF definition." 11945msgstr "``[PSCredential]`` は、DSC リソースの MOF 定義において``EmbeddedInstance(\"MSFT_Credential\")`` と共に定義されます。" 11946 11947#: ../../rst/user_guide/windows_dsc.rst:197 11948msgid "CimInstance Type" 11949msgstr "CimInstance タイプ" 11950 11951#: ../../rst/user_guide/windows_dsc.rst:198 11952msgid "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:" 11953msgstr "``[CimInstance]`` オブジェクトは、DSC がそのリソースで定義されたカスタムクラスに基づいてディクショナリーオブジェクトを格納するために使用されます。``[CimInstance]`` を取り込む値を YAML で定義することは、YAML でディクショナリーを定義することと同じです。たとえば、Ansible で``[CimInstance]`` の値を定義する場合は、以下のようになります。" 11954 11955#: ../../rst/user_guide/windows_dsc.rst:212 11956msgid "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``." 11957msgstr "上記の例では、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`` にあります。" 11958 11959#: ../../rst/user_guide/windows_dsc.rst:221 11960msgid "HashTable Type" 11961msgstr "HashTable タイプ" 11962 11963#: ../../rst/user_guide/windows_dsc.rst:222 11964msgid "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 like a normal dictionary value in YAML. A ``[HashTable]]`` is defined with ``EmbeddedInstance(\"MSFT_KeyValuePair\")`` in a DSC resource MOF definition." 11965msgstr "``[HashTable]`` オブジェクトもディクショナリーですが、定義できる/しなければならない厳密な鍵のセットを持っていません。``[CimInstance]`` のように、YAML で通常のディクショナリー値のように定義します。``[HashTable]]`` は、DSC リソースの MOF 定義において ``EmbeddedInstance(\"MSFT_KeyValuePair\")`` と共に定義されます。" 11966 11967#: ../../rst/user_guide/windows_dsc.rst:228 11968msgid "Arrays" 11969msgstr "配列" 11970 11971#: ../../rst/user_guide/windows_dsc.rst:229 11972msgid "Simple type arrays like ``[string[]]`` or ``[UInt32[]]`` are defined as a list or as a comma separated string which are 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:" 11973msgstr "``[string[]]`` や ``[UInt32[]]`` のような単純な型の配列は、リストまたはカンマ区切りの文字列として定義され、それらが型にキャストされます。リストを使用すると、DSC エンジンに渡す前に ``win_dsc`` モジュールで値が手動で解析されないため、推奨されます。たとえば、Ansible で単純な型の配列を定義するには、次のようにします。" 11974 11975#: ../../rst/user_guide/windows_dsc.rst:250 11976msgid "Complex type arrays like ``[CimInstance[]]`` (array of dicts), can be defined like this example:" 11977msgstr "``[CimInstance[]]`` (ディクショナリーの配列) のような複雑な型の配列は、次の例のように定義できます。" 11978 11979#: ../../rst/user_guide/windows_dsc.rst:268 11980msgid "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." 11981msgstr "上記の例は、`MSFT_xWebBindingInformation <https://github.com/dsccommunity/xWebAdministration/blob/master/source/DSCResources/MSFT_xWebSite/MSFT_xWebSite.schema.mof>`_ クラスの 2 つの値のある配列です。``[CimInstance[]]`` を定義すると、リソースドキュメントを参照して、定義で使用するキーを確認してください。" 11982 11983#: ../../rst/user_guide/windows_dsc.rst:273 11984msgid "DateTime" 11985msgstr "日時" 11986 11987#: ../../rst/user_guide/windows_dsc.rst:274 11988msgid "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:" 11989msgstr "``[DateTime]`` オブジェクトは、`ISO 8601 <https://www.w3.org/TR/NOTE-datetime>`_ の日付時間フォーマットで日付と時間を表す DateTime 文字列です。``[DateTime]`` フィールドの値は、文字列が Windows ホストに適切にシリアライズされるように、YAML で引用する必要があります。以下は、Ansible で``[DateTime]`` の値を定義する方法の例です。" 11990 11991#: ../../rst/user_guide/windows_dsc.rst:291 11992msgid "All the values above are equal to a UTC date time of February 22nd 2019 at 1:57pm with 31 seconds and 2311892 milliseconds." 11993msgstr "上記のすべての値は、UTCの 日付時刻が 2019 年 2 月 22 日午後 1 時 57 分 31秒 2311892 ミリ秒であることと同じです。" 11994 11995#: ../../rst/user_guide/windows_dsc.rst:295 11996msgid "Run As Another User" 11997msgstr "別のユーザーとして実行" 11998 11999#: ../../rst/user_guide/windows_dsc.rst:296 12000msgid "By default, DSC runs each resource as the SYSTEM account and not the account that Ansible use 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 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." 12001msgstr "デフォルトでは、DSC は各リソースを、Ansible がモジュールの実行に使用するアカウントではなく、SYSTEM アカウントとして実行します。つまり、``HKEY_CURRENT_USER`` のレジストリーハイブのように、ユーザープロファイルに基づいて動的に読み込まれるリソースは、``SYSTEM`` のプロファイルで読み込まれます。``PsDscRunAsCredential`` は、DSC エンジンが別のアカウントで実行されるように、すべての DSC リソースに設定することができるパラメーターです。``PsDscRunAsCredential`` はタイプが ``PSCredential`` なので、``_username`` と``_password`` というサフィックスで定義されています。" 12002 12003#: ../../rst/user_guide/windows_dsc.rst:305 12004msgid "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:" 12005msgstr "レジストリーリソースタイプを例として使用し、Ansible ユーザーの ``HKEY_CURRENT_USER`` ハイブにアクセスするタスクを定義する方法を説明します。" 12006 12007#: ../../rst/user_guide/windows_dsc.rst:322 12008msgid "Custom DSC Resources" 12009msgstr "カスタムの DSC リソース" 12010 12011#: ../../rst/user_guide/windows_dsc.rst:323 12012msgid "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." 12013msgstr "DSC のリソースは、Microsoft の組み込みオプションに限定されません。カスタムモジュールをインストールすることで、通常では利用できない他のリソースを管理することができます。" 12014 12015#: ../../rst/user_guide/windows_dsc.rst:327 12016msgid "Finding Custom DSC Resources" 12017msgstr "カスタムの DSC リソースの見つけ方" 12018 12019#: ../../rst/user_guide/windows_dsc.rst:328 12020msgid "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." 12021msgstr "`PSGallery <https://www.powershellgallery.com/>`_ を使用すると、カスタムリソースと、それを Windows ホストにインストールする方法に関するドキュメントを見つけることができます。" 12022 12023#: ../../rst/user_guide/windows_dsc.rst:331 12024msgid "The ``Find-DscResource`` cmdlet can also be used to find custom resources. For example:" 12025msgstr "``Find-DscResource`` コマンドレットを使用して、カスタムリソースを検索することもできます。以下に例を示します。" 12026 12027#: ../../rst/user_guide/windows_dsc.rst:341 12028msgid "DSC resources developed by Microsoft that start with ``x``, means the resource is experimental and comes with no support." 12029msgstr "Microsoft が開発した DSC リソースで、``x`` で始まるものは、実験的なリソースであり、サポートがないことを意味しています。" 12030 12031#: ../../rst/user_guide/windows_dsc.rst:345 12032msgid "Installing a Custom Resource" 12033msgstr "カスタムリソースのインストール" 12034 12035#: ../../rst/user_guide/windows_dsc.rst:346 12036msgid "There are three ways that a DSC resource can be installed on a host:" 12037msgstr "DSC リソースをホストにインストールする方法は 3 つあります。" 12038 12039#: ../../rst/user_guide/windows_dsc.rst:348 12040msgid "Manually with the ``Install-Module`` cmdlet" 12041msgstr "``Install-Module`` コマンドレットを手動で使用" 12042 12043#: ../../rst/user_guide/windows_dsc.rst:349 12044msgid "Using the ``win_psmodule`` Ansible module" 12045msgstr "Ansibleモジュール ``win_psmodule`` を使用" 12046 12047#: ../../rst/user_guide/windows_dsc.rst:350 12048msgid "Saving the module manually and copying it another host" 12049msgstr "モジュールを手動で保存して別のホストにコピー" 12050 12051#: ../../rst/user_guide/windows_dsc.rst:352 12052msgid "This is an example of installing the ``xWebAdministration`` resources using ``win_psmodule``:" 12053msgstr "これは、``win_psmodule`` を使用して ``xWebAdministration`` リソースをインストールする例です。" 12054 12055#: ../../rst/user_guide/windows_dsc.rst:362 12056msgid "Once installed, the win_dsc module will be able to use the resource by referencing it with the ``resource_name`` option." 12057msgstr "インストールすると、win_dsc モジュールは、``resource_name`` オプションでリソースを参照することで、リソースを使用できるようになります。" 12058 12059#: ../../rst/user_guide/windows_dsc.rst:365 12060msgid "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::" 12061msgstr "上記の最初の 2 つの方法は、ホストがインターネットにアクセスできる場合にのみ機能します。ホストがインターネットにアクセスできない場合は、まずインターネットにアクセスできる別のホスト上で上記の方法を使用してモジュールをインストールし、それをコピーする必要があります。モジュールをローカルのファイルパスに保存するには、次の PowerShell コマンドレットを実行します。" 12062 12063#: ../../rst/user_guide/windows_dsc.rst:373 12064msgid "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." 12065msgstr "これにより、``C:\\temp`` の中に``xWebAdministration`` というフォルダーが作成され、どのホストにもコピーできるようになります。PowerShell がこのオフラインリソースを見るためには、環境変数 ``PSModulePath`` で設定されたディレクトリーにコピーされている必要があります。ほとんどの場合、この変数を通じてパス ``C:\\Program Files\\WindowsPowerShell\\Module`` が設定されますが、``win_path`` モジュールを使用して異なるパスを追加することができます。" 12066 12067#: ../../rst/user_guide/windows_dsc.rst:381 12068msgid "Examples" 12069msgstr "例" 12070 12071#: ../../rst/user_guide/windows_dsc.rst:383 12072msgid "Extract a zip file" 12073msgstr "zip ファイルの展開" 12074 12075#: ../../rst/user_guide/windows_dsc.rst:395 12076msgid "Create a directory" 12077msgstr "ディレクトリーの作成" 12078 12079#: ../../rst/user_guide/windows_dsc.rst:418 12080msgid "Interact with Azure" 12081msgstr "Azure の操作" 12082 12083#: ../../rst/user_guide/windows_dsc.rst:441 12084msgid "Setup IIS Website" 12085msgstr "IIS Web サイトのセットアップ" 12086 12087#: ../../rst/user_guide/windows_dsc.rst:500 12088#: ../../rst/user_guide/windows_setup.rst:571 12089#: ../../rst/user_guide/windows_usage.rst:508 12090#: ../../rst/user_guide/windows_winrm.rst:909 12091msgid ":ref:`List of Windows Modules <windows_modules>`" 12092msgstr ":ref:`List of Windows Modules <windows_modules>`" 12093 12094#: ../../rst/user_guide/windows_dsc.rst:501 12095#: ../../rst/user_guide/windows_setup.rst:572 12096#: ../../rst/user_guide/windows_usage.rst:509 12097#: ../../rst/user_guide/windows_winrm.rst:910 12098msgid "Windows specific module list, all implemented in PowerShell" 12099msgstr "Windows 固有のモジュールリスト (すべて PowerShell に実装)" 12100 12101#: ../../rst/user_guide/windows_faq.rst:4 12102msgid "Windows Frequently Asked Questions" 12103msgstr "Windows に関するよくある質問 (FAQ)" 12104 12105#: ../../rst/user_guide/windows_faq.rst:6 12106msgid "Here are some commonly asked questions in regards to Ansible and Windows and their answers." 12107msgstr "ここでは、Ansible および Windows に関するよくある質問とその回答を紹介します。" 12108 12109#: ../../rst/user_guide/windows_faq.rst:9 12110msgid "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>`." 12111msgstr "本ガイドでは、Ansible を使用した Microsoft Windows サーバーの管理に関する質問について説明します。Ansible Core に関する質問は、「:ref:`一般的な FAQ ページ <ansible_faq>`」を参照してください。" 12112 12113#: ../../rst/user_guide/windows_faq.rst:14 12114msgid "Does Ansible work with Windows XP or Server 2003?" 12115msgstr "Ansible は、Windows XP または Server 2003 で動作しますか" 12116 12117#: ../../rst/user_guide/windows_faq.rst:15 12118msgid "Ansible does not work with Windows XP or Server 2003 hosts. Ansible does work with these Windows operating system versions:" 12119msgstr "Ansible は、Windows XP または Server 2003 ホストでは動作しません。Ansible は、以下の Windows オペレーティングシステムバージョンで動作します。" 12120 12121#: ../../rst/user_guide/windows_faq.rst:17 12122msgid "Windows Server 2008 :sup:`1`" 12123msgstr "Windows Server 2008 :sup:`1`" 12124 12125#: ../../rst/user_guide/windows_faq.rst:18 12126msgid "Windows Server 2008 R2 :sup:`1`" 12127msgstr "Windows Server 2008 R2 :sup:`1`" 12128 12129#: ../../rst/user_guide/windows_faq.rst:19 12130msgid "Windows Server 2012" 12131msgstr "Windows Server 2012" 12132 12133#: ../../rst/user_guide/windows_faq.rst:20 12134msgid "Windows Server 2012 R2" 12135msgstr "Windows Server 2012 R2" 12136 12137#: ../../rst/user_guide/windows_faq.rst:21 12138msgid "Windows Server 2016" 12139msgstr "Windows Server 2016" 12140 12141#: ../../rst/user_guide/windows_faq.rst:22 12142msgid "Windows Server 2019" 12143msgstr "Windows Server 2019" 12144 12145#: ../../rst/user_guide/windows_faq.rst:23 12146msgid "Windows 7 :sup:`1`" 12147msgstr "Windows 7 :sup:`1`" 12148 12149#: ../../rst/user_guide/windows_faq.rst:24 12150msgid "Windows 8.1" 12151msgstr "Windows 8.1" 12152 12153#: ../../rst/user_guide/windows_faq.rst:25 12154msgid "Windows 10" 12155msgstr "Windows 10" 12156 12157#: ../../rst/user_guide/windows_faq.rst:27 12158msgid "1 - See the :ref:`Server 2008 FAQ <windows_faq_server2008>` entry for more details." 12159msgstr "1 - 詳細は、:ref:`Server 2008 FAQ <windows_faq_server2008>` のエントリーを参照してください。" 12160 12161#: ../../rst/user_guide/windows_faq.rst:29 12162msgid "Ansible also has minimum PowerShell version requirements - please see :ref:`windows_setup` for the latest information." 12163msgstr "また、Ansible には PowerShell の最小バージョン要件があります。最新情報は「:ref:`windows_setup`」を参照してください。" 12164 12165#: ../../rst/user_guide/windows_faq.rst:35 12166msgid "Are Server 2008, 2008 R2 and Windows 7 supported?" 12167msgstr "Server 2008、2008 R2、Windows 7 に対応していますか" 12168 12169#: ../../rst/user_guide/windows_faq.rst:36 12170msgid "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." 12171msgstr "Microsoft は 2020 年 1 月 14 日にこれらのバージョンの Windows の Extended Support を終了し、Ansible は 2.10 のリリースで公式サポートを廃止しました。これらのオペレーティングシステムを対象とした新機能の開発は行われず、自動テストも終了しています。しかし、既存のモジュールや機能は引き続き動作する可能性があり、これらの Windows バージョンに関する問題を解決するための簡単なプル要求は承認される可能性があります。" 12172 12173#: ../../rst/user_guide/windows_faq.rst:39 12174msgid "Can I manage Windows Nano Server with Ansible?" 12175msgstr "Ansible で Windows Nano Server を管理できますか" 12176 12177#: ../../rst/user_guide/windows_faq.rst:40 12178msgid "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." 12179msgstr "Ansible は現在、Windows Nano Server では動作しません。これは、大部分のモジュールや内部コンポーネントで使用されている完全な .NET フレームワークにアクセスできないためです。" 12180 12181#: ../../rst/user_guide/windows_faq.rst:45 12182msgid "Can Ansible run on Windows?" 12183msgstr "Ansible は Windows で実行できますか" 12184 12185#: ../../rst/user_guide/windows_faq.rst:46 12186msgid "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)." 12187msgstr "いいえ、Ansible は Windows ホストのみを管理できます。Ansible は Windows ホスト上ではネイティブに実行できませんが、Windows Subsystem for Linux (WSL) の下で実行できます。" 12188 12189#: ../../rst/user_guide/windows_faq.rst:49 12190msgid "The Windows Subsystem for Linux is not supported by Ansible and should not be used for production systems." 12191msgstr "Windows Subsystem for Linux は Ansible ではサポートされていないため、実稼働システムには使用しないでください。" 12192 12193#: ../../rst/user_guide/windows_faq.rst:52 12194msgid "To install Ansible on WSL, the following commands can be run in the bash terminal:" 12195msgstr "WSL に Ansible をインストールするには、bash ターミナルで以下のコマンドを実行します。" 12196 12197#: ../../rst/user_guide/windows_faq.rst:61 12198msgid "To run Ansible from source instead of a release on the WSL, simply uninstall the pip installed version and then clone the git repo." 12199msgstr "WSL のリリースではなくソースから Ansible を実行するには、インストールした pip をアンインストールし、git リポジトリーのクローンを作成します。" 12200 12201#: ../../rst/user_guide/windows_faq.rst:73 12202msgid "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:" 12203msgstr "WSL 上で Ansible を実行したときにタイムアウトエラーが発生する場合は、``sleep`` が正しく返されない問題が原因となる可能性があります。以下の回避策により、この問題が解決される場合があります。" 12204 12205#: ../../rst/user_guide/windows_faq.rst:81 12206msgid "Another option is to use WSL 2 if running Windows 10 later than build 2004." 12207msgstr "別のオプションとして、ビルド 2004 よりも Windows 10 以上を実行している場合は WSL 2 を使用します。" 12208 12209#: ../../rst/user_guide/windows_faq.rst:89 12210msgid "Can I use SSH keys to authenticate to Windows hosts?" 12211msgstr "SSH キーを使用して Windows ホストへの認証を行うことはできますか" 12212 12213#: ../../rst/user_guide/windows_faq.rst:90 12214msgid "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." 12215msgstr "WinRM または PSRP 接続プラグインで SSH 鍵を使用することはできません。これらの接続プラグインは、SSH が使用する SSH キーペアの代わりに、認証に X509 証明書を使用します。" 12216 12217#: ../../rst/user_guide/windows_faq.rst:94 12218msgid "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." 12219msgstr "X509 証明書が生成され、ユーザーにマッピングされる方法は、SSH の実装とは異なります。詳細は、:ref:`windows_winrm` のドキュメントを参照してください。" 12220 12221#: ../../rst/user_guide/windows_faq.rst:98 12222msgid "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." 12223msgstr "Ansible 2.8 には、認証に SSH 鍵を使用する SSH 接続プラグインを Windows サーバーで使用する実験的なオプションが追加されました。詳細は「:ref:`this question <windows_faq_ssh>`」を参照してください。" 12224 12225#: ../../rst/user_guide/windows_faq.rst:105 12226msgid "Why can I run a command locally that does not work under Ansible?" 12227msgstr "Ansible で機能しないコマンドをローカルで実行できるのはなぜですか" 12228 12229#: ../../rst/user_guide/windows_faq.rst:106 12230msgid "Ansible executes commands through WinRM. These processes are different from running a command locally in these ways:" 12231msgstr "Ansible は、WinRM を介してコマンドを実行します。これらのプロセスは、以下の方法でローカルでコマンドを実行するのとは異なります。" 12232 12233#: ../../rst/user_guide/windows_faq.rst:109 12234msgid "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." 12235msgstr "CredSSP や Kerberos のような認証オプションを使用して、認証情報の委譲を行っていない限り、WinRM プロセスにはユーザーの認証情報をネットワークリソースに委譲する機能がなく、``Access is Denied`` エラーが発生します。" 12236 12237#: ../../rst/user_guide/windows_faq.rst:114 12238msgid "All processes run under WinRM are in a non-interactive session. Applications that require an interactive session will not work." 12239msgstr "WinRM で実行されるすべてのプロセスは、非対話型セッションです。対話型セッションを必要とするアプリケーションは機能しません。" 12240 12241#: ../../rst/user_guide/windows_faq.rst:117 12242msgid "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." 12243msgstr "WinRM を介して実行する場合、Windows は、一部のインストーラーやプログラムが依存している Windows Update API や DPAPI などの Windows 内部 API へのアクセスを制限します。" 12244 12245#: ../../rst/user_guide/windows_faq.rst:121 12246msgid "Some ways to bypass these restrictions are to:" 12247msgstr "これらの制限を回避する方法は次のとおりです。" 12248 12249#: ../../rst/user_guide/windows_faq.rst:123 12250msgid "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." 12251msgstr "``become`` を使用すると、ローカルで実行するときと同じようにコマンドを実行できます。``become`` を使用すると、Windows はプロセスが WinRM の下で実行されていることに気づかないため、ほとんどの WinRM の制限を回避することができます。詳細は、:ref:`become` のドキュメントを参照してください。" 12252 12253#: ../../rst/user_guide/windows_faq.rst:128 12254msgid "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." 12255msgstr "``win_scheduled_task`` で作成できる、スケジュールされたタスクを使用します。``become`` と同様に、WinRM の制限をすべて回避できますが、モジュールではなくコマンドの実行にのみ使用できます。" 12256 12257#: ../../rst/user_guide/windows_faq.rst:132 12258msgid "Use ``win_psexec`` to run a command on the host. PSExec does not use WinRM and so will bypass any of the restrictions." 12259msgstr "``win_psexec`` を使用してホストでコマンドを実行します。PSExec は WinRM を使用しないため、あらゆる制限を回避することができます。" 12260 12261#: ../../rst/user_guide/windows_faq.rst:135 12262msgid "To access network resources without any of these workarounds, you can use CredSSP or Kerberos with credential delegation enabled." 12263msgstr "これらの回避策を取らずにネットワークリソースにアクセスするには、認証情報の委譲を有効にした CredSSP または Kerberos を使用することができます。" 12264 12265#: ../../rst/user_guide/windows_faq.rst:138 12266msgid "See :ref:`become` more info on how to use become. The limitations section at :ref:`windows_winrm` has more details around WinRM limitations." 12267msgstr "become の使用方法に関する詳細の詳細は、「:ref:`become`」を参照してください。:ref:`windows_winrm` の制限セクションには、WinRM 制限の詳細が記載されています。" 12268 12269#: ../../rst/user_guide/windows_faq.rst:142 12270msgid "This program won't install on Windows with Ansible" 12271msgstr "このプログラムが、Ansible がインストールされている Windows にはインストールされません" 12272 12273#: ../../rst/user_guide/windows_faq.rst:143 12274msgid "See :ref:`this question <windows_faq_winrm>` for more information about WinRM limitations." 12275msgstr "WinRMの制限の詳細は、「:ref:`こちらの質問 <windows_faq_winrm>`」を参照してください。" 12276 12277#: ../../rst/user_guide/windows_faq.rst:146 12278msgid "What Windows modules are available?" 12279msgstr "どのような Windows モジュールが利用できますか" 12280 12281#: ../../rst/user_guide/windows_faq.rst:147 12282msgid "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." 12283msgstr "Ansible Core の Ansible モジュールの多くは、Linux/Unix マシンと任意の Web サービスの組み合わせを想定して記述されます。これらのモジュールは Python で記述されており、そのほとんどが Windows では動作しません。" 12284 12285#: ../../rst/user_guide/windows_faq.rst:151 12286msgid "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>`." 12287msgstr "このため、PowerShell で記述されており、Windows ホストで実行することを目的としている専用の Windows モジュールがあります。これらのモジュールの一覧は、「:ref:`here <windows_modules>` 」にあります。" 12288 12289#: ../../rst/user_guide/windows_faq.rst:155 12290msgid "In addition, the following Ansible Core modules/action-plugins work with Windows:" 12291msgstr "次の Ansible Core モジュールおよびアクションプラグインは、Windows で動作します。" 12292 12293#: ../../rst/user_guide/windows_faq.rst:157 12294msgid "add_host" 12295msgstr "add_host" 12296 12297#: ../../rst/user_guide/windows_faq.rst:158 12298msgid "assert" 12299msgstr "assert" 12300 12301#: ../../rst/user_guide/windows_faq.rst:159 12302msgid "async_status" 12303msgstr "async_status" 12304 12305#: ../../rst/user_guide/windows_faq.rst:160 12306msgid "debug" 12307msgstr "debug" 12308 12309#: ../../rst/user_guide/windows_faq.rst:161 12310msgid "fail" 12311msgstr "fail" 12312 12313#: ../../rst/user_guide/windows_faq.rst:162 12314msgid "fetch" 12315msgstr "fetch" 12316 12317#: ../../rst/user_guide/windows_faq.rst:163 12318msgid "group_by" 12319msgstr "group_by" 12320 12321#: ../../rst/user_guide/windows_faq.rst:164 12322msgid "include" 12323msgstr "include" 12324 12325#: ../../rst/user_guide/windows_faq.rst:165 12326msgid "include_role" 12327msgstr "include_role" 12328 12329#: ../../rst/user_guide/windows_faq.rst:167 12330msgid "meta" 12331msgstr "meta" 12332 12333#: ../../rst/user_guide/windows_faq.rst:168 12334msgid "pause" 12335msgstr "pause" 12336 12337#: ../../rst/user_guide/windows_faq.rst:169 12338msgid "raw" 12339msgstr "raw" 12340 12341#: ../../rst/user_guide/windows_faq.rst:170 12342msgid "script" 12343msgstr "script" 12344 12345#: ../../rst/user_guide/windows_faq.rst:171 12346msgid "set_fact" 12347msgstr "set_fact" 12348 12349#: ../../rst/user_guide/windows_faq.rst:172 12350msgid "set_stats" 12351msgstr "set_stats" 12352 12353#: ../../rst/user_guide/windows_faq.rst:173 12354msgid "setup" 12355msgstr "setup" 12356 12357#: ../../rst/user_guide/windows_faq.rst:174 12358msgid "slurp" 12359msgstr "slurp" 12360 12361#: ../../rst/user_guide/windows_faq.rst:175 12362msgid "template (also: win_template)" 12363msgstr "template (win_template も同様)" 12364 12365#: ../../rst/user_guide/windows_faq.rst:176 12366msgid "wait_for_connection" 12367msgstr "wait_for_connection" 12368 12369#: ../../rst/user_guide/windows_faq.rst:179 12370msgid "Can I run Python modules on Windows hosts?" 12371msgstr "Windows ホストで Python モジュールを実行できますか" 12372 12373#: ../../rst/user_guide/windows_faq.rst:180 12374msgid "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." 12375msgstr "できません。WinRM 接続プロトコルは PowerShell モジュールを使用するように設定されているため、Python モジュールは動作しません。この問題を回避するには、``delegate_to: localhost`` を使用して Ansible コントローラー上で Python モジュールを実行する方法があります。これは、Playbook 中に外部サービスに接続する必要があり、同等の Windows モジュールがない場合に便利です。" 12376 12377#: ../../rst/user_guide/windows_faq.rst:189 12378msgid "Can I connect to Windows hosts over SSH?" 12379msgstr "SSH 経由で Windows ホストに接続できますか" 12380 12381#: ../../rst/user_guide/windows_faq.rst:190 12382msgid "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." 12383msgstr "Ansible 2.8 には、SSH 接続プラグインを使用して 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>`_ することが強く推奨されます。" 12384 12385#: ../../rst/user_guide/windows_faq.rst:199 12386msgid "To use SSH as the connection to a Windows host, set the following variables in the inventory::" 12387msgstr "Windows ホストへの接続に SSH を使用するには、インベントリーに以下の変数を設定します。" 12388 12389#: ../../rst/user_guide/windows_faq.rst:208 12390msgid "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``." 12391msgstr "``ansible_shell_type`` の値は、``cmd`` または ``powershell`` のいずれかでなければなりません。SSH サービスで ``DefaultShell`` が設定されていない場合は ``cmd`` を使用して、``DefaultShell`` として設定されている場合は ``powershell`` を使用してください。" 12392 12393#: ../../rst/user_guide/windows_faq.rst:213 12394msgid "Why is connecting to a Windows host via SSH failing?" 12395msgstr "SSH 経由で Windows ホストに接続できないのはなぜですか" 12396 12397#: ../../rst/user_guide/windows_faq.rst:214 12398msgid "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." 12399msgstr "上記のように ``Win32-OpenSSH`` を使用している場合を除き、Windows ホストへの接続には :ref:`windows_winrm` を使用する必要があります。Ansible の出力で SSH が使用されたと表示された場合は、接続バーが正しく設定されていないか、ホストに正しく継承されていません。" 12400 12401#: ../../rst/user_guide/windows_faq.rst:218 12402msgid "Make sure ``ansible_connection: winrm`` is set in the inventory for the Windows host(s)." 12403msgstr "Windows ホストのインベントリーに ``ansible_connection: winrm`` が設定されていることを確認してください。" 12404 12405#: ../../rst/user_guide/windows_faq.rst:222 12406msgid "Why are my credentials being rejected?" 12407msgstr "認証情報が拒否されるのはなぜですか" 12408 12409#: ../../rst/user_guide/windows_faq.rst:223 12410msgid "This can be due to a myriad of reasons unrelated to incorrect credentials." 12411msgstr "これは、誤った認証情報とは無関係の、多種多様なものが原因である可能性があります。" 12412 12413#: ../../rst/user_guide/windows_faq.rst:225 12414msgid "See HTTP 401/Credentials Rejected at :ref:`windows_setup` for a more detailed guide of this could mean." 12415msgstr "この現象の詳細については、:ref:`windows_setup` の「HTTP 401/認証情報の拒否」を参照してください。" 12416 12417#: ../../rst/user_guide/windows_faq.rst:229 12418msgid "Why am I getting an error SSL CERTIFICATE_VERIFY_FAILED?" 12419msgstr "SSL CERTIFICATE_VERIFY_FAILED エラーが発生するのはなぜですか" 12420 12421#: ../../rst/user_guide/windows_faq.rst:230 12422msgid "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." 12423msgstr "Ansible コントローラーが Python 2.7.9 以降または SSLContext をバックポートした古いバージョンの Python (RHEL 7 の Python 2.7.5 など) で動作している場合、コントローラーは WinRM が HTTPS 接続に使用している証明書を検証しようとします。証明書を検証できない場合 (自己署名証明書の場合など) は、検証プロセスに失敗します。" 12424 12425#: ../../rst/user_guide/windows_faq.rst:236 12426msgid "To ignore certificate validation, add ``ansible_winrm_server_cert_validation: ignore`` to inventory for the Windows host." 12427msgstr "証明書の検証を無視するには、Windows ホストのインベントリーに ``ansible_winrm_server_cert_validation: ignore`` を追加してください。" 12428 12429#: ../../rst/user_guide/windows_faq.rst:242 12430msgid ":ref:`windows`" 12431msgstr ":ref:`windows`" 12432 12433#: ../../rst/user_guide/windows_faq.rst:243 12434msgid "The Windows documentation index" 12435msgstr "Windows ドキュメントの目次" 12436 12437#: ../../rst/user_guide/windows_performance.rst:4 12438msgid "Windows performance" 12439msgstr "Windows パフォーマンス" 12440 12441#: ../../rst/user_guide/windows_performance.rst:5 12442msgid "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." 12443msgstr "本書では、特に Ansible をそのホストで使用する状況、および一般的に使用する状況で高速化するために、Windows ホストに適用するパフォーマンスの最適化をいくつか紹介します。" 12444 12445#: ../../rst/user_guide/windows_performance.rst:10 12446msgid "Optimise PowerShell performance to reduce Ansible task overhead" 12447msgstr "Ansible タスクのオーバーヘッドを軽減するための PowerShell のパフォーマンスの最適化" 12448 12449#: ../../rst/user_guide/windows_performance.rst:11 12450msgid "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." 12451msgstr "PowerShell の起動を約 10 倍高速化するには、Administrator セッションで以下の PowerShell スニペットを実行します。数十秒かかることが予想されます。" 12452 12453#: ../../rst/user_guide/windows_performance.rst:17 12454msgid "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)." 12455msgstr "ネイティブイメージが ngen タスクやサービスによってすでに作成されている場合は、パフォーマンスに違いはありません (ただし、このスニペットはその時点で他の場合よりも高速に実行されます)。" 12456 12457#: ../../rst/user_guide/windows_performance.rst:42 12458msgid "PowerShell is used by every Windows Ansible module. This optimisation reduces the time PowerShell takes to start up, removing that overhead from every invocation." 12459msgstr "PowerShell はすべての Windows Ansible モジュールによって使用されます。この最適化により、PowerShell の起動時間を短縮し、呼び出しごとにそのオーバーヘッドを取り除きます。" 12460 12461#: ../../rst/user_guide/windows_performance.rst:45 12462msgid "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." 12463msgstr "このスニペットは `ネイティブイメージジェネレーター ngen <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#WhenToUse>`_ を使用して、PowerShell が依存しているアセンブリーのネイティブイメージを事前に作成します。" 12464 12465#: ../../rst/user_guide/windows_performance.rst:49 12466msgid "Fix high-CPU-on-boot for VMs/cloud instances" 12467msgstr "仮想マシン/クラウドインスタンスの、システム起動時の高 CPU を修正" 12468 12469#: ../../rst/user_guide/windows_performance.rst:50 12470msgid "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." 12471msgstr "インスタンスを生成するためにゴールデンイメージを作成している場合は、ゴールデンイメージのビルドプロセスとランタイムの間で CPU タイプが変わらないことがわかっていれば、ゴールデンイメージの作成時に `ngen キューの処理 <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#native-image-service>`_ を使用することで、起動時に高い CPU タスクが発生するのを防ぐことができます。" 12472 12473#: ../../rst/user_guide/windows_performance.rst:55 12474msgid "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>`_)." 12475msgstr "Playbook の最後付近に以下を置き、ネイティブイメージが無効になる可能性のある要素に注意してください (`MSDN <https://docs.microsoft.com/en-us/dotnet/framework/tools/ngen-exe-native-image-generator#native-images-and-jit-compilation>`_ を参照)。" 12476 12477#: ../../rst/user_guide/windows_setup.rst:4 12478msgid "Setting up a Windows Host" 12479msgstr "Windows ホストのセットアップ" 12480 12481#: ../../rst/user_guide/windows_setup.rst:5 12482msgid "This document discusses the setup that is required before Ansible can communicate with a Microsoft Windows host." 12483msgstr "本書では、Ansible が Microsoft Windows ホストと通信する前に必要なセットアップを説明します。" 12484 12485#: ../../rst/user_guide/windows_setup.rst:12 12486msgid "For Ansible to communicate to a Windows host and use Windows modules, the Windows host must meet these requirements:" 12487msgstr "Ansible が Windows ホストと通信し、Windows モジュールを使用するためには、Windows ホストが以下の要件を満たす必要があります。" 12488 12489#: ../../rst/user_guide/windows_setup.rst:15 12490msgid "Ansible can generally manage Windows versions under current and extended support from Microsoft. Ansible can manage desktop OSs including Windows 7, 8.1, and 10, and server OSs including Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016, and 2019." 12491msgstr "Ansible は、Microsoft の現行および拡張サポート下にある Windows バージョンを一般的に管理できます。Ansible は、Windows 7、8.1、および 10 を含むデスクトップ OS、およびWindows Server 2008、2008 R2、2012、2012 R2、2016、および 2019 を含むサーバー OS を管理できます。" 12492 12493#: ../../rst/user_guide/windows_setup.rst:20 12494msgid "Ansible requires PowerShell 3.0 or newer and at least .NET 4.0 to be installed on the Windows host." 12495msgstr "Ansible を利用するには、Windows ホストに PowerShell 3.0 以降と少なくとも .NET 4.0 がインストールされている必要があります。" 12496 12497#: ../../rst/user_guide/windows_setup.rst:23 12498msgid "A WinRM listener should be created and activated. More details for this can be found below." 12499msgstr "WinRM リスナーを作成し、有効にする必要があります。詳細は以下を参照してください。" 12500 12501#: ../../rst/user_guide/windows_setup.rst:26 12502msgid "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." 12503msgstr "これらは、Ansible 接続の基本的な要件ですが、Ansible モジュールの中には、新しい OS や PowerShell のバージョンなど、追加の要件があるものもあります。ホストがこれらの要件を満たしているかどうかは、モジュールのドキュメントページを参照してください。" 12504 12505#: ../../rst/user_guide/windows_setup.rst:32 12506msgid "Upgrading PowerShell and .NET Framework" 12507msgstr "PowerShell および .NET Framework のアップグレード" 12508 12509#: ../../rst/user_guide/windows_setup.rst:33 12510msgid "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." 12511msgstr "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>`_ スクリプトを使用してこれらを更新することができます。" 12512 12513#: ../../rst/user_guide/windows_setup.rst:36 12514msgid "This is an example of how to run this script from PowerShell:" 12515msgstr "このスクリプトを PowerShell から実行する例を以下に示します。" 12516 12517#: ../../rst/user_guide/windows_setup.rst:52 12518msgid "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:" 12519msgstr "完了したら、自動ログオンを解除して、実行ポリシーをデフォルト (Windows クライアントの場合は ``Restricted ``、Windows サーバーの場合は ``RemoteSigned``) に戻す必要があります。これには以下の PowerShell コマンドが必要です。" 12520 12521#: ../../rst/user_guide/windows_setup.rst:66 12522msgid "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." 12523msgstr "このスクリプトは、インストールが必要なプログラム (.NET Framework 4.5.2 など) や、必要な PowerShell バージョンを確認して動作します。再起動が必要で、``username`` パラメーターと ``password`` パラメーターが設定されている場合は、スクリプトが自動的に再起動し、再起動から復帰したときにログオンします。スクリプトは、アクションが不要になり、PowerShell バージョンがターゲットのバージョンと一致するまで続行されます。``username`` パラメーターおよび ``password`` パラメーターが設定されていない場合、スクリプトは必要に応じてユーザーに手動で再起動とログオンを促します。ユーザーが次にログインすると、スクリプトは前回の続きを実行し、アクションが必要なくなるまで処理を続けます。" 12524 12525#: ../../rst/user_guide/windows_setup.rst:77 12526msgid "If running on Server 2008, then SP2 must be installed. If running on Server 2008 R2 or Windows 7, then SP1 must be installed." 12527msgstr "Server 2008 で実行する場合は、SP2 がインストールされている必要があります。Server 2008 R2 または Windows 7 で実行している場合は SP1 をインストールする必要があります。" 12528 12529#: ../../rst/user_guide/windows_setup.rst:80 12530msgid "Windows Server 2008 can only install PowerShell 3.0; specifying a newer version will result in the script failing." 12531msgstr "Windows Server 2008 では PowerShell 3.0 しかインストールできないため、それより新しいバージョンを指定するとスクリプトが失敗します。" 12532 12533#: ../../rst/user_guide/windows_setup.rst:83 12534msgid "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." 12535msgstr "``username`` と ``password`` のパラメーターは、レジストリーに平文で保存されます。スクリプトの終了後にクリーンアップコマンドを実行して、ホスト上に認証情報が保存されていないことを確認してください。" 12536 12537#: ../../rst/user_guide/windows_setup.rst:88 12538msgid "WinRM Memory Hotfix" 12539msgstr "WinRM Memory Hotfix" 12540 12541#: ../../rst/user_guide/windows_setup.rst:89 12542msgid "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." 12543msgstr "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 をインストールできます。" 12544 12545#: ../../rst/user_guide/windows_setup.rst:95 12546msgid "The following PowerShell command will install the hotfix:" 12547msgstr "以下の PowerShell コマンドはホットフィックスをインストールします。" 12548 12549#: ../../rst/user_guide/windows_setup.rst:106 12550msgid "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." 12551msgstr "詳細は、Microsoft 社の `ホットフィックスのドキュメント <https://support.microsoft.com/en-us/help/2842230/out-of-memory-error-on-a-computer-that-has-a-customized-maxmemorypersh>`_ を参照してください。" 12552 12553#: ../../rst/user_guide/windows_setup.rst:109 12554msgid "WinRM Setup" 12555msgstr "WinRM の設定" 12556 12557#: ../../rst/user_guide/windows_setup.rst:110 12558msgid "Once Powershell has been upgraded to at least version 3.0, the final step is for the WinRM service to be configured 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." 12559msgstr "Powershell をバージョン 3.0 以降にアップグレードしたら、最後のステップとして、WinRM サービスを設定して Ansible が接続できるようにします。WinRM サービスには、Ansible が Windows ホストとどのように連携するかを決定する構成設定 ``listener`` と``service`` の 2 つの主要コンポーネントがあります。" 12560 12561#: ../../rst/user_guide/windows_setup.rst:115 12562msgid "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." 12563msgstr "各コンポーネントの詳細については後述しますが、基本的な設定には`ConfigureRemotingForAnsible.ps1 <https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1>`_ スクリプトが使えます。このスクリプトは、自己署名証明書を用いて HTTP と HTTPS の両方のリスナーを設定し、サービスで ``Basic`` 認証オプションを有効にします。" 12564 12565#: ../../rst/user_guide/windows_setup.rst:121 12566msgid "To use this script, run the following in PowerShell:" 12567msgstr "このスクリプトを使用するには、以下を PowerShell で実行します。" 12568 12569#: ../../rst/user_guide/windows_setup.rst:133 12570msgid "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." 12571msgstr "このスクリプトには、さまざまなスイッチやパラメーター (``-EnableCredSSP`` や ``-ForceNewSSLCert`` など) を設定することができます。これらのオプションのドキュメントは、スクリプト本体の上部にあります。" 12572 12573#: ../../rst/user_guide/windows_setup.rst:137 12574msgid "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." 12575msgstr "ConfigureRemotingForAnsible.ps1 スクリプトは、トレーニングと開発のみを目的としており、実稼働環境では使用しないでください。これは、本質的に安全でない可能性のある設定 (``Basic`` 認証など) を可能にするためです。" 12576 12577#: ../../rst/user_guide/windows_setup.rst:143 12578msgid "WinRM Listener" 12579msgstr "WinRM リスナー" 12580 12581#: ../../rst/user_guide/windows_setup.rst:144 12582msgid "The WinRM services listens for requests on one or more ports. Each of these ports must have a listener created and configured." 12583msgstr "WinRM サービスは、1 つ以上のポートで要求をリッスンします。これらのポートごとにリスナーを作成し、設定する必要があります。" 12584 12585#: ../../rst/user_guide/windows_setup.rst:147 12586msgid "To view the current listeners that are running on the WinRM service, run the following command:" 12587msgstr "WinRM サービスで実行している現在のリスナーを表示するには、次のコマンドを実行します。" 12588 12589#: ../../rst/user_guide/windows_setup.rst:154 12590#: ../../rst/user_guide/windows_setup.rst:266 12591msgid "This will output something like::" 12592msgstr "これにより、以下のような出力が表示されます。" 12593 12594#: ../../rst/user_guide/windows_setup.rst:178 12595msgid "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:" 12596msgstr "上の例では、2 つのリスナーが有効になっています。1 つは HTTP でポート 5985 をリッスンしており、もう 1 つは HTTPS でポート 5986 をリッスンしています。理解しておくと便利なオプションをいくつか紹介します。" 12597 12598#: ../../rst/user_guide/windows_setup.rst:182 12599msgid "``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." 12600msgstr "``Transport``: リスナーが HTTP または HTTPS のどちらで実行されている場合でも、データはさらなる変更なしに暗号化されるため、HTTPS 経由でリスナーを使用することが推奨されます。" 12601 12602#: ../../rst/user_guide/windows_setup.rst:186 12603msgid "``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``." 12604msgstr "``Port``: リスナーが実行するポート。デフォルトは、HTTP の場合は ``5985``、HTTPS の場合は ``5986`` です。このポートは、必要なものにそれぞれ変更でき、ホスト変数 ``ansible_port`` に対応することができます。" 12605 12606#: ../../rst/user_guide/windows_setup.rst:190 12607msgid "``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." 12608msgstr "``URLPrefix``: リッスンする URL プレフィックス。デフォルトは ``wsman`` です。これが変更された場合、ホスト変数 ``ansible_winrm_path`` は同じ値に設定する必要があります。" 12609 12610#: ../../rst/user_guide/windows_setup.rst:194 12611msgid "``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::" 12612msgstr "``CertificateThumbprint``: HTTPS リスナーを介して実行する場合、これは接続に使用される Windows 証明書ストアの証明書のサムプリントです。証明書自体の詳細を取得するには、PowerShell で該当する証明書のサムプリントを指定して次のコマンドを実行します。" 12613 12614#: ../../rst/user_guide/windows_setup.rst:203 12615msgid "Setup WinRM Listener" 12616msgstr "WinRM リスナーの設定" 12617 12618#: ../../rst/user_guide/windows_setup.rst:204 12619msgid "There are three ways to set up a WinRM listener:" 12620msgstr "WinRM リスナーを設定するには、3 つの方法があります。" 12621 12622#: ../../rst/user_guide/windows_setup.rst:206 12623msgid "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." 12624msgstr "HTTP には ``winrm quickconfig`` を、HTTPS には ``winrm quickconfig -transport:https`` を使用します。これは、ドメイン環境の外で動作し、シンプルなリスナーが必要な場合に、最も簡単に使用できるオプションです。他のオプションとは異なり、このプロセスには、必要なポートのためにファイアウォールを開き、WinRM サービスを開始するという利点があります。" 12625 12626#: ../../rst/user_guide/windows_setup.rst:212 12627msgid "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>`_." 12628msgstr "グループポリシーオブジェクトの使用。この方法は、ホストがドメインのメンバーである場合にリスナーを作成するのに最適な方法です。なぜなら、設定はユーザーの入力なしに自動的に行われるからです。グループポリシーオブジェクトの詳細は、`Group Policy Objects ドキュメント <https://msdn.microsoft.com/en-us/library/aa374162(v=vs.85).aspx>`_ を参照してください。" 12629 12630#: ../../rst/user_guide/windows_setup.rst:217 12631msgid "Using PowerShell to create the listener with a specific configuration. This can be done by running the following PowerShell commands:" 12632msgstr "PowerShell を使用して、特定の設定でリスナーを作成します。これは、以下の PowerShell コマンドを実行することで可能になります。" 12633 12634#: ../../rst/user_guide/windows_setup.rst:232 12635msgid "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>`_." 12636msgstr "この PowerShell コマンドレッドをともなう他のオプションを表示するには、「`New-WSManInstance <https://docs.microsoft.com/en-us/powershell/module/microsoft.wsman.management/new-wsmaninstance?view=powershell-5.1>`_」を参照してください。" 12637 12638#: ../../rst/user_guide/windows_setup.rst:235 12639msgid "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." 12640msgstr "HTTPS リスナーを作成する際には、既存の証明書を作成し、``LocalMachine\\My`` の証明書ストアに保存する必要があります。このストアに証明書が存在しないと、ほとんどのコマンドが失敗します。" 12641 12642#: ../../rst/user_guide/windows_setup.rst:240 12643msgid "Delete WinRM Listener" 12644msgstr "WinRM リスナーの削除" 12645 12646#: ../../rst/user_guide/windows_setup.rst:241 12647msgid "To remove a WinRM listener::" 12648msgstr "WinRM リスナーを削除するには、以下を実行します。" 12649 12650#: ../../rst/user_guide/windows_setup.rst:249 12651msgid "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." 12652msgstr "``Keys`` オブジェクトは文字列の配列であるため、異なる値を含むことができます。デフォルトでは、winrm enumerate winrm/config/Listeners の値に対応す る``Transport=`` と``Address=`` のキーを含んでいます。" 12653 12654#: ../../rst/user_guide/windows_setup.rst:254 12655msgid "WinRM Service Options" 12656msgstr "WinRM サービスオプション" 12657 12658#: ../../rst/user_guide/windows_setup.rst:255 12659msgid "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." 12660msgstr "WinRM サービスコンポーネントの動作を制御するように設定でき、認証オプションやメモリー設定など、複数のオプションを設定できます。" 12661 12662#: ../../rst/user_guide/windows_setup.rst:258 12663msgid "To get an output of the current service configuration options, run the following command:" 12664msgstr "現在のサービス設定オプションの出力を得るには、次のコマンドを実行します。" 12665 12666#: ../../rst/user_guide/windows_setup.rst:302 12667msgid "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:" 12668msgstr "これらのオプションの多くはほとんど変更する必要はありませんが、いくつかのオプションは WinRM の操作に簡単に影響を与えるので、理解しておくと便利です。重要なオプションの一部を紹介します。" 12669 12670#: ../../rst/user_guide/windows_setup.rst:306 12671msgid "``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." 12672msgstr "``Service\\AllowUnencrypted``: このオプションは、メッセージを暗号化せずに HTTP で実行されるトラフィックを WinRM で許可するかどうかを定義します。メッセージレベルの暗号化は、``ansible_winrm_transport`` が ``ntlm``、``kerberos`` または ``credssp`` の場合にのみ可能です。デフォルトでは、これは ``false`` であり、WinRM メッセージをデバッグするときにのみ ``true`` に設定する必要があります。" 12673 12674#: ../../rst/user_guide/windows_setup.rst:312 12675msgid "``Service\\Auth\\*``: These flags define what authentication options are allowed with the WinRM service. By default, ``Negotiate (NTLM)`` and ``Kerberos`` are enabled." 12676msgstr "``Service\\Auth\\*``: これらのフラグは、WinRM サービスで許可される認証オプションを定義します。デフォルトでは、``Negotiate (NTLM)`` および ``Kerberos`` が有効になります。" 12677 12678#: ../../rst/user_guide/windows_setup.rst:316 12679msgid "``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." 12680msgstr "``Service\\Auth\\CbtHardeningLevel``: チャンネルバインディングトークンを検証しない (None)、検証済みだが必要ない (Relaxed)、検証済みで必要 (Strict) のいずれかを指定します。CBT は、HTTPS の NTLM または Kerberos での接続時にのみ使用されます。" 12681 12682#: ../../rst/user_guide/windows_setup.rst:321 12683msgid "``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." 12684msgstr "``Service\\CertificateThumbprint``: これは、CredSSP 認証で使用される TLS チャンネルの暗号化に使用される証明書のサムプリントです。デフォルトでは、これは空です。自己署名証明書は、WinRM サービスの起動時に生成され、TLS プロセスで使用されます。" 12685 12686#: ../../rst/user_guide/windows_setup.rst:326 12687msgid "``Winrs\\MaxShellRunTime``: This is the maximum time, in milliseconds, that a remote command is allowed to execute." 12688msgstr "``Winrs\\MaxShellRunTime``: リモートコマンドの実行を許可する最大時間をミリ秒単位で指定します。" 12689 12690#: ../../rst/user_guide/windows_setup.rst:329 12691msgid "``Winrs\\MaxMemoryPerShellMB``: This is the maximum amount of memory allocated per shell, including the shell's child processes." 12692msgstr "``Winrs\\MaxMemoryPerShellMB``: シェルの子プロセスを含め、シェルごとに割り当てられるメモリーの最大量です。" 12693 12694#: ../../rst/user_guide/windows_setup.rst:332 12695msgid "To modify a setting under the ``Service`` key in PowerShell::" 12696msgstr "PowerShell の ``Service`` キーで設定を変更するには、以下を実行します。" 12697 12698#: ../../rst/user_guide/windows_setup.rst:340 12699msgid "To modify a setting under the ``Winrs`` key in PowerShell::" 12700msgstr "PowerShell の ``Winrs`` キーで設定を変更するには、以下を実行します。" 12701 12702#: ../../rst/user_guide/windows_setup.rst:348 12703msgid "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." 12704msgstr "ドメイン環境で動作している場合、これらのオプションの一部は GPO によって設定され、ホスト自体では変更できません。GPO で設定されたキーには、値の横に ``[Source=\"GPO\"]`` というテキストが表示されます。" 12705 12706#: ../../rst/user_guide/windows_setup.rst:353 12707msgid "Common WinRM Issues" 12708msgstr "一般的な WinRM の問題" 12709 12710#: ../../rst/user_guide/windows_setup.rst:354 12711msgid "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." 12712msgstr "WinRM にはさまざまな設定オプションがあるため、セットアップや設定が難しい場合があります。そのため、Ansible で表示される問題が、実際にはホストの設定の問題である可能性もあります。" 12713 12714#: ../../rst/user_guide/windows_setup.rst:358 12715msgid "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::" 12716msgstr "問題がホストの問題であるかどうかを判断する簡単な方法として、別の Windows ホストから次のコマンドを実行して、対象の Windows ホストに接続する方法があります。" 12717 12718#: ../../rst/user_guide/windows_setup.rst:376 12719msgid "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." 12720msgstr "失敗した場合は、WinRM の設定に問題があると思われます。成功した場合は、問題が WinRM の設定に関連していない可能性があるため、さらに詳しいトラブルシューティングの方法をご確認ください。" 12721 12722#: ../../rst/user_guide/windows_setup.rst:379 12723msgid "HTTP 401/Credentials Rejected" 12724msgstr "HTTP 401/認証情報の拒否" 12725 12726#: ../../rst/user_guide/windows_setup.rst:380 12727msgid "A HTTP 401 error indicates the authentication process failed during the initial connection. Some things to check for this are:" 12728msgstr "HTTP 401 エラーは、最初の接続時に認証プロセスが失敗したことを示します。これを確認するためのいくつかの項目があります。" 12729 12730#: ../../rst/user_guide/windows_setup.rst:383 12731msgid "Verify that the credentials are correct and set properly in your inventory with ``ansible_user`` and ``ansible_password``" 12732msgstr "``ansible_user`` および ``ansible_password`` を使用して、認証情報が正しく、インベントリーに適切に設定されていることを確認します。" 12733 12734#: ../../rst/user_guide/windows_setup.rst:386 12735msgid "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)." 12736msgstr "ユーザーがローカルの Administrators グループのメンバーであるか、明示的にアクセスを許可されていることを確認してください (``winrs`` コマンドによる接続テストで除外できます)。" 12737 12738#: ../../rst/user_guide/windows_setup.rst:390 12739msgid "Make sure that the authentication option set by ``ansible_winrm_transport`` is enabled under ``Service\\Auth\\*``" 12740msgstr "``ansible_winrm_transport`` で設定した認証オプションが、``Service\\Auth\\*`` で有効になっていることを確認してください。" 12741 12742#: ../../rst/user_guide/windows_setup.rst:393 12743msgid "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" 12744msgstr "HTTPS ではなく HTTP で実行する場合は、``ntlm``、``kerberos``、または ``credssp`` と ``ansible_winrm_message_encryption: auto`` を使用してメッセージの暗号化を有効にしてください。他の認証オプションを使用している場合や、インストールされている pywinrm のバージョンをアップグレードできない場合は、``Service\\AllowUnencrypted`` を``true`` に設定できますが、これはトラブルシューティングのためにのみ推奨されます。" 12745 12746#: ../../rst/user_guide/windows_setup.rst:399 12747msgid "Ensure the downstream packages ``pywinrm``, ``requests-ntlm``, ``requests-kerberos``, and/or ``requests-credssp`` are up to date using ``pip``." 12748msgstr "ダウンストリームパッケージである ``pywinrm``、``requests-ntlm``、``requests-kerberos``、または ``requests-credssp``、もしくはその組み合わせが ``pip`` を使用して最新の状態になっていることを確認します。" 12749 12750#: ../../rst/user_guide/windows_setup.rst:402 12751msgid "If using Kerberos authentication, ensure that ``Service\\Auth\\CbtHardeningLevel`` is not set to ``Strict``." 12752msgstr "Kerberos 認証を使用する場合は、``Service\\Auth\\CbtHardeningLevel`` が ``Strict`` に設定されていないことを確認してください。" 12753 12754#: ../../rst/user_guide/windows_setup.rst:405 12755msgid "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." 12756msgstr "Basic 認証や Certificate 認証を使用する際は、ユーザーがドメインアカウントではなく、ローカルアカウントであることを確認してください。ドメインアカウントは、Basic 認証や Certificate 認証では機能しません。" 12757 12758#: ../../rst/user_guide/windows_setup.rst:410 12759msgid "HTTP 500 Error" 12760msgstr "HTTP 500 Error" 12761 12762#: ../../rst/user_guide/windows_setup.rst:411 12763msgid "These indicate an error has occurred with the WinRM service. Some things to check for include:" 12764msgstr "これらは、WinRM サービスでエラーが発生したことを示しています。確認すべき点は以下の通りです。" 12765 12766#: ../../rst/user_guide/windows_setup.rst:414 12767msgid "Verify that the number of current open shells has not exceeded either ``WinRsMaxShellsPerUser`` or any of the other Winrs quotas haven't been exceeded." 12768msgstr "現在のオープンシェルの数が ``WinRsMaxShellsPerUser`` のどちらかを超えていないか、または他の Winrs のクォータを超えていないかを確認してください。" 12769 12770#: ../../rst/user_guide/windows_setup.rst:419 12771msgid "Timeout Errors" 12772msgstr "タイムアウトエラー" 12773 12774#: ../../rst/user_guide/windows_setup.rst:420 12775msgid "These usually indicate an error with the network connection where Ansible is unable to reach the host. Some things to check for include:" 12776msgstr "これらは通常、Ansible がホストに到達できないネットワーク接続のエラーを示しています。チェック項目には以下が含まれます。" 12777 12778#: ../../rst/user_guide/windows_setup.rst:423 12779msgid "Make sure the firewall is not set to block the configured WinRM listener ports" 12780msgstr "ファイアウォールが、設定された WinRM リスナーポートをブロックするように設定されていないことを確認します。" 12781 12782#: ../../rst/user_guide/windows_setup.rst:424 12783msgid "Ensure that a WinRM listener is enabled on the port and path set by the host vars" 12784msgstr "WinRM リスナーが、ホストの変数によって設定されたポートおよびパスで有効になっていることを確認します。" 12785 12786#: ../../rst/user_guide/windows_setup.rst:425 12787msgid "Ensure that the ``winrm`` service is running on the Windows host and configured for automatic start" 12788msgstr "Windows ホスト上で ``winrm`` サービスが稼動しており、自動起動するように設定されていることを確認する。" 12789 12790#: ../../rst/user_guide/windows_setup.rst:429 12791msgid "Connection Refused Errors" 12792msgstr "接続拒否エラー" 12793 12794#: ../../rst/user_guide/windows_setup.rst:430 12795msgid "These usually indicate an error when trying to communicate with the WinRM service on the host. Some things to check for:" 12796msgstr "これらは通常、ホスト上の WinRM サービスと通信しようとする際にエラーを示します。いくつかのチェック項目があります。" 12797 12798#: ../../rst/user_guide/windows_setup.rst:433 12799msgid "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." 12800msgstr "ホスト上で WinRM サービスが稼働していることを確認します。``(Get-Service -Name winrm).Status`` を使用して、サービスのステータスを取得します。" 12801 12802#: ../../rst/user_guide/windows_setup.rst:435 12803msgid "Check that the host firewall is allowing traffic over the WinRM port. By default this is ``5985`` for HTTP and ``5986`` for HTTPS." 12804msgstr "ホスト側のファイアウォールが、WinRMポートへのトラフィックを許可していることを確認します。デフォルトでは、HTTP では ``5985``、HTTPS では ``5986`` となっています。" 12805 12806#: ../../rst/user_guide/windows_setup.rst:438 12807msgid "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." 12808msgstr "インストーラーが WinRM や HTTP サービスを再起動してしまい、このエラーが発生することがあります。これに対処する最良の方法は、別の Windows ホストから ``win_psexec`` を使用します。" 12809 12810#: ../../rst/user_guide/windows_setup.rst:443 12811msgid "Failure to Load Builtin Modules" 12812msgstr "組み込みモジュールのロードに失敗" 12813 12814#: ../../rst/user_guide/windows_setup.rst:444 12815msgid "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:" 12816msgstr "``The 'Out-String' command was found in the module 'Microsoft.PowerShell.Utility', but the module could not be loaded.`` のようなエラーメッセージで powershell が失敗する場合は、``PSModulePath`` 環境変数で指定されたすべてのパスにアクセスしようとすると問題が発生する可能性があります。この問題の一般的な原因は、``PSModulePath`` 環境変数にファイル共有への UNC パスが含まれており、ダブルホップ/認証情報の委譲問題のために Ansible プロセスがこれらのディレクトリーにアクセスできないことです。この問題を回避するには、以下の方法があります。" 12817 12818#: ../../rst/user_guide/windows_setup.rst:450 12819msgid "Remove the UNC path from the ``PSModulePath`` environment variable, or" 12820msgstr "``PSModulePath`` 環境変数から UNC パスを削除します。" 12821 12822#: ../../rst/user_guide/windows_setup.rst:451 12823msgid "Use an authentication option that supports credential delegation like ``credssp`` or ``kerberos`` with credential delegation enabled" 12824msgstr "認証情報の委譲を有効にした ``credssp`` や ``kerberos`` のような、認証情報の委譲をサポートする認証オプションを使用します。" 12825 12826#: ../../rst/user_guide/windows_setup.rst:453 12827msgid "See `KB4076842 <https://support.microsoft.com/en-us/help/4076842>`_ for more information on this problem." 12828msgstr "この問題の詳細は、「`KB4076842 <https://support.microsoft.com/en-us/help/4076842>`_」を参照してください。" 12829 12830#: ../../rst/user_guide/windows_setup.rst:457 12831msgid "Windows SSH Setup" 12832msgstr "Windows SSH の設定" 12833 12834#: ../../rst/user_guide/windows_setup.rst:458 12835msgid "Ansible 2.8 has added an experimental SSH connection for Windows managed nodes." 12836msgstr "Ansible 2.8 では、Windows 管理ノードの実験的な SSH 接続が追加されました。" 12837 12838#: ../../rst/user_guide/windows_setup.rst:461 12839msgid "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." 12840msgstr "この機能はご自身の責任でお使いください。Windows での SSH の使用は実験的なものであり、実装は機能リリースにおいて後方互換性のない変更を行う可能性があります。また、サーバー側のコンポーネントは、インストールされているバージョンによっては信頼性に欠けることがあります。" 12841 12842#: ../../rst/user_guide/windows_setup.rst:467 12843msgid "Installing Win32-OpenSSH" 12844msgstr "Win32-OpenSSH のインストール" 12845 12846#: ../../rst/user_guide/windows_setup.rst:468 12847msgid "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 three installation options:" 12848msgstr "Windows で SSH を利用するための最初のステップは、Windows ホストに `Win32-OpenSSH <https://github.com/PowerShell/Win32-OpenSSH>`_ サービスをインストールすることです。Microsoft 社では，Windows の機能を利用して ``Win32-OpenSSH`` をインストールする方法を提供していますが、現在、この方法でインストールされるバージョンは，Ansible で動作させるには古すぎます．Ansible で使用するために ``Win32-OpenSSH`` をインストールするには、以下の 3 つのインストールオプションのいずれかを選択します。" 12849 12850#: ../../rst/user_guide/windows_setup.rst:474 12851msgid "Manually install the service, following the `install instructions <https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH>`_ from Microsoft." 12852msgstr "Microsoft 社が提供する `インストール手順 <https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH>`_ に従って、サービスを手動でインストールしてください。" 12853 12854#: ../../rst/user_guide/windows_setup.rst:477 12855msgid "Install the `openssh <https://chocolatey.org/packages/openssh>`_ package using Chocolatey::" 12856msgstr "Chocolatey を使用して `openssh <https://chocolatey.org/packages/openssh>`_ パッケージをインストールします。" 12857 12858#: ../../rst/user_guide/windows_setup.rst:481 12859msgid "Use ``win_chocolatey`` to install the service::" 12860msgstr "``win_chocolatey`` を使用してサービスをインストールします。" 12861 12862#: ../../rst/user_guide/windows_setup.rst:489 12863msgid "Use an existing Ansible Galaxy role like `jborean93.win_openssh <https://galaxy.ansible.com/jborean93/win_openssh>`_::" 12864msgstr "`jborean93.win_openssh <https://galaxy.ansible.com/jborean93/win_openssh>`_ などの既存の Ansible Galaxy ロールを使用します。" 12865 12866#: ../../rst/user_guide/windows_setup.rst:502 12867msgid "``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." 12868msgstr "``Win32-OpenSSH`` は未だベータ版の製品であり、新機能やバグ修正を含めて常に更新されています。Windows で SSH 接続をご利用の方は、上記 3 つの方法から最新版をインストールすることが強く推奨します。" 12869 12870#: ../../rst/user_guide/windows_setup.rst:508 12871msgid "Configuring the Win32-OpenSSH shell" 12872msgstr "Win32-OpenSSH シェルの設定" 12873 12874#: ../../rst/user_guide/windows_setup.rst:510 12875msgid "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::" 12876msgstr "デフォルトでは、``Win32-OpenSSH`` は ``cmd.exe`` をシェルとして使用します。別のシェルを設定するには、Ansible タスクを使用して、レジストリー設定を定義します。" 12877 12878#: ../../rst/user_guide/windows_setup.rst:529 12879msgid "Win32-OpenSSH Authentication" 12880msgstr "Win32-OpenSSH Authentication" 12881 12882#: ../../rst/user_guide/windows_setup.rst:530 12883msgid "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." 12884msgstr "Windows での Win32-OpenSSH 認証は、Unix/Linux ホストでの SSH 認証に似ています。平文のパスワードまたは SSH 公開鍵認証を使用し、公開鍵をユーザーのプロファイルディレクトリーの ``.ssh`` ディレクトリーにある ``authorized_key`` ファイルに追加し、Unix/Linux ホストと同様に SSH サービスで使用される ``sshd_config`` ファイルを使用してサービスを設定することができます。" 12885 12886#: ../../rst/user_guide/windows_setup.rst:537 12887msgid "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:" 12888msgstr "Ansible で SSH 鍵認証を使用する場合は、リモートセッションがユーザーの認証情報にアクセスできず、ネットワークリソースにアクセスしようとすると失敗することがあります。これは、ダブルホップや認証情報の委譲の問題としても知られています。この問題を回避するには 2 つの方法があります。" 12889 12890#: ../../rst/user_guide/windows_setup.rst:542 12891msgid "Use plaintext password auth by setting ``ansible_password``" 12892msgstr "``ansible_password`` を設定して平文テキストのパスワード認証を使用する" 12893 12894#: ../../rst/user_guide/windows_setup.rst:543 12895msgid "Use ``become`` on the task with the credentials of the user that needs access to the remote resource" 12896msgstr "リモートリソースへのアクセスを必要とするユーザーの認証情報を使用して、タスクで ``become`` を使用する" 12897 12898#: ../../rst/user_guide/windows_setup.rst:546 12899msgid "Configuring Ansible for SSH on Windows" 12900msgstr "Windows で SSH 用に Ansible の設定" 12901 12902#: ../../rst/user_guide/windows_setup.rst:547 12903msgid "To configure Ansible to use SSH for Windows hosts, you must set two connection variables:" 12904msgstr "Ansible が Windows ホストに SSH を使用するように設定するには、接続変数を 2 つ設定する必要があります。" 12905 12906#: ../../rst/user_guide/windows_setup.rst:549 12907msgid "set ``ansible_connection`` to ``ssh``" 12908msgstr "``ansible_connection`` を ``ssh`` に設定します。" 12909 12910#: ../../rst/user_guide/windows_setup.rst:550 12911msgid "set ``ansible_shell_type`` to ``cmd`` or ``powershell``" 12912msgstr "``ansible_shell_type`` を ``cmd`` または ``powershell`` に設定する" 12913 12914#: ../../rst/user_guide/windows_setup.rst:552 12915msgid "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." 12916msgstr "``ansible_shell_type`` 変数には、Windows ホストで設定されている``DefaultShell`` を反映させる必要があります。デフォルトのシェルの場合は ``cmd`` に、``DefaultShell`` が PowerShell に変更している場合は ``powershell`` に設定します。" 12917 12918#: ../../rst/user_guide/windows_setup.rst:557 12919msgid "Known issues with SSH on Windows" 12920msgstr "Windows での SSH に関する既知の問題" 12921 12922#: ../../rst/user_guide/windows_setup.rst:558 12923msgid "Using SSH with Windows is experimental, and we expect to uncover more issues. Here are the known ones:" 12924msgstr "Windows での SSH の使用は実験的なものであり、より多くの問題が発見されることを期待しています。ここでは、既知のものを紹介します。" 12925 12926#: ../../rst/user_guide/windows_setup.rst:561 12927msgid "Win32-OpenSSH versions older than ``v7.9.0.0p1-Beta`` do not work when ``powershell`` is the shell type" 12928msgstr "``powershell`` がシェルタイプの場合は、``v7.9.0.0p1-Beta`` よりも古い Win32-OpenSSH バージョンは機能しません。" 12929 12930#: ../../rst/user_guide/windows_setup.rst:562 12931msgid "While SCP should work, SFTP is the recommended SSH file transfer mechanism to use when copying or fetching a file" 12932msgstr "SCP も有効ですが、SFTP は、ファイルのコピーまたは取得時に使用する、推奨される SSH ファイル転送メカニズムです。" 12933 12934#: ../../rst/user_guide/windows_usage.rst:2 12935msgid "Using Ansible and Windows" 12936msgstr "Ansible と Windows の使用" 12937 12938#: ../../rst/user_guide/windows_usage.rst:3 12939msgid "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." 12940msgstr "Ansible を使用して Windows を管理する場合は、Unix/Linux ホストに適用される構文やルールの多くが Windows にも適用されますが、パスセパレーターや OS 固有のタスクなどのコンポーネントに関しては、若干の違いがあります。このドキュメントでは、Ansible を Windows で使用する際の詳細について説明します。" 12941 12942#: ../../rst/user_guide/windows_usage.rst:12 12943msgid "Use Cases" 12944msgstr "ユースケース" 12945 12946#: ../../rst/user_guide/windows_usage.rst:13 12947msgid "Ansible can be used to orchestrate a multitude of tasks on Windows servers. Below are some examples and info about common tasks." 12948msgstr "Ansible は、Windows サーバーにある多数のタスクを調整するために使用できます。以下は、一般的なタスクに関する例と情報です。" 12949 12950#: ../../rst/user_guide/windows_usage.rst:17 12951msgid "Installing Software" 12952msgstr "ソフトウェアのインストール" 12953 12954#: ../../rst/user_guide/windows_usage.rst:18 12955msgid "There are three main ways that Ansible can be used to install software:" 12956msgstr "Ansible を使用してソフトウェアをインストールできる主な方法は 3 つあります。" 12957 12958#: ../../rst/user_guide/windows_usage.rst:20 12959msgid "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." 12960msgstr "``win_chocolatey`` モジュールを使用。このモジュールは、デフォルトのパブリックな `Chocolatey <https://chocolatey.org/>`_ リポジトリーからプログラムデータを調達します。``source`` オプションを設定することで、代わりに内部リポジトリーを使用することができます。" 12961 12962#: ../../rst/user_guide/windows_usage.rst:24 12963msgid "Using the ``win_package`` module. This installs software using an MSI or .exe installer from a local/network path or URL." 12964msgstr "``win_package`` モジュールを使用します。これは、ローカル/ネットワークパスまたは URL から MSI または .exe インストーラーを使用してソフトウェアをインストールします。" 12965 12966#: ../../rst/user_guide/windows_usage.rst:27 12967msgid "Using the ``win_command`` or ``win_shell`` module to run an installer manually." 12968msgstr "``win_command`` モジュールまたは ``win_shell`` モジュールを使用して手動でインストーラーを実行する。" 12969 12970#: ../../rst/user_guide/windows_usage.rst:29 12971msgid "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." 12972msgstr "``win_chocolatey`` モジュールは、パッケージがすでにインストールされていて最新かどうかを確認するための最も完全なロジックを備えているため、このモジュールを使用することが推奨されます。" 12973 12974#: ../../rst/user_guide/windows_usage.rst:31 12975msgid "Below are some examples of using all three options to install 7-Zip:" 12976msgstr "以下は、3 つのすべてのオプションを使用して 7-Zip をインストールするいくつかの例です。" 12977 12978#: ../../rst/user_guide/windows_usage.rst:81 12979msgid "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." 12980msgstr "Microsoft Office や SQL Server などの一部のインストーラーは、認証情報の委譲や WinRM で制限されたコンポーネントへのアクセスを必要とします。これらの問題を回避するための最良の方法は、タスクに ``become`` を使用することです。``become`` を使用すると、Ansible はあたかもホスト上で対話的に実行されているかのようにインストーラを実行します。" 12981 12982#: ../../rst/user_guide/windows_usage.rst:86 12983msgid "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." 12984msgstr "多くのインストーラーは、WinRM を介してエラー情報を適切に返しません。このような場合には、ローカルでの動作が確認されている場合には become を使用することをお勧めします。" 12985 12986#: ../../rst/user_guide/windows_usage.rst:88 12987msgid "Some installers restart the WinRM or HTTP services, or cause them to become temporarily unavailable, making Ansible assume the system is unreachable." 12988msgstr "一部のインストーラーは、WinRM または HTTP サービスを再起動したり、一時的に利用できなくなったりするため、システムが到達不能であると Ansible により想定されます。" 12989 12990#: ../../rst/user_guide/windows_usage.rst:91 12991msgid "Installing Updates" 12992msgstr "更新のインストール" 12993 12994#: ../../rst/user_guide/windows_usage.rst:92 12995msgid "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." 12996msgstr "``win_updates`` モジュールおよび ``win_hotfix`` モジュールを使用すると、ホストにアップデートや Hotfix をインストールできます。モジュール ``win_updates`` はカテゴリー別に複数のアップデートをインストールするために使用され、``win_hotfix`` はローカルにダウンロードされた単一の更新または Hotfix ファイルをインストールするために使用されます。" 12997 12998#: ../../rst/user_guide/windows_usage.rst:97 12999msgid "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." 13000msgstr "``win_hotfix`` モジュールには、DISM PowerShell コマンドレットが存在するという要件があります。これらのコマンドレットは、Windows Server 2012 以降でのみデフォルトで追加されており、それ以前の Windows ホストではインストールする必要があります。" 13001 13002#: ../../rst/user_guide/windows_usage.rst:101 13003msgid "The following example shows how ``win_updates`` can be used:" 13004msgstr "次の例は、``win_updates`` の使用方法を示しています。" 13005 13006#: ../../rst/user_guide/windows_usage.rst:117 13007msgid "The following example show how ``win_hotfix`` can be used to install a single update or hotfix:" 13008msgstr "以下の例では、``win_hotfix`` を使用して単一のアップデートまたは Hotfix をインストールする方法を示しています。" 13009 13010#: ../../rst/user_guide/windows_usage.rst:139 13011msgid "Set Up Users and Groups" 13012msgstr "ユーザーおよびグループの設定" 13013 13014#: ../../rst/user_guide/windows_usage.rst:140 13015msgid "Ansible can be used to create Windows users and groups both locally and on a domain." 13016msgstr "Ansible を使用して、ローカルとドメインの両方で Windows ユーザーおよびグループを作成できます。" 13017 13018#: ../../rst/user_guide/windows_usage.rst:143 13019msgid "Local" 13020msgstr "ローカル" 13021 13022#: ../../rst/user_guide/windows_usage.rst:144 13023msgid "The modules ``win_user``, ``win_group`` and ``win_group_membership`` manage Windows users, groups and group memberships locally." 13024msgstr "``win_user`` モジュール、``win_group`` モジュール、および ``win_group_membership`` モジュールは、Windows のユーザー、グループ、およびグループのメンバーシップをローカルに管理します。" 13025 13026#: ../../rst/user_guide/windows_usage.rst:147 13027msgid "The following is an example of creating local accounts and groups that can access a folder on the same host:" 13028msgstr "以下は、同じホスト上のディレクトリーにアクセスできるローカルアカウントとグループを作成する例を示します。" 13029 13030#: ../../rst/user_guide/windows_usage.rst:190 13031msgid "Domain" 13032msgstr "ドメイン" 13033 13034#: ../../rst/user_guide/windows_usage.rst:191 13035msgid "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:" 13036msgstr "``win_domain_user`` モジュールおよび ``win_domain_group`` モジュールは、ドメインのユーザーおよびグループを管理します。以下は、ドメインユーザーのバッチを確実に作成する例です。" 13037 13038#: ../../rst/user_guide/windows_usage.rst:217 13039msgid "Running Commands" 13040msgstr "コマンドの実行" 13041 13042#: ../../rst/user_guide/windows_usage.rst:218 13043msgid "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." 13044msgstr "タスクに適したモジュールがない場合は、``win_shell`` モジュール、``win_command`` モジュール、``raw`` モジュール、および ``script`` モジュールを使用してコマンドやスクリプトを実行できます。" 13045 13046#: ../../rst/user_guide/windows_usage.rst:221 13047msgid "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." 13048msgstr "``raw`` モジュールは、Powershell コマンドをリモートで実行するだけです。``raw`` は、Ansible が通常使用するラッパーを一切使用していないため、``become``、``async`` および環境変数は動作しません。" 13049 13050#: ../../rst/user_guide/windows_usage.rst:225 13051msgid "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." 13052msgstr "``script`` モジュールは、Ansible コントローラーからのスクリプトを 1 つまたは複数の Windows ホスト上で実行します。``raw`` と同様に、``script`` は現在、``become``、``async``、または環境変数をサポートしていません。" 13053 13054#: ../../rst/user_guide/windows_usage.rst:229 13055msgid "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." 13056msgstr "``win_command`` モジュールは、実行ファイルまたはバッチファイルであるコマンドを実行するために使用され、``win_shell`` モジュールは、シェル内のコマンドを実行するために使用されます。" 13057 13058#: ../../rst/user_guide/windows_usage.rst:233 13059msgid "Choosing Command or Shell" 13060msgstr "コマンドまたはシェルの選択" 13061 13062#: ../../rst/user_guide/windows_usage.rst:234 13063msgid "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``." 13064msgstr "``win_shell`` モジュールおよび``win_command`` モジュールは、どちらもコマンドの実行に使用できます。``win_shell`` モジュールは ``PowerShell`` や``cmd`` のようなシェルライクなプロセス内で実行されるため、``<``、``>``、``|``、``;``、``&&``、``||`` のようなシェル演算子にアクセスできます。``win_shell`` では、複数行のコマンドも実行できます。" 13065 13066#: ../../rst/user_guide/windows_usage.rst:238 13067msgid "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``." 13068msgstr "``win_command`` モジュールは、シェルの外部でプロセスを実行するだけです。``cmd.exe`` や ``PowerShell.exe`` などのシェル実行ファイルに、``mkdir`` や ``New-Item`` などのシェルコマンドを渡してシェルコマンドを実行できます。" 13069 13070#: ../../rst/user_guide/windows_usage.rst:242 13071msgid "Here are some examples of using ``win_command`` and ``win_shell``:" 13072msgstr "以下は、``win_command`` と``win_shell`` を使用した例です。" 13073 13074#: ../../rst/user_guide/windows_usage.rst:270 13075msgid "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``." 13076msgstr "``mkdir``、``del``、``copy`` などの一部のコマンドは、CMD シェルにのみ存在します。``win_command`` でそれらを実行するには、``cmd.exe /c`` プレフィックスを付ける必要があります。" 13077 13078#: ../../rst/user_guide/windows_usage.rst:275 13079msgid "Argument Rules" 13080msgstr "引数のルール" 13081 13082#: ../../rst/user_guide/windows_usage.rst:276 13083msgid "When running a command through ``win_command``, the standard Windows argument rules apply:" 13084msgstr "``win_command`` を通じてコマンドを実行する際には、Windows の標準的な引数ルールが適用されます。" 13085 13086#: ../../rst/user_guide/windows_usage.rst:279 13087msgid "Each argument is delimited by a white space, which can either be a space or a tab." 13088msgstr "各引数は、空白またはタブのいずれかである空白で区切られます。" 13089 13090#: ../../rst/user_guide/windows_usage.rst:282 13091msgid "An argument can be surrounded by double quotes ``\"``. Anything inside these quotes is interpreted as a single argument even if it contains whitespace." 13092msgstr "引数は二重引用符 ``\"`` で囲むことができます。これらの引用符の内側には、空白が含まれていても、1 つの引数として解釈されます。" 13093 13094#: ../../rst/user_guide/windows_usage.rst:285 13095msgid "A double quote preceded by a backslash ``\\`` is interpreted as just a double quote ``\"`` and not as an argument delimiter." 13096msgstr "バックスラッシュ ``\\`` が前に付いた二重引用符は、引数区切り文字ではなく二重引用符 ``\"`` として解釈されます。" 13097 13098#: ../../rst/user_guide/windows_usage.rst:288 13099msgid "Backslashes are interpreted literally unless it immediately precedes double quotes; for example ``\\`` == ``\\`` and ``\\\"`` == ``\"``" 13100msgstr "バックスラッシュは、二重引用符の直前にない限り、文字通りに解釈されます (例: ``\\`` ==``\\`` および ``\\\"`` == ``\"``)。" 13101 13102#: ../../rst/user_guide/windows_usage.rst:291 13103msgid "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." 13104msgstr "偶数個のバックスラッシュの後に二重引用符が続く場合は、すべてのペアの引数で 1 つのバックスラッシュが使用され、二重引用符が引数の文字列区切り文字として使用されます。" 13105 13106#: ../../rst/user_guide/windows_usage.rst:295 13107msgid "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." 13108msgstr "奇数個のバックスラッシュの後に二重引用符が続く場合、引数ではペアごとに 1 つのバックスラッシュが使用され、二重引用符はエスケープされて引数のリテラル二重引用符となります。" 13109 13110#: ../../rst/user_guide/windows_usage.rst:299 13111msgid "With those rules in mind, here are some examples of quoting:" 13112msgstr "これらのルールを念頭に置いて、引用の例をいくつか示します。" 13113 13114#: ../../rst/user_guide/windows_usage.rst:324 13115msgid "For more information, see `escaping arguments <https://msdn.microsoft.com/en-us/library/17w5ykft(v=vs.85).aspx>`_." 13116msgstr "詳細情報は、「`escaping arguments <https://msdn.microsoft.com/en-us/library/17w5ykft(v=vs.85).aspx>`_」を参照してください。" 13117 13118#: ../../rst/user_guide/windows_usage.rst:327 13119msgid "Creating and Running a Scheduled Task" 13120msgstr "スケジュールされたタスクの作成および実行" 13121 13122#: ../../rst/user_guide/windows_usage.rst:328 13123msgid "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." 13124msgstr "WinRM には、特定のコマンドを実行したときにエラーが発生するような制限が設けられています。これらの制限を回避する方法の 1 つとして、スケジュールされたタスクを使用してコマンドを実行する方法があります。スケジュールされたタスクとは、実行ファイルをスケジュールに沿って、別のアカウントで実行する機能を提供する Windows コンポーネントです。" 13125 13126#: ../../rst/user_guide/windows_usage.rst:333 13127msgid "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:" 13128msgstr "Ansible バージョン 2.5 では、Windows でのスケジュールタスクの操作を容易にするモジュールが追加されました。以下は、実行後に自分自身を削除するスクリプトをスケジュールタスクとして実行する例です。" 13129 13130#: ../../rst/user_guide/windows_usage.rst:362 13131msgid "The modules used in the above example were updated/added in Ansible version 2.5." 13132msgstr "上記の例で使用されているモジュールは、Ansible バージョン 2.5 で更新または追加されたものです。" 13133 13134#: ../../rst/user_guide/windows_usage.rst:366 13135msgid "Path Formatting for Windows" 13136msgstr "Windows のパスのフォーマット" 13137 13138#: ../../rst/user_guide/windows_usage.rst:367 13139msgid "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." 13140msgstr "Windows は、従来の POSIX オペレーティングシステムとは多くの点で異なります。主な変更点のひとつは、パスの区切り文字が ``/`` から ``\\`` になったことです。POSIX システムでは、``\\`` がしばしばエスケープ文字として使用されるため、これは Playbook の記述方法に重大な問題を引き起こす可能性があります。" 13141 13142#: ../../rst/user_guide/windows_usage.rst:372 13143msgid "Ansible allows two different styles of syntax; each deals with path separators for Windows differently:" 13144msgstr "Ansible では、2 つの異なるスタイルの構文を使用できます。それぞれ Windows のパスセパレーターの扱いが異なります。" 13145 13146#: ../../rst/user_guide/windows_usage.rst:375 13147msgid "YAML Style" 13148msgstr "YAML スタイル" 13149 13150#: ../../rst/user_guide/windows_usage.rst:376 13151msgid "When using the YAML syntax for tasks, the rules are well-defined by the YAML standard:" 13152msgstr "タスクに YAML 構文を使用する場合、そのルールは YAML 規格によって明確に定義されています。" 13153 13154#: ../../rst/user_guide/windows_usage.rst:379 13155msgid "When using a normal string (without quotes), YAML will not consider the backslash an escape character." 13156msgstr "通常の文字列 (引用符なし) を使用する場合、YAML はバックスラッシュをエスケープ文字とはみなしません。" 13157 13158#: ../../rst/user_guide/windows_usage.rst:382 13159msgid "When using single quotes ``'``, YAML will not consider the backslash an escape character." 13160msgstr "一重引用符 ``'`` を使用する場合、YAML はバックスラッシュをエスケープ文字とはみなしません。" 13161 13162#: ../../rst/user_guide/windows_usage.rst:385 13163msgid "When using double quotes ``\"``, the backslash is considered an escape character and needs to escaped with another backslash." 13164msgstr "二重引用符 ``\"`` を使用する場合、バックスラッシュはエスケープ文字と見なされ、別のバックスラッシュでエスケープする必要があります。" 13165 13166#: ../../rst/user_guide/windows_usage.rst:388 13167msgid "You should only quote strings when it is absolutely necessary or required by YAML, and then use single quotes." 13168msgstr "文字列を引用するのは、絶対に必要な場合や YAML で要求される場合のみとし、その場合は一重引用符を使用します。" 13169 13170#: ../../rst/user_guide/windows_usage.rst:391 13171msgid "The YAML specification considers the following `escape sequences <https://yaml.org/spec/current.html#id2517668>`_:" 13172msgstr "YAML 仕様は、以下の `エスケープシーケンス <https://yaml.org/spec/current.html#id2517668>`_ を考慮します。" 13173 13174#: ../../rst/user_guide/windows_usage.rst:393 13175msgid "``\\0``, ``\\\\``, ``\\\"``, ``\\_``, ``\\a``, ``\\b``, ``\\e``, ``\\f``, ``\\n``, ``\\r``, ``\\t``, ``\\v``, ``\\L``, ``\\N`` and ``\\P`` -- Single character escape" 13176msgstr "``\\0``、``\\\\``、``\\\"``、``\\_``、``\\a``、``\\b``、``\\e``、``\\f``、``\\n" 13177"``、``\\r``、``\\t``、``\\v``、``\\L``、``\\N``、および ``\\P`` -- 一文字のエスケープ" 13178 13179#: ../../rst/user_guide/windows_usage.rst:396 13180msgid "``<TAB>``, ``<SPACE>``, ``<NBSP>``, ``<LNSP>``, ``<PSP>`` -- Special characters" 13181msgstr "``<TAB>``、``<SPACE>``、``<NBSP>``、``<LNSP>``、``<PSP>`` -- 特殊文字" 13182 13183#: ../../rst/user_guide/windows_usage.rst:399 13184#: ../../rst/user_guide/windows_usage.rst:449 13185msgid "``\\x..`` -- 2-digit hex escape" 13186msgstr "``\\x..`` -- 2 桁の 16 進エスケープ" 13187 13188#: ../../rst/user_guide/windows_usage.rst:401 13189#: ../../rst/user_guide/windows_usage.rst:451 13190msgid "``\\u....`` -- 4-digit hex escape" 13191msgstr "``\\u....`` -- 4 桁の 16 進エスケープ" 13192 13193#: ../../rst/user_guide/windows_usage.rst:403 13194#: ../../rst/user_guide/windows_usage.rst:453 13195msgid "``\\U........`` -- 8-digit hex escape" 13196msgstr "``\\U........`` -- 8 桁の 16 進エスケープ" 13197 13198#: ../../rst/user_guide/windows_usage.rst:405 13199msgid "Here are some examples on how to write Windows paths::" 13200msgstr "Windows パスの記述方法の例を次に示します。" 13201 13202#: ../../rst/user_guide/windows_usage.rst:419 13203msgid "This is an example which will fail:" 13204msgstr "これは失敗する例です。" 13205 13206#: ../../rst/user_guide/windows_usage.rst:426 13207msgid "This example shows the use of single quotes when they are required::" 13208msgstr "この例は、必要な場合の一重引用符の使用を示しています。" 13209 13210#: ../../rst/user_guide/windows_usage.rst:435 13211msgid "Legacy key=value Style" 13212msgstr "従来の key=value スタイル" 13213 13214#: ../../rst/user_guide/windows_usage.rst:436 13215msgid "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." 13216msgstr "従来の ``key=value`` の構文は、コマンドラインでのアドホックなコマンドや Playbook 内で使用されます。バックスラッシュ文字をエスケープする必要があり、Playbook が読みづらくなるため、Playbook 内ではこのスタイルの使用は推奨されません。レガシー構文は、Ansible の特定の実装に依存しており、引用符 (単一および二重) は、Ansible での解析方法には影響しません。" 13217 13218#: ../../rst/user_guide/windows_usage.rst:443 13219msgid "The Ansible key=value parser parse_kv() considers the following escape sequences:" 13220msgstr "Ansible の key=value パーサー parse_kv() は、以下のエスケープシーケンスを考慮します。" 13221 13222#: ../../rst/user_guide/windows_usage.rst:446 13223msgid "``\\``, ``'``, ``\"``, ``\\a``, ``\\b``, ``\\f``, ``\\n``, ``\\r``, ``\\t`` and ``\\v`` -- Single character escape" 13224msgstr "``\\``、``'``、``\"``、``\\a``、``\\b``、``\\f``、``\\n" 13225"``、``\\r``、``\\t``、``\\v`` -- 一文字のエスケープ" 13226 13227#: ../../rst/user_guide/windows_usage.rst:455 13228msgid "``\\N{...}`` -- Unicode character by name" 13229msgstr "``\\N{...}`` -- 名前による Unicode 文字" 13230 13231#: ../../rst/user_guide/windows_usage.rst:457 13232msgid "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." 13233msgstr "これは、バックスラッシュがいくつかのシーケンスのエスケープ文字になっていることを意味しており、通常、この形式の場合はバックスラッシュをエスケープする方が安全です。" 13234 13235#: ../../rst/user_guide/windows_usage.rst:460 13236msgid "Here are some examples of using Windows paths with the key=value style:" 13237msgstr "key=value スタイルで Windows パスを使用する例を次に示します。" 13238 13239#: ../../rst/user_guide/windows_usage.rst:482 13240msgid "The failing examples don't fail outright but will substitute ``\\t`` with the ``<TAB>`` character resulting in ``tempdir`` being ``C:\\Windows<TAB>emp``." 13241msgstr "失敗した例では、完全に失敗するわけではありませんが、``\\t`` を ``<TAB>`` の文字で置き換えて、``tempdir`` を ``C:\\Windows<TAB>emp`` にします。" 13242 13243#: ../../rst/user_guide/windows_usage.rst:486 13244#: ../../rst/user_guide/windows_winrm.rst:867 13245msgid "Limitations" 13246msgstr "制限事項" 13247 13248#: ../../rst/user_guide/windows_usage.rst:487 13249msgid "Some things you cannot do with Ansible and Windows are:" 13250msgstr "ここでは、Ansible および Windows でできないことを説明します。" 13251 13252#: ../../rst/user_guide/windows_usage.rst:489 13253msgid "Upgrade PowerShell" 13254msgstr "PowerShell のアップグレード" 13255 13256#: ../../rst/user_guide/windows_usage.rst:491 13257msgid "Interact with the WinRM listeners" 13258msgstr "WinRM リスナーとの対話" 13259 13260#: ../../rst/user_guide/windows_usage.rst:493 13261msgid "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." 13262msgstr "WinRM は、通常の運用時にサービスがオンラインで稼働していることに依存しているため、PowerShell をアップグレードしたり、Ansible で WinRM リスナーと対話したりすることはできません。これらのアクションはいずれも、接続の失敗を引き起こします。これは、技術的には ``async`` やスケジュールされたタスクを使用することで回避できますが、これらの方法は、実行するプロセスによって Ansible が使用する基礎的な接続が壊れると脆弱になるため、ブートストラッププロセスやイメージが作成される前に任せるのが最適です。" 13263 13264#: ../../rst/user_guide/windows_usage.rst:497 13265msgid "Developing Windows Modules" 13266msgstr "Windows モジュールの開発" 13267 13268#: ../../rst/user_guide/windows_usage.rst:498 13269msgid "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." 13270msgstr "Windows 用の Ansible モジュールは PowerShell で書かれているため、Windows モジュールの開発ガイドは標準規格のモジュールの開発ガイドとは大きく異なります。詳細は、「:ref:`developing_modules_general_windows`」を参照してください。" 13271 13272#: ../../rst/user_guide/windows_winrm.rst:4 13273msgid "Windows Remote Management" 13274msgstr "Windows リモート管理" 13275 13276#: ../../rst/user_guide/windows_winrm.rst:5 13277msgid "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." 13278msgstr "デフォルトで SSH を使用する Linux/Unix ホストとは異なり、Windows ホストは WinRM で設定されています。このトピックでは、Ansible で WinRM を設定し、使用する方法を説明します。" 13279 13280#: ../../rst/user_guide/windows_winrm.rst:12 13281msgid "What is WinRM?" 13282msgstr "WinRM とは" 13283 13284#: ../../rst/user_guide/windows_winrm.rst:13 13285msgid "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." 13286msgstr "WinRM は、Windows が別のサーバーとリモートで通信する際に使用する管理プロトコルです。WinRM は、HTTP/HTTPS で通信する SOA Pベースのプロトコルで、最近のすべての Windows OS に搭載されています。Windows Server 2012 以降、WinRM はデフォルトで有効になっていますが、ほとんどの場合、Ansible で WinRM を使用するには追加の設定が必要です。" 13287 13288#: ../../rst/user_guide/windows_winrm.rst:19 13289msgid "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:" 13290msgstr "Ansible は `pywinrm <https://github.com/diyan/pywinrm>`_ パッケージを使用して、WinRM を介して Windows サーバーと通信します。デフォルトでは Ansible パッケージとともにインストールされませんが、以下を実行することでインストールできます。" 13291 13292#: ../../rst/user_guide/windows_winrm.rst:27 13293msgid "on distributions with multiple python versions, use pip2 or pip2.x, where x matches the python minor version Ansible is running under." 13294msgstr "複数の python バージョンがあるディストリビューションでは、pip2 または pip2.x を使用します。x は、Ansible を実行している python マイナーバージョンと一致します。" 13295 13296#: ../../rst/user_guide/windows_winrm.rst:31 13297msgid "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." 13298msgstr "最新リリースの MacOS 上の Ansible で、``winrm`` または``psrp`` 接続プラグインを使用すると、通常は失敗します。これは、Python スタックの奥深くで発生する既知の問題であり、Ansible では変更できません。現在の唯一の回避策は、環境変数 ``no_proxy=*`` を設定し、Kerberos 認証を使用しないようにしてください。" 13299 13300#: ../../rst/user_guide/windows_winrm.rst:39 13301msgid "Authentication Options" 13302msgstr "認証オプション" 13303 13304#: ../../rst/user_guide/windows_winrm.rst:40 13305msgid "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." 13306msgstr "Windows ホストに接続する際、アカウントで認証する際に使用できるいくつかの異なるオプションがあります。認証タイプは、インベントリーのホストまたはグループに ``ansible_winrm_transport`` 変数で設定できます。" 13307 13308#: ../../rst/user_guide/windows_winrm.rst:44 13309msgid "The following matrix is a high level overview of the options:" 13310msgstr "以下のマトリックスは、オプションの概要を示しています。" 13311 13312#: ../../rst/user_guide/windows_winrm.rst:47 13313msgid "Option" 13314msgstr "オプション" 13315 13316#: ../../rst/user_guide/windows_winrm.rst:47 13317msgid "Local Accounts" 13318msgstr "ローカルアカウント" 13319 13320#: ../../rst/user_guide/windows_winrm.rst:47 13321msgid "Active Directory Accounts" 13322msgstr "Active Directory アカウント" 13323 13324#: ../../rst/user_guide/windows_winrm.rst:47 13325msgid "Credential Delegation" 13326msgstr "認証情報の委譲" 13327 13328#: ../../rst/user_guide/windows_winrm.rst:47 13329msgid "HTTP Encryption" 13330msgstr "HTTP 暗号化" 13331 13332#: ../../rst/user_guide/windows_winrm.rst:49 13333#: ../../rst/user_guide/windows_winrm.rst:61 13334msgid "Basic" 13335msgstr "基本" 13336 13337#: ../../rst/user_guide/windows_winrm.rst:49 13338#: ../../rst/user_guide/windows_winrm.rst:51 13339#: ../../rst/user_guide/windows_winrm.rst:53 13340#: ../../rst/user_guide/windows_winrm.rst:55 13341#: ../../rst/user_guide/windows_winrm.rst:57 13342msgid "Yes" 13343msgstr "可" 13344 13345#: ../../rst/user_guide/windows_winrm.rst:49 13346#: ../../rst/user_guide/windows_winrm.rst:51 13347#: ../../rst/user_guide/windows_winrm.rst:53 13348#: ../../rst/user_guide/windows_winrm.rst:55 13349msgid "No" 13350msgstr "不可" 13351 13352#: ../../rst/user_guide/windows_winrm.rst:51 13353#: ../../rst/user_guide/windows_winrm.rst:82 13354msgid "Certificate" 13355msgstr "証明書" 13356 13357#: ../../rst/user_guide/windows_winrm.rst:53 13358#: ../../rst/user_guide/windows_winrm.rst:268 13359msgid "Kerberos" 13360msgstr "Kerberos" 13361 13362#: ../../rst/user_guide/windows_winrm.rst:55 13363#: ../../rst/user_guide/windows_winrm.rst:241 13364msgid "NTLM" 13365msgstr "NTLM" 13366 13367#: ../../rst/user_guide/windows_winrm.rst:57 13368#: ../../rst/user_guide/windows_winrm.rst:456 13369msgid "CredSSP" 13370msgstr "CredSSP" 13371 13372#: ../../rst/user_guide/windows_winrm.rst:62 13373msgid "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)." 13374msgstr "Basic 認証は、最もシンプルな認証方法の 1 つですが、安全性が最も低くなります。これは、ユーザー名とパスワードが単純に Base64 エンコードされているためで、安全なチャンネル (例: HTTPS) が使用されていない場合は、誰でも解読することができます。Basic 認証は、ローカルアカウントにのみ使用することができます (ドメインアカウントには使用できません)。" 13375 13376#: ../../rst/user_guide/windows_winrm.rst:67 13377msgid "The following example shows host vars configured for basic authentication:" 13378msgstr "以下の例は、基本認証に設定されているホスト変数を示しています。" 13379 13380#: ../../rst/user_guide/windows_winrm.rst:76 13381msgid "Basic authentication is not enabled by default on a Windows host but can be enabled by running the following in PowerShell::" 13382msgstr "Basic 認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" 13383 13384#: ../../rst/user_guide/windows_winrm.rst:83 13385msgid "Certificate authentication uses certificates as keys similar to SSH key pairs, but the file format and key generation process is different." 13386msgstr "証明書認証は、SSH キーペアに似た鍵として証明書を使用しますが、ファイル形式と鍵の生成プロセスは異なります。" 13387 13388#: ../../rst/user_guide/windows_winrm.rst:86 13389msgid "The following example shows host vars configured for certificate authentication:" 13390msgstr "以下の例では、証明書認証に設定されているホスト変数を示しています。" 13391 13392#: ../../rst/user_guide/windows_winrm.rst:95 13393msgid "Certificate authentication is not enabled by default on a Windows host but can be enabled by running the following in PowerShell::" 13394msgstr "証明書認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" 13395 13396#: ../../rst/user_guide/windows_winrm.rst:100 13397msgid "Encrypted private keys cannot be used as the urllib3 library that is used by Ansible for WinRM does not support this functionality." 13398msgstr "暗号化された秘密鍵は、WinRM 向けに Ansible が使用する urllib3 ライブラリーとしては使用できません。この機能をサポートしません。" 13399 13400#: ../../rst/user_guide/windows_winrm.rst:104 13401msgid "Generate a Certificate" 13402msgstr "証明書の生成" 13403 13404#: ../../rst/user_guide/windows_winrm.rst:105 13405msgid "A certificate must be generated before it can be mapped to a local user. This can be done using one of the following methods:" 13406msgstr "証明書をローカルユーザーにマッピングする前に、証明書を生成する必要があります。これは、以下のいずれかの方法で行うことができます。" 13407 13408#: ../../rst/user_guide/windows_winrm.rst:108 13409msgid "OpenSSL" 13410msgstr "OpenSSL" 13411 13412#: ../../rst/user_guide/windows_winrm.rst:109 13413msgid "PowerShell, using the ``New-SelfSignedCertificate`` cmdlet" 13414msgstr "``New-SelfSignedCertificate`` コマンドレットを使用した PowerShell" 13415 13416#: ../../rst/user_guide/windows_winrm.rst:110 13417msgid "Active Directory Certificate Services" 13418msgstr "Active Directory 証明書サービス" 13419 13420#: ../../rst/user_guide/windows_winrm.rst:112 13421msgid "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)>`_." 13422msgstr "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)>`_ を参照してください。" 13423 13424#: ../../rst/user_guide/windows_winrm.rst:116 13425msgid "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." 13426msgstr "PowerShell コマンドレット (``New-SelfSignedCertificate``) を使用して認証用の証明書を生成する場合、Windows 10 または Windows Server 2012 R2 ホスト以降から生成された場合にのみ機能します。PFX 証明書から Ansible が使用する PEM ファイルに秘密鍵を抽出するには、OpenSSL が依然として必要です。" 13427 13428#: ../../rst/user_guide/windows_winrm.rst:122 13429msgid "To generate a certificate with ``OpenSSL``:" 13430msgstr "``OpenSSL`` で証明書を生成するには、以下を実行します。" 13431 13432#: ../../rst/user_guide/windows_winrm.rst:142 13433msgid "To generate a certificate with ``New-SelfSignedCertificate``:" 13434msgstr "``New-SelfSignedCertificate`` で証明書を生成するには、以下を実行します。" 13435 13436#: ../../rst/user_guide/windows_winrm.rst:170 13437msgid "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:``" 13438msgstr "PFX ファイルを pywinrm が使用できる秘密鍵に変換するには、OpenSSL で ``openssl pkcs12 -in cert.pfx -nocerts -nodes -out cert_key.pem -passin pass: -passout pass:`` コマンドを実行します。" 13439 13440#: ../../rst/user_guide/windows_winrm.rst:175 13441msgid "Import a Certificate to the Certificate Store" 13442msgstr "証明書ストアへの証明書のインポート" 13443 13444#: ../../rst/user_guide/windows_winrm.rst:176 13445msgid "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." 13446msgstr "証明書が生成されたら、発行した証明書を ``LocalMachine`` ストアの ``Trusted Root Certificate Authorities`` にインポートし、クライアント証明書の公開鍵を ``LocalMachine`` ストアの ``Trusted People`` ディレクトリーに存在させる必要があります。この例では、発行した証明書と公開鍵の両方が同じものです。" 13447 13448#: ../../rst/user_guide/windows_winrm.rst:182 13449msgid "Following example shows how to import the issuing certificate:" 13450msgstr "以下の例では、発行した証明書をインポートする方法を示します。" 13451 13452#: ../../rst/user_guide/windows_winrm.rst:197 13453msgid "If using ADCS to generate the certificate, then the issuing certificate will already be imported and this step can be skipped." 13454msgstr "ADCS を使用して証明書を生成する場合は、発行する証明書がすでにインポートされているため、この手順は省略できます。" 13455 13456#: ../../rst/user_guide/windows_winrm.rst:200 13457msgid "The code to import the client certificate public key is:" 13458msgstr "クライアント証明書の公開鍵をインポートするコードは以下のとおりです。" 13459 13460#: ../../rst/user_guide/windows_winrm.rst:216 13461msgid "Mapping a Certificate to an Account" 13462msgstr "証明書のアカウントへのマッピング" 13463 13464#: ../../rst/user_guide/windows_winrm.rst:217 13465msgid "Once the certificate has been imported, map it to the local user account::" 13466msgstr "証明書をインポートしたら、これをローカルユーザーアカウントにマッピングします。" 13467 13468#: ../../rst/user_guide/windows_winrm.rst:236 13469msgid "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." 13470msgstr "これが完了したら、ホスト変数 ``ansible_winrm_cert_pem`` に公開鍵のパスを、変数``ansible_winrm_cert_key_pem`` に秘密鍵のパスを設定してください。" 13471 13472#: ../../rst/user_guide/windows_winrm.rst:242 13473msgid "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." 13474msgstr "NTLM は、Microsoft が使用している古い認証メカニズムで、ローカルアカウントとドメインアカウントの両方をサポートしています。NTLM は、WinRM サービスでデフォルトで有効になっているため、使用する前に設定する必要はありません。" 13475 13476#: ../../rst/user_guide/windows_winrm.rst:246 13477msgid "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." 13478msgstr "NTLM は最も簡単に使用できる認証プロトコルであり、``Basic`` 認証よりも安全です。ドメイン環境で稼働している場合は、NTLM の代わりに ``Kerberos`` を使用する必要があります。" 13479 13480#: ../../rst/user_guide/windows_winrm.rst:250 13481msgid "Kerberos has several advantages over using NTLM:" 13482msgstr "Kerberos は NTLM の使用と比較して、以下のような利点があります。" 13483 13484#: ../../rst/user_guide/windows_winrm.rst:252 13485msgid "NTLM is an older protocol and does not support newer encryption protocols." 13486msgstr "NTLM は古いプロトコルであり、新しい暗号化プロトコルをサポートしません。" 13487 13488#: ../../rst/user_guide/windows_winrm.rst:254 13489msgid "NTLM is slower to authenticate because it requires more round trips to the host in the authentication stage." 13490msgstr "NTLM は、認証の段階でホストへのラウンドトリップが多くなるため、認証に時間がかかります。" 13491 13492#: ../../rst/user_guide/windows_winrm.rst:256 13493msgid "Unlike Kerberos, NTLM does not allow credential delegation." 13494msgstr "Kerberos とは異なり、NTLM は認証情報の委譲を許可していません。" 13495 13496#: ../../rst/user_guide/windows_winrm.rst:258 13497msgid "This example shows host variables configured to use NTLM authentication:" 13498msgstr "以下の例では、NTLM 認証を使用するように設定されているホスト変数を示しています。" 13499 13500#: ../../rst/user_guide/windows_winrm.rst:269 13501msgid "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." 13502msgstr "Kerberos は、ドメイン環境で実行する場合に使用する推奨の認証オプションです。Kerberos は、認証情報の委譲や HTTP でのメッセージ暗号化などの機能をサポートしており、WinRM で利用できるより安全なオプションの 1 つです。" 13503 13504#: ../../rst/user_guide/windows_winrm.rst:274 13505msgid "Kerberos requires some additional setup work on the Ansible host before it can be used properly." 13506msgstr "Kerberos を正しく使用するには、Ansible ホスト上でいくつかの追加設定作業が必要です。" 13507 13508#: ../../rst/user_guide/windows_winrm.rst:277 13509msgid "The following example shows host vars configured for Kerberos authentication:" 13510msgstr "以下の例は、Kerberos 認証に設定されたホスト変数を示しています。" 13511 13512#: ../../rst/user_guide/windows_winrm.rst:287 13513msgid "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." 13514msgstr "Ansible バージョン 2.3 以降では、``ansible_user`` と ``ansible_password`` に基づいて Kerberos チケットが作成されます。古いバージョンの Ansible で実行している場合や、``ansible_winrm_kinit_mode`` が ``manual`` の場合は、すでに Kerberos チケットを取得している必要があります。詳細は以下を参照してください。" 13515 13516#: ../../rst/user_guide/windows_winrm.rst:292 13517msgid "There are some extra host variables that can be set::" 13518msgstr "設定可能な追加のホスト変数があります。" 13519 13520#: ../../rst/user_guide/windows_winrm.rst:301 13521msgid "Installing the Kerberos Library" 13522msgstr "Kerberos ライブラリーのインストール" 13523 13524#: ../../rst/user_guide/windows_winrm.rst:302 13525msgid "Some system dependencies that must be installed prior to using Kerberos. The script below lists the dependencies based on the distro:" 13526msgstr "Kerberos を使用する前にインストールする必要があるシステム依存関係があります。以下のスクリプトは、ディストリビューションに基づく依存関係を一覧表示します。" 13527 13528#: ../../rst/user_guide/windows_winrm.rst:328 13529msgid "Once the dependencies have been installed, the ``python-kerberos`` wrapper can be install using ``pip``:" 13530msgstr "依存関係がインストールされたら、``pip`` を使用して ``python-kerberos`` ラッパーをインストールできます。" 13531 13532#: ../../rst/user_guide/windows_winrm.rst:337 13533msgid "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." 13534msgstr "Ansible はこれまで、``pywinrm`` を通じて Kerberos 認証をサポートしてきましたが、オプション機能やより安全なオプションは、``pywinrm`` ライブラリーまたは ``pykerberos`` ライブラリーの新しいバージョンでのみ利用できる場合があります。警告やエラーが発生した場合は、各バージョンを最新のものにアップグレードすることが推奨されます。この作業は、``pip`` のようなツールや、``dnf``、``yum``、``apt`` のようなシステムパッケージマネージャーで行うことができますが、パッケージ名や利用可能なバージョンはツールによって異なる場合があります。" 13535 13536#: ../../rst/user_guide/windows_winrm.rst:347 13537msgid "Configuring Host Kerberos" 13538msgstr "ホスト Kerberos の設定" 13539 13540#: ../../rst/user_guide/windows_winrm.rst:348 13541msgid "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." 13542msgstr "依存関係がインストールされたら、Kerberos がドメインと通信できるように設定する必要があります。この設定は、上のスクリプトでパッケージと一緒にインストールされた ``/etc/krb5.conf`` ファイルを通じて行われます。" 13543 13544#: ../../rst/user_guide/windows_winrm.rst:352 13545msgid "To configure Kerberos, in the section that starts with:" 13546msgstr "Kerberos を設定するには、以下で始まるセクションで行います。" 13547 13548#: ../../rst/user_guide/windows_winrm.rst:358 13549msgid "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:" 13550msgstr "プライマリーおよびセカンダリーの Active Directory ドメインコントローラーの完全なドメイン名と完全修飾ドメイン名を追加します。以下のようになるはずです。" 13551 13552#: ../../rst/user_guide/windows_winrm.rst:370 13553msgid "In the section that starts with:" 13554msgstr "以下で始まるセクションで、" 13555 13556#: ../../rst/user_guide/windows_winrm.rst:376 13557msgid "Add a line like the following for each domain that Ansible needs access for:" 13558msgstr "Ansible がアクセスする必要のある各ドメインに以下のような行を追加します。" 13559 13560#: ../../rst/user_guide/windows_winrm.rst:383 13561msgid "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." 13562msgstr "このファイルでは、デフォルトのドメインなど、その他の設定を行うことができます。詳細は `krb5.conf <https://web.mit.edu/kerberos/krb5-1.12/doc/admin/conf_files/krb5_conf.html>`_ を参照してください。" 13563 13564#: ../../rst/user_guide/windows_winrm.rst:388 13565msgid "Automatic Kerberos Ticket Management" 13566msgstr "Kerberos チケットの自動管理" 13567 13568#: ../../rst/user_guide/windows_winrm.rst:389 13569msgid "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." 13570msgstr "Ansible バージョン 2.3 以降では、ホストに ``ansible_user`` と``ansible_password`` の両方が指定された場合は、デフォルトで Kerberos チケットを自動的に管理します。このプロセスでは、各ホストの一時的な認証情報キャッシュに新しいチケットが作成されます。これは、チケットが失効する可能性を最小限にするために、各タスクが実行される前に行われます。一時的な認証情報キャッシュは、各タスクが完了すると削除され、デフォルトの認証情報キャッシュに干渉することはありません。" 13571 13572#: ../../rst/user_guide/windows_winrm.rst:396 13573msgid "To disable automatic ticket management, set ``ansible_winrm_kinit_mode=manual`` via the inventory." 13574msgstr "チケットの自動管理を無効にするには、インベントリーから ``ansible_winrm_kinit_mode=manual`` を設定してください。" 13575 13576#: ../../rst/user_guide/windows_winrm.rst:399 13577msgid "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." 13578msgstr "自動チケット管理には、制御ホストシステムのパスに標準の ``kinit`` バイナリーが必要です。別の場所やバイナリー名を指定するには、``ansible_winrm_kinit_cmd`` hostvar に MIT krbv5 ``kinit`` 互換バイナリーへの完全修飾パスを設定します。" 13579 13580#: ../../rst/user_guide/windows_winrm.rst:405 13581msgid "Manual Kerberos Ticket Management" 13582msgstr "Kerberos チケットの手動管理" 13583 13584#: ../../rst/user_guide/windows_winrm.rst:406 13585msgid "To manually manage Kerberos tickets, the ``kinit`` binary is used. To obtain a new ticket the following command is used:" 13586msgstr "Kerberos チケットを手動で管理するには、``kinit`` バイナリーを使用します。新しいチケットを取得するには、以下のコマンドを使用します。" 13587 13588#: ../../rst/user_guide/windows_winrm.rst:413 13589msgid "The domain must match the configured Kerberos realm exactly, and must be in upper case." 13590msgstr "ドメインは設定された Kerberos レルムに完全に一致し、大文字である必要があります。" 13591 13592#: ../../rst/user_guide/windows_winrm.rst:415 13593msgid "To see what tickets (if any) have been acquired, use the following command:" 13594msgstr "取得したチケット (存在する場合) を確認するには、以下のコマンドを使用します。" 13595 13596#: ../../rst/user_guide/windows_winrm.rst:421 13597msgid "To destroy all the tickets that have been acquired, use the following command:" 13598msgstr "取得したすべてのチケットを破棄するには、以下のコマンドを使用します。" 13599 13600#: ../../rst/user_guide/windows_winrm.rst:428 13601msgid "Troubleshooting Kerberos" 13602msgstr "Kerberos のトラブルシューティング" 13603 13604#: ../../rst/user_guide/windows_winrm.rst:429 13605msgid "Kerberos is reliant on a properly-configured environment to work. To troubleshoot Kerberos issues, ensure that:" 13606msgstr "Kerberos は、適切に構成された環境でなければ動作しません。Kerberos の問題をトラブルシューティングするには、以下を確認してください。" 13607 13608#: ../../rst/user_guide/windows_winrm.rst:432 13609msgid "The hostname set for the Windows host is the FQDN and not an IP address." 13610msgstr "Windows ホストのホスト名には、IP アドレスではなく FQDN であることを確認します。" 13611 13612#: ../../rst/user_guide/windows_winrm.rst:434 13613msgid "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." 13614msgstr "このドメインでは、DNS の正引きと逆引きが正常に動作しています。これをテストするには、Windows ホストに名前で ping を打ち、``nslookup`` で返された IP アドレスを使用します。IP アドレスに ``nslookup`` を使用すると、同じ名前が返されるはずです。" 13615 13616#: ../../rst/user_guide/windows_winrm.rst:439 13617msgid "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." 13618msgstr "Ansible ホストの時計はドメインコントローラーと同期します。Kerberos は時間に敏感で、わずかな時計のずれにより、チケット生成プロセスが失敗する可能性があります。" 13619 13620#: ../../rst/user_guide/windows_winrm.rst:443 13621msgid "Ensure that the fully qualified domain name for the domain is configured in the ``krb5.conf`` file. To check this, run::" 13622msgstr "ドメインの完全修飾ドメイン名が、``krb5.conf`` ファイルに設定されていることを確認してください。これを確認するには、次のように実行します。" 13623 13624#: ../../rst/user_guide/windows_winrm.rst:449 13625msgid "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." 13626msgstr "``klist`` で返されたドメイン名が要求されたものと異なる場合は、エイリアスが使用されています。``krb5.conf`` ファイルを更新して、エイリアスではなく完全修飾ドメイン名を使用する必要があります。" 13627 13628#: ../../rst/user_guide/windows_winrm.rst:453 13629msgid "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." 13630msgstr "デフォルトの kerberos ツールが置き換えられたり変更されたりした場合 (いくつかの IdM ソリューションではそうなっているかもしれません)、Python Kerberos ライブラリーをインストールしたりアップグレードしたりする際に問題が発生する可能性があります。本ガイドの作成時点では、このライブラリーは ``pykerberos`` と呼ばれ、MIT と Heimdal Kerberos ライブラリーの両方で動作することが知られています。``pykerberos`` のインストール問題を解決するには、Kerberos のシステム依存性が満たされていることを確認し (参照: `Installing the Kerberos Library`_)、PATH 環境変数からカスタム Kerberos ツールパスを削除し、Python Kerberos ライブラリーパッケージのインストールを再試行してください。" 13631 13632#: ../../rst/user_guide/windows_winrm.rst:457 13633msgid "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." 13634msgstr "CredSSP 認証は、認証情報の委譲を可能にする新しい認証プロトコルになります。これは、認証が成功した後のユーザー名とパスワードを暗号化し、それを CredSSP プロトコルを使用してサーバーに送信することで実現しています。" 13635 13636#: ../../rst/user_guide/windows_winrm.rst:462 13637msgid "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." 13638msgstr "ユーザー名とパスワードをサーバーに送信してダブルホップ認証に使用するため、Windows ホストが通信するホストが漏洩しておらず、信頼できることを確認してください。" 13639 13640#: ../../rst/user_guide/windows_winrm.rst:466 13641msgid "CredSSP can be used for both local and domain accounts and also supports message encryption over HTTP." 13642msgstr "CredSSP は、ローカルアカウントとドメインアカウントの両方に使用でき、HTTPでのメッセージ暗号化にも対応しています。" 13643 13644#: ../../rst/user_guide/windows_winrm.rst:469 13645msgid "To use CredSSP authentication, the host vars are configured like so:" 13646msgstr "CredSSP 認証を使用するには、以下のようにホスト変数を設定します。" 13647 13648#: ../../rst/user_guide/windows_winrm.rst:478 13649msgid "There are some extra host variables that can be set as shown below::" 13650msgstr "以下のように設定できる追加のホスト変数があります。" 13651 13652#: ../../rst/user_guide/windows_winrm.rst:482 13653msgid "CredSSP authentication is not enabled by default on a Windows host, but can be enabled by running the following in PowerShell:" 13654msgstr "CredSSP 認証は、Windows ホストではデフォルトでは有効になっていませんが、PowerShell で以下を実行することで有効にすることができます。" 13655 13656#: ../../rst/user_guide/windows_winrm.rst:490 13657msgid "Installing CredSSP Library" 13658msgstr "CredSSP ライブラリーのインストール" 13659 13660#: ../../rst/user_guide/windows_winrm.rst:492 13661msgid "The ``requests-credssp`` wrapper can be installed using ``pip``:" 13662msgstr "``requests-credssp`` ラッパーは、``pip`` を使用してインストールできます。" 13663 13664#: ../../rst/user_guide/windows_winrm.rst:499 13665msgid "CredSSP and TLS 1.2" 13666msgstr "CredSSP および TLS 1.2" 13667 13668#: ../../rst/user_guide/windows_winrm.rst:500 13669msgid "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." 13670msgstr "デフォルトでは、``requests-credssp`` ライブラリーは、TLS 1.2 プロトコルで認証するように設定されています。TLS 1.2 は、Windows Server 2012 および Windows 8 と、それ以降のリリースでは、デフォルトでインストールされ、有効になっています。" 13671 13672#: ../../rst/user_guide/windows_winrm.rst:504 13673msgid "There are two ways that older hosts can be used with CredSSP:" 13674msgstr "古いホストを CredSSP で使用できる方法は 2 つあります。" 13675 13676#: ../../rst/user_guide/windows_winrm.rst:506 13677msgid "Install and enable a hotfix to enable TLS 1.2 support (recommended for Server 2008 R2 and Windows 7)." 13678msgstr "TLS 1.2 のサポートを有効にする Hotfix をインストールして有効にしてください (Server 2008 R2 および Windows 7 で推奨)。" 13679 13680#: ../../rst/user_guide/windows_winrm.rst:509 13681msgid "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" 13682msgstr "インベントリーに ``ansible_winrm_credssp_disable_tlsv1_2=True`` を設定して、TLS 1.0 で実行するように設定します。これは、TLS 1.2 に対応していない Windows Server 2008 に接続する際の唯一の選択肢です。" 13683 13684#: ../../rst/user_guide/windows_winrm.rst:513 13685msgid "See :ref:`winrm_tls12` for more information on how to enable TLS 1.2 on the Windows host." 13686msgstr "Windows ホストで TLS 1.2 を有効にする方法は、「:ref:`winrm_tls12`」を参照してください。" 13687 13688#: ../../rst/user_guide/windows_winrm.rst:517 13689msgid "Set CredSSP Certificate" 13690msgstr "CredSSP 証明書の設定" 13691 13692#: ../../rst/user_guide/windows_winrm.rst:518 13693msgid "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." 13694msgstr "CredSSP は、TLS プロトコルで認証情報を暗号化して動作し、デフォルトでは自己署名証明書を使用します。WinRM サービス構成の``CertificateThumbprint`` オプションを使用して、別の証明書のサムプリントを指定することができます。" 13695 13696#: ../../rst/user_guide/windows_winrm.rst:521 13697msgid "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." 13698msgstr "この証明書構成は、WinRM リスナーの証明書とは独立しています。CredSSP では、メッセージトランスポートは依然として WinRM リスナーを介して行われますが、チャネル内の TLS 暗号化メッセージにはサービスレベル証明書が使用されます。" 13699 13700#: ../../rst/user_guide/windows_winrm.rst:525 13701msgid "To explicitly set the certificate to use for CredSSP::" 13702msgstr "CredSSP に使用する証明書を明示的に設定するには、以下を実行します。" 13703 13704#: ../../rst/user_guide/windows_winrm.rst:535 13705msgid "Non-Administrator Accounts" 13706msgstr "管理者以外のアカウント" 13707 13708#: ../../rst/user_guide/windows_winrm.rst:536 13709msgid "WinRM is configured by default to only allow connections from accounts in the local ``Administrators`` group. This can be changed by running:" 13710msgstr "WinRM は、デフォルトで、ローカルの ``Administrators`` グループのアカウントからの接続のみを許可するように設定されています。これは、以下を実行して変更できます。" 13711 13712#: ../../rst/user_guide/windows_winrm.rst:543 13713msgid "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." 13714msgstr "これにより、ACL エディターが表示され、新しいユーザーまたはグループを追加できます。WinRM でコマンドを実行するには、ユーザーおよびグループに少なくとも ``Read`` および ``Execute`` パーミッションが有効になっている必要があります。" 13715 13716#: ../../rst/user_guide/windows_winrm.rst:547 13717msgid "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." 13718msgstr "WinRM では、管理者以外のアカウントを使用することもできますが、一般的なサーバー管理作業では、ある程度の管理者権限が必要となるため、実用性は限られてしまいます。" 13719 13720#: ../../rst/user_guide/windows_winrm.rst:551 13721msgid "WinRM Encryption" 13722msgstr "WinRM 暗号化" 13723 13724#: ../../rst/user_guide/windows_winrm.rst:552 13725msgid "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." 13726msgstr "デフォルトでは、WinRM は、暗号化されていないチャンネル上で実行されると、動作に失敗します。WinRM プロトコルは、TLS over HTTP (HTTPS) を使用している場合や、メッセージレベルの暗号化を使用している場合は、チャンネルが暗号化されているとみなします。WinRM を TLS で使用することは、すべての認証オプションで動作するため、推奨されるオプションですが、WinRM リスナーで証明書を作成して使用する必要があります。" 13727 13728#: ../../rst/user_guide/windows_winrm.rst:558 13729msgid "The ``ConfigureRemotingForAnsible.ps1`` creates a self-signed certificate and creates the listener with that certificate. If in a domain environment, ADCS can also create a certificate for the host that is issued by the domain itself." 13730msgstr "``ConfigureRemotingForAnsible.ps1`` は、自己署名証明書を作成し、その証明書でリスナーを作成します。ドメイン環境であれば、ADCS はドメイン自体が発行するホスト用の証明書を作成することもできる。" 13731 13732#: ../../rst/user_guide/windows_winrm.rst:562 13733msgid "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." 13734msgstr "HTTPS を使用することができない場合は、認証オプションが ``NTLM``、``Kerberos``、または ``CredSSP`` であれば、HTTP を使用することができます。これらのプロトコルは、WinRM のペイロードを独自の暗号化方式で暗号化してからサーバーに送信します。メッセージレベルの暗号化は、HTTPS で実行する場合には使用されません。トランスポートとメッセージの両方の暗号化が必要な場合は、ホスト変数に ``ansible_winrm_message_encryption=always`` を設定してください。" 13735 13736#: ../../rst/user_guide/windows_winrm.rst:570 13737msgid "Message encryption over HTTP requires pywinrm>=0.3.0." 13738msgstr "HTTPでのメッセージ暗号化には 0.3.0 以上の pywinrm が必要です。" 13739 13740#: ../../rst/user_guide/windows_winrm.rst:572 13741msgid "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::" 13742msgstr "最後の手段として、Windows ホストの暗号化要件を無効にすることができます。これは、Ansible から送信されたものはすべて閲覧、操作でき、また同じネットワーク上の誰もがリモートセッションを完全に乗っ取ることができるため、開発やデバッグの目的でのみ使用してください。暗号化を無効にするには、以下の手順に従います。" 13743 13744#: ../../rst/user_guide/windows_winrm.rst:580 13745msgid "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." 13746msgstr "どうしても必要な場合を除き、暗号化チェックを無効にしないでください。暗号化チェックを無効にすると、認証情報やファイルなどの機密情報がネットワーク上の他の人に傍受される可能性があります。" 13747 13748#: ../../rst/user_guide/windows_winrm.rst:585 13749msgid "Inventory Options" 13750msgstr "インベントリーオプション" 13751 13752#: ../../rst/user_guide/windows_winrm.rst:586 13753msgid "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." 13754msgstr "Ansible の Windows サポートは、リモートホストのユーザー名、パスワード、接続タイプを示すいくつかの標準変数に依存しています。これらの変数はインベントリーで最も簡単に設定できますが、``host_vars``/``group_vars`` レベルで設定することもできます。" 13755 13756#: ../../rst/user_guide/windows_winrm.rst:591 13757msgid "When setting up the inventory, the following variables are required:" 13758msgstr "インベントリーを設定する際に、以下の変数が必要になります。" 13759 13760#: ../../rst/user_guide/windows_winrm.rst:606 13761msgid "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``." 13762msgstr "上記の変数を使用すると、Ansible は HTTPS を通じて Basic 認証で Windows ホストに接続します。``ansible_user`` に ``username@MY.DOMAIN.COM`` のような UPN 値がある場合は、``ansible_winrm_transport`` が ``kerberos`` 以外に設定されていない限り、認証オプションは自動的に Kerberos の使用を試みます。" 13763 13764#: ../../rst/user_guide/windows_winrm.rst:612 13765msgid "The following custom inventory variables are also supported for additional configuration of WinRM connections:" 13766msgstr "以下のカスタムインベントリー変数も、WinRM 接続の追加設定のためにサポートされています。" 13767 13768#: ../../rst/user_guide/windows_winrm.rst:615 13769msgid "``ansible_port``: The port WinRM will run over, HTTPS is ``5986`` which is the default while HTTP is ``5985``" 13770msgstr "``ansible_port``: WinRM が実行するポートです。HTTPS のデフォルトは ``5986`` で、HTTP のデフォルトは ``5985`` です。" 13771 13772#: ../../rst/user_guide/windows_winrm.rst:618 13773msgid "``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``" 13774msgstr "``ansible_winrm_scheme``: WinRM 接続に使用する接続スキーム (``http`` または ``https``) を指定します。Ansible は、``ansible_port`` が ``5985`` に指定されていない限り、デフォルトで ``https`` を使用します。" 13775 13776#: ../../rst/user_guide/windows_winrm.rst:622 13777msgid "``ansible_winrm_path``: Specify an alternate path to the WinRM endpoint, Ansible uses ``/wsman`` by default" 13778msgstr "``ansible_winrm_path``: WinRMエンドポイントへの別のパスを指定します。Ansibleはデフォルトで ``/wsman`` を使用します。" 13779 13780#: ../../rst/user_guide/windows_winrm.rst:625 13781msgid "``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" 13782msgstr "``ansible_winrm_realm``: Kerberos 認証に使用するレルムを指定します。``ansible_user`` に ``@`` が含まれる場合、Ansible はデフォルトで ``@`` の後にユーザー名の一部を使用します。" 13783 13784#: ../../rst/user_guide/windows_winrm.rst:629 13785msgid "``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``" 13786msgstr "``ansible_winrm_transport``: 1 つ以上の認証トランスポートオプションをコンマ区切りのリストで指定します。デフォルトでは、``kerberos`` モジュールがインストールされていてレルムが定義されている場合、Ansible は ``kerberos, basic`` を使用し、それ以外の場合は ``plaintext`` になります。" 13787 13788#: ../../rst/user_guide/windows_winrm.rst:634 13789msgid "``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``" 13790msgstr "``ansible_winrm_server_cert_validation``: サーバー証明書の検証モード (``ignore`` または``validate``) を指定します。Ansible のデフォルトは、Python 2.7.9 以降では ``validate`` で、これは Windows の自己署名証明書に対して証明書の検証エラーが発生します。WinRM リスナーで検証可能な証明書が設定されていない場合は、この設定を ``ignore`` に設定する必要があります。" 13791 13792#: ../../rst/user_guide/windows_winrm.rst:641 13793msgid "``ansible_winrm_operation_timeout_sec``: Increase the default timeout for WinRM operations, Ansible uses ``20`` by default" 13794msgstr "``ansible_winrm_operation_timeout_sec``: WinRM 操作のデフォルトタイムアウトを増やすと、Ansible はデフォルトで ``20`` を使用します。" 13795 13796#: ../../rst/user_guide/windows_winrm.rst:644 13797msgid "``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" 13798msgstr "``ansible_winrm_read_timeout_sec``: WinRM の読み取りタイムアウトを増やします。Ansible はデフォルトで ``30`` を使用します。ネットワークの問題が断続的に発生し、読み取りタイムアウトのエラーが発生し続ける場合に有効です。" 13799 13800#: ../../rst/user_guide/windows_winrm.rst:648 13801msgid "``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" 13802msgstr "``ansible_winrm_message_encryption``: 使用するメッセージ暗号化操作 (``auto``、``always``、``never``) を指定します。Ansible はデフォルトで``auto`` を使用します。``auto`` は、``ansible_winrm_scheme`` が``http`` および ``ansible_winrm_transport`` がメッセージ暗号化をサポートしている場合に限り、メッセージ暗号化が使用されることを意味します。``always`` は、メッセージ暗号化が常に使用されることを意味し、``never`` は、メッセージ暗号化が決して使用されないことを意味します。" 13803 13804#: ../../rst/user_guide/windows_winrm.rst:655 13805msgid "``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." 13806msgstr "``ansible_winrm_ca_trust_path``: ``certifi`` モジュールで使用されているものとは異なる cacert コンテナーを指定するために使用します。詳細は、「HTTPS 証明書の検証」セクションを参照してください。" 13807 13808#: ../../rst/user_guide/windows_winrm.rst:659 13809msgid "``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``)." 13810msgstr "``ansible_winrm_send_cbt``: ``ntlm`` または ``kerberos`` を HTTPS で使用する場合、認証ライブラリーは、中間者攻撃を緩和するためにチャネルバインディングトークンの送信を試みます。このフラグは、これらのバインディングを送信するかどうかを制御します (デフォルト: ``yes``)。" 13811 13812#: ../../rst/user_guide/windows_winrm.rst:664 13813msgid "``ansible_winrm_*``: Any additional keyword arguments supported by ``winrm.Protocol`` may be provided in place of ``*``" 13814msgstr "``ansible_winrm_*``:``winrm.Protocol`` でサポートされている任意の追加キーワード引数は、代わりに ``*`` で指定できます。" 13815 13816#: ../../rst/user_guide/windows_winrm.rst:667 13817msgid "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." 13818msgstr "さらに、各認証オプションで設定する必要がある特定の変数もあります。詳細は、上記の認証に関するセクションを参照してください。" 13819 13820#: ../../rst/user_guide/windows_winrm.rst:670 13821msgid "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." 13822msgstr "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 では警告なしに無視されます。" 13823 13824#: ../../rst/user_guide/windows_winrm.rst:677 13825msgid "``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``." 13826msgstr "``ansible_winrm_message_encryption`` は、TLS 上で行われるトランスポート暗号化とは異なります。WinRM ペイロードは、``ansible_winrm_message_encryption=never`` であっても、HTTPS で実行された場合でも TLS で暗号化されます。" 13827 13828#: ../../rst/user_guide/windows_winrm.rst:682 13829msgid "IPv6 Addresses" 13830msgstr "IPv6 アドレス" 13831 13832#: ../../rst/user_guide/windows_winrm.rst:683 13833msgid "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." 13834msgstr "IPv4 アドレスやホスト名の代わりに、IPv6 アドレスを使用することができます。このオプションは通常、インベントリーで設定します。Ansible は、`ipaddress <https://docs.python.org/3/library/ipaddress.html>`_ パッケージを使用してアドレスの解析を試み、pywinrm に正しく渡します。" 13835 13836#: ../../rst/user_guide/windows_winrm.rst:688 13837msgid "When defining a host using an IPv6 address, just add the IPv6 address as you would an IPv4 address or hostname:" 13838msgstr "IPv6 アドレスを使用してホストを定義する場合は、IPv4 アドレスやホスト名と同じように IPv6 アドレスを追加するだけです。" 13839 13840#: ../../rst/user_guide/windows_winrm.rst:702 13841msgid "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." 13842msgstr "ipaddress ライブラリーは Python 3.x にのみデフォルトで含まれています。Python 2.7 で IPv6 アドレスを使用するには、バックポートされたパッケージをインストールする ``pip install ipaddress`` を必ず実行してください。" 13843 13844#: ../../rst/user_guide/windows_winrm.rst:707 13845msgid "HTTPS Certificate Validation" 13846msgstr "HTTPS 証明書の検証" 13847 13848#: ../../rst/user_guide/windows_winrm.rst:708 13849msgid "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." 13850msgstr "TLS プロトコルの一環として、証明書が検証され、ホストがサブジェクトと一致し、クライアントがサーバー証明書の発行者を信頼していることが確認されます。自己署名証明書を使用したり、``ansible_winrm_server_cert_validation: ignore`` を設定したりすると、これらのセキュリティーメカニズムが回避されます。自己署名証明書には常に ``ignore`` フラグが必要ですが、認証局から発行された証明書は検証されます。" 13851 13852#: ../../rst/user_guide/windows_winrm.rst:716 13853msgid "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." 13854msgstr "ドメイン環境で HTTPS リスナーをセットアップする一般的な方法の 1 つは、Active Directory Certificate Service (AD CS) を使用することである。AD CS は、CSR (Certificate Signing Request) から署名付き証明書を生成するために使用されます。WinRM HTTPS リスナーが AD CS のような別の機関によって署名された証明書を使用している場合、Ansible は TLS ハンドシェイクの一部としてその発行者を信頼するように設定することができます。" 13855 13856#: ../../rst/user_guide/windows_winrm.rst:723 13857msgid "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." 13858msgstr "AD CS のような認証局 (CA) を Ansible に信頼させるには、CA の発行者証明書を PEM エンコード証明書としてエクスポートします。この証明書は、Ansible コントローラーのローカルにコピーして、証明書検証のソースとして使用することができます (CA チェーンとも呼ばれます)。" 13859 13860#: ../../rst/user_guide/windows_winrm.rst:728 13861msgid "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>`_." 13862msgstr "CA チェーンには、単一または複数の発行者証明書を含めることができ、各エントリーは改行されます。認証プロセスの一部としてカスタム CA チェーンを使用するには、``ansible_winrm_ca_trust_path`` にファイルのパスを設定します。この変数が設定されていない場合は、Python パッケージ `certifi <https://github.com/certifi/python-certifi>`_ のインストールパスにあるデフォルトの CAチ ェーンが使用されます。" 13863 13864#: ../../rst/user_guide/windows_winrm.rst:735 13865msgid "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." 13866msgstr "各 HTTP コールは Python リクエストライブラリーによって行われ、システムに組み込まれた証明書ストアを信頼機関として使用しません。サーバーの証明書発行者がシステムのトラストストアに追加されていない場合、証明書の検証は失敗します。" 13867 13868#: ../../rst/user_guide/windows_winrm.rst:743 13869msgid "TLS 1.2 Support" 13870msgstr "TLS 1.2 のサポート" 13871 13872#: ../../rst/user_guide/windows_winrm.rst:744 13873msgid "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::" 13874msgstr "WinRM は HTTP プロトコル上で動作するため、HTTPS を使用するということは、WinRM メッセージの暗号化に TLS プロトコルが使用されることを意味します。TLS は、クライアントとサーバーの両方で利用可能な、最適なプロトコルと暗号スイートを自動的に取り決めようとします。一致するものが見つからない場合、Ansible は次のようなメッセージでエラーになります。" 13875 13876#: ../../rst/user_guide/windows_winrm.rst:752 13877msgid "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." 13878msgstr "これは、Windows ホストが TLS v1.2 をサポートするように設定されていない場合ですが、Ansible コントローラーに古い OpenSSL バージョンがインストールされていることも意味します。" 13879 13880#: ../../rst/user_guide/windows_winrm.rst:756 13881msgid "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." 13882msgstr "Windows 8 および Windows Server 2012 には、デフォルトで TLS v1.2 がインストールされ、有効になっていますが、Server 2008 R2 や Windows 7 などの古いホストは手動で有効にする必要があります。" 13883 13884#: ../../rst/user_guide/windows_winrm.rst:760 13885msgid "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." 13886msgstr "Server 2008 の TLS 1.2 パッチにはバグがあり、Ansible の Windows ホストへの接続が停止してしまいます。これは、Server 2008 が TLS 1.2 を使用するように設定できないことを意味します。Server 2008 R2 とWindows 7 はこの問題の影響を受けず、TLS 1.2 を使用できます。" 13887 13888#: ../../rst/user_guide/windows_winrm.rst:765 13889msgid "To verify what protocol the Windows host supports, you can run the following command on the Ansible controller::" 13890msgstr "Windows ホストが対応しているプロトコルを確認するには、Ansible コントローラーで以下のコマンドを実行します。" 13891 13892#: ../../rst/user_guide/windows_winrm.rst:770 13893msgid "The output will contain information about the TLS session and the ``Protocol`` line will display the version that was negotiated::" 13894msgstr "出力には TLS セッションに関する情報が含まれ、``Protocol`` 行にはネゴシエートされたバージョンが表示されます。" 13895 13896#: ../../rst/user_guide/windows_winrm.rst:806 13897msgid "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:" 13898msgstr "ホストが ``TLSv1`` を返す場合は、TLS v1.2 が有効になるように設定する必要があります。これは、次の PowerShell スクリプトを実行することで行うことができます。" 13899 13900#: ../../rst/user_guide/windows_winrm.rst:831 13901msgid "The below Ansible tasks can also be used to enable TLS v1.2:" 13902msgstr "以下の Ansible タスクを使用して TLS v1.2 を有効にすることもできます。" 13903 13904#: ../../rst/user_guide/windows_winrm.rst:861 13905msgid "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." 13906msgstr "TLS プロトコルや、Windows ホストが提供する暗号スイートを設定する方法は他にもあります。これらの設定を管理するための GUI を提供するツールとして、Nartac Software 社の `IIS Crypto <https://www.nartac.com/Products/IISCrypto/>`_ があります。" 13907 13908#: ../../rst/user_guide/windows_winrm.rst:868 13909msgid "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:" 13910msgstr "WinRM プロトコルの設計上、WinRM を使用する際にはいくつかの制限があり、Ansible の Playbook を作成する際に問題となることがあります。これには次のようなものがあります。" 13911 13912#: ../../rst/user_guide/windows_winrm.rst:872 13913msgid "Credentials are not delegated for most authentication types, which causes authentication errors when accessing network resources or installing certain programs." 13914msgstr "ほとんどの認証タイプで認証情報が委譲されていないため、ネットワークリソースへのアクセスや特定のプログラムのインストール時に認証エラーが発生することがありました。" 13915 13916#: ../../rst/user_guide/windows_winrm.rst:876 13917msgid "Many calls to the Windows Update API are blocked when running over WinRM." 13918msgstr "WinRM 経由で実行すると、Windows Update API への多くの呼び出しがブロックされます。" 13919 13920#: ../../rst/user_guide/windows_winrm.rst:878 13921msgid "Some programs fail to install with WinRM due to no credential delegation or because they access forbidden Windows API like WUA over WinRM." 13922msgstr "認証情報の委譲や、WUA over WinRM などの禁止されている Windows API へのアクセスにより、一部のプログラムは WinRM でインストールできない場合があります。" 13923 13924#: ../../rst/user_guide/windows_winrm.rst:881 13925msgid "Commands under WinRM are done under a non-interactive session, which can prevent certain commands or executables from running." 13926msgstr "WinRM のコマンドは非対話型セッションで実行されるため、特定のコマンドや実行ファイルが実行できない場合があります。" 13927 13928#: ../../rst/user_guide/windows_winrm.rst:884 13929msgid "You cannot run a process that interacts with ``DPAPI``, which is used by some installers (like Microsoft SQL Server)." 13930msgstr "一部のインストーラー (Microsoft SQL Server など) が使用する ``DPAPI`` と対話するプロセスを実行することはできません。" 13931 13932#: ../../rst/user_guide/windows_winrm.rst:887 13933msgid "Some of these limitations can be mitigated by doing one of the following:" 13934msgstr "この制限の一部は、以下のいずれかを実行して軽減できます。" 13935 13936#: ../../rst/user_guide/windows_winrm.rst:889 13937msgid "Set ``ansible_winrm_transport`` to ``credssp`` or ``kerberos`` (with ``ansible_winrm_kerberos_delegation=true``) to bypass the double hop issue and access network resources" 13938msgstr "ダブルホップ問題を回避してネットワークリソースにアクセスするために、``ansible_winrm_transport`` を``credssp`` または``kerberos`` (``ansible_winrm_kerberos_delegation=true`` を使用) に設定します。" 13939 13940#: ../../rst/user_guide/windows_winrm.rst:893 13941msgid "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" 13942msgstr "``become`` を使用すると、すべての WinRM 制限を回避して、ローカルと同様にコマンドを実行できます。``credssp`` のような認証トランスポートを使用する場合とは異なり、非対話型の制限や、WUA や DPAPI などの API の制限も解除されます。" 13943 13944#: ../../rst/user_guide/windows_winrm.rst:898 13945msgid "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." 13946msgstr "``win_scheduled_task`` モジュールで作成されるコマンドを実行するために、スケジュールされたタスクを使用します。``become`` と同様に、WinRM の制限をすべて回避しますが、実行できるのはコマンドのみで、モジュールは実行できません。" 13947 13948#~ msgid "`webchat.freenode.net <https://webchat.freenode.net>`_" 13949#~ msgstr "`webchat.freenode.net <https://webchat.freenode.net>`_" 13950 13951#~ msgid "`irc.freenode.net <http://irc.freenode.net>`_" 13952#~ msgstr "`irc.freenode.net <http://irc.freenode.net>`_" 13953 13954#~ msgid "suboptions" 13955#~ msgstr "suboptions" 13956 13957