path: root/docs/docsite/rst/locales/ja/LC_MESSAGES/playbook_guide.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) Ansible project contributors
# This file is distributed under the same license as the Ansible package.
# FIRST AUTHOR <EMAIL@ADDRESS>, 2022.
#
msgid ""
msgstr ""
"Project-Id-Version: Ansible devel\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2022-10-05 09:34+0200\n"
"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=utf-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Generated-By: Babel 2.8.1\n"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:4
msgid "Manipulating data"
msgstr "データの操作"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:6
msgid "In many cases, you need to do some complex operation with your variables, while Ansible is not recommended as a data processing/manipulation tool, you can use the existing Jinja2 templating in conjunction with the many added Ansible filters, lookups and tests to do some very complex transformations."
msgstr "多くの場合あ、変数を使用して複雑な操作を行う必要がありますが、Ansible はデータ処理/操作ツールとしてはお勧めできませんが、既存の Jinja2 テンプレートと、追加された多くの Ansible フィルター、ルックアップ、テストを併用することで、非常に複雑な変換を行うことができます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:11
msgid "Let's start with a quick definition of each type of plugin:"
msgstr "各プラグイン定義の概要:"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:9
msgid "lookups: Mainly used to query 'external data', in Ansible these were the primary part of loops using the ``with_<lookup>`` construct, but they can be used independently to return data for processing. They normally return a list due to their primary function in loops as mentioned previously. Used with the ``lookup`` or ``query`` Jinja2 operators."
msgstr "lookups: 主に「外部データ」を照会するために使用されます。Ansible では、``with_<lookup>`` 構成を使用したループの主要部分でしたが、処理するデータを返すために独立して使用することもできます。前述のようにループでの主な機能であるため、通常はリストを返します。Jinja2 の演算子 ``lookup`` または ``query`` と一緒に使用します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:10
msgid "filters: used to change/transform data, used with the ``|`` Jinja2 operator."
msgstr "filters: Jinja2 演算子 ``|`` で使用される、データの変更/変換に使用します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:11
msgid "tests: used to validate data, used with the ``is`` Jinja2 operator."
msgstr "tests: Jinja2 演算子 ``is`` で使用されるデータの検証に使用されます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:19
msgid "Loops and list comprehensions"
msgstr "ループおよびリストの競合"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:21
msgid "Most programming languages have loops (``for``, ``while``, and so on) and list comprehensions to do transformations on lists including lists of objects. Jinja2 has a few filters that provide this functionality: ``map``, ``select``, ``reject``, ``selectattr``, ``rejectattr``."
msgstr "ほとんどのプログラミング言語にはループ (``for``、``while`` など) やリスト内包があり、オブジェクトのリストを含むリストの変換を行うことができます。Jinja2 には、このような機能を提供するフィルターがいくつかあります (``map``、``select``、``reject``、``selectattr``、``rejectattr``)。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:23
msgid "map: this is a basic for loop that just allows you to change every item in a list, using the 'attribute' keyword you can do the transformation based on attributes of the list elements."
msgstr "map: これは基本的な for ループで、リストのすべての項目を変更することができます。「attribute」キーワードを使用すると、リスト要素の属性に基づいて変換を行うことができます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:24
msgid "select/reject: this is a for loop with a condition, that allows you to create a subset of a list that matches (or not) based on the result of the condition."
msgstr "select/reject: これは、条件のあるループ用であり、条件の結果に基づいて一致する (または一致しない) リストのサブセットを作成できます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:25
msgid "selectattr/rejectattr: very similar to the above but it uses a specific attribute of the list elements for the conditional statement."
msgstr "selectattr/rejectattr: 上記と非常に似ていますが、条件文に対して list 要素の特定の属性を使用します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:30
msgid "Use a loop to create exponential backoff for retries/until."
msgstr "ループを使用して再試行/一時停止の指数関数的なバックオフを作成します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:44
msgid "Extract keys from a dictionary matching elements from a list"
msgstr "リストから一致するディクショナリー要素からのキー抽出"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:46
msgid "The Python equivalent code would be:"
msgstr "Python と同等のコードは以下のとおりです。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:55
msgid "There are several ways to do it in Ansible, this is just one example:"
msgstr "Ansible で実行する方法はいくつかあります。以下は一例です。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:57
msgid "Way to extract matching keys from a list of dictionaries"
msgstr "ディクショナリーのリストから一致するキーを抽出する方法"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:84
msgid "Results of debug task, a list with the extracted keys"
msgstr "デバッグタスクの結果 (展開した鍵を含むリスト)"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:97
msgid "Get the unique list of values of a variable that vary per host"
msgstr "ホストごとに異なる変数の値の一意のリストを取得"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:107
msgid "Find mount point"
msgstr "マウントポイントの検索"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:109
msgid "In this case, we want to find the mount point for a given path across our machines, since we already collect mount facts, we can use the following:"
msgstr "今回のケースでは、マシン間で指定されたパスのマウントポイントを検索したいのですが、すでにマウントファクトを収集しているため、次のように使用できます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:111
msgid "Use selectattr to filter mounts into list I can then sort and select the last from"
msgstr "selectattr を使用してマウントにフィルターを設定してリストにし、ソートして最後のものを選択します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:128
msgid "Omit elements from a list"
msgstr "リストからの要素を省略"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:130
msgid "The special ``omit`` variable ONLY works with module options, but we can still use it in other ways as an identifier to tailor a list of elements:"
msgstr "特別な ``omit`` 変数は、モジュールオプションでのみ機能しますが、要素のリストを調整するための識別子として、他の方法でも使用することができます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:132
msgid "Inline list filtering when feeding a module option"
msgstr "モジュールオプションのフィード時のインラインリストのフィルタリング"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:146
msgid "Another way is to avoid adding elements to the list in the first place, so you can just use it directly:"
msgstr "もう 1 つの方法は、そもそもリストに要素を追加しないようにして、直接利用することです。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:148
msgid "Using set_fact in a loop to increment a list conditionally"
msgstr "ループで set_fact を使用してリストを条件付きで増分する"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:166
msgid "Combine values from same list of dicts"
msgstr "同じリストのディクショナリーの値を結合する"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:167
msgid "Combining positive and negative filters from examples above, you can get a 'value when it exists' and a 'fallback' when it doesn't."
msgstr "上記の例から正のフィルターと負のフィルターを組み合わせると、「存在する場合の値」と存在しない場合の「フォールバック」を得ることができます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:169
msgid "Use selectattr and rejectattr to get the ansible_host or inventory_hostname as needed"
msgstr "必要に応じて、selectattr および rejectattr を使用して ansible_host または inventory_hostname を取得"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:187
msgid "Custom Fileglob Based on a Variable"
msgstr "変数に基づくカスタムファイルグロブ"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:189
msgid "This example uses `Python argument list unpacking <https://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists>`_ to create a custom list of fileglobs based on a variable."
msgstr "この例では、`Python argument list unpacking <https://docs.python.org/3/tutorial/controlflow.html#unpacking-argument-lists>`_ を使用して、変数に基づいてファイルグロブのカスタムリストを作成します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:191
msgid "Using fileglob with a list based on a variable."
msgstr "変数に基づくリストでファイルグロブの使用"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:212
msgid "Complex Type transformations"
msgstr "複雑なタイプ変換"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:214
msgid "Jinja provides filters for simple data type transformations (``int``, ``bool``, and so on), but when you want to transform data structures things are not as easy. You can use loops and list comprehensions as shown above to help, also other filters and lookups can be chained and used to achieve more complex transformations."
msgstr "Jinja には単純なデータ型変換のためのフィルターが用意されていますが (``int``、``bool`` など)、データ構造を変換したい場合はそう簡単ではありません。上記のようにループやリスト内包を利用することもできますし、他のフィルターやルックアップを連鎖させて使用することで、より複雑な変換を行うことができます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:221
msgid "Create dictionary from list"
msgstr "リストからディクショナリーを作成"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:223
msgid "In most languages it is easy to create a dictionary (a.k.a. map/associative array/hash and so on) from a list of pairs, in Ansible there are a couple of ways to do it and the best one for you might depend on the source of your data."
msgstr "ほとんどの言語では、ペアのリストからディクショナリー (マップ、連想配列、ハッシュなど) を簡単に作成できますが、Ansible ではいくつかの方法があり、データのソースによって最適な方法が異なります。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:226
msgid "These example produces ``{\"a\": \"b\", \"c\": \"d\"}``"
msgstr "これらの例では、``{\"a\": \"b\", \"c\": \"d\"}`` を生成します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:228
msgid "Simple list to dict by assuming the list is [key, value , key, value, ...]"
msgstr "リストが [key, value , key, value, ...] であることを前提とする、ディクショナリーへの単純なリスト"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:236
msgid "It is simpler when we have a list of pairs:"
msgstr "ペアのリストがある場合はより簡単にできる"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:243
msgid "Both end up being the same thing, with ``slice(2)`` transforming ``single_list`` to a ``list_of_pairs`` generator."
msgstr "``slice(2)`` が ``single_list`` を ``list_of_pairs`` ジェネレーターに変換することで、両方とも同じ内容になります。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:247
msgid "A bit more complex, using ``set_fact`` and a ``loop`` to create/update a dictionary with key value pairs from 2 lists:"
msgstr "``set_fact`` と ``loop`` を使用して、2 つのリストからキーと値のペアを持つ、もう少し複雑なディクショナリーを作成/更新します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:249
msgid "Using set_fact to create a dictionary from a set of lists"
msgstr "set_fact を使用してリストのセットからのディクショナリーの作成"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:267
msgid "This results in ``{\"foo\": \"a\", \"var\": \"b\", \"bar\": \"c\"}``."
msgstr "その結果、``{\"foo\": \"a\", \"var\": \"b\", \"bar\": \"c\"}`` になります。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:270
msgid "You can even combine these simple examples with other filters and lookups to create a dictionary dynamically by matching patterns to variable names:"
msgstr "これらの簡単な例を他のフィルターやルックアップと組み合わせて、変数名にパターンを一致させて動的にディクショナリーを作成することもできます。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:272
msgid "Using 'vars' to define dictionary from a set of lists without needing a task"
msgstr "「vars」を使用して、タスクを必要とせずにリストのセットからディクショナリーを定義"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:281
msgid "A quick explanation, since there is a lot to unpack from these two lines:"
msgstr "以下の 2 つの行から展開するため、簡単な説明があります。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:283
msgid "The ``varnames`` lookup returns a list of variables that match \"begin with ``xyz_``\"."
msgstr "``varnames`` ルックアップは、「begin with ``xyz_``」にマッチする変数の一覧を返します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:284
msgid "Then feeding the list from the previous step into the ``vars`` lookup to get the list of values. The ``*`` is used to 'dereference the list' (a pythonism that works in Jinja), otherwise it would take the list as a single argument."
msgstr "そして、前のステップのリストを ``vars`` ルックアップに送り、値のリストを取得します。``*`` は「リストを参照解除する」ために使用されます (Jinja でも通用する python の手法です)。そうでなければ、リストを 1 つの引数として受け取ることになります。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:286
msgid "Both lists get passed to the ``zip`` filter to pair them off into a unified list (key, value, key2, value2, ...)."
msgstr "両方のリストは、``zip`` フィルターに渡され、それらをペアにして統一されたリスト (key, value, key2, value2, ...) にします。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:287
msgid "The dict function then takes this 'list of pairs' to create the dictionary."
msgstr "その後、dict 関数はこの「ペアのリスト」を取得し、ディクショナリーを作成します。"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:290
msgid "An example on how to use facts to find a host's data that meets condition X:"
msgstr "ファクトを使用して、条件 X を満たすホストのデータを検索する例:"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:298
msgid "An example to show a host uptime in days/hours/minutes/seconds (assumes facts where gathered)."
msgstr "ホストのアップタイムを日数/時間/分/秒で表示する例（収集されるファクトを想定）"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:309
#: ../../rst/playbook_guide/playbooks_variables.rst:519
msgid ":ref:`playbooks_filters`"
msgstr ":ref:`playbooks_filters`"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:310
msgid "Jinja2 filters included with Ansible"
msgstr "Ansible に含まれる Jinja2 フィルター"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:311
msgid ":ref:`playbooks_tests`"
msgstr ":ref:`playbooks_tests`"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:312
msgid "Jinja2 tests included with Ansible"
msgstr "Ansible に含まれる Jinja2 テスト"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:313
msgid "`Jinja2 Docs <https://jinja.palletsprojects.com/>`_"
msgstr "`Jinja2 Docs <https://jinja.palletsprojects.com/>`_"

#: ../../rst/playbook_guide/complex_data_manipulation.rst:314
msgid "Jinja2 documentation, includes lists for core filters and tests"
msgstr "Jinja2 ドキュメント。コアフィルターおよびテストの一覧が含まれます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:3
msgid "Playbook Example: Continuous Delivery and Rolling Upgrades"
msgstr "Playbook の例: 継続的デリバリーおよびローリングアップグレード"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:11
msgid "What is continuous delivery?"
msgstr "継続的デリバリーとは"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:13
msgid "Continuous delivery (CD) means frequently delivering updates to your software application."
msgstr "継続的デリバリー (CD) は、ソフトウェアアプリケーションに更新を頻繁に配信することを意味します。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:15
msgid "The idea is that by updating more often, you do not have to wait for a specific timed period, and your organization gets better at the process of responding to change."
msgstr "更新の頻度を上げることで、特定の期間を待つ必要がなくなり、組織は変化に対応するプロセスを改善できるという考え方です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:18
msgid "Some Ansible users are deploying updates to their end users on an hourly or even more frequent basis -- sometimes every time there is an approved code change.  To achieve this, you need tools to be able to quickly apply those updates in a zero-downtime way."
msgstr "Ansible のユーザーの中には、エンドユーザーにアップデートを毎時またはそれ以上の頻度で配布している人がいます。承認されたコード変更があるたびに配布している場合もあります。そのためには、ダウンタイムなしで更新を迅速に適用できるツールが必要です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:21
msgid "This document describes in detail how to achieve this goal, using one of Ansible's most complete example playbooks as a template: lamp_haproxy. This example uses a lot of Ansible features: roles, templates, and group variables, and it also comes with an orchestration playbook that can do zero-downtime rolling upgrades of the web application stack."
msgstr "本ガイドでは、Ansible の最も完成度の高いサンプル Playbook の 1 つである lamp_haproxy をテンプレートとして、この目標を達成する方法を詳細に説明します。この例では、ロール、テンプレート、グループ変数などの Ansible の機能が数多く使用されており、Web アプリケーションスタックのローリングアップグレードをダウンタイムなしで行うことができるオーケストレーション Playbook も付属しています。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:28
msgid "`Click here for the latest playbooks for this example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_."
msgstr "このサンプルに使用する Playbook を取得するには、`こちら <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_ をクリックします。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:31
msgid "The playbooks deploy Apache, PHP, MySQL, Nagios, and HAProxy to a CentOS-based set of servers."
msgstr "Playbook は Apache、PHP、MySQL、Nagios、および HAProxy を CentOS ベースのサーバーセットにデプロイします。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:33
msgid "We're not going to cover how to run these playbooks here. Read the included README in the github project along with the example for that information. Instead, we're going to take a close look at every part of the playbook and describe what it does."
msgstr "ここでは、これらの Playbook を実行する方法については説明しません。その情報については、github プロジェクトに含まれる README をサンプルと一緒に読んでください。その代わり、Playbook の各部分をよく見て、それが何をするのかを説明します。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:39
msgid "Site deployment"
msgstr "サイトのデプロイメント"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:41
msgid "Let's start with ``site.yml``. This is our site-wide deployment playbook. It can be used to initially deploy the site, as well as push updates to all of the servers:"
msgstr "まず、``site.yml`` から始めましょう。これは、サイト全体のデプロイメント Playbook です。この Playbook を使用して、サイトの初期デプロイメントと、すべてのサーバーへの更新のプッシュを行うことができます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:86
msgid "If you're not familiar with terms like playbooks and plays, you should review :ref:`working_with_playbooks`."
msgstr "Playbook やプレイなどの用語に慣れていない場合は、:ref:`working_with_playbooks` を確認してください。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:88
msgid "In this playbook we have 5 plays. The first one targets ``all`` hosts and applies the ``common`` role to all of the hosts. This is for site-wide things like yum repository configuration, firewall configuration, and anything else that needs to apply to all of the servers."
msgstr "この Playbook では 5 つのプレイを紹介します。最初の Playbook は ``all`` のホストを対象とし、``common`` のロールをすべてのホストに適用します。これは、yum リポジトリーの設定やファイアウォールの設定など、サイト全体ですべてのサーバーに適用する必要があるものを対象としています。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:91
msgid "The next four plays run against specific host groups and apply specific roles to those servers. Along with the roles for Nagios monitoring, the database, and the web application, we've implemented a ``base-apache`` role that installs and configures a basic Apache setup. This is used by both the sample web application and the Nagios hosts."
msgstr "次の 4 つのプレイは、特定のホストグループに対して実行し、それらのサーバーに特定のロールを適用します。Nagios 監視、データベース、Web アプリケーションのロールと一緒に、基本的な Apache セットアップをインストールして設定する ``base-apache`` ロールを実装しました。これは、サンプルの Web アプリケーションと Nagios ホストの両方で使用されます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:99
msgid "Reusable content: roles"
msgstr "再利用可能なコンテンツ: ロール"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:101
msgid "By now you should have a bit of understanding about roles and how they work in Ansible. Roles are a way to organize content: tasks, handlers, templates, and files, into reusable components."
msgstr "その結果、ロールおよび Ansible での動作についてある程度理解できるはずです。ロールは、タスク、ハンドラー、テンプレート、ファイルなどのコンテンツを再利用可能なコンポーネントに整理する方法です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:104
msgid "This example has six roles: ``common``, ``base-apache``, ``db``, ``haproxy``, ``nagios``, and ``web``. How you organize your roles is up to you and your application, but most sites will have one or more common roles that are applied to all systems, and then a series of application-specific roles that install and configure particular parts of the site."
msgstr "この例では、``common``、``base-apache``、``db``、``haproxy``、``nagios``、および ``web`` の 6 つのロールがあります。ロールをどのように編成するかは、ニーズおよび使用するアプリケーション次第ですが、ほとんどのサイトでは、すべてのシステムに適用される 1 つまたは複数の共通ロールと、サイトの特定の部分をインストールおよび設定する一連のアプリケーション固有のロールがあります。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:108
msgid "Roles can have variables and dependencies, and you can pass in parameters to roles to modify their behavior. You can read more about roles in the :ref:`playbooks_reuse_roles` section."
msgstr "ロールは変数と依存関係を持つことができ、パラメーターをロールに渡すことでその動作を変更できます。ロールについては、「:ref:`playbooks_reuse_roles`」セクションで詳しく説明しています。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:114
msgid "Configuration: group variables"
msgstr "設定: グループ変数"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:116
msgid "Group variables are variables that are applied to groups of servers. They can be used in templates and in playbooks to customize behavior and to provide easily-changed settings and parameters. They are stored in a directory called ``group_vars`` in the same location as your inventory. Here is lamp_haproxy's ``group_vars/all`` file. As you might expect, these variables are applied to all of the machines in your inventory:"
msgstr "グループ変数は、サーバーのグループに適用される変数です。テンプレートや Playbook で使用することで、動作をカスタマイズしたり、簡単に変更できる設定やパラメーターを提供することができます。グループ変数は、インベントリーと同じ場所にある ``group_vars`` ディレクトリーに保存されます。以下は lamp_haproxy の ``group_vars/all`` ファイルです。ご想像のとおり、これらの変数はインベントリー内のすべてのマシンに適用されます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:127
msgid "This is a YAML file, and you can create lists and dictionaries for more complex variable structures. In this case, we are just setting two variables, one for the port for the web server, and one for the NTP server that our machines should use for time synchronization."
msgstr "これは YAML ファイルですが、リストやディクショナリーを作成することで、より複雑な変数構造にすることができます。ここでは 2 つの変数を設定しています。1 つは Web サーバーのポート用、もう 1 つはマシンが時刻同期に使用する NTP サーバーのポート用です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:131
msgid "Here's another group variables file. This is ``group_vars/dbservers`` which applies to the hosts in the ``dbservers`` group:"
msgstr "次は、別のグループ変数ファイルです。これは、``dbservers`` グループのホストに適用される ``group_vars/dbservers`` です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:142
msgid "If you look in the example, there are group variables for the ``webservers`` group and the ``lbservers`` group, similarly."
msgstr "上記の例を参照すると、同様に ``webservers`` グループと ``lbservers`` グループのグループ変数も存在します。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:144
msgid "These variables are used in a variety of places. You can use them in playbooks, like this, in ``roles/db/tasks/main.yml``:"
msgstr "これらの変数はさまざまな場所で使用され、``roles/db/tasks/main.yml`` のように Playbook でも使用できます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:161
msgid "You can also use these variables in templates, like this, in ``roles/common/templates/ntp.conf.j2``:"
msgstr "これらの変数は、``roles/common/templates/ntp.conf.j2`` で、テンプレートで使用することもできます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:176
msgid "You can see that the variable substitution syntax of {{ and }} is the same for both templates and variables. The syntax inside the curly braces is Jinja2, and you can do all sorts of operations and apply different filters to the data inside. In templates, you can also use for loops and if statements to handle more complex situations, like this, in ``roles/common/templates/iptables.j2``:"
msgstr "{{ および }} の変数置換構文は、テンプレートでも変数でも同じであることがわかります。中括弧の中の構文は Jinja2 のもので、中のデータに対してあらゆる種類の操作やさまざまなフィルターを適用することができます。テンプレートでは、for ループや if 文を使用して、以下のように、``roles/common/templates/iptables.j2`` でより複雑な状況を処理することもできます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:187
msgid "This is testing to see if the inventory name of the machine we're currently operating on (``inventory_hostname``) exists in the inventory group ``dbservers``. If so, that machine will get an iptables ACCEPT line for port 3306."
msgstr "これは、現在操作しているマシンのインベントリー名 (``inventory_hostname``) が、インベントリーグループ ``dbservers`` に存在するかどうかをテストしています。存在する場合、そのマシンはポート 3306 に対して iptables の ACCEPT 行を取得します。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:190
msgid "Here's another example, from the same template:"
msgstr "以下は、同じテンプレートの別の例です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:198
msgid "This loops over all of the hosts in the group called ``monitoring``, and adds an ACCEPT line for each monitoring hosts' default IPv4 address to the current machine's iptables configuration, so that Nagios can monitor those hosts."
msgstr "これは、``monitoring`` というグループのすべてのホストをループし、現在のマシンの iptables 設定に、各監視ホストのデフォルトの IPv4 アドレスに ACCEPT 行を追加し、Nagios がそれらのホストを監視できるようにします。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:201
msgid "You can learn a lot more about Jinja2 and its capabilities `here <https://jinja.palletsprojects.com/>`_, and you can read more about Ansible variables in general in the :ref:`playbooks_variables` section."
msgstr "Jinja2 とその機能については `こちら <https://jinja.palletsprojects.com/>`_ で、また Ansible の変数全般については :ref:`playbooks_variables` で詳しく説明しています。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:207
msgid "The rolling upgrade"
msgstr "ローリングアップグレード"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:209
msgid "Now you have a fully-deployed site with web servers, a load balancer, and monitoring. How do you update it? This is where Ansible's orchestration features come into play. While some applications use the term 'orchestration' to mean basic ordering or command-blasting, Ansible refers to orchestration as 'conducting machines like an orchestra', and has a pretty sophisticated engine for it."
msgstr "これで、Web サーバー、ロードバランサー、および監視機能を備えた完全なサイトが展開されました。これをどうやって更新しますか。ここで、Ansible のオーケストレーション機能が活躍します。アプリケーションの中には、「オーケストレーション」という言葉を、基本的な命令やコマンドブラストの意味で使用しているものもありますが、Ansible ではオーケストレーションを「オーケストラのようにマシンを指揮すること」と呼んでおり、そのためにかなり高度なエンジンを備えています。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:213
msgid "Ansible has the capability to do operations on multi-tier applications in a coordinated way, making it easy to orchestrate a sophisticated zero-downtime rolling upgrade of our web application. This is implemented in a separate playbook, called ``rolling_update.yml``."
msgstr "Ansible には、多層アプリケーションの操作を連携して行う機能があり、Web アプリケーションのダウンタイムなしのローリングアップグレードを簡単に編成 (オーケストレーション) することができます。これは、``rolling_update.yml`` という名前の別の Playbook に実装されています。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:215
msgid "Looking at the playbook, you can see it is made up of two plays. The first play is very simple and looks like this:"
msgstr "Playbook を確認すると、2 つのプレイで構成されていることがわかります。1 つ目のプレイはとてもシンプルで、次のようになります。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:222
msgid "What's going on here, and why are there no tasks? You might know that Ansible gathers \"facts\" from the servers before operating upon them. These facts are useful for all sorts of things: networking information, OS/distribution versions, and so on. In our case, we need to know something about all of the monitoring servers in our environment before we perform the update, so this simple play forces a fact-gathering step on our monitoring servers. You will see this pattern sometimes, and it's a useful trick to know."
msgstr "どうなっているのでしょうか。なぜタスクが存在しないのでしょうか。Ansible は、サーバーを操作する前に、サーバーから「ファクト」を収集することはご存知かもしれません。これらのファクトは、ネットワーク情報、OS/ディストリビューションのバージョンなど、あらゆる種類のものに役立ちます。今回のケースでは、更新を実行する前に、環境内のすべての監視サーバーについて何かを知る必要があるため、この単純なプレイによって、監視サーバーのファクト収集ステップが強制的に実行されます。このパターンは時々見かけますが、知っておくと便利なワザです。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:224
msgid "The next part is the update play. The first part looks like this:"
msgstr "次の部分は、更新プレイです。最初の部分は以下のようになっています。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:232
msgid "This is just a normal play definition, operating on the ``webservers`` group. The ``serial`` keyword tells Ansible how many servers to operate on at once. If it's not specified, Ansible will parallelize these operations up to the default \"forks\" limit specified in the configuration file. But for a zero-downtime rolling upgrade, you may not want to operate on that many hosts at once. If you had just a handful of webservers, you may want to set ``serial`` to 1, for one host at a time. If you have 100, maybe you could set ``serial`` to 10, for ten at a time."
msgstr "これは通常のプレイ定義で、``webservers`` グループで動作します。``serial`` キーワードは、一度に操作するサーバーの数を Ansible に伝えます。このキーワードが指定されていない場合、Ansible は設定ファイルで指定されているデフォルトの「フォーク」制限まで、これらの操作を並列化します。しかし、ダウンタイムなしのローリングアップグレードでは、それほど多くのホストを一度に操作する必要はないでしょう。Web サーバーがほんの一握りしかない場合には、``serial`` を 1 に設定して、一度に 1 つのホストに対して行うのがよいでしょう。100 台ある場合は、``serial`` を 10 に設定して、一度に 10 台のホストを操作することもできます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:234
msgid "Here is the next part of the update play:"
msgstr "以下は更新プレイの次の部分です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:253
msgid "The ``serial`` keyword forces the play to be executed in 'batches'. Each batch counts as a full play with a subselection of hosts. This has some consequences on play behavior. For example, if all hosts in a batch fails, the play fails, which in turn fails the entire run. You should consider this when combining with ``max_fail_percentage``."
msgstr "``serial`` キーワードを使用すると、プレイが「バッチ」で実行されます。各バッチは、ホストのサブセレクションを使用した完全なプレイとしてカウントされます。これは、プレイの動作にいくつかの影響を与えます。たとえば、バッチ内のすべてのホストが失敗した場合、そのプレイは失敗し、その結果、全体の実行も失敗します。``max_fail_percentage`` と組み合わせる場合は、この点を考慮する必要があります。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:256
msgid "The ``pre_tasks`` keyword just lets you list tasks to run before the roles are called. This will make more sense in a minute. If you look at the names of these tasks, you can see that we are disabling Nagios alerts and then removing the webserver that we are currently updating from the HAProxy load balancing pool."
msgstr "``pre_tasks`` キーワードでは、ロールが呼び出される前に実行するタスクをリストアップすることができます。これはすぐに意味をなします。これらのタスクの名前を見ると、Nagios のアラートを無効にして、現在更新中の Web サーバーを HAProxy 負荷分散プールから削除していることがわかります。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:258
msgid "The ``delegate_to`` and ``loop`` arguments, used together, cause Ansible to loop over each monitoring server and load balancer, and perform that operation (delegate that operation) on the monitoring or load balancing server, \"on behalf\" of the webserver. In programming terms, the outer loop is the list of web servers, and the inner loop is the list of monitoring servers."
msgstr "``delegate_to`` 引数および ``loop`` 引数を一緒に使用すると、Ansible が各監視サーバーとロードバランサーをループし、Web サーバーに「代わって」監視サーバーまたは負荷分散サーバーでその操作を実行 (操作を委譲) することになります。プログラミング用語では、外部ループは Web サーバーのリスト、内部ループは監視サーバーのリストになります。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:260
msgid "Note that the HAProxy step looks a little complicated.  We're using HAProxy in this example because it's freely available, though if you have (for instance) an F5 or Netscaler in your infrastructure (or maybe you have an AWS Elastic IP setup?), you can use Ansible modules  to communicate with them instead.  You might also wish to use other monitoring modules instead of nagios, but this just shows the main goal of the 'pre tasks' section -- take the server out of monitoring, and take it out of rotation."
msgstr "HAProxy のステップは少し複雑に見えることに注意してください。この例では HAProxy を使用していますが、これは自由に利用できるからです。しかし、(たとえば) F5 や Netscaler がインフラストラクチャーにある場合 (あるいは AWS の Elastic IP を設定している場合) は、代わりに Ansible モジュールを使用してそれらと通信することができます。nagios の代わりに他の監視モジュールを使用することもできますが、これは「事前タスク」セクションの主な目的、つまり、サーバーを監視から外し、ローテーションから外すことを示しています。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:262
msgid "The next step simply re-applies the proper roles to the web servers. This will cause any configuration management declarations in ``web`` and ``base-apache`` roles to be applied to the web servers, including an update of the web application code itself. We don't have to do it this way--we could instead just purely update the web application, but this is a good example of how roles can be used to reuse tasks:"
msgstr "次の手順では、適切なロールを Web サーバーに再適用するだけです。これにより、``web`` と ``base-apache`` のロールにおける構成管理宣言が Web サーバーに適用され、Web アプリケーションコード自体の更新も行われます。このようにしなくても、純粋に Web アプリケーションを更新するだけでもよいのですが、これはロールを使用してタスクを再利用する方法のよい例です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:271
msgid "Finally, in the ``post_tasks`` section, we reverse the changes to the Nagios configuration and put the web server back in the load balancing pool:"
msgstr "最後に、``post_tasks`` セクションで、Nuppet 設定への変更を元に戻し、Web サーバーを負荷分散プールに戻します。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:289
msgid "Again, if you were using a Netscaler or F5 or Elastic Load Balancer, you would just substitute in the appropriate modules instead."
msgstr "NetScaler、F5、または Elastic Load Balancer を使用する場合は、代わりに適切なモジュールに置き換えてください。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:294
msgid "Managing other load balancers"
msgstr "その他のロードバランサーの管理"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:296
msgid "In this example, we use the simple HAProxy load balancer to front-end the web servers. It's easy to configure and easy to manage. As we have mentioned, Ansible has support for a variety of other load balancers like Citrix NetScaler, F5 BigIP, Amazon Elastic Load Balancers, and more. See the :ref:`working_with_modules` documentation for more information."
msgstr "この例では、シンプルな HAProxy ロードバランサーを Web サーバーのフロントエンドに使用しています。設定が簡単で、管理も容易です。これまで述べてきたように、Ansible は Citrix NetScaler、F5 BigIP、Amazon Elastic Load Balancer など、他のさまざまなロードバランサーをサポートしています。詳細は、「:ref:`working_with_modules`」のドキュメントをご覧ください。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:298
msgid "For other load balancers, you may need to send shell commands to them (like we do for HAProxy above), or call an API, if your load balancer exposes one. For the load balancers for which Ansible has modules, you may want to run them as a ``local_action`` if they contact an API. You can read more about local actions in the :ref:`playbooks_delegation` section.  Should you develop anything interesting for some hardware where there is not a module, it might make for a good contribution!"
msgstr "その他のロードバランサーの場合は、シェルコマンドを送信するか (上記の HAProxy の場合と同様)、ロードバランサーが API を公開している場合は API を呼び出す必要があるかもしれません。Ansible にモジュールが用意されているロードバランサーについては、API を呼び出す場合には、``local_action`` として実行することもできます。ローカルアクションについては、:ref:`playbooks_delegation` セクションで詳しく説明しています。モジュールがないハードウェアで何か面白いものを開発したら、良い貢献になるかもしれません。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:303
msgid "Continuous delivery end-to-end"
msgstr "継続的デリバリーのエンドツーエンド"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:305
msgid "Now that you have an automated way to deploy updates to your application, how do you tie it all together? A lot of organizations use a continuous integration tool like `Jenkins <https://jenkins.io/>`_ or `Atlassian Bamboo <https://www.atlassian.com/software/bamboo>`_ to tie the development, test, release, and deploy steps together. You may also want to use a tool like `Gerrit <https://www.gerritcodereview.com/>`_ to add a code review step to commits to either the application code itself, or to your Ansible playbooks, or both."
msgstr "アプリケーションの更新を自動的にデプロイする方法が確立されましたが、これらをどのようにまとめたらよいでしょうか。多くの組織では、`Jenkins <https://jenkins.io/>`_ や `Atlassian Bamboo <https://www.atlassian.com/software/bamboo>`_ のような継続的統合ツールを使用して、開発、テスト、リリース、デプロイの各ステップを関連付けています。また、`Gerrit <https://www.gerritcodereview.com/>`_ のようなツールを使用して、アプリケーションコード自体か、Ansible Playbook のいずれか、または両方のコミットにコードレビューのステップを追加することもできます。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:307
msgid "Depending on your environment, you might be deploying continuously to a test environment, running an integration test battery against that environment, and then deploying automatically into production.  Or you could keep it simple and just use the rolling-update for on-demand deployment into test or production specifically.  This is all up to you."
msgstr "環境によっては、テスト環境に継続的にデプロイし、その環境に対して統合テストバッテリーを実行してから、実稼働環境に自動的にデプロイする場合があります。または、シンプルに保ち、ローリングアップデートを使用して、特にテスト環境または実稼働環境にオンデマンドでデプロイすることもできます。これはすべてあなた次第です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:309
msgid "For integration with Continuous Integration systems, you can easily trigger playbook runs using the ``ansible-playbook`` command line tool, or, if you're using AWX, the ``tower-cli`` command or the built-in REST API.  (The tower-cli command 'joblaunch' will spawn a remote job over the REST API and is pretty slick)."
msgstr "継続的統合システムとの連携では、``ansible-playbook`` コマンドラインツール (AWX を使用している場合は、``tower-cli`` コマンドや組み込み REST API) を使用して簡単に Playbook の実行をトリガーすることができます (tower-cli コマンドの「joblaunch」は、REST API を介してリモートジョブを生成し、非常に洗練されています)。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:311
msgid "This should give you a good idea of how to structure a multi-tier application with Ansible, and orchestrate operations upon that app, with the eventual goal of continuous delivery to your customers. You could extend the idea of the rolling upgrade to lots of different parts of the app; maybe add front-end web servers along with application servers, for instance, or replace the SQL database with something like MongoDB or Riak. Ansible gives you the capability to easily manage complicated environments and automate common operations."
msgstr "ここでは、Ansible を使用して多層アプリケーションを構築し、そのアプリケーションの操作を調整して、最終的に顧客に継続的に提供する方法を紹介しています。ローリングアップグレードの概念は、アプリケーションのさまざまな部分に広げることができます。たとえば、アプリケーションサーバーと一緒にフロントエンドの Web サーバーを追加したり、SQL データベースを MongoDB や Riak のようなものに置き換えたりすることができます。Ansible は、複雑な環境を簡単に管理し、一般的な操作を自動化する機能を提供します。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:315
msgid "`lamp_haproxy example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_"
msgstr "`lamp_haproxy example <https://github.com/ansible/ansible-examples/tree/master/lamp_haproxy>`_"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:316
msgid "The lamp_haproxy example discussed here."
msgstr "ここで説明した lamp_haproxy の例です。"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:317
#: ../../rst/playbook_guide/playbooks_conditionals.rst:540
#: ../../rst/playbook_guide/playbooks_lookups.rst:28
#: ../../rst/playbook_guide/playbooks_reuse.rst:211
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:594
#: ../../rst/playbook_guide/playbooks_roles.rst:15
msgid ":ref:`working_with_playbooks`"
msgstr ":ref:`working_with_playbooks`"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:318
#: ../../rst/playbook_guide/playbooks_async.rst:185
#: ../../rst/playbook_guide/playbooks_blocks.rst:187
#: ../../rst/playbook_guide/playbooks_conditionals.rst:541
#: ../../rst/playbook_guide/playbooks_debugger.rst:338
#: ../../rst/playbook_guide/playbooks_delegation.rst:166
#: ../../rst/playbook_guide/playbooks_environment.rst:149
#: ../../rst/playbook_guide/playbooks_error_handling.rst:269
#: ../../rst/playbook_guide/playbooks_filters.rst:2185
#: ../../rst/playbook_guide/playbooks_lookups.rst:29
#: ../../rst/playbook_guide/playbooks_loops.rst:487
#: ../../rst/playbook_guide/playbooks_prompts.rst:116
#: ../../rst/playbook_guide/playbooks_startnstep.rst:44
#: ../../rst/playbook_guide/playbooks_strategies.rst:246
#: ../../rst/playbook_guide/playbooks_tags.rst:426
#: ../../rst/playbook_guide/playbooks_templating.rst:26
#: ../../rst/playbook_guide/playbooks_tests.rst:528
#: ../../rst/playbook_guide/playbooks_variables.rst:516
msgid "An introduction to playbooks"
msgstr "Playbook の概要"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:319
#: ../../rst/playbook_guide/playbooks_blocks.rst:188
#: ../../rst/playbook_guide/playbooks_conditionals.rst:542
#: ../../rst/playbook_guide/playbooks_filters.rst:2192
#: ../../rst/playbook_guide/playbooks_loops.rst:488
#: ../../rst/playbook_guide/playbooks_strategies.rst:249
#: ../../rst/playbook_guide/playbooks_tags.rst:427
#: ../../rst/playbook_guide/playbooks_tests.rst:535
#: ../../rst/playbook_guide/playbooks_variables.rst:523
msgid ":ref:`playbooks_reuse_roles`"
msgstr ":ref:`playbooks_reuse_roles`"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:320
msgid "An introduction to playbook roles"
msgstr "Playbook のロールの概要"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:321
#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:115
#: ../../rst/playbook_guide/playbooks_conditionals.rst:546
#: ../../rst/playbook_guide/playbooks_error_handling.rst:274
#: ../../rst/playbook_guide/playbooks_filters.rst:2188
#: ../../rst/playbook_guide/playbooks_lookups.rst:32
#: ../../rst/playbook_guide/playbooks_loops.rst:494
#: ../../rst/playbook_guide/playbooks_prompts.rst:119
#: ../../rst/playbook_guide/playbooks_reuse.rst:213
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:598
#: ../../rst/playbook_guide/playbooks_tests.rst:531
msgid ":ref:`playbooks_variables`"
msgstr ":ref:`playbooks_variables`"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:322
msgid "An introduction to Ansible variables"
msgstr "Ansible 変数の概要"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:323
msgid "`Ansible.com: Continuous Delivery <https://www.ansible.com/use-cases/continuous-delivery>`_"
msgstr "`Ansible.com: Continuous Delivery <https://www.ansible.com/use-cases/continuous-delivery>`_"

#: ../../rst/playbook_guide/guide_rolling_upgrade.rst:324
msgid "An introduction to Continuous Delivery with Ansible"
msgstr "Ansible を使用した継続的デリバリーの概要"

#: ../../rst/playbook_guide/index.rst:5
msgid "Using Ansible playbooks"
msgstr "Ansible Playbook の使用"

#: ../../rst/playbook_guide/index.rst:9
msgid "**Making Open Source More Inclusive**"
msgstr "**多様性を受け入れるオープンソースの強化**"

#: ../../rst/playbook_guide/index.rst:11
msgid "Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. We ask that you open an issue or pull request if you come upon a term that we have missed. For more details, see `our CTO Chris Wright's message <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_."
msgstr "Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。まずは、マスター (master)、スレーブ (slave)、ブラックリスト (blacklist)、ホワイトリスト (whitelist) の 4 つの用語の置き換えから始めます。問題のある用語を見つけた場合は、問題を作成するか、プル要求を作成してください。詳細は、`弊社 の CTO、Chris Wright のメッセージ <https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language>`_ を参照してください。"

#: ../../rst/playbook_guide/index.rst:13
msgid "Welcome to the Ansible playbooks guide. Playbooks are automation blueprints, in ``YAML`` format, that Ansible uses to deploy and configure nodes in an inventory. This guide introduces you to playbooks and then covers different use cases for tasks and plays, such as:"
msgstr "Ansible Playbook ガイドへようこそ。Playbook は、``YAML`` 形式の自動化ブループリントで、Ansible はインベントリーでのノードのデプロイおよび設定に使用します。本書では、Playbook を紹介して、以下のようなタスクやプレイのさまざまなユースケースについて説明します。"

#: ../../rst/playbook_guide/index.rst:17
msgid "Executing tasks with elevated privileges or as a different user."
msgstr "昇格された権限で、または別のユーザーとしてタスクを実行する"

#: ../../rst/playbook_guide/index.rst:18
msgid "Using loops to repeat tasks for items in a list."
msgstr "ループを使用して、リスト内の項目に対してタスクを繰り返す。"

#: ../../rst/playbook_guide/index.rst:19
msgid "Delegating playbooks to execute tasks on different machines."
msgstr "異なるマシンでタスクを実行する Playbook を委譲する。"

#: ../../rst/playbook_guide/index.rst:20
msgid "Running conditional tasks and evaluating conditions with playbook tests."
msgstr "条件タスクを実行して Playbook テストを使用して条件を評価する。"

#: ../../rst/playbook_guide/index.rst:21
msgid "Using blocks to group sets of tasks."
msgstr "ブロックを使用してタスクセットをグループ化する。"

#: ../../rst/playbook_guide/index.rst:23
msgid "You can also learn how to use Ansible playbooks more effectively by creating re-usable files and roles, including and importing playbooks, and running selected parts of a playbook with tags."
msgstr "また、Playbook を含む再利用可能なファイルおよびロールを作成し、タグを使用して Playbook の選択された部分を実行することで、Ansible Playbook をより効果的に使用する方法についても学ぶことができます。"

#: ../../rst/playbook_guide/playbook_pathing.rst:5
msgid "Search paths in Ansible"
msgstr "Ansible でパスの検索"

#: ../../rst/playbook_guide/playbook_pathing.rst:7
msgid "You can control the paths Ansible searches to find resources on your control node (including configuration, modules, roles, ssh keys, and more) as well as resources on the remote nodes you are managing. Use absolute paths to tell Ansible where to find resources whenever you can. However, absolute paths are not always practical. This page covers how Ansible interprets relative search paths, along with ways to troubleshoot when Ansible cannot find the resource you need."
msgstr "Ansible がコントロールノード上のリソース (構成、モジュール、ロール、ssh キーなど) や、管理しているリモートノード上のリソースを検索する際のパスを制御できます。リソースを検索する場所を Ansible に伝えるには、可能な限り絶対パスを使用します。しかし、絶対パスは必ずしも実用的ではありません。このページでは、Ansible が相対検索パスをどのように解釈するか、また Ansible が必要なリソースを見つけられない場合のトラブルシューティングの方法について説明します。"

#: ../../rst/playbook_guide/playbook_pathing.rst:13
msgid "Config paths"
msgstr "設定パス"

#: ../../rst/playbook_guide/playbook_pathing.rst:15
msgid "By default these should be relative to the config file, some are specifically relative to the current working directory or the playbook and should have this noted in their description. Things like ssh keys are left to use the current working directory because it mirrors how the underlying tools would use it."
msgstr "デフォルトでは、これらは設定ファイルからの相対的なものですが、中には特に現在の作業ディレクトリーや Playbook からの相対的なものもあるため、説明にその旨を記載してください。ssh キーのようなものは、基本的なツールが使用する方法を反映するため、現在の作業ディレクトリーを使用するようになっています。"

#: ../../rst/playbook_guide/playbook_pathing.rst:19
msgid "Task paths"
msgstr "タスクパス"

#: ../../rst/playbook_guide/playbook_pathing.rst:21
msgid "Relative paths used in a task typically refer to remote files and directories on the managed nodes. However, paths passed to lookup plugins and some paths used in action plugins such as the \"src\" path for the :ref:`template <ansible_collections.ansible.builtin.template_module>` and :ref:`copy <ansible_collections.ansible.builtin.copy_module>` modules refer to local files and directories on the control node."
msgstr "タスクで使用される相対パスは通常、管理ノードのリモートファイルおよびディレクトリーを参照します。ただし、lookup プラグインに渡されるパスや、:ref:`template <ansible_collections.ansible.builtin.template_module>` モジュールおよび :ref:`copy <ansible_collections.ansible.builtin.copy_module>` モジュールの「src」パス等のアクションプラグインで使用される一部のパスは、コントロールノードのローカルファイルおよびディレクトリーを参照します。"

#: ../../rst/playbook_guide/playbook_pathing.rst:24
msgid "Resolving local relative paths"
msgstr "ローカル相対パスの解決"

#: ../../rst/playbook_guide/playbook_pathing.rst:26
msgid "When you specify a relative path for a local file, Ansible will try to find that file first in the current task's role, then in other roles that included or depend on the current role, then relative to the file in which the task is defined, and finally relative to the current play. It will take the first matching file that it finds. This way, if multiple files with the same filename exist, Ansible will find the file that is closest to the current task and that is most likely to be file you wanted."
msgstr "ローカルファイルの相対パスを指定する場合、Ansible は現在のタスクのロールでまずそのファイルを見つけようとします。次に、現在のロールに含まれる、または依存する他のロールで、次にタスクが定義されているファイルに相対的に、最後に現在のプレイに相対的に見つけようとします。これにより、最初に見つかったマッチするファイルが使用されます。したがって、同じファイル名を持つ複数のファイルが存在する場合、Ansible は現在のタスクにもっとも近く、希望のファイルである可能性が高いファイルを検索します。"

#: ../../rst/playbook_guide/playbook_pathing.rst:28
msgid "Specifically, Ansible tries to find the file"
msgstr "具体的には、Ansible は以下のようにファイルを検索しようとします"

#: ../../rst/playbook_guide/playbook_pathing.rst:30
msgid "In the current role."
msgstr "現在のロールで"

#: ../../rst/playbook_guide/playbook_pathing.rst:32
msgid "In its appropriate subdirectory—\"files\", \"vars\", \"templates\" or \"tasks\", depending on the kind of file Ansible is searching for."
msgstr "Ansible が検索するファイルの種類に応じて、適切なサブディレクトリー(「files」、「vars」、「templates」、または「tasks」)で"

#: ../../rst/playbook_guide/playbook_pathing.rst:33
msgid "Directly in its directory."
msgstr "そのディレクトリーに直接"

#: ../../rst/playbook_guide/playbook_pathing.rst:35
msgid "Like 1, in the parent role that called into this current role with `include_role`, `import_role`, or with a role dependency. If the parent role has its own parent role, Ansible will repeat this step with that role."
msgstr "1 と同様に、`include_role`、`import_role` またはロールの依存関係でこの現在のロールに呼び出される親ロールで。親ロールに独自の親ロールがある場合は、Ansible はそのロールでこの手順を繰り返します。"

#: ../../rst/playbook_guide/playbook_pathing.rst:36
msgid "Like 1, in the current task file's directory."
msgstr "1 と同様に、現在のタスクファイルのディレクトリーで"

#: ../../rst/playbook_guide/playbook_pathing.rst:37
msgid "Like 1, in the current play file's directory."
msgstr "1 と同様に、現在の play ファイルのディレクトリーで"

#: ../../rst/playbook_guide/playbook_pathing.rst:39
msgid "Ansible does not search the current working directory. (The directory you're in when you execute Ansible.) Also, Ansible will only search within a role if you actually included it with an `include_role` or `import_role` task or a dependency. If you instead use `include`, `include_task` or `import_task` to include just the tasks from a specific file but not the full role, Ansible will not search that role in steps 1 and 2."
msgstr "Ansible は、現在の作業ディレクトリー(Ansibleを実行する時のディレクトリー)を検索しません。また、`include_role` または `import_role` タスクまたは依存関係で実際に含めた場合、Ansible はロール内のみ検索します。代わりに、`include`、`include_task`、または `import_task` を使用して、完全なロールではなく特定のファイルからのタスクだけを含める場合、Ansible はステップ1および2でそのロールを検索しません。"

#: ../../rst/playbook_guide/playbook_pathing.rst:41
msgid "When you execute Ansible, the variable `ansible_search_path` will contain the paths searched, in the order they were searched in but without listing their subdirectories. If you run Ansible in verbosity level 5 by passing the `-vvvvv` argument, Ansible will report each directory as it searches, except when it searches for a tasks file."
msgstr "Ansible を実行すると、変数 `ansible_search_path` には、検索されたパスが検索された順に含まれますが、そのサブディレクトリーは一覧表示されません。`-vvvvv` 引数を渡して詳細レベル5でAnsible を実行すると、タスクファイルを検索した場合を除き、Ansible は検索した順に各ディレクトリーを報告します。"

#: ../../rst/playbook_guide/playbook_pathing.rst:44
msgid "The current working directory might vary depending on the connection plugin and if the action is local or remote. For the remote it is normally the directory on which the login shell puts the user. For local it is either the directory you executed ansible from or in some cases the playbook directory."
msgstr "現在の作業ディレクトリは、接続プラグインと、アクションがローカルかリモートかによって異なる場合があります。リモートの場合、通常、ログインシェルがユーザーを配置するディレクトリになります。ローカルの場合は、ansibleを実行したディレクトリか、場合によってはPlaybokディレクトリになります。"

#: ../../rst/playbook_guide/playbooks.rst:4
msgid "Working with playbooks"
msgstr "Playbook の操作"

#: ../../rst/playbook_guide/playbooks.rst:6
msgid "Playbooks record and execute Ansible's configuration, deployment, and orchestration functions. They can describe a policy you want your remote systems to enforce, or a set of steps in a general IT process."
msgstr "Playbook は、Ansible の設定、デプロイメント、オーケストレーション機能を記録して実行します。リモートシステムを強制するポリシーや、一般的な IT プロセスで一連の手順を説明することができます。"

#: ../../rst/playbook_guide/playbooks.rst:9
msgid "If Ansible modules are the tools in your workshop, playbooks are your instruction manuals, and your inventory of hosts are your raw material."
msgstr "Ansible モジュールがワークショップのツールである場合、Playbook は手順のマニュアルにあり、ホストのインベントリーは実際のマテリアルになります。"

#: ../../rst/playbook_guide/playbooks.rst:11
msgid "At a basic level, playbooks can be used to manage configurations of and deployments to remote machines. At a more advanced level, they can sequence multi-tier rollouts involving rolling updates, and can delegate actions to other hosts, interacting with monitoring servers and load balancers along the way."
msgstr "基本的なレベルでは、Playbook を使用して、リモートマシンの設定およびリモートマシンへのデプロイメントを管理できます。より高度なレベルでは、ローリングアップデートに関連する複数層のロールアウトを分類し、他のホストにアクションを委譲して、監視サーバーやロードバランサーと対話できます。"

#: ../../rst/playbook_guide/playbooks.rst:14
msgid "Playbooks are designed to be human-readable and are developed in a basic text language. There are multiple ways to organize playbooks and the files they include, and we'll offer up some suggestions on that and making the most out of Ansible."
msgstr "Playbook は人間が判読可能で、基本的なテキスト言語で開発されるように設計されています。Playbook と、Playbook に含まれるファイルを整理する方法は複数あり、その方法と、Ansible を最大限に活用するための提案を行います。"

#: ../../rst/playbook_guide/playbooks.rst:17
msgid "You should look at `Example Playbooks <https://github.com/ansible/ansible-examples>`_ while reading along with the playbook documentation. These illustrate best practices as well as how to put many of the various concepts together."
msgstr "Playbook ドキュメントと一緒に、`Example Playbooks <https://github.com/ansible/ansible-examples>`_ を参照してください。ここでは、ベストプラクティスや、さまざまな概念をまとめて配置する方法を説明します。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:5
msgid "Advanced playbook syntax"
msgstr "高度な Playbook の構文"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:7
msgid "The advanced YAML syntax examples on this page give you more control over the data placed in YAML files used by Ansible. You can find additional information about Python-specific YAML in the official `PyYAML Documentation <https://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes>`_."
msgstr "このページの高度な YAML 構文の例では、Ansible が使用する YAML ファイルに配置されるデータをより細かく制御できます。Python 固有の YAML に関する追加情報は、公式の `PyYAML ドキュメント <https://pyyaml.org/wiki/PyYAMLDocumentation#YAMLtagsandPythontypes>`_ でご覧いただけます。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:13
msgid "Unsafe or raw strings"
msgstr "安全でない文字列または生の文字列"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:15
#, python-format
msgid "When handling values returned by lookup plugins, Ansible uses a data type called ``unsafe`` to block templating. Marking data as unsafe prevents malicious users from abusing Jinja2 templates to execute arbitrary code on target machines. The Ansible implementation ensures that unsafe values are never templated. It is more comprehensive than escaping Jinja2 with ``{% raw %} ... {% endraw %}`` tags."
msgstr "lookup プラグインから返される値を処理する際、Ansible は ``unsafe`` というデータタイプを使用してテンプレートをブロックします。データを安全ではないとマークすることで、悪意のあるユーザーが Jinja2 のテンプレートを悪用してターゲットマシンで任意のコードを実行することを防ぎます。Ansible の実装では、安全でない値が決してテンプレート化されないようにしています。``{% raw %} ... {% endraw %}`` タグで Jinja2 をエスケープするよりも包括的です。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:17
msgid "You can use the same ``unsafe`` data type in variables you define, to prevent templating errors and information disclosure. You can mark values supplied by :ref:`vars_prompts<unsafe_prompts>` as unsafe. You can also use ``unsafe`` in playbooks. The most common use cases include passwords that allow special characters like ``{`` or ``%``, and JSON arguments that look like templates but should not be templated. For example:"
msgstr "定義した変数に同じ ``unsafe`` データ型を使用すると、テンプレートエラーや情報の漏えいを防ぐことができます。:ref:`vars_prompts<unsafe_prompts>` により提供された値を安全でないものとしてマーク付けできます。Playbook で ``unsafe`` を使用することもできます。最も一般的なユースケースには、テンプレートのような ``{`` や ``%`` などの特殊文字を許可するパスワードが含まれていますが、テンプレート化すべきではありません。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:24
msgid "In a playbook:"
msgstr "Playbook の場合は、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:35
msgid "For complex variables such as hashes or arrays, use ``!unsafe`` on the individual elements:"
msgstr "ハッシュや配列などの複雑な変数の場合は、個々の要素で ``!unsafe`` を使用します。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:50
msgid "YAML anchors and aliases: sharing variable values"
msgstr "YAML アンカーおよびエイリアス: 変数値の共有"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:52
msgid "`YAML anchors and aliases <https://yaml.org/spec/1.2/spec.html#id2765878>`_ help you define, maintain, and use shared variable values in a flexible way. You define an anchor with ``&``, then refer to it using an alias, denoted with ``*``. Here's an example that sets three values with an anchor, uses two of those values with an alias, and overrides the third value:"
msgstr "`YAML アンカーおよびエイリアス <https://yaml.org/spec/1.2/spec.html#id2765878>`_ は、柔軟な方法で共有変数の値を定義、維持、および使用するのに役立ちます。``&`` でアンカーを定義し、``*`` で示すエイリアスを使用して参照します。ここでは、アンカーで 3 つの値を設定し、エイリアスでこれらの値を 2 つ使用し、3 番目の値を上書きする例を以下に示します。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:71
msgid "Here, ``app1`` and ``app2`` share the values for ``opts`` and ``port`` using the anchor ``&jvm_opts`` and the alias ``*jvm_opts``. The value for ``path`` is merged by ``<<`` or `merge operator <https://yaml.org/type/merge.html>`_."
msgstr "ここで、``app1`` および ``app2`` は、アンカー ``&jvm_opts`` およびエイリアス ``*jvm_opts`` を使用して、``opts`` と ``port`` の値を共有します。``path`` の値は、``<<`` または `merge operator <https://yaml.org/type/merge.html>`_ によってマージされます。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:74
msgid "Anchors and aliases also let you share complex sets of variable values, including nested variables. If you have one variable value that includes another variable value, you can define them separately:"
msgstr "アンカーおよびエイリアスを使用すると、入れ子になった変数など、複雑な変数値のセットを共有することもできます。ある変数値に別の変数値が含まれている場合は、その変数値を別々に定義することができます。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:82
msgid "This is inefficient and, at scale, means more maintenance. To incorporate the version value in the name, you can use an anchor in ``app_version`` and an alias in ``custom_name``:"
msgstr "これは非効率的であり、大規模な場合には、より多くのメンテナンスが行われます。名前に version の値を組み込むには、``app_version`` にアンカーと、``custom_name`` のエイリアスを使用できます。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:93
msgid "Now, you can re-use the value of ``app_version`` within the value of  ``custom_name`` and use the output in a template:"
msgstr "これで、``custom_name`` の値の ``app_version`` の値を再利用し、テンプレートで出力を使用できます。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:111
msgid "You've anchored the value of ``version`` with the ``&my_version`` anchor, and re-used it with the ``*my_version`` alias. Anchors and aliases let you access nested values inside dictionaries."
msgstr "``version`` の値を ``&my_version`` というアンカーで固定し、``*my_version`` というエイリアスで再利用しています。アンカーとエイリアスを使用することで、ディクショナリー内のネストした値にアクセスすることができます。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:116
#: ../../rst/playbook_guide/playbooks_conditionals.rst:547
#: ../../rst/playbook_guide/playbooks_error_handling.rst:275
#: ../../rst/playbook_guide/playbooks_filters.rst:2189
#: ../../rst/playbook_guide/playbooks_lookups.rst:33
#: ../../rst/playbook_guide/playbooks_loops.rst:495
#: ../../rst/playbook_guide/playbooks_prompts.rst:120
#: ../../rst/playbook_guide/playbooks_tests.rst:532
msgid "All about variables"
msgstr "変数の詳細"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:117
msgid ":ref:`complex_data_manipulation`"
msgstr ":ref:`complex_data_manipulation`"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:118
msgid "Doing complex data manipulation in Ansible"
msgstr "Ansible での複雑なデータ操作の実行"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:119
msgid "`User Mailing List <https://groups.google.com/group/ansible-project>`_"
msgstr "`メーリングリストの使用 <https://groups.google.com/group/ansible-project>`_"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:120
#: ../../rst/playbook_guide/playbooks_async.rst:187
#: ../../rst/playbook_guide/playbooks_blocks.rst:191
#: ../../rst/playbook_guide/playbooks_conditionals.rst:549
#: ../../rst/playbook_guide/playbooks_debugger.rst:340
#: ../../rst/playbook_guide/playbooks_delegation.rst:172
#: ../../rst/playbook_guide/playbooks_environment.rst:151
#: ../../rst/playbook_guide/playbooks_error_handling.rst:277
#: ../../rst/playbook_guide/playbooks_filters.rst:2197
#: ../../rst/playbook_guide/playbooks_lookups.rst:37
#: ../../rst/playbook_guide/playbooks_loops.rst:497
#: ../../rst/playbook_guide/playbooks_prompts.rst:122
#: ../../rst/playbook_guide/playbooks_strategies.rst:252
#: ../../rst/playbook_guide/playbooks_tags.rst:430
#: ../../rst/playbook_guide/playbooks_templating.rst:32
#: ../../rst/playbook_guide/playbooks_tests.rst:540
#: ../../rst/playbook_guide/playbooks_variables.rst:530
msgid "Have a question?  Stop by the google group!"
msgstr "ご質問はございますか。Google Group をご覧ください。"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:121
#: ../../rst/playbook_guide/playbooks_async.rst:188
#: ../../rst/playbook_guide/playbooks_blocks.rst:192
#: ../../rst/playbook_guide/playbooks_conditionals.rst:550
#: ../../rst/playbook_guide/playbooks_debugger.rst:341
#: ../../rst/playbook_guide/playbooks_delegation.rst:173
#: ../../rst/playbook_guide/playbooks_environment.rst:152
#: ../../rst/playbook_guide/playbooks_error_handling.rst:278
#: ../../rst/playbook_guide/playbooks_filters.rst:2198
#: ../../rst/playbook_guide/playbooks_lookups.rst:38
#: ../../rst/playbook_guide/playbooks_loops.rst:498
#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:775
#: ../../rst/playbook_guide/playbooks_prompts.rst:123
#: ../../rst/playbook_guide/playbooks_strategies.rst:253
#: ../../rst/playbook_guide/playbooks_tags.rst:431
#: ../../rst/playbook_guide/playbooks_templating.rst:33
#: ../../rst/playbook_guide/playbooks_tests.rst:541
#: ../../rst/playbook_guide/playbooks_variables.rst:531
msgid ":ref:`communication_irc`"
msgstr ":ref:`communication_irc`"

#: ../../rst/playbook_guide/playbooks_advanced_syntax.rst:122
#: ../../rst/playbook_guide/playbooks_async.rst:189
#: ../../rst/playbook_guide/playbooks_blocks.rst:193
#: ../../rst/playbook_guide/playbooks_conditionals.rst:551
#: ../../rst/playbook_guide/playbooks_debugger.rst:342
#: ../../rst/playbook_guide/playbooks_delegation.rst:174
#: ../../rst/playbook_guide/playbooks_environment.rst:153
#: ../../rst/playbook_guide/playbooks_error_handling.rst:279
#: ../../rst/playbook_guide/playbooks_filters.rst:2199
#: ../../rst/playbook_guide/playbooks_lookups.rst:39
#: ../../rst/playbook_guide/playbooks_loops.rst:499
#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:776
#: ../../rst/playbook_guide/playbooks_prompts.rst:124
#: ../../rst/playbook_guide/playbooks_strategies.rst:254
#: ../../rst/playbook_guide/playbooks_tags.rst:432
#: ../../rst/playbook_guide/playbooks_templating.rst:34
#: ../../rst/playbook_guide/playbooks_tests.rst:542
#: ../../rst/playbook_guide/playbooks_variables.rst:532
msgid "How to join Ansible chat channels"
msgstr "Ansible チャットチャンネルへの参加方法"

#: ../../rst/playbook_guide/playbooks_async.rst:4
msgid "Asynchronous actions and polling"
msgstr "非同期アクションおよびポーリング"

#: ../../rst/playbook_guide/playbooks_async.rst:6
msgid "By default Ansible runs tasks synchronously, holding the connection to the remote node open until the action is completed. This means within a playbook, each task blocks the next task by default, meaning subsequent tasks will not run until the current task completes. This behavior can create challenges. For example, a task may take longer to complete than the SSH session allows for, causing a timeout. Or you may want a long-running process to execute in the background while you perform other tasks concurrently. Asynchronous mode lets you control how long-running tasks execute."
msgstr "デフォルトでは、Ansible はタスクを同期的に実行し、アクションが完了するまでリモートノードへの接続を維持します。つまり、Playbook 内では、デフォルトでは各タスクが次のタスクをブロックし、現在のタスクが完了するまで後続のタスクが実行されないことになります。この動作には課題があります。たとえば、あるタスクが SSH セッションの許容範囲を超えて完了するのに時間がかかり、タイムアウトが発生する場合があります。また、他のタスクを同時に実行している間、長時間実行するプロセスをバックグラウンドで実行したい場合もあります。非同期モードでは、長時間実行するタスクの実行方法を制御することができます。"

#: ../../rst/playbook_guide/playbooks_async.rst:12
msgid "Asynchronous ad hoc tasks"
msgstr "非同期アドホックタスク"

#: ../../rst/playbook_guide/playbooks_async.rst:14
msgid "You can execute long-running operations in the background with :ref:`ad hoc tasks <intro_adhoc>`. For example, to execute ``long_running_operation`` asynchronously in the background, with a timeout (``-B``) of 3600 seconds, and without polling (``-P``):"
msgstr ":ref:`アドホックタスク <intro_adhoc>` を使用すると、バックグラウンドで長時間実行される操作を実行することができます。たとえば、``long_running_operation`` をバックグラウンドで非同期的に実行し、タイムアウト (``-B``) を 3600 秒に設定し、ポーリング (``-P``) を行わない場合は次のようになります。"

#: ../../rst/playbook_guide/playbooks_async.rst:20
msgid "To check on the job status later, use the ``async_status`` module, passing it the job ID that was returned when you ran the original job in the background:"
msgstr "後でジョブステータスを確認するには、``async_status`` モジュールを使用し、バックグラウンドで元のジョブの実行時に返されたジョブ ID を渡します。"

#: ../../rst/playbook_guide/playbooks_async.rst:26
msgid "Ansible can also check on the status of your long-running job automatically with polling. In most cases, Ansible will keep the connection to your remote node open between polls. To run for 30 minutes and poll for status every 60 seconds:"
msgstr "Ansible は、ポーリングによって長時間実行するジョブの状態を自動的に確認することもできます。ほとんどの場合、Ansible はポーリングの間もリモートノードへの接続を維持します。30 分間実行し、60 秒ごとにステータスをポーリングするには次のようにします。"

#: ../../rst/playbook_guide/playbooks_async.rst:32
msgid "Poll mode is smart so all jobs will be started before polling begins on any machine. Be sure to use a high enough ``--forks`` value if you want to get all of your jobs started very quickly. After the time limit (in seconds) runs out (``-B``), the process on the remote nodes will be terminated."
msgstr "ポーリングモードは高性能であるため、どのマシンでもポーリングが開始する前にすべてのジョブが開始します。すべてのジョブを非常に迅速に開始したい場合は ``--forks`` を十分な高さにしてください。制限時間 (秒単位) がなくなると (``-B``)、リモートノードのプロセスは終了します。"

#: ../../rst/playbook_guide/playbooks_async.rst:34
msgid "Asynchronous mode is best suited to long-running shell commands or software upgrades. Running the copy module asynchronously, for example, does not do a background file transfer."
msgstr "非同期モードは、長時間実行するシェルコマンドやソフトウェアのアップグレードに最適です。たとえば、copy モジュールを非同期で実行しても、バックグラウンドでのファイル転送は行われません。"

#: ../../rst/playbook_guide/playbooks_async.rst:37
msgid "Asynchronous playbook tasks"
msgstr "非同期 Playbook タスク"

#: ../../rst/playbook_guide/playbooks_async.rst:39
msgid ":ref:`Playbooks <working_with_playbooks>` also support asynchronous mode and polling, with a simplified syntax. You can use asynchronous mode in playbooks to avoid connection timeouts or to avoid blocking subsequent tasks. The behavior of asynchronous mode in a playbook depends on the value of `poll`."
msgstr ":ref:`Playbook <working_with_playbooks>` は、非同期モードとポーリングもサポートしており、構文も簡素化されています。非同期モードを Playbook で使用すると、接続のタイムアウトや、後続タスクのブロックを回避できます。Playbook での非同期モードの動作は、`poll` の値に依存します。"

#: ../../rst/playbook_guide/playbooks_async.rst:42
msgid "Avoid connection timeouts: poll > 0"
msgstr "接続のタイムアウトの回避: poll > 0"

#: ../../rst/playbook_guide/playbooks_async.rst:44
msgid "If you want to set a longer timeout limit for a certain task in your playbook, use ``async`` with ``poll`` set to a positive value. Ansible will still block the next task in your playbook, waiting until the async task either completes, fails or times out. However, the task will only time out if it exceeds the timeout limit you set with the ``async`` parameter."
msgstr "Playbook 内の特定のタスクにより長いタイムアウト制限を設定する場合は、``async`` を使用し、``poll`` を正の値に設定します。Ansible は、Playbook 内に記載される次のタスクをブロックし、非同期タスクが完了するか、失敗するか、タイムアウトになるまで待機します。ただし、タスクがタイムアウトになるのは、``async`` パラメーターで設定したタイムアウト制限を超えた場合のみです。"

#: ../../rst/playbook_guide/playbooks_async.rst:46
msgid "To avoid timeouts on a task, specify its maximum runtime and how frequently you would like to poll for status:"
msgstr "タスクでタイムアウトを回避するには、最大ランタイムとステータスをポーリングする頻度を指定します。"

#: ../../rst/playbook_guide/playbooks_async.rst:63
msgid "The default poll value is set by the :ref:`DEFAULT_POLL_INTERVAL` setting. There is no default for the async time limit.  If you leave off the 'async' keyword, the task runs synchronously, which is Ansible's default."
msgstr "デフォルトのポール値は、:ref:`DEFAULT_POLL_INTERVAL` の設定で設定されます。非同期時間制限のデフォルトはありません。「async」キーワードを省略すると、タスクは同期的に実行されます。これが Ansible のデフォルトです。"

#: ../../rst/playbook_guide/playbooks_async.rst:69
msgid "As of Ansible 2.3, async does not support check mode and will fail the task when run in check mode. See :ref:`check_mode_dry` on how to skip a task in check mode."
msgstr "Ansible 2.3 の時点では、非同期はチェックモードをサポートしておらず、チェックモードで実行するとタスクが失敗します。チェックモードでタスクをスキップする方法は、「:ref:`check_mode_dry`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_async.rst:74
msgid "When an async task completes with polling enabled, the temporary async job cache file (by default in ~/.ansible_async/) is automatically removed."
msgstr "ポーリングを有効にして非同期タスクが完了すると、一時的な非同期ジョブキャッシュファイル (デフォルトでは ~/.ansible_async/ にある) が自動的に削除されます。"

#: ../../rst/playbook_guide/playbooks_async.rst:78
msgid "Run tasks concurrently: poll = 0"
msgstr "タスクの同時実行: poll = 0"

#: ../../rst/playbook_guide/playbooks_async.rst:80
msgid "If you want to run multiple tasks in a playbook concurrently, use ``async`` with ``poll`` set to 0. When you set ``poll: 0``, Ansible starts the task and immediately moves on to the next task without waiting for a result. Each async task runs until it either completes, fails or times out (runs longer than its ``async`` value). The playbook run ends without checking back on async tasks."
msgstr "Playbook 内の複数のタスクを同時に実行する場合は、``async`` を使用し、``poll`` を 0 に設定します。``poll: 0`` を設定すると、Ansible はタスクを開始し、結果を待たずに直ちに次のタスクに移ります。各非同期タスクは、完了するか、失敗するか、タイムアウトにする (``async`` の値よりも長く実行される) まで実行されます。Playbook の実行は、非同期タスクを再度チェックせずに終了します。"

#: ../../rst/playbook_guide/playbooks_async.rst:82
msgid "To run a playbook task asynchronously:"
msgstr "Playbook タスクを非同期的に実行するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_async.rst:99
msgid "Do not specify a poll value of 0 with operations that require exclusive locks (such as yum transactions) if you expect to run other commands later in the playbook against those same resources."
msgstr "排他的ロックを必要とする操作 (yum トランザクションなど) では、同じリソースに対して Playbook の後半で他のコマンドを実行することを想定して、poll 値に 0 を指定しないでください。"

#: ../../rst/playbook_guide/playbooks_async.rst:102
msgid "Using a higher value for ``--forks`` will result in kicking off asynchronous tasks even faster. This also increases the efficiency of polling."
msgstr "``--forks`` の値を増やすと、非同期タスクの開始が速くなります。これにより、ポーリングの効率が高まります。"

#: ../../rst/playbook_guide/playbooks_async.rst:105
msgid "When running with ``poll: 0``, Ansible will not automatically cleanup the async job cache file. You will need to manually clean this up with the :ref:`async_status <async_status_module>` module with ``mode: cleanup``."
msgstr "``poll: 0`` で実行すると、Ansible は非同期ジョブキャッシュファイルを自動的にクリーンアップしません。``mode: cleanup`` で :ref:`async_status <async_status_module>` モジュールを使用して手動でクリーンアップする必要があります。"

#: ../../rst/playbook_guide/playbooks_async.rst:109
msgid "If you need a synchronization point with an async task, you can register it to obtain its job ID and use the :ref:`async_status <async_status_module>` module to observe it in a later task. For example:"
msgstr "非同期タスクとの同期ポイントが必要な場合は、これを登録してジョブ ID を取得し、:ref:`async_status <async_status_module>` モジュールを使用して後続のタスクで確認することができます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_async.rst:130
msgid "If the value of ``async:`` is not high enough, this will cause the \"check on it later\" task to fail because the temporary status file that the ``async_status:`` is looking for will not have been written or no longer exist"
msgstr "``async:`` の値が十分に高くない場合は、``async_status:`` が探している一時的なステータスファイルが書き込まれていないか、存在しなくなったため、「後で確認する」タスクが失敗することになります。"

#: ../../rst/playbook_guide/playbooks_async.rst:135
msgid "Asynchronous playbook tasks always return changed. If the task is using a module that requires the user to annotate changes with ``changed_when``, ``creates``,  and so on, then those should be added to the following ``async_status`` task."
msgstr "非同期 Playbook タスクは常に変更を返します。タスクが、ユーザーが ``changed_when`` および ``creates`` を使用して変更にアノテーションを付ける必要があるモジュールを使用している場合は、それらのタスクを以下の ``async_status`` タスクに追加する必要があります。"

#: ../../rst/playbook_guide/playbooks_async.rst:139
msgid "To run multiple asynchronous tasks while limiting the number of tasks running concurrently:"
msgstr "複数の非同期タスクを実行しながら、同時に実行するタスクの数を制限するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_async.rst:182
#: ../../rst/playbook_guide/playbooks_delegation.rst:167
msgid ":ref:`playbooks_strategies`"
msgstr ":ref:`playbooks_strategies`"

#: ../../rst/playbook_guide/playbooks_async.rst:183
msgid "Options for controlling playbook execution"
msgstr "Playbook の実行を制御するオプション"

#: ../../rst/playbook_guide/playbooks_async.rst:184
#: ../../rst/playbook_guide/playbooks_blocks.rst:186
#: ../../rst/playbook_guide/playbooks_debugger.rst:337
#: ../../rst/playbook_guide/playbooks_delegation.rst:165
#: ../../rst/playbook_guide/playbooks_environment.rst:148
#: ../../rst/playbook_guide/playbooks_error_handling.rst:268
#: ../../rst/playbook_guide/playbooks_prompts.rst:115
#: ../../rst/playbook_guide/playbooks_startnstep.rst:43
#: ../../rst/playbook_guide/playbooks_tags.rst:425
#: ../../rst/playbook_guide/playbooks_templating.rst:25
#: ../../rst/playbook_guide/playbooks_tests.rst:527
msgid ":ref:`playbooks_intro`"
msgstr ":ref:`playbooks_intro`"

#: ../../rst/playbook_guide/playbooks_async.rst:186
#: ../../rst/playbook_guide/playbooks_blocks.rst:190
#: ../../rst/playbook_guide/playbooks_conditionals.rst:548
#: ../../rst/playbook_guide/playbooks_debugger.rst:339
#: ../../rst/playbook_guide/playbooks_delegation.rst:171
#: ../../rst/playbook_guide/playbooks_environment.rst:150
#: ../../rst/playbook_guide/playbooks_error_handling.rst:276
#: ../../rst/playbook_guide/playbooks_filters.rst:2196
#: ../../rst/playbook_guide/playbooks_lookups.rst:36
#: ../../rst/playbook_guide/playbooks_loops.rst:496
#: ../../rst/playbook_guide/playbooks_prompts.rst:121
#: ../../rst/playbook_guide/playbooks_strategies.rst:251
#: ../../rst/playbook_guide/playbooks_tags.rst:429
#: ../../rst/playbook_guide/playbooks_templating.rst:31
#: ../../rst/playbook_guide/playbooks_tests.rst:539
#: ../../rst/playbook_guide/playbooks_variables.rst:529
msgid "`User Mailing List <https://groups.google.com/group/ansible-devel>`_"
msgstr "`User Mailing List <https://groups.google.com/group/ansible-devel>`_"

#: ../../rst/playbook_guide/playbooks_blocks.rst:5
msgid "Blocks"
msgstr "ブロック"

#: ../../rst/playbook_guide/playbooks_blocks.rst:7
msgid "Blocks create logical groups of tasks. Blocks also offer ways to handle task errors, similar to exception handling in many programming languages."
msgstr "ブロックは、タスクの論理的なグループを作ります。また、ブロックにはタスクのエラーを処理する方法があり、多くのプログラミング言語の例外処理に似ています。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:13
msgid "Grouping tasks with blocks"
msgstr "ブロックを使用したタスクのグループ化"

#: ../../rst/playbook_guide/playbooks_blocks.rst:15
msgid "All tasks in a block inherit directives applied at the block level. Most of what you can apply to a single task (with the exception of loops) can be applied at the block level, so blocks make it much easier to set data or directives common to the tasks. The directive does not affect the block itself, it is only inherited by the tasks enclosed by a block. For example, a `when` statement is applied to the tasks within a block, not to the block itself."
msgstr "ブロック内のすべてのタスクは、ブロックレベルで適用されるディレクティブを継承します。単一のタスクに適用できるもの (ループを除く) のほとんどは、ブロックレベルで適用できるため、ブロックを使用すると、タスクに共通するデータやディレクティブを設定することが非常に簡単になります。ディレクティブはブロック自体には影響せず、ブロックで囲まれたタスクにのみ継承されます。たとえば、`when` 文は、ブロック自体にではなく、ブロック内のタスクに適用されます。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:17
msgid "Block example with named tasks inside the block"
msgstr "内部に名前付きタスクを含むブロックの例"

#: ../../rst/playbook_guide/playbooks_blocks.rst:46
msgid "In the example above, the 'when' condition will be evaluated before Ansible runs each of the three tasks in the block. All three tasks also inherit the privilege escalation directives, running as the root user. Finally, ``ignore_errors: yes`` ensures that Ansible continues to execute the playbook even if some of the tasks fail."
msgstr "上の例では、Ansible がブロック内の 3 つのタスクをそれぞれ実行する前に、「when」条件が評価されます。また、3 つのタスクはすべて、特権昇格ディレクティブを継承し、root ユーザーとして実行します。最後に、``ignore_errors: yes`` は、一部のタスクが失敗しても、Ansible が Playbook の実行を継続することを保証します。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:48
msgid "Names for blocks have been available since Ansible 2.3. We recommend using names in all tasks, within blocks or elsewhere, for better visibility into the tasks being executed when you run the playbook."
msgstr "ブロックの名前は、Ansible 2.3 から利用できるようになりました。Playbook の実行時に実行されているタスクの可視性を高めるために、ブロック内やその他の場所で、すべてのタスクに名前を使用することが推奨されます。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:53
msgid "Handling errors with blocks"
msgstr "ブロックを使用したエラーの処理"

#: ../../rst/playbook_guide/playbooks_blocks.rst:55
msgid "You can control how Ansible responds to task errors using blocks with ``rescue`` and ``always`` sections."
msgstr "``rescue`` セクションおよび ``always`` セクションのブロックを使用して、Ansible がタスクエラーに対応する方法を制御できます。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:57
msgid "Rescue blocks specify tasks to run when an earlier task in a block fails. This approach is similar to exception handling in many programming languages. Ansible only runs rescue blocks after a task returns a 'failed' state. Bad task definitions and unreachable hosts will not trigger the rescue block."
msgstr "レスキューブロックは、ブロック内の先行タスクが失敗したときに実行するタスクを指定します。このアプローチは、多くのプログラミング言語における例外処理に似ています。Ansible は、タスクが「失敗」状態を返した後にのみレスキューブロックを実行します。誤ったタスク定義や到達不可能なホストでは、レスキューブロックは実行しません。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:60
msgid "Block error handling example"
msgstr "ブロックエラー処理例"

#: ../../rst/playbook_guide/playbooks_blocks.rst:82
msgid "You can also add an ``always`` section to a block. Tasks in the ``always`` section run no matter what the task status of the previous block is."
msgstr "``always`` セクションをブロックに追加することもできます。前のブロックのタスクステータスに関係なく、``always`` セクションのタスクは実行します。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:85
msgid "Block with always section"
msgstr "always セクションのあるブロック"

#: ../../rst/playbook_guide/playbooks_blocks.rst:106
msgid "Together, these elements offer complex error handling."
msgstr "この要素をまとめると、複雑なエラー処理を行います。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:108
msgid "Block with all sections"
msgstr "すべてのセクションのブロック"

#: ../../rst/playbook_guide/playbooks_blocks.rst:140
msgid "The tasks in the ``block`` execute normally. If any tasks in the block return ``failed``, the ``rescue`` section executes tasks to recover from the error. The ``always`` section runs regardless of the results of the ``block`` and ``rescue`` sections."
msgstr "``block`` のタスクは正常に実行されます。ブロック内のいずれかのタスクが ``failed`` を返すと、``rescue`` セクションはエラーから回復するためのタスクを実行します。``always`` セクションは、``block`` セクションと ``rescue`` セクションの結果に関わらず実行されます。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:142
msgid "If an error occurs in the block and the rescue task succeeds, Ansible reverts the failed status of the original task for the run and continues to run the play as if the original task had succeeded. The rescued task is considered successful, and does not trigger ``max_fail_percentage`` or ``any_errors_fatal`` configurations. However, Ansible still reports a failure in the playbook statistics."
msgstr "ブロック内でエラーが発生し、レスキュータスクが成功した場合、Ansible は実行中の元のタスクの失敗ステータスを元に戻し、元のタスクが成功したかのようにプレイの実行を継続します。レスキューとなったタスクは成功したとみなされ、``max_fail_percentage`` や ``any_errors_fatal`` の設定は発生しません。ただし、Ansible は Playbook の統計で失敗を報告します。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:144
msgid "You can use blocks with ``flush_handlers`` in a rescue task to ensure that all handlers run even if an error occurs:"
msgstr "レスキュータスクにおいて ``flush_handlers`` でブロックを使用し、エラーが発生した場合でもすべてのハンドラーが実行されるようにします。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:146
msgid "Block run handlers in error handling"
msgstr "エラー処理におけるブロック実行ハンドラー"

#: ../../rst/playbook_guide/playbooks_blocks.rst:172
msgid "Ansible provides a couple of variables for tasks in the ``rescue`` portion of a block:"
msgstr "Ansible は、ブロックの ``rescue`` の部分にタスクの変数をいくつか提供します。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:175
msgid "ansible_failed_task"
msgstr "ansible_failed_task"

#: ../../rst/playbook_guide/playbooks_blocks.rst:175
msgid "The task that returned 'failed' and triggered the rescue. For example, to get the name use ``ansible_failed_task.name``."
msgstr "「失敗した」と返され、レスキューのきっかけとなったタスクです。たとえば、名前を取得するには ``ansible_failed_task.name`` を使用します。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:178
msgid "ansible_failed_result"
msgstr "ansible_failed_result"

#: ../../rst/playbook_guide/playbooks_blocks.rst:178
msgid "The captured return result of the failed task that triggered the rescue. This would equate to having used this var in the ``register`` keyword."
msgstr "レスキューをトリガーした失敗したタスクの戻り値。これは、``register`` キーワードでこの変数を使用するのと同じです。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:182
msgid "In ``ansible-core`` 2.14 or later, both variables are propagated from an inner block to an outer ``rescue`` portion of a block."
msgstr "``ansible-core`` 2.14 以降では、両方の変数が内部ブロックからブロックの外部の ``rescue`` 部分に伝播されます。"

#: ../../rst/playbook_guide/playbooks_blocks.rst:189
#: ../../rst/playbook_guide/playbooks_conditionals.rst:543
#: ../../rst/playbook_guide/playbooks_filters.rst:2193
#: ../../rst/playbook_guide/playbooks_loops.rst:489
#: ../../rst/playbook_guide/playbooks_strategies.rst:250
#: ../../rst/playbook_guide/playbooks_tags.rst:428
#: ../../rst/playbook_guide/playbooks_tests.rst:536
#: ../../rst/playbook_guide/playbooks_variables.rst:524
msgid "Playbook organization by roles"
msgstr "ロール別の Playbook の組織"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:5
msgid "Validating tasks: check mode and diff mode"
msgstr "タスクの検証: チェックモードと差分モード"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:7
msgid "Ansible provides two modes of execution that validate tasks: check mode and diff mode. These modes can be used separately or together. They are useful when you are creating or editing a playbook or role and you want to know what it will do. In check mode, Ansible runs without making any changes on remote systems. Modules that support check mode report the changes they would have made. Modules that do not support check mode report nothing and do nothing. In diff mode, Ansible provides before-and-after comparisons. Modules that support diff mode display detailed information. You can combine check mode and diff mode for detailed validation of your playbook or role."
msgstr "Ansible には、タスクを検証するために、チェックモードと差分モードという 2 つの実行モードが用意されています。これらのモードは、別々に使用することも、一緒に使用することもできます。これらのモードは、Playbook やロールを作成または編集する際に、その実行内容を知りたい場合に便利です。チェックモードでは、Ansible はリモートシステムに変更を加えずに実行します。チェックモードをサポートするモジュールは、自身が行った変更を報告します。チェックモードをサポートしていないモジュールは、何も報告せず、何も行いません。差分モードでは、Ansible は事前と事後の比較を行います。差分モードをサポートするモジュールは、詳細情報を表示します。チェックモードと差分モードを組み合わせて、Playbook やロールの詳細な検証を行うことができます。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:13
msgid "Using check mode"
msgstr "チェックモードの使用"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:15
msgid "Check mode is just a simulation. It will not generate output for tasks that use :ref:`conditionals based on registered variables <conditionals_registered_vars>` (results of prior tasks). However, it is great for validating configuration management playbooks that run on one node at a time. To run a playbook in check mode:"
msgstr "チェックモードはあくまでもシミュレーションです。:ref:`conditionals based on registered variables <conditionals_registered_vars>` (先行タスクの結果) を使用するタスクの出力は生成されません。しかし、一度に 1 つのノードで実行する構成管理の Playbook を検証するには最適です。Playbook をチェックモードで実行するには以下を行います。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:24
msgid "Enforcing or preventing check mode on tasks"
msgstr "タスクでのチェックモードの強制または禁止"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:28
msgid "If you want certain tasks to run in check mode always, or never, regardless of whether you run the playbook with or without ``--check``, you can add the ``check_mode`` option to those tasks:"
msgstr "Playbook を実行する際に ``--check`` を付けるかどうかに関わらず、特定のタスクを常にチェックモードで実行する場合は、それらのタスクに ``check_mode`` オプションを追加します。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:30
msgid "To force a task to run in check mode, even when the playbook is called without ``--check``, set ``check_mode: yes``."
msgstr "``--check`` を使用せずに Playbook が呼び出された場合でも、タスクを強制的にチェックモードで実行するには、``check_mode: yes`` を設定します。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:31
msgid "To force a task to run in normal mode and make changes to the system, even when the playbook is called with ``--check``, set ``check_mode: no``."
msgstr "Playbook が ``--check`` で呼び出された場合でも、タスクを強制的に通常モードで実行し、システムに変更を加えるには、``check_mode: no`` を設定します。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:33
#: ../../rst/playbook_guide/playbooks_filters.rst:809
#: ../../rst/playbook_guide/playbooks_tags.rst:285
#: ../../rst/playbook_guide/playbooks_tags.rst:315
msgid "For example:"
msgstr "例:"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:50
msgid "Running single tasks with ``check_mode: yes`` can be useful for testing Ansible modules, either to test the module itself or to test the conditions under which a module would make changes. You can register variables (see :ref:`playbooks_conditionals`) on these tasks for even more detail on the potential changes."
msgstr "``check_mode: yes`` を使用してシングルタスクを実行すると、Ansible モジュールをテストする際に便利です。モジュール自体をテストしたり、モジュールが変更を行う条件をテストしたりすることができます。これらのタスクに変数 (:ref:`playbooks_conditionals` を参照) を登録すると、潜在的な変更についてさらに詳しく知ることができます。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:52
msgid "Prior to version 2.2 only the equivalent of ``check_mode: no`` existed. The notation for that was ``always_run: yes``."
msgstr "バージョン 2.2 以前では、``check_mode: no`` に相当するものだけが存在していました。その表記法は ``always_run: yes`` でした。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:55
msgid "Skipping tasks or ignoring errors in check mode"
msgstr "タスクをスキップまたはチェックモードでエラーを無視する"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:59
msgid "If you want to skip a task or ignore errors on a task when you run Ansible in check mode, you can use a boolean magic variable ``ansible_check_mode``, which is set to ``True`` when Ansible runs in check mode. For example:"
msgstr "Ansible をチェックモードで実行する際に、タスクをスキップしたり、タスクのエラーを無視したりする場合は、ブール型のマジック変数 ``ansible_check_mode`` を使用することができます。この変数は、Ansible をチェックモードで実行すると、``True`` に設定されます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:80
msgid "Using diff mode"
msgstr "差分モードの使用"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:82
msgid "The ``--diff`` option for ansible-playbook can be used alone or with ``--check``. When you run in diff mode, any module that supports diff mode reports the changes made or, if used with ``--check``, the changes that would have been made. Diff mode is most common in modules that manipulate files (for example, the template module) but other modules might also show 'before and after' information (for example, the user module)."
msgstr "ansible-playbook の ``--diff`` オプションは、単独でも ``--check`` と併用しても構いません。差分モードで実行すると、差分モードをサポートしているすべてのモジュールが、行われた変更を報告します (``--check`` と併用する場合は、行われたであろう変更を報告します)。差分モードは、ファイルを操作するモジュール (template モジュールなど) で最も一般的ですが、その他のモジュールでも「変更前と変更後」の情報を表示することがあります (user モジュールなど)。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:84
msgid "Diff mode produces a large amount of output, so it is best used when checking a single host at a time. For example:"
msgstr "差分モードは大量の出力を生成するため、一度に 1 つのホストを確認するときに使うのが最適です。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:93
msgid "Enforcing or preventing diff mode on tasks"
msgstr "タスクでの差分モードの強制または禁止"

#: ../../rst/playbook_guide/playbooks_checkmode.rst:95
msgid "Because the ``--diff`` option can reveal sensitive information, you can disable it for a task by specifying ``diff: no``. For example:"
msgstr "``--diff`` オプションは機密情報を表示する可能性があるため、``diff: no`` を指定してタスクに対してこれを無効にすることができます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:5
msgid "Conditionals"
msgstr "条件分岐 (Conditional)"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:7
msgid "In a playbook, you may want to execute different tasks, or have different goals, depending on the value of a fact (data about the remote system), a variable, or the result of a previous task. You may want the value of some variables to depend on the value of other variables. Or you may want to create additional groups of hosts based on whether the hosts match other criteria. You can do all of these things with conditionals."
msgstr "Playbook では、ファクト (リモートシステムに関するデータ)、変数、または以前のタスクの結果の値に応じて、異なるタスクを実行したり、異なるゴールを設定したりすることができます。また、ある変数の値に応じて別の変数の値を変更したい場合もあります。また、ホストが他の基準に一致するかどうかに基づいて、ホストの追加グループを作成することもできます。これらのことはすべて、条件分岐で実現できます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:9
msgid "Ansible uses Jinja2 :ref:`tests <playbooks_tests>` and :ref:`filters <playbooks_filters>` in conditionals. Ansible supports all the standard tests and filters, and adds some unique ones as well."
msgstr "Ansible は Jinja2 の :ref:`テスト <playbooks_tests>` および :ref:`フィルター <playbooks_filters>` を条件分岐で使用しています。Ansible は標準的なテストやフィルターをすべてサポートしており、独自のものもいくつか追加されています。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:13
msgid "There are many options to control execution flow in Ansible. You can find more examples of supported conditionals at `<https://jinja.palletsprojects.com/en/latest/templates/#comparisons>`_."
msgstr "Ansible で実行フローを制御するオプションは多数あります。サポートされている条件分岐の例は、`<https://jinja.palletsprojects.com/en/latest/templates/#comparisons>`_ で確認できます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:21
msgid "Basic conditionals with ``when``"
msgstr "``when`` を使用する基本的な条件分岐"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:23
msgid "The simplest conditional statement applies to a single task. Create the task, then add a ``when`` statement that applies a test. The ``when`` clause is a raw Jinja2 expression without double curly braces (see :ref:`group_by_module`). When you run the task or playbook, Ansible evaluates the test for all hosts. On any host where the test passes (returns a value of True), Ansible runs that task. For example, if you are installing mysql on multiple machines, some of which have SELinux enabled, you might have a task to configure SELinux to allow mysql to run. You would only want that task to run on machines that have SELinux enabled:"
msgstr "最も簡単な条件文は、1 つのタスクに適用されるものです。タスクを作成し、テストを適用する ``when`` の文を追加します。``when`` 句は、二重中括弧のない生の Jinja2 式です (:ref:`group_by_module` 参照)。タスクや Playbook を実行すると、Ansible はすべてのホストに対してテストを評価します。テストにパスする (True の値を返す) ホストでは、Ansible はそのタスクを実行します。たとえば、複数のマシンに mysql をインストールし、そのうちのいくつかのマシンでは SELinux が有効になっている場合は、mysql の実行を許可するように SELinux を設定するタスクがあります。このタスクは、SELinux が有効になっているマシンでのみ実行されるようにします。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:37
msgid "Conditionals based on ansible_facts"
msgstr "ansible_facts に基づく条件分岐"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:39
msgid "Often you want to execute or skip a task based on facts. Facts are attributes of individual hosts, including IP address, operating system, the status of a filesystem, and many more. With conditionals based on facts:"
msgstr "ファクトに基づいてタスクを実行したりスキップしたりしたい場合がよくあります。ファクトとは、IP アドレス、オペレーティングシステム、ファイルシステムの状態など、個々のホストの属性のことです。ファクトに基づく条件分岐で、以下を行います。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:41
msgid "You can install a certain package only when the operating system is a particular version."
msgstr "特定のパッケージは、オペレーティングシステムが特定のバージョンの場合にのみインストールできます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:42
msgid "You can skip configuring a firewall on hosts with internal IP addresses."
msgstr "内部 IP アドレスを持つホストでファイアウォールの設定を省略できます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:43
msgid "You can perform cleanup tasks only when a filesystem is getting full."
msgstr "ファイルシステムが満杯になった場合にのみ、クリーンアップタスクを実行することができます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:45
msgid "See :ref:`commonly_used_facts` for a list of facts that frequently appear in conditional statements. Not all facts exist for all hosts. For example, the 'lsb_major_release' fact used in an example below only exists when the lsb_release package is installed on the target host. To see what facts are available on your systems, add a debug task to your playbook:"
msgstr "条件文に頻繁に現れるファクトの一覧は、:ref:`commonly_used_facts` を参照してください。すべてのファクトがすべてのホストに存在するわけではありません。たとえば、以下の例で使用されている「lsb_major_release」ファクトは、ターゲットホストに lsb_release パッケージがインストールされている場合にのみ存在します。システム上で利用可能なファクトを確認するには、Playbook にデバッグタスクを追加します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:53
msgid "Here is a sample conditional based on a fact:"
msgstr "以下は、ファクトに基づく条件分岐の例です。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:62
msgid "If you have multiple conditions, you can group them with parentheses:"
msgstr "複数の条件がある場合は、括弧でグループ化できます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:72
msgid "You can use `logical operators <https://jinja.palletsprojects.com/en/latest/templates/#logic>`_ to combine conditions. When you have multiple conditions that all need to be true (that is, a logical ``and``), you can specify them as a list:"
msgstr "`logical operators <https://jinja.palletsprojects.com/en/latest/templates/#logic>`_ を使用して条件を組み合わせることができます。すべてが True である必要がある複数の条件がある場合 (つまり、論理的な ``and``)、それらをリストとして指定することができます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:83
msgid "If a fact or variable is a string, and you need to run a mathematical comparison on it, use a filter to ensure that Ansible reads the value as an integer:"
msgstr "ファクトまたは変数が文字列で、それに対して数学比較を実行する必要がある場合は、フィルターを使用して Ansible が値を整数として読み取るようにします。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:94
msgid "Conditions based on registered variables"
msgstr "登録済みの変数に基づく条件"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:96
msgid "Often in a playbook you want to execute or skip a task based on the outcome of an earlier task. For example, you might want to configure a service after it is upgraded by an earlier task. To create a conditional based on a registered variable:"
msgstr "Playbook では、以前のタスクの結果に基づいてタスクを実行またはスキップしたい場合がよくあります。たとえば、以前のタスクによってサービスがアップグレードされた後に、そのサービスを設定したい場合などです。登録された変数に基づいて条件分岐を作成するには、次のようにします。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:98
msgid "Register the outcome of the earlier task as a variable."
msgstr "以前のタスクの結果を変数として登録します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:99
msgid "Create a conditional test based on the registered variable."
msgstr "登録した変数に基づいて条件分岐テストを作成します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:101
msgid "You create the name of the registered variable using the ``register`` keyword. A registered variable always contains the status of the task that created it as well as any output that task generated. You can use registered variables in templates and action lines as well as in conditional ``when`` statements. You can access the string contents of the registered variable using ``variable.stdout``. For example:"
msgstr "登録された変数の名前は、``register`` キーワードを使用して作成します。登録された変数には、そのキーワードを作成したタスクのステータスと、そのタスクが生成した出力が常に含まれています。登録された変数は、テンプレートやアクション行、および条件付きの ``when`` 文で使用できます。登録された変数の文字列内容にアクセスするには、``variable.stdout`` を使用します。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:118
msgid "You can use registered results in the loop of a task if the variable is a list. If the variable is not a list, you can convert it into a list, with either ``stdout_lines`` or with ``variable.stdout.split()``. You can also split the lines by other fields:"
msgstr "登録された結果は、変数がリストの場合、タスクのループ内で使用できます。変数がリストでない場合は、``stdout_lines`` または ``variable.stdout.split()`` でリストに変換できます。また、他のフィールドで行を分割することもできます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:138
msgid "The string content of a registered variable can be empty. If you want to run another task only on hosts where the stdout of your registered variable is empty, check the registered variable's string contents for emptiness:"
msgstr "登録された変数の文字列内容は空になることがあります。登録された変数の標準出力が空のホストでのみ別のタスクを実行したい場合は、登録された変数の文字列内容が空であるかどうかをチェックします。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:156
msgid "Ansible always registers something in a registered variable for every host, even on hosts where a task fails or Ansible skips a task because a condition is not met. To run a follow-up task on these hosts, query the registered variable for ``is skipped`` (not for \"undefined\" or \"default\"). See :ref:`registered_variables` for more information. Here are sample conditionals based on the success or failure of a task. Remember to ignore errors if you want Ansible to continue executing on a host when a failure occurs:"
msgstr "タスクが失敗したホストや、条件が満たされずに Ansible がタスクをスキップしたホストであっても、Ansible は常にすべてのホストの登録変数に何かを登録します。これらのホストでフォローアップタスクを実行するには、登録済みの変数に ``is skipped`` を照会します (「undefined」や「default」ではありません)。詳細は、「:ref:`registered_variables`」を参照してください。以下は、タスクの成功または失敗に基づく条件分岐のサンプルです。失敗したときにホスト上で Ansible の実行を継続させたい場合は、エラーを無視することを忘れないでください。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:178
msgid "Older versions of Ansible used ``success`` and ``fail``, but ``succeeded`` and ``failed`` use the correct tense. All of these options are now valid."
msgstr "古いバージョンの Ansible では、``success`` および ``fail`` が使用されていましたが、``succeeded`` および ``failed`` は正しい時制を使用します。このオプションはすべて有効になりました。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:182
msgid "Conditionals based on variables"
msgstr "変数に基づく条件分岐"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:184
msgid "You can also create conditionals based on variables defined in the playbooks or inventory. Because conditionals require boolean input (a test must evaluate as True to trigger the condition), you must apply the ``| bool`` filter to non boolean variables, such as string variables with content like 'yes', 'on', '1', or 'true'. You can define variables like this:"
msgstr "また、Playbook やインベントリーで定義された変数に基づいて、条件分岐を作成することもできます。条件分岐にはブール値の入力が必要なため (条件を成立させるためには、テストが True と評価されなければなりません)、「yes」、「on」、「1」、「true」などの内容を持つ文字列変数など、ブール値以外の変数には、``| bool`` フィルターを適用する必要があります。変数は次のように定義できます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:192
msgid "With the variables above, Ansible would run one of these tasks and skip the other:"
msgstr "上記の変数を使用すると、Ansible はこれらのタスクのいずれかを実行し、他のタスクを省略します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:205
msgid "If a required variable has not been set, you can skip or fail using Jinja2's `defined` test. For example:"
msgstr "必要な変数が設定されていない場合は、省略するか、Jinja2 の `定義済み` テストを使用して失敗します。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:218
msgid "This is especially useful in combination with the conditional import of vars files (see below). As the examples show, you do not need to use `{{ }}` to use variables inside conditionals, as these are already implied."
msgstr "これは、変数ファイルの条件分岐インポートとの組み合わせで特に有効です (以下参照)。これらの例が示すように、条件分岐の中で変数を使用するために `{{ }}` を使用する必要はありません。それらはすでに暗示されているためです。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:224
msgid "Using conditionals in loops"
msgstr "ループでの条件分岐の使用"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:226
msgid "If you combine a ``when`` statement with a :ref:`loop <playbooks_loops>`, Ansible processes the condition separately for each item. This is by design, so you can execute the task on some items in the loop and skip it on other items. For example:"
msgstr "``when`` 文と :ref:`loop <playbooks_loops>` を組み合わせた場合、Ansible は各アイテムに対して個別に条件を処理します。これは意図的なもので、ループ内の一部のアイテムでタスクを実行し、他のアイテムではスキップすることができます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:236
msgid "If you need to skip the whole task when the loop variable is undefined, use the `|default` filter to provide an empty iterator. For example, when looping over a list:"
msgstr "ループ変数が未定義のときにタスク全体を省略する必要がある場合は、`|default` フィルターを使用して空のイテレーターを指定します。たとえば、リストをループする場合は、以下を行います。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:245
msgid "You can do the same thing when looping over a dict:"
msgstr "同じことが、ディクショナリーをループするときにもできます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:257
msgid "Loading custom facts"
msgstr "カスタムファクトの読み込み中"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:259
msgid "You can provide your own facts, as described in :ref:`developing_modules`.  To run them, just make a call to your own custom fact gathering module at the top of your list of tasks, and variables returned there will be accessible to future tasks:"
msgstr ":ref:`developing_modules` で説明しているように、独自のファクトを提供することができます。それらを実行するには、タスクリストの先頭にある独自のカスタムファクト収集モジュールを呼び出すだけで、そこから返された変数は将来のタスクにアクセスできるようになります。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:274
msgid "Conditionals with re-use"
msgstr "再利用による条件分岐"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:276
msgid "You can use conditionals with re-usable tasks files, playbooks, or roles. Ansible executes these conditional statements differently for dynamic re-use (includes) and for static re-use (imports). See :ref:`playbooks_reuse` for more information on re-use in Ansible."
msgstr "条件分岐は、再利用可能なタスクファイル、Playbook、またはロールで使用できます。Ansible はこれらの条件文を、動的再利用 (インクルード) および静的再利用 (インポート) で異なる方法で実行します。Ansible での再利用の詳細は、「:ref:`playbooks_reuse`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:281
msgid "Conditionals with imports"
msgstr "インポートのある条件分岐"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:283
msgid "When you add a conditional to an import statement, Ansible applies the condition to all tasks within the imported file. This behavior is the equivalent of :ref:`tag_inheritance`. Ansible applies the condition to every task, and evaluates each task separately. For example, if you want to define and then display a variable that was not previously defined, you might have a playbook called ``main.yml`` and a tasks file called ``other_tasks.yml``:"
msgstr "インポートステートメントに条件分岐を追加すると、Ansible はインポートされたファイル内のすべてのタスクにその条件を適用します。この動作は、:ref:`tag_inheritance` と同等です。Ansible は、すべてのタスクに条件を適用し、各タスクを個別に評価します。たとえば、以前に定義されていない変数を定義して表示する場合に、``main.yml`` という Playbookと、``other_tasks.yml`` というタスクファイルがあるとします。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:303
#: ../../rst/playbook_guide/playbooks_conditionals.rst:360
msgid "Ansible expands this at execution time to the equivalent of:"
msgstr "Ansible は、実行時にこれを以下に相当するものに拡張します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:319
msgid "If ``x`` is initially defined, both tasks are skipped as intended. But if ``x`` is initially undefined, the debug task will be skipped since the conditional is evaluated for every imported task. The conditional will evaluate to ``true`` for the ``set_fact`` task, which will define the variable and cause the ``debug`` conditional to evaluate to ``false``."
msgstr "``x`` が最初に定義されている場合、両方のタスクが意図した通りにスキップされます。ただし、``x`` が最初に定義されていない場合は、インポートされたすべてのタスクに対して条件が評価されるため、デバッグタスクはスキップされます。この条件は ``set_fact`` に対して ``true`` と評価し、これにより変数が定義され、``debug`` の条件が ``false`` と評価されます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:321
msgid "If this is not the behavior you want, use an ``include_*`` statement to apply a condition only to that statement itself."
msgstr "このような動作を望まない場合は、 文を使用して、その文自体にのみ条件を適用します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:332
msgid "Now if ``x`` is initially undefined, the debug task will not be skipped because the conditional is evaluated at the time of the include and does not apply to the individual tasks."
msgstr "``x`` が最初に定義されていない場合には、include 時に条件が評価され、個別のタスクには適用されないため、デバッグタスクはスキップされません。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:334
msgid "You can apply conditions to ``import_playbook`` as well as to the other ``import_*`` statements. When you use this approach, Ansible returns a 'skipped' message for every task on every host that does not match the criteria, creating repetitive output. In many cases the :ref:`group_by module <group_by_module>` can be a more streamlined way to accomplish the same objective; see :ref:`os_variance`."
msgstr "``import_playbook`` には、他の ``import_*`` 文と同様に条件を適用できます。この方法を使用すると、Ansible は基準に一致しないすべてのホスト上のすべてのタスクに対して「skipped」メッセージを返し、反復的な出力を作成します。多くの場合、:ref:`group_by モジュール <group_by_module>` は、同じ目的を達成するためのより合理的な方法となります。「:ref:`os_variance`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:339
msgid "Conditionals with includes"
msgstr "includes を持つ条件分岐"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:341
msgid "When you use a conditional on an ``include_*`` statement, the condition is applied only to the include task itself and not to any other tasks within the included file(s). To contrast with the example used for conditionals on imports above, look at the same playbook and tasks file, but using an include instead of an import:"
msgstr "``include_*`` 文に条件分岐を使用すると、その条件はインクルードタスク自体にのみ適用され、インクルードファイル内の他のタスクには適用されません。上記のインポートに対する条件分岐の例と対比するために、同じ Playbook とタスクファイルを見てください。ただし、インポートの代わりにインクルードを使用しています。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:380
msgid "By using ``include_tasks`` instead of ``import_tasks``, both tasks from ``other_tasks.yml`` will be executed as expected. For more information on the differences between ``include`` v ``import`` see :ref:`playbooks_reuse`."
msgstr "``import_tasks`` の代わりに ``include_tasks`` を使用すると、``other_tasks.yml`` からの両方のタスクが想定どおりに実行されます。``include`` と ``import`` の相違点は、「:ref:`playbooks_reuse`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:383
msgid "Conditionals with roles"
msgstr "ロールを含む条件分岐"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:385
msgid "There are three ways to apply conditions to roles:"
msgstr "状態をロールに適用する方法は 3 つあります。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:387
msgid "Add the same condition or conditions to all tasks in the role by placing your ``when`` statement under the ``roles`` keyword. See the example in this section."
msgstr "``when`` 文を ``roles`` キーワードの下に置くことで、ロール内のすべてのタスクに同じ条件を追加します。このセクションの例を参照してください。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:388
msgid "Add the same condition or conditions to all tasks in the role by placing your ``when`` statement on a static ``import_role`` in your playbook."
msgstr "Playbook の静的 ``import_role`` に ``when`` 文を配置して、ロール内のすべてのタスクに同じ条件を追加します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:389
msgid "Add a condition or conditions to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role based on your ``when`` statement. To select or skip tasks within the role, you must have conditions set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the condition or conditions to the include. When you use this approach, Ansible applies the condition to the include itself plus any tasks in the role that also have that ``when`` statement."
msgstr "ロール自体の中の個々のタスクまたはブロックに条件を追加します。これは、``when`` 文に基づいてロール内の一部のタスクを選択またはスキップすることができる唯一の方法です。ロール内のタスクを選択またはスキップするには、個々のタスクまたはブロックに条件を設定し、Playbook で動的 ``include_role`` を使用し、条件をインクルードに追加する必要があります。この方法を使用すると、Ansible は条件をインクルード自体に加えて、``when`` の文を持つロール内のすべてのタスクに適用します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:391
msgid "When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds the conditions you define to all the tasks in the role. For example:"
msgstr "``roles`` キーワードを使用して Playbook にロールを静的に組み込むと、Ansible は定義した条件をロール内のすべてのタスクに追加します。たとえば、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:403
msgid "Selecting variables, files, or templates based on facts"
msgstr "ファクトに基づいた変数、ファイル、またはテンプレートの選択"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:405
msgid "Sometimes the facts about a host determine the values you want to use for certain variables or even the file or template you want to select for that host. For example, the names of packages are different on CentOS and on Debian. The configuration files for common services are also different on different OS flavors and versions. To load different variables file, templates, or other files based on a fact about the hosts:"
msgstr "ホストに関するファクトによって、特定の変数に使用する値や、そのホスト用に選択するファイルやテンプレートが決定することがあります。たとえば、パッケージの名前は CentOS と Debian では異なります。また、一般的なサービスの設定ファイルも、OS のフレーバーやバージョンごとに異なります。ホストに関するファクトに基づいて、異なる変数ファイルやテンプレートなどを読み込むには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:407
msgid "name your vars files, templates, or files to match the Ansible fact that differentiates them"
msgstr "変数ファイル、テンプレート、またはファイルを区別する Ansible ファクトに合わせて名前を付ける"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:409
msgid "select the correct vars file, template, or file for each host with a variable based on that Ansible fact"
msgstr "Ansible ファクトに基づいて変数を使用して、各ホストの正しい変数ファイル、テンプレート、またはファイルを選択します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:411
msgid "Ansible separates variables from tasks, keeping your playbooks from turning into arbitrary code with nested conditionals. This approach results in more streamlined and auditable configuration rules because there are fewer decision points to track."
msgstr "Ansible は、変数とタスクを分離することで、Playbook がネストされた条件分岐による任意のコードにならないようにしています。このアプローチでは、追跡すべき決定ポイントが少なくなるため、より合理的で監査可能な設定ルールになります。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:414
msgid "Selecting variables files based on facts"
msgstr "ファクトに基づく変数ファイルの選択"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:416
msgid "You can create a playbook that works on multiple platforms and OS versions with a minimum of syntax by placing your variable values in vars files and conditionally importing them. If you want to install Apache on some CentOS and some Debian servers, create variables files with YAML keys and values. For example:"
msgstr "変数の値を vars ファイルに置き、条件付きでインポートすることで、最小限の構文で複数のプラットフォームや OS バージョンで動作する Playbook を作成することができます。一部の CentOS と一部の Debian サーバーに Apache をインストールする場合は、YAML のキーと値で変数ファイルを作成します。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:425
msgid "Then import those variables files based on the facts you gather on the hosts in your playbook:"
msgstr "次に、Playbook のホストに収集するファクトに基づいて、これらの変数ファイルをインポートします。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:441
msgid "Ansible gathers facts on the hosts in the webservers group, then interpolates the variable \"ansible_facts['os_family']\" into a list of filenames. If you have hosts with Red Hat operating systems (CentOS, for example), Ansible looks for 'vars/RedHat.yml'. If that file does not exist, Ansible attempts to load 'vars/os_defaults.yml'. For Debian hosts, Ansible first looks for 'vars/Debian.yml', before falling back on 'vars/os_defaults.yml'. If no files in the list are found, Ansible raises an error."
msgstr "Ansible は webservers グループに属するホストのファクトを収集し、変数「ansible_facts['os_family']」をファイル名のリストに補間します。Red Hat オペレーティングシステムを搭載したホスト (CentOS など) がある場合、Ansible は「vars/RedHat.yml」を探します。このファイルが存在しない場合、Ansibleは「vars/os_defaults.yml」の読み込みを試みます。Debian ホストの場合、Ansible はまず「vars/Debian.yml」を探し、その後で「vars/os_defaults.yml」にフォールバックします。リスト内のファイルが見つからない場合は、Ansible がエラーを出力します。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:444
msgid "Selecting files and templates based on facts"
msgstr "ファクトに基づくファイルとテンプレートの選択"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:446
msgid "You can use the same approach when different OS flavors or versions require different configuration files or templates. Select the appropriate file or template based on the variables assigned to each host. This approach is often much cleaner than putting a lot of conditionals into a single template to cover multiple OS or package versions."
msgstr "OS のフレーバーやバージョンによって、設定ファイルやテンプレートが異なる場合も同様の方法で対応できます。各ホストに割り当てられた変数に基づいて、適切なファイルやテンプレートを選択します。この方法は、複数の OS やパッケージのバージョンに対応するために 1 つのテンプレートに多くの条件分岐を入れるよりも、はるかにすっきりすることが多いです。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:448
msgid "For example, you can template out a configuration file that is very different between, say, CentOS and Debian:"
msgstr "例えば、CentOS と Debian の間で大きく異なる設定ファイルをテンプレート化することができます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:466
msgid "Commonly-used facts"
msgstr "一般的に使用されるファクト"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:468
msgid "The following Ansible facts are frequently used in conditionals."
msgstr "以下の Ansible ファクトは、条件分岐で頻繁に使用されます。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:473
msgid "ansible_facts['distribution']"
msgstr "ansible_facts['distribution']"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:475
#: ../../rst/playbook_guide/playbooks_conditionals.rst:515
msgid "Possible values (sample, not complete list):"
msgstr "使用できる値 (完全リストではなく一部です):"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:506
msgid "ansible_facts['distribution_major_version']"
msgstr "ansible_facts['distribution_major_version']"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:508
msgid "The major version of the operating system. For example, the value is `16` for Ubuntu 16.04."
msgstr "オペレーティングシステムのメジャーバージョンです。たとえば、Ubuntu 16.04 の場合は `16` となります。"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:513
msgid "ansible_facts['os_family']"
msgstr "ansible_facts['os_family']"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:544
#: ../../rst/playbook_guide/playbooks_error_handling.rst:270
#: ../../rst/playbook_guide/playbooks_filters.rst:2194
#: ../../rst/playbook_guide/playbooks_intro.rst:148
#: ../../rst/playbook_guide/playbooks_loops.rst:490
#: ../../rst/playbook_guide/playbooks_reuse.rst:219
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:596
#: ../../rst/playbook_guide/playbooks_tests.rst:537
#: ../../rst/playbook_guide/playbooks_variables.rst:525
msgid ":ref:`tips_and_tricks`"
msgstr ":ref:`tips_and_tricks`"

#: ../../rst/playbook_guide/playbooks_conditionals.rst:545
#: ../../rst/playbook_guide/playbooks_error_handling.rst:271
#: ../../rst/playbook_guide/playbooks_filters.rst:2195
#: ../../rst/playbook_guide/playbooks_loops.rst:491
#: ../../rst/playbook_guide/playbooks_reuse.rst:220
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:597
#: ../../rst/playbook_guide/playbooks_templating.rst:28
#: ../../rst/playbook_guide/playbooks_tests.rst:538
#: ../../rst/playbook_guide/playbooks_variables.rst:526
msgid "Tips and tricks for playbooks"
msgstr "Playbook のヒントと裏技"

#: ../../rst/playbook_guide/playbooks_debugger.rst:5
msgid "Debugging tasks"
msgstr "タスクのデバッグ"

#: ../../rst/playbook_guide/playbooks_debugger.rst:7
msgid "Ansible offers a task debugger so you can fix errors during execution instead of editing your playbook and running it again to see if your change worked. You have access to all of the features of the debugger in the context of the task. You can check or set the value of variables, update module arguments, and re-run the task with the new variables and arguments. The debugger lets you resolve the cause of the failure and continue with playbook execution."
msgstr "Ansible にはタスクデバッガーがあり、変更が成功したかどうかを確認するために Playbook を編集して再度実行するのではなく、実行中にエラーを修正することができます。タスクのコンテキスト内で、デバッガーのすべての機能にアクセスできます。変数の値をチェックしたり設定したり、モジュールの引数を更新したり、新しい変数や引数を使用してタスクを再実行したりできます。デバッガーは、失敗の原因を解決し、Playbook の実行を続行することができます。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:13
msgid "Enabling the debugger"
msgstr "デバッガーの有効化"

#: ../../rst/playbook_guide/playbooks_debugger.rst:15
msgid "The debugger is not enabled by default. If you want to invoke the debugger during playbook execution, you must enable it first."
msgstr "デバッガーはデフォルトでは有効になっていません。Playbook の実行中にデバッガーを呼び出す場合は、最初に有効にする必要があります。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:17
msgid "Use one of these three methods to enable the debugger:"
msgstr "以下の 3 つの方法のいずれかを使用してデバッガーを有効にします。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:19
msgid "with the debugger keyword"
msgstr "デバッガーキーワードの使用"

#: ../../rst/playbook_guide/playbooks_debugger.rst:20
msgid "in configuration or an environment variable, or"
msgstr "設定または環境変数で"

#: ../../rst/playbook_guide/playbooks_debugger.rst:21
msgid "as a strategy"
msgstr "ストラテジーとして"

#: ../../rst/playbook_guide/playbooks_debugger.rst:24
msgid "Enabling the debugger with the ``debugger`` keyword"
msgstr "``debugger`` キーワードでデバッガーを有効にする"

#: ../../rst/playbook_guide/playbooks_debugger.rst:28
msgid "You can use the ``debugger`` keyword to enable (or disable) the debugger for a specific play, role, block, or task. This option is especially useful when developing or extending playbooks, plays, and roles. You can enable the debugger on new or updated tasks. If they fail, you can fix the errors efficiently. The ``debugger`` keyword accepts five values:"
msgstr "``debugger`` キーワードを使用すると、特定のプレイ、ロール、ブロック、またはタスクに対してデバッガーを有効 (または無効) にすることができます。このオプションは、Playbook、プレイ、およびロールを開発または拡張する際に特に役立ちます。新規または更新されたタスクでデバッガーを有効にすることができます。失敗しても、効率的にエラーを修正することができます。``debugger`` キーワードは 5 つの値を受け入れます。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:34
msgid "Value"
msgstr "値"

#: ../../rst/playbook_guide/playbooks_debugger.rst:34
msgid "Result"
msgstr "結果"

#: ../../rst/playbook_guide/playbooks_debugger.rst:36
msgid "always"
msgstr "always"

#: ../../rst/playbook_guide/playbooks_debugger.rst:36
msgid "Always invoke the debugger, regardless of the outcome"
msgstr "結果に関係なく、常にデバッガーを呼び出します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:38
msgid "never"
msgstr "never"

#: ../../rst/playbook_guide/playbooks_debugger.rst:38
msgid "Never invoke the debugger, regardless of the outcome"
msgstr "結果に関係なく、デバッガーを呼び出しません。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:40
msgid "on_failed"
msgstr "on_failed"

#: ../../rst/playbook_guide/playbooks_debugger.rst:40
msgid "Only invoke the debugger if a task fails"
msgstr "タスクが失敗した場合に限りデバッガーを呼び出します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:42
msgid "on_unreachable"
msgstr "on_unreachable"

#: ../../rst/playbook_guide/playbooks_debugger.rst:42
msgid "Only invoke the debugger if a host is unreachable"
msgstr "ホストが到達できない場合に限りデバッガーを呼び出します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:44
msgid "on_skipped"
msgstr "on_skipped"

#: ../../rst/playbook_guide/playbooks_debugger.rst:44
msgid "Only invoke the debugger if the task is skipped"
msgstr "タスクがスキップされた場合に限りデバッガーを呼び出します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:48
msgid "When you use the ``debugger`` keyword, the value you specify overrides any global configuration to enable or disable the debugger. If you define ``debugger`` at multiple levels, such as in a role and in a task, Ansible honors the most granular definition. The definition at the play or role level applies to all blocks and tasks within that play or role, unless they specify a different value. The definition at the block level overrides the definition at the play or role level, and applies to all tasks within that block, unless they specify a different value. The definition at the task level always applies to the task; it overrides the definitions at the block, play, or role level."
msgstr "``debugger`` キーワードを使用すると、指定した値が、デバッガ―を有効または無効にするグローバル構成よりも優先されます。``debugger`` をロールやタスクなどの複数のレベルで定義した場合、Ansible は最も詳細な定義を尊重します。プレイまたはロールのレベルでの定義は、異なる値を指定しない限り、そのプレイまたはロール内のすべてのブロックおよびタスクに適用されます。ブロックレベルの定義は、プレイまたはロールレベルの定義よりも優先され、異なる値が指定されていない限り、そのブロック内のすべてのタスクに適用されます。タスクレベルでの定義は、常にタスクに適用され、ブロック、プレイ、またはロールレベルでの定義よりも優先されます。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:51
msgid "Examples of using the ``debugger`` keyword"
msgstr "``debugger`` キーワードの使用例"

#: ../../rst/playbook_guide/playbooks_debugger.rst:53
msgid "Example of setting the ``debugger`` keyword on a task:"
msgstr "タスクに ``debugger`` キーワードを設定する例:"

#: ../../rst/playbook_guide/playbooks_debugger.rst:61
msgid "Example of setting the ``debugger`` keyword on a play:"
msgstr "プレイに ``debugger`` キーワードを設定する例:"

#: ../../rst/playbook_guide/playbooks_debugger.rst:73
msgid "Example of setting the ``debugger`` keyword at multiple levels:"
msgstr "複数のレベルで ``debugger`` キーワードを設定する例:"

#: ../../rst/playbook_guide/playbooks_debugger.rst:85
msgid "In this example, the debugger is set to ``never`` at the play level and to ``on_failed`` at the task level. If the task fails, Ansible invokes the debugger, because the definition on the task overrides the definition on its parent play."
msgstr "この例では、デバッガーは、プレイレベルでは ``never`` に、タスクレベルでは ``on_failed`` に設定されています。タスクが失敗した場合、タスクの定義が親プレイの定義を上書きするため、Ansible はデバッガーを起動します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:88
msgid "Enabling the debugger in configuration or an environment variable"
msgstr "設定または環境変数でのデバッガーの有効化"

#: ../../rst/playbook_guide/playbooks_debugger.rst:92
msgid "You can enable the task debugger globally with a setting in ansible.cfg or with an environment variable. The only options are ``True`` or ``False``. If you set the configuration option or environment variable to ``True``, Ansible runs the debugger on failed tasks by default."
msgstr "タスクデバッガーをグローバルに有効にするには、ansible.cfg 内の設定または環境変数を使用します。オプションは ``True`` または ``False`` のみです。設定オプションまたは環境変数を ``True`` に設定した場合、Ansible はデフォルトで失敗したタスクに対してデバッガーを実行します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:94
msgid "To enable the task debugger from ansible.cfg, add this setting to the defaults section:"
msgstr "ansible.cfg からタスクデバッガーを有効にするには、以下の設定を defaults セクションに追加します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:101
msgid "To enable the task debugger with an environment variable, pass the variable when you run your playbook:"
msgstr "環境変数でタスクデバッガーを有効にするには、Playbook の実行時に変数を渡します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:107
msgid "When you enable the debugger globally, every failed task invokes the debugger, unless the role, play, block, or task explicitly disables the debugger. If you need more granular control over what conditions trigger the debugger, use the ``debugger`` keyword."
msgstr "グローバルにデバッガを有効にすると、ロール、プレイ、ブロック、またはタスクが明示的にデバッガ―を無効にしていない限り、失敗したタスクはすべてデバッガ―を起動します。どのような条件でデバッガーが起動するかをより詳細に制御する必要がある場合は、``debugger`` キーワードを使用します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:110
msgid "Enabling the debugger as a strategy"
msgstr "ストラテジーとしてのデバッガーの有効化"

#: ../../rst/playbook_guide/playbooks_debugger.rst:112
msgid "If you are running legacy playbooks or roles, you may see the debugger enabled as a :ref:`strategy <strategy_plugins>`. You can do this at the play level, in ansible.cfg, or with the environment variable ``ANSIBLE_STRATEGY=debug``. For example:"
msgstr "レガシーの Playbook やロールを実行している場合は、:ref:`strategy <strategy_plugins>` としてデバッガーが有効になっていることがあります。この設定は、プレイレベル、ansible.cfg、または環境変数 ``ANSIBLE_STRATEGY=debug`` で行うことができます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:121
msgid "Or in ansible.cfg:"
msgstr "または ansible.cfg で以下を行います。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:130
msgid "This backwards-compatible method, which matches Ansible versions before 2.5, may be removed in a future release."
msgstr "この後方互換性のある方法は、Ansible の 2.5 以前のバージョンに対応していますが、将来のリリースでは削除される可能性があります。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:133
msgid "Resolving errors in the debugger"
msgstr "デバッガーでエラーの解決"

#: ../../rst/playbook_guide/playbooks_debugger.rst:135
msgid "After Ansible invokes the debugger, you can use the seven :ref:`debugger commands <available_commands>` to resolve the error that Ansible encountered. Consider this example playbook, which defines the ``var1`` variable but uses the undefined ``wrong_var`` variable in a task by mistake."
msgstr "Ansible がデバッガーを起動した後、7 つの :ref:`debugger コマンド <available_commands>` を使用して、Ansibleが遭遇したエラーを解決することができます。この Playbook の例では ``var1`` 変数を定義していますが、未定義の ``wrong_var`` 変数を誤ってタスクで使用します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:148
msgid "If you run this playbook, Ansible invokes the debugger when the task fails. From the debug prompt, you can change the module arguments or the variables and run the task again."
msgstr "この Playbook を実行すると、Ansible はタスクの失敗時にデバッガーを呼び出します。デバッグプロンプトから、モジュール引数または変数を変更して、タスクを再度実行できます。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:183
msgid "Changing the task arguments in the debugger to use ``var1`` instead of ``wrong_var`` makes the task run successfully."
msgstr "デバッガでタスクの引数 ``wrong_var`` の代わりに ``var1`` を使用するように変更すると、タスクが正常に実行されます。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:188
msgid "Available debug commands"
msgstr "利用可能なデバッグコマンド"

#: ../../rst/playbook_guide/playbooks_debugger.rst:190
msgid "You can use these seven commands at the debug prompt:"
msgstr "これらの 7 つのコマンドは、デバッグプロンプトで使用できます。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:196
msgid "Command"
msgstr "コマンド"

#: ../../rst/playbook_guide/playbooks_debugger.rst:196
msgid "Shortcut"
msgstr "ショートカット"

#: ../../rst/playbook_guide/playbooks_debugger.rst:196
msgid "Action"
msgstr "アクション"

#: ../../rst/playbook_guide/playbooks_debugger.rst:198
msgid "print"
msgstr "print"

#: ../../rst/playbook_guide/playbooks_debugger.rst:198
msgid "p"
msgstr "p"

#: ../../rst/playbook_guide/playbooks_debugger.rst:198
msgid "Print information about the task"
msgstr "タスクに関する情報を出力する"

#: ../../rst/playbook_guide/playbooks_debugger.rst:200
msgid "task.args[*key*] = *value*"
msgstr "task.args[*key*] = *value*"

#: ../../rst/playbook_guide/playbooks_debugger.rst:200
#: ../../rst/playbook_guide/playbooks_debugger.rst:202
msgid "no shortcut"
msgstr "ショートカットなし"

#: ../../rst/playbook_guide/playbooks_debugger.rst:200
msgid "Update module arguments"
msgstr "モジュール引数を更新する"

#: ../../rst/playbook_guide/playbooks_debugger.rst:202
msgid "task_vars[*key*] = *value*"
msgstr "task_vars[*key*] = *value*"

#: ../../rst/playbook_guide/playbooks_debugger.rst:202
msgid "Update task variables (you must ``update_task`` next)"
msgstr "タスク変数を更新する (次回 ``update_task`` する必要があります)"

#: ../../rst/playbook_guide/playbooks_debugger.rst:204
msgid "update_task"
msgstr "update_task"

#: ../../rst/playbook_guide/playbooks_debugger.rst:204
msgid "u"
msgstr "u"

#: ../../rst/playbook_guide/playbooks_debugger.rst:204
msgid "Recreate a task with updated task variables"
msgstr "更新されたタスク変数でタスクを再作成する"

#: ../../rst/playbook_guide/playbooks_debugger.rst:206
msgid "redo"
msgstr "redo"

#: ../../rst/playbook_guide/playbooks_debugger.rst:206
msgid "r"
msgstr "r"

#: ../../rst/playbook_guide/playbooks_debugger.rst:206
msgid "Run the task again"
msgstr "タスクを再度実行する"

#: ../../rst/playbook_guide/playbooks_debugger.rst:208
msgid "continue"
msgstr "continue"

#: ../../rst/playbook_guide/playbooks_debugger.rst:208
msgid "c"
msgstr "c"

#: ../../rst/playbook_guide/playbooks_debugger.rst:208
msgid "Continue executing, starting with the next task"
msgstr "実行を継続する (次のタスクから開始)"

#: ../../rst/playbook_guide/playbooks_debugger.rst:210
msgid "quit"
msgstr "quit"

#: ../../rst/playbook_guide/playbooks_debugger.rst:210
msgid "q"
msgstr "q"

#: ../../rst/playbook_guide/playbooks_debugger.rst:210
msgid "Quit the debugger"
msgstr "デバッガーを終了する"

#: ../../rst/playbook_guide/playbooks_debugger.rst:214
msgid "For more details, see the individual descriptions and examples below."
msgstr "詳細は、以下の個別の説明および例を参照してください。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:219
msgid "Print command"
msgstr "コマンドを出力する"

#: ../../rst/playbook_guide/playbooks_debugger.rst:221
msgid "``print *task/task.args/task_vars/host/result*`` prints information about the task."
msgstr "``print *task/task.args/task_vars/host/result*`` は、タスクに関する情報を出力します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:248
msgid "Update args command"
msgstr "args コマンドを更新する"

#: ../../rst/playbook_guide/playbooks_debugger.rst:250
msgid "``task.args[*key*] = *value*`` updates a module argument. This sample playbook has an invalid package name."
msgstr "``task.args[*key*] = *value*`` モジュール引数を更新します。このサンプル Playbook には無効なパッケージ名があります。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:263
msgid "When you run the playbook, the invalid package name triggers an error, and Ansible invokes the debugger. You can fix the package name by viewing, then updating the module argument."
msgstr "Playbook を実行すると、パッケージ名が無効であるためにエラーが発生し、Ansible がデバッガーを起動します。パッケージ名を修正するには、モジュールの引数を表示してから更新します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:274
msgid "After you update the module argument, use ``redo`` to run the task again with the new args."
msgstr "モジュール引数を更新したら、``redo`` を使用して、新しい引数でタスクを再度実行します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:279
msgid "Update vars command"
msgstr "vars コマンドの更新"

#: ../../rst/playbook_guide/playbooks_debugger.rst:281
msgid "``task_vars[*key*] = *value*`` updates the ``task_vars``. You could fix the playbook above by viewing, then updating the task variables instead of the module args."
msgstr "``task_vars[*key*] = *value*`` は、``task_vars`` を更新します。モジュール引数ではなくタスク変数を表示してから更新して、上記の Playbook を修正できます。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:293
msgid "After you update the task variables, you must use ``update_task`` to load the new variables before using ``redo`` to run the task again."
msgstr "タスク変数を更新したら、``redo`` を使用してタスクを再実行する前に、``update_task`` を使用して新しい変数を読み込む必要があります。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:296
msgid "In 2.5 this was updated from ``vars`` to ``task_vars`` to avoid conflicts with the ``vars()`` python function."
msgstr "これは、python 関数 ``vars()`` と競合しないように、2.5 で ``vars`` から ``task_vars`` に更新されました。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:301
msgid "Update task command"
msgstr "task コマンドの更新"

#: ../../rst/playbook_guide/playbooks_debugger.rst:305
msgid "``u`` or ``update_task`` recreates the task from the original task data structure and templates with updated task variables. See the entry :ref:`update_vars_command` for an example of use."
msgstr "``u`` または ``update_task`` は、更新されたタスク変数を持つ元のタスクデータ構造とテンプレートからタスクを再作成します。使用例は、エントリー:ref:`update_vars_command` を参照してください。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:310
msgid "Redo command"
msgstr "コマンドのやり直し"

#: ../../rst/playbook_guide/playbooks_debugger.rst:312
msgid "``r`` or ``redo`` runs the task again."
msgstr "``r`` または ``redo`` はタスクを再実行します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:317
msgid "Continue command"
msgstr "コマンドの続行"

#: ../../rst/playbook_guide/playbooks_debugger.rst:319
msgid "``c`` or ``continue`` continues executing, starting with the next task."
msgstr "``c`` または ``continue`` は、次のタスクから開始して実行を継続します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:324
msgid "Quit command"
msgstr "Quit コマンド"

#: ../../rst/playbook_guide/playbooks_debugger.rst:326
msgid "``q`` or ``quit`` quits the debugger. The playbook execution is aborted."
msgstr "``q`` または ``quit`` はデバッガーを終了します。Playbook の実行は中止します。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:329
msgid "How the debugger interacts with the free strategy"
msgstr "デバッガーがフリーストラテジーとどのように相互作用するか"

#: ../../rst/playbook_guide/playbooks_debugger.rst:331
msgid "With the default ``linear`` strategy enabled, Ansible halts execution while the debugger is active, and runs the debugged task immediately after you enter the ``redo`` command. With the ``free`` strategy enabled, however, Ansible does not wait for all hosts, and may queue later tasks on one host before a task fails on another host. With the ``free`` strategy, Ansible does not queue or execute any tasks while the debugger is active. However, all queued tasks remain in the queue and run as soon as you exit the debugger. If you use ``redo`` to reschedule a task from the debugger, other queued tasks may execute before your rescheduled task. For more information about strategies, see :ref:`playbooks_strategies`."
msgstr "デフォルトの ``linear`` ストラテジーを有効にすると、Ansible はデバッガ―がアクティブな間は実行を停止し、``redo`` コマンドを入力した直後にデバッグされたタスクを実行します。しかし、``free`` ストラテジーを有効にすると、Ansible はすべてのホストを待たずに、別のホストでタスクが失敗する前に、あるホストで後のタスクをキューに入れることがあります。``free`` ストラテジーを使用すると、デバッガーがアクティブな間、Ansible は、タスクの照会や実行を行いません。ただし、キューに入れられたタスクはすべてキューに残り、デバッガーを終了するとすぐに実行されます。``redo`` を使用してデバッガーからタスクを再スケジュールすると、再スケジュールされたタスクの前にキューに入れられた他のタスクが実行する場合があります。ストラテジーの詳細については「:ref:`playbooks_strategies`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_debugger.rst:335
msgid ":ref:`playbooks_start_and_step`"
msgstr ":ref:`playbooks_start_and_step`"

#: ../../rst/playbook_guide/playbooks_debugger.rst:336
msgid "Running playbooks while debugging or testing"
msgstr "デバッグ時またはテスト時の Playbook の実行"

#: ../../rst/playbook_guide/playbooks_delegation.rst:4
msgid "Controlling where tasks run: delegation and local actions"
msgstr "タスクの実行場所の制御: 委譲およびローカルアクション"

#: ../../rst/playbook_guide/playbooks_delegation.rst:6
msgid "By default Ansible gathers facts and executes all tasks on the machines that match the ``hosts`` line of your playbook. This page shows you how to delegate tasks to a different machine or group, delegate facts to specific machines or groups, or run an entire playbook locally. Using these approaches, you can manage inter-related environments precisely and efficiently. For example, when updating your webservers, you might need to remove them from a load-balanced pool temporarily. You cannot perform this task on the webservers themselves. By delegating the task to localhost, you keep all the tasks within the same play."
msgstr "デフォルトでは、Ansible はファクトを収集し、Playbook の ``hosts`` 行に一致するマシン上ですべてのタスクを実行します。このページでは、タスクを別のマシンやグループに委譲したり、ファクトを特定のマシンやグループに委譲したり、Playbook 全体をローカルで実行する方法を紹介します。これらの方法を用いることで、相互に関連する環境を正確かつ効率的に管理することができます。たとえば、Web サーバーを更新する際に、負荷分散したプールから一時的に Web サーバーを削除しないといけない場合があります。このタスクは、Web サーバー自身では実行できません。このタスクを localhost に委譲することで、すべてのタスクを同じプレイに収めることができます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:12
msgid "Tasks that cannot be delegated"
msgstr "委譲できないタスク"

#: ../../rst/playbook_guide/playbooks_delegation.rst:14
msgid "Some tasks always execute on the controller. These tasks, including ``include``, ``add_host``, and ``debug``, cannot be delegated."
msgstr "一部のタスクは常にコントローラーで実行します。これらのタスクには、``include``、``add_host``、および ``debug`` を含むタスクを委譲できません。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:19
msgid "Delegating tasks"
msgstr "タスクの委譲"

#: ../../rst/playbook_guide/playbooks_delegation.rst:21
msgid "If you want to perform a task on one host with reference to other hosts, use the ``delegate_to`` keyword on a task. This is ideal for managing nodes in a load balanced pool or for controlling outage windows. You can use delegation with the :ref:`serial <rolling_update_batch_size>` keyword to control the number of hosts executing at one time:"
msgstr "あるホストで他のホストを参照しながらタスクを実行したい場合は、タスクに ``delegate_to`` キーワードを使用します。これは、負荷分散されたプールのノードを管理したり、障害発生時のウィンドウを制御するのに最適です。:ref:`serial <rolling_update_batch_size>` キーワードで委譲を使用すると、一度に実行するホストの数を制御することができます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:43
msgid "The first and third tasks in this play run on 127.0.0.1, which is the machine running Ansible. There is also a shorthand syntax that you can use on a per-task basis: ``local_action``. Here is the same playbook as above, but using the shorthand syntax for delegating to 127.0.0.1:"
msgstr "ここでは、1 番目と 3 番目のタスクを 127.0.0.1 で実行していますが、これは Ansible を実行しているマシンです。また、タスクごとに使用できる簡略化された構文があります (``local_action``)。以下は、上記と同じ Playbook ですが、127.0.0.1 に委譲するための短縮構文を使用します。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:59
msgid "You can use a local action to call 'rsync' to recursively copy files to the managed servers:"
msgstr "ローカルアクションを使用して「rsync」を呼び出し、管理対象のサーバーにファイルを再帰的にコピーすることができます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:70
msgid "Note that you must have passphrase-less SSH keys or an ssh-agent configured for this to work, otherwise rsync asks for a passphrase."
msgstr "これが機能するためには、パスフレーズなしの SSH 鍵または ssh-agent が設定されていなければならないことに注意してください。そうでなければ、rsync はパスフレーズを要求します。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:72
msgid "To specify more arguments, use the following syntax:"
msgstr "引数をさらに指定する必要がある場合は、以下の構文を使用できます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:89
msgid "The `ansible_host` variable and other connection variables, if present, reflects information about the host a task is delegated to, not the inventory_hostname."
msgstr "`ansible_host` 変数と他の接続変数がある場合は、inventory_hostname ではなく、タスクが委譲されるホストに関する情報を反映します。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:93
msgid "Although you can ``delegate_to`` a host that does not exist in inventory (by adding IP address, DNS name or whatever requirement the connection plugin has), doing so does not add the host to your inventory and might cause issues. Hosts delegated to in this way do not inherit variables from the \"all\" group', so variables like connection user and key are missing. If you must ``delegate_to`` a non-inventory host, use the :ref:`add host module <add_host_module>`."
msgstr "（IP アドレス、DNS 名、または接続プラグインの要件を追加することにより）インベントリーに存在しないホストを ``delegate_to`` にすることができますが、これを行うと、インベントリーにホストを追加せず、問題が発生する可能性があります。このように委譲されたホストは「すべて」グループから変数を継承しないため、接続ユーザーとキーなどの変数がありません。インベントリーホスト以外をのホストを ``delegate_to`` にする必要がある場合は、:ref:`add host module <add_host_module>` を使用します。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:99
msgid "Delegation and parallel execution"
msgstr "委譲と並列実行"

#: ../../rst/playbook_guide/playbooks_delegation.rst:100
msgid "By default Ansible tasks are executed in parallel. Delegating a task does not change this and does not handle concurrency issues (multiple forks writing to the same file). Most commonly, users are affected by this when updating a single file on a single delegated to host for all hosts (using the ``copy``, ``template``, or ``lineinfile`` modules, for example). They will still operate in parallel forks (default 5) and overwrite each other."
msgstr "デフォルトでは、Ansible タスクは並行して実行されます。タスクを委譲してもこれは変更されず、同時実行の問題（複数のフォークが同じファイルに書き込む）は処理されません。最も一般的には、すべてのホストのホストに委任された単一のファイルを更新するときに、ユーザーはこれの影響を受けます（``copy``、``template``、 または``lineinfile`` モジュールなど）。それらは引き続き並列フォーク（デフォルトは 5）で動作し、相互に上書きします。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:103
msgid "This can be handled in several ways:"
msgstr "これは複数の方法で処理できます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:112
msgid "By using an intermediate play with  `serial: 1` or using  `throttle: 1` at task level, for more detail see :ref:`playbooks_strategies`"
msgstr "`serial: 1` で中間プレイを使用するか、タスクレベルで `throttle: 1` を使用します。詳細は、:ref:`playbooks_strategies`を参照してください。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:117
msgid "Delegating facts"
msgstr "ファクトの委譲"

#: ../../rst/playbook_guide/playbooks_delegation.rst:119
msgid "Delegating Ansible tasks is like delegating tasks in the real world - your groceries belong to you, even if someone else delivers them to your home. Similarly, any facts gathered by a delegated task are assigned by default to the `inventory_hostname` (the current host), not to the host which produced the facts (the delegated to host). To assign gathered facts to the delegated host instead of the current host, set ``delegate_facts`` to ``true``:"
msgstr "Ansible のタスクを委譲することは、現実世界でタスクを委譲することと同じです。たとえ他の誰かがあなたの家に食料品を届けたとしても、あなたの食料品はあなたのものです。同様に、委譲されたタスクによって収集されたファクトは、デフォルトでは、ファクトを生成したホスト (委譲されたホスト) ではなく、`inventory_hostname` (現在のホスト) に割り当てられます。集めたファクトを現在のホストではなく委譲されたホストに割り当てるには、``delegate_facts`` を ``true`` に設定します。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:133
msgid "This task gathers facts for the machines in the dbservers group and assigns the facts to those machines, even though the play targets the app_servers group. This way you can lookup `hostvars['dbhost1']['ansible_default_ipv4']['address']` even though dbservers were not part of the play, or left out by using `--limit`."
msgstr "このタスクは、プレイが app_servers グループを対象としているにもかかわらず、dbservers グループのマシンのファクトを収集し、それらのマシンにファクトを割り当てます。このようにして、たとえ dbservers がプレイの一部でなくても、あるいは `--limit` を使用して除外されていても、`hostvars['dbhost1']['ansible_default_ipv4']['address']` を調べることができます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:138
msgid "Local playbooks"
msgstr "ローカルの Playbook"

#: ../../rst/playbook_guide/playbooks_delegation.rst:140
msgid "It may be useful to use a playbook locally on a remote host, rather than by connecting over SSH.  This can be useful for assuring the configuration of a system by putting a playbook in a crontab.  This may also be used to run a playbook inside an OS installer, such as an Anaconda kickstart."
msgstr "SSH で接続するのではなく、リモートホスト上でローカルに Playbook を使用することが便利な場合があります。これは、crontab に Playbook を置くことで、システムの構成を保証するのに役立ちます。また、Anaconda のキックスタートなど、OS インストーラー内で Playbook を実行する場合にも使用できます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:143
msgid "To run an entire playbook locally, just set the ``hosts:`` line to ``hosts: 127.0.0.1`` and then run the playbook like so:"
msgstr "Playbook 全体をローカルで実行するには、``hosts:`` 行を ``hosts: 127.0.0.1`` に設定し、次のように Playbook を実行します。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:149
msgid "Alternatively, a local connection can be used in a single playbook play, even if other plays in the playbook use the default remote connection type:"
msgstr "また、Playbook 内の他のプレイがデフォルトのリモート接続タイプを使用していても、1 つの Playbook のプレイでローカル接続を使用することもできます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:159
msgid "If you set the connection to local and there is no ansible_python_interpreter set, modules will run under /usr/bin/python and not under {{ ansible_playbook_python }}. Be sure to set ansible_python_interpreter: \"{{ ansible_playbook_python }}\" in host_vars/localhost.yml, for example. You can avoid this issue by using ``local_action`` or ``delegate_to: localhost`` instead."
msgstr "接続先をローカルに設定し、ansible_python_interpreter が設定されていないと、モジュールは、{{ ansible_playbook_python }} ではなく /usr/bin/python で実行します。ansible_python_interpreter を必ず設定してください (host_vars/localhost.yml の「{{ ansible_playbook_python }}」など)。代わりに ``local_action`` または ``delegate_to: localhost`` を使用することで、この問題を回避できます。"

#: ../../rst/playbook_guide/playbooks_delegation.rst:168
msgid "More ways to control how and where Ansible executes"
msgstr "Ansible の実行方法および場所を制御する方法"

#: ../../rst/playbook_guide/playbooks_delegation.rst:169
msgid "`Ansible Examples on GitHub <https://github.com/ansible/ansible-examples>`_"
msgstr "`Ansible Examples on GitHub <https://github.com/ansible/ansible-examples>`_"

#: ../../rst/playbook_guide/playbooks_delegation.rst:170
msgid "Many examples of full-stack deployments"
msgstr "フルスタックデプロイメントの例が多数あります。"

#: ../../rst/playbook_guide/playbooks_environment.rst:4
msgid "Setting the remote environment"
msgstr "リモート環境の設定"

#: ../../rst/playbook_guide/playbooks_environment.rst:8
msgid "You can use the ``environment`` keyword at the play, block, or task level to set an environment variable for an action on a remote host. With this keyword, you can enable using a proxy for a task that does http requests, set the required environment variables for language-specific version managers, and more."
msgstr "プレイ、ブロック、またはタスクのレベルで ``environment`` キーワードを使用して、リモートホスト上のアクションに環境変数を設定することができます。このキーワードを使用すると、http リクエストを行うタスクでプロキシーの使用を有効にしたり、言語固有のバージョンマネージャーに必要な環境変数を設定したりすることができます。"

#: ../../rst/playbook_guide/playbooks_environment.rst:10
msgid "When you set a value with ``environment:`` at the play or block level, it is available only to tasks within the play or block that are executed by the same user. The ``environment:`` keyword does not affect Ansible itself, Ansible configuration settings, the environment for other users, or the execution of other plugins like lookups and filters. Variables set with ``environment:`` do not automatically become Ansible facts, even when you set them at the play level. You must include an explicit ``gather_facts`` task in your playbook and set the ``environment`` keyword on that task to turn these values into Ansible facts."
msgstr "プレイまたはブロックレベルで ``environment:`` を使用して値を設定すると、同じユーザーによって実行されるプレイまたはブロック内のタスクでのみ使用できます。``environment:`` キーワードは、Ansible 自体、Ansible の構成設定、他のユーザーの環境、ルックアップやフィルターなどの他のプラグインの実行には影響しません。``environment:`` で設定した変数は、プレイレベルで設定しても、自動的に Ansible のファクトにはなりません。これらの値を Ansible のファクトにするには、Playbook に明示的な ``gather_facts`` タスクを含め、そのタスクに ``environment`` キーワードを設定する必要があります。"

#: ../../rst/playbook_guide/playbooks_environment.rst:16
msgid "Setting the remote environment in a task"
msgstr "タスクへのリモート環境の設定"

#: ../../rst/playbook_guide/playbooks_environment.rst:18
msgid "You can set the environment directly at the task level."
msgstr "タスクレベルで環境を直接指定することもできます。"

#: ../../rst/playbook_guide/playbooks_environment.rst:34
msgid "You can re-use environment settings by defining them as variables in your play and accessing them in a task as you would access any stored Ansible variable."
msgstr "環境変数をプレイの変数として定義し、保存した Ansible 変数にアクセスするときにタスクからアクセスできることで、環境変数を再利用できます。"

#: ../../rst/playbook_guide/playbooks_environment.rst:54
msgid "You can store environment settings for re-use in multiple playbooks by defining them in a group_vars file."
msgstr "複数の Playbook に再使用する環境設定は、group_vars ファイルに定義することで保存できます。"

#: ../../rst/playbook_guide/playbooks_environment.rst:67
msgid "You can set the remote environment at the play level."
msgstr "プレイレベルでリモート環境を設定できます。"

#: ../../rst/playbook_guide/playbooks_environment.rst:80
msgid "These examples show proxy settings, but you can provide any number of settings this way."
msgstr "これらの例ではプロキシー設定を示していますが、この設定をいくつでも提供できます。"

#: ../../rst/playbook_guide/playbooks_environment.rst:83
msgid "Working with language-specific version managers"
msgstr "言語固有のバージョンマネージャーの使用"

#: ../../rst/playbook_guide/playbooks_environment.rst:85
msgid "Some language-specific version managers (such as rbenv and nvm) require you to set environment variables while these tools are in use. When using these tools manually, you usually source some environment variables from a script or from lines added to your shell configuration file. In Ansible, you can do this with the environment keyword at the play level."
msgstr "言語固有のバージョンマネージャー (rbenv や nvmなど) の中には、これらのツールを使用する際に環境変数を設定する必要があります。これらのツールを手動で使用する場合、通常はスクリプトやシェル構成ファイルに追加した行から環境変数を設定します。Ansible では、プレイレベルで環境キーワードを使用してこれを行うことができます。"

#: ../../rst/playbook_guide/playbooks_environment.rst:124
msgid "The example above uses ``ansible_env`` as part of the PATH. Basing variables on ``ansible_env`` is risky. Ansible populates ``ansible_env`` values by gathering facts, so the value of the variables depends on the remote_user or become_user Ansible used when gathering those facts. If you change remote_user/become_user the values in ``ansible_env`` may not be the ones you expect."
msgstr "上の例では、``ansible_env`` を PATH の一部として使用しています。変数を ``ansible_env`` に基づかせるのはリスクがあります。Ansible はファクトを収集して ``ansible_env`` の値を生成するため、変数の値はファクトの収集時に Ansible が使用した remote_user や become_user に依存します。remote_user/become_user を変更した場合、``ansible_env`` の値は期待したものとは異なる可能性があります。"

#: ../../rst/playbook_guide/playbooks_environment.rst:127
msgid "Environment variables are normally passed in clear text (shell plugin dependent) so they are not a recommended way of passing secrets to the module being executed."
msgstr "環境変数は、通常、(シェルプラグインに依存する) クリアテキストに渡されます。したがって、実行するモジュールにシークレットを渡す方法は推奨されません。"

#: ../../rst/playbook_guide/playbooks_environment.rst:129
msgid "You can also specify the environment at the task level."
msgstr "タスクレベルで環境を指定することもできます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:5
msgid "Error handling in playbooks"
msgstr "Playbook でのエラー処理"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:7
msgid "When Ansible receives a non-zero return code from a command or a failure from a module, by default it stops executing on that host and continues on other hosts. However, in some circumstances you may want different behavior. Sometimes a non-zero return code indicates success. Sometimes you want a failure on one host to stop execution on all hosts. Ansible provides tools and settings to handle these situations and help you get the behavior, output, and reporting you want."
msgstr "Ansible は、コマンドからゼロ以外の戻りコードを受け取った場合や、モジュールから失敗を受け取った場合、デフォルトでは、そのホストでの実行を停止し、他のホストで継続します。しかし、状況によっては異なる動作をさせたい場合があります。ゼロ以外の戻りコードが成功を示す場合もあります。あるホストで失敗したら、すべてのホストで実行を停止させたい場合もあります。Ansible には、このような状況に対応するためのツールや設定が用意されており、必要な動作、出力、レポートを得ることができます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:15
msgid "Ignoring failed commands"
msgstr "失敗したコマンドの無視"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:17
msgid "By default Ansible stops executing tasks on a host when a task fails on that host. You can use ``ignore_errors`` to continue on in spite of the failure."
msgstr "デフォルトでは、Ansible は、ホストでタスクが失敗すると、ホストでタスクの実行を停止します。``ignore_errors`` を使用すると、障害が発生しても続行されます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:25
msgid "The ``ignore_errors`` directive only works when the task is able to run and returns a value of 'failed'. It does not make Ansible ignore undefined variable errors, connection failures, execution issues (for example, missing packages), or syntax errors."
msgstr "``ignore_errors`` ディレクティブは、タスクが実行可能で、「failed」という値を返す場合にのみ機能します。未定義の変数のエラー、接続の失敗、実行時の問題 (パッケージの欠落など)、構文エラーなどを Ansible に無視させるものではありません。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:30
msgid "Ignoring unreachable host errors"
msgstr "到達不能なホストエラーを無視"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:34
msgid "You can ignore a task failure due to the host instance being 'UNREACHABLE' with the ``ignore_unreachable`` keyword. Ansible ignores the task errors, but continues to execute future tasks against the unreachable host. For example, at the task level:"
msgstr "``ignore_unreachable`` キーワードで、ホストインスタンスが「UNREACHABLE」であることによるタスクの失敗を無視することができます。Ansible はタスクのエラーを無視しますが、到達不可能なホストに対して今後のタスクを実行し続けます。たとえば、タスクレベルでは以下のようになります。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:45
msgid "And at the playbook level:"
msgstr "また、Playbook レベルでは以下を行います。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:62
msgid "Resetting unreachable hosts"
msgstr "到達できないホストのリセット"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:64
msgid "If Ansible cannot connect to a host, it marks that host as 'UNREACHABLE' and removes it from the list of active hosts for the run. You can use `meta: clear_host_errors` to reactivate all hosts, so subsequent tasks can try to reach them again."
msgstr "Ansible はホストに接続できない場合、そのホストを「UNREACHABLE」とマークし、実行時にアクティブなホストのリストから削除します。`meta: clear_host_errors` を使用してすべてのホストを再有効化することで、後続のタスクが再びホストに到達しようとすることができます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:70
msgid "Handlers and failure"
msgstr "ハンドラーおよび失敗"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:72
msgid "Ansible runs :ref:`handlers <handlers>` at the end of each play. If a task notifies a handler but another task fails later in the play, by default the handler does *not* run on that host, which may leave the host in an unexpected state. For example, a task could update a configuration file and notify a handler to restart some service. If a task later in the same play fails, the configuration file might be changed but the service will not be restarted."
msgstr "Ansible は、各プレイの最後に :ref:`handlers <handlers>` を実行します。タスクがハンドラーに通知しても、プレイの後半で別のタスクが失敗すると、デフォルトではハンドラーはそのホスト上で **実行されず**、ホストが予期せぬ状態になる可能性があります。たとえば、タスクが設定ファイルを更新し、ハンドラーにサービスの再起動を通知したとします。同じプレイの後半でタスクが失敗した場合、設定ファイルは変更するかもしれませんが、サービスは再起動しません。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:79
msgid "You can change this behavior with the ``--force-handlers`` command-line option, by including ``force_handlers: True`` in a play, or by adding ``force_handlers = True`` to ansible.cfg. When handlers are forced, Ansible will run all notified handlers on all hosts, even hosts with failed tasks. (Note that certain errors could still prevent the handler from running, such as a host becoming unreachable.)"
msgstr "この動作は、``force_handlers: True`` をプレイに含めるか、``force_handlers = True`` を ansible.cfg に追加して、``--force-handlers`` コマンドラインオプションで変更できます。ハンドラーが強制的に実行すると、Ansible は通知されたすべてのハンドラーを、タスクが失敗したホストも含めてすべてのホストで実行します (ホストが到達不能になるなど、特定のエラーによってハンドラーの実行が妨げられる可能性があることに注意してください)。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:88
msgid "Defining failure"
msgstr "障害の定義"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:90
msgid "Ansible lets you define what \"failure\" means in each task using the ``failed_when`` conditional. As with all conditionals in Ansible, lists of multiple ``failed_when`` conditions are joined with an implicit ``and``, meaning the task only fails when *all* conditions are met. If you want to trigger a failure when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator."
msgstr "Ansible では、``failed_when`` 条件分岐を使用して、各タスクで「失敗」の意味を定義することができます。Ansible のすべての条件分岐と同様に、複数の ``failed_when`` 条件のリストは暗黙の ``and`` で結合されており、これは *すべての* 条件が満たされたときにのみタスクが失敗することを意味します。いずれかの条件が満たされたときに失敗をトリガーしたい場合は、明示的な ``or`` 演算子を使用して文字列で条件を定義する必要があります。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:92
msgid "You may check for failure by searching for a word or phrase in the output of a command"
msgstr "コマンドの出力で単語またはフレーズを検索して、障害の有無を確認できます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:101
msgid "or based on the return code"
msgstr "または、戻りコードに基いて確認できます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:110
msgid "You can also combine multiple conditions for failure. This task will fail if both conditions are true:"
msgstr "複数の条件を組み合わせて失敗させることもできます。このタスクは、両方の条件が真であれば失敗します。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:121
msgid "If you want the task to fail when only one condition is satisfied, change the ``failed_when`` definition to"
msgstr "条件が満たされたときにのみタスクが失敗する場合は、``failed_when`` 定義を以下のように変更します。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:127
msgid "If you have too many conditions to fit neatly into one line, you can split it into a multi-line YAML value with ``>``."
msgstr "条件が多すぎて 1 行にうまく収まらない場合は、``>`` を使用して、これを複数行の YAML 値に分割できます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:142
msgid "Defining \"changed\""
msgstr "「変更済み」の定義"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:144
msgid "Ansible lets you define when a particular task has \"changed\" a remote node using the ``changed_when`` conditional. This lets you determine, based on return codes or output, whether a change should be reported in Ansible statistics and whether a handler should be triggered or not. As with all conditionals in Ansible, lists of multiple ``changed_when`` conditions are joined with an implicit ``and``, meaning the task only reports a change when *all* conditions are met. If you want to report a change when any of the conditions is met, you must define the conditions in a string with an explicit ``or`` operator. For example:"
msgstr "Ansible では、``changed_when`` 条件式を使用して、特定のタスクがリモートノードを「変更」したときを定義することができます。これにより、戻りコードや出力に基づいて、変更を Ansible の統計で報告するかどうか、ハンドラーをトリガーするかどうかを決定することができます。Ansible のすべての条件式と同様に、複数の ``changed_when`` 条件のリストは暗黙の ``and`` で結合されており、タスクは *すべての* 条件が満たされたときにのみ変更を報告することを意味します。いずれかの条件が満たされたときに変更を報告したい場合は、明示的な ``or`` 演算子を使用して文字列で条件を定義する必要があります。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:159
msgid "You can also combine multiple conditions to override \"changed\" result."
msgstr "複数の条件を組み合わせて「変更」の結果を上書きすることもできます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:173
msgid "Just like ``when`` these two conditionals do not require templating delimiters (``{{ }}``) as they are implied."
msgstr "``when`` と同様に、これら 2 つの条件には、暗黙の了解として、テンプレート化の区切り文字(``{{ }}``)は必要ありません。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:175
msgid "See :ref:`controlling_what_defines_failure` for more conditional syntax examples."
msgstr "その他の条件付き構文例については、「:ref:`controlling_what_defines_failure`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:178
msgid "Ensuring success for command and shell"
msgstr "コマンドとシェルの成功の確認"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:180
msgid "The :ref:`command <command_module>` and :ref:`shell <shell_module>` modules care about return codes, so if you have a command whose successful exit code is not zero, you can do this:"
msgstr ":ref:`command <command_module>` モジュールおよび :ref:`shell <shell_module>` モジュールは戻りコードを処理するため、正常な終了コードがゼロではないコマンドがある場合は、以下を行うことができます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:190
msgid "Aborting a play on all hosts"
msgstr "すべてのホストでプレイを中止"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:192
msgid "Sometimes you want a failure on a single host, or failures on a certain percentage of hosts, to abort the entire play on all hosts. You can stop play execution after the first failure happens with ``any_errors_fatal``. For finer-grained control, you can use ``max_fail_percentage`` to abort the run after a given percentage of hosts has failed."
msgstr "時には、1 つのホストでの失敗や、ある割合のホストでの失敗により、すべてのホストでのプレイ全体を中止させたいことがあります。``any_errors_fatal`` を使用すると、最初の失敗が発生した後にプレイの実行を停止することができます。より細かく制御するには、``max_fail_percentage`` を使用して、特定の割合のホストで失敗した後に実行を中止することができます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:195
msgid "Aborting on the first error: any_errors_fatal"
msgstr "最初のエラーで強制終了: any_errors_fatal"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:197
msgid "If you set ``any_errors_fatal`` and a task returns an error, Ansible finishes the fatal task on all hosts in the current batch, then stops executing the play on all hosts. Subsequent tasks and plays are not executed. You can recover from fatal errors by adding a :ref:`rescue section <block_error_handling>` to the block. You can set ``any_errors_fatal`` at the play or block level."
msgstr "``any_errors_fatal`` を設定し、タスクがエラーを返した場合、Ansible は現在のバッチ内のすべてのホストで致命的なタスクを終了し、すべてのホストでプレイの実行を停止します。後続のタスクやプレイは実行されません。致命的なエラーから回復するには、ブロックに :ref:`rescue section <block_error_handling>` を追加します。``any_errors_fatal`` は、プレイまたはブロックレベルで設定できます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:212
#, python-format
msgid "You can use this feature when all tasks must be 100% successful to continue playbook execution. For example, if you run a service on machines in multiple data centers with load balancers to pass traffic from users to the service, you want all load balancers to be disabled before you stop the service for maintenance. To ensure that any failure in the task that disables the load balancers will stop all other tasks:"
msgstr "この機能は、Playbook の実行を継続するために、すべてのタスクが 100％ 成功する必要がある場合に使用できます。たとえば、複数のデータセンターにあるマシンでサービスを実行し、ユーザーからのトラフィックをサービスに渡すためにロードバランサーを使用している場合は、メンテナンスのためにサービスを停止する前に、すべてのロードバランサーを無効にします。ロードバランサーを無効にするタスクに障害が発生しても、他のすべてのタスクを停止させるには、次のようにします。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:239
msgid "In this example Ansible starts the software upgrade on the front ends only if all of the load balancers are successfully disabled."
msgstr "この例では、すべてのロードバランサーが正常に無効になっている場合にのみ、Ansible が、フロントエンドでソフトウェアのアップグレードを開始します。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:244
msgid "Setting a maximum failure percentage"
msgstr "最大失敗率の設定"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:246
msgid "By default, Ansible continues to execute tasks as long as there are hosts that have not yet failed. In some situations, such as when executing a rolling update, you may want to abort the play when a certain threshold of failures has been reached. To achieve this, you can set a maximum failure percentage on a play:"
msgstr "デフォルトでは、Ansible はまだ失敗していないホストがある限り、タスクを実行し続けます。ローリングアップデートを実行する場合など、ある一定の失敗率に達したときにプレイを中断したい場合があります。これを可能にするには、プレイの最大失敗率を設定することができます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:255
msgid "The ``max_fail_percentage`` setting applies to each batch when you use it with :ref:`serial <rolling_update_batch_size>`. In the example above, if more than 3 of the 10 servers in the first (or any) batch of servers failed, the rest of the play would be aborted."
msgstr "``max_fail_percentage`` の設定は、:ref:`serial <rolling_update_batch_size>` と一緒に使用すると、各バッチに適用されます。上の例では、最初の (あるいは任意の) バッチに含まれる 10 台のサーバーのうち 3 台以上が故障した場合、残りのプレイは中止されます。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:259
msgid "The percentage set must be exceeded, not equaled. For example, if serial were set to 4 and you wanted the task to abort the play when 2 of the systems failed, set the max_fail_percentage at 49 rather than 50."
msgstr "設定されたパーセンテージは、同等ではなく、超えなければなりません。たとえば、serialが 4 に設定されていて、2 つのシステムが故障したときにプレイを中止するタスクにしたい場合は、max_fail_percentage を 50 ではなく 49 に設定します。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:262
msgid "Controlling errors in blocks"
msgstr "ブロックのエラーを制御"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:264
msgid "You can also use blocks to define responses to task errors. This approach is similar to exception handling in many programming languages. See :ref:`block_error_handling` for details and examples."
msgstr "ブロックを使用してタスクエラーへの応答を定義することもできます。この方法は、多くのプログラミング言語での例外処理に似ています。詳細と例は、「:ref:`block_error_handling`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:272
#: ../../rst/playbook_guide/playbooks_filters.rst:2186
#: ../../rst/playbook_guide/playbooks_lookups.rst:30
#: ../../rst/playbook_guide/playbooks_loops.rst:492
#: ../../rst/playbook_guide/playbooks_prompts.rst:117
#: ../../rst/playbook_guide/playbooks_reuse.rst:215
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:600
#: ../../rst/playbook_guide/playbooks_tests.rst:529
#: ../../rst/playbook_guide/playbooks_variables.rst:517
msgid ":ref:`playbooks_conditionals`"
msgstr ":ref:`playbooks_conditionals`"

#: ../../rst/playbook_guide/playbooks_error_handling.rst:273
#: ../../rst/playbook_guide/playbooks_filters.rst:2187
#: ../../rst/playbook_guide/playbooks_lookups.rst:31
#: ../../rst/playbook_guide/playbooks_loops.rst:493
#: ../../rst/playbook_guide/playbooks_prompts.rst:118
#: ../../rst/playbook_guide/playbooks_tests.rst:530
#: ../../rst/playbook_guide/playbooks_variables.rst:518
msgid "Conditional statements in playbooks"
msgstr "Playbook の条件分岐文"

#: ../../rst/playbook_guide/playbooks_execution.rst:4
msgid "Executing playbooks"
msgstr "Playbook の実行"

#: ../../rst/playbook_guide/playbooks_execution.rst:6
msgid "Ready to run your Ansible playbook?"
msgstr "Ansible Playbook を実行する準備はできましたか?"

#: ../../rst/playbook_guide/playbooks_execution.rst:8
msgid "Running complex playbooks requires some trial and error so learn about some of the abilities that Ansible gives you to ensure successful execution. You can validate your tasks with \"dry run\" playbooks, use the start-at-task and step mode options to efficiently troubleshoot playbooks. You can also use Ansible debugger to correct tasks during execution. Ansible also offers flexibility with asynchronous playbook execution and tags that let you run specific parts of your playbook."
msgstr "複雑な Playbook を実行するには試行錯誤が必要なので、実行を成功させるために Ansible が提供するいくつかの機能を確認してみてください。\"dry run\" Playbook でタスクを検証し、start-at-task および step モードオプションを使用して Playbook を効率的にトラブルシューティングできます。Ansible デバッガーを使用して、実行中にタスクを修正することもできます。Ansible は、Playbook の特定の部分を実行できる非同期 Playbook 実行やタグによる柔軟性も提供します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:5
msgid "Using filters to manipulate data"
msgstr "フィルターを使用したデータの操作"

#: ../../rst/playbook_guide/playbooks_filters.rst:7
msgid "Filters let you transform JSON data into YAML data, split a URL to extract the hostname, get the SHA1 hash of a string, add or multiply integers, and much more. You can use the Ansible-specific filters documented here to manipulate your data, or use any of the standard filters shipped with Jinja2 - see the list of :ref:`built-in filters <jinja2:builtin-filters>` in the official Jinja2 template documentation. You can also use :ref:`Python methods <jinja2:python-methods>` to transform data. You can :ref:`create custom Ansible filters as plugins <developing_filter_plugins>`, though we generally welcome new filters into the ansible-core repo so everyone can use them."
msgstr "フィルターを使用すると、JSON データを YAML データに変換したり、URL を分割してホスト名を抽出したり、文字列の SHA1 ハッシュを取得したり、整数を加算または乗算したりなど、さまざまなことができます。ここで紹介している Ansible 固有のフィルターを使用してデータを操作することもできますし、Jinja2 に同梱されている標準的なフィルターを使用することもできます。Jinja2 の公式テンプレートドキュメントの :ref:`組み込みフィルター <jinja2:builtin-filters>` のリストを参照してださい。また、:ref:`Python メソッド <jinja2:python-methods>` を使用してデータを変換することもできます。:ref:`カスタム Ansible フィルターをプラグインとして作成 <developing_filter_plugins>` することもできますが、通常は、誰もが使用できるように新しいフィルターを ansible-core リポジトリーに追加することが歓迎されています。"

#: ../../rst/playbook_guide/playbooks_filters.rst:9
msgid "Because templating happens on the Ansible controller, **not** on the target host, filters execute on the controller and transform data locally."
msgstr "テンプレート化はターゲットホスト上 **ではなく**、Ansible コントローラー上で行われるため、フィルターはコントローラ上で実行し、データはローカルに変換されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:15
msgid "Handling undefined variables"
msgstr "未定義変数の処理"

#: ../../rst/playbook_guide/playbooks_filters.rst:17
msgid "Filters can help you manage missing or undefined variables by providing defaults or making some variables optional. If you configure Ansible to ignore most undefined variables, you can mark some variables as requiring values with the ``mandatory`` filter."
msgstr "フィルターは、デフォルトを指定したり、一部の変数を任意にしたりすることで、欠落している変数や未定義の変数を管理するのに役立ちます。ほとんどの未定義の変数を無視するように Ansibl eを設定した場合は、``mandatory`` フィルターを使用して、いくつかの変数を必要な値としてマークすることができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:22
msgid "Providing default values"
msgstr "デフォルト値の指定"

#: ../../rst/playbook_guide/playbooks_filters.rst:24
msgid "You can provide default values for variables directly in your templates using the Jinja2 'default' filter. This is often a better approach than failing if a variable is not defined:"
msgstr "Jinja2 の「default」フィルターを使用すれば、テンプレートの中で直接、変数のデフォルト値を指定することができます。変数が定義されていない場合に失敗するよりも優れたアプローチであることがよくあります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:30
msgid "In the above example, if the variable 'some_variable' is not defined, Ansible uses the default value 5, rather than raising an \"undefined variable\" error and failing. If you are working within a role, you can also add a ``defaults/main.yml`` to define the default values for variables in your role."
msgstr "上記の例では、変数「some_variable」が定義されていない場合、Ansible は「undefined variable」エラーを発生させて失敗するのではなく、デフォルト値 5 を使用します。ロール内で作業している場合は、``defaults/main.yml`` を追加して、ロール内の変数のデフォルト値を定義することもできます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:32
msgid "Beginning in version 2.8, attempting to access an attribute of an Undefined value in Jinja will return another Undefined value, rather than throwing an error immediately. This means that you can now simply use a default with a value in a nested data structure (in other words, :code:`{{ foo.bar.baz | default('DEFAULT') }}`) when you do not know if the intermediate values are defined."
msgstr "バージョン 2.8 から、Jinja で Undefined の値の属性にアクセスしようとすると、すぐにエラーが発生するのではなく、別の Undefined の値が返されます。これにより、中間値が定義されているかどうかわからない場合に、ネストされたデータ構造の中の値でデフォルトを簡単に使用することができるようになりました (つまり :code:`{{ foo.bar.baz | default('DEFAULT') }}`)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:35
msgid "If you want to use the default value when variables evaluate to false or an empty string you have to set the second parameter to ``true``:"
msgstr "変数が false または空の文字列に評価されるときにデフォルト値を使用する場合は、2 番目のパラメーターを ``true`` に設定する必要があります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:44
msgid "Making variables optional"
msgstr "変数の任意設定"

#: ../../rst/playbook_guide/playbooks_filters.rst:46
msgid "By default Ansible requires values for all variables in a templated expression. However, you can make specific variables optional. For example, you might want to use a system default for some items and control the value for others. To make a variable optional, set the default value to the special variable ``omit``:"
msgstr "デフォルトでは、Ansible はテンプレート式のすべての変数に値を要求します。しかし、特定の変数を任意にすることができます。たとえば、一部の項目ではシステムのデフォルト値を使用し、他の項目では値を制御することができます。変数を任意にするには、特殊変数 ``omit`` にデフォルト値を設定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:61
msgid "In this example, the default mode for the files ``/tmp/foo`` and ``/tmp/bar`` is determined by the umask of the system. Ansible does not send a value for ``mode``. Only the third file, ``/tmp/baz``, receives the `mode=0444` option."
msgstr "この例では、``/tmp/foo`` ファイルおよび ``/tmp/bar`` ファイルのデフォルトモードはシステムの umask により決定されます。Ansible は ``mode`` の値を送信しません。3 番目のファイルである ``/tmp/baz`` だけが `mode=0444` オプションを受け取ります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:63
msgid "If you are \"chaining\" additional filters after the ``default(omit)`` filter, you should instead do something like this: ``\"{{ foo | default(None) | some_filter or omit }}\"``. In this example, the default ``None`` (Python null) value will cause the later filters to fail, which will trigger the ``or omit`` portion of the logic. Using ``omit`` in this manner is very specific to the later filters you are chaining though, so be prepared for some trial and error if you do this."
msgstr "``default(omit)`` フィルターの後に追加のフィルターを「連鎖」させる場合は、代わりに ``\"{{ foo | default(None) | some_filter or omit }}\"`` のようにしてください。この例では、デフォルトの ``None`` (Python null) の値により、後続のフィルターが失敗し、ロジックの ``or omit`` 部分が誘発されます。``omit`` をこのように使用することは、連鎖させる後続のフィルターに非常に依存するため、試行錯誤が必要になります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:69
msgid "Defining mandatory values"
msgstr "必須値の定義"

#: ../../rst/playbook_guide/playbooks_filters.rst:71
msgid "If you configure Ansible to ignore undefined variables, you may want to define some values as mandatory. By default, Ansible fails if a variable in your playbook or command is undefined. You can configure Ansible to allow undefined variables by setting :ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` to ``false``. In that case, you may want to require some variables to be defined. You can do this with:"
msgstr "未定義の変数を無視するように Ansible を設定する場合は、一部の値を必須として定義したい場合があります。デフォルトでは、Playbook またはコマンドの変数が未定義の場合、Ansible は失敗します。:ref:`DEFAULT_UNDEFINED_VAR_BEHAVIOR` を ``false`` に設定することで、未定義の変数を許可するように Ansible を設定することができます。その場合は、一部の変数の定義を必須にしたい場合があります。これには次の方法があります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:77
msgid "The variable value will be used as is, but the template evaluation will raise an error if it is undefined."
msgstr "変数の値はそのまま使用されますが、定義されていない場合は、テンプレートの評価でエラーが発生します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:79
msgid "A convenient way of requiring a variable to be overridden is to give it an undefined value using the ``undef`` keyword. This can be useful in a role's defaults."
msgstr "変数の上書きを要求する便利な方法は、``undef`` キーワードを使用して未定義値を提供することです。これは、ロールのデフォルトで役に立ちます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:87
msgid "Defining different values for true/false/null (ternary)"
msgstr "true/false/null (三項) に異なる値を定義する"

#: ../../rst/playbook_guide/playbooks_filters.rst:89
msgid "You can create a test, then define one value to use when the test returns true and another when the test returns false (new in version 1.9):"
msgstr "テストを作成し、そのテストが true を返したときに使用する値と、false を返したときに使用する値を定義することができます (バージョン 1.9 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:95
msgid "In addition, you can define a one value to use on true, one value on false and a third value on null (new in version 2.8):"
msgstr "さらに、true に使用する値を 1 つ定義し、false で 1 つの値、null で 3 番目の値を定義できます (バージョン 2.8 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:102
msgid "Managing data types"
msgstr "データ型の管理"

#: ../../rst/playbook_guide/playbooks_filters.rst:104
msgid "You might need to know, change, or set the data type on a variable. For example, a registered variable might contain a dictionary when your next task needs a list, or a user :ref:`prompt <playbooks_prompts>` might return a string when your playbook needs a boolean value. Use the ``type_debug``, ``dict2items``, and ``items2dict`` filters to manage data types. You can also use the data type itself to cast a value as a specific data type."
msgstr "変数のデータ型の確認、変更、または設定を行う必要がある場合があります。たとえば、次のタスクでリストが必要なときに、登録済みの変数にディクショナリーが含まれていたり、Playbook でブール値が必要なときに、ユーザーの :ref:`prompt <playbooks_prompts>` が文字列を返したりすることがあります。データタイプの管理には、``type_debug``、``dict2items``、および ``items2dict`` の各フィルターを使用します。また、データ型自体を使用して、値を特定のデータ型としてキャストすることもできます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:107
msgid "Discovering the data type"
msgstr "データ型の検出"

#: ../../rst/playbook_guide/playbooks_filters.rst:111
msgid "If you are unsure of the underlying Python type of a variable, you can use the ``type_debug`` filter to display it. This is useful in debugging when you need a particular type of variable:"
msgstr "変数の基礎となる Python の型がわからない場合は、``type_debug`` フィルターを使用して表示することができます。これはデバッグ時に特定の型の変数が必要になったときに便利です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:117
msgid "You should note that, while this may seem like a useful filter for checking that you have the right type of data in a variable, you should often prefer :ref:`type tests <type_tests>`, which will allow you to test for specific data types."
msgstr "このフィルターは、変数のデータ型が正しいかどうかをチェックするのに便利なように思えますが、特定のデータ型をテストできる:ref:`type tests <type_tests>`の方が良い場合が多いことに注意してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:122
msgid "Transforming dictionaries into lists"
msgstr "ディクショナリーのリストへの変換"

#: ../../rst/playbook_guide/playbooks_filters.rst:127
msgid "Use the ``dict2items`` filter to transform a dictionary into a list of items suitable for :ref:`looping <playbooks_loops>`:"
msgstr "``dict2items`` フィルターを使用して、ディクショナリーを :ref:`looping <playbooks_loops>` に適した項目のリストに変換します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:133
#: ../../rst/playbook_guide/playbooks_filters.rst:160
msgid "Dictionary data (before applying the ``dict2items`` filter):"
msgstr "ディクショナリーデータ (``dict2items`` フィルターを適用する前):"

#: ../../rst/playbook_guide/playbooks_filters.rst:141
#: ../../rst/playbook_guide/playbooks_filters.rst:168
msgid "List data (after applying the ``dict2items`` filter):"
msgstr "データを一覧表示 (``dict2items`` フィルターを適用した後):"

#: ../../rst/playbook_guide/playbooks_filters.rst:152
msgid "The ``dict2items`` filter is the reverse of the ``items2dict`` filter."
msgstr "``dict2items`` フィルターは、``items2dict`` フィルターの逆の効果があります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:154
msgid "If you want to configure the names of the keys, the ``dict2items`` filter accepts 2 keyword arguments. Pass the ``key_name`` and ``value_name`` arguments to configure the names of the keys in the list output:"
msgstr "キー名を設定する場合は、``dict2items`` フィルターは 2 つのキーワード引数を受け入れます。``key_name`` 引数および ``value_name`` 引数を渡すと、リスト出力のキーの名前を設定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:179
msgid "Transforming lists into dictionaries"
msgstr "リストのディクショナリーへの変換"

#: ../../rst/playbook_guide/playbooks_filters.rst:183
msgid "Use the ``items2dict`` filter to transform a list into a dictionary, mapping the content into ``key: value`` pairs:"
msgstr "``items2dict`` フィルターを使用してリストをディクショナリーに変換し、コンテンツを ``key: value`` のペアにマッピングします。"

#: ../../rst/playbook_guide/playbooks_filters.rst:189
msgid "List data (before applying the ``items2dict`` filter):"
msgstr "リストデータ (``items2dict`` フィルターを適用する前):"

#: ../../rst/playbook_guide/playbooks_filters.rst:199
msgid "Dictionary data (after applying the ``items2dict`` filter):"
msgstr "ディクショナリーデータ (``items2dict`` フィルターを適用した後):"

#: ../../rst/playbook_guide/playbooks_filters.rst:206
msgid "The ``items2dict`` filter is the reverse of the ``dict2items`` filter."
msgstr "``items2dict`` フィルターは、``dict2items`` フィルターの逆の効果があります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:208
msgid "Not all lists use ``key`` to designate keys and ``value`` to designate values. For example:"
msgstr "すべてのリストで、キーの指定に ``key`` を使用し、値の指定に ``value`` を使用しているわけではありません。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:220
msgid "In this example, you must pass the ``key_name`` and ``value_name`` arguments to configure the transformation. For example:"
msgstr "この例では、``key_name`` 引数と ``value_name`` 引数を渡すと、変換を設定する必要があります。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:226
msgid "If you do not pass these arguments, or do not pass the correct values for your list, you will see ``KeyError: key`` or ``KeyError: my_typo``."
msgstr "これらの引数、またはリストに適した値を渡さない場合は、``KeyError: key`` または ``KeyError: my_typo`` が表示されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:229
msgid "Forcing the data type"
msgstr "データ型を強制"

#: ../../rst/playbook_guide/playbooks_filters.rst:231
msgid "You can cast values as certain types. For example, if you expect the input \"True\" from a :ref:`vars_prompt <playbooks_prompts>` and you want Ansible to recognize it as a boolean value instead of a string:"
msgstr "値を特定の型にキャストすることができます。たとえば、:ref:`vars_prompt <playbooks_prompts>` から「True」という入力を期待していて、Ansible にそれを文字列ではなくブール値として認識させたい場合は、次のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:239
msgid "If you want to perform a mathematical comparison on a fact and you want Ansible to recognize it as an integer instead of a string:"
msgstr "ファクトに対して数学的な比較を実行し、Ansible が文字列ではなく整数として認識する場合は、以下を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:252
msgid "Formatting data: YAML and JSON"
msgstr "データのフォーマット: YAML および JSON"

#: ../../rst/playbook_guide/playbooks_filters.rst:254
msgid "You can switch a data structure in a template from or to JSON or YAML format, with options for formatting, indenting, and loading data. The basic filters are occasionally useful for debugging:"
msgstr "テンプレート内のデータ構造を JSON 形式と YAML 形式との間で切り替えることができ、フォーマット化やインデント付け、データの読み込みなどのオプションも用意されています。基本的なフィルターは、時折、デバッグに役立ちます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:261
msgid "For human readable output, you can use:"
msgstr "人が判読できる出力にするには、以下を使用できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:268
msgid "You can change the indentation of either format:"
msgstr "いずれかの形式のインデントを変更できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:275
msgid "The ``to_yaml`` and ``to_nice_yaml`` filters use the `PyYAML library`_ which has a default 80 symbol string length limit. That causes unexpected line break after 80th symbol (if there is a space after 80th symbol) To avoid such behavior and generate long lines, use the ``width`` option. You must use a hardcoded number to define the width, instead of a construction like ``float(\"inf\")``, because the filter does not support proxying Python functions. For example:"
msgstr "``to_yaml`` フィルターおよび ``to_nice_yaml`` フィルターは、デフォルトで 80 記号の文字列長制限を持つ `PyYAML library`_ を使用しています。このため、80 番目の記号の後に予期せぬ改行が発生します (80 番目のシンボルの後に空白がある場合)。このような動作を回避し、長い行を生成するには、``width`` オプションを使用します。フィルターは Python 関数のプロキシーをサポートしていないため、``float(\"inf\")`` のような構文ではなく、ハードコードされた数値を使用して幅を定義する必要があります。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:283
msgid "The filter does support passing through other YAML parameters. For a full list, see the `PyYAML documentation`_ for ``dump()``."
msgstr "フィルターは他の YAML パラメーターのパススルーをサポートします。完全な一覧は、``dump()``の「`PyYAML ドキュメント`_」を参照してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:285
msgid "If you are reading in some already formatted data:"
msgstr "すでにフォーマットされている一部のデータで読み取る場合:"

#: ../../rst/playbook_guide/playbooks_filters.rst:292
#: ../../rst/playbook_guide/playbooks_filters.rst:334
msgid "for example:"
msgstr "以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:307
msgid "Filter `to_json` and Unicode support"
msgstr "`to_json` と Unicode サポートをフィルタリング"

#: ../../rst/playbook_guide/playbooks_filters.rst:309
msgid "By default `to_json` and `to_nice_json` will convert data received to ASCII, so:"
msgstr "デフォルトでは、`to_json` および `to_nice_json` は、受診したデータを ASCII に変換するため、次のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:315
msgid "will return:"
msgstr "以下が返されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:321
msgid "To keep Unicode characters, pass the parameter `ensure_ascii=False` to the filter:"
msgstr "Unicode 文字を保持するには、パラメーター `ensure_ascii=False` をフィルターに渡します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:331
msgid "To parse multi-document YAML strings, the ``from_yaml_all`` filter is provided. The ``from_yaml_all`` filter will return a generator of parsed YAML documents."
msgstr "複数ドキュメントの YAML 文字列を解析するために、``from_yaml_all`` フィルターが提供されます。``from_yaml_all`` フィルターは解析された YAML ドキュメントのジェネレーターを返します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:349
msgid "Combining and selecting data"
msgstr "データの統合および選択"

#: ../../rst/playbook_guide/playbooks_filters.rst:351
msgid "You can combine data from multiple sources and types, and select values from large data structures, giving you precise control over complex data."
msgstr "複数のソースやタイプのデータを組み合わせたり、大規模なデータ構造から値を選択したりすることで、複雑なデータを正確に制御することができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:356
msgid "Combining items from multiple lists: zip and zip_longest"
msgstr "複数のリストからの項目の組み合わせ: zip および zip_longest"

#: ../../rst/playbook_guide/playbooks_filters.rst:360
msgid "To get a list combining the elements of other lists use ``zip``:"
msgstr "他のリストの要素を組み合わせたリストを取得するには、``zip`` を使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:376
msgid "To always exhaust all lists use ``zip_longest``:"
msgstr "すべての一覧を常に使い切るには、``zip_longest`` を使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:386
msgid "Similarly to the output of the ``items2dict`` filter mentioned above, these filters can be used to construct a ``dict``:"
msgstr "上記の ``items2dict`` フィルターの出力と同様に、これらのフィルターを使用して ``dict`` を作成できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:392
msgid "List data (before applying the ``zip`` filter):"
msgstr "リストデータ (``zip`` フィルターを適用する前):"

#: ../../rst/playbook_guide/playbooks_filters.rst:403
msgid "Dictionary data (after applying the ``zip`` filter):"
msgstr "ディクショナリーデータ (``zip`` フィルターを適用した後):"

#: ../../rst/playbook_guide/playbooks_filters.rst:411
msgid "Combining objects and subelements"
msgstr "オブジェクトとサブ要素の統合"

#: ../../rst/playbook_guide/playbooks_filters.rst:415
msgid "The ``subelements`` filter produces a product of an object and the subelement values of that object, similar to the ``subelements`` lookup. This lets you specify individual subelements to use in a template. For example, this expression:"
msgstr "``subelements`` フィルターは、``subelements`` ルックアップと同様に、オブジェクトとそのオブジェクトのサブエレメントの値の積を生成します。これにより、テンプレートで使用する個々のサブエレメントを指定することができます。たとえば、以下のような式になります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:421
msgid "Data before applying the ``subelements`` filter:"
msgstr "``subelements`` フィルターの適用前のデータ:"

#: ../../rst/playbook_guide/playbooks_filters.rst:439
msgid "Data after applying the ``subelements`` filter:"
msgstr "``subelements`` フィルターの適用後のデータ:"

#: ../../rst/playbook_guide/playbooks_filters.rst:469
msgid "You can use the transformed data with ``loop`` to iterate over the same subelement for multiple objects:"
msgstr "変換したデータを ``loop`` とともに使用して、複数のオブジェクトに対して同じサブ要素を繰り返すことができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:482
msgid "Combining hashes/dictionaries"
msgstr "ハッシュ/ディクショナリーの統合"

#: ../../rst/playbook_guide/playbooks_filters.rst:486
msgid "The ``combine`` filter allows hashes to be merged. For example, the following would override keys in one hash:"
msgstr "``combine`` フィルターはハッシュをマージできます。たとえば、以下は 1 つのハッシュ内のキーをオーバーライドします。"

#: ../../rst/playbook_guide/playbooks_filters.rst:492
msgid "The resulting hash would be:"
msgstr "生成されるハッシュは、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:498
msgid "The filter can also take multiple arguments to merge:"
msgstr "フィルターは複数の引数を使用してマージすることもできます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:505
msgid "In this case, keys in ``d`` would override those in ``c``, which would override those in ``b``, and so on."
msgstr "この場合、``d`` のキーは ``c`` のキーを上書きし、``b`` のキーも同様に上書きされます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:507
msgid "The filter also accepts two optional parameters: ``recursive`` and ``list_merge``."
msgstr "フィルターは、``recursive`` および ``list_merge`` の 2 つの任意のパラメーターも使用できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:512
msgid "recursive"
msgstr "再帰"

#: ../../rst/playbook_guide/playbooks_filters.rst:510
msgid "Is a boolean, default to ``False``. Should the ``combine`` recursively merge nested hashes. Note: It does **not** depend on the value of the ``hash_behaviour`` setting in ``ansible.cfg``."
msgstr "ブール値で、デフォルトは ``False`` です。``combine`` が入れ子になったハッシュを再帰的にマージするかどうかを指定します。注: ``ansible.cfg`` の ``hash_behaviour`` 設定の値には **依存しません** 。"

#: ../../rst/playbook_guide/playbooks_filters.rst:516
msgid "list_merge"
msgstr "list_merge"

#: ../../rst/playbook_guide/playbooks_filters.rst:515
msgid "Is a string, its possible values are ``replace`` (default), ``keep``, ``append``, ``prepend``, ``append_rp`` or ``prepend_rp``. It modifies the behaviour of ``combine`` when the hashes to merge contain arrays/lists."
msgstr "使用できる値は ``replace`` (デフォルト)、``keep``、``append``、``prepend``、``append_rp``、または ``prepend_rp`` です。ハッシュに配列/リストをマージする際に ``combine`` の動作を変更します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:532
msgid "If ``recursive=False`` (the default), nested hash aren't merged:"
msgstr "``recursive=False`` (デフォルト) の場合は、ネストされたハッシュがマージされません。"

#: ../../rst/playbook_guide/playbooks_filters.rst:538
#: ../../rst/playbook_guide/playbooks_filters.rst:554
#: ../../rst/playbook_guide/playbooks_filters.rst:580
#: ../../rst/playbook_guide/playbooks_filters.rst:593
#: ../../rst/playbook_guide/playbooks_filters.rst:606
#: ../../rst/playbook_guide/playbooks_filters.rst:620
#: ../../rst/playbook_guide/playbooks_filters.rst:649
#: ../../rst/playbook_guide/playbooks_filters.rst:668
#: ../../rst/playbook_guide/playbooks_filters.rst:714
#: ../../rst/playbook_guide/playbooks_filters.rst:817
msgid "This would result in:"
msgstr "これにより、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:548
msgid "If ``recursive=True``, recurse into nested hash and merge their keys:"
msgstr "``recursive=True`` の場合は、ネストされたハッシュを再帰的に使用して、鍵をマージします。"

#: ../../rst/playbook_guide/playbooks_filters.rst:565
msgid "If ``list_merge='replace'`` (the default), arrays from the right hash will \"replace\" the ones in the left hash:"
msgstr "``list_merge='replace'`` (デフォルト) の場合、右ハッシュの配列は左ハッシュの配列を「置き換え」ます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:587
msgid "If ``list_merge='keep'``, arrays from the left hash will be kept:"
msgstr "``list_merge='keep'`` の場合は、左のハッシュからの配列が保持されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:600
msgid "If ``list_merge='append'``, arrays from the right hash will be appended to the ones in the left hash:"
msgstr "``list_merge='append'`` の場合は、右のハッシュからの配列が左のハッシュ内の配列に追加されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:614
msgid "If ``list_merge='prepend'``, arrays from the right hash will be prepended to the ones in the left hash:"
msgstr "``list_merge='prepend'`` の場合は、右のハッシュからの配列が左のハッシュ内の配列の前に追加されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:628
msgid "If ``list_merge='append_rp'``, arrays from the right hash will be appended to the ones in the left hash. Elements of arrays in the left hash that are also in the corresponding array of the right hash will be removed (\"rp\" stands for \"remove present\"). Duplicate elements that aren't in both hashes are kept:"
msgstr "``list_merge='append_rp'`` の場合は、右ハッシュの配列が、左ハッシュの配列に追加されます。左ハッシュの配列のうち、右ハッシュの対応する配列にもある要素は削除されます (「rp」は「remove present」の略)。両方のハッシュに存在しない重複した要素は保持されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:662
msgid "If ``list_merge='prepend_rp'``, the behavior is similar to the one for ``append_rp``, but elements of arrays in the right hash are prepended:"
msgstr "``list_merge='prepend_rp'`` の場合、動作は ``append_rp`` のものと似ていますが、右のハッシュ内の配列の要素の前に追加されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:681
msgid "``recursive`` and ``list_merge`` can be used together:"
msgstr "``recursive`` および ``list_merge`` は一緒に使用できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:739
msgid "Selecting values from arrays or hashtables"
msgstr "配列またはハッシュテーブルからの値の選択"

#: ../../rst/playbook_guide/playbooks_filters.rst:743
msgid "The `extract` filter is used to map from a list of indices to a list of values from a container (hash or array):"
msgstr "`extract` フィルターは、インデックスのリストから、コンテナー (ハッシュまたは配列) の値のリストへのマッピングに使用されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:750
msgid "The results of the above expressions would be:"
msgstr "上記の式の結果は、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:757
msgid "The filter can take another argument:"
msgstr "フィルターは別の引数を取ることができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:763
msgid "This takes the list of hosts in group 'x', looks them up in `hostvars`, and then looks up the `ec2_ip_address` of the result. The final result is a list of IP addresses for the hosts in group 'x'."
msgstr "これにより、グループ「x」のホスト一覧が `hostvars` で検索され、結果の `ec2_ip_address` を探します。最終結果は、グループ「x」のホストの IP アドレス一覧になります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:765
msgid "The third argument to the filter can also be a list, for a recursive lookup inside the container:"
msgstr "フィルターの第 3 引数にはリストを指定することもでき、コンテナー内の再帰的なルックアップが可能です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:771
msgid "This would return a list containing the value of `b['a']['x']['y']`."
msgstr "これにより、`b['a']['x']['y']` の値が含まれるリストが返されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:774
msgid "Combining lists"
msgstr "リストの統合"

#: ../../rst/playbook_guide/playbooks_filters.rst:776
msgid "This set of filters returns a list of combined lists."
msgstr "このフィルターセットは、組み合わせたリストを返します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:780
msgid "permutations"
msgstr "置換"

#: ../../rst/playbook_guide/playbooks_filters.rst:781
msgid "To get permutations of a list:"
msgstr "リストの置換を取得するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:794
msgid "combinations"
msgstr "組み合わせ"

#: ../../rst/playbook_guide/playbooks_filters.rst:795
msgid "Combinations always require a set size:"
msgstr "組み合わせには常にセットサイズが必要です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:803
msgid "Also see the :ref:`zip_filter`"
msgstr "また、「:ref:`zip_filter`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:806
msgid "products"
msgstr "製品"

#: ../../rst/playbook_guide/playbooks_filters.rst:807
msgid "The product filter returns the `cartesian product <https://docs.python.org/3/library/itertools.html#itertools.product>`_ of the input iterables. This is roughly equivalent to nested for-loops in a generator expression."
msgstr "製品フィルターは、入力されたイテラブルの `cartesian product <https://docs.python.org/3/library/itertools.html#itertools.product>`_ を返します。これはジェネレータ式の入れ子になった for-loop とほぼ同じです。"

#: ../../rst/playbook_guide/playbooks_filters.rst:826
msgid "Selecting JSON data: JSON queries"
msgstr "JSON データの選択: JSON クエリー"

#: ../../rst/playbook_guide/playbooks_filters.rst:828
msgid "To select a single element or a data subset from a complex data structure in JSON format (for example, Ansible facts), use the ``json_query`` filter.  The ``json_query`` filter lets you query a complex JSON structure and iterate over it using a loop structure."
msgstr "JSON 形式の複雑なデータ構造 (Ansible ファクトなど) から単一の要素やデータサブセットを選択するには、``json_query`` フィルターを使用します。``json_query`` フィルターを使用すると、複雑な JSON 構造を照会し、ループ構造を使用して反復処理することができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:832
#: ../../rst/playbook_guide/playbooks_filters.rst:991
msgid "This filter has migrated to the `community.general <https://galaxy.ansible.com/community/general>`_ collection. Follow the installation instructions to install that collection."
msgstr "`community.general <https://galaxy.ansible.com/community/general>`_ フィルターはコレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。"

#: ../../rst/playbook_guide/playbooks_filters.rst:835
msgid "You must manually install the **jmespath** dependency on the Ansible controller before using this filter. This filter is built upon **jmespath**, and you can use the same syntax. For examples, see `jmespath examples <https://jmespath.org/examples.html>`_."
msgstr "このフィルターを使用する前に、Ansible コントローラーに **jmespath** 依存関係を手動でインストールする必要があります。このフィルターは **jmespath** をベースに作られており、同じ構文を使用することができます。例については、`jmespath examples <https://jmespath.org/examples.html>`_ を参照してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:837
msgid "Consider this data structure:"
msgstr "このデータ構造を考えてみましょう。"

#: ../../rst/playbook_guide/playbooks_filters.rst:888
msgid "To extract all clusters from this structure, you can use the following query:"
msgstr "この構造からすべてのクラスターを抽出するには、以下のクエリーを使用できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:897
msgid "To extract all server names:"
msgstr "すべてのサーバー名を抽出するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:906
msgid "To extract ports from cluster1:"
msgstr "cluster1 からポートを抽出するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:917
msgid "You can use a variable to make the query more readable."
msgstr "変数を使用すると、クエリーの読み取りがより容易になります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:919
msgid "To print out the ports from cluster1 in a comma separated string:"
msgstr "cluster1 のポートをコンマ区切りの文字列で表示するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:927
msgid "In the example above, quoting literals using backticks avoids escaping quotes and maintains readability."
msgstr "上の例では、リテラルを backtick で引用することで、引用符のエスケープを避け、読みやすさを維持しています。"

#: ../../rst/playbook_guide/playbooks_filters.rst:929
msgid "You can use YAML `single quote escaping <https://yaml.org/spec/current.html#id2534365>`_:"
msgstr "YAML の `single quote escaping <https://yaml.org/spec/current.html#id2534365>`_ を使用できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:938
msgid "Escaping single quotes within single quotes in YAML is done by doubling the single quote."
msgstr "YAML の一重引用符内で一重引用符をエスケープする場合は、一重引用符を二重にします。"

#: ../../rst/playbook_guide/playbooks_filters.rst:940
msgid "To get a hash map with all ports and names of a cluster:"
msgstr "クラスターのすべてのポートおよび名前を持つハッシュマップを取得するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:951
msgid "To extract ports from all clusters with name starting with 'server1':"
msgstr "「server1」で始まる名前の全クラスターからポートを抽出するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:961
msgid "To extract ports from all clusters with name containing 'server1':"
msgstr "「server1」を含む名前の全クラスターからポートを抽出するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:971
msgid "while using ``starts_with`` and ``contains``, you have to use `` to_json | from_json `` filter for correct parsing of data structure."
msgstr "``starts_with`` および ``contains`` を使用する場合は、データ構造を正しく解析するために ``to_json | from_json`` フィルターを使用する必要があります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:975
msgid "Randomizing data"
msgstr "データのランダム化"

#: ../../rst/playbook_guide/playbooks_filters.rst:977
msgid "When you need a randomly generated value, use one of these filters."
msgstr "ランダムに生成された値が必要な場合は、これらのフィルターのいずれかを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:983
msgid "Random MAC addresses"
msgstr "ランダムな MAC アドレス"

#: ../../rst/playbook_guide/playbooks_filters.rst:987
msgid "This filter can be used to generate a random MAC address from a string prefix."
msgstr "このフィルターは、文字列プレフィックスからランダムな MAC アドレスを生成するために使用できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:993
msgid "To get a random MAC address from a string prefix starting with '52:54:00':"
msgstr "'52:54:00' で始まる文字列プレフィックスからランダムな MAC アドレスを取得するには、次のコマンドを実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1000
msgid "Note that if anything is wrong with the prefix string, the filter will issue an error."
msgstr "プレフィックスの文字列で不具合が生じた場合は、フィルターによりエラーが生じることに注意してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1004
msgid "As of Ansible version 2.9, you can also initialize the random number generator from a seed to create random-but-idempotent MAC addresses:"
msgstr "Ansible バージョン 2.9 以降では、シードから乱数ジェネレーターを初期化し、ランダムで冪等な MAC アドレスを作成することもできます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1014
msgid "Random items or numbers"
msgstr "ランダムな項目または数字"

#: ../../rst/playbook_guide/playbooks_filters.rst:1016
msgid "The ``random`` filter in Ansible is an extension of the default Jinja2 random filter, and can be used to return a random item from a sequence of items or to generate a random number based on a range."
msgstr "Ansible の``random`` フィルターは、デフォルトの Jinja2 ランダムフィルターを拡張したもので、一連のアイテムからランダムな項目を返したり、範囲に基づいてランダムな数値を生成したりするのに使用できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1018
msgid "To get a random item from a list:"
msgstr "リストからランダムなアイテムを取得するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1025
msgid "To get a random number between 0 (inclusive) and a specified integer (exclusive):"
msgstr "0 (含む) から指定した整数 (除く) の間の乱数を取得するには、次のようにします。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1032
msgid "To get a random number from 0 to 100 but in steps of 10:"
msgstr "0 から 100 までの 10 のステップで乱数を取得するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1039
msgid "To get a random number from 1 to 100 but in steps of 10:"
msgstr "1 から 100 までの 10 のステップで乱数を取得するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1048
msgid "You can initialize the random number generator from a seed to create random-but-idempotent numbers:"
msgstr "シードから乱数ジェネレーターを初期化し、ランダムで冪等な数字を作成できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1055
msgid "Shuffling a list"
msgstr "リストのシャッフル"

#: ../../rst/playbook_guide/playbooks_filters.rst:1057
msgid "The ``shuffle`` filter randomizes an existing list, giving a different order every invocation."
msgstr "``shuffle`` フィルターは、既存のリストをランダム化し、呼び出しごとに異なる順序を提供します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1059
msgid "To get a random list from an existing  list:"
msgstr "既存のリストからランダムなリストを取得するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1068
msgid "You can initialize the shuffle generator from a seed to generate a random-but-idempotent order:"
msgstr "シャッフルジェネレーターをシードから初期化して、ランダムで冪等な順序を生成することができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1075
msgid "The shuffle filter returns a list whenever possible. If you use it with a non 'listable' item, the filter does nothing."
msgstr "シャッフルフィルターは可能な場合常にリストを返します。「リスト可能」ではない項目で使用すると、フィルターは何も行いません。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1081
msgid "Managing list variables"
msgstr "リスト変数の管理"

#: ../../rst/playbook_guide/playbooks_filters.rst:1083
msgid "You can search for the minimum or maximum value in a list, or flatten a multi-level list."
msgstr "リストの最小値や最大値を検索したり、複数レベルのリストをフラットにすることができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1085
msgid "To get the minimum value from list of numbers:"
msgstr "数値リストから最小値を取得するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1093
msgid "To get the minimum value in a list of objects:"
msgstr "オブジェクトのリストで最小値を取得するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1099
msgid "To get the maximum value from a list of numbers:"
msgstr "数値リストから最大値を取得するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1107
msgid "To get the maximum value in a list of objects:"
msgstr "オブジェクトのリストで最大値を取得するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1115
msgid "Flatten a list (same thing the `flatten` lookup does):"
msgstr "リストをフラット化します (`flatten` ルックアップと同等)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1122
msgid "Flatten only the first level of a list (akin to the `items` lookup):"
msgstr "リストの最初のレベルのみをフラット化します (`items` ルックアップと同等)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1132
msgid "Preserve nulls in a list, by default flatten removes them. :"
msgstr "リストに null を保持します。デフォルトでは、フラット化はこれらを削除します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1143
msgid "Selecting from sets or lists (set theory)"
msgstr "セットまたはリストの中から選択 (理論の設定)"

#: ../../rst/playbook_guide/playbooks_filters.rst:1145
msgid "You can select or combine items from sets or lists."
msgstr "セットまたはリストから項目を選択または組み合わせることができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1149
msgid "To get a unique set from a list:"
msgstr "リストから一意のセットを取得するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1157
msgid "To get a union of two lists:"
msgstr "2 つのリストを組み合わせて取得するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1166
msgid "To get the intersection of 2 lists (unique list of all items in both):"
msgstr "2 つのリスト (両方の全項目の一意のリスト) で構成されるものを取得するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1175
msgid "To get the difference of 2 lists (items in 1 that don't exist in 2):"
msgstr "2 つのリストの相違点を取得するには (2 に存在しない 1 の項目)、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1184
msgid "To get the symmetric difference of 2 lists (items exclusive to each list):"
msgstr "2 つのリストの対称的な違いを取得する (各リストへの除外) には、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1196
msgid "Calculating numbers (math)"
msgstr "数字の計算 (数学)"

#: ../../rst/playbook_guide/playbooks_filters.rst:1200
msgid "You can calculate logs, powers, and roots of numbers with Ansible filters. Jinja2 provides other mathematical functions like abs() and round()."
msgstr "Ansible のフィルターを使用して、対数、累乗、おより根を計算することができます。また、Jinja2 には abs() や round() などの数学関数も用意されています。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1202
msgid "Get the logarithm (default is e):"
msgstr "対数を取得します (デフォルトは e)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1209
msgid "Get the base 10 logarithm:"
msgstr "底が 10 の対数を取得します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1216
msgid "Give me the power of 2! (or 5):"
msgstr "2 の累乗 (または 5)を取得します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1223
msgid "Square root, or the 5th:"
msgstr "平方根または 5 乗根を取得します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1235
msgid "Managing network interactions"
msgstr "ネットワーク対話の管理"

#: ../../rst/playbook_guide/playbooks_filters.rst:1237
msgid "These filters help you with common network tasks."
msgstr "これらのフィルターは、一般的なネットワークタスクの使用に役立ちます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1241
msgid "These filters have migrated to the `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ collection. Follow the installation instructions to install that collection."
msgstr "これらのフィルターは `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1246
msgid "IP address filters"
msgstr "IP アドレスフィルター"

#: ../../rst/playbook_guide/playbooks_filters.rst:1250
msgid "To test if a string is a valid IP address:"
msgstr "文字列が有効な IP アドレスかどうかをテストするには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1256
msgid "You can also require a specific IP protocol version:"
msgstr "さらに、特定の IP プロトコルバージョンが必要です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1263
msgid "IP address filter can also be used to extract specific information from an IP address. For example, to get the IP address itself from a CIDR, you can use:"
msgstr "IP アドレスフィルターを使用して、IP アドレスから特定の情報を抽出することもできます。たとえば、CIDR から IP アドレス自体を取得するには、以下を使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1271
msgid "More information about ``ipaddr`` filter and complete usage guide can be found in :ref:`playbooks_filters_ipaddr`."
msgstr "``ipaddr`` フィルターの詳細と完全な使用ガイドは、「:ref:`playbooks_filters_ipaddr`」にあります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1277
msgid "Network CLI filters"
msgstr "ネットワーク CLI フィルター"

#: ../../rst/playbook_guide/playbooks_filters.rst:1281
msgid "To convert the output of a network device CLI command into structured JSON output, use the ``parse_cli`` filter:"
msgstr "ネットワーク機器の CLI コマンドの出力を構造化された JSON 出力に変換するには、``parse_cli`` フィルターを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1288
msgid "The ``parse_cli`` filter will load the spec file and pass the command output through it, returning JSON output. The YAML spec file defines how to parse the CLI output."
msgstr "``parse_cli`` フィルターは、spec ファイルを読み込み、コマンド出力を通して JSON 出力を返します。YAML の spec ファイルは、CLI 出力をどのように解析するかを定義します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1291
msgid "The spec file should be valid formatted YAML.  It defines how to parse the CLI output and return JSON data.  Below is an example of a valid spec file that will parse the output from the ``show vlan`` command."
msgstr "spec ファイルは有効な形式の YAML でなければなりません。CLI の出力をどのように解析し、JSON データを返すかを定義します。以下は、``show vlan`` コマンドからの出力を解析する有効な spec ファイルの例です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1313
#: ../../rst/playbook_guide/playbooks_filters.rst:1419
msgid "The spec file above will return a JSON data structure that is a list of hashes with the parsed VLAN information."
msgstr "上記の spec ファイルは、解析された VLAN 情報を持つハッシュのリストである JSON データ構造を返します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1316
msgid "The same command could be parsed into a hash by using the key and values directives.  Here is an example of how to parse the output into a hash value using the same ``show vlan`` command."
msgstr "同じコマンドでも、鍵と値のディレクティブを使用することで、ハッシュに解析することができます。以下は、同じ ``show vlan`` コマンドを使用して出力をハッシュ値に解析する例です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1339
msgid "Another common use case for parsing CLI commands is to break a large command into blocks that can be parsed.  This can be done using the ``start_block`` and ``end_block`` directives to break the command into blocks that can be parsed."
msgstr "CLI コマンドを解析するもう一つの一般的なユースケースは、大きなコマンドを解析可能なブロックに分割することです。これは、``start_block`` ディレクティブと ``end_block`` ディレクティブを使用して、コマンドを解析可能なブロックに分割することで行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1363
msgid "The example above will parse the output of ``show interface`` into a list of hashes."
msgstr "上の例では、``show interface`` の出力を解析して、ハッシュのリストを作成します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1366
msgid "The network filters also support parsing the output of a CLI command using the TextFSM library.  To parse the CLI output with TextFSM use the following filter:"
msgstr "ネットワークフィルターは、TextFSM ライブラリーを使用して CLI コマンドの出力の解析もサポートします。TextFSM で CLI 出力を解析するには、以下のフィルターを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1374
msgid "Use of the TextFSM filter requires the TextFSM library to be installed."
msgstr "TextFSM フィルターを使用するには、TextFSM ライブラリーをインストールする必要があります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1377
msgid "Network XML filters"
msgstr "ネットワーク XML フィルター"

#: ../../rst/playbook_guide/playbooks_filters.rst:1381
msgid "To convert the XML output of a network device command into structured JSON output, use the ``parse_xml`` filter:"
msgstr "ネットワークデバイスコマンドの XML 出力を構造化された JSON 出力に変換するには、``parse_xml`` フィルターを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1388
msgid "The ``parse_xml`` filter will load the spec file and pass the command output through formatted as JSON."
msgstr "``parse_xml`` フィルターは、spec ファイルを読み込み、JSON としてフォーマットされたコマンド出力を渡します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1391
msgid "The spec file should be valid formatted YAML. It defines how to parse the XML output and return JSON data."
msgstr "仕様ファイルは有効な YAML 形式である必要があります。XML 出力を解析し、JSON データを返す方法を定義します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1394
msgid "Below is an example of a valid spec file that will parse the output from the ``show vlan | display xml`` command."
msgstr "以下は、``show vlan | display xml`` コマンドの出力を解析するための有効な spec ファイルの例です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1422
msgid "The same command could be parsed into a hash by using the key and values directives.  Here is an example of how to parse the output into a hash value using the same ``show vlan | display xml`` command."
msgstr "同じコマンドでも、鍵と値のディレクティブを使用することで、ハッシュに解析することができます。以下は、同じ ``show vlan | display xml`` コマンドを使用して出力をハッシュ値に解析する例です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1450
msgid "The value of ``top`` is the XPath relative to the XML root node. In the example XML output given below, the value of ``top`` is ``configuration/vlans/vlan``, which is an XPath expression relative to the root node (<rpc-reply>). ``configuration`` in the value of ``top`` is the outer most container node, and ``vlan`` is the inner-most container node."
msgstr "``top`` の値は、XML ルートノードに対する相対的な XPath です。以下の XML 出力例では、``top`` の値は ``configuration/vlans/vlan`` であり、これはルートノード (<rpc-reply>) に対する相対的な XPath 式です。``top`` の値の ``configuration`` は最も外側のコンテナーノードであり、``vlan`` は最も内側のコンテナーノードです。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1456
msgid "``items`` is a dictionary of key-value pairs that map user-defined names to XPath expressions that select elements. The Xpath expression is relative to the value of the XPath value contained in ``top``. For example, the ``vlan_id`` in the spec file is a user defined name and its value ``vlan-id`` is the relative to the value of XPath in ``top``"
msgstr "``items`` は、ユーザー定義の名前を、要素を選択する XPath 式にマッピングするキーと値のペアのディクショナリーです。Xpath 式は、``top`` に含まれる XPath 値の値に対する相対値です。たとえば、spec ファイルの ``vlan_id`` はユーザー定義の名前で、その値 ``vlan-id`` は、``top`` に含まれる XPath の値に対する相対値です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1461
msgid "Attributes of XML tags can be extracted using XPath expressions. The value of ``state`` in the spec is an XPath expression used to get the attributes of the ``vlan`` tag in output XML.:"
msgstr "XML タグの属性は、XPath 式を用いて抽出することができます。仕様書の ``state`` の値は、出力された XML の ``vlan`` タグの属性を取得するために使用される XPath 式です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1479
msgid "For more information on supported XPath expressions, see `XPath Support <https://docs.python.org/3/library/xml.etree.elementtree.html#xpath-support>`_."
msgstr "サポートされる XPath 式の詳細は、「`XPath Support <https://docs.python.org/3/library/xml.etree.elementtree.html#xpath-support>`_」を参照してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1482
msgid "Network VLAN filters"
msgstr "ネットワーク VLAN フィルター"

#: ../../rst/playbook_guide/playbooks_filters.rst:1486
msgid "Use the ``vlan_parser`` filter to transform an unsorted list of VLAN integers into a sorted string list of integers according to IOS-like VLAN list rules. This list has the following properties:"
msgstr "``vlan_parser`` フィルターを使用して、ソートされていない VLAN 整数のリストを、IOS のような VLAN リストのルールに従ってソートされた整数の文字列リストに変換します。このリストには以下のプロパティーがあります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1489
msgid "Vlans are listed in ascending order."
msgstr "VLAN は昇順でリストされます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1490
msgid "Three or more consecutive VLANs are listed with a dash."
msgstr "3 つ以上の連続した VLAN はダッシュ付きでリストされます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1491
msgid "The first line of the list can be first_line_len characters long."
msgstr "リストの最初の行は、first_line_len 文字の長さになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1492
msgid "Subsequent list lines can be other_line_len characters."
msgstr "後続のリスト行は、other_line_len 文字になります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1494
msgid "To sort a VLAN list:"
msgstr "VLAN リストをソートするには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1500
msgid "This example renders the following sorted list:"
msgstr "この例では、以下のソートリストを示しています。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1507
msgid "Another example Jinja template:"
msgstr "Jinja テンプレートの他の例:"

#: ../../rst/playbook_guide/playbooks_filters.rst:1517
msgid "This allows for dynamic generation of VLAN lists on a Cisco IOS tagged interface. You can store an exhaustive raw list of the exact VLANs required for an interface and then compare that to the parsed IOS output that would actually be generated for the configuration."
msgstr "これにより、Cisco IOS タグ付きインターフェース上の VLAN リストを動的に生成することができます。インターフェースに必要な正確な VLAN の網羅的な生のリストを保存し、それを設定のために実際に生成されるであろう解析された IOS 出力と比較することができます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1523
msgid "Hashing and encrypting strings and passwords"
msgstr "文字列およびパスワードのハッシュ処理および暗号化"

#: ../../rst/playbook_guide/playbooks_filters.rst:1527
msgid "To get the sha1 hash of a string:"
msgstr "文字列の sha1 ハッシュを取得するには、次のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1534
msgid "To get the md5 hash of a string:"
msgstr "文字列の md5 ハッシュを取得するには、次のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1541
msgid "Get a string checksum:"
msgstr "文字列のチェックサムを取得します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1548
msgid "Other hashes (platform dependent):"
msgstr "その他のハッシュ (プラットフォームに依存):"

#: ../../rst/playbook_guide/playbooks_filters.rst:1554
msgid "To get a sha512 password hash (random salt):"
msgstr "sha512 パスワードハッシュ (任意の salt) を取得するには、次のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1561
msgid "To get a sha256 password hash with a specific salt:"
msgstr "特定の salt を持つ sha256 パスワードハッシュを取得するには、次のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1568
msgid "An idempotent method to generate unique hashes per system is to use a salt that is consistent between runs:"
msgstr "システムごとに一意のハッシュを生成する冪等な方法は、実行間で一貫性のある salt を使用することです。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1575
msgid "Hash types available depend on the control system running Ansible, 'hash' depends on `hashlib <https://docs.python.org/3.8/library/hashlib.html>`_, password_hash depends on `passlib <https://passlib.readthedocs.io/en/stable/lib/passlib.hash.html>`_. The `crypt <https://docs.python.org/3.8/library/crypt.html>`_ is used as a fallback if ``passlib`` is not installed."
msgstr "利用可能なハッシュタイプは、Ansible を実行している制御システムに依存しており、「hash」は `hashlib <https://docs.python.org/3.8/library/hashlib.html>`_ に、「password_hash」は `passlib <https://passlib.readthedocs.io/en/stable/lib/passlib.hash.html>`_ に依存しています。`crypt <https://docs.python.org/3.8/library/crypt.html>`_ は ``passlib`` がインストールされていない場合のフォールバックとして使用されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1579
msgid "Some hash types allow providing a rounds parameter:"
msgstr "ハッシュタイプによっては、rounds パラメーターを指定できるものもあります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1586
msgid "The filter `password_hash` produces different results depending on whether you installed `passlib` or not."
msgstr "フィルター `password_hash` は、`passlib` をインストールしたかどうかによって異なる結果を生成します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1588
msgid "To ensure idempotency, specify `rounds` to be neither `crypt`'s nor `passlib`'s default, which is `5000` for `crypt` and a variable value (`535000` for sha256, `656000` for sha512) for `passlib`:"
msgstr "冪等性を確保するには、`rounds` を `crypt` または `passlib`のデフォルトにならないように指定します。これは、`crypt` の場合は `5000`、`passlib` の場合は変数値 (sha256 の場合は `535000`、sha512 の場合は`656000`) です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1595
msgid "Hash type 'blowfish' (BCrypt) provides the facility to specify the version of the BCrypt algorithm."
msgstr "ハッシュタイプ 'blowfish' (BCrypt) は、BCrypt アルゴリズムのバージョンを指定する機能を提供します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1603
msgid "The parameter is only available for `blowfish (BCrypt) <https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt.html#passlib.hash.bcrypt>`_. Other hash types will simply ignore this parameter. Valid values for this parameter are: ['2', '2a', '2y', '2b']"
msgstr "このパラメーターは、`blowfish (BCrypt) <https://passlib.readthedocs.io/en/stable/lib/passlib.hash.bcrypt.html#passlib.hash.bcrypt>`_ でのみ利用できます。他のハッシュタイプは、このパラメーターを無視します。このパラメーターに対する有効な値は ['2', '2a', '2y', '2b'] です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1609
msgid "You can also use the Ansible :ref:`vault <vault>` filter to encrypt data:"
msgstr "Ansible の :ref:`vault <vault>` フィルターを使用してデータを暗号化することもできます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1624
msgid "And then decrypt it using the unvault filter:"
msgstr "その後、unvault フィルターを使用して復号します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1641
msgid "Manipulating text"
msgstr "テキストの操作"

#: ../../rst/playbook_guide/playbooks_filters.rst:1643
msgid "Several filters work with text, including URLs, file names, and path names."
msgstr "いくつかのフィルターは、URL、ファイル名、パス名などのテキストを扱います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1648
msgid "Adding comments to files"
msgstr "ファイルへのコメントの追加"

#: ../../rst/playbook_guide/playbooks_filters.rst:1650
msgid "The ``comment`` filter lets you create comments in a file from text in a template, with a variety of comment styles. By default Ansible uses ``#`` to start a comment line and adds a blank comment line above and below your comment text. For example the following:"
msgstr "``comment`` フィルターを使用すると、テンプレート内のテキストから、さまざまなコメントスタイルでファイル内にコメントを作成することができます。Ansible のデフォルトでは、``#`` を使用してコメント行を開始し、コメントテキストの上下に空白のコメント行を追加します。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1656
msgid "produces this output:"
msgstr "次の出力を生成します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1664
msgid "Ansible offers styles for comments in C (``//...``), C block (``/*...*/``), Erlang (``%...``) and XML (``<!--...-->``):"
msgstr "Ansibleでは、C (``//...``)、C ブロック (``/*...*/``)、Erlang (``%...``)、および XML (``<!--...-->``) のコメント用スタイルを提供しています。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1674
msgid "You can define a custom comment character. This filter:"
msgstr "カスタムのコメント文字を定義できます。このフィルターは、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1680
msgid "produces:"
msgstr "生成:"

#: ../../rst/playbook_guide/playbooks_filters.rst:1688
msgid "You can fully customize the comment style:"
msgstr "コメントスタイルを完全にカスタマイズすることもできます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1694
msgid "That creates the following output:"
msgstr "これにより、以下の出力が作成されます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1706
msgid "The filter can also be applied to any Ansible variable. For example to make the output of the ``ansible_managed`` variable more readable, we can change the definition in the ``ansible.cfg`` file to this:"
msgstr "フィルターは、Ansible 変数にも適用することもできます。たとえば、``ansible_managed`` 変数の出力をより読みやすくするために、``ansible.cfg`` ファイルの定義を以下のように変更します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1720
msgid "and then use the variable with the `comment` filter:"
msgstr "次に、`comment` フィルターで変数を使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1726
msgid "which produces this output:"
msgstr "これは、次の出力を生成します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1740
msgid "URLEncode Variables"
msgstr "URLEncode 変数"

#: ../../rst/playbook_guide/playbooks_filters.rst:1742
msgid "The ``urlencode`` filter quotes data for use in a URL path or query using UTF-8:"
msgstr "``urlencode`` フィルターは、URL パスを使用、または UTF-8 を使用したクエリーで使用するデータを引用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1750
msgid "Splitting URLs"
msgstr "URL の分割"

#: ../../rst/playbook_guide/playbooks_filters.rst:1754
msgid "The ``urlsplit`` filter extracts the fragment, hostname, netloc, password, path, port, query, scheme, and username from an URL. With no arguments, returns a dictionary of all the fields:"
msgstr "``urlsplit`` フィルターは、URL からフラグメント、ホスト名、netloc、パスワード、パス、ポート、クエリー、スキーム、およびユーザー名を抽出します。引数がない場合は、すべてのフィールドのディクショナリーを返します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1800
msgid "Searching strings with regular expressions"
msgstr "正規表現を使用した文字列の検索"

#: ../../rst/playbook_guide/playbooks_filters.rst:1802
msgid "To search in a string or extract parts of a string with a regular expression, use the ``regex_search`` filter:"
msgstr "文字列の検索または正規表現で文字列の部分を抽出するには、``regex_search`` フィルターを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1822
msgid "The ``regex_search`` filter returns an empty string if it cannot find a match:"
msgstr "``regex_search`` フィルターは、一致するものが見つからない場合に空の文字列を返します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1833
msgid "The ``regex_search`` filter returns ``None`` when used in a Jinja expression (for example in conjunction with operators, other filters, and so on). See the two examples below."
msgstr "Jinja 式で使用されると、``regex_search`` フィルターは ``None`` を返します )たとえば演算子、他のフィルターなど)。以下の 2 例を参照してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1842
msgid "This is due to historic behavior and the custom re-implementation of some of the Jinja internals in Ansible. Enable the ``jinja2_native`` setting if you want the ``regex_search`` filter to always return ``None`` if it cannot find a match. See :ref:`jinja2_faqs` for details."
msgstr "これは、Ansible の Jinja 内部のいくつかの歴史的な動作とカスタムの再実装によるものです。一致するものがみつからない場合に ``regex_search`` フィルターが常に ``None`` を返すようにするには、``jinja2_native`` 設定を有効にします。詳細は :ref:`jinja2_faqs` を参照してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1844
msgid "To extract all occurrences of regex matches in a string, use the ``regex_findall`` filter:"
msgstr "文字列の中にある正規表現の一致のすべての出現箇所を抽出するには、``regex_findall`` フィルターを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1857
msgid "To replace text in a string with regex, use the ``regex_replace`` filter:"
msgstr "文字列のテキストを正規表現に置き換えるには、``regex_replace`` フィルターを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1882
msgid "If you want to match the whole string and you are using ``*`` make sure to always wraparound your regular expression with the start/end anchors. For example ``^(.*)$`` will always match only one result, while ``(.*)`` on some Python versions will match the whole string and an empty string at the end, which means it will make two replacements:"
msgstr "文字列全体に一致させたい場合に ``*`` を使用する場合は、必ず開始/終了アンカーで正規表現を折り返すようにしてください。たとえば、``^(.*)$`` は常に 1 つの結果のみに一致しますが、``(.*)`` はいくつかの Python バージョンでは文字列全体と最後に空の文字列に一致します。つまり 2 つの置換を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1905
msgid "Prior to ansible 2.0, if ``regex_replace`` filter was used with variables inside YAML arguments (as opposed to simpler 'key=value' arguments), then you needed to escape backreferences (for example, ``\\\\1``) with 4 backslashes (``\\\\\\\\``) instead of 2 (``\\\\``)."
msgstr "ansible 2.0 より前のバージョンでは、(単純な「key=value」引数ではなく) ``regex_replace`` フィルターを YAML 引数内の変数に使用する場合は、後方参照 (たとえば ``\\\\1``) をバックスラッシュ 2 つ (``\\\\``) ではなく 4 つ (``\\\\\\\\``) でエスケープする必要がありました。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1909
msgid "To escape special characters within a standard Python regex, use the ``regex_escape`` filter (using the default ``re_type='python'`` option):"
msgstr "標準の Python 正規表現内で特殊文字をエスケープするには、``regex_escape`` フィルターを使用します (デフォルトの ``re_type='python'`` オプションを使用)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1918
msgid "To escape special characters within a POSIX basic regex, use the ``regex_escape`` filter with the ``re_type='posix_basic'`` option:"
msgstr "POSIX 基本正規表現内で特殊文字をエスケープするには、``regex_escape`` フィルターを ``re_type='posix_basic'`` オプションを付けて使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1927
msgid "Managing file names and path names"
msgstr "ファイル名とパス名の管理"

#: ../../rst/playbook_guide/playbooks_filters.rst:1929
msgid "To get the last name of a file path, like 'foo.txt' out of '/etc/asdf/foo.txt':"
msgstr "「/etc/asdf/foo.txt」の「foo.txt」のように、ファイルパスの最後の名前を取得するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1935
msgid "To get the last name of a windows style file path (new in version 2.0):"
msgstr "ウィンドウスタイルのファイルパスの最後の名前を取得するには、以下を指定します (バージョン 2.0 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1941
msgid "To separate the windows drive letter from the rest of a file path (new in version 2.0):"
msgstr "Windows ドライブの文字を残りのファイルパスから分離するには、以下を指定します (バージョン 2.0 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1947
msgid "To get only the windows drive letter:"
msgstr "Windows ドライブの文字のみを取得するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1953
msgid "To get the rest of the path without the drive letter:"
msgstr "ドライブ文字なしで残りのパスを取得するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1959
msgid "To get the directory from a path:"
msgstr "パスからディレクトリーを取得するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1965
msgid "To get the directory from a windows path (new version 2.0):"
msgstr "Windows パスからディレクトリーを取得するには、以下を指定します (バージョン 2.0 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1971
msgid "To expand a path containing a tilde (`~`) character (new in version 1.5):"
msgstr "チルド (`~`) 文字を含むパスを拡張するには、以下を指定します (バージョン 1.5 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1977
msgid "To expand a path containing environment variables:"
msgstr "環境変数を含むパスを拡張するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1983
msgid "`expandvars` expands local variables; using it on remote paths can lead to errors."
msgstr "`expandvars` は、ローカル変数を拡張します。リモートパスで使用するとエラーが発生する可能性があります。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1987
msgid "To get the real path of a link (new in version 1.8):"
msgstr "リンクの実際のパスを取得するには、以下を指定します (バージョン 1.8 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1993
msgid "To get the relative path of a link, from a start point (new in version 1.7):"
msgstr "リンクの相対パスを取得するには、開始点から以下を行います (バージョン 1.7 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:1999
msgid "To get the root and extension of a path or file name (new in version 2.0):"
msgstr "パスまたはファイル名のルートおよび拡張を取得するには、以下を指定します (バージョン 2.0 の新機能)。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2006
msgid "The ``splitext`` filter always returns a pair of strings. The individual components can be accessed by using the ``first`` and ``last`` filters:"
msgstr "``splitext`` フィルターは、常に文字列のペアを返します。個々のコンポーネントは、``first`` フィルターおよび ``last`` フィルターを使用してアクセスできます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2016
msgid "To join one or more path components:"
msgstr "1 つ以上のパスコンポーネントを結合するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2025
msgid "Manipulating strings"
msgstr "文字列の操作"

#: ../../rst/playbook_guide/playbooks_filters.rst:2027
msgid "To add quotes for shell usage:"
msgstr "シェルの使用に引用符を追加するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2034
msgid "To concatenate a list into a string:"
msgstr "リストを文字列に連結するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2040
msgid "To split a string into a list:"
msgstr "文字列をリストに分割するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2048
msgid "To work with Base64 encoded strings:"
msgstr "Base64 でエンコードされた文字列を使用するには、以下を指定します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2055
msgid "As of version 2.6, you can define the type of encoding to use, the default is ``utf-8``:"
msgstr "バージョン 2.6 以降では、使用するエンコーディングのタイプを定義できます。デフォルトは ``utf-8`` です。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2062
msgid "The ``string`` filter is only required for Python 2 and ensures that text to encode is a unicode string. Without that filter before b64encode the wrong value will be encoded."
msgstr "``string`` フィルターは Python 2 でのみ必要です。エンコードするテキストがユニコード文字列であることを確認します。b64encode より前のフィルターを使用しないと、誤った値がエンコードされます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2067
msgid "Managing UUIDs"
msgstr "UUID の管理"

#: ../../rst/playbook_guide/playbooks_filters.rst:2069
msgid "To create a namespaced UUIDv5:"
msgstr "namespace を使用した UUIDv5 を作成するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2077
msgid "To create a namespaced UUIDv5 using the default Ansible namespace '361E6D51-FAEC-444A-9079-341386DA8E2E':"
msgstr "デフォルトの Ansible 名前空間「361E6D51-FAEC-444A-9079-341386DA8E2E2E」を使用して名前空間を指定した UUIDv5 を作成するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2085
msgid "To make use of one attribute from each item in a list of complex variables, use the :func:`Jinja2 map filter <jinja2:jinja-filters.map>`:"
msgstr "複雑な変数のリストで、各項目から 1 つの属性を使用するには、:func:`Jinja2 map filter <jinja2:jinja-filters.map>` を使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2093
msgid "Handling dates and times"
msgstr "日付と時刻の処理"

#: ../../rst/playbook_guide/playbooks_filters.rst:2095
msgid "To get a date object from a string use the `to_datetime` filter:"
msgstr "文字列から日付オブジェクトを取得するには、`to_datetime` フィルターを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2109
msgid "For a full list of format codes for working with python date format strings, see https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior."
msgstr "Python 日付形式の文字列を使用する形式コードの全一覧は、https://docs.python.org/3/library/datetime.html#strftime-and-strptime-behavior を参照してください。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2113
msgid "To format a date using a string (like with the shell date command), use the \"strftime\" filter:"
msgstr "文字列 (shell date コマンドの場合のように) を使用して日付をフォーマットするには、「strftime」フィルターを使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2135
msgid "strftime takes an optional utc argument, defaulting to False, meaning times are in the local timezone::"
msgstr "strftime はオプションの utc 引数を取ります。デフォルトは False で、ローカルタイムゾーンの時間を使用します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2140
msgid "To get all string possibilities, check https://docs.python.org/3/library/time.html#time.strftime"
msgstr "すべての文字列の可能性を取得するには、https://docs.python.org/3/library/time.html#time.strftime を確認します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2143
msgid "Getting Kubernetes resource names"
msgstr "Kubernetes リソース名の取得"

#: ../../rst/playbook_guide/playbooks_filters.rst:2147
msgid "These filters have migrated to the `kubernetes.core <https://galaxy.ansible.com/kubernetes/core>`_ collection. Follow the installation instructions to install that collection."
msgstr "これらのフィルターは `kubernetes.core <https://galaxy.ansible.com/kubernetes/core>`_ コレクションに移行しました。インストール手順に従ってそのコレクションをインストールします。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2149
msgid "Use the \"k8s_config_resource_name\" filter to obtain the name of a Kubernetes ConfigMap or Secret, including its hash:"
msgstr "「k8s_config_resource_name」フィルターを使用して、Kubernetes ConfigMap または Secret の名前を、そのハッシュを含めて取得します。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2156
msgid "This can then be used to reference hashes in Pod specifications:"
msgstr "これは、Pod 仕様のハッシュを参照するために使用できます。"

#: ../../rst/playbook_guide/playbooks_filters.rst:2184
#: ../../rst/playbook_guide/playbooks_loops.rst:486
#: ../../rst/playbook_guide/playbooks_strategies.rst:245
#: ../../rst/playbook_guide/playbooks_variables.rst:515
msgid ":ref:`about_playbooks`"
msgstr ":ref:`about_playbooks`"

#: ../../rst/playbook_guide/playbooks_filters.rst:2190
#: ../../rst/playbook_guide/playbooks_lookups.rst:34
#: ../../rst/playbook_guide/playbooks_reuse.rst:217
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:602
#: ../../rst/playbook_guide/playbooks_tests.rst:533
#: ../../rst/playbook_guide/playbooks_variables.rst:521
msgid ":ref:`playbooks_loops`"
msgstr ":ref:`playbooks_loops`"

#: ../../rst/playbook_guide/playbooks_filters.rst:2191
#: ../../rst/playbook_guide/playbooks_lookups.rst:35
#: ../../rst/playbook_guide/playbooks_tests.rst:534
#: ../../rst/playbook_guide/playbooks_variables.rst:522
msgid "Looping in playbooks"
msgstr "Playbook でのループ"

#: ../../rst/playbook_guide/playbooks_handlers.rst:4
msgid "Handlers: running operations on change"
msgstr "ハンドラー: 変更時に実行する操作"

#: ../../rst/playbook_guide/playbooks_handlers.rst:6
msgid "Sometimes you want a task to run only when a change is made on a machine. For example, you may want to restart a service if a task updates the configuration of that service, but not if the configuration is unchanged. Ansible uses handlers to address this use case. Handlers are tasks that only run when notified."
msgstr "マシンに変更が加えられたときにのみ、タスクを実行したい場合があります。たとえば、タスクがサービスの設定を更新した場合はサービスを再起動し、設定が変更していない場合には再起動しないようにしたい場合があります。Ansible では、このようなユースケースに対応するためにハンドラーを使用しています。ハンドラーは、通知されたときにのみ実行するタスクです。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:12
msgid "Handler example"
msgstr "ハンドラーの例"

#: ../../rst/playbook_guide/playbooks_handlers.rst:14
msgid "This playbook, ``verify-apache.yml``, contains a single play with a handler."
msgstr "この Playbook ``verify-apache.yml`` には、ハンドラーを使用した 1 つのプレイが含まれます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:49
msgid "In this example playbook, the Apache server is restarted by the handler after all tasks complete in the play."
msgstr "この Playbook の例では、プレイのすべてのタスクが完了した後、Apache サーバーはハンドラーによって再起動されます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:53
#: ../../rst/playbook_guide/playbooks_reuse.rst:136
msgid "Notifying handlers"
msgstr "ハンドラーの通知"

#: ../../rst/playbook_guide/playbooks_handlers.rst:55
msgid "Tasks can instruct one or more handlers to execute using the ``notify`` keyword. The ``notify`` keyword can be applied to a task and accepts a list of handler names that  are notified on a task change. Alternately, a string containing a single handler name can be supplied as well. The following example demonstrates how multiple handlers can be notified by a single task:"
msgstr "タスクは、``notify`` キーワードを使用して実行するハンドラーを 1 つまたは複数指示できます。``notify`` キーワードはタスクに適用され、タスクの変更時に通知されるハンドラー名の一覧を受け入れることができます。あるいは、1 つのハンドラー名が含まれる文字列を指定することもできます。以下の例は、1 つのタスクで複数のハンドラーに通知する方法を示しています。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:79
msgid "In the above example the handlers are executed on task change in the following order: ``Restart memcached``, ``Restart apache``. Handlers are executed in the order they are defined in the ``handlers`` section, not in the order listed in the ``notify`` statement. Notifying the same handler multiple times will result in executing the handler only once regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts."
msgstr "上記の例では、ハンドラーはタスクの変更時に ``Restart memcached``、``Restart apache`` の順で実行されます。ハンドラーは、``notify`` ステートメントにリストされている順番ではなく、``handlers`` セクションで定義された順序で実行されます。同じハンドラーを複数回指定しても、通知するタスクの数に関係なくハンドラーは 1 回しか実行されません。たとえば、複数のタスクが設定ファイルを更新し、Apache を再起動するようにハンドラーに通知した場合、Ansible は不要な再起動を防ぐために Apache に 1 度だけバウンスします。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:83
msgid "Naming handlers"
msgstr "ハンドラーの命名"

#: ../../rst/playbook_guide/playbooks_handlers.rst:85
msgid "Handlers must be named in order for tasks to be able to notify them using the ``notify`` keyword."
msgstr "タスクが``notify`` キーワードを使用して通知できるように、ハンドラーに名前を付ける必要があります。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:87
msgid "Alternately, handlers can utilize the ``listen`` keyword. Using this handler keyword, handlers can listen on topics that can group multiple handlers as follows:"
msgstr "あるいは、ハンドラーは ``listen`` キーワードを使用できます。このハンドラーキーワードを使用すると、ハンドラーは以下のように複数のハンドラーをグループ化できるトピックをリッスンできます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:109
msgid "Notifying the ``restart web services`` topic results in executing all handlers listening to that topic regardless of how those handlers are named."
msgstr "``restart web services`` トピックに通知すると、ハンドラーの名前が何であるかに関わらず、そのトピックをリッスンするすべてのハンドラーが実行されます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:111
msgid "This use makes it much easier to trigger multiple handlers. It also decouples handlers from their names, making it easier to share handlers among playbooks and roles (especially when using third-party roles from a shared source such as Ansible Galaxy)."
msgstr "これにより、複数のハンドラーを簡単に発生させることができます。また、ハンドラーを名前から切り離すことで、Playbook やロール間でのハンドラーの共有が容易になります (特に Ansible Galaxy のような共有ソースからサードパーティーのロールを使用する場合)。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:113
msgid "Each handler should have a globally unique name. If multiple handlers are defined with the same name, only the last one defined is notified with ``notify``, effectively shadowing all of the previous handlers with the same name. Alternately handlers sharing the same name can all be notified and executed if they listen on the same topic by notifying that topic."
msgstr "各ハンドラーにはグローバルに一意な名前を付ける必要があります。複数のハンドラーが同じ名前で定義されている場合、最後に定義されたハンドラーのみが ``notify`` で通知され、実質的に同じ名前のそれまでのすべてのハンドラーは保護されます。あるいは、同じ名前を共有するハンドラーが同じトピックをリッスンする場合は、そのトピックに通知することですべてのハンドラーが通知され、実行されます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:115
msgid "There is only one global scope for handlers (handler names and listen topics) regardless of where the handlers are defined. This also includes handlers defined in roles."
msgstr "ハンドラーが定義されている場所に関係なく、ハンドラー（ハンドラー名およびリッスントピック）には 1 つのグローバルスコープがあります。これには、ロールで定義されたハンドラーも含まれます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:119
msgid "Controlling when handlers run"
msgstr "ハンドラーの実行時の制御"

#: ../../rst/playbook_guide/playbooks_handlers.rst:121
msgid "By default, handlers run after all the tasks in a particular play have been completed. Notified handlers are executed automatically after each of the following sections, in the following order: ``pre_tasks``, ``roles``/``tasks`` and ``post_tasks``. This approach is efficient, because the handler only runs once, regardless of how many tasks notify it. For example, if multiple tasks update a configuration file and notify a handler to restart Apache, Ansible only bounces Apache once to avoid unnecessary restarts."
msgstr "デフォルトでは、ハンドラーは、特定のプレイのすべてのタスクが完了した後に実行されます。通知されたハンドラーは、``pre_tasks``、``roles``/``tasks``、および ``post_tasks``のセクションの順に自動的に実行されます。ハンドラーは、いくつのタスクが通知したかに関わらず、一度だけ実行するため、このアプローチは効率的です。たとえば、複数のタスクが設定ファイルを更新し、ハンドラーに Apache の再起動を通知した場合、Ansible は Apache に 1 回だけバウンスさせ、不要な再起動を回避します。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:123
msgid "If you need handlers to run before the end of the play, add a task to flush them using the :ref:`meta module <meta_module>`, which executes Ansible actions:"
msgstr "プレイの終了前にハンドラーを実行する必要がある場合は、Ansible アクションを実行する :ref:`meta module <meta_module>` を使用して、タスクをフラッシュします。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:137
msgid "The ``meta: flush_handlers`` task triggers any handlers that have been notified at that point in the play."
msgstr "``meta: flush_handlers`` タスクは、プレイのその時点で通知されたハンドラーを発生させます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:139
msgid "Once handlers are executed, either automatically after each mentioned section or manually by the ``flush_handlers`` meta task, they can be notified and run again in later sections of the play."
msgstr "指定された各セクションの後に自動的に、または ``flush_handlers`` メタタスクで手動でハンドラーが実行されると、プレイの後のセクションで再度通知して実行することができます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:143
msgid "Using variables with handlers"
msgstr "ハンドラーでの変数の使用"

#: ../../rst/playbook_guide/playbooks_handlers.rst:145
msgid "You may want your Ansible handlers to use variables. For example, if the name of a service varies slightly by distribution, you want your output to show the exact name of the restarted service for each target machine. Avoid placing variables in the name of the handler. Since handler names are templated early on, Ansible may not have a value available for a handler name like this:"
msgstr "Ansible ハンドラーで変数を使用したい場合があります。たとえば、サービスの名前がディストリビューションによってわずかに異なる場合に、ターゲットマシンごとに再起動したサービスの正確な名前を出力するとします。ハンドラーの名前に変数を入れないでください。ハンドラー名は初期段階でテンプレート化されているため、Ansible では次のようなハンドラー名に利用できる値がない場合があります。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:153
msgid "If the variable used in the handler name is not available, the entire play fails. Changing that variable mid-play **will not** result in newly created handler."
msgstr "ハンドラー名で使用される変数が利用できない場合は、プレイ全体が失敗します。変数 mid-play を変更すると、新しく作成されたハンドラーが **作成されません**。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:155
msgid "Instead, place variables in the task parameters of your handler. You can load the values using ``include_vars`` like this:"
msgstr "代わりに、ハンドラーのタスクパラメーターに変数を配置します。以下のように ``include_vars`` を使用して、値を読み込むことができます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:169
msgid "While handler names can contain a template, ``listen`` topics cannot."
msgstr "ハンドラー名にはテンプレートを含めることができますが、``listen`` トピックにはテンプレートを含めることはできません。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:173
msgid "Handlers in roles"
msgstr "ロールのハンドラー"

#: ../../rst/playbook_guide/playbooks_handlers.rst:175
msgid "Handlers from roles are not just contained in their roles but rather inserted into global scope with all other handlers from a play. As such they can be used outside of the role they are defined in. It also means that their name can conflict with handlers from outside the role. To ensure that a handler from a role is notified as opposed to one from outside the role with the same name, notify the handler by using its name in the following form: ``role_name : handler_name``."
msgstr "ロールからのハンドラーはそのロール内に含まれるだけでなく、プレイからの他のすべてのハンドラーと共にグローバルスコープに挿入されます。したがって、ハンドラーは定義されたロール外で使用できます。また、ハンドラーの名前がロール外からのハンドラーと競合する可能性があることも意味します。同じ名前を持つロール外からのハンドラーではなく、ロールからのハンドラーが通知されるようにするには、``role_name : handler_name`` のフォームで名前を使用してハンドラーに通知します。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:177
msgid "Handlers notified within the ``roles`` section are automatically flushed at the end of the ``tasks`` section, but before any ``tasks`` handlers."
msgstr "``roles``セクション内で通知されるハンドラーは、``tasks`` セクションの最後に、ただし ``tasks`` ハンドラーの前に自動的にフラッシュされます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:181
msgid "Includes and imports in handlers"
msgstr "ハンドラーのインクルードおよびインポート"

#: ../../rst/playbook_guide/playbooks_handlers.rst:182
msgid "Notifying a dynamic include such as ``include_task`` as a handler results in executing all tasks from within the include. It is not possible to notify a handler defined inside a dynamic include."
msgstr "ハンドラーとして ``include_task`` などの動的インクルードに通知すると、インクルード内からのすべてのタスクが実行されます。動的インクルード内で定義されたハンドラーに通知することはできません。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:184
msgid "Having a static include such as ``import_task`` as a handler results in that handler being effectively rewritten by handlers from within that import before the play execution. A static include itself cannot be notified; the tasks from within that include, on the other hand, can be notified individually."
msgstr "ハンドラーとして ``import_task`` などの静的インクルードを指定すると、実質的にそのハンドラーはプレイの実行前にそのインポート内からのハンドラーにより書き換えられます。静インクルード自体には通知できず、一方、そのインクルード内からのタスクには個別に通知できます。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:188
msgid "Meta tasks as handlers"
msgstr "ハンドラーとしてのメタタスク"

#: ../../rst/playbook_guide/playbooks_handlers.rst:190
msgid "Since Ansible 2.14 :ref:`meta tasks <ansible_collections.ansible.builtin.meta_module>` are allowed to be used and notified as handlers. Note that however ``flush_handlers`` cannot be used as a handler to prevent unexpected behavior."
msgstr "Ansible 2.14 以降は、:ref:`meta tasks <ansible_collections.ansible.builtin.meta_module>` をハンドラーとして使用して、通知できます。ただし、``flush_handlers`` は、予期しない動作を回避するためにハンドラーとして使用できません。"

#: ../../rst/playbook_guide/playbooks_handlers.rst:194
msgid "Limitations"
msgstr "制限事項"

#: ../../rst/playbook_guide/playbooks_handlers.rst:196
msgid "A handler cannot run ``import_role`` or ``include_role``."
msgstr "ハンドラーは ``import_role`` または ``include_role`` を実行できません。"

#: ../../rst/playbook_guide/playbooks_intro.rst:6
msgid "Ansible playbooks"
msgstr "Ansible Playbook"

#: ../../rst/playbook_guide/playbooks_intro.rst:8
msgid "Ansible Playbooks offer a repeatable, re-usable, simple configuration management and multi-machine deployment system, one that is well suited to deploying complex applications. If you need to execute a task with Ansible more than once, write a playbook and put it under source control. Then you can use the playbook to push out new configuration or confirm the configuration of remote systems. The playbooks in the `ansible-examples repository <https://github.com/ansible/ansible-examples>`_ illustrate many useful techniques. You may want to look at these in another tab as you read the documentation."
msgstr "Ansible Playbook は、繰り返し使用可能で、再利用可能なシンプルな構成管理および複数マシンのデプロイメントシステムであり、複雑なアプリケーションのデプロイメントに適しています。Ansible で複数回タスクを実行する必要がある場合は、Playbook を作成してソースコントロール下に置きます。その後、Playbook を使用して、新しい設定をプッシュアウトしたり、リモートシステムの設定を確認したりすることができます。`ansible-examples リポジトリー <https://github.com/ansible/ansible-examples>`_ の Playbook には、多くの便利なテクニックが紹介されています。ドキュメントを読みながら、これらを別のタブで見てみるのもいいかもしれません。"

#: ../../rst/playbook_guide/playbooks_intro.rst:10
msgid "Playbooks can:"
msgstr "Playbook は、以下のことができます。"

#: ../../rst/playbook_guide/playbooks_intro.rst:12
msgid "declare configurations"
msgstr "宣言設定"

#: ../../rst/playbook_guide/playbooks_intro.rst:13
msgid "orchestrate steps of any manual ordered process, on multiple sets of machines, in a defined order"
msgstr "複数のマシンセットで、手動で順序付けされたプロセスの手順を定義された順序で編成します。"

#: ../../rst/playbook_guide/playbooks_intro.rst:14
msgid "launch tasks synchronously or :ref:`asynchronously <playbooks_async>`"
msgstr "タスクを同期または :ref:`非同期 <playbooks_async>` で起動"

#: ../../rst/playbook_guide/playbooks_intro.rst:22
msgid "Playbook syntax"
msgstr "Playbook 構文"

#: ../../rst/playbook_guide/playbooks_intro.rst:24
msgid "Playbooks are expressed in YAML format with a minimum of syntax. If you are not familiar with YAML, look at our overview of :ref:`yaml_syntax` and consider installing an add-on for your text editor (see :ref:`other_tools_and_programs`) to help you write clean YAML syntax in your playbooks."
msgstr "Playbook は最小限の構文で YAML 形式で表現されます。YAML に慣れていない方は、:ref:`yaml_syntax` の概要を参照してください。また、Playbook にきれいな YAML 構文を書くために、テキストエディター用のアドオンのインストールを検討してください (「:ref:`other_tools_and_programs`」を参照)。"

#: ../../rst/playbook_guide/playbooks_intro.rst:26
msgid "A playbook is composed of one or more 'plays' in an ordered list. The terms 'playbook' and 'play' are sports analogies. Each play executes part of the overall goal of the playbook, running one or more tasks. Each task calls an Ansible module."
msgstr "Playbook は、1 つまたは複数の「プレイ」を順番に並べたものです。「Playbook」と「プレイ」という言葉は、スポーツに例えられています。各プレイは、Playbook の全体的な目標の一部を実行し、1 つまたは複数のタスクを実行します。各タスクは、Ansible モジュールを呼び出します。"

#: ../../rst/playbook_guide/playbooks_intro.rst:29
msgid "Playbook execution"
msgstr "Playbook 実行"

#: ../../rst/playbook_guide/playbooks_intro.rst:31
msgid "A playbook runs in order from top to bottom. Within each play, tasks also run in order from top to bottom. Playbooks with multiple 'plays' can orchestrate multi-machine deployments, running one play on your webservers, then another play on your database servers, then a third play on your network infrastructure, and so on. At a minimum, each play defines two things:"
msgstr "Playbook は、上から下に向かって順番に実行されます。各プレイの中では、タスクも上から下の順に実行されます。複数の「プレイ」を持つ Playbook では、複数のマシンのデプロイメントを編成することができます。あるプレイを Web サーバーで実行した後、別のプレイをデータベースサーバーで実行し、さらに 3 つ目のプレイをネットワークインフラストラクチャーで実行するといった具合です。最低限、各プレイは 2 つのことを定義します。"

#: ../../rst/playbook_guide/playbooks_intro.rst:33
msgid "the managed nodes to target, using a :ref:`pattern <intro_patterns>`"
msgstr ":ref:`pattern <intro_patterns>` を使用する管理ノードが対象である"

#: ../../rst/playbook_guide/playbooks_intro.rst:34
msgid "at least one task to execute"
msgstr "実行すべき 1 つ以上のタスク"

#: ../../rst/playbook_guide/playbooks_intro.rst:38
msgid "In Ansible 2.10 and later, we recommend you use the fully-qualified collection name in your playbooks to ensure the correct module is selected, because multiple collections can contain modules with the same name (for example, ``user``). See :ref:`collections_using_playbook`."
msgstr "Ansible 2.10 以降では、複数のコレクションに同じ名前のモジュールが含まれていることがあるため (例: ``user``)、正しいモジュールが選択されるように、Playbook で完全修飾コレクション名を使用することが推奨されます。「:ref:`collections_using_playbook`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_intro.rst:40
msgid "In this example, the first play targets the web servers; the second play targets the database servers."
msgstr "この例では、第 1 のプレイは Web サーバーを対象とし、第 2 のプレイはデータベースサーバーを対象としています。"

#: ../../rst/playbook_guide/playbooks_intro.rst:73
msgid "Your playbook can include more than just a hosts line and tasks. For example, the playbook above sets a ``remote_user`` for each play. This is the user account for the SSH connection. You can add other :ref:`playbook_keywords` at the playbook, play, or task level to influence how Ansible behaves. Playbook keywords can control the :ref:`connection plugin <connection_plugins>`, whether to use :ref:`privilege escalation <become>`, how to handle errors, and more. To support a variety of environments, Ansible lets you set many of these parameters as command-line flags, in your Ansible configuration, or in your inventory. Learning the :ref:`precedence rules <general_precedence_rules>` for these sources of data will help you as you expand your Ansible ecosystem."
msgstr "Playbook には、ホストラインとタスク以外の情報も含めることができます。たとえば、上記の Playbook では、各プレイに ``remote_user`` を設定しています。これは、SSH 接続用のユーザーアカウントです。Playbook、プレイ、またはタスクレベルで他の :ref:`playbook_keywords` を追加して、Ansible の動作に影響を与えることができます。Playbook のキーワードでは、:ref:`connection プラグイン <connection_plugins>` で、:ref:`特権昇格 <become>` を使用するかどうか、エラーをどのように処理するかなどを制御できます。さまざまな環境に対応するため、Ansible では、これらのパラメーターの多くをコマンドラインフラグ、Ansible の構成、またはインベントリーで設定することができます。これらのデータソースの :ref:`優先順位のルール <general_precedence_rules>` を学ぶことは、Ansible のエコシステムを拡張する際に役立ちます。"

#: ../../rst/playbook_guide/playbooks_intro.rst:78
msgid "Task execution"
msgstr "タスクの実行"

#: ../../rst/playbook_guide/playbooks_intro.rst:80
msgid "By default, Ansible executes each task in order, one at a time, against all machines matched by the host pattern. Each task executes a module with specific arguments. When a task has executed on all target machines, Ansible moves on to the next task. You can use :ref:`strategies <playbooks_strategies>` to change this default behavior. Within each play, Ansible applies the same task directives to all hosts. If a task fails on a host, Ansible takes that host out of the rotation for the rest of the playbook."
msgstr "デフォルトでは、Ansible は、ホストパターンに一致するすべてのマシンに対して、各タスクを 1 つずつ順番に実行します。各タスクは、特定の引数を持つモジュールを実行します。タスクがすべてのターゲットマシンで実行すると、Ansible は次のタスクに移ります。このデフォルトの動作を変更するには、:ref:`ストラテジー <playbooks_strategies>` を使用します。各プレイの中で、Ansible は同じタスクディレクティブをすべてのホストに適用します。あるホストでタスクが失敗した場合、Ansible はそのホストを Playbook の残りの部分のローテーションから外します。"

#: ../../rst/playbook_guide/playbooks_intro.rst:82
msgid "When you run a playbook, Ansible returns information about connections, the ``name`` lines of all your plays and tasks, whether each task has succeeded or failed on each machine, and whether each task has made a change on each machine. At the bottom of the playbook execution, Ansible provides a summary of the nodes that were targeted and how they performed. General failures and fatal \"unreachable\" communication attempts are kept separate in the counts."
msgstr "Playbook を実行すると、Ansible は接続に関する情報、すべてのプレイとタスクの ``name`` 行、各タスクが各マシンで成功したか失敗したか、および各タスクが各マシンで変更を行ったかどうかを返します。Playbook の実行の最後に、Ansible は、対象となったノードとそのパフォーマンスの概要を表示します。一般的な失敗と致命的な「到達不能」の通信試行は、カウントの中で分けて表示されます。"

#: ../../rst/playbook_guide/playbooks_intro.rst:87
msgid "Desired state and 'idempotency'"
msgstr "希望の状態および「冪等性」"

#: ../../rst/playbook_guide/playbooks_intro.rst:89
msgid "Most Ansible modules check whether the desired final state has already been achieved, and exit without performing any actions if that state has been achieved, so that repeating the task does not change the final state. Modules that behave this way are often called 'idempotent.' Whether you run a playbook once, or multiple times, the outcome should be the same. However, not all playbooks and not all modules behave this way. If you are unsure, test your playbooks in a sandbox environment before running them multiple times in production."
msgstr "ほとんどの Ansible モジュールは、目的の最終状態がすでに達成されているかどうかを確認し、その状態が達成されている場合は何も実行せずに終了するため、タスクを繰り返しても最終状態は変わりません。このような動作をするモジュールは、しばしば「冪等性」と呼ばれます。Playbook を 1 回だけ実行しても、複数回実行しても、結果は同じになるはずです。しかし、すべての Playbook やすべてのモジュールがこのように動作するわけではありません。不安な場合は、実稼働環境で Playbook を複数回実行する前に、サンドボックス環境で Playbook をテストしてください。"

#: ../../rst/playbook_guide/playbooks_intro.rst:94
msgid "Running playbooks"
msgstr "Playbook の実行"

#: ../../rst/playbook_guide/playbooks_intro.rst:96
msgid "To run your playbook, use the :ref:`ansible-playbook` command."
msgstr "Playbook を実行するには、:ref:`ansible-playbook` コマンドを使用します。"

#: ../../rst/playbook_guide/playbooks_intro.rst:102
msgid "Use the ``--verbose`` flag when running your playbook to see detailed output from successful modules as well as unsuccessful ones."
msgstr "成功したモジュールと失敗したモジュールの詳細な出力を確認するには、Playbook の実行時に ``--verbose`` フラグを使用します。"

#: ../../rst/playbook_guide/playbooks_intro.rst:107
msgid "Ansible-Pull"
msgstr "ansible-pull"

#: ../../rst/playbook_guide/playbooks_intro.rst:109
msgid "Should you want to invert the architecture of Ansible, so that nodes check in to a central location, instead of pushing configuration out to them, you can."
msgstr "ノードに設定をプッシュするのではなく、Ansible のアーキテクチャーを逆にして、ノードが中央の場所にチェックインするようにしたい場合は、以下を行うことができます。"

#: ../../rst/playbook_guide/playbooks_intro.rst:112
msgid "The ``ansible-pull`` is a small script that will checkout a repo of configuration instructions from git, and then run ``ansible-playbook`` against that content."
msgstr "``ansible-pull`` は小さなスクリプトで、git から設定方法をまとめたリポジトリーをチェックアウトし、その内容に対して ``ansible-playbook`` を実行します。"

#: ../../rst/playbook_guide/playbooks_intro.rst:115
msgid "Assuming you load balance your checkout location, ``ansible-pull`` scales essentially infinitely."
msgstr "チェックアウトの場所を負荷分散する場合、``ansible-pull`` は基本的に無限にスケーリングを行います。"

#: ../../rst/playbook_guide/playbooks_intro.rst:117
msgid "Run ``ansible-pull --help`` for details."
msgstr "詳細は、「``ansible-pull --help``」を参照してください。"

#: ../../rst/playbook_guide/playbooks_intro.rst:119
msgid "There's also a `clever playbook <https://github.com/ansible/ansible-examples/blob/master/language_features/ansible_pull.yml>`_ available to configure ``ansible-pull`` via a crontab from push mode."
msgstr "また、プッシュモードからの crontab で ``ansible-pull`` を設定する際に利用可能な `優れた Playbook <https://github.com/ansible/ansible-examples/blob/master/language_features/ansible_pull.yml>`_ もあります。"

#: ../../rst/playbook_guide/playbooks_intro.rst:122
msgid "Verifying playbooks"
msgstr "Playbook の検証"

#: ../../rst/playbook_guide/playbooks_intro.rst:124
msgid "You may want to verify your playbooks to catch syntax errors and other problems before you run them. The :ref:`ansible-playbook` command offers several options for verification, including ``--check``, ``--diff``, ``--list-hosts``, ``--list-tasks``, and ``--syntax-check``. The :ref:`validate-playbook-tools` describes other tools for validating and testing playbooks."
msgstr "Playbook を実行する前に、構文エラーやその他の問題を検出するために、Playbook を検証したい場合があります。:ref:`ansible-playbook` コマンドには、``--check``、``--diff``、``--list-hosts``、``--list-tasks``、``--syntax-check`` など、検証のためのオプションが用意されています。「:ref:`validate-playbook-tools`」では、Playbook の検証とテストのための他のツールについて説明しています。"

#: ../../rst/playbook_guide/playbooks_intro.rst:129
msgid "ansible-lint"
msgstr "ansible-lint"

#: ../../rst/playbook_guide/playbooks_intro.rst:131
msgid "You can use `ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_ for detailed, Ansible-specific feedback on your playbooks before you execute them. For example, if you run ``ansible-lint`` on the playbook called ``verify-apache.yml`` near the top of this page, you should get the following results:"
msgstr "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_ を使用すると、Playbook を実行する前に、Playbook に対する Ansible 固有の詳細なフィードバックを得ることができます。たとえば、このページの上位にある ``verify-apache.yml`` という Playbook に対して ``ansible-lint`` を実行すると、以下のような結果が得られます。"

#: ../../rst/playbook_guide/playbooks_intro.rst:140
msgid "The `ansible-lint default rules <https://docs.ansible.com/ansible-lint/rules/default_rules.html>`_ page describes each error. For ``[403]``, the recommended fix is to change ``state: latest`` to ``state: present`` in the playbook."
msgstr "`ansible-lint デフォルトルール <https://docs.ansible.com/ansible-lint/rules/default_rules.html>`_ ページには、各エラーについて説明しています。``[403]`` については、Playbook で ``state: latest`` を ``state: present`` に変更することが推奨されます。"

#: ../../rst/playbook_guide/playbooks_intro.rst:144
msgid "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_"
msgstr "`ansible-lint <https://docs.ansible.com/ansible-lint/index.html>`_"

#: ../../rst/playbook_guide/playbooks_intro.rst:145
msgid "Learn how to test Ansible Playbooks syntax"
msgstr "Ansible Playbook 構文のテスト方法について"

#: ../../rst/playbook_guide/playbooks_intro.rst:146
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:592
msgid ":ref:`yaml_syntax`"
msgstr ":ref:`yaml_syntax`"

#: ../../rst/playbook_guide/playbooks_intro.rst:147
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:593
msgid "Learn about YAML syntax"
msgstr "YAML 構文について"

#: ../../rst/playbook_guide/playbooks_intro.rst:149
msgid "Tips for managing playbooks in the real world"
msgstr "実際の Playbook の管理に関するさまざまなヒント"

#: ../../rst/playbook_guide/playbooks_intro.rst:150
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:606
msgid ":ref:`list_of_collections`"
msgstr ":ref:`list_of_collections`"

#: ../../rst/playbook_guide/playbooks_intro.rst:151
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:607
msgid "Browse existing collections, modules, and plugins"
msgstr "既存のコレクション、モジュール、およびプラグインの閲覧"

#: ../../rst/playbook_guide/playbooks_intro.rst:152
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:608
msgid ":ref:`developing_modules`"
msgstr ":ref:`developing_modules`"

#: ../../rst/playbook_guide/playbooks_intro.rst:153
msgid "Learn to extend Ansible by writing your own modules"
msgstr "独自のモジュールを作成して Ansible を拡張する方法について"

#: ../../rst/playbook_guide/playbooks_intro.rst:154
msgid ":ref:`intro_patterns`"
msgstr ":ref:`intro_patterns`"

#: ../../rst/playbook_guide/playbooks_intro.rst:155
msgid "Learn about how to select hosts"
msgstr "ホストの選択方法について"

#: ../../rst/playbook_guide/playbooks_intro.rst:156
msgid "`GitHub examples directory <https://github.com/ansible/ansible-examples>`_"
msgstr "`GitHub examples directory <https://github.com/ansible/ansible-examples>`_"

#: ../../rst/playbook_guide/playbooks_intro.rst:157
msgid "Complete end-to-end playbook examples"
msgstr "完全なエンドツーエンド Playbook の例"

#: ../../rst/playbook_guide/playbooks_intro.rst:158
#: ../../rst/playbook_guide/playbooks_reuse.rst:225
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:612
msgid "`Mailing List <https://groups.google.com/group/ansible-project>`_"
msgstr "`Mailing List <https://groups.google.com/group/ansible-project>`_"

#: ../../rst/playbook_guide/playbooks_intro.rst:159
#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:774
#: ../../rst/playbook_guide/playbooks_reuse.rst:226
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:613
msgid "Questions? Help? Ideas?  Stop by the list on Google Groups"
msgstr "ご質問はございますか。サポートが必要ですか。ご提案はございますか。Google グループの一覧をご覧ください。"

#: ../../rst/playbook_guide/playbooks_lookups.rst:5
msgid "Lookups"
msgstr "ルックアップ (lookup)"

#: ../../rst/playbook_guide/playbooks_lookups.rst:7
msgid "Lookup plugins retrieve data from outside sources such as files, databases, key/value stores, APIs, and other services. Like all templating, lookups execute and are evaluated on the Ansible control machine. Ansible makes the data returned by a lookup plugin available using the standard templating system. Before Ansible 2.5, lookups were mostly used indirectly in ``with_<lookup>`` constructs for looping. Starting with Ansible 2.5, lookups are used more explicitly as part of Jinja2 expressions fed into the ``loop`` keyword."
msgstr "lookup プラグインは、ファイル、データベース、キー/値ストア、API、その他のサービスなどの外部ソースからデータを取得します。すべてのテンプレート化と同様に、lookup は Ansible のコントロールマシン上で実行され、評価されます。Ansible では、lookup プラグインが返すデータを、標準のテンプレートシステムを使用して利用できるようにします。Ansible 2.5 以前、lookup はほとんどの場合、``with_<lookup>`` のループのための構成で間接的に使用されていました。Ansible 2.5 以降、lookup は Jinja2 の式の一部として、より明示的に使用されるようになり、``loop`` キーワードに供給されるようになりました。"

#: ../../rst/playbook_guide/playbooks_lookups.rst:12
msgid "Using lookups in variables"
msgstr "変数での lookup の使用"

#: ../../rst/playbook_guide/playbooks_lookups.rst:14
msgid "You can populate variables using lookups. Ansible evaluates the value each time it is executed in a task (or template)."
msgstr "lookup を使用して変数を設定することができます。Ansible は、タスク (またはテンプレート) で実行されるたびに値を評価します。"

#: ../../rst/playbook_guide/playbooks_lookups.rst:24
msgid "For more details and a list of lookup plugins in ansible-core, see :ref:`plugins_lookup`. You may also find lookup plugins in collections. You can review a list of lookup plugins installed on your control machine with the command ``ansible-doc -l -t lookup``."
msgstr "ansible-core の lookup プラグインの詳細と一覧は、「:ref:`plugins_lookup`」を参照してください。また、lookup プラグインはコレクションにも含まれています。コントロールマシンにインストールされている lookup プラグインのリストは、``ansible-doc -l -t lookup`` コマンドで確認できます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:5
msgid "Loops"
msgstr "ループ"

#: ../../rst/playbook_guide/playbooks_loops.rst:7
msgid "Ansible offers the ``loop``, ``with_<lookup>``, and ``until`` keywords to execute a task multiple times. Examples of commonly-used loops include changing ownership on several files and/or directories with the :ref:`file module <file_module>`, creating multiple users with the :ref:`user module <user_module>`, and repeating a polling step until a certain result is reached."
msgstr "Ansible には、``loop``、``with_<lookup>``、および ``until`` というキーワードがあり、1 つのタスクを複数回実行することができます。一般的に使用されるループの例としては、:ref:`file module <file_module>` で複数のファイルやディレクトリーの所有権を変更する、:ref:`user module <user_module>` で複数のユーザーを作成する、特定の結果が得られるまでポーリングステップを繰り返すなどがあります。"

#: ../../rst/playbook_guide/playbooks_loops.rst:11
msgid "We added ``loop`` in Ansible 2.5. It is not yet a full replacement for ``with_<lookup>``, but we recommend it for most use cases."
msgstr "Ansible 2.5 で ``loop`` を追加しました。``with_<lookup>`` は完全に置き換えるものではありませんが、ほとんどのユースケースで推奨されています。"

#: ../../rst/playbook_guide/playbooks_loops.rst:12
msgid "We have not deprecated the use of ``with_<lookup>`` - that syntax will still be valid for the foreseeable future."
msgstr "``with_<lookup>`` の使用は非推奨になっていません。この構文は、今後も有効です。"

#: ../../rst/playbook_guide/playbooks_loops.rst:13
msgid "We are looking to improve ``loop`` syntax - watch this page and the `changelog <https://github.com/ansible/ansible/tree/devel/changelogs>`_ for updates."
msgstr "``loop`` 構文を改善する場合は、このページと `changelog <https://github.com/ansible/ansible/tree/devel/changelogs>`_ で更新を確認します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:19
msgid "Comparing ``loop`` and ``with_*``"
msgstr "``loop`` と ``with_*`` の比較"

#: ../../rst/playbook_guide/playbooks_loops.rst:21
msgid "The ``with_<lookup>`` keywords rely on :ref:`lookup_plugins` - even  ``items`` is a lookup."
msgstr "``with_<lookup>`` キーワードは :ref:`lookup_plugins` に依存し、``items`` も lookup となります。"

#: ../../rst/playbook_guide/playbooks_loops.rst:22
msgid "The ``loop`` keyword is equivalent to ``with_list``, and is the best choice for simple loops."
msgstr "``loop`` キーワードは ``with_list`` と同等であり、単純なループに最適です。"

#: ../../rst/playbook_guide/playbooks_loops.rst:23
msgid "The ``loop`` keyword will not accept a string as input, see :ref:`query_vs_lookup`."
msgstr "``loop`` キーワードは文字列を入力として受け付けません。「:ref:`query_vs_lookup`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_loops.rst:24
msgid "Generally speaking, any use of ``with_*`` covered in :ref:`migrating_to_loop` can be updated to use ``loop``."
msgstr "通常、「:ref:`migrating_to_loop`」で対応している ``with_*`` を使用すると、``loop`` を使用するように更新できます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:25
msgid "Be careful when changing ``with_items`` to ``loop``, as ``with_items`` performed implicit single-level flattening. You may need to use ``flatten(1)`` with ``loop`` to match the exact outcome. For example, to get the same output as:"
msgstr "``with_items`` を ``loop`` に変更する際には、``with_items`` が暗黙の単一レベルのフラット化を行うため注意が必要です。正確な結果を得るためには、``flatten(1)`` と ``loop`` の併用が必要になる可能性があります。たとえば、次と同じ出力を得るには、"

#: ../../rst/playbook_guide/playbooks_loops.rst:34
msgid "you would need"
msgstr "以下が必要です。"

#: ../../rst/playbook_guide/playbooks_loops.rst:40
msgid "Any ``with_*`` statement that requires using ``lookup`` within a loop should not be converted to use the ``loop`` keyword. For example, instead of doing:"
msgstr "ループ内で ``lookup`` を使用する必要のある ``with_*`` 文は、``loop`` キーワードを使用するように変換しないでください。たとえば、代わりに、以下を行います。"

#: ../../rst/playbook_guide/playbooks_loops.rst:46
msgid "it's cleaner to keep"
msgstr "保持する方が見た目がすっきりします。"

#: ../../rst/playbook_guide/playbooks_loops.rst:55
msgid "Standard loops"
msgstr "標準ループ"

#: ../../rst/playbook_guide/playbooks_loops.rst:58
msgid "Iterating over a simple list"
msgstr "シンプルなリストでの反復"

#: ../../rst/playbook_guide/playbooks_loops.rst:60
msgid "Repeated tasks can be written as standard loops over a simple list of strings. You can define the list directly in the task."
msgstr "繰り返されるタスクは、文字列の単純なリストに対する標準的なループとして記述できます。このリストはタスクの中で直接定義できます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:73
msgid "You can define the list in a variables file, or in the 'vars' section of your play, then refer to the name of the list in the task."
msgstr "変数ファイルでリストを定義するか、プレイの「vars」セクションで、タスク内のリストの名前を参照します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:79
msgid "Either of these examples would be the equivalent of"
msgstr "これらの例のいずれも、以下と同等です。"

#: ../../rst/playbook_guide/playbooks_loops.rst:95
msgid "You can pass a list directly to a parameter for some plugins. Most of the packaging modules, like :ref:`yum <yum_module>` and :ref:`apt <apt_module>`, have this capability. When available, passing the list to a parameter is better than looping over the task. For example"
msgstr "いくつかのプラグインでは、パラメーターにリストを直接渡すことができます。:ref:`yum <yum_module>` や :ref:`apt <apt_module>` など、ほとんどのパッケージングモジュールにこの機能があります。利用できる場合は、リストをパラメーターに渡す方が、タスクをループさせるよりも良いでしょう。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:110
msgid "Check the :ref:`module documentation <modules_by_category>` to see if you can pass a list to any particular module's parameter(s)."
msgstr ":ref:`モジュールのドキュメント <modules_by_category>` で、特定モジュールのパラメーターにリストを渡すことができるかどうかを確認します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:113
msgid "Iterating over a list of hashes"
msgstr "ハッシュリストでの反復"

#: ../../rst/playbook_guide/playbooks_loops.rst:115
msgid "If you have a list of hashes, you can reference subkeys in a loop. For example:"
msgstr "ハッシュリストがある場合は、ループでサブキーを参照できます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:128
msgid "When combining :ref:`conditionals <playbooks_conditionals>` with a loop, the ``when:`` statement is processed separately for each item. See :ref:`the_when_statement` for examples."
msgstr ":ref:`conditionals <playbooks_conditionals>` とループを組み合わせると、``when:`` 文は各項目について個別に処理されます。例は「:ref:`the_when_statement`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_loops.rst:132
msgid "Iterating over a dictionary"
msgstr "ディクショナリーでの反復"

#: ../../rst/playbook_guide/playbooks_loops.rst:134
msgid "To loop over a dict, use the  :ref:`dict2items <dict_filter>`:"
msgstr "ディクショナリーでループするには、:ref:`dict2items <dict_filter>` を使用します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:147
msgid "Here, we are iterating over `tag_data` and printing the key and the value from it."
msgstr "ここでは、`tag_data` を繰り返し処理し、キーと値を出力します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:150
msgid "Registering variables with a loop"
msgstr "ループによる変数の登録"

#: ../../rst/playbook_guide/playbooks_loops.rst:152
msgid "You can register the output of a loop as a variable. For example"
msgstr "ループの出力を変数として登録できます。たとえば、次のようになります。"

#: ../../rst/playbook_guide/playbooks_loops.rst:163
msgid "When you use ``register`` with a loop, the data structure placed in the variable will contain a ``results`` attribute that is a list of all responses from the module. This differs from the data structure returned when using ``register`` without a loop."
msgstr "``register`` をループで使用すると、変数に配置されるデータ構造には、モジュールからのすべての応答のリストである ``results`` 属性が含まれます。これは、``register`` をループなしで使用したときに返されるデータ構造とは異なります。"

#: ../../rst/playbook_guide/playbooks_loops.rst:204
msgid "Subsequent loops over the registered variable to inspect the results may look like"
msgstr "登録済みの変数で後続のループを実行して結果を検査すると、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_loops.rst:214
msgid "During iteration, the result of the current item will be placed in the variable."
msgstr "反復時に、現在の項目の結果は変数に配置されます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:229
msgid "Complex loops"
msgstr "複雑なループ"

#: ../../rst/playbook_guide/playbooks_loops.rst:232
msgid "Iterating over nested lists"
msgstr "入れ子のリストでの反復"

#: ../../rst/playbook_guide/playbooks_loops.rst:234
msgid "You can use Jinja2 expressions to iterate over complex lists. For example, a loop can combine nested lists."
msgstr "Jinja2 の式を使用して、複雑なリストを繰り返し処理することができます。たとえば、ループは入れ子になったリストを組み合わせることができます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:250
msgid "Retrying a task until a condition is met"
msgstr "条件が満たされるまでタスクの再試行"

#: ../../rst/playbook_guide/playbooks_loops.rst:254
msgid "You can use the ``until`` keyword to retry a task until a certain condition is met. Here's an example:"
msgstr "``until`` キーワードを使用すると、ある条件が満たされるまでタスクを再試行することができます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:265
msgid "This task runs up to 5 times with a delay of 10 seconds between each attempt. If the result of any attempt has \"all systems go\" in its stdout, the task succeeds. The default value for \"retries\" is 3 and \"delay\" is 5."
msgstr "このタスクは、各試行の間に 10 秒の遅延を置いて最大 5 回実行される。試行の結果、標準出力に「all systems go」と表示されていれば、タスクは成功です。「retries (再試行)」のデフォルト値は 3、「delay (遅延)」は 5 です。"

#: ../../rst/playbook_guide/playbooks_loops.rst:267
msgid "To see the results of individual retries, run the play with ``-vv``."
msgstr "個別の再試行の結果を表示するには、``-vv`` でプレイを実行します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:269
msgid "When you run a task with ``until`` and register the result as a variable, the registered variable will include a key called \"attempts\", which records the number of the retries for the task."
msgstr "``until`` を使用してタスクを実行し、結果を変数として登録する場合は、登録済み変数には「attempts」と呼ばれる鍵が含まれ、タスクの再試行回数を記録します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:271
msgid "You must set the ``until`` parameter if you want a task to retry. If ``until`` is not defined, the value for the ``retries`` parameter is forced to 1."
msgstr "タスクが再試行するには、``until`` パラメーターを設定する必要があります。``until`` が定義されていない場合は、``retries`` パラメーターの値が 1 に強制されます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:274
msgid "Looping over inventory"
msgstr "インベントリーのループ"

#: ../../rst/playbook_guide/playbooks_loops.rst:276
msgid "To loop over your inventory, or just a subset of it, you can use a regular ``loop`` with the ``ansible_play_batch`` or ``groups`` variables."
msgstr "インベントリーやその一部だけをループさせるには、通常の ``loop`` に ``ansible_play_batch`` 変数や ``groups`` 変数を加えたものを使用することができます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:290
msgid "There is also a specific lookup plugin ``inventory_hostnames`` that can be used like this"
msgstr "また、以下のような特定の lookup プラグイン ``inventory_hostnames`` も使用できます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:304
msgid "More information on the patterns can be found in :ref:`intro_patterns`."
msgstr "パターンの詳細は、「:ref:`intro_patterns`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_loops.rst:309
msgid "Ensuring list input for ``loop``: using ``query`` rather than ``lookup``"
msgstr "``loop`` のリスト入力の確保: ``lookup`` の代わりに ``query`` を使用"

#: ../../rst/playbook_guide/playbooks_loops.rst:311
msgid "The ``loop`` keyword requires a list as input, but the ``lookup`` keyword returns a string of comma-separated values by default. Ansible 2.5 introduced a new Jinja2 function named :ref:`query <query>` that always returns a list, offering a simpler interface and more predictable output from lookup plugins when using the ``loop`` keyword."
msgstr "``loop`` キーワードは入力としてリストを必要としますが、``lookup`` キーワードはデフォルトでコンマで区切られた値の文字列を返すようになっています。Ansible 2.5 では、:ref:`query <query>` という名前の新しい Jinja2 関数が導入され、常にリストを返すようになりました。これにより、インターフェースがシンプルになり、``loop`` キーワードを使用した場合の lookup プラグインの出力がより予測しやすくなりました。"

#: ../../rst/playbook_guide/playbooks_loops.rst:313
msgid "You can force ``lookup`` to return a list to ``loop`` by using ``wantlist=True``, or you can use ``query`` instead."
msgstr "``wantlist=True`` を使用すれば、``lookup`` がリストを ``loop`` に返すように強制したり、代わりに ``query`` を使用することもできます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:315
msgid "The following two examples do the same thing."
msgstr "以下の2つの例は、同じことをします。"

#: ../../rst/playbook_guide/playbooks_loops.rst:327
msgid "Adding controls to loops"
msgstr "ループへのコントロールの追加"

#: ../../rst/playbook_guide/playbooks_loops.rst:330
msgid "The ``loop_control`` keyword lets you manage your loops in useful ways."
msgstr "``loop_control`` キーワードを使用すると、ループを便利な方法で管理できます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:333
msgid "Limiting loop output with ``label``"
msgstr "``label`` を使用したループ出力の制限"

#: ../../rst/playbook_guide/playbooks_loops.rst:336
msgid "When looping over complex data structures, the console output of your task can be enormous. To limit the displayed output, use the ``label`` directive with ``loop_control``."
msgstr "複雑なデータ構造をループしていると、タスクのコンソール出力が膨大になることがあります。表示される出力を制限するには、``label`` ディレクティブと ``loop_control`` を使用します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:355
msgid "The output of this task will display just the ``name`` field for each ``item`` instead of the entire contents of the multi-line ``{{ item }}`` variable."
msgstr "このタスクの出力には、複数行の ``{{ item }}`` 変数の内容全体ではなく、各 ``item`` の ``name`` フィールドのみが表示されます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:357
msgid "This is for making console output more readable, not protecting sensitive data. If there is sensitive data in ``loop``, set ``no_log: yes`` on the task to prevent disclosure."
msgstr "これはコンソール出力を読みやすくするためのもので、機密データを保護するものではありません。``loop`` に機密データがある場合は、``no_log: yes`` をタスクに設定して漏洩を防ぎます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:360
msgid "Pausing within a loop"
msgstr "ループ内での一時停止"

#: ../../rst/playbook_guide/playbooks_loops.rst:363
msgid "To control the time (in seconds) between the execution of each item in a task loop, use the ``pause`` directive with ``loop_control``."
msgstr "タスクループの各項目の実行間隔を (秒単位) で制御するには、``pause`` で ``loop_control`` ディレクティブを使用します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:379
msgid "Tracking progress through a loop with ``index_var``"
msgstr "``index_var`` のあるループでの進捗の追跡"

#: ../../rst/playbook_guide/playbooks_loops.rst:382
msgid "To keep track of where you are in a loop, use the ``index_var`` directive with ``loop_control``. This directive specifies a variable name to contain the current loop index."
msgstr "ループ内のどこにいるかを把握するには、``loop_control`` とともに ``index_var`` ディレクティブを使用します。このディレクティブは、現在のループのインデックスを格納する変数名を指定します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:396
msgid "`index_var` is 0 indexed."
msgstr "`index_var` は、0 インデックスです。"

#: ../../rst/playbook_guide/playbooks_loops.rst:399
msgid "Defining inner and outer variable names with ``loop_var``"
msgstr "``loop_var`` を使用した内部変数名および外部変数名の定義"

#: ../../rst/playbook_guide/playbooks_loops.rst:402
msgid "You can nest two looping tasks using ``include_tasks``. However, by default Ansible sets the loop variable ``item`` for each loop. This means the inner, nested loop will overwrite the value of ``item`` from the outer loop. You can specify the name of the variable for each loop using ``loop_var`` with ``loop_control``."
msgstr "``include_tasks`` を使用すると、2 つのループタスクを入れ子にすることができます。ただし、Ansible のデフォルトでは、ループごとにループ変数 ``item`` が設定されます。これは、入れ子になった内側のループが、外側のループの ``item`` の値を上書きすることを意味します。``loop_var`` と ``loop_control`` を使用して、各ループの変数名を指定することができます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:425
msgid "If Ansible detects that the current loop is using a variable which has already been defined, it will raise an error to fail the task."
msgstr "定義されている変数を現在のループが使用していることを Ansible が検出すると、タスクが失敗するためにエラーが発生します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:428
msgid "Extended loop variables"
msgstr "拡張ループ変数"

#: ../../rst/playbook_guide/playbooks_loops.rst:431
msgid "As of Ansible 2.8 you can get extended loop information using the ``extended`` option to loop control. This option will expose the following information."
msgstr "Ansible 2.8 では、ループ制御に ``extended`` オプションを使用することで、拡張されたループ情報を得ることができます。このオプションは、以下の情報を公開します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:434
msgid "Variable"
msgstr "変数"

#: ../../rst/playbook_guide/playbooks_loops.rst:434
#: ../../rst/playbook_guide/playbooks_variables.rst:110
msgid "Description"
msgstr "説明"

#: ../../rst/playbook_guide/playbooks_loops.rst:436
msgid "``ansible_loop.allitems``"
msgstr "``ansible_loop.allitems``"

#: ../../rst/playbook_guide/playbooks_loops.rst:436
msgid "The list of all items in the loop"
msgstr "ループ内のすべての項目のリスト"

#: ../../rst/playbook_guide/playbooks_loops.rst:437
msgid "``ansible_loop.index``"
msgstr "``ansible_loop.index``"

#: ../../rst/playbook_guide/playbooks_loops.rst:437
msgid "The current iteration of the loop. (1 indexed)"
msgstr "ループの現在の反復 (1 インデックス化)"

#: ../../rst/playbook_guide/playbooks_loops.rst:438
msgid "``ansible_loop.index0``"
msgstr "``ansible_loop.index0``"

#: ../../rst/playbook_guide/playbooks_loops.rst:438
msgid "The current iteration of the loop. (0 indexed)"
msgstr "ループの現在の反復 (0 インデックス化)"

#: ../../rst/playbook_guide/playbooks_loops.rst:439
msgid "``ansible_loop.revindex``"
msgstr "``ansible_loop.revindex``"

#: ../../rst/playbook_guide/playbooks_loops.rst:439
msgid "The number of iterations from the end of the loop (1 indexed)"
msgstr "ループの最後からの反復回数 (1 インデックス化)"

#: ../../rst/playbook_guide/playbooks_loops.rst:440
msgid "``ansible_loop.revindex0``"
msgstr "``ansible_loop.revindex0``"

#: ../../rst/playbook_guide/playbooks_loops.rst:440
msgid "The number of iterations from the end of the loop (0 indexed)"
msgstr "ループの最後からの反復回数 (0 インデックス化)"

#: ../../rst/playbook_guide/playbooks_loops.rst:441
msgid "``ansible_loop.first``"
msgstr "``ansible_loop.first``"

#: ../../rst/playbook_guide/playbooks_loops.rst:441
msgid "``True`` if first iteration"
msgstr "最初の反復の場合は ``True``"

#: ../../rst/playbook_guide/playbooks_loops.rst:442
msgid "``ansible_loop.last``"
msgstr "``ansible_loop.last``"

#: ../../rst/playbook_guide/playbooks_loops.rst:442
msgid "``True`` if last iteration"
msgstr "最後の反復の場合は ``True``"

#: ../../rst/playbook_guide/playbooks_loops.rst:443
msgid "``ansible_loop.length``"
msgstr "``ansible_loop.length``"

#: ../../rst/playbook_guide/playbooks_loops.rst:443
msgid "The number of items in the loop"
msgstr "ループ内の項目数"

#: ../../rst/playbook_guide/playbooks_loops.rst:444
msgid "``ansible_loop.previtem``"
msgstr "``ansible_loop.previtem``"

#: ../../rst/playbook_guide/playbooks_loops.rst:444
msgid "The item from the previous iteration of the loop. Undefined during the first iteration."
msgstr "ループの前の反復の項目。最初の反復では未定義です。"

#: ../../rst/playbook_guide/playbooks_loops.rst:445
msgid "``ansible_loop.nextitem``"
msgstr "``ansible_loop.nextitem``"

#: ../../rst/playbook_guide/playbooks_loops.rst:445
msgid "The item from the following iteration of the loop. Undefined during the last iteration."
msgstr "ループの次の反復の項目。最初の反復では未定義です。"

#: ../../rst/playbook_guide/playbooks_loops.rst:453
msgid "When using ``loop_control.extended`` more memory will be utilized on the control node. This is a result of ``ansible_loop.allitems`` containing a reference to the full loop data for every loop. When serializing the results for display in callback plugins within the main ansible process, these references may be dereferenced causing memory usage to increase."
msgstr "``loop_control.extended`` を使用すると、制御ノードでより多くのメモリーが使用されます。これは、すべてのループの完全なループデータへの参照が含まれる ``ansible_loop.allitems`` の結果です。メインのAnsibleプロセス内のコールバックプラグインに表示するために結果をシリアル化すると、これらの参照が逆参照され、メモリー使用量が増加する可能性があります。"

#: ../../rst/playbook_guide/playbooks_loops.rst:457
msgid "To disable the ``ansible_loop.allitems`` item, to reduce memory consumption, set ``loop_control.extended_allitems: no``."
msgstr "``ansible_loop.allitems`` 項目を無効にしてメモリー消費を減らすには、``loop_control.extended_allitems: no`` を設定します。"

#: ../../rst/playbook_guide/playbooks_loops.rst:466
msgid "Accessing the name of your loop_var"
msgstr "loop_var の名前へのアクセス"

#: ../../rst/playbook_guide/playbooks_loops.rst:469
msgid "As of Ansible 2.8 you can get the name of the value provided to ``loop_control.loop_var`` using the ``ansible_loop_var`` variable"
msgstr "Ansible 2.8 では、``ansible_loop_var`` 変数を使用して ``loop_control.loop_var`` に提供された値の名前を取得できます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:471
msgid "For role authors, writing roles that allow loops, instead of dictating the required ``loop_var`` value, you can gather the value via the following"
msgstr "ロールの作成者は、必要な ``loop_var`` 値を指定する代わりに、ループを許可するロールを作成することで、次の方法で値を収集できます。"

#: ../../rst/playbook_guide/playbooks_loops.rst:480
msgid "Migrating from with_X to loop"
msgstr "with_X から loop への移行"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:1
msgid "In most cases, loops work best with the ``loop`` keyword instead of ``with_X`` style loops. The ``loop`` syntax is usually best expressed using filters instead of more complex use of ``query`` or ``lookup``."
msgstr "ほとんどの場合、ループは、``with_X`` スタイルのループではなく、``loop`` キーワードで最適に機能します。``loop`` 構文は通常、``query`` や ``lookup`` の複雑な使用ではなく、フィルターを使用して表現できます。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:3
msgid "These examples show how to convert many common ``with_`` style loops to ``loop`` and filters."
msgstr "以下の例では、一般的な ``with_`` スタイルのループを ``loop`` およびフィルターに変換する方法を示しています。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:6
msgid "with_list"
msgstr "with_list"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:8
msgid "``with_list`` is directly replaced by ``loop``."
msgstr "``with_list`` は、直接 ``loop`` に置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:27
msgid "with_items"
msgstr "with_items"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:29
msgid "``with_items`` is replaced by ``loop`` and the ``flatten`` filter."
msgstr "``with_items`` は、``loop`` フィルターおよび ``flatten`` フィルターに置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:44
msgid "with_indexed_items"
msgstr "with_indexed_items"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:46
msgid "``with_indexed_items`` is replaced by ``loop``, the ``flatten`` filter and ``loop_control.index_var``."
msgstr "``with_indexed_items`` は、``loop``、``flatten`` フィルター、および ``loop_control.index_var`` に置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:63
msgid "with_flattened"
msgstr "with_flattened"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:65
msgid "``with_flattened`` is replaced by ``loop`` and the ``flatten`` filter."
msgstr "``with_flattened`` は、``loop`` フィルターおよび ``flatten`` フィルターに置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:80
msgid "with_together"
msgstr "with_together"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:82
msgid "``with_together`` is replaced by ``loop`` and the ``zip`` filter."
msgstr "``with_together`` は、``loop`` フィルターおよび ``zip`` フィルターに置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:98
msgid "Another example with complex data"
msgstr "複雑なデータがある別の例"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:113
msgid "with_dict"
msgstr "with_dict"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:115
msgid "``with_dict`` can be substituted by ``loop`` and either the ``dictsort`` or ``dict2items`` filters."
msgstr "``with_dict`` は、``loop`` フィルターと、``dictsort`` フィルターまたは ``dict2items`` フィルターのいずれかのフィルターに置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:135
msgid "with_sequence"
msgstr "with_sequence"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:137
msgid "``with_sequence`` is replaced by ``loop`` and the ``range`` function, and potentially the ``format`` filter."
msgstr "``with_sequence`` は、``loop`` 関数と ``range`` の関数、そして潜在的には ``format`` フィルターに置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:153
msgid "with_subelements"
msgstr "with_subelements"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:155
msgid "``with_subelements`` is replaced by ``loop`` and the ``subelements`` filter."
msgstr "``with_subelements`` は、``loop`` フィルターおよび ``subelements`` フィルターに置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:172
msgid "with_nested/with_cartesian"
msgstr "with_nested/with_cartesian"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:174
msgid "``with_nested`` and ``with_cartesian`` are replaced by loop and the ``product`` filter."
msgstr "``with_nested`` と``with_cartesian`` は、ループと ``product`` のフィルターに置き換えられました。"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:191
msgid "with_random_choice"
msgstr "with_random_choice"

#: ../../rst/playbook_guide/shared_snippets/with2loop.txt:193
msgid "``with_random_choice`` is replaced by just use of the ``random`` filter, without need of ``loop``."
msgstr "``with_random_choice`` は、``random`` フィルターを使用するだけで、``loop`` を必要とせずに置き換えることができます。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:4
msgid "Module defaults"
msgstr "モジュールのデフォルト"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:6
msgid "If you frequently call the same module with the same arguments, it can be useful to define default arguments for that particular module using the ``module_defaults`` keyword."
msgstr "同じ引数で同じモジュールを頻繁に呼び出す場合は、``module_defaults`` キーワードを使用して、その特定のモジュールのデフォルト引数を定義すると便利です。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:8
msgid "Here is a basic example:"
msgstr "以下に基本的な例を示します。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:34
msgid "The ``module_defaults`` keyword can be used at the play, block, and task level. Any module arguments explicitly specified in a task will override any established default for that module argument."
msgstr "``module_defaults`` キーワードは、プレイ、ブロック、およびタスクレベルで使用できます。タスクで明示的に指定されたモジュール引数は、そのモジュール引数に対して確立されたデフォルトを上書きします。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:46
msgid "You can remove any previously established defaults for a module by specifying an empty dict."
msgstr "空のディクショナリーを指定することで、それまでに設定されたモジュールのデフォルトを削除することができます。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:58
msgid "Any module defaults set at the play level (and block/task level when using ``include_role`` or ``import_role``) will apply to any roles used, which may cause unexpected behavior in the role."
msgstr "プレイレベルで設定されるモジュールのデフォルト (``include_role`` または ``import_role`` を使用する際のブロックまたはタスクのレベル) は、使用されるロールに適用されます。これにより、ロールで予期しない動作が発生する可能性があります。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:60
msgid "Here are some more realistic use cases for this feature."
msgstr "この機能のより実用的なユースケースを以下に示します。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:62
msgid "Interacting with an API that requires auth."
msgstr "認証をを必要とする API との対話:"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:85
msgid "Setting a default AWS region for specific EC2-related modules."
msgstr "特定の EC2 関連のモジュールにデフォルトの AWS リージョンを設定します。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:103
msgid "Module defaults groups"
msgstr "モジュールのデフォルトグループ"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:107
msgid "Ansible 2.7 adds a preview-status feature to group together modules that share common sets of parameters. This makes it easier to author playbooks making heavy use of API-based modules such as cloud modules."
msgstr "Ansible 2.7 では、共通のパラメーターセットを持つモジュールをまとめて表示するプレビューステータス機能が追加されました。これにより、クラウドモジュールなどの API ベースのモジュールを多用する Playbook の作成が容易になります。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:110
msgid "Group"
msgstr "グループ"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:110
msgid "Purpose"
msgstr "目的"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:110
msgid "Ansible Version"
msgstr "Ansible バージョン"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:112
msgid "aws"
msgstr "aws"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:112
msgid "Amazon Web Services"
msgstr "Amazon Web Services"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:112
#: ../../rst/playbook_guide/playbooks_module_defaults.rst:114
#: ../../rst/playbook_guide/playbooks_module_defaults.rst:116
msgid "2.7"
msgstr "2.7"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:114
msgid "azure"
msgstr "azure"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:114
msgid "Azure"
msgstr "Azure"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:116
msgid "gcp"
msgstr "gcp"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:116
msgid "Google Cloud Platform"
msgstr "Google Cloud Platform"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:118
msgid "k8s"
msgstr "k8s"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:118
msgid "Kubernetes"
msgstr "Kubernetes"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:118
#: ../../rst/playbook_guide/playbooks_module_defaults.rst:120
msgid "2.8"
msgstr "2.8"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:120
msgid "os"
msgstr "os"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:120
msgid "OpenStack"
msgstr "OpenStack"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:122
msgid "acme"
msgstr "acme"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:122
msgid "ACME"
msgstr "ACME"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:122
#: ../../rst/playbook_guide/playbooks_module_defaults.rst:124
#: ../../rst/playbook_guide/playbooks_module_defaults.rst:126
#: ../../rst/playbook_guide/playbooks_module_defaults.rst:128
msgid "2.10"
msgstr "2.10"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:124
msgid "docker*"
msgstr "docker*"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:124
msgid "Docker"
msgstr "Docker"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:126
msgid "ovirt"
msgstr "ovirt"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:126
msgid "oVirt"
msgstr "oVirt"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:128
msgid "vmware"
msgstr "vmware"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:128
msgid "VMware"
msgstr "VMware"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:131
msgid "The `docker_stack <docker_stack_module>`_ module is not included in the ``docker`` defaults group."
msgstr "`docker_stack <docker_stack_module>`_ モジュールは、``docker`` デフォルトグループには含まれません。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:133
msgid "Use the groups with ``module_defaults`` by prefixing the group name with ``group/`` - for example ``group/aws``."
msgstr "グループ名の前に ``group/`` を追加して (例: ``group/aws``)、``module_defaults`` でグループを使用します。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:135
msgid "In a playbook, you can set module defaults for whole groups of modules, such as setting a common AWS region."
msgstr "Playbook では、一般的な AWS リージョンの設定など、モジュールのグループ全体にモジュールのデフォルトを設定できます。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:155
msgid "In ansible-core 2.12, collections can define their own groups in the ``meta/runtime.yml`` file. ``module_defaults`` does not take the ``collections`` keyword into account, so the fully qualified group name must be used for new groups in ``module_defaults``."
msgstr "ansible-core 2.12 では、コレクションは ``meta/runtime.yml`` ファイルで独自のグループを定義できます。``module_defaults`` は ``collections`` キーワードを考慮に入れないため、完全修飾グループ名を ``module_defaults`` の新規グループに使用する必要があります。"

#: ../../rst/playbook_guide/playbooks_module_defaults.rst:157
msgid "Here is an example ``runtime.yml`` file for a collection and a sample playbook using the group."
msgstr "以下は、グループを使用したコレクションおよびサンプル Playbook の ``runtime.yml`` ファイルの例です。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:6
msgid "Understanding privilege escalation: become"
msgstr "権限昇格の理解: become"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:8
msgid "Ansible uses existing privilege escalation systems to execute tasks with root privileges or with another user's permissions. Because this feature allows you to 'become' another user, different from the user that logged into the machine (remote user), we call it ``become``. The ``become`` keyword uses existing privilege escalation tools like `sudo`, `su`, `pfexec`, `doas`, `pbrun`, `dzdo`, `ksu`, `runas`, `machinectl` and others."
msgstr "Ansible は既存の権限昇格システムを使用して、root 権限または別のユーザーのパーミッションでタスクを実行します。この機能を使用すると、このマシンにログインしたユーザー (リモートユーザー) とは別のユーザー「になる (become)」ことができるため、この機能は ``become`` と呼ばれています。``become`` キーワードは、`sudo`、`su`、`pfexec`、`doas`、`pbrun`、`dzdo`、`ksu`、`runas`、`machinectl` などの既存の特権昇格ツールを使用します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:14
msgid "Using become"
msgstr "become の使用"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:16
msgid "You can control the use of ``become`` with play or task directives, connection variables, or at the command line. If you set privilege escalation properties in multiple ways, review the :ref:`general precedence rules<general_precedence_rules>` to understand which settings will be used."
msgstr "play ディレクティブまたは task ディレクティブ、接続変数、またはコマンドラインでの ``become`` の使用を制御できます。複数の方法で権限昇格プロパティーを設定する場合は、:ref:`一般的な優先順位ルール<general_precedence_rules>` を確認し、使用する設定を確認します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:18
msgid "A full list of all become plugins that are included in Ansible can be found in the :ref:`become_plugin_list`."
msgstr "Ansible に含まれる全 become プラグインの完全リストは、:ref:`become_plugin_list` にあります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:21
msgid "Become directives"
msgstr "Become ディレクティブ"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:23
msgid "You can set the directives that control ``become`` at the play or task level. You can override these by setting connection variables, which often differ from one host to another. These variables and directives are independent. For example, setting ``become_user`` does not set ``become``."
msgstr "プレイまたはタスクレベルで、``become`` を制御するディレクティブを設定できます。多くの場合は、ホストごとに異なる接続変数を設定することで、これらをオーバーライドできます。これらの変数とディレクティブは独立しています。たとえば、``become_user`` に設定しても ``become`` に設定されません。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:26
msgid "become"
msgstr "become"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:26
msgid "set to ``yes`` to activate privilege escalation."
msgstr "権限昇格をアクティブにするには、``yes`` に設定します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:29
msgid "become_user"
msgstr "become_user"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:29
msgid "set to user with desired privileges — the user you `become`, NOT the user you login as. Does NOT imply ``become: yes``, to allow it to be set at host level. Default value is ``root``."
msgstr "希望する権限を持つユーザーに設定します。ログインしたユーザーではなく、`become` を行ったユーザーになります。ホストレベルで設定できるようにする ``become: yes`` を意味するものではありません。デフォルト値は ``root`` です。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:32
msgid "become_method"
msgstr "become_method"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:32
msgid "(at play or task level) overrides the default method set in ansible.cfg, set to use any of the :ref:`become_plugins`."
msgstr "(play レベルまたは task レベルで)、ansible.cfg に設定されたデフォルトのメソッドをオーバーライドし、:ref:`become_plugins` を使用するよう設定します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:35
msgid "become_flags"
msgstr "become_flags"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:35
msgid "(at play or task level) permit the use of specific flags for the tasks or role. One common use is to change the user to nobody when the shell is set to nologin. Added in Ansible 2.2."
msgstr "(play レベルまたは task レベルで) タスクまたはロールに特定のフラグの使用を許可します。一般的な使い方としては、シェルが nologin に設定されているときに、ユーザーを nobody に変更するのが一般的な方法です。Ansible 2.2 で追加されました。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:37
msgid "For example, to manage a system service (which requires ``root`` privileges) when connected as a non-``root`` user, you can use the default value of ``become_user`` (``root``):"
msgstr "たとえば、``root`` 以外のユーザーとして接続する際にシステムサービスを管理する (``root`` 権限が必要) には、``become_user`` (``root``) のデフォルト値を使用できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:47
msgid "To run a command as the ``apache`` user:"
msgstr "``apache`` ユーザーとしてコマンドを実行するには、次を実行します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:56
msgid "To do something as the ``nobody`` user when the shell is nologin:"
msgstr "シェルが nologin の場合に ``nobody`` ユーザーとして操作を行う場合は、次を実行します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:67
msgid "To specify a password for sudo, run ``ansible-playbook`` with ``--ask-become-pass`` (``-K`` for short). If you run a playbook utilizing ``become`` and the playbook seems to hang, most likely it is stuck at the privilege escalation prompt. Stop it with `CTRL-c`, then execute the playbook with ``-K`` and the appropriate password."
msgstr "sudo のパスワードを指定するには、``ansible-playbook`` を ``--ask-become-pass`` (略して ``-K``) と一緒に実行します。``become`` を使用して Playbook を実行し、Playbook がハングしているように見える場合は、ほとんどの場合、特権昇格のプロンプトで止まっています。`CTRL-c` で停止させてから、``-K`` と適切なパスワードで Playbook を実行してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:71
msgid "Become connection variables"
msgstr "Become 接続変数"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:73
msgid "You can define different ``become`` options for each managed node or group. You can define these variables in inventory or use them as normal variables."
msgstr "管理対象ノードまたはグループごとに異なる ``become`` オプションを定義できます。これらの変数はインベントリーで定義するか、通常の変数として使用できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:76
msgid "ansible_become"
msgstr "ansible_become"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:76
msgid "overrides the ``become`` directive, decides if privilege escalation is used or not."
msgstr "``become`` ディレクティブを上書きします。権限のエスカレーションが使用されるかどうかを指定します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:79
msgid "ansible_become_method"
msgstr "ansible_become_method"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:79
msgid "which privilege escalation method should be used"
msgstr "使用する権限昇格方法です。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:82
msgid "ansible_become_user"
msgstr "ansible_become_user"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:82
msgid "set the user you become through privilege escalation; does not imply ``ansible_become: yes``"
msgstr "権限昇格で become を行うユーザーを設定します。``ansible_become: yes`` を意味するものではありません。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:85
msgid "ansible_become_password"
msgstr "ansible_become_password"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:85
msgid "set the privilege escalation password. See :ref:`playbooks_vault` for details on how to avoid having secrets in plain text"
msgstr "権限昇格パスワードを設定します。平文での秘密の使用を回避する方法は、「:ref:`playbooks_vault`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:88
msgid "ansible_common_remote_group"
msgstr "ansible_common_remote_group"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:88
msgid "determines if Ansible should try to ``chgrp`` its temporary files to a group if ``setfacl`` and ``chown`` both fail. See `Risks of becoming an unprivileged user`_ for more information. Added in version 2.10."
msgstr "``setfacl`` と ``chown`` の両方が失敗した場合に、Ansible が一時ファイルをグループに ``chgrp`` しようとするかどうかを決定します。詳細は「`非特権ユーザーになるリスク`_」を参照してください。バージョン 2.10 で追加されました。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:90
msgid "For example, if you want to run all tasks as ``root`` on a server named ``webserver``, but you can only connect as the ``manager`` user, you could use an inventory entry like this:"
msgstr "たとえば、すべてのタスクを ``webserver`` という名前のサーバーで ``root`` として実行することを望み、``manager`` ユーザーとしてのみ接続できる場合は、以下のようなインベントリーエントリーを使用できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:97
msgid "The variables defined above are generic for all become plugins but plugin specific ones can also be set instead. Please see the documentation for each plugin for a list of all options the plugin has and how they can be defined. A full list of become plugins in Ansible can be found at :ref:`become_plugins`."
msgstr "上記の変数はすべての become プラグインに汎用的なものですが、代わりにプラグイン固有の変数を設定することもできます。そのプラグインが持つすべてのオプションとその定義方法の一覧は、各プラグインのドキュメントを参照してください。Ansible における become プラグインの完全なリストは :ref:`become_plugins` を参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:102
msgid "Become command-line options"
msgstr "Become コマンドラインオプション"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:105
msgid "ask for privilege escalation password; does not imply become will be used. Note that this password will be used for all hosts."
msgstr "権限昇格パスワードを要求します。これは。必ずしも become が使用されるとは限りません。このパスワードはすべてのホストで使用されることに注意してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:108
msgid "run operations with become (no password implied)"
msgstr "become で操作を実行します (パスワードがないことを示しています)。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:111
msgid "privilege escalation method to use (default=sudo), valid choices: [ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ]"
msgstr "使用する特権昇格方法 (デフォルトは sudo)。有効な選択肢は、[ sudo | su | pbrun | pfexec | doas | dzdo | ksu | runas | machinectl ] となります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:115
msgid "run operations as this user (default=root), does not imply --become/-b"
msgstr "このユーザー (デフォルトは root) として操作を実行します。--become/-b を意味するものではありません。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:118
msgid "Risks and limitations of become"
msgstr "become のリスクおよび制限"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:120
msgid "Although privilege escalation is mostly intuitive, there are a few limitations on how it works.  Users should be aware of these to avoid surprises."
msgstr "特権の昇格はほとんど直感的ですが、それがどのように機能するかについては、いくつかの制限があります。問題が発生しないように、これらの点に注意する必要があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:124
msgid "Risks of becoming an unprivileged user"
msgstr "非特権ユーザーになる (become) リスク"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:126
msgid "Ansible modules are executed on the remote machine by first substituting the parameters into the module file, then copying the file to the remote machine, and finally executing it there."
msgstr "Ansible モジュールは、まずモジュールファイルにパラメーターを代入し、次にそのファイルをリモートマシンにコピーし、最後にそこで実行することで、リモートマシン上で実行されます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:130
msgid "Everything is fine if the module file is executed without using ``become``, when the ``become_user`` is root, or when the connection to the remote machine is made as root. In these cases Ansible creates the module file with permissions that only allow reading by the user and root, or only allow reading by the unprivileged user being switched to."
msgstr "モジュールファイルが ``become`` を使用せずに、``become_user`` が root の場合や、リモートマシンへの接続が root として行われる場合、すべてのことは問題ありません。このような場合、Ansible は、ユーザーおよび root による読み取りのみを許可するパーミッション、または切り替え先の非特権ユーザーの読み取りのみを許可するパーミッションを持つモジュールファイルを作成します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:136
msgid "However, when both the connection user and the ``become_user`` are unprivileged, the module file is written as the user that Ansible connects as (the ``remote_user``), but the file needs to be readable by the user Ansible is set to ``become``. The details of how Ansible solves this can vary based on platform. However, on POSIX systems, Ansible solves this problem in the following way:"
msgstr "ただし、接続ユーザーと ``become_user`` の両方が特権を持たない場合、モジュールファイルは Ansible が接続するユーザー (``remote_user``) として記述されますが、Ansible が ``become`` に設定されているユーザーがファイルを読み取れる必要があります。Ansible がこれをプラットフォーム別に解決する方法の詳細は次のとおりですが、POSIX システムでは、Ansible がこの問題を解決します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:142
msgid "First, if :command:`setfacl` is installed and available in the remote ``PATH``, and the temporary directory on the remote host is mounted with POSIX.1e filesystem ACL support, Ansible will use POSIX ACLs to share the module file with the second unprivileged user."
msgstr "まず、リモート ``PATH`` に :command:`setfacl` がインストールされ、利用可能な場合は、リモートホストの一時ディレクトリーが POSIX.1e ファイルシステム ACL サポートでマウントされている場合、Ansible は POSIX ACL を使用して 2 つの非特権ユーザーとモジュールファイルを共有します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:147
msgid "Next, if POSIX ACLs are **not** available or :command:`setfacl` could not be run, Ansible will attempt to change ownership of the module file using :command:`chown` for systems which support doing so as an unprivileged user."
msgstr "次に、POSIX ACL が利用 **できない** か、:command:`setfacl` を実行できない場合、Ansible は、特権のないユーザーとして対応するシステムの :command:`chown` を使用してモジュールファイルの所有権を変更しようとします。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:151
msgid "New in Ansible 2.11, at this point, Ansible will try :command:`chmod +a` which is a macOS-specific way of setting ACLs on files."
msgstr "Ansible 2.11 の新機能として、Ansible は、ファイルに ACL を設定する際に macOS 固有の方法で :command:`chmod +a` を試行します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:154
msgid "New in Ansible 2.10, if all of the above fails, Ansible will then check the value of the configuration setting ``ansible_common_remote_group``. Many systems will allow a given user to change the group ownership of a file to a group the user is in. As a result, if the second unprivileged user (the ``become_user``) has a UNIX group in common with the user Ansible is connected as (the ``remote_user``), and if ``ansible_common_remote_group`` is defined to be that group, Ansible can try to change the group ownership of the module file to that group by using :command:`chgrp`, thereby likely making it readable to the ``become_user``."
msgstr "Ansible 2.10 の新機能で、上記のすべてが失敗すると、Ansible は構成設定 ``ansible_common_remote_group`` の値を確認します。多くのシステムでは、特定のユーザーが、ファイルのグループ所有権を、所属するグループに変更できます。その結果、2 番目の非特権ユーザー (``become_user``) に、Ansible が (``remote_user``として) 接続するユーザーに共通する UNIX グループがあり、``ansible_common_remote_group`` がそのグループとして定義されている場合は、 :command:`chgrp` を使用してモジュールファイルのグループ所有権をそのグループに変更しようとすることができます。したがって、``become_user`` が読みるようになる可能性があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:164
msgid "At this point, if ``ansible_common_remote_group`` was defined and a :command:`chgrp` was attempted and returned successfully, Ansible assumes (but, importantly, does not check) that the new group ownership is enough and does not fall back further. That is, Ansible **does not check** that the ``become_user`` does in fact share a group with the ``remote_user``; so long as the command exits successfully, Ansible considers the result successful and does not proceed to check ``allow_world_readable_tmpfiles`` per below."
msgstr "この時点で、``ansible_common_remote_group`` が定義され、 :command:`chgrp` が試行されて正常に返された場合、Ansible は新しいグループの所有権で十分であると仮定し (ただし、重要なことですが、確認はしません)、それ以上はフォールバックしません。つまり、``become_user`` が実際に ``remote_user`` とグループを共有しているかどうかは **確認しません**。コマンドが正常に終了する限り、Ansible はその結果を成功とみなし、以下の ``allow_world_readable_tmpfiles`` のチェックには進みません。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:172
msgid "If ``ansible_common_remote_group`` is **not** set and the chown above it failed, or if ``ansible_common_remote_group`` *is* set but the :command:`chgrp` (or following group-permissions :command:`chmod`) returned a non-successful exit code, Ansible will lastly check the value of ``allow_world_readable_tmpfiles``. If this is set, Ansible will place the module file in a world-readable temporary directory, with world-readable permissions to allow the ``become_user`` (and incidentally any other user on the system) to read the contents of the file. **If any of the parameters passed to the module are sensitive in nature, and you do not trust the remote machines, then this is a potential security risk.**"
msgstr "``ansible_common_remote_group`` が **設定されておらず**、そこでの chown が失敗した場合、または ``ansible_common_remote_group`` *が* 設定されているが :command:`chgrp` (またはそれに続くグループパーミッションの :command:`chmod`) が成功しない終了コードを返した場合、Ansible は最後に ``allow_world_readable_tmpfiles`` の値を確認します。この値が設定されていると、Ansible はモジュールファイルを誰もが読める一時ディレクトリーに置き、``become_user`` (およびシステム上の他のユーザー) がファイルの内容を読めるように、誰もが読み取り可能なパーミッションを設定します。**モジュールに渡されるパラメーターに機密性があり、リモートマシンを信用していない場合、これは潜在的なセキュリティーリスクとなります。**"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:183
msgid "Once the module is done executing, Ansible deletes the temporary file."
msgstr "モジュールの実行が完了すると、Ansible は一時ファイルを削除します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:185
msgid "Several ways exist to avoid the above logic flow entirely:"
msgstr "上記のロジックフローを完全に回避する方法はいくつかあります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:187
msgid "Use `pipelining`.  When pipelining is enabled, Ansible does not save the module to a temporary file on the client.  Instead it pipes the module to the remote python interpreter's stdin. Pipelining does not work for python modules involving file transfer (for example: :ref:`copy <copy_module>`, :ref:`fetch <fetch_module>`, :ref:`template <template_module>`), or for non-python modules."
msgstr "`pipelining` を使用します。パイプラインを有効にすると、Ansible はモジュールをクライアント上の一時ファイルに保存しません。代わりに、モジュールをリモートの python インタープリターの標準入力にパイプします。パイプラインは、ファイル転送を伴う python モジュール (例: :ref:`copy <copy_module>`、:ref:`fetch <fetch_module>`、:ref:`template <template_module>`) や、python 以外のモジュールでは機能しません。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:193
msgid "Avoid becoming an unprivileged user.  Temporary files are protected by UNIX file permissions when you ``become`` root or do not use ``become``.  In Ansible 2.1 and above, UNIX file permissions are also secure if you make the connection to the managed machine as root and then use ``become`` to access an unprivileged account."
msgstr "非特権ユーザーは使用しないでください。root に ``become`` した場合、または ``become`` を使用しない場合は、UNIX ファイルの権限で保護されます。Ansible 2.1 以降では、UNIX ファイルのパーミッションは、root として管理マシンに接続し、権限のないアカウントにアクセスするには、``become`` を使用しても保護されます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:199
msgid "Although the Solaris ZFS filesystem has filesystem ACLs, the ACLs are not POSIX.1e filesystem acls (they are NFSv4 ACLs instead).  Ansible cannot use these ACLs to manage its temp file permissions so you may have to resort to ``allow_world_readable_tmpfiles`` if the remote machines use ZFS."
msgstr "Solaris ZFS ファイルシステムにはファイルシステム ACL がありますが、ACL は POSIX.1e ファイルシステムの acl ではありません (正しくは NFSv4 ACL)。Ansible はこれらの ACL を使用してその一時ファイルのパーミッションを管理できないため、リモートマシンが ZFS を使用している場合は ``allow_world_readable_tmpfiles`` を再処理しないといけない場合があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:206
msgid "Ansible makes it hard to unknowingly use ``become`` insecurely. Starting in Ansible 2.1, Ansible defaults to issuing an error if it cannot execute securely with ``become``. If you cannot use pipelining or POSIX ACLs, must connect as an unprivileged user, must use ``become`` to execute as a different unprivileged user, and decide that your managed nodes are secure enough for the modules you want to run there to be world readable, you can turn on ``allow_world_readable_tmpfiles`` in the :file:`ansible.cfg` file.  Setting ``allow_world_readable_tmpfiles`` will change this from an error into a warning and allow the task to run as it did prior to 2.1."
msgstr "Ansible では、知らずに ``become`` を安全でない状態で使用することは困難です。Ansible 2.1 以降、Ansible は ``become`` で安全に実行できない場合は、デフォルトでエラーを発行するようになっています。パイプラインや POSIX ACL を使用できず、非特権ユーザーとして接続しなければならず、``become`` を使用して別の非特権ユーザーとして実行しなければならず、管理対象のノードが、そこで実行したいモジュールが誰でも読むことができる程度に安全であると判断した場合は、:file:`ansible.cfg` ファイルで ``allow_world_readable_tmpfiles`` を有効にすることができます。``allow_world_readable_tmpfiles`` を設定すると、これがエラーから警告に変わり、2.1 以前のようにタスクを実行できるようになります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:218
msgid "Ansible 2.10 introduces the above-mentioned ``ansible_common_remote_group`` fallback. As mentioned above, if enabled, it is used when ``remote_user`` and ``become_user`` are both unprivileged users. Refer to the text above for details on when this fallback happens."
msgstr "Ansible 2.10 では、上記の ``ansible_common_remote_group`` フォールバックが導入されました。上記のように、有効になっていると、``remote_user`` と ``become_user`` の両方が非特権ユーザーである場合に使用されます。このフォールバックが発生するときの詳細は、上記のテキストを参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:223
msgid "As mentioned above, if ``ansible_common_remote_group`` and ``allow_world_readable_tmpfiles`` are both enabled, it is unlikely that the world-readable fallback will ever trigger, and yet Ansible might still be unable to access the module file. This is because after the group ownership change is successful, Ansible does not fall back any further, and also does not do any check to ensure that the ``become_user`` is actually a member of the \"common group\". This is a design decision made by the fact that doing such a check would require another round-trip connection to the remote machine, which is a time-expensive operation. Ansible does, however, emit a warning in this case."
msgstr "上記のように、``ansible_common_remote_group`` と ``allow_world_readable_tmpfiles`` の両方が有効になると、誰でも読み取り可能なフォールバックがトリガーされず、Ansible がまだモジュールファイルにアクセスできない可能性があります。これは、グループの所有権変更が成功した後に、Ansible はこれ以上フォールバックせず、``become_user`` が実際には「共通グループ」のメンバーであることを確認するためのチェックが行われないためですこれは、このようなチェックを行うと、リモートマシンへの別のラウンドトリップ接続が必要になり、時間のかかる操作になってしまうことを考慮した設計上の決定です。しかし、Ansible はこの場合、警告を発します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:235
msgid "Not supported by all connection plugins"
msgstr "すべての connection プラグインでサポートされない"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:237
msgid "Privilege escalation methods must also be supported by the connection plugin used. Most connection plugins will warn if they do not support become. Some will just ignore it as they always run as root (jail, chroot, and so on)."
msgstr "特権昇格の方法は、使用する connection プラグインがサポートしている必要があります。ほとんどの connection プラグインは、become をサポートしていないと警告を表示します。一部の connection プラグインでは、常に root として実行されるため (jail、chroot など)、無視されます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:242
msgid "Only one method may be enabled per host"
msgstr "ホストごとに有効にできる方法は 1 つだけ"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:244
msgid "Methods cannot be chained. You cannot use ``sudo /bin/su -`` to become a user, you need to have privileges to run the command as that user in sudo or be able to su directly to it (the same for pbrun, pfexec or other supported methods)."
msgstr "メソッドを連鎖させることはできません。``sudo /bin/su -`` を使用してユーザーになる (become) ことはできません。そのユーザーとして sudo でコマンドを実行するか、直接 su できるような権限が必要です (pbrun、pfexec、その他のサポートされている方法も同様です)。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:249
msgid "Privilege escalation must be general"
msgstr "特権昇格は一般的なものにすること"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:251
msgid "You cannot limit privilege escalation permissions to certain commands. Ansible does not always use a specific command to do something but runs modules (code) from a temporary file name which changes every time.  If you have '/sbin/service' or '/bin/chmod' as the allowed commands this will fail with ansible as those paths won't match with the temporary file that Ansible creates to run the module. If you have security rules that constrain your sudo/pbrun/doas environment to running specific command paths only, use Ansible from a special account that does not have this constraint, or use AWX or the :ref:`ansible_platform` to manage indirect access to SSH credentials."
msgstr "特権昇格の許可を特定のコマンドに限定することはできません。Ansible は常に特定のコマンドを使用して何かを行うわけではなく、毎回変更される一時ファイル名からモジュール (コード) を実行します。許可されるコマンドとして「/sbin/service」や「/bin/chmod」を指定した場合、これらのパスは Ansible がモジュールを実行するために作成する一時ファイルと一致しないため、Ansible では失敗します。sudo/pbrun/doas 環境で特定のコマンドパスしか実行できないようなセキュリティールールがある場合は、この制約を受けない特別なアカウントで Ansible を使用するか、AWX または :ref:`ansible_platform` を使用して SSH 認証情報への間接的なアクセスを管理してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:262
msgid "May not access environment variables populated by pamd_systemd"
msgstr "pamd_systemd が設定する環境変数にアクセスできない場合"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:264
msgid "For most Linux distributions using ``systemd`` as their init, the default methods used by ``become`` do not open a new \"session\", in the sense of systemd. Because the ``pam_systemd`` module will not fully initialize a new session, you might have surprises compared to a normal session opened through ssh: some environment variables set by ``pam_systemd``, most notably ``XDG_RUNTIME_DIR``, are not populated for the new user and instead inherited or just emptied."
msgstr "``systemd`` を init として使用しているほとんどの Linux ディストリビューションでは、``become`` が使用するデフォルトの方法では、systemd の意味での新しい「セッション」を開くことができません。``pam_systemd`` モジュールは新しいセッションを完全には初期化しないため、ssh で開いた通常のセッションと比べて驚くことがあるかもしれません。``pam_systemd`` によって設定されたいくつかの環境変数、特に ``XDG_RUNTIME_DIR`` は新しいユーザーには設定されず、代わりに継承されたり、単に空になったりします。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:272
msgid "This might cause trouble when trying to invoke systemd commands that depend on ``XDG_RUNTIME_DIR`` to access the bus:"
msgstr "このため、バスへのアクセスを ``XDG_RUNTIME_DIR`` に依存する systemd コマンドを呼び出す際に問題が発生する可能性があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:282
msgid "To force ``become`` to open a new systemd session that goes through ``pam_systemd``, you can use ``become_method: machinectl``."
msgstr "``become`` に、``pam_systemd`` を通して新しい systemd セッションを開くために、``become_method: machinectl`` を使用することができます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:285
msgid "For more information, see `this systemd issue <https://github.com/systemd/systemd/issues/825#issuecomment-127917622>`_."
msgstr "詳細情報は、「`this systemd issue <https://github.com/systemd/systemd/issues/825#issuecomment-127917622>`_」を参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:289
msgid "Resolving Temporary File Error Messsages"
msgstr "一時的なファイルエラーメッセージの解決"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:291
msgid "Failed to set permissions on the temporary files Ansible needs to create when becoming an unprivileged user\""
msgstr "非特権ユーザーになる場合に Ansible が作成する必要のある一時ファイルに権限を設定できませんでした"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:292
msgid "This error can be resolved by installing the package that provides the ``setfacl`` command. (This is frequently the ``acl`` package but check your OS documentation.)"
msgstr "このエラーは、``setfacl`` コマンドを提供するパッケージをインストールすることで解決できます (多くの場合、これは``acl``パッケージ ですが、OS ドキュメントを確認してください)。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:297
msgid "Become and network automation"
msgstr "become およびネットワーク自動化"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:299
msgid "As of version 2.6, Ansible supports ``become`` for privilege escalation (entering ``enable`` mode or privileged EXEC mode) on all Ansible-maintained network platforms that support ``enable`` mode. Using ``become`` replaces the ``authorize`` and ``auth_pass`` options in a ``provider`` dictionary."
msgstr "バージョン 2.6 以降、Ansible は、``enable`` モードをサポートするすべての Ansible が保守するネットワークプラットフォームにおいて、特権昇格 (``enable`` モードまたは特権 EXEC モードへの移行) のために ``become`` をサポートしています。``become`` を使用すると、``provider`` ディクショナリーの ``authorize`` オプションおよび ``auth_pass`` のオプションが置き換えられます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:301
msgid "You must set the connection type to either ``connection: ansible.netcommon.network_cli`` or ``connection: ansible.netcommon.httpapi`` to use ``become`` for privilege escalation on network devices. Check the :ref:`platform_options` documentation for details."
msgstr "ネットワークデバイスの特権昇格に ``become`` を使用するには、接続タイプを ``connection: ansible.netcommon.network_cli`` または ``connection: ansible.netcommon.httpapi`` のいずれかに設定する必要があります。詳細については、「:ref:`platform_options`」を確認してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:303
msgid "You can use escalated privileges on only the specific tasks that need them, on an entire play, or on all plays. Adding ``become: yes`` and ``become_method: enable`` instructs Ansible to enter ``enable`` mode before executing the task, play, or playbook where those parameters are set."
msgstr "昇格した権限は、それを必要とする特定のタスクのみ、プレイ全体でのみ、またはすべてのプレイで使用することができます。``become: yes`` と ``become_method: enable`` を追加すると、これらのパラメーターが設定されているタスク、プレイ、または Playbook を実行する前に、``enable`` モードに入るよう Ansible に指示します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:305
msgid "If you see this error message, the task that generated it requires ``enable`` mode to succeed:"
msgstr "このエラーメッセージが表示された場合に、エラーメッセージを生成したタスクを成功させるには、``enable`` モードが必要になります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:311
msgid "To set ``enable`` mode for a specific task, add ``become`` at the task level:"
msgstr "特定のタスクに ``enable`` モードを設定するには、タスクレベルで ``become`` を追加します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:322
msgid "To set enable mode for all tasks in a single play, add ``become`` at the play level:"
msgstr "1 つのプレイのすべてのタスクに enable モードを設定するには、プレイレベルに ``become`` を追加します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:336
msgid "Setting enable mode for all tasks"
msgstr "すべてのタスクに enable モードの設定"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:338
msgid "Often you wish for all tasks in all plays to run using privilege mode, that is best achieved by using ``group_vars``:"
msgstr "すべてのプレイのすべてのタスクを特権モードで実行させたいと思うことがよくありますが、そのような場合には、``group_vars`` を使用することが最適です。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:340
msgid "**group_vars/eos.yml**"
msgstr "**group_vars/eos.yml**"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:351
msgid "Passwords for enable mode"
msgstr "enable モードのパスワード"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:353
msgid "If you need a password to enter ``enable`` mode, you can specify it in one of two ways:"
msgstr "``enable`` モードに入るパスワードが必要な場合は、以下のいずれかの方法で指定できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:355
msgid "providing the :option:`--ask-become-pass <ansible-playbook --ask-become-pass>` command line option"
msgstr ":option:`--ask-become-pass <ansible-playbook --ask-become-pass>` コマンドラインオプションの指定"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:356
msgid "setting the ``ansible_become_password`` connection variable"
msgstr "``ansible_become_password`` 接続変数の設定"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:360
msgid "As a reminder passwords should never be stored in plain text. For information on encrypting your passwords and other secrets with Ansible Vault, see :ref:`vault`."
msgstr "通知パスワードは平文で保存しないでください。Ansible Vault でパスワードやその他の秘密を暗号化する方法は、「:ref:`vault`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:363
msgid "authorize and auth_pass"
msgstr "authorize および auth_pass"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:365
msgid "Ansible still supports ``enable`` mode with ``connection: local`` for legacy network playbooks. To enter ``enable`` mode with ``connection: local``, use the module options ``authorize`` and ``auth_pass``:"
msgstr "Ansible では、従来のネットワークの Playbook について、``connection: local`` を使用した ``enable`` モードを引き続きサポートしています。``connection: local`` で ``enable`` モードに入るには、モジュールオプション ``authorize`` および ``auth_pass`` を使用します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:380
msgid "We recommend updating your playbooks to use ``become`` for network-device ``enable`` mode consistently. The use of ``authorize`` and of ``provider`` dictionaries will be deprecated in future. Check the :ref:`platform_options` documentation for details."
msgstr "ネットワークデバイスの ``enable`` モードに ``become`` を一貫して使用するように Playbook を更新することが推奨されます。``authorize`` および ``provider`` ディクショナリーの使用は、今後は推奨されません。詳細は、:ref:`platform_options` のドキュメントを参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:385
msgid "Become and Windows"
msgstr "Become および Windows"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:387
msgid "Since Ansible 2.3, ``become`` can be used on Windows hosts through the ``runas`` method. Become on Windows uses the same inventory setup and invocation arguments as ``become`` on a non-Windows host, so the setup and variable names are the same as what is defined in this document with the exception of ``become_user``. As there is no sensible default for ``become_user`` on Windows it is required when using ``become``. See :ref:`ansible.builtin.runas become plugin <ansible_collections.ansible.builtin.runas_become>` for details."
msgstr "Ansible 2.3 以降、``become`` は ``runas`` メソッドを通じて Windows ホストでも使用できるようになりました。Windows 上の Become は、非 Windows ホスト上の ``become`` と同じインベントリー設定と起動引数を使用するため、設定と変数名はこのドキュメントで定義されているものと同じになります (``become_user`` を除く)。Windows には妥当な ``become_user`` のデフォルトがないので、``become`` を使用時に必要です。詳細は、:ref:`ansible.builtin.runas become plugin <ansible_collections.ansible.builtin.runas_become>` を参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:394
msgid "While ``become`` can be used to assume the identity of another user, there are other uses for it with Windows hosts. One important use is to bypass some of the limitations that are imposed when running on WinRM, such as constrained network delegation or accessing forbidden system calls like the WUA API. You can use ``become`` with the same user as ``ansible_user`` to bypass these limitations and run commands that are not normally accessible in a WinRM session."
msgstr "``become`` は、別のユーザーの ID を装うために使用することができますが、Windows ホストではそれ以外にも使用方法があります。重要な用途の 1 つは、ネットワーク委譲の制約や、WUA API のような禁止されたシステムコールへのアクセスなど、WinRM 上で実行する際に課される制限の一部を回避することです。``become`` を ``ansible_user`` と同じユーザーで使用すると、これらの制限を回避して、WinRM セッションでは通常アクセスできないコマンドを実行することができます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:402
msgid "On Windows you cannot connect with an underprivileged account and use become to elevate your rights. Become can only be used if your connection account is already an Administrator of the target host."
msgstr "Windows では、権限のないアカウントで接続できず、become を使用して権限を昇格することはできません。become は、接続アカウントがすでにターゲットホストの管理者である場合にのみ使用できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:407
msgid "Administrative rights"
msgstr "管理者権限"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:409
msgid "Many tasks in Windows require administrative privileges to complete. When using the ``runas`` become method, Ansible will attempt to run the module with the full privileges that are available to the become user. If it fails to elevate the user token, it will continue to use the limited token during execution."
msgstr "Windows の多くのタスクを完了するには、管理者権限が必要です。``runas`` の become メソッドを使用すると、Ansible は become ユーザーが使用できる全権限でモジュールの実行を試みます。ユーザートークンの昇格に失敗すると、実行中に制限されたトークンを引き続き使用します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:414
msgid "A user must have the ``SeDebugPrivilege`` to run a become process with elevated privileges. This privilege is assigned to Administrators by default. If the debug privilege is not available, the become process will run with a limited set of privileges and groups."
msgstr "ユーザーは、昇格された権限で become プロセスを実行するには、``SeDebugPrivilege`` が必要です。この権限はデフォルトで管理者に割り当てられます。デバッグ権限が利用できない場合、become プロセスは、限られた一連の特権およびグループで実行されます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:419
msgid "To determine the type of token that Ansible was able to get, run the following task:"
msgstr "Ansible が取得できたトークンの種類を確認するには、以下のタスクを実行します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:428
msgid "The output will look something similar to the below:"
msgstr "出力は以下のようになります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:516
msgid "Under the ``label`` key, the ``account_name`` entry determines whether the user has Administrative rights. Here are the labels that can be returned and what they represent:"
msgstr "``label`` キーにおいて、``account_name`` エントリーは、ユーザーに管理権限があるかどうかを判断します。ここでは、返すことができるラベルと、そのラベルが表す内容を紹介します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:520
msgid "``Medium``: Ansible failed to get an elevated token and ran under a limited token. Only a subset of the privileges assigned to user are available during the module execution and the user does not have administrative rights."
msgstr "``Medium``: Ansible が昇格したトークンの取得に失敗し、制限付きのトークンで実行されました。モジュールの実行中に、ユーザーに割り当てられた特権のサブセットのみが利用可能で、ユーザーは管理者権限を持っていません。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:524
msgid "``High``: An elevated token was used and all the privileges assigned to the user are available during the module execution."
msgstr "``High``: 昇格されたトークンが使用され、ユーザーに割り当てられたすべての特権は、モジュールの実行時に利用できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:527
msgid "``System``: The ``NT AUTHORITY\\System`` account is used and has the highest level of privileges available."
msgstr "``System``: ``NT AUTHORITY\\System`` アカウントが使用され、利用可能な最高レベルの特権が付与されます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:530
msgid "The output will also show the list of privileges that have been granted to the user. When the privilege value is ``disabled``, the privilege is assigned to the logon token but has not been enabled. In most scenarios these privileges are automatically enabled when required."
msgstr "出力には、ユーザーに付与される権限の一覧が表示されます。権限の値が ``disabled`` の場合、特権はログオントークンに割り当てられますが、有効になっていません。ほとんどのシナリオでは、これらの特権は必要に応じて自動的に有効になります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:535
msgid "If running on a version of Ansible that is older than 2.5 or the normal ``runas`` escalation process fails, an elevated token can be retrieved by:"
msgstr "Ansible のバージョンが 2.5 よりも古い場合や、通常の ``runas`` のエスカレーションプロセスが失敗した場合は、昇格したトークンを以下の方法で取得できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:538
msgid "Set the ``become_user`` to ``System`` which has full control over the operating system."
msgstr "``become_user`` を、オペレーティングシステムを完全にコントロールする ``System`` に設定します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:541
msgid "Grant ``SeTcbPrivilege`` to the user Ansible connects with on WinRM. ``SeTcbPrivilege`` is a high-level privilege that grants full control over the operating system. No user is given this privilege by default, and care should be taken if you grant this privilege to a user or group. For more information on this privilege, please see `Act as part of the operating system <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn221957(v=ws.11)>`_. You can use the below task to set this privilege on a Windows host:"
msgstr "Ansible が WinRM で接続するユーザーに ``SeTcbPrivilege`` を付与します。``SeTcbPrivilege`` は、オペレーティングシステムに対する完全な制御を付与する高レベルの特権です。デフォルトでは、この特権は指定されていません。この特権をユーザーまたはグループに付与する場合は注意が必要です。この特権の詳細は、「`Act as part of the operating system <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn221957(v=ws.11)>`_」を参照してください。以下のタスクを使用して、Windows ホストでこの特権を設定できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:557
msgid "Turn UAC off on the host and reboot before trying to become the user. UAC is a security protocol that is designed to run accounts with the ``least privilege`` principle. You can turn UAC off by running the following tasks:"
msgstr "そのユーザーになる (become) 前に、ホストで UAC をオフにし、再起動します。UAC は、``least privilege`` プリンシパルでアカウントを実行するように設計されたセキュリティープロトコルです。以下のタスクを実行して UAC をオフにすることができます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:577
msgid "Granting the ``SeTcbPrivilege`` or turning UAC off can cause Windows security vulnerabilities and care should be given if these steps are taken."
msgstr "``SeTcbPrivilege`` を付与するか UAC をオフにすると、Windows のセキュリティー上の脆弱性を引き起こす可能性があるため、このような手順を実行する場合は注意が必要です。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:581
msgid "Local service accounts"
msgstr "ローカルサービスアカウント"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:583
msgid "Prior to Ansible version 2.5, ``become`` only worked on Windows with a local or domain user account. Local service accounts like ``System`` or ``NetworkService`` could not be used as ``become_user`` in these older versions. This restriction has been lifted since the 2.5 release of Ansible. The three service accounts that can be set under ``become_user`` are:"
msgstr "Ansible バージョン 2.5 より前のバージョンでは、``become`` は、Windows でローカルまたはドメインのユーザーアカウントでのみ動作していました。``System`` や ``NetworkService`` などのローカルサービスアカウントは、これらの旧バージョンでは ``become_user`` として使用できません。この制限は、Ansible 2.5 のリリース以降は解除されました。``become_user`` に設定できる 3 つのサービスアカウントは以下のとおりです。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:589
msgid "System"
msgstr "システム"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:590
msgid "NetworkService"
msgstr "NetworkService"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:591
msgid "LocalService"
msgstr "LocalService"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:593
msgid "Because local service accounts do not have passwords, the ``ansible_become_password`` parameter is not required and is ignored if specified."
msgstr "ローカルサービスアカウントはパスワードを持たないため、``ansible_become_password`` パラメーターは必須ではなく、指定しても無視されます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:598
msgid "Become without setting a password"
msgstr "パスワードを設定しない Become"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:600
msgid "As of Ansible 2.8, ``become`` can be used to become a Windows local or domain account without requiring a password for that account. For this method to work, the following requirements must be met:"
msgstr "Ansible 2.8 では、Windows のローカルまたはドメインアカウントになるために、そのアカウントのパスワードがなくても ``become`` を使用することができます。この方法を行うには、以下の要件を満たす必要があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:604
msgid "The connection user has the ``SeDebugPrivilege`` privilege assigned"
msgstr "接続ユーザーに ``SeDebugPrivilege`` 権限が割り当てられている"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:605
msgid "The connection user is part of the ``BUILTIN\\Administrators`` group"
msgstr "接続ユーザーが ``BUILTIN\\Administrators`` グループに属している"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:606
msgid "The ``become_user`` has either the ``SeBatchLogonRight`` or ``SeNetworkLogonRight`` user right"
msgstr "``become_user`` に、``SeBatchLogonRight`` または ``SeNetworkLogonRight`` のユーザー権限がある"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:608
msgid "Using become without a password is achieved in one of two different methods:"
msgstr "パスワードなしの become は、次のいずれかの方法で使用できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:610
msgid "Duplicating an existing logon session's token if the account is already logged on"
msgstr "アカウントがすでにログオンしている場合は、既存のログオンセッションのトークンを複製する"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:611
msgid "Using S4U to generate a logon token that is valid on the remote host only"
msgstr "S4U を使用してリモートホストでのみ有効なログイントークンを生成する"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:613
msgid "In the first scenario, the become process is spawned from another logon of that user account. This could be an existing RDP logon, console logon, but this is not guaranteed to occur all the time. This is similar to the ``Run only when user is logged on`` option for a Scheduled Task."
msgstr "最初のシナリオでは、そのユーザーアカウントの別のログオンから become プロセスを起動します。これは既存の RDP ログイン、コンソールログオンですが、これは常に発生するとは限りません。これは、スケジュール済みタスクの ``Run only when user is logged on`` オプションと類似しています。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:618
msgid "In the case where another logon of the become account does not exist, S4U is used to create a new logon and run the module through that. This is similar to the ``Run whether user is logged on or not`` with the ``Do not store password`` option for a Scheduled Task. In this scenario, the become process will not be able to access any network resources like a normal WinRM process."
msgstr "become アカウントの別のログオンが存在しない場合は、S4U を使用して新しいログオンを作成し、それを介してモジュールを実行します。これは、スケジュール済みタスクの ``Do not store password`` オプションを持つ ``Run whether user is logged on or not`` と似ています。このシナリオでは、become プロセスは通常の WinRM プロセスなどのネットワークリソースにアクセスできません。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:624
msgid "To make a distinction between using become with no password and becoming an account that has no password make sure to keep ``ansible_become_password`` as undefined or set ``ansible_become_password:``."
msgstr "パスワードなしで become を使用することと、パスワードがないアカウントになる (become) ことを区別するには、``ansible_become_password`` を undefined にしておくか、``ansible_become_password:`` を設定してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:628
msgid "Because there are no guarantees an existing token will exist for a user when Ansible runs, there's a high change the become process will only have access to local resources. Use become with a password if the task needs to access network resources"
msgstr "Ansible の実行時に既存のトークンがユーザーに存在するという保証がないため、become プロセスがローカルリソースにのみアクセスできます。タスクがネットワークリソースにアクセスする必要がある場合は、パスワードで become を使用します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:634
msgid "Accounts without a password"
msgstr "パスワードのないアカウント"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:636
msgid "As a general security best practice, you should avoid allowing accounts without passwords."
msgstr "セキュリティーに関する一般的なベストプラクティスとして、パスワードのないアカウントを許可しないでください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:638
msgid "Ansible can be used to become a Windows account that does not have a password (like the ``Guest`` account). To become an account without a password, set up the variables like normal but set ``ansible_become_password: ''``."
msgstr "Ansible を使用して、パスワードがない Windows アカウントになります (``Guest`` アカウントなど)。パスワードのないアカウントになるには、通常どおり変数を設定しますが、``ansible_become_password: ''`` を設定します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:642
msgid "Before become can work on an account like this, the local policy `Accounts: Limit local account use of blank passwords to console logon only <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj852174(v=ws.11)>`_ must be disabled. This can either be done through a Group Policy Object (GPO) or with this Ansible task:"
msgstr "このようなアカウントで become を有効にする前に、ローカルポリシー `Accounts: Limit local account use of blank passwords to console logon only <https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj852174(v=ws.11)>`_ を無効にする必要があります。これは Group Policy Object (GPO) またはこの Ansible タスクで実行できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:657
msgid "This is only for accounts that do not have a password. You still need to set the account's password under ``ansible_become_password`` if the become_user has a password."
msgstr "これは、パスワードがないアカウント専用です。become_user にパスワードがある場合は、``ansible_become_password`` でアカウントのパスワードを設定する必要があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:662
msgid "Become flags for Windows"
msgstr "Windows での Become フラグ"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:664
msgid "Ansible 2.5 added the ``become_flags`` parameter to the ``runas`` become method. This parameter can be set using the ``become_flags`` task directive or set in Ansible's configuration using ``ansible_become_flags``. The two valid values that are initially supported for this parameter are ``logon_type`` and ``logon_flags``."
msgstr "Ansible 2.5 では、``become_flags`` パラメーターを become メソッド ``runas`` に追加しました。このパラメーターは、``become_flags`` タスクディレクティブを使用するか、``ansible_become_flags`` を使用して Ansible の設定で設定できます。このパラメーターで最初にサポートされる 2 つの有効な値は ``logon_type`` と ``logon_flags`` です。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:670
msgid "These flags should only be set when becoming a normal user account, not a local service account like LocalSystem."
msgstr "これらのフラグは、LocalSystem などのローカルサービスアカウントではなく、通常のユーザーアカウントになる (become) 場合にのみ設定する必要があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:672
msgid "The key ``logon_type`` sets the type of logon operation to perform. The value can be set to one of the following:"
msgstr "鍵 ``logon_type`` は、実行するログオン操作のタイプを設定します。値は以下のいずれかに設定できます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:675
msgid "``interactive``: The default logon type. The process will be run under a context that is the same as when running a process locally. This bypasses all WinRM restrictions and is the recommended method to use."
msgstr "``interactive``: デフォルトのログオンタイプ。プロセスは、ローカルでプロセスを実行するときと同じコンテキストで実行されます。これにより、すべての WinRM 制限が回避され、推奨される方法です。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:679
msgid "``batch``: Runs the process under a batch context that is similar to a scheduled task with a password set. This should bypass most WinRM restrictions and is useful if the ``become_user`` is not allowed to log on interactively."
msgstr "``batch``: パスワードセットを使用してスケジュールされたタスクに似たバッチコンテキストでプロセスを実行します。これにより、ほとんどの WinRM 制限を回避する必要があり、``become_user`` が対話的にログインできない場合に役立ちます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:684
msgid "``new_credentials``: Runs under the same credentials as the calling user, but outbound connections are run under the context of the ``become_user`` and ``become_password``, similar to ``runas.exe /netonly``. The ``logon_flags`` flag should also be set to ``netcredentials_only``. Use this flag if the process needs to access a network resource (like an SMB share) using a different set of credentials."
msgstr "``new_credentials``: 呼び出し元ユーザーと同じ認証情報の下で実行されますが、発信側の接続は ``runas.exe /netonly`` と同様に ``become_user`` と ``become_password`` のコンテキストの下で実行されます。``logon_flags`` フラグは、``netcredentials_only`` にも設定する必要があります。このフラグは、プロセスが異なる認証情報セットを使用してネットワークリソース (SMB 共有など) にアクセスする必要がある場合に使用します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:691
msgid "``network``: Runs the process under a network context without any cached credentials. This results in the same type of logon session as running a normal WinRM process without credential delegation, and operates under the same restrictions."
msgstr "``network``: キャッシュされた認証情報なしで、ネットワークコンテキストでプロセスを実行します。これにより、認証情報の委譲を使用せずに通常の WinRM プロセスを実行するのと同じ種類のログオンセッションが実行され、同じ制限で動作します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:696
msgid "``network_cleartext``: Like the ``network`` logon type, but instead caches the credentials so it can access network resources. This is the same type of logon session as running a normal WinRM process with credential delegation."
msgstr "``network_cleartext``: ``network`` ログオンタイプなのですが、代わりに認証情報をキャッシュするため、ネットワークリソースにアクセスできます。これは、認証情報の委譲を使用して通常の WinRM プロセスを実行するのと同じタイプのログオンセッションです。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:700
msgid "For more information, see `dwLogonType <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-logonusera>`_."
msgstr "詳細情報は、「`dwLogonType <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-logonusera>`_」を参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:703
msgid "The ``logon_flags`` key specifies how Windows will log the user on when creating the new process. The value can be set to none or multiple of the following:"
msgstr "``logon_flags`` キーは、新規プロセスの作成時に Windows がユーザーをログに記録する方法を指定します。この値は、以下の複数の値に設定でき、値を設定しないこともできます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:706
msgid "``with_profile``: The default logon flag set. The process will load the user's profile in the ``HKEY_USERS`` registry key to ``HKEY_CURRENT_USER``."
msgstr "``with_profile``: デフォルトのログオンフラグセット。このプロセスは、``HKEY_USERS`` レジストリーキーのユーザーのプロファイルを ``HKEY_CURRENT_USER`` に読み込みます。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:709
msgid "``netcredentials_only``: The process will use the same token as the caller but will use the ``become_user`` and ``become_password`` when accessing a remote resource. This is useful in inter-domain scenarios where there is no trust relationship, and should be used with the ``new_credentials`` ``logon_type``."
msgstr "``netcredentials_only``: プロセスは呼び出し元と同じトークンを使用しますが、リモートリソースにアクセスする際には ``become_user`` と ``become_password`` を使用します。これは、信頼関係がないドメイン間シナリオで便利です。また、``new_credentials`` ``logon_type`` と共に使用する必要があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:714
msgid "By default ``logon_flags=with_profile`` is set, if the profile should not be loaded set ``logon_flags=`` or if the profile should be loaded with ``netcredentials_only``, set ``logon_flags=with_profile,netcredentials_only``."
msgstr "デフォルトでは ``logon_flags=with_profile`` が設定されていますが、プロファイルを読み込む必要がない場合は ``logon_flags=`` を設定するか、``netcredentials_only`` でプロファイルを読み込む必要がある場合は``logon_flags=with_profile,netcredentials_only`` を設定してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:718
msgid "For more information, see `dwLogonFlags <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-createprocesswithtokenw>`_."
msgstr "詳細情報は、「`dwLogonFlags <https://docs.microsoft.com/en-gb/windows/desktop/api/winbase/nf-winbase-createprocesswithtokenw>`_」を参照してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:720
msgid "Here are some examples of how to use ``become_flags`` with Windows tasks:"
msgstr "Windows タスクで ``become_flags`` を使用する例を以下に示します。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:748
msgid "Limitations of become on Windows"
msgstr "Windows における become 制限"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:750
msgid "Running a task with ``async`` and ``become`` on Windows Server 2008, 2008 R2 and Windows 7 only works when using Ansible 2.7 or newer."
msgstr "Windows Server 2008、2008 R2、Windows 7 で ``async`` および ``become`` を使用してタスクを実行できるのは、Ansible 2.7 以降を使用している場合のみです。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:753
msgid "By default, the become user logs on with an interactive session, so it must have the right to do so on the Windows host. If it does not inherit the ``SeAllowLogOnLocally`` privilege or inherits the ``SeDenyLogOnLocally`` privilege, the become process will fail. Either add the privilege or set the ``logon_type`` flag to change the logon type used."
msgstr "デフォルトでは、become ユーザーは対話型セッションでログオンするため、Windows ホストでこの権限を設定する必要があります。``SeAllowLogOnLocally`` 特権を継承しない場合、または ``SeDenyLogOnLocally`` 特権を継承する場合は become プロセスに失敗します。特権を追加するか、``logon_type`` フラグを設定して使用するログオンタイプを変更してください。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:759
msgid "Prior to Ansible version 2.3, become only worked when ``ansible_winrm_transport`` was either ``basic`` or ``credssp``. This restriction has been lifted since the 2.4 release of Ansible for all hosts except Windows Server 2008 (non R2 version)."
msgstr "Ansible バージョン 2.3 よりも前のバージョンでは、``ansible_winrm_transport`` が ``basic`` または ``credssp`` のいずれかでのみ機能していました。この制限は、Windows Server 2008 (R2 バージョン以外) を除くすべてのホストで 2.4 リリース以降に取り込まれました。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:764
msgid "The Secondary Logon service ``seclogon`` must be running to use ``ansible_become_method: runas``"
msgstr "``ansible_become_method: runas`` を使用するには、セカンダリーログオンサービス ``seclogon`` が実行している必要があります。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:766
msgid "The connection user must already be an Administrator on the Windows host to use ``runas``. The target become user does not need to be an Administrator though."
msgstr "``runas`` を使用するには、接続ユーザーがすでに Windows ホストの管理者である必要があります。ターゲット become ユーザーは管理者である必要はありません。"

#: ../../rst/playbook_guide/playbooks_privilege_escalation.rst:773
msgid "`Mailing List <https://groups.google.com/forum/#!forum/ansible-project>`_"
msgstr "`Mailing List <https://groups.google.com/forum/#!forum/ansible-project>`_"

#: ../../rst/playbook_guide/playbooks_prompts.rst:5
msgid "Interactive input: prompts"
msgstr "インタラクティブな入力: prompt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:7
msgid "If you want your playbook to prompt the user for certain input, add a 'vars_prompt' section. Prompting the user for variables lets you avoid recording sensitive data like passwords. In addition to security, prompts support flexibility. For example, if you use one playbook across multiple software releases, you could prompt for the particular release version."
msgstr "Playbook でユーザーに特定の入力を促したい場合は、「vars_prompt」セクションを追加します。ユーザーに変数の入力を促すことで、パスワードのような機密データの記録を回避することができます。セキュリティーのほかに、プロンプトは柔軟性をサポートします。たとえば、1 つの Playbook を複数のソフトウェアリリースで使用する場合は、特定のリリースバージョンの入力を促すことができます。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:12
msgid "Here is a most basic example:"
msgstr "以下は最も基本的な例です。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:33
msgid "The user input is hidden by default but it can be made visible by setting ``private: no``."
msgstr "ユーザー入力はデフォルトでは表示されませんが、``private: no`` を設定することで表示できます。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:36
msgid "Prompts for individual ``vars_prompt`` variables will be skipped for any variable that is already defined through the command line ``--extra-vars`` option, or when running from a non-interactive session (such as cron or Ansible AWX). See :ref:`passing_variables_on_the_command_line`."
msgstr "個別の ``vars_prompt`` 変数の入力を求めるプロンプトは、コマンドラインの ``--extra-vars`` オプションですでに定義されている変数や、非対話的なセッション (cron や Ansible AWX など) から実行する場合に省略されます。「:ref:`passing_variables_on_the_command_line`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:38
msgid "If you have a variable that changes infrequently, you can provide a default value that can be overridden."
msgstr "まれに変更する変数がある場合は、上書きできるデフォルト値を指定できます。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:49
msgid "Hashing values supplied by ``vars_prompt``"
msgstr "``vars_prompt`` により提供される値のハッシュ処理"

#: ../../rst/playbook_guide/playbooks_prompts.rst:51
msgid "You can hash the entered value so you can use it, for instance, with the user module to define a password:"
msgstr "入力された値をハッシュ処理することができます。したがって、たとえばユーザーモジュールで使用してパスワードを定義できます。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:64
msgid "If you have `Passlib <https://passlib.readthedocs.io/en/stable/>`_ installed, you can use any crypt scheme the library supports:"
msgstr "`Passlib <https://passlib.readthedocs.io/en/stable/>`_ をインストールしている場合は、ライブラリーがサポートする任意の crypt スキームを使用できます。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:66
msgid "*des_crypt* - DES Crypt"
msgstr "*des_crypt* - DES Crypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:67
msgid "*bsdi_crypt* - BSDi Crypt"
msgstr "*bsdi_crypt* - BSDi Crypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:68
msgid "*bigcrypt* - BigCrypt"
msgstr "*bigcrypt* - BigCrypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:69
msgid "*crypt16* - Crypt16"
msgstr "*crypt16* - Crypt16"

#: ../../rst/playbook_guide/playbooks_prompts.rst:70
#: ../../rst/playbook_guide/playbooks_prompts.rst:93
msgid "*md5_crypt* - MD5 Crypt"
msgstr "*md5_crypt* - MD5 Crypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:71
#: ../../rst/playbook_guide/playbooks_prompts.rst:92
msgid "*bcrypt* - BCrypt"
msgstr "*bcrypt* - BCrypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:72
msgid "*sha1_crypt* - SHA-1 Crypt"
msgstr "*sha1_crypt* - SHA-1 Crypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:73
msgid "*sun_md5_crypt* - Sun MD5 Crypt"
msgstr "*sun_md5_crypt* - Sun MD5 Crypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:74
#: ../../rst/playbook_guide/playbooks_prompts.rst:94
msgid "*sha256_crypt* - SHA-256 Crypt"
msgstr "*sha256_crypt* - SHA-256 Crypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:75
#: ../../rst/playbook_guide/playbooks_prompts.rst:95
msgid "*sha512_crypt* - SHA-512 Crypt"
msgstr "*sha512_crypt* - SHA-512 Crypt"

#: ../../rst/playbook_guide/playbooks_prompts.rst:76
msgid "*apr_md5_crypt* - Apache's MD5-Crypt variant"
msgstr "*apr_md5_crypt* - Apache's MD5-Crypt variant"

#: ../../rst/playbook_guide/playbooks_prompts.rst:77
msgid "*phpass* - PHPass' Portable Hash"
msgstr "*phpass* - PHPass' Portable Hash"

#: ../../rst/playbook_guide/playbooks_prompts.rst:78
msgid "*pbkdf2_digest* - Generic PBKDF2 Hashes"
msgstr "*pbkdf2_digest* - Generic PBKDF2 Hashes"

#: ../../rst/playbook_guide/playbooks_prompts.rst:79
msgid "*cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash"
msgstr "*cta_pbkdf2_sha1* - Cryptacular's PBKDF2 hash"

#: ../../rst/playbook_guide/playbooks_prompts.rst:80
msgid "*dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash"
msgstr "*dlitz_pbkdf2_sha1* - Dwayne Litzenberger's PBKDF2 hash"

#: ../../rst/playbook_guide/playbooks_prompts.rst:81
msgid "*scram* - SCRAM Hash"
msgstr "*scram* - SCRAM Hash"

#: ../../rst/playbook_guide/playbooks_prompts.rst:82
msgid "*bsd_nthash* - FreeBSD's MCF-compatible nthash encoding"
msgstr "*bsd_nthash* - FreeBSD's MCF 互換の nthash エンコーディング"

#: ../../rst/playbook_guide/playbooks_prompts.rst:84
msgid "The only parameters accepted are 'salt' or 'salt_size'. You can use your own salt by defining 'salt', or have one generated automatically using 'salt_size'. By default Ansible generates a salt of size 8."
msgstr "使用できるパラメーターは「salt」または「salt_size」のみです。「salt」を定義して独自のソルトを使用することも、「salt_size」を使用して自動的に生成されるソルトを使用することもできます。デフォルトでは、Ansible はサイズ 8 の salt を生成します。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:90
msgid "If you do not have Passlib installed, Ansible uses the `crypt <https://docs.python.org/3/library/crypt.html>`_ library as a fallback. Ansible supports at most four crypt schemes, depending on your platform at most the following crypt schemes are supported:"
msgstr "Passlib がインストールされていない場合、Ansible はフォールバックとして `crypt <https://docs.python.org/3/library/crypt.html>`_ ライブラリーを使用します。Ansible は最大で 4 つの暗号方式をサポートしていますが、プラットフォームによっては最大で以下の暗号方式をサポートしています。"

#: ../../rst/playbook_guide/playbooks_prompts.rst:101
msgid "Allowing special characters in ``vars_prompt`` values"
msgstr "``vars_prompt`` 値での特殊文字の許可"

#: ../../rst/playbook_guide/playbooks_prompts.rst:103
msgid "Some special characters, such as ``{`` and ``%`` can create templating errors. If you need to accept special characters, use the ``unsafe`` option:"
msgstr "``{`` や ``%`` などの特殊文字は、テンプレートエラーの作成が可能です。特殊文字を受け入れる必要がある場合は、``unsafe`` オプションを使用します。"

#: ../../rst/playbook_guide/playbooks_python_version.rst:5
msgid "Python3 in templates"
msgstr "テンプレート内の Python3"

#: ../../rst/playbook_guide/playbooks_python_version.rst:7
msgid "Ansible uses Jinja2 to take advantage of Python data types and standard functions in templates and variables. You can use these data types and standard functions to perform a rich set of operations on your data. However, if you use templates, you must be aware of differences between Python versions."
msgstr "Ansible は Jinja2 を使用して、テンプレートや変数に Python のデータ型や標準関数を活用しています。これらのデータ型や標準関数を利用することで、データに対して豊富な操作を行うことができます。ただし、テンプレートを使用する場合は、Python のバージョンによる違いに注意する必要があります。"

#: ../../rst/playbook_guide/playbooks_python_version.rst:11
msgid "These topics help you design templates that work on both Python2 and Python3. They might also help if you are upgrading from Python2 to Python3. Upgrading within Python2 or Python3 does not usually introduce changes that affect Jinja2 templates."
msgstr "これらのトピックは、Python2 と Python3 の両方で動作するテンプレートをデザインするのに役立ちます。また、Python2 から Python3 へのアップグレードの際にも役立つでしょう。Python2 や Python3 にアップグレードしても、通常は Jinja2 のテンプレートに影響を与えるような変更はありません。"

#: ../../rst/playbook_guide/playbooks_python_version.rst:16
msgid "Dictionary views"
msgstr "ディクショナリービュー"

#: ../../rst/playbook_guide/playbooks_python_version.rst:18
msgid "In Python2, the :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` methods return a list.  Jinja2 returns that to Ansible via a string representation that Ansible can turn back into a list."
msgstr "Python2 では、:meth:`dict.keys`、:meth:`dict.values`、および :meth:`dict.items` メソッドはリストを返します。Jinja2 は、Ansible がリストに戻ってきた文字列表現で Ansible に返します。"

#: ../../rst/playbook_guide/playbooks_python_version.rst:22
msgid "In Python3, those methods return a :ref:`dictionary view <python3:dict-views>` object. The string representation that Jinja2 returns for dictionary views cannot be parsed back into a list by Ansible.  It is, however, easy to make this portable by using the :func:`list <jinja2:jinja-filters.list>` filter whenever using :meth:`dict.keys`, :meth:`dict.values`, or :meth:`dict.items`."
msgstr "Python3 では、これらのメソッドは :ref:`ディクショナリービュー <python3:dict-views>` オブジェクトを返します。Jinja2 がディクショナリービューに返す文字列表現は、Ansible ではリストに解析し直すことができません。しかし、:meth:`dict.keys`、:meth:`dict.values`、または :meth:`dict.items` を使用する際には必ず :func:`list <jinja2:jinja-filters.list>` フィルターを使用することで、簡単に移植することができます。"

#: ../../rst/playbook_guide/playbooks_python_version.rst:45
msgid "dict.iteritems()"
msgstr "dict.iteritems()"

#: ../../rst/playbook_guide/playbooks_python_version.rst:47
msgid "Python2 dictionaries have :meth:`~dict.iterkeys`, :meth:`~dict.itervalues`, and :meth:`~dict.iteritems` methods."
msgstr "Python2 ディクショナリーには、:meth:`~dict.iterkeys` メソッド、:meth:`~dict.itervalues` メソッド、および :meth:`~dict.iteritems` メソッドがあります。"

#: ../../rst/playbook_guide/playbooks_python_version.rst:49
msgid "Python3 dictionaries do not have these methods. Use :meth:`dict.keys`, :meth:`dict.values`, and :meth:`dict.items` to make your playbooks and templates compatible with both Python2 and Python3."
msgstr "Python3 ディクショナリーにはこれらのメソッドがありません。:meth:`dict.keys`、:meth:`dict.values`、および :meth:`dict.items` を使用して、Playbook およびテンプレートを Python2 と Python3 の両方に対応させてください。"

#: ../../rst/playbook_guide/playbooks_python_version.rst:66
msgid "The :ref:`pb-py-compat-dict-views` entry for information on why the :func:`list filter <jinja2:jinja-filters.list>` is necessary here."
msgstr "ここで :func:`list filter <jinja2:jinja-filters.list>` が必要な理由は、:ref:`pb-py-compat-dict-views` エントリーを参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:5
msgid "Re-using Ansible artifacts"
msgstr "Ansible アーティファクトの再利用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:7
msgid "You can write a simple playbook in one very large file, and most users learn the one-file approach first. However, breaking your automation work up into smaller files is an excellent way to organize complex sets of tasks and reuse them. Smaller, more distributed artifacts let you re-use the same variables, tasks, and plays in multiple playbooks to address different use cases. You can use distributed artifacts across multiple parent playbooks or even multiple times within one playbook. For example, you might want to update your customer database as part of several different playbooks. If you put all the tasks related to updating your database in a tasks file or a role, you can re-use them in many playbooks while only maintaining them in one place."
msgstr "簡単な Playbook を非常に大きな 1 つのファイルに書くことができるため、ほとんどのユーザーはまず 1 つのファイルを使用した方法を学びます。しかし、自動化作業を小さなファイルに分割することは、複雑なタスクのセットを整理して再利用するための優れた方法です。小さく分散されたアーティファクトを使用して、同じ変数、タスク、プレイを複数の Playbook で再利用し、異なるユースケースに対応することができます。分散されたアーティファクトは、複数の親 Playbook にまたがって使用することも、1 つの Playbook 内で複数回使用することもできます。たとえば、複数の Playbook の一部として顧客データベースを更新する場合があります。データベースの更新に関連するすべてのタスクをタスクファイルにまとめておけば、それらを 1 カ所で管理するだけで、多くの Playbook で再利用することができます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:13
msgid "Creating re-usable files and roles"
msgstr "再利用可能なファイルおよびロールの作成"

#: ../../rst/playbook_guide/playbooks_reuse.rst:15
msgid "Ansible offers four distributed, re-usable artifacts: variables files, task files, playbooks, and roles."
msgstr "Ansible は、変数ファイル、タスクファイル、Playbook、およびロールの 4 つに分散した再利用可能なアーティファクトを提供します。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:17
msgid "A variables file contains only variables."
msgstr "変数ファイルには変数のみが含まれます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:18
msgid "A task file contains only tasks."
msgstr "タスクファイルにはタスクのみが含まれます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:19
msgid "A playbook contains at least one play, and may contain variables, tasks, and other content. You can re-use tightly focused playbooks, but you can only re-use them statically, not dynamically."
msgstr "Playbook には、少なくとも 1 つのプレイが含まれており、変数、タスク、その他のコンテンツを含むことができます。厳密に焦点を絞った Playbook は再利用できますが、動的にではなく静的にしか再利用できません。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:20
msgid "A role contains a set of related tasks, variables, defaults, handlers, and even modules or other plugins in a defined file-tree. Unlike variables files, task files, or playbooks, roles can be easily uploaded and shared via Ansible Galaxy. See :ref:`playbooks_reuse_roles` for details about creating and using roles."
msgstr "ロールには、関連するタスク、変数、デフォルト、ハンドラー、さらにはモジュールや他のプラグインのセットが、定義されたファイルツリーに格納されています。変数ファイル、タスクファイル、Playbook とは異なり、ロールは Ansible Galaxy で簡単にアップロードして共有することができます。ロールの作成と使用の詳細については、「:ref:`playbooks_reuse_roles`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:25
msgid "Re-using playbooks"
msgstr "Playbook の再利用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:27
msgid "You can incorporate multiple playbooks into a main playbook. However, you can only use imports to re-use playbooks. For example:"
msgstr "複数の Playbook をメインの Playbook に組み込むことができますが、インポートのみを使用して Playbook を再使用できます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:34
msgid "Importing incorporates playbooks in other playbooks statically. Ansible runs the plays and tasks in each imported playbook in the order they are listed, just as if they had been defined directly in the main playbook."
msgstr "インポートでは、他の Playbook に静的に Playbook を組み込みます。Ansible は、インポートした各 Playbook 内のプレイやタスクを、メインの Playbook で直接定義した場合と同様に、リストに記載された順に実行します。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:36
msgid "You can select which playbook you want to import at runtime by defining your imported playbook filename with a variable, then passing the variable with either ``--extra-vars`` or the ``vars`` keyword. For example:"
msgstr "変数でインポートされた Playbook ファイルを定義し、``--extra-vars`` または ``vars`` キーワードで変数を渡すことで、ランタイム時にインポートする Playbook を選択できます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:45
msgid "If you run this playbook with ``ansible-playbook my_playbook -e import_from_extra_var=other_playbook.yml``, Ansible imports both one_playbook.yml and other_playbook.yml."
msgstr "``ansible-playbook my_playbook -e import_from_extra_var=other_playbook.yml`` を使用してこの Playbook を実行すると、Ansible は one_playbook.yml と other_playbook.yml の両方をインポートします。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:48
msgid "When to turn a playbook into a role"
msgstr "Playbook をロールに変換するタイミング"

#: ../../rst/playbook_guide/playbooks_reuse.rst:50
msgid "For some use cases, simple playbooks work well. However, starting at a certain level of complexity, roles work better than playbooks. A role lets you store your defaults, handlers, variables, and tasks in separate directories, instead of in a single long document. Roles are easy to share on Ansible Galaxy. For complex use cases, most users find roles easier to read, understand, and maintain than all-in-one playbooks."
msgstr "一部のユースケースでは、簡単な Playbook は適切に機能します。ただし、複雑さがあるレベルを超えると、ロールは Playbook よりも優れています。ロールを使用すると、デフォルト、ハンドラー、変数、タスクを、単一の長いドキュメントではなく、個別のディレクトリーに保存できます。ロールは、Ansible Galaxy で簡単に共有できます。複雑なユースケースでは、ほとんどのユーザーは、オールインワンの Playbook よりもロールの方が読んで理解して維持するのが簡単だと感じています。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:53
msgid "Re-using files and roles"
msgstr "ファイルおよびロールの再利用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:55
msgid "Ansible offers two ways to re-use files and roles in a playbook: dynamic and static."
msgstr "Ansible は、Playbook でファイルとロールを再利用する 2 つの方法 (動的および静的) を提供します。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:57
msgid "For dynamic re-use, add an ``include_*`` task in the tasks section of a play:"
msgstr "動的再利用には、プレイの tasks セクションに ``include_*`` タスクを追加します。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:59
msgid ":ref:`include_role <include_role_module>`"
msgstr ":ref:`include_role <include_role_module>`"

#: ../../rst/playbook_guide/playbooks_reuse.rst:60
msgid ":ref:`include_tasks <include_tasks_module>`"
msgstr ":ref:`include_tasks <include_tasks_module>`"

#: ../../rst/playbook_guide/playbooks_reuse.rst:61
msgid ":ref:`include_vars <include_vars_module>`"
msgstr ":ref:`include_vars <include_vars_module>`"

#: ../../rst/playbook_guide/playbooks_reuse.rst:63
msgid "For static re-use, add an ``import_*`` task in the tasks section of a play:"
msgstr "静的な再利用の場合は、プレイの tasks セクションに ``import_*`` タスクを追加します。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:65
msgid ":ref:`import_role <import_role_module>`"
msgstr ":ref:`import_role <import_role_module>`"

#: ../../rst/playbook_guide/playbooks_reuse.rst:66
msgid ":ref:`import_tasks <import_tasks_module>`"
msgstr ":ref:`import_tasks <import_tasks_module>`"

#: ../../rst/playbook_guide/playbooks_reuse.rst:68
msgid "Task include and import statements can be used at arbitrary depth."
msgstr "タスクの include 文および import 文は任意の深さで使用できます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:70
msgid "You can still use the bare :ref:`roles <roles_keyword>` keyword at the play level to incorporate a role in a playbook statically. However, the bare :ref:`include <include_module>` keyword, once used for both task files and playbook-level includes, is now deprecated."
msgstr "プレイレベルで裸の :ref:`roles <roles_keyword>` キーワードを使用して、ロールを静的に Playbook に組み込むことは可能です。しかし、かつてタスクファイルと Playbook レベルのインクルードの両方に使用されていた裸の :ref:`include <include_module>` キーワードは、現在では非推奨となっています。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:73
msgid "Includes: dynamic re-use"
msgstr "インクルード: 動的再利用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:75
msgid "Including roles, tasks, or variables adds them to a playbook dynamically. Ansible processes included files and roles as they come up in a playbook, so included tasks can be affected by the results of earlier tasks within the top-level playbook. Included roles and tasks are similar to handlers - they may or may not run, depending on the results of other tasks in the top-level playbook."
msgstr "ロール、タスク、または変数をインクルードすると、Playbook に動的に追加されます。Ansible は、Playbook に同梱されるインクルードファイルやロールを処理するため、インクルードタスクは、トップレベルの Playbook 内の以前のタスクの結果によって影響を受ける可能性があります。インクルードされるロールやタスクは、ハンドラーと同様、トップレベルの Playbook 内の他のタスクの結果に応じて、実行されたりされなかったりします。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:77
msgid "The primary advantage of using ``include_*`` statements is looping. When a loop is used with an include, the included tasks or role will be executed once for each item in the loop."
msgstr "``include_*`` 文を使用する主な利点はループです。インクルードでループが使用されると、インクルードされたタスクまたはロールがループの各項目に対して 1 回実行されます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:79
msgid "The filenames for included roles, tasks, and vars are templated before inclusion."
msgstr "含まれるロール、タスク、および変数のファイル名は、包含前にテンプレート化されます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:81
msgid "You can pass variables into includes. See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence."
msgstr "変数をインクルードに渡すことができます。変数の継承と優先順位の詳細は、「:ref:`ansible_variable_precedence`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:84
msgid "Imports: static re-use"
msgstr "インポート: 静的再利用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:86
msgid "Importing roles, tasks, or playbooks adds them to a playbook statically. Ansible pre-processes imported files and roles before it runs any tasks in a playbook, so imported content is never affected by other tasks within the top-level playbook."
msgstr "ロール、タスク、または Playbook をインポートすると、それらが静的に Playbook に追加されます。Ansible は、インポートされたファイルやロールを Playbook 内のタスクを実行する前に前処理するため、インポートされたコンテンツがトップレベルの Playbook 内の他のタスクの影響を受けることはありません。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:88
msgid "The filenames for imported roles and tasks support templating, but the variables must be available when Ansible is pre-processing the imports. This can be done with the ``vars`` keyword or by using ``--extra-vars``."
msgstr "インポートしたロールおよびタスクのファイル名はテンプレートをサポートしますが、Ansible がインポートの事前処理時に変数が利用できるようにする必要があります。これは、``vars`` キーワードまたは ``--extra-vars`` を使用して実行できます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:90
msgid "You can pass variables to imports. You must pass variables if you want to run an imported file more than once in a playbook. For example:"
msgstr "インポートには変数を渡すことができます。インポートしたファイルを 1 つの Playbook で複数回実行する場合は、変数を渡す必要があります。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:107
msgid "See :ref:`ansible_variable_precedence` for more details on variable inheritance and precedence."
msgstr "変数の継承および優先順位に関する詳細は、「:ref:`ansible_variable_precedence`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:112
msgid "Comparing includes and imports: dynamic and static re-use"
msgstr "インクルードとインポートの比較: 動的再利用および静的再利用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:114
msgid "Each approach to re-using distributed Ansible artifacts has advantages and limitations. You may choose dynamic re-use for some playbooks and static re-use for others. Although you can use both dynamic and static re-use in a single playbook, it is best to select one approach per playbook. Mixing static and dynamic re-use can introduce difficult-to-diagnose bugs into your playbooks. This table summarizes the main differences so you can choose the best approach for each playbook you create."
msgstr "分散した Ansible のアーティファクトを再利用する方法には、それぞれ利点と制限があります。一部の Playbook では動的再利用を行い、他の Playbook では静的再利用を行うことができます。1 つの Playbook で動的再利用と静的再利用の両方を使用することもできますが、Playbook ごとに 1 つのアプローチを選択するのが最善です。静的再利用と動的再利用を混在させると、診断が困難なバグが Playbook に発生する可能性があります。この表で主な違いをまとめています。作成する Playbook ごとに最適な方法を選択してください。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:120
msgid "Include_*"
msgstr "Include_*"

#: ../../rst/playbook_guide/playbooks_reuse.rst:120
msgid "Import_*"
msgstr "Import_*"

#: ../../rst/playbook_guide/playbooks_reuse.rst:122
msgid "Type of re-use"
msgstr "再利用の種類"

#: ../../rst/playbook_guide/playbooks_reuse.rst:122
msgid "Dynamic"
msgstr "動的"

#: ../../rst/playbook_guide/playbooks_reuse.rst:122
msgid "Static"
msgstr "静的"

#: ../../rst/playbook_guide/playbooks_reuse.rst:124
msgid "When processed"
msgstr "処理時"

#: ../../rst/playbook_guide/playbooks_reuse.rst:124
msgid "At runtime, when encountered"
msgstr "ランタイム時に (発生した場合)"

#: ../../rst/playbook_guide/playbooks_reuse.rst:124
msgid "Pre-processed during playbook parsing"
msgstr "Playbook の解析中に事前処理"

#: ../../rst/playbook_guide/playbooks_reuse.rst:126
msgid "Task or play"
msgstr "タスクまたはプレイ"

#: ../../rst/playbook_guide/playbooks_reuse.rst:126
msgid "All includes are tasks"
msgstr "インクルードはすべてタスク"

#: ../../rst/playbook_guide/playbooks_reuse.rst:126
msgid "``import_playbook`` cannot be a task"
msgstr "``import_playbook`` タスクにすることはできない"

#: ../../rst/playbook_guide/playbooks_reuse.rst:128
msgid "Task options"
msgstr "タスクオプション"

#: ../../rst/playbook_guide/playbooks_reuse.rst:128
msgid "Apply only to include task itself"
msgstr "タスク自体を含める場合にのみ適用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:128
msgid "Apply to all child tasks in import"
msgstr "インポート中のすべての子タスクに適用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:130
msgid "Calling from loops"
msgstr "ループからの呼び出し"

#: ../../rst/playbook_guide/playbooks_reuse.rst:130
msgid "Executed once for each loop item"
msgstr "各ループ項目に対して 1 回実行"

#: ../../rst/playbook_guide/playbooks_reuse.rst:130
msgid "Cannot be used in a loop"
msgstr "ループでは使用できない"

#: ../../rst/playbook_guide/playbooks_reuse.rst:132
msgid "Using ``--list-tags``"
msgstr "``--list-tags`` の使用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:132
msgid "Tags within includes not listed"
msgstr "掲載されていないインクルード内のタグ"

#: ../../rst/playbook_guide/playbooks_reuse.rst:132
msgid "All tags appear with ``--list-tags``"
msgstr "すべてのタグが ``--list-tags`` で表示"

#: ../../rst/playbook_guide/playbooks_reuse.rst:134
msgid "Using ``--list-tasks``"
msgstr "``--list-tasks`` の使用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:134
msgid "Tasks within includes not listed"
msgstr "リストにないインクルード内のタスク"

#: ../../rst/playbook_guide/playbooks_reuse.rst:134
msgid "All tasks appear with ``--list-tasks``"
msgstr "すべてのタスクが ``--list-tasks`` で表示"

#: ../../rst/playbook_guide/playbooks_reuse.rst:136
msgid "Cannot trigger handlers within includes"
msgstr "インクルード内でハンドラーをトリガーできない"

#: ../../rst/playbook_guide/playbooks_reuse.rst:136
msgid "Can trigger individual imported handlers"
msgstr "インポートした個別のハンドラーをトリガーできる"

#: ../../rst/playbook_guide/playbooks_reuse.rst:138
msgid "Using ``--start-at-task``"
msgstr "``--start-at-task`` の使用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:138
msgid "Cannot start at tasks within includes"
msgstr "インクルード内のタスクで開始できない"

#: ../../rst/playbook_guide/playbooks_reuse.rst:138
msgid "Can start at imported tasks"
msgstr "インポートされたタスクから始められる"

#: ../../rst/playbook_guide/playbooks_reuse.rst:140
msgid "Using inventory variables"
msgstr "インベントリー変数の使用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:140
msgid "Can ``include_*: {{ inventory_var }}``"
msgstr "``include_*: {{ inventory_var }}`` が使用できる"

#: ../../rst/playbook_guide/playbooks_reuse.rst:140
msgid "Cannot ``import_*: {{ inventory_var }}``"
msgstr "``import_*: {{ inventory_var }}`` が使用できない"

#: ../../rst/playbook_guide/playbooks_reuse.rst:142
msgid "With playbooks"
msgstr "Playbook の使用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:142
msgid "No ``include_playbook``"
msgstr "``include_playbook`` なし"

#: ../../rst/playbook_guide/playbooks_reuse.rst:142
msgid "Can import full playbooks"
msgstr "完全な Playbook をインポートできる"

#: ../../rst/playbook_guide/playbooks_reuse.rst:144
msgid "With variables files"
msgstr "変数ファイルの使用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:144
msgid "Can include variables files"
msgstr "変数ファイルを含めることができる"

#: ../../rst/playbook_guide/playbooks_reuse.rst:144
msgid "Use ``vars_files:`` to import variables"
msgstr "``vars_files:`` を使用して変数をインポート"

#: ../../rst/playbook_guide/playbooks_reuse.rst:150
msgid "There are also big differences in resource consumption and performance, imports are quite lean and fast, while includes require a lot of management and accounting."
msgstr "また、リソースの消費やパフォーマンスに大きな違いがあり、インポートは非常に柔軟で高速ですが、インクルードには多くの管理と会計が必要になります。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:154
msgid "Re-using tasks as handlers"
msgstr "タスクをハンドラーとして再利用"

#: ../../rst/playbook_guide/playbooks_reuse.rst:156
msgid "You can also use includes and imports in the :ref:`handlers` section of a playbook. For instance, if you want to define how to restart Apache, you only have to do that once for all of your playbooks. You might make a ``restarts.yml`` file that looks like:"
msgstr "Playbook の :ref:`handlers` セクションでインクルードおよびインポートを使用することもできます。たとえば、Apache の再起動方法を定義する場合は、すべての Playbook に対して一度だけ設定する必要があります。``restarts.yml`` ファイルを以下のように行うことができます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:171
msgid "You can trigger handlers from either an import or an include, but the procedure is different for each method of re-use. If you include the file, you must notify the include itself, which triggers all the tasks in ``restarts.yml``. If you import the file, you must notify the individual task(s) within ``restarts.yml``. You can mix direct tasks and handlers with included or imported tasks and handlers."
msgstr "ハンドラーはインポートとインクルードのどちらからでも起動できますが、その手順は再利用の方法ごとに異なります。ファイルをインクルードする場合は、インクルード自体を通知する必要があり、これにより ``restarts.yml`` のすべてのタスクが発生します。ファイルをインポートする場合は、``restarts.yml`` 内の個々のタスクを通知する必要があります。直接的なタスクやハンドラーと、インクルードまたはインポートされたタスクやハンドラーを混在させることができます。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:174
msgid "Triggering included (dynamic) handlers"
msgstr "インクルード (動的) ハンドラーのトリガー"

#: ../../rst/playbook_guide/playbooks_reuse.rst:176
msgid "Includes are executed at run-time, so the name of the include exists during play execution, but the included tasks do not exist until the include itself is triggered. To use the ``Restart apache`` task with dynamic re-use, refer to the name of the include itself. This approach triggers all tasks in the included file as handlers. For example, with the task file shown above:"
msgstr "インクルードはランタイムに実行されるため、インクルードの名前はプレイの実行中に存在しますが、インクルードされたタスクはインクルード自体がトリガーされるまで存在しません。``Restart apache`` タスクを動的再利用で使用するには、インクルード自体の名前を参照します。この方法では、インクルードファイル内のすべてのタスクがハンドラーとしてトリガーされます。たとえば、上に示したタスクファイルでは、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:190
msgid "Triggering imported (static) handlers"
msgstr "インポートされた (静的) ハンドラーのトリガー"

#: ../../rst/playbook_guide/playbooks_reuse.rst:192
msgid "Imports are processed before the play begins, so the name of the import no longer exists during play execution, but the names of the individual imported tasks do exist. To use the ``Restart apache`` task with static re-use, refer to the name of each task or tasks within the imported file. For example, with the task file shown above:"
msgstr "インポートは再生開始前に処理されるため、インポートの名前は再生実行中には存在しませんが、インポートされた各タスクの名前は存在します。``Restart apache`` タスクを静的に再利用して使用するには、インポートされたファイル内の各タスクの名前を参照する必要があります。たとえば、上述のタスクファイルであれば、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_reuse.rst:209
msgid ":ref:`utilities_modules`"
msgstr ":ref:`utilities_modules`"

#: ../../rst/playbook_guide/playbooks_reuse.rst:210
msgid "Documentation of the ``include*`` and ``import*`` modules discussed here."
msgstr "ここで説明する ``include*`` モジュールおよび ``import*`` モジュールに関するドキュメント"

#: ../../rst/playbook_guide/playbooks_reuse.rst:212
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:595
#: ../../rst/playbook_guide/playbooks_roles.rst:16
msgid "Review the basic Playbook language features"
msgstr "基本的な Playbook 言語機能の確認"

#: ../../rst/playbook_guide/playbooks_reuse.rst:214
msgid "All about variables in playbooks"
msgstr "Playbook の変数の詳細のすべて"

#: ../../rst/playbook_guide/playbooks_reuse.rst:216
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:601
msgid "Conditionals in playbooks"
msgstr "Playbook の条件"

#: ../../rst/playbook_guide/playbooks_reuse.rst:218
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:603
msgid "Loops in playbooks"
msgstr "Playbook のループ"

#: ../../rst/playbook_guide/playbooks_reuse.rst:221
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:590
#: ../../rst/playbook_guide/playbooks_roles.rst:13
msgid ":ref:`ansible_galaxy`"
msgstr ":ref:`ansible_galaxy`"

#: ../../rst/playbook_guide/playbooks_reuse.rst:222
#: ../../rst/playbook_guide/playbooks_roles.rst:14
msgid "How to share roles on galaxy, role management"
msgstr "Galaxy (ロール管理) におけるロールの共有方法"

#: ../../rst/playbook_guide/playbooks_reuse.rst:223
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:610
msgid "`GitHub Ansible examples <https://github.com/ansible/ansible-examples>`_"
msgstr "`GitHub Ansible の例 <https://github.com/ansible/ansible-examples>`_"

#: ../../rst/playbook_guide/playbooks_reuse.rst:224
#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:611
msgid "Complete playbook files from the GitHub project source"
msgstr "Github プロジェクトソースの完全な Playbook ファイル"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:5
msgid "Roles"
msgstr "ロール"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:7
msgid "Roles let you automatically load related vars, files, tasks, handlers, and other Ansible artifacts based on a known file structure. After you group your content in roles, you can easily reuse them and share them with other users."
msgstr "ロールを使用すると、既知のファイル構造に基づいて、関連の変数、ファイル、タスク、ハンドラー、およびその他の Ansible アーティファクトを自動的に読み込むことができます。ロール内のコンテンツをグループ化した後、簡単に再利用でき、他のユーザーと共有できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:13
msgid "Role directory structure"
msgstr "ロールのディレクトリー構造"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:15
msgid "An Ansible role has a defined directory structure with eight main standard directories. You must include at least one of these directories in each role. You can omit any directories the role does not use. For example:"
msgstr "Ansible ロールには、8 つの主要な標準ディレクトリーを持つ定義されたディレクトリー構造があります。各ロールには、ディレクトリーを少なくとも 1 つ含める必要があります。ロールが使用されないディレクトリーは除外できます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:26
msgid "By default Ansible will look in each directory within a role for a ``main.yml`` file for relevant content (also ``main.yaml`` and ``main``):"
msgstr "デフォルトでは、Ansible はロール内の各ディレクトリーで、関連するコンテンツ (``main.yaml`` および ``main``) について ``main.yml`` ファイルを検索します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:28
msgid "``tasks/main.yml`` - the main list of tasks that the role executes."
msgstr "``tasks/main.yml`` - ロールが実行するタスクの主なリスト。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:29
msgid "``handlers/main.yml`` - handlers, which may be used within or outside this role."
msgstr "``handlers/main.yml`` - このロール内外で使用できるハンドラー。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:30
msgid "``library/my_module.py`` - modules, which may be used within this role (see :ref:`embedding_modules_and_plugins_in_roles` for more information)."
msgstr "``library/my_module.py`` - このロール内で使用できるモジュール (詳細は「:ref:`embedding_modules_and_plugins_in_roles`」を参照)。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:31
msgid "``defaults/main.yml`` - default variables for the role (see :ref:`playbooks_variables` for more information). These variables have the lowest priority of any variables available, and can be easily overridden by any other variable, including inventory variables."
msgstr "``defaults/main.yml`` - ロールのデフォルト変数 (詳細は「:ref:`playbooks_variables`」を参照)。これらの変数には、利用可能な変数の中で一番低い優先順位があり、インベントリー変数など、他の変数で簡単に上書きできます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:32
msgid "``vars/main.yml`` - other variables for the role (see :ref:`playbooks_variables` for more information)."
msgstr "``vars/main.yml`` - ロールの他の変数 (詳細は :ref:`playbooks_variables` を参照)。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:33
msgid "``files/main.yml`` - files that the role deploys."
msgstr "``files/main.yml`` - ロールがデプロイするファイル。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:34
msgid "``templates/main.yml`` - templates that the role deploys."
msgstr "``templates/main.yml`` - ロールがデプロイするテンプレート。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:35
msgid "``meta/main.yml`` - metadata for the role, including role dependencies and optional Galaxy metadata such as platforms supported."
msgstr "``meta/main.yml`` - ロールの依存関係やサポートされているプラットフォームなどの任意の Galaxy メタデータを含む、ロールのメタデータ。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:37
msgid "You can add other YAML files in some directories. For example, you can place platform-specific tasks in separate files and refer to them in the ``tasks/main.yml`` file:"
msgstr "他の YAML ファイルを一部のディレクトリーに追加できます。たとえば、プラットフォーム固有のタスクを別々のファイルに配置し、それらを ``tasks/main.yml`` ファイルで参照できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:62
msgid "Roles may also include modules and other plugin types in a directory called ``library``. For more information, please refer to :ref:`embedding_modules_and_plugins_in_roles` below."
msgstr "ロールには、``library`` と呼ばれるディレクトリーにモジュールおよびその他のプラグインタイプが含まれる場合があります。詳細は、以下の「:ref:`embedding_modules_and_plugins_in_roles`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:67
msgid "Storing and finding roles"
msgstr "ロールの保存および検索"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:69
msgid "By default, Ansible looks for roles in the following locations:"
msgstr "デフォルトでは、Ansible は以下の場所でロールを検索します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:71
msgid "in collections, if you are using them"
msgstr "コレクションでそれらを使用している場合"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:72
msgid "in a directory called ``roles/``, relative to the playbook file"
msgstr "``roles/`` という名前のディレクトリー (Playbook ファイルへの相対パス) で"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:73
msgid "in the configured :ref:`roles_path <DEFAULT_ROLES_PATH>`. The default search path is ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles``."
msgstr "設定された :ref:`roles_path <DEFAULT_ROLES_PATH>` では、デフォルトの検索パスは ``~/.ansible/roles:/usr/share/ansible/roles:/etc/ansible/roles`` です。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:74
msgid "in the directory where the playbook file is located"
msgstr "Playbook ファイルが配置されているディレクトリーで"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:76
msgid "If you store your roles in a different location, set the :ref:`roles_path <DEFAULT_ROLES_PATH>` configuration option so Ansible can find your roles. Checking shared roles into a single location makes them easier to use in multiple playbooks. See :ref:`intro_configuration` for details about managing settings in ansible.cfg."
msgstr "ロールを別の場所に保存する場合は、Ansible がロールを見つけることができるように、:ref:`roles_path <DEFAULT_ROLES_PATH>` 設定オプションを設定します。共有ロールを 1 つの場所にチェックインすることで、複数の Playbook で簡単に使用できます。ansible.cfg の設定に関する詳細は、「:ref:`intro_configuration`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:78
msgid "Alternatively, you can call a role with a fully qualified path:"
msgstr "または、完全修飾パスでロールを呼び出すことができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:88
msgid "Using roles"
msgstr "ロールの使用"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:90
msgid "You can use roles in three ways:"
msgstr "以下の 3 つの方法でロールを使用できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:92
msgid "at the play level with the ``roles`` option: This is the classic way of using roles in a play."
msgstr "``roles`` オプションを使用してプレイレベルで: プレイでロールを使用する従来の方式です。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:93
msgid "at the tasks level with ``include_role``: You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``."
msgstr "``include_role`` を使用してタスクレベルで: ``include_role`` を使用してプレイの ``tasks`` セクションのどこからでもロールを動的に再利用できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:94
msgid "at the tasks level with ``import_role``: You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``."
msgstr "``import_role`` を使用してタスクレベルで: ``import_role`` を使用してプレイの ``tasks`` セクションのどこからでもロールを静的に再利用できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:99
msgid "Using roles at the play level"
msgstr "プレイレベルでのロールの使用"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:101
msgid "The classic (original) way to use roles is with the ``roles`` option for a given play:"
msgstr "ロールを使用する従来の (元の) 方法は、特定のプレイの ``roles`` オプションを使用して行います。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:111
msgid "When you use the ``roles`` option at the play level, for each role 'x':"
msgstr "プレイレベルで ``roles`` オプションを使用する場合は、各ロール「x」に対して以下のように設定します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:113
msgid "If roles/x/tasks/main.yml exists, Ansible adds the tasks in that file to the play."
msgstr "roles/x/tasks/main.yml が存在する場合、Ansible はそのファイルのタスクをプレイに追加します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:114
msgid "If roles/x/handlers/main.yml exists, Ansible adds the handlers in that file to the play."
msgstr "roles/x/handlers/main.yml が存在する場合、Ansible はそのファイルのハンドラーをプレイに追加します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:115
msgid "If roles/x/vars/main.yml exists, Ansible adds the variables in that file to the play."
msgstr "roles/x/vars/main.yml が存在する場合、Ansible はそのファイルの変数をプレイに追加します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:116
msgid "If roles/x/defaults/main.yml exists, Ansible adds the variables in that file to the play."
msgstr "roles/x/defaults/main.yml が存在する場合、Ansible はそのファイルの変数をプレイに追加します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:117
msgid "If roles/x/meta/main.yml exists, Ansible adds any role dependencies in that file to the list of roles."
msgstr "roles/x/meta/main.yml が存在する場合、Ansible はそのファイル内のすべてのロールの依存関係をロールのリストに追加します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:118
msgid "Any copy, script, template or include tasks (in the role) can reference files in roles/x/{files,templates,tasks}/ (dir depends on task) without having to path them relatively or absolutely."
msgstr "コピー、スクリプト、テンプレート、またはインクルードタスク (ロール内) は、相対パスや絶対パスを必要とせずに roles/x/{files,templates,tasks}/ (ディレクトリーはタスクに依存します) のファイルを参照できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:120
msgid "When you use the ``roles`` option at the play level, Ansible treats the roles as static imports and processes them during playbook parsing. Ansible executes each play in this order:"
msgstr "プレイレベルで ``roles`` オプションを使用すると、Ansible はロールを静的インポートとして処理し、Playbook の解析時に処理します。Ansible は以下の順序でそれぞれのプレイを実行します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:122
msgid "Any ``pre_tasks`` defined in the play."
msgstr "プレイに定義されているすべての ``pre_tasks``。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:123
msgid "Any handlers triggered by pre_tasks."
msgstr "ハンドラーは、pre_tasks により誘発されます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:124
msgid "Each role listed in ``roles:``, in the order listed. Any role dependencies defined in the role's ``meta/main.yml`` run first, subject to tag filtering and conditionals. See :ref:`role_dependencies` for more details."
msgstr "``roles:`` に一覧表示される順序で、各ロールがリストされます。ロールの ``meta/main.yml`` で定義されたロール依存関係は、タグのフィルタリングおよび条件に基づいて最初に実行されます。詳細は、「:ref:`role_dependencies`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:125
msgid "Any ``tasks`` defined in the play."
msgstr "プレイに定義されているすべての ``tasks``。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:126
msgid "Any handlers triggered by the roles or tasks."
msgstr "ロールやタスクによってトリガーされるすべてのハンドラー。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:127
msgid "Any ``post_tasks`` defined in the play."
msgstr "プレイに定義されているすべての ``post_tasks``。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:128
msgid "Any handlers triggered by post_tasks."
msgstr "ハンドラーは、post_tasks により誘発されます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:131
msgid "If using tags with tasks in a role, be sure to also tag your pre_tasks, post_tasks, and role dependencies and pass those along as well, especially if the pre/post tasks and role dependencies are used for monitoring outage window control or load balancing. See :ref:`tags` for details on adding and using tags."
msgstr "ロール内のタスクにタグを使用する場合は、pre_tasks、post_tasks、およびロールの依存関係にもタグを付けて、それらも渡すようにしてください。特に、事前または事後のタスクおよびロールの依存関係が、停止時のウィンドウ制御や負荷分散の監視に使用されている場合は、そのようにしてください。タグの追加と使用の詳細は、「:ref:`tags`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:133
msgid "You can pass other keywords to the ``roles`` option:"
msgstr "他のキーワードを ``roles`` オプションに渡すことができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:152
msgid "When you add a tag to the ``role`` option, Ansible applies the tag to ALL tasks within the role."
msgstr "タグを ``role`` オプションに追加すると、Ansible はタグをロール内のすべてのタスクに適用します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:154
msgid "When using ``vars:`` within the ``roles:`` section of a playbook, the variables are added to the play variables, making them available to all tasks within the play before and after the role. This behavior can be changed by :ref:`DEFAULT_PRIVATE_ROLE_VARS`."
msgstr "Playbook の ``roles:`` セクションで ``vars:`` を使用すると、変数がプレイ変数に追加され、ロールの前後にプレイ内のすべてのタスクで利用できるようになります。この動作は :ref:`DEFAULT_PRIVATE_ROLE_VARS` で変更できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:157
msgid "Including roles: dynamic reuse"
msgstr "ロールの追加: 動的な再利用"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:159
msgid "You can reuse roles dynamically anywhere in the ``tasks`` section of a play using ``include_role``. While roles added in a ``roles`` section run before any other tasks in a play, included roles run in the order they are defined. If there are other tasks before an ``include_role`` task, the other tasks will run first."
msgstr "``include_role`` を使用すると、プレイの ``tasks`` セクション内の任意の場所でロールを動的に再利用することができます。``roles`` セクションで追加されたロールはプレイ内の他のタスクよりも先に実行されますが、含まれるロールは定義された順に実行されます。``include_role`` のタスクの前に他のタスクがある場合は、他のタスクが先に実行します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:161
msgid "To include a role:"
msgstr "ロールを指定するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:180
msgid "You can pass other keywords, including variables and tags, when including roles:"
msgstr "ロールを含める際には、変数やタグなど、他のキーワードを渡すことができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:196
msgid "When you add a :ref:`tag <tags>` to an ``include_role`` task, Ansible applies the tag `only` to the include itself. This means you can pass ``--tags`` to run only selected tasks from the role, if those tasks themselves have the same tag as the include statement. See :ref:`selective_reuse` for details."
msgstr "``include_role`` タスクに :ref:`tag <tags>` を追加すると、Ansible はインクルード自体に `only` というタグを適用します。つまり、``--tags`` を渡して、ロールから選択されたタスクのみを実行することができます。ただし、それらのタスク自体が include 文と同じタグを持っている場合に限ります。詳細は、「:ref:`selective_reuse`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:198
msgid "You can conditionally include a role:"
msgstr "ロールを条件付きで含めることができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:211
msgid "Importing roles: static reuse"
msgstr "ロールのインポート: 静的再利用"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:213
msgid "You can reuse roles statically anywhere in the ``tasks`` section of a play using ``import_role``. The behavior is the same as using the ``roles`` keyword. For example:"
msgstr "``import_role`` を使用してプレイの ``tasks`` セクションの任意の場所に、ロールを静的に再利用できます。動作は、``roles`` キーワードの使用と同じです。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:232
msgid "You can pass other keywords, including variables and tags, when importing roles:"
msgstr "ロールをインポートする際には、変数やタグなど、他のキーワードを渡すことができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:247
msgid "When you add a tag to an ``import_role`` statement, Ansible applies the tag to `all` tasks within the role. See :ref:`tag_inheritance` for details."
msgstr "タグを ``import_role`` 文に追加すると、Ansible はタグをロール内の `all` タスクに適用します。詳細は、「:ref:`tag_inheritance`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:252
msgid "Role argument validation"
msgstr "ロール引数を検証する"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:254
msgid "Beginning with version 2.11, you may choose to enable role argument validation based on an argument specification. This specification is defined in the ``meta/argument_specs.yml`` file (or with the ``.yaml`` file extension). When this argument specification is defined, a new task is inserted at the beginning of role execution that will validate the parameters supplied for the role against the specification. If the parameters fail validation, the role will fail execution."
msgstr "バージョン 2.11 以降では、引数の仕様に基づいてロールの引数検証を有効にすることができます。この仕様は、``meta/argument_specs.yml`` ファイル (または ``.yaml`` ファイル拡張子) で定義されます。この引数仕様が定義されると、ロール実行の最初に新しいタスクが挿入され、仕様に対して、ロールに指定したパラメーターを検証します。パラメーターの検証に失敗した場合は、ロールの実行が失敗します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:262
msgid "Ansible also supports role specifications defined in the role ``meta/main.yml`` file, as well. However, any role that defines the specs within this file will not work on versions below 2.11. For this reason, we recommend using the ``meta/argument_specs.yml`` file to maintain backward compatibility."
msgstr "Ansible は、ロールの ``meta/main.yml`` ファイルで定義されるロールの仕様もサポートしますが、このファイル内の仕様を定義するロールは 2.11 未満のバージョンでは動作しません。そのため、``meta/argument_specs.yml`` ファイルを使用して後方互換性を維持することが推奨されます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:268
msgid "When role argument validation is used on a role that has defined :ref:`dependencies <role_dependencies>`, then validation on those dependencies will run before the dependent role, even if argument validation fails for the dependent role."
msgstr ":ref:`dependencies <role_dependencies>` を定義しているロールにロールの引数検証が使用されている場合は、依存するロールの引数検証が失敗しても、それらの依存関係の検証は依存するロールの前に実行します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:273
msgid "Specification format"
msgstr "仕様の形式"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:275
msgid "The role argument specification must be defined in a top-level ``argument_specs`` block within the role ``meta/argument_specs.yml`` file. All fields are lower-case."
msgstr "ロール引数の指定は、ロール ``meta/argument_specs.yml`` ファイルの上位の ``argument_specs`` ブロックで定義する必要があります。すべてのフィールドは小文字になります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "entry-point-name"
msgstr "entry-point-name"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:280
msgid "The name of the role entry point."
msgstr "ロールエントリーポイントの名前。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:281
msgid "This should be ``main`` in the case of an unspecified entry point."
msgstr "これは、エントリーポイントが未指定の場合は ``main`` である必要があります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:282
msgid "This will be the base name of the tasks file to execute, with no ``.yml`` or ``.yaml`` file extension."
msgstr "これは、ファイル拡張子 ``.yml`` または ``.yaml`` のない、実行するタスクファイルのベース名です。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "short_description"
msgstr "short_description"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:286
msgid "A short, one-line description of the entry point."
msgstr "エントリーポイントの 1 行の短い説明。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:287
msgid "The ``short_description`` is displayed by ``ansible-doc -t role -l``."
msgstr "``short_description`` は、``ansible-doc -t role -l`` に表示されます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "description"
msgstr "description"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:291
msgid "A longer description that may contain multiple lines."
msgstr "複数の行が含まれる可能性のある長い説明。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "author"
msgstr "author"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:295
msgid "Name of the entry point authors."
msgstr "エントリーポイント作成者の名前。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:296
msgid "Use a multi-line list if there is more than one author."
msgstr "作成者が複数になる場合は、複数行のリストを使用します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "options"
msgstr "options"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:300
msgid "Options are often called \"parameters\" or \"arguments\". This section defines those options."
msgstr "オプションは、しばしば「パラメーター」や「引数」と呼ばれます。このセクションでは、それらのオプションを定義します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:301
msgid "For each role option (argument), you may include:"
msgstr "各ロールオプション (引数) に以下を含めることができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "option-name"
msgstr "option-name"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:305
msgid "The name of the option/argument."
msgstr "オプション/引数の名前。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:309
msgid "Detailed explanation of what this option does. It should be written in full sentences."
msgstr "このオプションの機能の詳細な説明。これは、完全な文章で記述する必要があります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "type"
msgstr "type"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:313
msgid "The data type of the option. See :ref:`Argument spec <argument_spec>` for allowed values for ``type``. Default is ``str``."
msgstr "オプションのデータタイプ。``type`` に設定可能な値については、:ref:`引数の仕様 <argument_spec>` を参照してください。デフォルトは ``str`` です。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:314
msgid "If an option is of type ``list``, ``elements`` should be specified."
msgstr "オプションが ``list`` タイプの場合は、``elements`` を指定する必要があります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "required"
msgstr "必須"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:318
msgid "Only needed if ``true``."
msgstr "``true`` の場合にのみ必要です。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:319
msgid "If missing, the option is not required."
msgstr "見つからない場合、そのオプションは必要ありません。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "default"
msgstr "default"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:323
msgid "If ``required`` is false/missing, ``default`` may be specified (assumed 'null' if missing)."
msgstr "``required`` が false もしくは指定されていない場合は、``default`` を指定できます (見つからない場合は「null」と見なされます)。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:324
msgid "Ensure that the default value in the docs matches the default value in the code. The actual default for the role variable will always come from ``defaults/main.yml``."
msgstr "ドキュメントのデフォルト値が、コードのデフォルト値と一致していることを確認します。ロール変数の実際のデフォルトは常に ``defaults/main.yml`` から取得されます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:326
msgid "The default field must not be listed as part of the description, unless it requires additional information or conditions."
msgstr "追加の情報や条件が必要な場合を除き、デフォルトのフィールドは、説明の一部として記載しないでください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:327
msgid "If the option is a boolean value, you can use any of the boolean values recognized by Ansible: (such as true/false or yes/no).  Choose the one that reads better in the context of the option."
msgstr "オプションがブール値の場合は、Ansible が認識する任意のブール値 (true/false、yes/no など) を使用できます。オプションのコンテキストで読み取りが適切であればこれを選択します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "choices"
msgstr "choices"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:332
msgid "List of option values."
msgstr "オプション値のリスト。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:333
msgid "Should be absent if empty."
msgstr "空欄の場合は指定なしになります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst
msgid "elements"
msgstr "elements"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:337
msgid "Specifies the data type for list elements when type is ``list``."
msgstr "タイプが ``list`` の場合に、リスト要素のデータ型を指定します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:341
msgid "If this option takes a dict or list of dicts, you can define the structure here."
msgstr "このオプションがディクショナリーまたはディクショナリーのリストを取る場合は、ここで構造を定義できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:344
msgid "Sample specification"
msgstr "サンプル仕様"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:379
msgid "Running a role multiple times in one play"
msgstr "1 つのプレイでロールを複数回実行する"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:381
msgid "Ansible only executes each role once in a play, even if you define it multiple times, unless the parameters defined on the role are different for each definition. For example, Ansible only runs the role ``foo`` once in a play like this:"
msgstr "Ansible は、ロールに定義されているパラメーターが定義ごとに異なる場合を除き、各ロールを複数回定義してもプレイでは 1 回しか実行しません。たとえば、Ansible は次のようなプレイで ``foo`` というロールを 1 回だけ実行します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:392
msgid "You have two options to force Ansible to run a role more than once."
msgstr "Ansible が複数のロールを強制的に実行するオプションは 2 つあります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:395
msgid "Passing different parameters"
msgstr "異なるパラメーターを渡す"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:397
msgid "If you pass different parameters in each role definition, Ansible runs the role more than once. Providing different variable values is not the same as passing different role parameters. You must use the ``roles`` keyword for this behavior, since ``import_role`` and ``include_role`` do not accept role parameters."
msgstr "各ロール定義で異なるパラメーターを渡すと、Ansible はそのロールを複数回実行します。異なる変数値を提供することは、異なるロールパラメーターを渡すこととは異なります。``import_role`` および ``include_role`` はロールパラメーターを受け入れないため、この動作には ``roles`` キーワードを使用する必要があります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:399
msgid "This play runs the ``foo`` role twice:"
msgstr "このプレイでは、``foo`` ロールが 2 回実行されます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:409
msgid "This syntax also runs the ``foo`` role twice;"
msgstr "この構文は、``foo`` ロールを 2 回実行します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:421
msgid "In these examples, Ansible runs ``foo`` twice because each role definition has different parameters."
msgstr "これらの例では、各ロール定義のパラメーターが異なるため、Ansible は ``foo`` を 2 回実行します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:424
msgid "Using ``allow_duplicates: true``"
msgstr "``allow_duplicates: true`` の使用"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:426
msgid "Add ``allow_duplicates: true`` to the ``meta/main.yml`` file for the role:"
msgstr "ロールの ``meta/main.yml`` ファイルに ``allow_duplicates: true`` を追加します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:441
msgid "In this example, Ansible runs ``foo`` twice because we have explicitly enabled it to do so."
msgstr "この例では、Ansible が ``foo`` を2回実行していますが、これは明示的に実行できるようにしたためです。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:446
msgid "Using role dependencies"
msgstr "ロール依存関係の使用"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:448
msgid "Role dependencies let you automatically pull in other roles when using a role."
msgstr "ロールの依存関係により、ロールを使用する際に他のロールを自動的にプルできます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:450
msgid "Role dependencies are prerequisites, not true dependencies. The roles do not have a parent/child relationship. Ansible loads all listed roles, runs the roles listed under ``dependencies`` first, then runs the role that lists them. The play object is the parent of all roles, including roles called by a ``dependencies`` list."
msgstr "ロールの依存関係は前提条件であり、真の依存関係ではありません。また、ロールは親子関係を持ちません。Ansible はリストアップされたすべてのロールを読み込み、``dependencies`` にリストアップされたロールを最初に実行し、次にそれらをリストアップしたロールを実行します。play オブジェクトは、``dependencies`` のリストで呼び出されるロールを含め、すべてのロールの親です。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:452
msgid "Role dependencies are stored in the ``meta/main.yml`` file within the role directory. This file should contain a list of roles and parameters to insert before the specified role. For example:"
msgstr "ロールの依存関係は、ロールディレクトリー内の ``meta/main.yml`` ファイルに保存されます。このファイルには、指定されたロールの前に挿入するロールとパラメーターの一覧を含める必要があります。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:470
msgid "Ansible always executes roles listed in ``dependencies`` before the role that lists them. Ansible executes this pattern recursively when you use the ``roles`` keyword. For example, if you list role ``foo`` under ``roles:``, role ``foo`` lists role ``bar`` under ``dependencies`` in its meta/main.yml file, and role ``bar`` lists role ``baz`` under ``dependencies`` in its meta/main.yml, Ansible executes ``baz``, then ``bar``, then ``foo``."
msgstr "Ansible は、``dependencies`` に記載されているロールを、それを記載しているロールの前に常に実行します。``roles`` キーワードを使用すると、Ansible はこのパターンを再帰的に実行します。たとえば、ロール ``foo`` を ``roles:`` の下にリストし、ロール ``foo`` が meta/main.yml ファイルの ``dependencies`` の下にロール ``bar`` をリストし、ロール ``bar`` が meta/main.yml の ``dependencies`` の下にロール ``baz`` をリストしている場合、Ansibleは ``baz``、``bar``、``foo`` の順に実行します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:473
msgid "Running role dependencies multiple times in one play"
msgstr "1 つのプレイでロールの依存関係を複数回実行する"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:475
msgid "Ansible treats duplicate role dependencies like duplicate roles listed under ``roles:``: Ansible only executes role dependencies once, even if defined multiple times, unless the parameters, tags, or when clause defined on the role are different for each definition. If two roles in a play both list a third role as a dependency, Ansible only runs that role dependency once, unless you pass different parameters, tags, when clause, or use ``allow_duplicates: true`` in the role you want to run multiple times. See :ref:`Galaxy role dependencies <galaxy_dependencies>` for more details."
msgstr "Ansible は、``roles:`` に記載されている重複したロールのように、重複したロールの依存関係を扱います。Ansible は、ロールに定義されたパラメーター、タグ、または when 句が定義ごとに異なる場合を除き、複数回定義されていてもロールの依存関係を 1 回のみ実行します。プレイ内の 2 つのロールが両方とも依存関係として 3 番目のロールをリストしている場合、Ansible は、複数回実行するロールで異なるパラメーター、タグ、when 句を渡すか、``allow_duplicates: true`` を使用しない限り、そのロールの依存関係を 1 回のみ実行します。詳細は、「:ref:`Galaxy role dependencies <galaxy_dependencies>`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:479
msgid "Role deduplication does not consult the invocation signature of parent roles. Additionally, when using ``vars:`` instead of role params, there is a side effect of changing variable scoping. Using ``vars:`` results in those variables being scoped at the play level. In the below example, using ``vars:`` would cause ``n`` to be defined as ``4`` through the entire play, including roles called before it."
msgstr "ロールの重複排除は、親ロールの呼び出し署名を参照しません。さらに、ロールパラメーターの代わりに ``vars:`` を使用する場合は、変数のスコープを変更するという副作用があります。``vars:`` を使用すると、それらの変数がプレイレベルで対象となります。以下の例では、``vars:`` を使用すると、それ以前に呼び出されたロールを含め、プレー全体を通して ``n`` が ``4`` として定義されることになります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:481
msgid "In addition to the above, users should be aware that role de-duplication occurs before variable evaluation. This means that :term:`Lazy Evaluation` may make seemingly different role invocations equivalently the same, preventing the role from running more than once."
msgstr "上記に加えて、ユーザーは変数評価の前にロールの重複排除が行われることに注意する必要があります。つまり、:term:`Lazy Evaluation` は、一見異なるロールの呼び出しを等価にして、ロールが複数回実行されるのを防ぐことができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:484
msgid "For example, a role named ``car`` depends on a role named ``wheel`` as follows:"
msgstr "たとえば、``car`` という名前のロールは、以下のように ``wheel`` という名前のロールに依存します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:499
msgid "And the ``wheel`` role depends on two roles: ``tire`` and ``brake``. The ``meta/main.yml`` for wheel would then contain the following:"
msgstr "そして、``wheel`` のロールは、``tire`` と ``brake`` の 2 つのロールに依存します。このため、wheel 用の ``meta/main.yml`` は以下のようになります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:508
msgid "And the ``meta/main.yml`` for ``tire`` and ``brake`` would contain the following:"
msgstr "そして、「``tire``」および「``brake``」の「``meta/main.yml``」には、次のような内容が含まれています。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:515
msgid "The resulting order of execution would be as follows:"
msgstr "その結果作成される実行順序は以下のようになります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:528
msgid "To use ``allow_duplicates: true`` with role dependencies, you must specify it for the role listed under ``dependencies``, not for the role that lists it. In the example above, ``allow_duplicates: true`` appears in the ``meta/main.yml`` of the ``tire`` and ``brake`` roles. The ``wheel`` role does not require ``allow_duplicates: true``, because each instance defined by ``car`` uses different parameter values."
msgstr "``allow_duplicates: true`` をロール依存で使用するには、それをリストしているロールではなく、``dependencies`` の下にリストされているロールに対して指定する必要があります。上記の例では、``allow_duplicates: true`` は、``tire`` ロールおよび ``brake`` ロールの ``meta/main.yml`` に表示されます。``wheel`` ロールは、``car`` で定義された各インスタンスが異なるパラメーター値を使用するため、``allow_duplicates: true`` を必要としません。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:531
msgid "See :ref:`playbooks_variables` for details on how Ansible chooses among variable values defined in different places (variable inheritance and scope). Also deduplication happens ONLY at the play level, so multiple plays in the same playbook may rerun the roles."
msgstr "Ansible が、さまざまな場所（変数継承および範囲）で定義される変数の値から選択する方法は、「:ref:`playbooks_variables`」を参照してください。また、重複排除はプレイレベルでのみ行われるため、同じ Playbook の複数のプレイがロールを再実行する可能性があります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:537
msgid "Embedding modules and plugins in roles"
msgstr "ロールでのモジュールおよびプラグインの埋め込み"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:539
msgid "If you write a custom module (see :ref:`developing_modules`) or a plugin (see :ref:`developing_plugins`), you might wish to distribute it as part of a role. For example, if you write a module that helps configure your company's internal software, and you want other people in your organization to use this module, but you do not want to tell everyone how to configure their Ansible library path, you can include the module in your internal_config role."
msgstr "カスタムモジュール (「:ref:`developing_modules`」を参照) やプラグイン (「:ref:`developing_plugins`」を参照) を作成した場合は、ロールの一部として配布したい場合があります。たとえば、社内のソフトウェアを設定するためのモジュールを作成し、組織内の他の人にもこのモジュールを使用してほしいにも関わらず、Ansible のライブラリーパスを設定する方法を全員に開示したくない場合は、internal_config ロールにモジュールを含めることができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:541
msgid "To add a module or a plugin to a role: Alongside the 'tasks' and 'handlers' structure of a role, add a directory named 'library' and then include the module directly inside the 'library' directory."
msgstr "モジュールやプラグインをロールに追加するには、ロールの「tasks」および「handlers」構造の横に、「library」という名前のディレクトリーを追加し、その「library」ディレクトリー内にモジュールを直接インクルードします。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:544
msgid "Assuming you had this:"
msgstr "以下があるとします。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:554
msgid "The module will be usable in the role itself, as well as any roles that are called *after* this role, as follows:"
msgstr "モジュールは、次のように、ロール自体、およびこのロールの *後に* 呼び出されるすべてのロールで使用できます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:565
msgid "If necessary, you can also embed a module in a role to modify a module in Ansible's core distribution. For example, you can use the development version of a particular module before it is released in production releases by copying the module and embedding the copy in a role. Use this approach with caution, as API signatures may change in core components, and this workaround is not guaranteed to work."
msgstr "必要に応じて、ロールにモジュールを埋め込み、Ansible のコアディストリビューションのモジュールを変更することもできます。たとえば、モジュールをコピーし、そのコピーをロールに埋め込むことで、特定のモジュールの開発バージョンを実稼働リリースの前に使用することができます。コアコンポーネントでは API シグネチャーが変更する可能性があり、この回避策は動作が保証されていないため、この方法は慎重に使用してください。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:567
msgid "The same mechanism can be used to embed and distribute plugins in a role, using the same schema. For example, for a filter plugin:"
msgstr "同じスキーマを使用して、ロールにプラグインを埋め込んだり配布したりすることもできます。たとえば、フィルタープラグインの場合は、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:577
msgid "These filters can then be used in a Jinja template in any role called after 'my_custom_filter'."
msgstr "これらのフィルターは、Jinja のテンプレートで、「my_custom_filter」の後に呼ばれる任意のロールで使用することができます。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:580
msgid "Sharing roles: Ansible Galaxy"
msgstr "ロールの共有: Ansible Galaxy"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:582
msgid "`Ansible Galaxy <https://galaxy.ansible.com>`_ is a free site for finding, downloading, rating, and reviewing all kinds of community-developed Ansible roles and can be a great way to get a jumpstart on your automation projects."
msgstr "`Ansible Galaxy <https://galaxy.ansible.com>`_ は、コミュニティーで開発されたあらゆる種類の Ansible ロールを検索、ダウンロード、評価、およびレビューする無料サイトで、ここで自動化プロジェクトをすぐに開始するための優れた方法です。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:584
msgid "The client ``ansible-galaxy`` is included in Ansible. The Galaxy client allows you to download roles from Ansible Galaxy and provides an excellent default framework for creating your own roles."
msgstr "クライアント ``ansible-galaxy`` は、Ansible に含まれています。Galaxy クライアントを使用すると、Ansible Galaxy からロールをダウンロードでき、独自のロールを作成する優れたデフォルトのフレームワークも提供します。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:586
msgid "Read the `Ansible Galaxy documentation <https://galaxy.ansible.com/docs/>`_ page for more information. A page that refers back to this one frequently is the Galaxy Roles document which explains the required metadata your role needs for use in Galaxy <https://galaxy.ansible.com/docs/contributing/creating_role.html>."
msgstr "詳細は、`Ansible Galaxy documentation <https://galaxy.ansible.com/docs/>`_ ページを参照してください。これを頻繁に参照するページは、Galaxy Role のドキュメントで、Galaxy <https://galaxy.ansible.com/docs/contributing/creating_role.html> で使用するためにロールが必要とするメタデータについて説明しています。"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:591
msgid "How to create new roles, share roles on Galaxy, role management"
msgstr "新規ロールの作成、Galaxy でのロールの共有、およびロールの管理の方法"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:599
msgid "Variables in playbooks"
msgstr "Playbook の変数"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:604
msgid ":ref:`tags`"
msgstr ":ref:`tags`"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:605
msgid "Using tags to select or skip roles/tasks in long playbooks"
msgstr "タグを使用した長い Playbook でロール/タスクの選択またはスキップ"

#: ../../rst/playbook_guide/playbooks_reuse_roles.rst:609
msgid "Extending Ansible by writing your own modules"
msgstr "独自のモジュールを作成して Ansible を拡張"

#: ../../rst/playbook_guide/playbooks_roles.rst:4
msgid "Playbook Roles and Include Statements"
msgstr "Playbook ロールおよび Include 文"

#: ../../rst/playbook_guide/playbooks_roles.rst:7
msgid "Topics"
msgstr "トピック"

#: ../../rst/playbook_guide/playbooks_roles.rst:9
msgid "The documentation regarding roles and includes for playbooks have moved. Their new location is here: :ref:`playbooks_reuse`. Please update any links you may have made directly to this page."
msgstr "Playbook のロールおよびインクルードに関するドキュメントが移動しました。新しい場所は「:ref:`playbooks_reuse`」です。このページに直接作成したリンクを更新してください。"

#: ../../rst/playbook_guide/playbooks_roles.rst:17
msgid ":ref:`playbooks_reuse`"
msgstr ":ref:`playbooks_reuse`"

#: ../../rst/playbook_guide/playbooks_roles.rst:18
msgid "Creating reusable Playbooks."
msgstr "再利用可能な Playbook の作成"

#: ../../rst/playbook_guide/playbooks_special_topics.rst:6
msgid "Advanced playbooks features"
msgstr "Playbook の高度な機能"

#: ../../rst/playbook_guide/playbooks_special_topics.rst:8
msgid "This page is obsolete. Refer to the :ref:`main User Guide index page <user_guide_index>` for links to all playbook-related topics. Please update any links you may have made directly to this page."
msgstr "このページは使用されなくなりました。Playbook に関連するすべてのトピックへのリンクは、:ref:`メインのユーザーガイドのインデックスページ <user_guide_index>` を参照してください。このページに直接リンクを張っている場合は更新してください。"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:5
msgid "Executing playbooks for troubleshooting"
msgstr "トラブルシューティングのための Playbook の実行"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:7
msgid "When you are testing new plays or debugging playbooks, you may need to run the same play multiple times. To make this more efficient, Ansible offers two alternative ways to execute a playbook: start-at-task and step mode."
msgstr "新しいプレイをテストしたり、Playbook をデバッグしたりする際に、同じプレイを複数回実行しないといけない場合があります。これを効率的に行うために、Ansible では Playbook の実行方法として、start-at-task モードと step モードの 2 種類を用意しています。"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:12
msgid "start-at-task"
msgstr "start-at-task"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:14
msgid "To start executing your playbook at a particular task (usually the task that failed on the previous run), use the ``--start-at-task`` option."
msgstr "特定のタスク (通常は直前の実行で失敗したタスク) で Playbook の実行を開始するには、``--start-at-task`` オプションを使用します。"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:20
msgid "In this example, Ansible starts executing your playbook at a task named \"install packages\". This feature does not work with tasks inside dynamically re-used roles or tasks (``include_*``), see :ref:`dynamic_vs_static`."
msgstr "この例では、Ansible は「install packages」という名前のタスクで Playbook の実行を開始します。この機能は、動的に再利用されるロールやタスク内のタスク (``include_*``) では動作しません。「:ref:`dynamic_vs_static`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:25
msgid "Step mode"
msgstr "step モード"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:27
msgid "To execute a playbook interactively, use ``--step``."
msgstr "Playbook を対話的に実行するには、``--step`` を使用します。"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:33
msgid "With this option, Ansible stops on each task, and asks if it should execute that task. For example, if you have a task called \"configure ssh\", the playbook run will stop and ask."
msgstr "このオプションを使用すると、Ansible は各タスクで停止し、そのタスクを実行すべきかどうかを尋ねます。たとえば、「configure ssh」という名前のタスクがあった場合、Playbook の実行は停止し、次のように尋ねてきます。"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:39
msgid "Answer \"y\" to execute the task, answer \"n\" to skip the task, and answer \"c\" to exit step mode, executing all remaining tasks without asking."
msgstr "「y」と答えてタスクを実行し、「n」と答えてタスクをスキップし、「c」と応えて step モードを終了し、残りのタスクをすべて実行します。"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:45
msgid ":ref:`playbook_debugger`"
msgstr ":ref:`playbook_debugger`"

#: ../../rst/playbook_guide/playbooks_startnstep.rst:46
msgid "Using the Ansible debugger"
msgstr "Ansible デバッガーの使用"

#: ../../rst/playbook_guide/playbooks_strategies.rst:4
msgid "Controlling playbook execution: strategies and more"
msgstr "Playbook の実行の制御: strategy など"

#: ../../rst/playbook_guide/playbooks_strategies.rst:6
msgid "By default, Ansible runs each task on all hosts affected by a play before starting the next task on any host, using 5 forks. If you want to change this default behavior, you can use a different strategy plugin, change the number of forks, or apply one of several keywords like ``serial``."
msgstr "デフォルトでは、Ansible はプレイの影響を受けるすべてのホストで各タスクを実行してから、任意のホストで次のタスクを開始し、5 つのフォークを使用します。このデフォルトの動作を変更する場合は、別のストラテジープラグインを使用するか、フォーク数を変更するか、``serial`` のようなキーワードのいずれかを適用することができます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:12
msgid "Selecting a strategy"
msgstr "ストラテジーの選択"

#: ../../rst/playbook_guide/playbooks_strategies.rst:13
msgid "The default behavior described above is the :ref:`linear strategy<linear_strategy>`. Ansible offers other strategies, including the :ref:`debug strategy<debug_strategy>` (see also  :ref:`playbook_debugger`) and the :ref:`free strategy<free_strategy>`, which allows each host to run until the end of the play as fast as it can:"
msgstr "上述のデフォルトの動作は :ref:`linear strategy<linear_strategy>` です。Ansible には、:ref:`debug strategy<debug_strategy>` (:ref:`playbook_debugger` も参照) や :ref:`free strategy<free_strategy>` など、他のストラテジーも用意されています。フリーストラテジーでは、各ホストがプレイが終了するまでできるだけ速く実行することができます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:22
msgid "You can select a different strategy for each play as shown above, or set your preferred strategy globally in ``ansible.cfg``, under the ``defaults`` stanza:"
msgstr "上記のように各プレイに異なるストラテジーを選択するか、``defaults`` stanza の ``ansible.cfg`` で優先されるストラテジーをグローバルに設定できます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:29
msgid "All strategies are implemented as :ref:`strategy plugins<strategy_plugins>`. Please review the documentation for each strategy plugin for details on how it works."
msgstr "すべてのストラテジーは :ref:`strategy プラグイン<strategy_plugins>` として実装されます。その仕組みの詳細は、各 strategy プラグインのドキュメントを参照してください。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:32
msgid "Setting the number of forks"
msgstr "フォークの数の設定"

#: ../../rst/playbook_guide/playbooks_strategies.rst:33
msgid "If you have the processing power available and want to use more forks, you can set the number in ``ansible.cfg``:"
msgstr "利用可能な処理能力があり、さらに多くのフォークを使用する場合は、``ansible.cfg`` で数値を設定できます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:40
msgid "or pass it on the command line: `ansible-playbook -f 30 my_playbook.yml`."
msgstr "または、コマンドラインで渡します (`ansible-playbook -f 30 my_playbook.yml`)。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:43
msgid "Using keywords to control execution"
msgstr "キーワードを使用した実行の制御"

#: ../../rst/playbook_guide/playbooks_strategies.rst:45
msgid "In addition to strategies, several :ref:`keywords<playbook_keywords>` also affect play execution. You can set a number, a percentage, or a list of numbers of hosts you want to manage at a time with ``serial``. Ansible completes the play on the specified number or percentage of hosts before starting the next batch of hosts. You can restrict the number of workers allotted to a block or task with ``throttle``. You can control how Ansible selects the next host in a group to execute against with ``order``. You can run a task on a single host with ``run_once``. These keywords are not strategies. They are directives or options applied to a play, block, or task."
msgstr "ストラテジーだけでなく、いくつかの :ref:`キーワード<playbook_keywords>` もプレイの実行に影響を与えます。``serial`` では、一度に管理したいホストの数、割合、またはリストを設定できます。Ansible は、指定した数または割合のホストでプレイを完了してから、次のホストのバッチを開始します。``throttle`` で、ブロックやタスクに割り当てられるワーカーの数を制限することができます。``order`` で、Ansible がグループ内の次のホストを選択して実行する方法を制御できます。``run_once`` を使用して、1 つのタスクを 1 つのホストで実行することができます。これらのキーワードはストラテジーではなく、プレイ、ブロック、またはタスクに適用されるディレクティブやオプションです。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:47
msgid "Other keywords that affect play execution include ``ignore_errors``, ``ignore_unreachable``, and ``any_errors_fatal``. These options are documented in :ref:`playbooks_error_handling`."
msgstr "プレイの実行に影響する他のキーワードには、``ignore_errors``、``ignore_unreachable``、および ``any_errors_fatal`` が含まれます。これらのオプションは、「:ref:`playbooks_error_handling`」に記載されています。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:52
msgid "Setting the batch size with ``serial``"
msgstr "``serial`` を使用してバッチサイズの設定"

#: ../../rst/playbook_guide/playbooks_strategies.rst:54
msgid "By default, Ansible runs in parallel against all the hosts in the :ref:`pattern <intro_patterns>` you set in the ``hosts:`` field of each play. If you want to manage only a few machines at a time, for example during a rolling update, you can define how many hosts Ansible should manage at a single time using the ``serial`` keyword:"
msgstr "デフォルトでは、Ansible は、各プレイの ``hosts:`` フィールドで設定した :ref:`pattern <intro_patterns>` のすべてのホストに対して並行して実行します。ローリングアップデート中など、一度に数台のマシンのみを管理する場合は、``serial`` キーワードを使用して、Ansible が一度に管理するホストの数を定義できます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:71
msgid "In the above example, if we had 6 hosts in the group 'webservers', Ansible would execute the play completely (both tasks) on 3 of the hosts before moving on to the next 3 hosts:"
msgstr "上の例では、「webservers」というグループに 6 台のホストがあった場合、Ansible はそのうちの 3 台のホストでプレイを完全に (両方のタスクを) 実行してから、次の 3 台のホストに移ります。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:109
msgid "Setting the batch size with ``serial`` changes the scope of the Ansible failures to the batch size, not the entire host list. You can use  :ref:`ignore_unreachable <ignore_unreachable>` or :ref:`max_fail_percentage <maximum_failure_percentage>` to modify this behavior."
msgstr "``serial`` を使用してバッチサイズを設定すると、ホストリスト全体ではなく、Ansible の失敗のスコープがバッチサイズに変更されます。この動作を変更するには、:ref:`ignore_unreachable <ignore_unreachable>` または :ref:`max_fail_percentage <maximum_failure_percentage>` を使用します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:111
msgid "You can also specify a percentage with the ``serial`` keyword. Ansible applies the percentage to the total number of hosts in a play to determine the number of hosts per pass:"
msgstr "``serial`` キーワードでパーセンテージを指定することもできます。Ansible は、プレイ内のホストの合計数にパーセンテージを適用して、パスごとのホスト数を決定します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:120
msgid "If the number of hosts does not divide equally into the number of passes, the final pass contains the remainder. In this example, if you had 20 hosts in the webservers group, the first batch would contain 6 hosts, the second batch would contain 6 hosts, the third batch would contain 6 hosts, and the last batch would contain 2 hosts."
msgstr "ホストの数がパスの数に等しく分配されない場合は、最後のパスには残りの数が含まれます。この例では、webservers グループに 20 台のホストがある場合、最初のバッチには 6 台のホストが、2 番目のバッチには 6 台のホストが、3 番目のバッチには 6 台のホストが、そして最後のバッチには 2 台のホストが含まれます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:122
msgid "You can also specify batch sizes as a list. For example:"
msgstr "また、バッチサイズをリストとして指定することもできます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:134
msgid "In the above example, the first batch would contain a single host, the next would contain 5 hosts, and (if there are any hosts left), every following batch would contain either 10 hosts or all the remaining hosts, if fewer than 10 hosts remained."
msgstr "上記の例では、最初のバッチには 1 台のホストが含まれ、次のバッチには 5 台のホストが含まれ、(ホストが残っていれば) その後のすべてのバッチには 10 台のホストが含まれるか、または 10 台未満のホストが残っていれば、残りのすべてのホストが含まれることになります。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:136
msgid "You can list multiple batch sizes as percentages:"
msgstr "複数のバッチサイズをパーセンテージとして一覧表示できます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:148
msgid "You can also mix and match the values:"
msgstr "値を混在させたり、一致させることもできます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:161
msgid "No matter how small the percentage, the number of hosts per pass will always be 1 or greater."
msgstr "パーセンテージを小さくしても、各パスのホスト数は常に 1 以上になります。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:164
msgid "Restricting execution with ``throttle``"
msgstr "``throttle`` で実行を制限"

#: ../../rst/playbook_guide/playbooks_strategies.rst:166
msgid "The ``throttle`` keyword limits the number of workers for a particular task. It can be set at the block and task level. Use ``throttle`` to restrict tasks that may be CPU-intensive or interact with a rate-limiting API:"
msgstr "``throttle`` キーワードは、特定のタスクに対するワーカーの数を制限します。これは、ブロックおよびタスクのレベルで設定できます。``throttle`` を使用して、CPU に負荷がかかる可能性のあるタスクや、レート制限 API と相互作用するタスクを制限します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:174
msgid "If you have already restricted the number of forks or the number of machines to execute against in parallel, you can reduce the number of workers with ``throttle``, but you cannot increase it. In other words, to have an effect, your ``throttle`` setting must be lower than your ``forks`` or ``serial`` setting if you are using them together."
msgstr "すでにフォークの数や並列実行するマシンの数を制限している場合は、``throttle`` でワーカーの数を減らすことはできますが、増やすことはできません。つまり、それを合わせて使用する場合に効果を得るためには、``throttle`` の設定が ``forks`` や ``serial`` の設定よりも低くなければなりません。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:177
msgid "Ordering execution based on inventory"
msgstr "インベントリーに基づく実行の順序付け"

#: ../../rst/playbook_guide/playbooks_strategies.rst:179
msgid "The ``order`` keyword controls the order in which hosts are run. Possible values for order are:"
msgstr "``order`` キーワードは、ホストが実行する順序を制御します。order に指定できる値は次のとおりです。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:181
msgid "inventory:"
msgstr "inventory:"

#: ../../rst/playbook_guide/playbooks_strategies.rst:182
msgid "(default) The order provided by the inventory for the selection requested (see note below)"
msgstr "（デフォルト）要求された選択に対してインベントリーによって提供される順序（以下の注記を参照）"

#: ../../rst/playbook_guide/playbooks_strategies.rst:183
msgid "reverse_inventory:"
msgstr "reverse_inventory:"

#: ../../rst/playbook_guide/playbooks_strategies.rst:184
msgid "The same as above, but reversing the returned list"
msgstr "上記と同じですが、返されたリストの再検証"

#: ../../rst/playbook_guide/playbooks_strategies.rst:185
msgid "sorted:"
msgstr "sorted:"

#: ../../rst/playbook_guide/playbooks_strategies.rst:186
msgid "Sorted alphabetically sorted by name"
msgstr "名前をアルファベット順で並べ替えます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:187
msgid "reverse_sorted:"
msgstr "reverse_sorted:"

#: ../../rst/playbook_guide/playbooks_strategies.rst:188
msgid "Sorted by name in reverse alphabetical order"
msgstr "アルファベットの逆順で名前がソートされます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:190
msgid "shuffle:"
msgstr "shuffle:"

#: ../../rst/playbook_guide/playbooks_strategies.rst:190
msgid "Randomly ordered on each run"
msgstr "実行ごとにランダムに順序付けられます。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:193
msgid "the 'inventory' order does not equate to the order in which hosts/groups are defined in the inventory source file, but the 'order in which a selection is returned from the compiled inventory'. This is a backwards compatible option and while reproducible it is not normally predictable. Due to the nature of inventory, host patterns, limits, inventory plugins and the ability to allow multiple sources it is almost impossible to return such an order. For simple cases this might happen to match the file definition order, but that is not guaranteed."
msgstr "'インベントリー' の順序は、インベントリーソースファイル内でホスト/グループが定義する順序と同じではありませんが、'コンパイルされたインベントリーから選択が返される順序' と同じです。これは下位互換性のあるオプションであり、再現可能ですが、通常は予測できません。インベントリーの性質、ホストパターン、制限、インベントリープラグイン、および複数のソースを許可する機能により、そのような順序を返すことはほとんど不可能です。単純なケースでは、これはファイル定義の順序と一致する可能性がありますが、それは保証されていません。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:198
msgid "Running on a single machine with ``run_once``"
msgstr "シングルマシンで、``run_once`` で動作します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:200
msgid "If you want a task to run only on the first host in your batch of hosts, set ``run_once`` to true on that task:"
msgstr "ホストのバッチの最初のホストでタスクを実行する場合は、そのタスクで ``run_once`` を true に設定します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:216
msgid "Ansible executes this task on the first host in the current batch and applies all results and facts to all the hosts in the same batch. This approach is similar to applying a conditional to a task such as:"
msgstr "Ansible は、現在のバッチの最初のホストでこのタスクを実行し、すべての結果とファクトを同じバッチのすべてのホストに適用します。この方法は、次のような条件をタスクに適用することに似ています。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:223
msgid "However, with ``run_once``, the results are applied to all the hosts. To run the task on a specific host, instead of the first host in the batch, delegate the task:"
msgstr "ただし、``run_once`` では、結果はすべてのホストに適用されます。バッチの最初のホストではなく、特定のホストでタスクを実行するには、タスクを次のように委譲します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:231
msgid "As always with :ref:`delegation <playbooks_delegation>`, the action will be executed on the delegated host, but the information is still that of the original host in the task."
msgstr ":ref:`委譲 <playbooks_delegation>` の場合と同様、アクションは委譲されたホストで実行されますが、情報はタスクの元のホストの情報になります。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:234
msgid "When used together with ``serial``, tasks marked as ``run_once`` will be run on one host in *each* serial batch. If the task must run only once regardless of ``serial`` mode, use :code:`when: inventory_hostname == ansible_play_hosts_all[0]` construct."
msgstr "``serial`` と併用すると、``run_once`` とマークされたタスクは、*各* シリアルバッチの中の 1 台のホストで実行します。タスクが ``serial`` モードに関係なく 1 回だけ実行する必要がある場合は、:code:`when: inventory_hostname == ansible_play_hosts_all[0]` コンストラクトを使用します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:238
msgid "Any conditional (in other words, `when:`) will use the variables of the 'first host' to decide if the task runs or not, no other hosts will be tested."
msgstr "条件 (つまり `when:`) は、「first host」の変数を使用して、タスクが実行されるかどうかを判断し、他のホストはテストされません。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:241
msgid "If you want to avoid the default behavior of setting the fact for all hosts, set ``delegate_facts: True`` for the specific task or block."
msgstr "すべてのホストにファクトを設定するデフォルトの動作を回避する場合は、特定のタスクまたはブロックに ``delegate_facts: True`` を設定します。"

#: ../../rst/playbook_guide/playbooks_strategies.rst:247
msgid ":ref:`playbooks_delegation`"
msgstr ":ref:`playbooks_delegation`"

#: ../../rst/playbook_guide/playbooks_strategies.rst:248
msgid "Running tasks on or assigning facts to specific machines"
msgstr "特定マシンでのタスクの実行、または特定マシンへのファクトの割り当て"

#: ../../rst/playbook_guide/playbooks_tags.rst:5
msgid "Tags"
msgstr "タグ"

#: ../../rst/playbook_guide/playbooks_tags.rst:7
msgid "If you have a large playbook, it may be useful to run only specific parts of it instead of running the entire playbook. You can do this with Ansible tags. Using tags to execute or skip selected tasks is a two-step process:"
msgstr "大規模な Playbook を使用する場合は、Playbook 全体を実行するのではなく、特定の部分だけを実行すると便利な場合があります。これを実現するには、Ansible のタグを使用します。タグを使用して選択したタスクを実行またはスキップするには、2 つのステップがあります。"

#: ../../rst/playbook_guide/playbooks_tags.rst:9
msgid "Add tags to your tasks, either individually or with tag inheritance from a block, play, role, or import."
msgstr "タスクにタグを追加するには、個別にタグを追加するか、ブロック、プレイ、ロール、またはインポートからタグを継承する必要があります。"

#: ../../rst/playbook_guide/playbooks_tags.rst:10
msgid "Select or skip tags when you run your playbook."
msgstr "Playbook の実行時にタグを選択またはスキップします。"

#: ../../rst/playbook_guide/playbooks_tags.rst:16
msgid "Adding tags with the tags keyword"
msgstr "tags キーワードを使用したタグの追加"

#: ../../rst/playbook_guide/playbooks_tags.rst:18
msgid "You can add tags to a single task or include. You can also add tags to multiple tasks by defining them at the level of a block, play, role, or import. The keyword ``tags`` addresses all these use cases. The ``tags`` keyword always defines tags and adds them to tasks; it does not select or skip tasks for execution. You can only select or skip tasks based on tags at the command line when you run a playbook. See :ref:`using_tags` for more details."
msgstr "タグは、単一のタスクまたはインクルードに追加できます。また、ブロック、プレイ、ロール、またはインポートのレベルでタグを定義することで、複数のタスクにタグを追加することもできます。``tags`` キーワードは、これらすべてのユースケースに対応しています。``tags`` キーワードは、常にタグを定義してタスクに追加しますが、実行するタスクの選択やスキップは行いません。タグに基づいてタスクを選択またはスキップできるのは、Playbook の実行時にコマンドラインで行う場合のみです。詳細は、「:ref:`using_tags`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:21
msgid "Adding tags to individual tasks"
msgstr "個別タスクへのタグの追加"

#: ../../rst/playbook_guide/playbooks_tags.rst:23
msgid "At the simplest level, you can apply one or more tags to an individual task. You can add tags to tasks in playbooks, in task files, or within a role. Here is an example that tags two tasks with different tags:"
msgstr "最も簡単なレベルでは、個々のタスクに 1 つまたは複数のタグを適用できます。タグは、Playbook 内、タスクファイル内、またはロール内のタスクに追加できます。以下は、2 つのタスクに異なるタグを付ける例です。"

#: ../../rst/playbook_guide/playbooks_tags.rst:45
msgid "You can apply the same tag to more than one individual task. This example tags several tasks with the same tag, \"ntp\":"
msgstr "同じタグを複数の個別タスクに適用できます。この例では、同じタグ「ntp」を使用して、複数のタスクにタグを付けることができます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:81
msgid "If you ran these four tasks in a playbook with ``--tags ntp``, Ansible would run the three tasks tagged ``ntp`` and skip the one task that does not have that tag."
msgstr "``--tags ntp`` を使用して、この 4 つのタスクを Playbook で実行した場合、Ansible は ``ntp`` のタグが付いた 3 つのタスクを実行し、タグが付いていない 1 つのタスクをスキップします。"

#: ../../rst/playbook_guide/playbooks_tags.rst:86
msgid "Adding tags to includes"
msgstr "インクルードするタグの追加"

#: ../../rst/playbook_guide/playbooks_tags.rst:88
msgid "You can apply tags to dynamic includes in a playbook. As with tags on an individual task, tags on an ``include_*`` task apply only to the include itself, not to any tasks within the included file or role. If you add ``mytag`` to a dynamic include, then run that playbook with ``--tags mytag``, Ansible runs the include itself, runs any tasks within the included file or role tagged with ``mytag``, and skips any tasks within the included file or role without that tag. See :ref:`selective_reuse` for more details."
msgstr "タグは、Playbook 内の動的インクルードにタグを適用できます。個々のタスクのタグと同様に、``include_*`` タスクのタグは、インクルード自体にのみ適用され、インクルードされたファイルやロール内のタスクには適用されません。動的インクルードに ``mytag`` を追加し、その Playbook を ``--tags mytag`` で実行すると、Ansible はインクルード自体を実行し、``mytag`` でタグ付けされたインクルードファイルまたはロール内のタスクを実行し、そのタグのないインクルードファイルまたはロール内のタスクをスキップします。詳細は「:ref:`selective_reuse`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:90
msgid "You add tags to includes the same way you add tags to any other task:"
msgstr "タグを追加して、他のタスクにタグを追加する方法と同じ方法でインクルードします。"

#: ../../rst/playbook_guide/playbooks_tags.rst:101
msgid "You can add a tag only to the dynamic include of a role. In this example, the ``foo`` tag will `not` apply to tasks inside the ``bar`` role:"
msgstr "タグは、ロールの動的インクルードにのみ追加できます。この例では、``foo`` タグは ``bar`` ロール内のタスクに適用 `されません`。"

#: ../../rst/playbook_guide/playbooks_tags.rst:114
msgid "With plays, blocks, the ``role`` keyword, and static imports, Ansible applies tag inheritance, adding the tags you define to every task inside the play, block, role, or imported file. However, tag inheritance does *not* apply to dynamic re-use with ``include_role`` and ``include_tasks``. With dynamic re-use (includes), the tags you define apply only to the include itself. If you need tag inheritance, use a static import. If you cannot use an import because the rest of your playbook uses includes, see :ref:`apply_keyword` for ways to work around this behavior."
msgstr "プレイ、ブロック、``role`` キーワード、および静的なインポートでは、Ansible はタグ継承を適用し、定義したタグをプレイ、ブロック、ロール、またはインポートしたファイル内のすべてのタスクに追加します。しかし、``include_role`` や ``include_tasks`` のような動的再利用では、タグの継承は *適用されません*。動的再利用 (インクルード) では、定義したタグはインクルード自体にのみ適用されます。タグの継承が必要な場合は、静的インポートを使用してください。Playbook の他の部分がインクルードを使用しているためにインポートを使用できない場合は、この動作を回避する方法について「:ref:`apply_keyword`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:119
msgid "Tag inheritance: adding tags to multiple tasks"
msgstr "タグの継承: 複数のタスクへのタグの追加"

#: ../../rst/playbook_guide/playbooks_tags.rst:121
msgid "If you want to apply the same tag or tags to multiple tasks without adding a ``tags`` line to every task, you can define the tags at the level of your play or block, or when you add a role or import a file. Ansible applies the tags down the dependency chain to all child tasks. With roles and imports, Ansible appends the tags set by the ``roles`` section or import to any tags set on individual tasks or blocks within the role or imported file. This is called tag inheritance. Tag inheritance is convenient, because you do not have to tag every task. However, the tags still apply to the tasks individually."
msgstr "すべてのタスクに ``tags`` 行を追加することなく、複数のタスクに同じタグを適用したい場合は、プレイやブロックのレベル、またはロールの追加やファイルのインポートの際にタグを定義することができます。Ansible は、依存関係の連鎖の下にあるタグをすべての子タスクに適用します。ロールやインポートの場合、Ansible は ``roles`` セクションやインポートで設定されたタグを、ロールやインポートしたファイル内の個々のタスクやブロックに設定されたタグに追加します。これを「タグの継承」と呼びます。タグの継承は、すべてのタスクにタグを付ける必要がないため便利です。ただし、タグはタスクに個別に適用されます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:124
msgid "Adding tags to blocks"
msgstr "ブロックへのタグの追加"

#: ../../rst/playbook_guide/playbooks_tags.rst:126
msgid "If you want to apply a tag to many, but not all, of the tasks in your play, use a :ref:`block <playbooks_blocks>` and define the tags at that level. For example, we could edit the NTP example shown above to use a block:"
msgstr "プレイ中のタスクのすべてではなく、多くのタスクにタグを適用したい場合は、:ref:`ブロック <playbooks_blocks>` を使用し、そのレベルでタグを定義します。たとえば、上で紹介した NTP の例を編集して、ブロックを使用することができます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:161
msgid "Adding tags to plays"
msgstr "プレイへのタグの追加"

#: ../../rst/playbook_guide/playbooks_tags.rst:163
msgid "If all the tasks in a play should get the same tag, you can add the tag at the level of the play. For example, if you had a play with only the NTP tasks, you could tag the entire play:"
msgstr "プレイの中のすべてのタスクに同じタグを付ける必要がある場合は、プレイのレベルでタグを追加することができます。たとえば、NTP タスクだけのプレイがあった場合は、プレイ全体にタグを付けることができます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:194
msgid "Adding tags to roles"
msgstr "ロールへのタグの追加"

#: ../../rst/playbook_guide/playbooks_tags.rst:196
msgid "There are three ways to add tags to roles:"
msgstr "ロールにタグを追加するには、3 つの方法があります。"

#: ../../rst/playbook_guide/playbooks_tags.rst:198
msgid "Add the same tag or tags to all tasks in the role by setting tags under ``roles``. See examples in this section."
msgstr "``roles`` セクションにタグを設定して、ロールのすべてのタスクに同じタグを追加します。本セクションの例を参照してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:199
msgid "Add the same tag or tags to all tasks in the role by setting tags on a static ``import_role`` in your playbook. See examples in :ref:`tags_on_imports`."
msgstr "Playbook の静的 ``import_role`` にタグを設定して、ロール内のすべてのタスクに同じタグを追加します。「:ref:`tags_on_imports`」の例を参照してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:200
msgid "Add a tag or tags to individual tasks or blocks within the role itself. This is the only approach that allows you to select or skip some tasks within the role. To select or skip tasks within the role, you must have tags set on individual tasks or blocks, use the dynamic ``include_role`` in your playbook, and add the same tag or tags to the include. When you use this approach, and then run your playbook with ``--tags foo``, Ansible runs the include itself plus any tasks in the role that also have the tag ``foo``. See :ref:`tags_on_includes` for details."
msgstr "ロール自体の中の個々のタスクやブロックにタグを追加します。これは、ロール内の一部のタスクを選択またはスキップすることができる唯一の方法です。ロール内のタスクを選択またはスキップするには、個々のタスクまたはブロックにタグを設定し、Playbook で動的な ``include_role`` を使用して、同じタグをインクルードに追加する必要があります。この方法で ``--tags foo`` を付けて Playbook を実行すると、Ansible はインクルード自体に加えて、タグ ``foo`` を持つロール内のタスクを実行します。詳細は、「:ref:`tags_on_includes`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:202
msgid "When you incorporate a role in your playbook statically with the ``roles`` keyword, Ansible adds any tags you define to all the tasks in the role. For example:"
msgstr "``roles`` キーワードを使用して Playbook にロールを静的に組み込むと、Ansible は定義したタグをロール内のすべてのタスクに追加します。たとえば、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_tags.rst:212
msgid "or:"
msgstr "または"

#: ../../rst/playbook_guide/playbooks_tags.rst:229
msgid "Adding tags to imports"
msgstr "インポートへのタグの追加"

#: ../../rst/playbook_guide/playbooks_tags.rst:231
msgid "You can also apply a tag or tags to all the tasks imported by the static ``import_role`` and ``import_tasks`` statements:"
msgstr "また、静的な ``import_role`` 文や ``import_tasks`` 文によりインポートされたすべてのタスクに、タグを適用することもできます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:252
msgid "Tag inheritance for includes: blocks and the ``apply`` keyword"
msgstr "インクルードのタグ継承: ブロックおよび ``apply`` キーワード"

#: ../../rst/playbook_guide/playbooks_tags.rst:254
msgid "By default, Ansible does not apply :ref:`tag inheritance <tag_inheritance>` to dynamic re-use with ``include_role`` and ``include_tasks``. If you add tags to an include, they apply only to the include itself, not to any tasks in the included file or role. This allows you to execute selected tasks within a role or task file - see :ref:`selective_reuse` when you run your playbook."
msgstr "デフォルトでは、Ansible は :ref:`タグ継承 <tag_inheritance>` を適用せず、``include_role`` および ``include_tasks`` を使用した動的再利用を行います。タグをインクルードに追加すると、タグはインクルード自体にのみ適用され、インクルードしたファイルやロール内のタスクには適用されません。これにより、ロールやタスクファイル内の選択したタスクを実行することができます。Playbook を実行する際には、「:ref:`selective_reuse`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:256
msgid "If you want tag inheritance, you probably want to use imports. However, using both includes and imports in a single playbook can lead to difficult-to-diagnose bugs. For this reason, if your playbook uses ``include_*`` to re-use roles or tasks, and you need tag inheritance on one include, Ansible offers two workarounds. You can use the ``apply`` keyword:"
msgstr "タグの継承が必要な場合は、おそらくインポートを使用したいと思うでしょう。ただし、1 つの Playbook でインクルードとインポートの両方を使用すると、診断が困難なバグが発生する可能性があります。このような理由から、Playbook で ``include_*`` を使用してロールやタスクを再利用している場合に、1 つのインクルードでタグの継承が必要な場合、Ansible には 2 つの回避策があります。``apply`` キーワードを使用することができます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:269
msgid "Or you can use a block:"
msgstr "または、以下のブロックを使用できます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:281
msgid "Special tags: always and never"
msgstr "特別なタグ: always および never"

#: ../../rst/playbook_guide/playbooks_tags.rst:283
msgid "Ansible reserves two tag names for special behavior: always and never. If you assign the ``always`` tag to a task or play, Ansible will always run that task or play, unless you specifically skip it (``--skip-tags always``)."
msgstr "Ansible は、特別な動作のために、always と never という 2 つのタグ名を予約しています。``always`` タグをタスクやプレイに割り当てると、Ansible は特にスキップしない限り、常にそのタスクやプレイを実行します (``--skip-tags always``)。"

#: ../../rst/playbook_guide/playbooks_tags.rst:303
msgid "Fact gathering is tagged with 'always' by default. It is only skipped if you apply a tag and then use a different tag in ``--tags`` or the same tag in ``--skip-tags``."
msgstr "ファクト収集には、デフォルトで「always」というタグが付けられています。タグを適用した後、``--tags`` で別のタグを使用したり、``--skip-tags`` で同じタグを使用した場合に限りスキップされます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:308
msgid "The role argument specification validation task is tagged with 'always' by default. This validation will be skipped if you use ``--skip-tags always``."
msgstr "ロールの引数の仕様検証タスクは、デフォルトで「always」でタグ付けされます。この検証は、``--skip-tags always`` を使用する場合に省略されます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:313
msgid "If you assign the ``never`` tag to a task or play, Ansible will skip that task or play unless you specifically request it (``--tags never``)."
msgstr "``never`` タグをタスクまたはプレイに割り当てると、特に要求しない限り (``--tags never``)、Ansible はそのタスクまたはプレイをスキップします。"

#: ../../rst/playbook_guide/playbooks_tags.rst:325
msgid "The rarely-used debug task in the example above only runs when you specifically request the ``debug`` or ``never`` tags."
msgstr "上記の例では、ほとんど使用されないデバッグタスクは、``debug`` タグまたは ``never`` タグを特別に要求した場合にのみ実行します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:330
msgid "Selecting or skipping tags when you run a playbook"
msgstr "Playbook の実行時にタグの選択または省略"

#: ../../rst/playbook_guide/playbooks_tags.rst:332
msgid "Once you have added tags to your tasks, includes, blocks, plays, roles, and imports, you can selectively execute or skip tasks based on their tags when you run :ref:`ansible-playbook`. Ansible runs or skips all tasks with tags that match the tags you pass at the command line. If you have added a tag at the block or play level, with ``roles``, or with an import, that tag applies to every task within the block, play, role, or imported role or file. If you have a role with lots of tags and you want to call subsets of the role at different times, either :ref:`use it with dynamic includes <selective_reuse>`, or split the role into multiple roles."
msgstr "タスク、インクルード、ブロック、プレイ、ロール、およびインポートにタグを追加したら、:ref:`ansible-playbook` を実行する際に、タグに基づいてタスクを選択的に実行またはスキップすることができます。Ansible は、コマンドラインで指定したタグと一致するタグを持つすべてのタスクを実行またはスキップします。ブロックやプレイのレベルで、``roles`` またはインポートを使用してタグを追加した場合、そのタグはブロック、プレイ、ロール、もしくはインポートされたロールまたはファイル内のすべてのタスクに適用されます。多くのタグを持つロールがあり、ロールのサブセットを異なるタイミングで呼び出したい場合は、:ref:`動的インクルードで使用する <selective_reuse>` か、ロールを複数のロールに分割してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:334
msgid ":ref:`ansible-playbook` offers five tag-related command-line options:"
msgstr ":ref:`ansible-playbook` は、タグ関連のコマンドラインオプションを 5 つ提供します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:336
msgid "``--tags all`` - run all tasks, ignore tags (default behavior)"
msgstr "``--tags all`` - すべてのタスクを実行し、タグを無視します (デフォルトの動作)。"

#: ../../rst/playbook_guide/playbooks_tags.rst:337
msgid "``--tags [tag1, tag2]`` - run only tasks with either the tag ``tag1`` or the tag ``tag2``"
msgstr "``--tags [tag1, tag2]`` - ``tag1`` タグまたは ``tag2`` タグのいずれかでのみタスクを実行します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:338
msgid "``--skip-tags [tag3, tag4]`` - run all tasks except those with either the tag ``tag3`` or the tag ``tag4``"
msgstr "``--skip-tags [tag3, tag4]`` - ``tag3`` タグまたは ``tag4`` タグのいずれかが指定されたタスク以外のすべてのタスクを実行します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:339
msgid "``--tags tagged`` - run only tasks with at least one tag"
msgstr "``--tags tagged`` - 1 つ以上のタグでタスクのみを実行します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:340
msgid "``--tags untagged`` - run only tasks with no tags"
msgstr "``--tags untagged`` - タグなしでタスクのみを実行します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:342
msgid "For example, to run only tasks and blocks tagged ``configuration`` and ``packages`` in a very long playbook:"
msgstr "たとえば、非常に長い Playbook で、タスクと、``configuration`` および ``packages`` のタグが付けられたブロックのみを実行するには、以下のコマンドを実行します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:348
msgid "To run all tasks except those tagged ``packages``:"
msgstr "``packages`` のタグが付いたタスク以外のすべてのタスクを実行するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:355
msgid "Previewing the results of using tags"
msgstr "タグの使用結果のプレビュー"

#: ../../rst/playbook_guide/playbooks_tags.rst:357
msgid "When you run a role or playbook, you might not know or remember which tasks have which tags, or which tags exist at all. Ansible offers two command-line flags for :ref:`ansible-playbook` that help you manage tagged playbooks:"
msgstr "ロールや Playbook を実行する際、どのタスクがどのタグを持っているのか、あるいはどのタグが存在するのかを知らない、あるいは覚えていない場合があります。Ansible では、タグ付き Playbookの管理に役立つ :ref:`ansible-playbook` にコマンドラインフラグを 2 つ提供しています。"

#: ../../rst/playbook_guide/playbooks_tags.rst:359
msgid "``--list-tags`` - generate a list of available tags"
msgstr "``--list-tags`` - 利用可能なタグのリストを生成します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:360
msgid "``--list-tasks`` - when used with ``--tags tagname`` or ``--skip-tags tagname``, generate a preview of tagged tasks"
msgstr "``--list-tasks`` - ``--tags tagname`` または ``--skip-tags tagname`` と併用すると、タグ付けされたタスクのプレビューを生成します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:362
msgid "For example, if you do not know whether the tag for configuration tasks is ``config`` or ``conf`` in a playbook, role, or tasks file, you can display all available tags without running any tasks:"
msgstr "たとえば、Playbook、ロール、またはタスクファイルの中で、設定タスクのタグが ``config`` か ``conf`` かがわからない場合は、タスクを実行せずに利用可能なタグをすべて表示することができます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:368
msgid "If you do not know which tasks have the tags ``configuration`` and ``packages``, you can pass those tags and add ``--list-tasks``. Ansible lists the tasks but does not execute any of them."
msgstr "``configuration`` と ``packages`` のタグを持つタスクがわからない場合は、これらのタグを渡して ``--list-tasks`` を追加します。Ansible はタスクをリストアップしますが、実行はしません。"

#: ../../rst/playbook_guide/playbooks_tags.rst:374
msgid "These command-line flags have one limitation: they cannot show tags or tasks within dynamically included files or roles. See :ref:`dynamic_vs_static` for more information on differences between static imports and dynamic includes."
msgstr "これらのコマンドラインフラグには、動的インクルードされたファイルやロール内のタグやタスクを表示することができないという制限があります。静的インポートと動的インクルードの違いについての詳細は、「:ref:`dynamic_vs_static`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_tags.rst:379
msgid "Selectively running tagged tasks in re-usable files"
msgstr "再利用可能なファイルでタグ付けされたタスクを選択的に実行"

#: ../../rst/playbook_guide/playbooks_tags.rst:381
msgid "If you have a role or a tasks file with tags defined at the task or block level, you can selectively run or skip those tagged tasks in a playbook if you use a dynamic include instead of a static import. You must use the same tag on the included tasks and on the include statement itself. For example you might create a file with some tagged and some untagged tasks:"
msgstr "タスクやブロックのレベルでタグが定義されているロールやタスクファイルがある場合は、静的インポートの代わりに動的インクルードを使用すると、Playbook 内のタグ付きタスクを選択的に実行したりスキップしたりすることができます。インクルードされるタスクと include 文自体には、同じタグを使用する必要があります。たとえば、タグ付きのタスクとタグなしのタスクを含むファイルを作成する場合は、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_tags.rst:404
msgid "And you might include the tasks file above in a playbook:"
msgstr "また、Playbook に上記のタスクファイルを含めることができます。"

#: ../../rst/playbook_guide/playbooks_tags.rst:416
msgid "When you run the playbook with ``ansible-playbook -i hosts myplaybook.yml --tags \"mytag\"``, Ansible skips the task with no tags, runs the tagged individual task, and runs the two tasks in the block."
msgstr "``ansible-playbook -i hosts myplaybook.yml --tags \"mytag\"`` を使用して Playbook を実行すると、Ansible はタグのないタスクを省略し、タグ付けされた個別のタスクを実行し、ブロック内の 2 つのタスクを実行します。"

#: ../../rst/playbook_guide/playbooks_tags.rst:419
msgid "Configuring tags globally"
msgstr "タグのグローバル設定"

#: ../../rst/playbook_guide/playbooks_tags.rst:421
msgid "If you run or skip certain tags by default, you can use the :ref:`TAGS_RUN` and :ref:`TAGS_SKIP` options in Ansible configuration to set those defaults."
msgstr "デフォルトで特定のタグを実行するか、スキップする場合は、Ansible 設定で :ref:`TAGS_RUN` オプションおよび :ref:`TAGS_SKIP` オプションを使用してこれらのデフォルトを設定できます。"

#: ../../rst/playbook_guide/playbooks_templating.rst:5
msgid "Templating (Jinja2)"
msgstr "テンプレート作成 (Jinja2)"

#: ../../rst/playbook_guide/playbooks_templating.rst:7
msgid "Ansible uses Jinja2 templating to enable dynamic expressions and access to :ref:`variables <playbooks_variables>` and :ref:`facts <vars_and_facts>`. You can use templating with the :ref:`template module <template_module>`. For example, you can create a template for a configuration file, then deploy that configuration file to multiple environments and supply the correct data (IP address, hostname, version) for each environment. You can also use templating in playbooks directly, by templating task names and more. You can use all the :ref:`standard filters and tests <jinja2:builtin-filters>` included in Jinja2. Ansible includes additional specialized filters for selecting and transforming data, tests for evaluating template expressions, and :ref:`lookup_plugins` for retrieving data from external sources such as files, APIs, and databases for use in templating."
msgstr "Ansible は Jinja2 テンプレートを使用して動的な式を有効にし、:ref:`variables <playbooks_variables>` および :ref:`facts <vars_and_facts>` へのアクセスを有効にします。:ref:`template module <template_module>` でテンプレートを使用できます。たとえば、設定ファイルのテンプレートを作成してから、その設定ファイルを複数の環境にデプロイし、各環境に対して適切なデータ（IP アドレス、ホスト名、バージョン）を指定できます。 タスク名などをテンプレート化することで、Playbook でテンプレートを直接使用することもできます。Jinja2 に含まれるすべての :ref:`standard filters and tests <jinja2:builtin-filters>` を使用できます。Ansible には、データを選択および変換するための追加の特殊なフィルター、テンプレート式の評価のテスト、テンプレートで使用するファイル、API、データベースなどの外部ソースからデータを取得するための :ref:`lookup_plugins` が含まれています。"

#: ../../rst/playbook_guide/playbooks_templating.rst:14
msgid "All templating happens on the Ansible controller **before** the task is sent and executed on the target machine. This approach minimizes the package requirements on the target (jinja2 is only required on the controller). It also limits the amount of data Ansible passes to the target machine. Ansible parses templates on the controller and passes only the information needed for each task to the target machine, instead of passing all the data on the controller and parsing it on the target."
msgstr "テンプレート化はすべて、タスクが送信されターゲットマシンで実行する **前** に、Ansible のコントローラーで行われます。このアプローチにより、ターゲットでのパッケージ要件を最小限に抑えることができます (jinja2 はコントローラーでのみ必要です)。また、Ansible がターゲットマシンに渡すデータの量も制限されます。Ansible は、コントローラーですべてのデータを渡してターゲットで解析するのではなく、コントローラーでテンプレートを解析し、各タスクに必要な情報だけをターゲットマシンに渡します。"

#: ../../rst/playbook_guide/playbooks_templating.rst:21
msgid "Files and data used by the :ref:`template module <template_module>` must be utf-8 encoded."
msgstr ":ref:`template module <template_module>` で使用されるファイルおよびデータは utf-8 エンコードされている必要があります。"

#: ../../rst/playbook_guide/playbooks_templating.rst:27
msgid ":ref:`playbook_tips`"
msgstr ":ref:`playbook_tips`"

#: ../../rst/playbook_guide/playbooks_templating.rst:29
msgid "`Jinja2 Docs <https://jinja.palletsprojects.com/en/latest/templates/>`_"
msgstr "`Jinja2 Docs <https://jinja.palletsprojects.com/en/latest/templates/>`_"

#: ../../rst/playbook_guide/playbooks_templating.rst:30
msgid "Jinja2 documentation, includes the syntax and semantics of the templates"
msgstr "Jinja2 ドキュメント（テンプレートの構文およびセマンティクスを含む）"

#: ../../rst/playbook_guide/playbooks_templating_now.rst:4
msgid "The now function: get the current time"
msgstr "now 関数: 現在の時間を取得します。"

#: ../../rst/playbook_guide/playbooks_templating_now.rst:8
msgid "The ``now()`` Jinja2 function retrieves a Python datetime object or a string representation for the current time."
msgstr "Jinja2 関数 ``now()`` は、Python の datetime オブジェクトまたは現在の時間を表す文字列を取得します。"

#: ../../rst/playbook_guide/playbooks_templating_now.rst:10
msgid "The ``now()`` function supports 2 arguments:"
msgstr "``now()`` 関数は、2 つの引数をサポートします。"

#: ../../rst/playbook_guide/playbooks_templating_now.rst:13
msgid "utc"
msgstr "utc"

#: ../../rst/playbook_guide/playbooks_templating_now.rst:13
msgid "Specify ``True`` to get the current time in UTC. Defaults to ``False``."
msgstr "UTC で現在の時間を取得するには、``True`` を指定します。デフォルトは ``False`` です。"

#: ../../<generated>:1
msgid "fmt"
msgstr "fmt"

#: ../../rst/playbook_guide/playbooks_templating_now.rst:16
msgid "Accepts a `strftime <https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior>`_ string that returns a formatted date time string."
msgstr "`strftime <https://docs.python.org/3/library/datetime.html#strftime-strptime-behavior>`_ の文字列を受け取り、形式化された日時文字列を返します。"

#: ../../rst/playbook_guide/playbooks_tests.rst:5
msgid "Tests"
msgstr "テスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:7
msgid "`Tests <https://jinja.palletsprojects.com/en/latest/templates/#tests>`_ in Jinja are a way of evaluating template expressions and returning True or False. Jinja ships with many of these. See `builtin tests`_ in the official Jinja template documentation."
msgstr "Jinja の `Tests <https://jinja.palletsprojects.com/en/latest/templates/#tests>`_ は、テンプレート式を評価して、True または False を返します。Jinja にはこれらの多くが同梱されています。Jinja の公式テンプレートドキュメントの「`builtin tests`_」をご覧ください。"

#: ../../rst/playbook_guide/playbooks_tests.rst:9
msgid "The main difference between tests and filters are that Jinja tests are used for comparisons, whereas filters are used for data manipulation, and have different applications in jinja. Tests can also be used in list processing filters, like ``map()`` and ``select()`` to choose items in the list."
msgstr "テストとフィルターの主な違いは、Jinja のテストは比較に使用されるのに対し、フィルターはデータ操作に使用され、Jinja では用途が異なります。テストは、``map()`` や ``select()`` のように、リスト内の項目を選択するリスト処理フィルターにも使用できます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:11
msgid "Like all templating, tests always execute on the Ansible controller, **not** on the target of a task, as they test local data."
msgstr "すべてのテンプレートと同様、テストは常に、ローカルデータをテストする際にタスクのターゲットでは **なく**、Ansible コントローラーで実行されます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:13
msgid "In addition to those Jinja2 tests, Ansible supplies a few more and users can easily create their own."
msgstr "このような Jinja2 テストに加えて、Ansible はより多くのものを提供しており、ユーザーは独自のテストを簡単に作成できます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:21
msgid "Test syntax"
msgstr "テストの構文"

#: ../../rst/playbook_guide/playbooks_tests.rst:23
msgid "`Test syntax <https://jinja.palletsprojects.com/en/latest/templates/#tests>`_ varies from `filter syntax <https://jinja.palletsprojects.com/en/latest/templates/#filters>`_ (``variable | filter``). Historically Ansible has registered tests as both jinja tests and jinja filters, allowing for them to be referenced using filter syntax."
msgstr "`テストの構文 <https://jinja.palletsprojects.com/en/latest/templates/#tests>` は、`フィルターの構文 <https://jinja.palletsprojects.com/en/latest/templates/#filters>`_ (``variable | filter``) と異なります。これまで Ansible は、テストを jinja テストと jinja フィルターの両方に登録し、filter 構文を使用して参照できるようにしてきました。"

#: ../../rst/playbook_guide/playbooks_tests.rst:25
msgid "As of Ansible 2.5, using a jinja test as a filter will generate a deprecation warning. As of Ansible 2.9+ using jinja test syntax is required."
msgstr "Ansible 2.5 の時点では、jinja テストをフィルターとして使用すると非推奨に関する警告が生成されます。Ansible 2.9 以降では、jinja テスト構文を使用する必要があります。"

#: ../../rst/playbook_guide/playbooks_tests.rst:27
msgid "The syntax for using a jinja test is as follows"
msgstr "jinja テストを使用するための構文は、以下のとおりです。"

#: ../../rst/playbook_guide/playbooks_tests.rst:33
msgid "Such as"
msgstr "例:"

#: ../../rst/playbook_guide/playbooks_tests.rst:42
msgid "Testing strings"
msgstr "文字列のテスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:44
msgid "To match strings against a substring or a regular expression, use the ``match``, ``search`` or ``regex`` tests"
msgstr "サブ文字列または正規表現に対して文字列と一致させるには、「``match``」、「``search``」、または「``regex``」を使用します。"

#: ../../rst/playbook_guide/playbooks_tests.rst:68
msgid "``match`` succeeds if it finds the pattern at the beginning of the string, while ``search`` succeeds if it finds the pattern anywhere within string. By default, ``regex`` works like ``search``, but ``regex`` can be configured to perform other tests as well, by passing the ``match_type`` keyword argument. In particular, ``match_type`` determines the ``re`` method that gets used to perform the search. The full list can be found in the relevant Python documentation `here <https://docs.python.org/3/library/re.html#regular-expression-objects>`_."
msgstr "``match`` は、文字列の先頭でパターンを見つけた場合に成功し、``search`` は、文字列内の任意の場所でパターンを見つけた場合に成功します。デフォルトでは、``regex`` は ``search`` のように動作しますが、``regex`` は ``match_type`` キーワード引数を渡すことで、他のテストも実行するように構成することができます。特に、``match_type`` は、検索を実行する際に使用される ``re`` メソッドを決定します。完全なリストは、`こちら <https://docs.python.org/3/library/re.html#regular-expression-objects>`_ にある関連 Python ドキュメントを参照してください。"

#: ../../rst/playbook_guide/playbooks_tests.rst:70
msgid "All of the string tests also take optional ``ignorecase`` and ``multiline`` arguments. These correspond to ``re.I`` and ``re.M`` from Python's ``re`` library, respectively."
msgstr "すべての文字列テストは、任意の ``ignorecase`` 引数および ``multiline`` 引数を取ります。これらは、Python の ``re`` ライブラリーからそれぞれ ``re.I`` および ``re.M`` に対応します。"

#: ../../rst/playbook_guide/playbooks_tests.rst:75
msgid "Vault"
msgstr "Vault"

#: ../../rst/playbook_guide/playbooks_tests.rst:79
msgid "You can test whether a variable is an inline single vault encrypted value using the ``vault_encrypted`` test."
msgstr "変数がインラインの 1 つの vault で暗号化された値であるかどうかは、``vault_encrypted`` テストでテストできます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:99
msgid "Testing truthiness"
msgstr "真偽の検証"

#: ../../rst/playbook_guide/playbooks_tests.rst:103
msgid "As of Ansible 2.10, you can now perform Python like truthy and falsy checks."
msgstr "Ansible 2.10 以降では、Python を真偽チェックのように実行できるようになりました。"

#: ../../rst/playbook_guide/playbooks_tests.rst:119
msgid "Additionally, the ``truthy`` and ``falsy`` tests accept an optional parameter called ``convert_bool`` that will attempt to convert boolean indicators to actual booleans."
msgstr "また、``truthy`` テストおよび ``falsy`` テストは、ブール値インジケーターを実際のブール値に変換しようとする ``convert_bool`` と呼ばれる任意のパラメーターを受け入れます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:139
msgid "Comparing versions"
msgstr "バージョンの比較"

#: ../../rst/playbook_guide/playbooks_tests.rst:143
msgid "In 2.5 ``version_compare`` was renamed to ``version``"
msgstr "2.5 では、``version_compare`` の名前が ``version`` に変更されました。"

#: ../../rst/playbook_guide/playbooks_tests.rst:145
msgid "To compare a version number, such as checking if the ``ansible_facts['distribution_version']`` version is greater than or equal to '12.04', you can use the ``version`` test."
msgstr "``ansible_facts['distribution_version']`` のバージョンが「12.04」以上かどうかを確認するなど、バージョン番号を比較するには、``version`` テストを使用します。"

#: ../../rst/playbook_guide/playbooks_tests.rst:148
msgid "The ``version`` test can also be used to evaluate the ``ansible_facts['distribution_version']``"
msgstr "``version`` テストを使用して ``ansible_facts['distribution_version']`` を評価することもできます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:154
msgid "If ``ansible_facts['distribution_version']`` is greater than or equal to 12.04, this test returns True, otherwise False."
msgstr "``ansible_facts['distribution_version']`` が 12.04 以上の場合は、このテストで True が返り、それ以外の場合は False が返ります。"

#: ../../rst/playbook_guide/playbooks_tests.rst:156
msgid "The ``version`` test accepts the following operators"
msgstr "``version`` テストでは、以下の演算子を受け入れます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:162
msgid "This test also accepts a 3rd parameter, ``strict`` which defines if strict version parsing as defined by ``ansible.module_utils.compat.version.StrictVersion`` should be used.  The default is ``False`` (using ``ansible.module_utils.compat.version.LooseVersion``), ``True`` enables strict version parsing"
msgstr "このテストは、3 番目のパラメーター ``strict`` も受け入れます。これは、``ansible.module_utils.compat.version.StrictVersion`` で定義された厳格なバージョン解析機能を使用できます。デフォルトは ``False`` (``ansible.module_utils.compat.version.LooseVersion`` を使用) で、``True`` は、厳格なバージョン解析を有効にします。"

#: ../../rst/playbook_guide/playbooks_tests.rst:168
msgid "As of Ansible 2.11 the ``version`` test accepts a ``version_type`` parameter which is mutually exclusive with ``strict``, and accepts the following values"
msgstr "Ansible 2.11 の時点で、``version`` テストは ``strict`` と相互に排他的な ``version_type`` パラメーターを受け入れ、以下の値を受け入れます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:175
msgid "``loose``"
msgstr "``loose``"

#: ../../rst/playbook_guide/playbooks_tests.rst:175
msgid "This type corresponds to the Python ``distutils.version.LooseVersion`` class. All version formats are valid for this type. The rules for comparison are simple and predictable, but may not always give expected results."
msgstr "このタイプは Python ``distutils.version.LooseVersion`` クラスに対応します。すべてのバージョン形式はこのタイプで有効です。比較のルールはシンプルで予測可能ですが、常に想定される結果が提供されるとは限りません。"

#: ../../rst/playbook_guide/playbooks_tests.rst:178
msgid "``strict``"
msgstr "``strict``"

#: ../../rst/playbook_guide/playbooks_tests.rst:178
msgid "This type corresponds to the Python ``distutils.version.StrictVersion`` class. A version number consists of two or three dot-separated numeric components, with an optional \"pre-release\" tag on the end. The pre-release tag consists of a single letter 'a' or 'b' followed by a number.  If the numeric components of two version numbers are equal, then one with a pre-release tag will always be deemed earlier (lesser) than one without."
msgstr "このタイプは、Python ``distutils.version.StrictVersion`` クラスに対応します。バージョン番号は、2 つまたは 3 つのドットで区切られたコンポーネントで設定され、オプションで release タグが付きます。プレリリースタグは 1 文字 (a または b) とそれに続く数字で設定されます。2 つのバージョン番号の数値が等しく、プレリリースタグの付いたコンポーネントは常に 1 つ前の (1 つ小さい) とみなされます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:181
msgid "``semver``/``semantic``"
msgstr "``semver``/``semantic``"

#: ../../rst/playbook_guide/playbooks_tests.rst:181
msgid "This type implements the `Semantic Version <https://semver.org>`_ scheme for version comparison."
msgstr "このタイプは、バージョン比較の `Semantic Version <https://semver.org>`_ スキームを実装します。"

#: ../../rst/playbook_guide/playbooks_tests.rst:184
msgid "``pep440``"
msgstr "``pep440``"

#: ../../rst/playbook_guide/playbooks_tests.rst:184
msgid "This type implements the Python `PEP-440 <https://peps.python.org/pep-0440/>`_ versioning rules for version comparison. Added in version 2.14."
msgstr "このタイプは、バージョン比較の Python `PEP-440 <https://peps.python.org/pep-0440/>`_ バージョン管理ルールを実装します。バージョン 2.14 で追加されました。"

#: ../../rst/playbook_guide/playbooks_tests.rst:186
msgid "Using ``version_type`` to compare a semantic version would be achieved like the following"
msgstr "``version_type`` を使用してセマンティックバージョンを比較すると、以下のように実行されます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:192
msgid "In Ansible 2.14, the ``pep440`` option for ``version_type`` was added, and the rules of this type are defined in `PEP-440 <https://peps.python.org/pep-0440/>`_. The following example showcases how this type can differentiate pre-releases as being less than a general release."
msgstr "Ansible 2.14 では、``version_type`` の ``pep440`` オプションが追加され、このタイプのルールは `PEP-440 <https://peps.python.org/pep-0440/>`_ で定義されています。以下の例では、このタイプのリリースを一般的なリリースよりも小さいものとして、区別できることが分かります。"

#: ../../rst/playbook_guide/playbooks_tests.rst:198
msgid "When using ``version`` in a playbook or role, don't use ``{{ }}`` as described in the `FAQ <https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#when-should-i-use-also-how-to-interpolate-variables-or-dynamic-variable-names>`_"
msgstr "Playbook またはロールで ``version`` を使用する場合は、`FAQ <https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#when-should-i-use-also-how-to-interpolate-variables-or-dynamic-variable-names>`_ で説明されているように ``{{ }}`` を使用しないでください。"

#: ../../rst/playbook_guide/playbooks_tests.rst:213
msgid "Set theory tests"
msgstr "セット理論テスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:217
msgid "In 2.5 ``issubset`` and ``issuperset`` were renamed to ``subset`` and ``superset``"
msgstr "2.5 では、``issubset`` および ``issuperset`` の名前が ``subset`` および ``superset`` に変更されました。"

#: ../../rst/playbook_guide/playbooks_tests.rst:219
msgid "To see if a list includes or is included by another list, you can use 'subset' and 'superset'"
msgstr "リストに別のリストが含まれているか、またはリストが別のリストに含まれているかを確認するには、「subset」および「superset」を使用します。"

#: ../../rst/playbook_guide/playbooks_tests.rst:238
msgid "Testing if a list contains a value"
msgstr "リストに値が含まれるかどうかのテスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:242
msgid "Ansible includes a ``contains`` test which operates similarly, but in reverse of the Jinja2 provided ``in`` test. The ``contains`` test is designed to work with the ``select``, ``reject``, ``selectattr``, and ``rejectattr`` filters"
msgstr "Ansible には、Jinja2 が提供する ``in`` テストとは逆に、同様の動作をする ``contains`` テストが含まれています。``contains`` テストは、フィルターの ``select``、``reject``、``selectattr``、および ``rejectattr`` で動作するように設計されています。"

#: ../../rst/playbook_guide/playbooks_tests.rst:274
msgid "Testing if a list value is True"
msgstr "リスト値が True の場合のテスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:278
msgid "You can use `any` and `all` to check if any or all elements in a list are true or not"
msgstr "`any` および `all` を使用して、リスト内の一部またはすべての要素が true かどうかを確認できます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:303
msgid "Testing paths"
msgstr "パスのテスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:305
msgid "In 2.5 the following tests were renamed to remove the ``is_`` prefix"
msgstr "2.5 では、以下のテストの名前が変更になり、``is_`` プレフィックスが削除されました。"

#: ../../rst/playbook_guide/playbooks_tests.rst:307
msgid "The following tests can provide information about a path on the controller"
msgstr "以下のテストは、コントローラー上のパスに関する情報を提供します。"

#: ../../rst/playbook_guide/playbooks_tests.rst:350
msgid "Testing size formats"
msgstr "サイズ形式のテスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:352
msgid "The ``human_readable`` and ``human_to_bytes`` functions let you test your playbooks to make sure you are using the right size format in your tasks, and that you provide Byte format to computers and human-readable format to people."
msgstr "``human_readable`` 関数および ``human_to_bytes`` 関数を使用すると、Playbook をテストして、タスクで適切なサイズの形式を使用しているかどうか、また、コンピューターにはバイト形式、およびユーザーには人間が判読可能な形式を提供しているかどうかを確認することができます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:357
msgid "Human readable"
msgstr "人間が読み取り可能"

#: ../../rst/playbook_guide/playbooks_tests.rst:359
msgid "Asserts whether the given string is human readable or not."
msgstr "指定の文字列が人が判読できるかどうかをアサートします。"

#: ../../rst/playbook_guide/playbooks_tests.rst:361
#: ../../rst/playbook_guide/playbooks_tests.rst:386
msgid "For example"
msgstr "たとえば、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_tests.rst:375
#: ../../rst/playbook_guide/playbooks_tests.rst:402
msgid "This would result in"
msgstr "これにより、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_tests.rst:382
msgid "Human to bytes"
msgstr "人間からバイト"

#: ../../rst/playbook_guide/playbooks_tests.rst:384
msgid "Returns the given string in the Bytes format."
msgstr "指定した文字列をバイト形式で返します。"

#: ../../rst/playbook_guide/playbooks_tests.rst:412
msgid "Testing task results"
msgstr "タスク結果のテスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:414
msgid "The following tasks are illustrative of the tests meant to check the status of tasks"
msgstr "以下のタスクは、タスクのステータスを確認するためのテストを示しています。"

#: ../../rst/playbook_guide/playbooks_tests.rst:445
msgid "From 2.1, you can also use success, failure, change, and skip so that the grammar matches, for those who need to be strict about it."
msgstr "2.1 以降、文法を厳密にする必要がある場合に、success、failure、change、および skip を使用して、文法が一致するようにすることもできます。"

#: ../../rst/playbook_guide/playbooks_tests.rst:450
msgid "Type Tests"
msgstr "タイプテスト"

#: ../../rst/playbook_guide/playbooks_tests.rst:452
msgid "When looking to determine types, it may be tempting to use the ``type_debug`` filter and compare that to the string name of that type, however, you should instead use type test comparisons, such as:"
msgstr "タイプを決定する際には、``type_debug`` フィルターを使用して、そのタイプの文字列名と比較したくなるかもしれません。しかし、代わりに以下のようなタイプテストの比較を使用する必要があります。"

#: ../../rst/playbook_guide/playbooks_variables.rst:5
msgid "Using Variables"
msgstr "変数の使用"

#: ../../rst/playbook_guide/playbooks_variables.rst:7
msgid "Ansible uses variables to manage differences between systems. With Ansible, you can execute tasks and playbooks on multiple different systems with a single command. To represent the variations among those different systems, you can create variables with standard YAML syntax, including lists and dictionaries. You can define these variables in your playbooks, in your :ref:`inventory <intro_inventory>`, in re-usable :ref:`files <playbooks_reuse>` or :ref:`roles <playbooks_reuse_roles>`, or at the command line. You can also create variables during a playbook run by registering the return value or values of a task as a new variable."
msgstr "Ansible は変数を使用してシステム間の違いを管理します。Ansible では、1 つのコマンドで複数の異なるシステム上でタスクや Playbook を実行することができます。これらの異なるシステム間の差異を表現するために、リストやディクショナリーなどの標準的な YAML 構文で変数を作成できます。これらの変数は、Playbook、:ref:`インベントリー <intro_inventory>`、再利用可能な :ref:`ファイル <playbooks_reuse>`、または :ref:`ロール <playbooks_reuse_roles>`、もしくはコマンドラインで定義できます。また、タスクの戻り値を新しい変数として登録することで、Playbook の実行中に変数を作成することもできます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:9
msgid "After you create variables, either by defining them in a file, passing them at the command line, or registering the return value or values of a task as a new variable, you can use those variables in module arguments, in :ref:`conditional \"when\" statements <playbooks_conditionals>`, in :ref:`templates <playbooks_templating>`, and in :ref:`loops <playbooks_loops>`. The `ansible-examples github repository <https://github.com/ansible/ansible-examples>`_ contains many examples of using variables in Ansible."
msgstr "ファイルで定義したり、コマンドラインで渡したり、タスクの戻り値を新しい変数として登録したりして変数を作成した後は、その変数をモジュールの引数、:ref:`条件分岐の「when」文 <playbooks_conditionals>`、:ref:`テンプレート <playbooks_templating>`、および :ref:`ループ <playbooks_loops>` で使用することができます。`ansible-examples github リポジトリー <https://github.com/ansible/ansible-examples>`_ には、Ansible での変数の使用例が多数掲載されています。"

#: ../../rst/playbook_guide/playbooks_variables.rst:11
msgid "Once you understand the concepts and examples on this page, read about :ref:`Ansible facts <vars_and_facts>`, which are variables you retrieve from remote systems."
msgstr "このページの概念と例を理解したら、リモートシステムから取得する変数である :ref:`Ansible ファクト <vars_and_facts>` を確認します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:19
msgid "Creating valid variable names"
msgstr "有効な変数名の作成"

#: ../../rst/playbook_guide/playbooks_variables.rst:21
msgid "Not all strings are valid Ansible variable names. A variable name can only include letters, numbers, and underscores. `Python keywords`_ or :ref:`playbook keywords<playbook_keywords>` are not valid variable names. A variable name cannot begin with a number."
msgstr "すべての文字列が有効な Ansible の変数名になるわけではありません。変数名には、文字、数字、アンダースコアのみを含めることができます。`Python キーワード`_ または :ref:`playbook キーワード<playbook_keywords>` は有効な変数名ではありません。変数名は、数字で始めることはできません。"

#: ../../rst/playbook_guide/playbooks_variables.rst:23
msgid "Variable names can begin with an underscore. In many programming languages, variables that begin with an underscore are private. This is not true in Ansible. Variables that begin with an underscore are treated exactly the same as any other variable. Do not rely on this convention for privacy or security."
msgstr "変数名はアンダースコアで始めることができます。多くのプログラミング言語では、アンダースコアで始まる変数はプライベートです。Ansible ではこれは当てはまりません。アンダースコアで始まる変数は、他の変数とまったく同じように扱われます。プライバシーやセキュリティーのために、この規約に依存しないでください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:25
msgid "This table gives examples of valid and invalid variable names:"
msgstr "この表は、有効かつ無効な変数名の例を紹介します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:31
msgid "Valid variable names"
msgstr "有効な変数名"

#: ../../rst/playbook_guide/playbooks_variables.rst:31
msgid "Not valid"
msgstr "有効ではない"

#: ../../rst/playbook_guide/playbooks_variables.rst:33
msgid "``foo``"
msgstr "``foo``"

#: ../../rst/playbook_guide/playbooks_variables.rst:33
msgid "``*foo``, `Python keywords`_ such as ``async`` and ``lambda``"
msgstr "``*foo``、`Python キーワード`_ (``async``、``lambda`` など)"

#: ../../rst/playbook_guide/playbooks_variables.rst:35
msgid "``foo_env``"
msgstr "``foo_env``"

#: ../../rst/playbook_guide/playbooks_variables.rst:35
msgid ":ref:`playbook keywords<playbook_keywords>` such as ``environment``"
msgstr "``environment`` などの :ref:`playbook キーワード<playbook_keywords>`"

#: ../../rst/playbook_guide/playbooks_variables.rst:37
msgid "``foo_port``"
msgstr "``foo_port``"

#: ../../rst/playbook_guide/playbooks_variables.rst:37
msgid "``foo-port``, ``foo port``, ``foo.port``"
msgstr "``foo-port``、``foo port``、``foo.port``"

#: ../../rst/playbook_guide/playbooks_variables.rst:39
msgid "``foo5``, ``_foo``"
msgstr "``foo5``、``_foo``"

#: ../../rst/playbook_guide/playbooks_variables.rst:39
msgid "``5foo``, ``12``"
msgstr "``5foo``、``12``"

#: ../../rst/playbook_guide/playbooks_variables.rst:45
msgid "Simple variables"
msgstr "単純な変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:47
msgid "Simple variables combine a variable name with a single value. You can use this syntax (and the syntax for lists and dictionaries shown below) in a variety of places. For details about setting variables in inventory, in playbooks, in reusable files, in roles, or at the command line, see :ref:`setting_variables`."
msgstr "単純変数は、変数名と 1 つの値を組み合わせたものです。この構文 (および後述のリストやディレクトリーの構文) は、さまざまな場所で使用できます。インベントリー、Playbook、再利用可能なファイル、ロール、コマンドラインでの変数設定の詳細については、「:ref:`setting_variables`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:50
msgid "Defining simple variables"
msgstr "簡単な変数の定義"

#: ../../rst/playbook_guide/playbooks_variables.rst:52
msgid "You can define a simple variable using standard YAML syntax. For example:"
msgstr "標準の YAML 構文を使用して単純な変数を定義できます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:59
msgid "Referencing simple variables"
msgstr "単純な変数の参照"

#: ../../rst/playbook_guide/playbooks_variables.rst:61
msgid "After you define a variable, use Jinja2 syntax to reference it. Jinja2 variables use double curly braces. For example, the expression ``My amp goes to {{ max_amp_value }}`` demonstrates the most basic form of variable substitution. You can use Jinja2 syntax in playbooks. For example:"
msgstr "変数を定義した後は、Jinja2 の構文を使用して変数を参照します。Jinja2 の変数には二重の中括弧が使用されます。たとえば、``My amp goes to {{ max_amp_value }}`` という式は、最も基本的な形の変数置換を示しています。Playbook では、Jinja2 構文を使用できます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:69
msgid "In this example, the variable defines the location of a file, which can vary from one system to another."
msgstr "この例では、変数がファイルの場所を定義していますが、これはシステムごとに異なる可能性があります。"

#: ../../rst/playbook_guide/playbooks_variables.rst:73
msgid "Ansible allows Jinja2 loops and conditionals in :ref:`templates <playbooks_templating>` but not in playbooks. You cannot create a loop of tasks. Ansible playbooks are pure machine-parseable YAML."
msgstr "Ansible では、:ref:`テンプレート <playbooks_templating>` で Jinja2 のループや条件分岐を使用できますが、Playbook では使用できません。タスクのループを作成することはできません。Ansible の Playbook は純粋に機械で解析可能な YAML です。"

#: ../../rst/playbook_guide/playbooks_variables.rst:78
msgid "When to quote variables (a YAML gotcha)"
msgstr "変数を引用するタイミング (YAML に関する注意点)"

#: ../../rst/playbook_guide/playbooks_variables.rst:80
msgid "If you start a value with ``{{ foo }}``, you must quote the whole expression to create valid YAML syntax. If you do not quote the whole expression, the YAML parser cannot interpret the syntax - it might be a variable or it might be the start of a YAML dictionary. For guidance on writing YAML, see the :ref:`yaml_syntax` documentation."
msgstr "値を ``{{ foo }}`` で始めた場合、有効な YAML 構文を作成するためには式全体を引用しなければなりません。式全体を引用符で囲まないと、YAML パーサーはその構文を解釈できません。それは変数かもしれないし、YAML ディレクトリーの始まりかもしれません。YAML の記述方法については、「:ref:`yaml_syntax`」のドキュメントを参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:82
msgid "If you use a variable without quotes like this:"
msgstr "引用符なしの変数を使用する場合は、以下のようになります。"

#: ../../rst/playbook_guide/playbooks_variables.rst:90
msgid "You will see: ``ERROR! Syntax Error while loading YAML.`` If you add quotes, Ansible works correctly:"
msgstr "``ERROR! Syntax Error while loading YAML.`` を参照してください。引用符を追加すると、Ansible が正常に機能します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:101
msgid "Boolean variables"
msgstr "ブール値の変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:103
msgid "Ansible accepts a broad range of values for boolean variables: ``true/false``, ``1/0``, ``yes/no``, ``True/False`` and so on. The matching of valid strings is case insensitive. While documentation examples focus on ``true/false`` to be compatible with ``ansible-lint`` default settings, you can use any of the following:"
msgstr "Ansible では、ブール変数 ``true/false``、``1/0``、``yes/no``、``True/False`` など、幅広い値を使用できます。有効な文字列の照合では、大文字と小文字を区別しません。ドキュメントのサンプルは、``true/false`` と ``ansible-lint`` のデフォルト設定との互換性を確保することに焦点を置いていますが、以下のいずれかを使用できます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:110
msgid "Valid values"
msgstr "有効な値"

#: ../../rst/playbook_guide/playbooks_variables.rst:112
msgid "``True`` , ``'true'`` , ``'t'`` , ``'yes'`` , ``'y'`` , ``'on'`` , ``'1'`` , ``1`` , ``1.0``"
msgstr "``True`` , ``'true'`` , ``'t'`` , ``'yes'`` , ``'y'`` , ``'on'`` , ``'1'`` , ``1`` , ``1.0``"

#: ../../rst/playbook_guide/playbooks_variables.rst:112
msgid "Truthy values"
msgstr "真理値"

#: ../../rst/playbook_guide/playbooks_variables.rst:114
msgid "``False`` , ``'false'`` , ``'f'`` , ``'no'`` , ``'n'`` , ``'off'`` , ``'0'`` , ``0`` , ``0.0``"
msgstr "``False`` , ``'false'`` , ``'f'`` , ``'no'`` , ``'n'`` , ``'off'`` , ``'0'`` , ``0`` , ``0.0``"

#: ../../rst/playbook_guide/playbooks_variables.rst:114
msgid "Falsy values"
msgstr "偽値"

#: ../../rst/playbook_guide/playbooks_variables.rst:121
msgid "List variables"
msgstr "リスト変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:123
msgid "A list variable combines a variable name with multiple values. The multiple values can be stored as an itemized list or in square brackets ``[]``, separated with commas."
msgstr "リスト変数は、変数名と複数の値を組み合わせたものです。複数の値は、項目別のリストとして、または角括弧 ``[]`` の中にコンマで区切って格納できます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:126
msgid "Defining variables as lists"
msgstr "変数をリストとして定義"

#: ../../rst/playbook_guide/playbooks_variables.rst:128
msgid "You can define variables with multiple values using YAML lists. For example:"
msgstr "YAML リストを使用して、複数の値で変数を定義できます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:138
msgid "Referencing list variables"
msgstr "リスト変数の参照"

#: ../../rst/playbook_guide/playbooks_variables.rst:140
msgid "When you use variables defined as a list (also called an array), you can use individual, specific fields from that list. The first item in a list is item 0, the second item is item 1. For example:"
msgstr "リスト (配列とも呼ばれる) として定義された変数を使用する場合は、そのリストから個々の特定のフィールドを使用することができます。リストの最初の項目は項目 0、2 番目の項目は項目 1 です。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:146
msgid "The value of this expression would be \"northeast\"."
msgstr "この式の値は「northeast」になります。"

#: ../../rst/playbook_guide/playbooks_variables.rst:151
msgid "Dictionary variables"
msgstr "ディクショナリー変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:153
msgid "A dictionary stores the data in key-value pairs. Usually, dictionaries are used to store related data, such as the information contained in an ID or a user profile."
msgstr "ディクショナリーは、データをキーと値のペアに保存します。通常、ディクショナリーは ID またはユーザープロファイルに含まれる情報などの関連データを保存するために使用されます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:156
msgid "Defining variables as key:value dictionaries"
msgstr "変数を key:value ディクショナリーとして定義"

#: ../../rst/playbook_guide/playbooks_variables.rst:158
msgid "You can define more complex variables using YAML dictionaries. A YAML dictionary maps keys to values.  For example:"
msgstr "YAML ディクショナリーを使用してより複雑な変数を定義できます。YAML ディクショナリーはキーを値にマッピングします。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:167
msgid "Referencing key:value dictionary variables"
msgstr "key:value ディクショナリー変数の参照"

#: ../../rst/playbook_guide/playbooks_variables.rst:169
msgid "When you use variables defined as a key:value dictionary (also called a hash), you can use individual, specific fields from that dictionary using either bracket notation or dot notation:"
msgstr "key:value ディクショナリー (ハッシュとも呼ばれます) として定義された変数を使用する場合は、括弧表記またはドット表記のいずれかを使用して、そのディクショナリーの個々の特定のフィールドを使用できます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:176
msgid "Both of these examples reference the same value (\"one\"). Bracket notation always works. Dot notation can cause problems because some keys collide with attributes and methods of python dictionaries. Use bracket notation if you use keys which start and end with two underscores (which are reserved for special meanings in python) or are any of the known public attributes:"
msgstr "これらの例では、どちらも同じ値 (「one」) を参照しています。括弧表記は常に有効です。ドット表記では、一部のキーが python ディクショナリーの属性やメソッドと衝突するため、問題が生じます。2 つのアンダースコアで始まって終わるキー (python では特別な意味を持つものとして予約されています) や、既知の公開属性を使用する場合は、括弧表記を使用してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:178
msgid "``add``, ``append``, ``as_integer_ratio``, ``bit_length``, ``capitalize``, ``center``, ``clear``, ``conjugate``, ``copy``, ``count``, ``decode``, ``denominator``, ``difference``, ``difference_update``, ``discard``, ``encode``, ``endswith``, ``expandtabs``, ``extend``, ``find``, ``format``, ``fromhex``, ``fromkeys``, ``get``, ``has_key``, ``hex``, ``imag``, ``index``, ``insert``, ``intersection``, ``intersection_update``, ``isalnum``, ``isalpha``, ``isdecimal``, ``isdigit``, ``isdisjoint``, ``is_integer``, ``islower``, ``isnumeric``, ``isspace``, ``issubset``, ``issuperset``, ``istitle``, ``isupper``, ``items``, ``iteritems``, ``iterkeys``, ``itervalues``, ``join``, ``keys``, ``ljust``, ``lower``, ``lstrip``, ``numerator``, ``partition``, ``pop``, ``popitem``, ``real``, ``remove``, ``replace``, ``reverse``, ``rfind``, ``rindex``, ``rjust``, ``rpartition``, ``rsplit``, ``rstrip``, ``setdefault``, ``sort``, ``split``, ``splitlines``, ``startswith``, ``strip``, ``swapcase``, ``symmetric_difference``, ``symmetric_difference_update``, ``title``, ``translate``, ``union``, ``update``, ``upper``, ``values``, ``viewitems``, ``viewkeys``, ``viewvalues``, ``zfill``."
msgstr "``add``、``append``、``as_integer_ratio``、``bit_length``、``capitalize``、``center``、``clear``、``conjugate``、``copy``、``count``、``decode``、``denominator``、``difference``、``difference_update``、``discard``、``encode``、``endswith``、``expandtabs``、``extend``、``find``、``format``、``fromhex``、``fromkeys``、``get``、``has_key``、``hex``、``imag``、``index``、``insert``、``intersection``、``intersection_update``、``isalnum``、``isalpha``、``isdecimal``、``isdigit``、``isdisjoint``、``is_integer``、``islower``、``isnumeric``、``isspace``、``issubset``、``issuperset``、``istitle``、``isupper``、``items``、``iteritems``、``iterkeys``、``itervalues``、``join``、``keys``、``ljust``、``lower``、``lstrip``、``numerator``、``partition``、``pop``、``popitem``、``real``、``remove``、``replace``、``reverse``、``rfind``、``rindex``、``rjust``、``rpartition``、``rsplit``、``rstrip``、``setdefault``、``sort``、``split``、``splitlines``、``startswith``、``strip``、``swapcase``、``symmetric_difference``、``symmetric_difference_update``、``title``、``translate``、``union``、``update``、``upper``、``values``、``viewitems``、``viewkeys``、``viewvalues``、``zfill``"

#: ../../rst/playbook_guide/playbooks_variables.rst:183
msgid "Registering variables"
msgstr "変数の登録"

#: ../../rst/playbook_guide/playbooks_variables.rst:185
msgid "You can create variables from the output of an Ansible task with the task keyword ``register``. You can use registered variables in any later tasks in your play. For example:"
msgstr "タスクキーワード ``register`` を使用して、Ansible タスクの出力から変数を作成することができます。登録した変数は、プレイ中の後続のタスクで使用することができます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:202
msgid "For more examples of using registered variables in conditions on later tasks, see :ref:`playbooks_conditionals`. Registered variables may be simple variables, list variables, dictionary variables, or complex nested data structures. The documentation for each module includes a ``RETURN`` section describing the return values for that module. To see the values for a particular task, run your playbook with ``-v``."
msgstr "登録された変数を後のタスクの条件で使用する例は、「:ref:`playbooks_conditionals`」を参照してください。登録した変数には、単純な変数、リスト変数、ディクショナリー変数、複雑にネストしたデータ構造などがあります。各モジュールのドキュメントには、そのモジュールの戻り値を説明した ``RETURN`` セクションがあります。特定のタスクの値を確認するには、``-v`` で Playbook を実行します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:204
msgid "Registered variables are stored in memory. You cannot cache registered variables for use in future playbook runs. Registered variables are only valid on the host for the rest of the current playbook run, including subsequent plays within the same playbook run."
msgstr "登録された変数はメモリーに保存されます。登録された変数を今後のプレイで使用するためにキャッシュすることはできません。登録された変数は、現在の Playbook の残りが実行されている間、ホスト上でのみ有効です (同じ Playbook の実行中の後続のプレイを含む)。"

#: ../../rst/playbook_guide/playbooks_variables.rst:206
msgid "Registered variables are host-level variables. When you register a variable in a task with a loop, the registered variable contains a value for each item in the loop. The data structure placed in the variable during the loop will contain a ``results`` attribute, that is a list of all responses from the module. For a more in-depth example of how this works, see the :ref:`playbooks_loops` section on using register with a loop."
msgstr "登録された変数は、ホストレベルの変数です。ループのあるタスクで変数を登録すると、登録された変数にはループ内の各項目の値が入ります。ループ中に変数に置かれたデータ構造には、``results`` 属性、つまりモジュールからの全応答のリストが含まれます。この動作の詳細な例については、ループで登録の使用に関する「:ref:`playbooks_loops`」セクションを参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:208
msgid "If a task fails or is skipped, Ansible still registers a variable with a failure or skipped status, unless the task is skipped based on tags. See :ref:`tags` for information on adding and using tags."
msgstr "タスクが失敗またはスキップしても、タグに基づいてタスクがスキップされていない限り、Ansible は失敗またはスキップのステータスで変数を登録します。タグの追加および使用に関する情報は、「:ref:`tags`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:213
msgid "Referencing nested variables"
msgstr "ネストされた変数の参照"

#: ../../rst/playbook_guide/playbooks_variables.rst:215
msgid "Many registered variables (and :ref:`facts <vars_and_facts>`) are nested YAML or JSON data structures. You cannot access values from these nested data structures with the simple ``{{ foo }}`` syntax. You must use either bracket notation or dot notation. For example, to reference an IP address from your facts using the bracket notation:"
msgstr "多くの登録された変数 (および :ref:`ファクト <vars_and_facts>`) は、ネストされた YAML または JSON データ構造です。これらのネストしたデータ構造の値には、単純な ``{{ foo }}`` の構文ではアクセスできません。括弧表記またはドット表記のいずれかを使用する必要があります。たとえば、括弧表記を使用してファクトから IP アドレスを参照するには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_variables.rst:221
msgid "To reference an IP address from your facts using the dot notation:"
msgstr "ドット表記を使用してファクトから IP アドレスを参照するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:231
msgid "Transforming variables with Jinja2 filters"
msgstr "Jinja2 フィルターを使用した変数の変換"

#: ../../rst/playbook_guide/playbooks_variables.rst:233
msgid "Jinja2 filters let you transform the value of a variable within a template expression. For example, the ``capitalize`` filter capitalizes any value passed to it; the ``to_yaml`` and ``to_json`` filters change the format of your variable values. Jinja2 includes many `built-in filters <https://jinja.palletsprojects.com/templates/#builtin-filters>`_ and Ansible supplies many more filters. To find more examples of filters, see :ref:`playbooks_filters`."
msgstr "Jinja2 のフィルターは、テンプレート式内の変数の値を変換することができます。たとえば、``capitalize`` フィルターは、渡された値をすべて大文字にします。``to_yaml`` フィルターおよび ``to_json`` フィルターは、変数の値の形式を変更します。Jinja2 には多くの `built-in フィルター <https://jinja.palletsprojects.com/templates/#builtin-filters>`_ があり、Ansible にはさらに多くのフィルターが用意されています。フィルターのその他の例については、「:ref:`playbooks_filters`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:238
msgid "Where to set variables"
msgstr "変数を設定する場所"

#: ../../rst/playbook_guide/playbooks_variables.rst:240
msgid "You can define variables in a variety of places, such as in inventory, in playbooks, in reusable files, in roles, and at the command line. Ansible loads every possible variable it finds, then chooses the variable to apply based on :ref:`variable precedence rules <ansible_variable_precedence>`."
msgstr "変数は、インベントリー、Playbook、再利用可能ファイル、ロール、コマンドラインなど、さまざまな場所で定義することができます。Ansible は、検出可能なすべての変数を読み込み、:ref:`変数の優先順位ルール <ansible_variable_precedence>` に基づいて適用する変数を選択します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:245
msgid "Defining variables in inventory"
msgstr "インベントリーでの変数の定義"

#: ../../rst/playbook_guide/playbooks_variables.rst:247
msgid "You can define different variables for each individual host, or set shared variables for a group of hosts in your inventory. For example, if all machines in the ``[Boston]`` group use 'boston.ntp.example.com' as an NTP server, you can set a group variable. The :ref:`intro_inventory` page has details on setting :ref:`host variables <host_variables>` and :ref:`group variables <group_variables>` in inventory."
msgstr "個々のホストごとに異なる変数を定義したり、インベントリー内のホストグループに共有変数を設定することができます。たとえば、``[Boston]`` グループのすべてのマシンが NTP サーバーとして「boston.ntp.example.com」を使用する場合は、グループ変数を設定することができます。「:ref:`intro_inventory`」 ページには、インベントリーで :ref:`host 変数 <host_variables>` および :ref:`group 変数 <group_variables>` を設定するための詳細が記載されています。"

#: ../../rst/playbook_guide/playbooks_variables.rst:252
msgid "Defining variables in a play"
msgstr "プレイでの変数の定義"

#: ../../rst/playbook_guide/playbooks_variables.rst:254
msgid "You can define variables directly in a playbook play:"
msgstr "変数は Playbook プレイで直接定義できます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:262
msgid "When you define variables in a play, they are only visible to tasks executed in that play."
msgstr "プレイで変数を定義すると、そのプレイで実行しているタスクでのみ表示されます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:268
msgid "Defining variables in included files and roles"
msgstr "インクルードファイルおよびロールでの変数の定義"

#: ../../rst/playbook_guide/playbooks_variables.rst:270
msgid "You can define variables in reusable variables files and/or in reusable roles. When you define variables in reusable variable files, the sensitive variables are separated from playbooks. This separation enables you to store your playbooks in a source control software and even share the playbooks, without the risk of exposing passwords or other sensitive and personal data. For information about creating reusable files and roles, see :ref:`playbooks_reuse`."
msgstr "変数は、再利用可能な変数ファイルや再利用可能なロールに定義することができます。再利用可能な変数ファイルに変数を定義すると、機密性の高い変数が Playbook から分離されます。この分離により、パスワードなどの機密情報や個人情報を流出させることなく、ソースコントロールソフトウェアに Playbook を保存したり、Playbook を共有したりすることができます。再利用可能なファイルやロールの作成は、「:ref:`playbooks_reuse`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:272
msgid "This example shows how you can include variables defined in an external file:"
msgstr "この例は、外部ファイルで定義された変数を追加する方法を示しています。"

#: ../../rst/playbook_guide/playbooks_variables.rst:290
msgid "The contents of each variables file is a simple YAML dictionary. For example:"
msgstr "各変数ファイルの内容は、単純な YAML ディクショナリーです。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:300
msgid "You can keep per-host and per-group variables in similar files. To learn about organizing your variables, see :ref:`splitting_out_vars`."
msgstr "ホスト別およびグループ別の変数を同様のファイルに維持することができます。変数を整理する方法は、「:ref:`splitting_out_vars`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:305
msgid "Defining variables at runtime"
msgstr "ランタイム時の変数の定義"

#: ../../rst/playbook_guide/playbooks_variables.rst:307
msgid "You can define variables when you run your playbook by passing variables at the command line using the ``--extra-vars`` (or ``-e``) argument. You can also request user input with a ``vars_prompt`` (see :ref:`playbooks_prompts`). When you pass variables at the command line, use a single quoted string, that contains one or more variables, in one of the formats below."
msgstr "Playbook の実行時に変数を定義するには、コマンドラインで ``--extra-vars`` (または ``-e``) 引数を使用して変数を渡します。また、``vars_prompt`` (:ref:`playbooks_prompts` 参照) でユーザーの入力を要求することもできます。コマンドラインで変数を渡すときは、以下のいずれかの形式で、1 つまたは複数の変数を含む一重引用符で囲まれた文字列を使用します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:310
msgid "key=value format"
msgstr "key=value 形式"

#: ../../rst/playbook_guide/playbooks_variables.rst:312
msgid "Values passed in using the ``key=value`` syntax are interpreted as strings. Use the JSON format if you need to pass non-string values such as Booleans, integers, floats, lists, and so on."
msgstr "``key=value`` 構文を使用して渡される値は文字列として解釈されます。ブール値、整数、浮動小数点、リストなど、文字列以外の値を渡す必要がある場合は、JSON 形式を使用します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:319
msgid "JSON string format"
msgstr "JSON 文字列の形式"

#: ../../rst/playbook_guide/playbooks_variables.rst:326
msgid "When passing variables with ``--extra-vars``, you must escape quotes and other special characters appropriately for both your markup (for example, JSON), and for your shell:"
msgstr "``--extra-vars`` で変数を渡す場合には、マークアップ (JSON など) とシェルの両方で、引用符やその他の特殊文字を適切にエスケープする必要があります。"

#: ../../rst/playbook_guide/playbooks_variables.rst:334
msgid "If you have a lot of special characters, use a JSON or YAML file containing the variable definitions."
msgstr "特殊文字が多数ある場合は、変数定義を含む JSON ファイルまたは YAML ファイルを使用します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:337
msgid "vars from a JSON or YAML file"
msgstr "JSON ファイルまたは YAML ファイルの変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:347
msgid "Variable precedence: Where should I put a variable?"
msgstr "変数の優先順位: 変数をどこに置くべきか"

#: ../../rst/playbook_guide/playbooks_variables.rst:349
msgid "You can set multiple variables with the same name in many different places. When you do this, Ansible loads every possible variable it finds, then chooses the variable to apply based on variable precedence. In other words, the different variables will override each other in a certain order."
msgstr "同じ名前の複数の変数をさまざまな場所に設定することができます。これを行うと、Ansible は検出可能なすべての変数を読み込み、次に変数の優先順位に基づいて適用する変数を選択します。つまり、異なる変数が一定の順序で互いに上書きされます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:351
msgid "Teams and projects that agree on guidelines for defining variables (where to define certain types of variables) usually avoid variable precedence concerns. We suggest that you define each variable in one place: figure out where to define a variable, and keep it simple. For examples, see :ref:`variable_examples`."
msgstr "変数の定義に関するガイドライン (特定のタイプの変数をどこで定義するか) に合意したチームやプロジェクトは、通常、変数の優先順位に関する懸念を回避することができます。各変数は、一箇所で定義することが推奨されます。どこで変数を定義するかを把握し、簡潔さを保ってください。例については、「:ref:`variable_examples`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:353
msgid "Some behavioral parameters that you can set in variables you can also set in Ansible configuration, as command-line options, and using playbook keywords. For example, you can define the user Ansible uses to connect to remote devices as a variable with ``ansible_user``, in a configuration file with ``DEFAULT_REMOTE_USER``, as a command-line option with ``-u``, and with the playbook keyword ``remote_user``. If you define the same parameter in a variable and by another method, the variable overrides the other setting. This approach allows host-specific settings to override more general settings. For examples and more details on the precedence of these various settings, see :ref:`general_precedence_rules`."
msgstr "変数で設定できる動作パラメーターの中には、Ansible の構成、コマンドラインオプション、および Playbook キーワードで設定できるものがあります。たとえば、Ansible がリモートデバイスへの接続に使用するユーザーは、変数では ``ansible_user``、構成ファイルでは ``DEFAULT_REMOTE_USER``、コマンドラインオプションでは ``-u`` 、Playbook キーワードでは ``remote_user`` で定義できます。変数と別の方法で同じパラメーターを定義した場合は、変数が別の設定を上書きします。この方法では、ホスト固有の設定がより一般的な設定を上書きします。これらのさまざまな設定の優先順位の例や詳細は、「:ref:`general_precedence_rules`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:356
msgid "Understanding variable precedence"
msgstr "変数の優先順位について"

#: ../../rst/playbook_guide/playbooks_variables.rst:358
msgid "Ansible does apply variable precedence, and you might have a use for it. Here is the order of precedence from least to greatest (the last listed variables override all other variables):"
msgstr "Ansible では変数の優先順位を適用しており、それを利用できる場合があります。ここでは、優先順位の低いものから高いものまでを紹介します (最後に挙げた変数が他のすべての変数を上書きします)。"

#: ../../rst/playbook_guide/playbooks_variables.rst:360
msgid "command line values (for example, ``-u my_user``, these are not variables)"
msgstr "コマンドラインの値 (例: ``-u my_user`` (これらは変数ではありません))"

#: ../../rst/playbook_guide/playbooks_variables.rst:361
msgid "role defaults (defined in role/defaults/main.yml) [1]_"
msgstr "ロールのデフォルト(role/defaults/main.yml で定義) [1]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:362
msgid "inventory file or script group vars [2]_"
msgstr "インベントリーファイルまたはスクリプトのグループ変数 [2]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:363
msgid "inventory group_vars/all [3]_"
msgstr "インベントリー group_vars/all [3]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:364
msgid "playbook group_vars/all [3]_"
msgstr "playbook group_vars/all [3]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:365
msgid "inventory group_vars/* [3]_"
msgstr "インベントリー group_vars/* [3]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:366
msgid "playbook group_vars/* [3]_"
msgstr "playbook group_vars/* [3]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:367
msgid "inventory file or script host vars [2]_"
msgstr "インベントリーファイルまたはスクリプトホスト変数 [2]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:368
msgid "inventory host_vars/* [3]_"
msgstr "インベントリー host_vars/* [3]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:369
msgid "playbook host_vars/* [3]_"
msgstr "playbook host_vars/* [3]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:370
msgid "host facts / cached set_facts [4]_"
msgstr "ホストファクト / キャッシュ済み set_facts [4]_"

#: ../../rst/playbook_guide/playbooks_variables.rst:371
msgid "play vars"
msgstr "プレイ変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:372
msgid "play vars_prompt"
msgstr "play vars_prompt"

#: ../../rst/playbook_guide/playbooks_variables.rst:373
msgid "play vars_files"
msgstr "play vars_files"

#: ../../rst/playbook_guide/playbooks_variables.rst:374
msgid "role vars (defined in role/vars/main.yml)"
msgstr "role 変数 (role/vars/main.yml で定義)"

#: ../../rst/playbook_guide/playbooks_variables.rst:375
msgid "block vars (only for tasks in block)"
msgstr "ブロック変数 (ブロックのタスクにのみ適用)"

#: ../../rst/playbook_guide/playbooks_variables.rst:376
msgid "task vars (only for the task)"
msgstr "タスク変数 (タスク専用)"

#: ../../rst/playbook_guide/playbooks_variables.rst:377
msgid "include_vars"
msgstr "include_vars"

#: ../../rst/playbook_guide/playbooks_variables.rst:378
msgid "set_facts / registered vars"
msgstr "set_facts / 登録変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:379
msgid "role (and include_role) params"
msgstr "role (および include_role) パラメーター"

#: ../../rst/playbook_guide/playbooks_variables.rst:380
msgid "include params"
msgstr "include パラメーター"

#: ../../rst/playbook_guide/playbooks_variables.rst:381
msgid "extra vars (for example, ``-e \"user=my_user\"``)(always win precedence)"
msgstr "追加の変数 (例: ``-e \"user=my_user\"``)(常に優先されます)"

#: ../../rst/playbook_guide/playbooks_variables.rst:383
msgid "In general, Ansible gives precedence to variables that were defined more recently, more actively, and with more explicit scope. Variables in the defaults folder inside a role are easily overridden. Anything in the vars directory of the role overrides previous versions of that variable in the namespace. Host and/or inventory variables override role defaults, but explicit includes such as the vars directory or an ``include_vars`` task override inventory variables."
msgstr "一般的に、Ansible は、より新しく、より積極的に、より明確なスコープで定義された変数を優先します。ロール内の defaults フォルダーにある変数は簡単に上書きされます。ロールの vars ディレクトリーにあるものは、名前空間内のその変数の以前のバージョンを上書きします。ホストおよび/またはインベントリー変数はロールのデフォルトを上書きしますが、vars ディレクトリーや ``include_vars`` タスクなどの明示的なインクルードはインベントリー変数を上書きします。"

#: ../../rst/playbook_guide/playbooks_variables.rst:385
msgid "Ansible merges different variables set in inventory so that more specific settings override more generic settings. For example, ``ansible_ssh_user`` specified as a group_var is overridden by ``ansible_user`` specified as a host_var. For details about the precedence of variables set in inventory, see :ref:`how_we_merge`."
msgstr "Ansible は、インベントリーに設定した異なる変数をマージして、より特定の設定がより一般的な設定を上書きするようにします。たとえば、group_var として指定した ``ansible_ssh_user`` は、host_var として指定した ``ansible_user`` により上書きされます。インベントリーで設定された変数の優先順位の詳細については、「:ref:`how_we_merge`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:388
msgid "Footnotes"
msgstr "注記"

#: ../../rst/playbook_guide/playbooks_variables.rst:389
msgid "Tasks in each role see their own role's defaults. Tasks defined outside of a role see the last role's defaults."
msgstr "各ロールのタスクには、それぞれのロールのデフォルト値が表示されます。ロールの外で定義されたタスクには、最後のロールのデフォルトが表示されます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:390
msgid "Variables defined in inventory file or provided by dynamic inventory."
msgstr "インベントリーファイルで定義される変数、または動的インベントリーで指定される変数。"

#: ../../rst/playbook_guide/playbooks_variables.rst:391
msgid "Includes vars added by 'vars plugins' as well as host_vars and group_vars which are added by the default vars plugin shipped with Ansible."
msgstr "「vars プラグイン」と、Ansible に同梱されるデフォルトの vars プラグインにより追加される host_vars および group_vars が含まれるインクルード変数。"

#: ../../rst/playbook_guide/playbooks_variables.rst:392
msgid "When created with set_facts's cacheable option, variables have the high precedence in the play, but are the same as a host facts precedence when they come from the cache."
msgstr "set_facts のキャッシュ可能なオプションを使用して作成すると、変数がプレイに優先されますが、キャッシュからのホストのファクトと同様に優先されます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:395
msgid "Within any section, redefining a var overrides the previous instance. If multiple groups have the same variable, the last one loaded wins. If you define a variable twice in a play's ``vars:`` section, the second one wins."
msgstr "どのセクションでも、変数を再定義すると前のインスタンスが上書きされます。複数のグループが同じ変数を持っている場合は、最後に読み込まれたものが優先されます。プレイ中の ``vars:`` のセクションで変数を 2 回定義した場合は、2 回目の変数が優先されます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:398
msgid "The previous describes the default config ``hash_behaviour=replace``, switch to ``merge`` to only partially overwrite."
msgstr "以前は、デフォルトの設定 ``hash_behaviour=replace`` を説明し、``merge`` に切り替えてを部分的に上書きします。"

#: ../../rst/playbook_guide/playbooks_variables.rst:403
msgid "Scoping variables"
msgstr "変数のスコープ設定"

#: ../../rst/playbook_guide/playbooks_variables.rst:405
msgid "You can decide where to set a variable based on the scope you want that value to have. Ansible has three main scopes:"
msgstr "変数をどこに設定するかは、その値が持つべきスコープに基づいて決めることができます。Ansible には大きく分けて 3 つのスコープがあります。"

#: ../../rst/playbook_guide/playbooks_variables.rst:407
msgid "Global: this is set by config, environment variables and the command line"
msgstr "グローバル: これは、設定、環境変数、およびコマンドラインで設定されます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:408
msgid "Play: each play and contained structures, vars entries (vars; vars_files; vars_prompt), role defaults and vars."
msgstr "プレイ: 各プレイおよび含まれる構造、変数エントリー (vars、vars_files、vars_prompt)、ロールのデフォルト、および変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:409
msgid "Host: variables directly associated to a host, like inventory, include_vars, facts or registered task outputs"
msgstr "ホスト: インベントリー、include_vars、ファクト、または登録されたタスクの出力などのホストに直接関連付けられる変数"

#: ../../rst/playbook_guide/playbooks_variables.rst:411
msgid "Inside a template, you automatically have access to all variables that are in scope for a host, plus any registered variables, facts, and magic variables."
msgstr "テンプレート内では、ホストのスコープ内にあるすべての変数と、登録済みの変数、ファクト、およびマジック変数に自動的にアクセスできます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:416
msgid "Tips on where to set variables"
msgstr "変数を設定する場所に関するヒント"

#: ../../rst/playbook_guide/playbooks_variables.rst:418
msgid "You should choose where to define a variable based on the kind of control you might want over values."
msgstr "変数を定義する場所は、値をどのように制御するかによって選択する必要があります。"

#: ../../rst/playbook_guide/playbooks_variables.rst:420
msgid "Set variables in inventory that deal with geography or behavior. Since groups are frequently the entity that maps roles onto hosts, you can often set variables on the group instead of defining them on a role. Remember: child groups override parent groups, and host variables override group variables. See :ref:`define_variables_in_inventory` for details on setting host and group variables."
msgstr "地理や動作を扱うインベントリーに変数を設定します。グループは、ホストにロールをマッピングするエンティティーであることが多いため、ロールに変数を定義する代わりに、グループに変数を設定することができます。子グループが親グループを上書きし、ホスト変数がグループ変数を上書きすることを忘れないでください。ホスト変数とグループ変数の設定の詳細は、「:ref:`define_variables_in_inventory`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:422
msgid "Set common defaults in a ``group_vars/all`` file. See :ref:`splitting_out_vars` for details on how to organize host and group variables in your inventory. Group variables are generally placed alongside your inventory file, but they can also be returned by dynamic inventory (see :ref:`intro_dynamic_inventory`) or defined in AWX or on :ref:`ansible_platform` from the UI or API:"
msgstr "``group_vars/all`` ファイルで共通のデフォルトを設定します。インベントリーでホスト変数とグループ変数を整理する方法の詳細については、「:ref:`splitting_out_vars`」を参照してください。グループ変数は通常、インベントリーファイルと一緒に置かれますが、動的インベントリー (:ref:`intro_dynamic_inventory` を参照) で返されたり、AWX、または UI や API から :ref:`ansible_platform` で定義することもできます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:431
msgid "Set location-specific variables in ``group_vars/my_location`` files. All groups are children of the ``all`` group, so variables set here override those set in ``group_vars/all``:"
msgstr "``group_vars/my_location`` ファイルにロケーション固有の変数を設定します。すべてのグループは ``all`` グループの子であるため、ここに設定される変数は ``group_vars/all`` で設定した変数を上書きします。"

#: ../../rst/playbook_guide/playbooks_variables.rst:439
msgid "If one host used a different NTP server, you could set that in a host_vars file, which would override the group variable:"
msgstr "1 つのホストが別の NTP サーバーを使用している場合は、host_vars ファイルにそのホストを設定できます。これにより、グループ変数が上書きされます。"

#: ../../rst/playbook_guide/playbooks_variables.rst:447
msgid "Set defaults in roles to avoid undefined-variable errors. If you share your roles, other users can rely on the reasonable defaults you added in the ``roles/x/defaults/main.yml`` file, or they can easily override those values in inventory or at the command line. See :ref:`playbooks_reuse_roles` for more info. For example:"
msgstr "未定義な変数エラーを防ぐために、ロールにデフォルト値を設定します。ロールを共有している場合、他のユーザーは、``roles/x/defaults/main.yml`` ファイルで追加した妥当なデフォルト値を信頼するか、インベントリーやコマンドラインで簡単にその値を上書きすることができます。詳細は、「:ref:`playbooks_reuse_roles`」を参照してください。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:456
msgid "Set variables in roles to ensure a value is used in that role, and is not overridden by inventory variables. If you are not sharing your role with others, you can define app-specific behaviors like ports this way, in ``roles/x/vars/main.yml``. If you are sharing roles with others, putting variables here makes them harder to override, although they still can by passing a parameter to the role or setting a variable with ``-e``:"
msgstr "ロールに変数を設定することで、値がそのロールで使用され、インベントリー変数で上書きされないようにします。ロールを他の人と共有していない場合は、ポートなどのアプリ固有の動作を、このように ``roles/x/vars/main.yml`` で定義できます。他の人とロールを共有している場合は、ここに変数を置くことで上書きされにくくなります。ただし、ロールにパラメーターを渡したり、``-e`` で変数を設定したりすれば、上書きされる可能性はあります。"

#: ../../rst/playbook_guide/playbooks_variables.rst:465
msgid "Pass variables as parameters when you call roles for maximum clarity, flexibility, and visibility. This approach overrides any defaults that exist for a role. For example:"
msgstr "明確さ、柔軟性、および可視性を最大化するためにロールを呼び出す場合は、パラメーターとして変数を渡します。この方法では、ロールに存在するデフォルトを上書きします。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:474
msgid "When you read this playbook it is clear that you have chosen to set a variable or override a default. You can also pass multiple values, which allows you to run the same role multiple times. See :ref:`run_role_twice` for more details. For example:"
msgstr "この Playbook を読むと、変数の設定やデフォルトの上書きを選択したことがわかります。また、複数の値を渡すことができるため、同じロールを複数回実行することができます。詳細は「:ref:`run_role_twice`」を参照してください。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:492
msgid "Variables set in one role are available to later roles. You can set variables in a ``roles/common_settings/vars/main.yml`` file and use them in other roles and elsewhere in your playbook:"
msgstr "1 つのロールに設定された変数は、後のロールで使用できます。変数は、``roles/common_settings/vars/main.yml`` ファイルに設定して、他のロールや Playbook の他の場所で使用します。"

#: ../../rst/playbook_guide/playbooks_variables.rst:503
msgid "There are some protections in place to avoid the need to namespace variables. In this example, variables defined in 'common_settings' are available to 'something' and 'something_else' tasks, but tasks in 'something' have foo set at 12, even if 'common_settings' sets foo to 20."
msgstr "変数の名前空間化の必要性を回避するために、いくつかの保護機能があります。この例では、「common_settings」で定義された変数は「something」と「something_else」のタスクで使用できますが、「common_settings」で foo が 20 に設定されていても、「something」のタスクでは foo が 12 に設定されています。"

#: ../../rst/playbook_guide/playbooks_variables.rst:506
msgid "Instead of worrying about variable precedence, we encourage you to think about how easily or how often you want to override a variable when deciding where to set it. If you are not sure what other variables are defined, and you need a particular value, use ``--extra-vars`` (``-e``) to override all other variables."
msgstr "変数の優先順位を気にするのではなく、変数をどこに設定するかを決める際には、どれだけ簡単に、あるいはどれだけ頻繁に変数を上書きしたいかを考えることが推奨されます。他の変数がどのように定義されているかわからず、特定の値が必要な場合は、``--extra-vars`` (``-e``) を使用して、他のすべての変数を上書きします。"

#: ../../rst/playbook_guide/playbooks_variables.rst:509
msgid "Using advanced variable syntax"
msgstr "高度な変数構文の使用"

#: ../../rst/playbook_guide/playbooks_variables.rst:511
msgid "For information about advanced YAML syntax used to declare variables and have more control over the data placed in YAML files used by Ansible, see :ref:`playbooks_advanced_syntax`."
msgstr "変数を宣言するのに使用される高度な YAML 構文、および Ansible により使用される YAML ファイルにあるデータに対する制御の詳細は、「:ref:`playbooks_advanced_syntax`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_variables.rst:520
msgid "Jinja2 filters and their uses"
msgstr "Jinja2 フィルターおよびその使用"

#: ../../rst/playbook_guide/playbooks_variables.rst:527
msgid ":ref:`special_variables`"
msgstr ":ref:`special_variables`"

#: ../../rst/playbook_guide/playbooks_variables.rst:528
msgid "List of special variables"
msgstr "特殊な変数のリスト"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:5
msgid "Discovering variables: facts and magic variables"
msgstr "変数の検出: ファクトおよびマジック変数"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:7
msgid "With Ansible you can retrieve or discover certain variables containing information about your remote systems or about Ansible itself. Variables related to remote systems are called facts. With facts, you can use the behavior or state of one system as configuration on other systems. For example, you can use the IP address of one system as a configuration value on another system. Variables related to Ansible are called magic variables."
msgstr "Ansible では、リモートシステムや Ansible 自体に関する情報を含む特定の変数を取得または検出を行うことができます。リモートシステムに関連する変数をファクトと呼びます。ファクトを使用すると、あるシステムの動作や状態を他のシステムの設定値として使用することができます。たとえば、あるシステムの IP アドレスを、他のシステムの設定値として使用することができます。Ansible に関連する変数をマジック変数と呼びます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:13
msgid "Ansible facts"
msgstr "Ansible ファクト"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:15
msgid "Ansible facts are data related to your remote systems, including operating systems, IP addresses, attached filesystems, and more. You can access this data in the ``ansible_facts`` variable. By default, you can also access some Ansible facts as top-level variables with the ``ansible_`` prefix. You can disable this behavior using the :ref:`INJECT_FACTS_AS_VARS` setting. To see all available facts, add this task to a play:"
msgstr "Ansible のファクトは、オペレーティングシステム、IP アドレス、添付のファイルシステムなど、リモートシステムに関連するデータです。このデータには、``ansible_facts`` という変数でアクセスできます。デフォルトでは、一部の Ansible ファクトは、``ansible_`` というプレフィックスを持つトップレベルの変数としてアクセスすることもできます。この動作は、:ref:`INJECT_FACTS_AS_VARS` の設定で無効にすることができます。利用可能なすべてのファクトを表示するには、このタスクをプレイに追加します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:23
msgid "To see the 'raw' information as gathered, run this command at the command line:"
msgstr "収集された「生」の情報を見るには、コマンドラインで次のコマンドを実行します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:29
msgid "Facts include a large amount of variable data, which may look like this:"
msgstr "ファクトには大量の変数データが含まれており、それは次のようなものです。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:490
msgid "You can reference the model of the first disk in the facts shown above in a template or playbook as:"
msgstr "上記のファクトの最初のディスクのモデルをテンプレートまたは Playbook で参照できます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:496
msgid "To reference the system hostname:"
msgstr "システムのホスト名を参照するには、以下を実行します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:502
msgid "You can use facts in conditionals (see :ref:`playbooks_conditionals`) and also in templates. You can also use facts to create dynamic groups of hosts that match particular criteria, see the :ref:`group_by module <group_by_module>` documentation for details."
msgstr "ファクトは、条件式 (:ref:`playbooks_conditionals` を参照) やテンプレートでも使用できます。また、ファクトを使用して、特定の条件に一致するホストの動的なグループを作成することもできます。詳細は、:ref:`group_by モジュール <group_by_module>` のドキュメントを参照してください。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:504
#, python-format
msgid "Because ``ansible_date_time`` is created and cached when Ansible gathers facts before each playbook run, it can get stale with long-running playbooks. If your playbook takes a long time to run, use the ``pipe`` filter (for example, ``lookup('pipe', 'date +%Y-%m-%d.%H:%M:%S')``) or :ref:`now() <templating_now>` with a Jinja 2 template instead of ``ansible_date_time``."
msgstr "``ansible_date_time`` は、Ansible が各 Playbook の実行前にファクトを収集したときにキャッシュされるため、長時間実行される Playbook で古くなる可能性があります。Playbook の実行に長い時間がかかる場合は、``ansible_date_time`` ではなく Jinja 2 テンプレートで ``pipe`` フィルター（例: ``lookup('pipe', 'date +%Y-%m-%d.%H:%M:%S')``）または :ref:`now() <templating_now>` を使用します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:509
msgid "Package requirements for fact gathering"
msgstr "ファクト収集のパッケージ要件"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:511
msgid "On some distros, you may see missing fact values or facts set to default values because the packages that support gathering those facts are not installed by default. You can install the necessary packages on your remote hosts using the OS package manager. Known dependencies include:"
msgstr "一部のディストリビューションでは、ファクトの収集をサポートするパッケージがデフォルトでインストールされていないため、ファクトの値が見つからなかったり、ファクトがデフォルト値に設定されたりすることがあります。OS のパッケージマネージャーを使用して、リモートホストに必要なパッケージをインストールすることができます。既知の依存関係には以下のものがあります。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:513
msgid "Linux Network fact gathering -  Depends on  the ``ip`` binary, commonly included in the ``iproute2`` package."
msgstr "Linux ネットワークファクト収集 - 一般的に ``iproute2`` パッケージに含まれる ``ip`` バイナリーによって異なります。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:518
msgid "Caching facts"
msgstr "ファクトのキャッシュ"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:520
msgid "Like registered variables, facts are stored in memory by default. However, unlike registered variables, facts can be gathered independently and cached for repeated use. With cached facts, you can refer to facts from one system when configuring a second system, even if Ansible executes the current play on the second system first. For example:"
msgstr "登録された変数と同様に、ファクトはデフォルトでメモリーに保存されます。ただし、登録された変数とは異なり、ファクトは独立して収集し、繰り返し使用するためにキャッシュすることができます。キャッシュされたファクトを使用すると、Ansible が 2 つ目のシステムで現在のプレイを最初に実行した場合でも、1 つのシステムのファクトを参照して 2 つ目のシステムを設定することができます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:526
msgid "Caching is controlled by the cache plugins. By default, Ansible uses the memory cache plugin, which stores facts in memory for the duration of the current playbook run. To retain Ansible facts for repeated use, select a different cache plugin. See :ref:`cache_plugins` for details."
msgstr "キャッシュ処理は、キャッシュプラグインによって制御されます。デフォルトでは、Ansible はメモリーキャッシュプラグインを使用し、現在の Playbook の実行期間中、メモリーにファクトを保存します。Ansible のファクトを繰り返し使用するために保持するには、別のキャッシュプラグインを選択します。詳細は「:ref:`cache_plugins`」を参照してください。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:528
msgid "Fact caching can improve performance. If you manage thousands of hosts, you can configure fact caching to run nightly, then manage configuration on a smaller set of servers periodically throughout the day. With cached facts, you have access to variables and information about all hosts even when you are only managing a small number of servers."
msgstr "ファクトキャッシュ処理はパフォーマンスを向上させます。何千台ものホストを管理している場合は、ファクトキャッシュ処理を毎晩実行するように設定し、小規模なサーバ群の設定を 1 日中定期的に管理することができます。キャッシュされたファクトがあれば、少数のサーバーしか管理していなくても、すべてのホストに関する変数および情報にアクセスすることができます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:533
msgid "Disabling facts"
msgstr "ファクトの無効化"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:535
msgid "By default, Ansible gathers facts at the beginning of each play. If you do not need to gather facts (for example, if you know everything about your systems centrally), you can turn off fact gathering at the play level to improve scalability. Disabling facts may particularly improve performance in push mode with very large numbers of systems, or if you are using Ansible on experimental platforms. To disable fact gathering:"
msgstr "デフォルトでは、Ansible は各プレイの開始時にファクトを収集します。ファクトを収集する必要がない場合 (たとえば、システムに関する情報をすべて一元的に把握している場合) は、プレイレベルでのファクト収集をオフにすることで、スケーラビリティーを向上させることができます。ファクトを無効にすると、非常に多数のシステムを使用するプッシュモードや、実験的なプラットフォームで Ansible を使用している場合に、特にパフォーマンスが向上することがあります。ファクトの収集を無効にするには、以下を行います。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:543
msgid "Adding custom facts"
msgstr "カスタムファクトの追加"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:545
msgid "The setup module in Ansible automatically discovers a standard set of facts about each host. If you want to add custom values to your facts, you can write a custom facts module, set temporary facts with a ``ansible.builtin.set_fact`` task, or provide permanent custom facts using the facts.d directory."
msgstr "Ansible のセットアップモジュールは、各ホストに関する標準的なファクトのセットを自動的に検出します。ファクトにカスタム値を追加したい場合は、カスタムファクトモジュールを記述したり、``ansible.builtin.set_fact`` タスクで一時的なファクトを設定したり、facts.d ディレクトリーを使用して恒久的なカスタムファクトを提供したりすることができます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:550
msgid "facts.d or local facts"
msgstr "facts.d またはローカルファクト"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:554
msgid "You can add static custom facts by adding static files to facts.d, or add dynamic facts by adding executable scripts to facts.d. For example, you can add a list of all users on a host to your facts by creating and running a script in facts.d."
msgstr "静的なカスタムファクトは、静的ファイルを facts.d に追加することで追加でき、動的なファクトは実行可能なスクリプトを facts.d に追加することで追加できます。たとえば、facts.d でスクリプトを作成して実行することにより、ホスト上のすべてのユーザーのリストをファクトに追加できます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:556
msgid "To use facts.d, create an ``/etc/ansible/facts.d`` directory on the remote host or hosts. If you prefer a different directory, create it and specify it using the ``fact_path`` play keyword. Add files to the directory to supply your custom facts. All file names must end with ``.fact``. The files can be JSON, INI, or executable files returning JSON."
msgstr "facts.d を使用するには、リモートホストまたはホスト上に ``/etc/ansible/facts.d`` ディレクトリーを作成します。別のディレクトリーを使用する場合は、そのディレクトリーを作成し、プレイキーワード ``fact_path`` を使用して指定します。このディレクトリーにファイルを追加して、カスタムファクトを提供します。すべてのファイル名は、``.fact`` で終わる必要があります。ファイルには、JSON、INI、または JSON を返す実行可能ファイルを使用できます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:558
msgid "To add static facts, simply add a file with the ``.fact`` extension. For example, create ``/etc/ansible/facts.d/preferences.fact`` with this content:"
msgstr "静的ファクトを追加するには、``.fact`` 拡張子を持つファイルを追加するだけです。たとえば、以下の内容で ``/etc/ansible/facts.d/preferences.fact`` を作成します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:566
msgid "Make sure the file is not executable as this will break the ``ansible.builtin.setup`` module."
msgstr "``ansible.builtin.setup`` モジュールが壊れるため、このファイルが実行ファイルではないことを確認してください。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:568
msgid "The next time fact gathering runs, your facts will include a hash variable fact named ``general`` with ``asdf`` and ``bar`` as members. To validate this, run the following:"
msgstr "次回、ファクト収集が実行されると、ファクトには、``asdf`` と ``bar`` をメンバーとする ``general`` という名前のハッシュ変数ファクトが含まれるようになります。これを検証するには、次のように実行します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:574
msgid "And you will see your custom fact added:"
msgstr "これにより、カスタムファクトが追加されているのが確認できます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:589
msgid "The ansible_local namespace separates custom facts created by facts.d from system facts or variables defined elsewhere in the playbook, so variables will not override each other. You can access this custom fact in a template or playbook as:"
msgstr "ansible_local 名前空間は、facts.d で作成されたカスタムファクトと、システムファクトや Playbook 内の他の場所で定義された変数を分離し、変数が互いに上書きされないようにします。このカスタムファクトには、テンプレートや Playbook で次のようにアクセスできます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:595
msgid "The key part in the key=value pairs will be converted into lowercase inside the ansible_local variable. Using the example above, if the ini file contained ``XYZ=3`` in the ``[general]`` section, then you should expect to access it as: ``{{ ansible_local['preferences']['general']['xyz'] }}`` and not ``{{ ansible_local['preferences']['general']['XYZ'] }}``. This is because Ansible uses Python's `ConfigParser`_ which passes all option names through the `optionxform`_ method and this method's default implementation converts option names to lower case."
msgstr "鍵と値のペアの鍵の部分は、ansible_local 変数内で小文字に変換されます。上記の例では、ini ファイルの ``[general]`` セクションに ``XYZ=3`` が含まれていた場合は、``{{ ansible_local['preferences']['general']['XYZ'] }}`` ではなく、``{{ ansible_local['preferences']['general']['xyz'] }}`` としてアクセスすることになります。これは、Ansible が Python の `ConfigParser`_ を使用して、すべてのオプション名を `optionxform`_ メソッドに渡しており、このメソッドのデフォルトの実装では、オプション名が小文字に変換されるためです。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:600
msgid "You can also use facts.d to execute a script on the remote host, generating dynamic custom facts to the ansible_local namespace. For example, you can generate a list of all users that exist on a remote host as a fact about that host. To generate dynamic custom facts using facts.d:"
msgstr "facts.d を使用して、リモートホスト上でスクリプトを実行し、ansible_local 名前空間に動的なカスタムファクトを生成することもできます。たとえば、リモートホストに存在するすべてのユーザーのリストを、そのホストに関するファクトとして生成することができます。facts.d を使用して動的なカスタムファクトを生成するには、以下の手順に従います。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:602
msgid "Write and test a script to generate the JSON data you want."
msgstr "スクリプトを作成してテストして、必要な JSON データを生成します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:603
msgid "Save the script in your facts.d directory."
msgstr "スクリプトを facts.d ディレクトリーに保存します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:604
msgid "Make sure your script has the ``.fact`` file extension."
msgstr "スクリプトに ``.fact`` ファイル拡張子があることを確認します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:605
msgid "Make sure your script is executable by the Ansible connection user."
msgstr "スクリプトが Ansible 接続ユーザーによって実行可能であることを確認します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:606
msgid "Gather facts to execute the script and add the JSON output to ansible_local."
msgstr "スクリプトを実行するファクトを収集し、JSON 出力を ansible_local に追加します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:608
msgid "By default, fact gathering runs once at the beginning of each play. If you create a custom fact using facts.d in a playbook, it will be available in the next play that gathers facts. If you want to use it in the same play where you created it, you must explicitly re-run the setup module. For example:"
msgstr "デフォルトでは、ファクトの収集は各プレイの開始時に一度だけ実行します。Playbook で facts.d を使用してカスタムファクトを作成すると、ファクトを収集する次のプレイで使用できるようになります。作成したのと同じプレイで使用したい場合は、セットアップモジュールを明示的に再実行する必要があります。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:630
msgid "If you use this pattern frequently, a custom facts module would be more efficient than facts.d."
msgstr "このパターンを頻繁に使用すると、カスタムファクトモジュールは facts.d よりも効率が上がります。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:635
msgid "Information about Ansible: magic variables"
msgstr "Ansible に関する情報: マジック変数"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:637
msgid "You can access information about Ansible operations, including the python version being used, the hosts and groups in inventory, and the directories for playbooks and roles, using \"magic\" variables. Like connection variables, magic variables are :ref:`special_variables`. Magic variable names are reserved - do not set variables with these names. The variable ``environment`` is also reserved."
msgstr "使用している Python のバージョン、インベントリー内のホストやグループ、Playbook やロールのディレクトリーなど、Ansible の操作に関する情報は、「マジック」変数を使用してアクセスすることができます。接続変数と同様に、マジック変数は :ref:`special_variables` です。マジック変数の名前は予約済みです。これらの名前で変数を設定しないでください。変数 ``environment`` も予約済みです。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:639
msgid "The most commonly used magic variables are ``hostvars``, ``groups``, ``group_names``, and ``inventory_hostname``. With ``hostvars``, you can access variables defined for any host in the play, at any point in a playbook. You can access Ansible facts using the ``hostvars`` variable too, but only after you have gathered (or cached) facts.  Note that variables defined at play objects are not defined for specific hosts and therefore are not mapped to hostvars."
msgstr "最も一般的に使用されるマジック変数は、``hostvars``、``groups``、``group_names``、および ``inventory_hostname`` です。``hostvars`` を使用すると、Playbook 内の任意の時点で、プレイ内の任意のホストに対して定義された変数にアクセスできます。``hostvars`` 変数を使用して Ansible のファクトにアクセスすることもできますが、ファクトを収集 (またはキャッシュ) した後でなければなりません。プレイオブジェクトで定義された変数は特定のホストに対して定義されていないため、hostvars にマップされないことに注意してください。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:641
msgid "If you want to configure your database server using the value of a 'fact' from another node, or the value of an inventory variable assigned to another node, you can use ``hostvars`` in a template or on an action line:"
msgstr "他のノードの「ファクト」の値や、他のノードに割り当てられたインベントリー変数の値を使用してデータベースサーバーを設定する場合は、テンプレートやアクション行で ``hostvars`` を使用することができます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:647
msgid "With ``groups``, a list of all the groups (and hosts) in the inventory, you can enumerate all hosts within a group. For example:"
msgstr "``groups`` では、インベントリー内のすべてのグループ (およびホスト) のリストで、グループ内のすべてのホストを列挙できます。以下に例を示します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:655
msgid "You can use ``groups`` and ``hostvars`` together to find all the IP addresses in a group."
msgstr "``groups`` と ``hostvars`` を一緒に使用して、グループ内のすべての IP アドレスを探すことができます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:663
msgid "You can use this approach to point a frontend proxy server to all the hosts in your app servers group, to set up the correct firewall rules between servers, and so on. You must either cache facts or gather facts for those hosts before the task that fills out the template."
msgstr "この方法を使用して、フロントエンドプロキシーサーバーがアプリサーバーグループ内のすべてのホストを指すようにしたり、サーバー間に正しいファイアウォールルールを設定したりできます。テンプレートに入力するタスクの前に、ファクトをキャッシュするか、それらのホストのファクトを収集する必要があります。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:665
msgid "With ``group_names``, a list (array) of all the groups the current host is in, you can create templated files that vary based on the group membership (or role) of the host:"
msgstr "``group_names`` では、現在のホストが置かれているすべてのグループのリスト (配列) は、ホストのグループメンバーシップ (またはロール) に基づいて異なるテンプレートファイルを作成できます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:673
msgid "You can use the magic variable ``inventory_hostname``, the name of the host as configured in your inventory, as an alternative to ``ansible_hostname`` when fact-gathering is disabled. If you have a long FQDN, you can use ``inventory_hostname_short``, which contains the part up to the first period, without the rest of the domain."
msgstr "ファクト収集が無効になっているときには、``ansible_hostname`` の代わりに、インベントリーで設定されたホストの名前であるマジック変数 ``inventory_hostname`` を使用できます。長い FQDN がある場合には、最初のピリオドまでの部分を含み、ドメインの残りの部分を含まない ``inventory_hostname_short`` を使用することができます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:675
msgid "Other useful magic variables refer to the current play or playbook. These vars may be useful for filling out templates with multiple hostnames or for injecting the list into the rules for a load balancer."
msgstr "その他の有用なマジック変数は、現在のプレイや Playbook を参照します。これらの変数は、複数のホスト名でテンプレートを埋めるときや、ロードバランサーのルールにリストを注入するときに便利です。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:677
msgid "``ansible_play_hosts`` is the list of all hosts still active in the current play."
msgstr "``ansible_play_hosts`` は、現在のプレイでアクティブなままになっているすべてのホストの完全なリストです。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:679
msgid "``ansible_play_batch`` is a list of hostnames that are in scope for the current 'batch' of the play."
msgstr "``ansible_play_batch`` は、現在のプレイの「バッチ」の範囲内にあるホスト名のリストです。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:681
msgid "The batch size is defined by ``serial``, when not set it is equivalent to the whole play (making it the same as ``ansible_play_hosts``)."
msgstr "バッチサイズは ``serial`` で定義されます。設定されていない場合は、プレイ全体に相当するようになります (``ansible_play_hosts`` と同じになります)。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:683
msgid "``ansible_playbook_python`` is the path to the python executable used to invoke the Ansible command line tool."
msgstr "``ansible_playbook_python`` は、Ansible コマンドラインツールを起動するのに使用される Python 実行ファイルへのパスです。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:685
msgid "``inventory_dir`` is the pathname of the directory holding Ansible's inventory host file."
msgstr "``inventory_dir`` は、Ansible のインベントリーホストファイルを保持するディレクトリーのパス名です。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:687
msgid "``inventory_file`` is the pathname and the filename pointing to the Ansible's inventory host file."
msgstr "``inventory_file`` は、Ansible のインベントリーホストファイルを参照するパス名とファイル名です。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:689
msgid "``playbook_dir`` contains the playbook base directory."
msgstr "``playbook_dir`` には Playbook のベースディレクトリーが含まれます。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:691
msgid "``role_path`` contains the current role's pathname and only works inside a role."
msgstr "``role_path`` には現在のロールのパス名が含まれ、ロール内でのみ動作します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:693
msgid "``ansible_check_mode`` is a boolean, set to ``True`` if you run Ansible with ``--check``."
msgstr "``ansible_check_mode`` が ``--check`` で Ansible を実行する場合は ``True`` に設定します。"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:698
msgid "Ansible version"
msgstr "Ansible version"

#: ../../rst/playbook_guide/playbooks_vars_facts.rst:702
msgid "To adapt playbook behavior to different versions of Ansible, you can use the variable ``ansible_version``, which has the following structure:"
msgstr "Playbook の動作をさまざまなバージョンの Ansible に適用するには、``ansible_version`` 変数を使用できます。この変数には、以下の構造があります。"

#: ../../rst/playbook_guide/playbooks_vault.rst:4
msgid "Using vault in playbooks"
msgstr "Playbook での Vault の使用"

#: ../../rst/playbook_guide/playbooks_vault.rst:6
msgid "The documentation regarding Ansible Vault has moved. The new location is here: :ref:`vault`. Please update any links you may have made directly to this page."
msgstr "Ansible Vault に関するドキュメントが移動しました。新しい場所は「:ref:`vault`」です。このページに直接作成した可能性のあるリンクを更新してください。"