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

en: Developing network plugins
ja: ネットワークプラグインの開発

en: You can extend the existing network modules with custom plugins in your collection.
ja: コレクションのカスタムプラグインを使用して、既存のネットワークモジュールを拡張できます。

en: Network connection plugins
ja: ネットワーク接続プラグイン

en: Each network connection plugin has a set of its own plugins which provide a specification of the connection for a particular set of devices. The specific plugin used is selected at runtime based on the value of the ``ansible_network_os`` variable assigned to the host. This variable should be set to the same value as the name of the plugin to be loaded. Thus, ``ansible_network_os=nxos`` will try to load a plugin in a file named ``nxos.py``, so it is important to name the plugin in a way that will be sensible to users.
ja: 各ネットワーク接続プラグインには、独自のプラグインセットがあります。これは、特定のデバイスセットの接続の仕様を提供します。使用される特定のプラグインは、ホストに割り当てられた ``ansible_network_os`` 変数の値に基づいてランタイム時に選択されます。この変数は、読み込むプラグインの名前と同じ値に設定する必要があります。そのため、``ansible_network_os=nxos`` は、``nxos.py`` という名前のファイルにプラグインを読み込もうとするため、ユーザーが適切な方法でプラグインに名前を付けることが重要です。

en: Public methods of these plugins may be called from a module or module_utils with the connection proxy object just as other connection methods can. The following is a very simple example of using such a call in a module_utils file so it may be shared with other modules.
ja: これらのプラグインのパブリックメソッドは、他の接続方法と同様に、接続のプロキシーオブジェクトを使用して、モジュールまたは module_utils から接続で呼び出すことができます。以下は、その他のモジュールと共有できるように、module_utils ファイルでこのような呼び出しを使用する非常に簡単な例です。

en: Developing httpapi plugins
ja: httpapi プラグインの開発

en: :ref:`httpapi plugins <httpapi_plugins>` serve as adapters for various HTTP(S) APIs for use with the ``httpapi`` connection plugin. They should implement a minimal set of convenience methods tailored to the API you are attempting to use.
ja: :ref:`httpapi プラグイン <httpapi_plugins>` は、``httpapi`` 接続プラグインで使用するさまざまな HTTP(S) API のアダプターとして機能します。このプラグインは、使用しようとしている API に適した最小限の便利なメソッドを実装する必要があります。

en: Specifically, there are a few methods that the ``httpapi`` connection plugin expects to exist.
ja: 具体的には、``httpapi`` 接続プラグインが存在することが必要なメソッドがいくつかあります。

en: Making requests
ja: 要求の作成

en: The ``httpapi`` connection plugin has a ``send()`` method, but an httpapi plugin needs a ``send_request(self, data, **message_kwargs)`` method as a higher-level wrapper to ``send()``. This method should prepare requests by adding fixed values like common headers or URL root paths. This method may do more complex work such as turning data into formatted payloads, or determining which path or method to request. It may then also unpack responses to be more easily consumed by the caller.
ja: ``httpapi`` 接続プラグインには ``send()`` メソッドがありますが、httpapi プラグインには、``send()`` への高レベルラッパーとして ``send_request(self, data, **message_kwargs)`` メソッドが必要です。このメソッドは、共通ヘッダーや URL ルートパスなどの固定値を追加することで要求を準備する必要があります。このメソッドは、フォーマットされたペイロードへのデータの切り替えや、リクエスト用のパスやメソッドの特定など、より複雑な作業を行うことがあります。その後、呼び出し元によって簡単に消費される応答が展開される可能性があります

en: Authenticating
ja: 認証

en: By default, all requests will authenticate with HTTP Basic authentication. If a request can return some kind of token to stand in place of HTTP Basic, the ``update_auth(self, response, response_text)`` method should be implemented to inspect responses for such tokens. If the token is meant to be included with the headers of each request, it is sufficient to return a dictionary which will be merged with the computed headers for each request. The default implementation of this method does exactly this for cookies. If the token is used in another way, say in a query string, you should instead save that token to an instance variable, where the ``send_request()`` method (above) can add it to each request
ja: デフォルトでは、すべての要求は HTTP Basic 認証で認証されます。要求が HTTP Basic の代わりにある種のトークンを返す場合は、``update_auth(self, response, response_text)`` メソッドを実装して、このようなトークンの応答を検査する必要があります。トークンが各要求のヘッダーに含まれるように設計されている場合は、各要求に対して計算されたヘッダーとマージするディクショナリーを返すだけで十分です。このメソッドのデフォルト実装は Cookie に対して行われる方法で行われます。トークンが別の方法 (クエリー文字列など) で使用される場合は、そのトークンをインスタンス変数に保存して、``send_request()`` メソッド (上記) により各要求に追加できるようにします。

en: If instead an explicit login endpoint needs to be requested to receive an authentication token, the ``login(self, username, password)`` method can be implemented to call that endpoint. If implemented, this method will be called once before requesting any other resources of the server. By default, it will also be attempted once when a HTTP 401 is returned from a request.
ja: 代わりに明示的なログインエンドポイントを要求して認証トークンを受け取る必要がある場合は、``login(self, username, password)`` メソッドを実装して、そのエンドポイントを呼び出すことができます。このメソッドを実装すると、サーバーの他のリソースを要求する前にこのメソッドが一度呼び出されます。デフォルトでは、要求から HTTP 401 が返されるとこれが一度試行されます。

en: Similarly, ``logout(self)`` can be implemented to call an endpoint to invalidate and/or release the current token, if such an endpoint exists. This will be automatically called when the connection is closed (and, by extension, when reset).
ja: 同様に、``logout(self)`` を実装してエンドポイントを呼び出し、そのエンドポイントが存在する場合は現在のトークンを無効化または解放できます。これは、接続を閉じると自動的に呼び出されます (また、リセット時には拡張により呼び出されます)。

en: Error handling
ja: エラー処理

en: The ``handle_httperror(self, exception)`` method can deal with status codes returned by the server. The return value indicates how the plugin will continue with the request:
ja: ``handle_httperror(self, exception)`` メソッドは、サーバーによって返されるステータスコードを処理できます。戻り値は、プラグインがどのようにリクエストを続けるかを示します。

en: A value of ``true`` means that the request can be retried. This my be used to indicate a transient error, or one that has been resolved. For example, the default implementation will try to call ``login()`` when presented with a 401, and return ``true`` if successful.
ja: ``true`` の値は、要求を再試行できることを意味します。これは、一時的なエラーや解決されたエラーを示すために使用できます。たとえば、デフォルトの実装では、401 が示されると ``login()`` の呼び出しが試行され、成功した場合は ``true`` が返されます。

en: A value of ``false`` means that the plugin is unable to recover from this response. The status code will be raised as an exception to the calling module.
ja: ``false`` の値は、プラグインがこの応答から復元できないことを意味します。ステータスコードは、呼び出したモジュールに例外としてあげられます。

en: Any other value will be taken as a nonfatal response from the request. This may be useful if the server returns error messages in the body of the response. Returning the original exception is usually sufficient in this case, as HTTPError objects have the same interface as a successful response.
ja: その他の値は、要求からの致命的でない応答として取られます。これは、サーバーが応答のボディーでエラーメッセージを返す場合に便利です。HTTPError オブジェクトは正常な応答と同じインターフェースを持つため、通常は元の例外を返します。

en: For example httpapi plugins, see the `source code for the httpapi plugins <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/httpapi>`_ included with Ansible Core.
ja: httpapi プラグインの例は、Ansible Core に含まれる `httpapi プラグインのソースコード <https://github.com/ansible/ansible/tree/devel/lib/ansible/plugins/httpapi>`_ を参照してください。

en: Developing NETCONF plugins
ja: NETCONF プラグインの開発

en: The :ref:`netconf <netconf_connection>` connection plugin provides a connection to remote devices over the ``SSH NETCONF`` subsystem. Network devices typically use this connection plugin to send and receive ``RPC`` calls over ``NETCONF``.
ja: :ref:`netconf <netconf_connection>` 接続プラグインは、``SSH NETCONF`` サブシステム経由でリモートデバイスへの接続を提供します。ネットワークデバイスは通常、この接続プラグインを使用して、``NETCONF`` で ``RPC`` 呼び出しを送受信します。

en: The ``netconf`` connection plugin uses the ``ncclient`` Python library under the hood to initiate a NETCONF session with a NETCONF-enabled remote network device. ``ncclient`` also executes NETCONF RPC requests and receives responses. You must install the ``ncclient`` on the local Ansible controller.
ja: ``netconf`` 接続プラグインは、Python ライブラリー ``ncclient`` を使用して、NETCONF が有効なリモートネットワークデバイスで NETCONF セッションを開始します。また、``ncclient`` は NETCONF RPC 要求を実行し、応答を受け取ります。ローカルの Ansible コントローラーに ``ncclient`` をインストールする必要があります。

en: To use the ``netconf`` connection plugin for network devices that support standard NETCONF (:RFC:`6241`) operations such as ``get``, ``get-config``, ``edit-config``, set ``ansible_network_os=default``. You can use :ref:`netconf_get <netconf_get_module>`, :ref:`netconf_config <netconf_config_module>` and :ref:`netconf_rpc <netconf_rpc_module>` modules to talk to a NETCONF enabled remote host.
ja: ``get``、``get-config``、``edit-config`` などの標準 NETCONF (:RFC:`6241`) 操作に対応するネットワークデバイスの ``netconf`` 接続プラグインを使用するには、``ansible_network_os=default`` を設定します。:ref:`netconf_get <netconf_get_module>` モジュール、:ref:`netconf_config <netconf_config_module>` モジュール、および :ref:`netconf_rpc <netconf_rpc_module>` モジュールを使用して、NETCONF が有効なリモートホストと通信できます。

en: As a contributor and user, you should be able to use all the methods under the ``NetconfBase`` class if your device supports standard NETCONF. You can contribute a new plugin if the device you are working with has a vendor specific NETCONF RPC. To support a vendor specific NETCONF RPC, add the implementation in the network OS specific NETCONF plugin.
ja: デバイスが標準の NETCONF に対応している場合は、貢献者およびユーザーとして、``NetconfBase`` クラスのすべてのメソッドを使用できるようにする必要があります。作業しているデバイスにベンダー固有の NETCONF RPC がある場合は、新しいプラグインを提供できます。ベンダー固有の NETCONF RPC に対応するには、ネットワーク OS 固有の NETCONF プラグインに実装を追加します。

en: For Junos for example:
ja: たとえば、Junios の場合は以下のようになります。

en: See the vendor-specific Junos RPC methods implemented in ``plugins/netconf/junos.py``.
ja: ``plugins/netconf/junos.py`` に実装されるベンダー固有の Junos RPC メソッドを参照してください。

en: Set the value of ``ansible_network_os`` to the name of the netconf plugin file, that is ``junos`` in this case.
ja: ``ansible_network_os`` の値を netconf プラグインファイルの名前 (ここでは ``junos``) に設定します。

en: Developing network_cli plugins
ja: network_cli プラグインの開発

en: The :ref:`network_cli <network_cli_connection>` connection type uses ``paramiko_ssh`` under the hood which creates a pseudo terminal to send commands and receive responses. ``network_cli`` loads two platform specific plugins based on the value of ``ansible_network_os``:
ja: 接続タイプ :ref:`network_cli <network_cli_connection>` は、コマンドを送信して応答を受け取るための疑似端末を作成するフード (hood) の下で、``paramiko_ssh`` を使用します。``network_cli`` は、``ansible_network_os`` の値に基づいて 2 つのプラットフォーム固有のプラグインを読み込みます。

en: Terminal plugin (for example ``plugins/terminal/ios.py``) - Controls the parameters related to terminal, such as setting terminal length and width, page disabling and privilege escalation. Also defines regex to identify the command prompt and error prompts.
ja: 端末のプラグイン (例: ``plugins/terminal/ios.py``) - 端末の長さや幅の設定、ページの無効化、権限の昇格など、端末に関連するパラメーターを制御します。また、正規表現を定義して、コマンドプロンプトおよびエラープロンプトを特定します。

en: :ref:`cliconf_plugins` (for example, :ref:`ios cliconf <ios_cliconf>`) - Provides an abstraction layer for low level send and receive operations. For example, the ``edit_config()`` method ensures that the prompt is in ``config`` mode before executing configuration commands.
ja: :ref:`cliconf_plugins` (例: :ref:`ios cliconf <ios_cliconf>`) - 低レベルの送受信操作の抽象化レイヤーを提供します。たとえば、``edit_config()`` メソッドは、設定コマンドを実行する前にプロンプトが ``config`` モードになるようにします。

en: To contribute a new network operating system to work with the ``network_cli`` connection, implement the ``cliconf`` and ``terminal`` plugins for that network OS.
ja: 新しいネットワークオペレーティングシステムが ``network_cli`` 接続と連携するようにするには、そのネットワーク OS の ``cliconf`` プラグインおよび ``terminal`` プラグインを実装します。

en: The plugins can reside in:
ja: このプラグインは以下の場所に置くことができます。

en: Adjacent to playbook in folders
ja: ディレクトリー内で Playbook に隣接

en: Roles
ja: ロール

en: Collections
ja: コレクション

en: The user can also set the :ref:`DEFAULT_CLICONF_PLUGIN_PATH`  to configure the ``cliconf`` plugin path.
ja: ``cliconf`` プラグインパスを設定するために、ユーザーは :ref:`DEFAULT_CLICONF_PLUGIN_PATH` を設定することもできます。

en: After adding the ``cliconf`` and ``terminal`` plugins in the expected locations, users can:
ja: 予想される場所に ``cliconf`` プラグインおよび ``terminal`` プラグインを追加したら、ユーザーは以下を行うことができます。

en: Use the :ref:`cli_command <cli_command_module>` to run an arbitrary command on the network device.
ja: :ref:`cli_command <cli_command_module>` を使用して、ネットワークデバイス上で任意のコマンドを実行します。

en: Use the :ref:`cli_config <cli_config_module>` to  implement configuration changes on the remote hosts without platform-specific modules.
ja: :ref:`cli_config <cli_config_module>` を使用して、プラットフォーム固有のモジュールを使用しないリモートホストに設定変更を実装する。

en: Developing cli_parser plugins in a collection
ja: コレクションでの cli_parser プラグインの開発

en: You can use ``cli_parse`` as an entry point for a cli_parser plugin in your own collection.
ja: ``cli_parse`` は、独自のコレクションで cli_parser プラグインのエントリーポイントとして使用できます。

en: The following sample shows the start of a custom cli_parser plugin:
ja: 以下の例は、カスタム cli_parser プラグインの開始を示しています。

en: The following task uses this custom cli_parser plugin:
ja: 以下のタスクでは、このカスタム cli_parser プラグインを使用します。

en: To develop a custom plugin: - Each cli_parser plugin requires a ``CliParser`` class. - Each cli_parser plugin requires a ``parse`` function. - Always return a dictionary with ``errors`` or ``parsed``. - Place the custom cli_parser in plugins/cli_parsers directory of the collection. - See the `current cli_parsers <https://github.com/ansible-collections/ansible.netcommon/tree/main/plugins/cli_parsers>`_ for examples to follow.
ja: カスタムプラグインを開発するには: - 各 cli_parser プラグインには ``CliParser`` クラスが必要です。- 各 cli_parser プラグインには ``parse`` 関数が必要です。- 常に ``errors`` または ``parsed`` でディクショナリーを返します。コレクションの plugins/cli_parsers ディレクトリーにカスタムの cli_parser を置きます。例は `現在の cli_parsers <https://github.com/ansible-collections/ansible.netcommon/tree/main/plugins/cli_parsers>` を参照してください。

en: Developing network resource modules
ja: ネットワークリソースモジュールの開発

en: Understanding network and security resource modules
ja: ネットワークおよびセキュリティーのリソースモジュールの概要

en: Network and security devices separate configuration into sections (such as interfaces, VLANs, and so on) that apply to a network or security service. Ansible resource modules take advantage of this to allow users to configure subsections or resources within the device configuration. Resource modules provide a consistent experience across different network and security devices. For example, a network resource module may only update the configuration for a specific portion of the network interfaces, VLANs, ACLs, and so on for a network device. The resource module:
ja: ネットワークデバイスおよびセキュリティーデバイスは、その設定を、ネットワークサービスまたはセキュリティーサービスに適用されるセクション (インターフェース、VLAN など) に分割します。Ansible リソースモジュールはこれを利用して、ユーザーがデバイス設定でサブセクションやリソースを設定できるようにします。リソースモジュールは、異なるネットワークおよびセキュリティーデバイス全体で一貫したエクスペリエンスを提供します。たとえば、ネットワークリソースモジュールは、ネットワークインターフェース、VLAN、ACL などの特定の部分に対して設定を更新することができます。リソースモジュールは、以下を行います。

en: Fetches a piece of the configuration (fact gathering), for example, the interfaces configuration.
ja: インターフェース設定など、設定の一部 (ファクト収集) を取得します。

en: Converts the returned configuration into key-value pairs.
ja: 返された設定をキーと値のペアに変換します。

en: Places those key-value pairs into an internal agnostic structured data format.
ja: これらのキーと値のペアを内部に依存しない構造化データ形式に置きます。

en: Now that the configuration data is normalized, the user can update and modify the data and then use the resource module to send the configuration data back to the device. This results in a full round-trip configuration update without the need for manual parsing, data manipulation, and data model management.
ja: 設定データが正規化され、ユーザーはデータを更新して変更し、リソースモジュールを使用して設定データをデバイスに戻すことができます。これにより、手動の解析、データ操作、およびデータモデル管理を必要とせずに、完全なラウンドトリップ設定の更新が可能になります。

en: The resource module has two top-level keys - ``config`` and ``state``:
ja: リソースモジュールには、``config`` と ``state`` の 2 つのトップレベルキーがあります。

en: ``config`` defines the resource configuration data model as key-value pairs.  The type of the ``config`` option can be ``dict`` or ``list of dict`` based on the resource managed.  That is, if the device has a single global configuration, it should be a ``dict`` (for example, a global LLDP configuration). If the device has multiple instances of configuration, it should be of type ``list`` with each element in the list of type ``dict`` (for example, interfaces configuration).
ja: ``config`` は、リソース設定のデータモデルをキーと値のペアとして定義します。``config`` オプションのタイプは、管理されるリソースに基づいて ``dict`` または ``list of dict`` になります。つまり、デバイスにグローバル設定が 1 つある場合には、``dict`` でなければなりません (例: グローバル LLDP 設定)。デバイスに複数の設定インスタンスがある場合は、タイプが ``list`` となり、リストの各要素はタイプが ``dict`` である必要があります (例: インターフェース設定)。

en: ``state`` defines the action the resource module takes on the end device.
ja: ``state`` リソースモジュールがエンドデバイスで使用するアクションを定義します。

en: The ``state`` for a new resource module should support the following values (as applicable for the devices that support them):
ja: 新しいリソースモジュールの ``state`` は、以下の値をサポートする必要があります (サポートするデバイスに該当する場合)。

en: Ansible merges the on-device configuration with the provided configuration in the task.
ja: Ansible は、デバイス上の設定をタスクに指定した設定と統合します。

en: Ansible replaces the on-device configuration subsection with the provided configuration subsection in the task.
ja: Ansible が、デバイス上の設定のサブセクションを、タスクに指定した設定のサブセクションに置き換えます。

en: Ansible overrides the on-device configuration for the resource with the provided configuration in the task. Use caution with this state as you could remove your access to the device (for example, by overriding the management interface configuration).
ja: Ansible は、リソースのデバイスの設定を、タスクで提供された設定を使用して上書きします。この状態では、デバイスへのアクセスが削除される可能性があるため、注意が必要です (たとえば、管理インターフェイスの設定を上書きするなど)。

en: Ansible deletes the on-device configuration subsection and restores any default settings.
ja: Ansible は、デバイス上の設定サブセクションを削除して、デフォルト設定を復元します。

en: Ansible displays the resource details gathered from the network device and accessed with the ``gathered`` key in the result.
ja: Ansible は、ネットワークデバイスから収集したリソースの詳細を表示し、結果の ``gathered`` キーを使用してアクセスします。

en: Ansible renders the provided configuration in the task in the device-native format (for example, Cisco IOS CLI). Ansible returns this rendered configuration in the ``rendered`` key in the result. Note this state does not communicate with the network device and can be used offline.
ja: Ansible は、デバイスネイティブの形式でタスク内の提供された設定をレンダリングします (例: Cisco IOS CLI)。Ansible は、結果内の ``rendered`` キーでレンダリングされた設定を返します。この状態はネットワークデバイスと通信せず、オフラインで使用できる点に注意してください。

en: Ansible parses the configuration from the ``running_configuration`` option into Ansible structured data in the ``parsed`` key in the result. Note this does not gather the configuration from the network device so this state can be used offline.
ja: Ansible は、``running_configuration`` オプションから、その結果内の ``parsed`` キーの Ansible 構造化データに設定を解析します。この設定は、ネットワークデバイスから設定が収集されないため、この状態をオフラインで使用できる点に注意してください。

en: Modules in Ansible-maintained collections must support these state values. If you develop a module with only "present" and "absent" for state, you may submit it to a community collection.
ja: Ansible が管理しているコレクションのモジュールは、これらの状態値をサポートする必要があります。状態が「present」および「absent」のモジュールを開発した場合は、コミュニティーコレクションに提出することができます。

en: The states ``rendered``, ``gathered``, and ``parsed`` do not perform any change on the device.
ja: 状態 ``rendered``、``gathered``、および ``parsed`` はデバイス上で変更を行いません。

en: Walkthrough of how state values are implemented for VLANs.
ja: VLAN への状態値の実装方法のウォールスルー

en: Developing network and security resource modules
ja: ネットワークおよびセキュリティーのリソースモジュールの開発

en: The Ansible Engineering team ensures the module design and code pattern  within Ansible-maintained collections is uniform across resources and across platforms to give a vendor-agnostic feel and deliver good quality code. We recommend you use the `resource module builder <https://github.com/ansible-network/resource_module_builder>`_ to  develop a resource module.
ja: Ansible Engineering チームは、Ansible が管理しているコレクション内のモジュール設計およびコードパターンがリソースやプラットフォーム全体で統一され、ベンダーに依存せず、適切な品質コードを提供します。`リソースモジュールビルダー <https://github.com/ansible-network/resource_module_builder>`_ を使用してリソースモジュールを開発することが推奨されます。

en: The highlevel process for developing a resource module is:
ja: リソースモジュール開発の主なプロセスは次のとおりです。

en: Create and share a resource model design in the `resource module models repository <https://github.com/ansible-network/resource_module_models>`_ as a PR for review.
ja: レビュー用にプル要求として、`リソースモジュールモデルリポジトリー <https://github.com/ansible-network/resource_module_models>`_ でリソースモデルの設計を作成し、共有します。

en: Download the latest version of the `resource module builder <https://github.com/ansible-network/resource_module_builder>`_.
ja: 最新バージョンの `リソースモジュールビルダー <https://github.com/ansible-network/resource_module_builder>`_ をダウンロードします。

en: Run the ``resource module builder`` to create a collection scaffold from your approved resource model.
ja: ``リソースモジュールビルダー`` を実行して、承認されたリソースモデルからコレクションのスキャフォールディングを作成します。

en: Write the code to implement your resource module.
ja: コードを作成し、リソースモジュールを実装します。

en: Develop integration and unit tests to verify your resource module.
ja: 統合テストおよびユニットテストを開発して、リソースモジュールを確認します。

en: Create a PR to the appropriate collection that you want to add your new resource module to. See :ref:`contributing_maintained_collections` for details on determining the correct collection for your module.
ja: 新しいリソースモジュールを追加する適切なコレクションにプル要求を作成します。モジュールの正しいコレクションを判断する方法は「:ref:`contributing_maintained_collections`」を参照してください。

en: Understanding the model and resource module builder
ja: モデルおよびリソースモジュールビルダーの理解

en: The resource module builder is an Ansible Playbook that helps developers scaffold and maintain an Ansible resource module. It uses a model as the single source of truth for the module. This model is a ``yaml`` file that is used for the module DOCUMENTATION section and the argument spec.
ja: リソースモジュールビルダーは、開発者が Ansible リソースモジュールをスキャフォールディングし、維持できるようにする Ansible Playbook です。このモデルは、モジュールの信頼できる唯一のソースとして使用します。このモデルは、モジュールの DOCUMENTATION セクションおよび引数仕様に使用される ``yaml`` ファイルです。

en: The resource module builder has the following capabilities:
ja: リソースモジュールビルダーには以下の機能があります。

en: Uses a defined model to scaffold a resource module directory layout and initial class files.
ja: 定義されたモデルを使用して、リソースモジュールディレクトリーのレイアウトと初期クラスファイルをスキャフォールディングします。

en: Scaffolds either an Ansible role or a collection.
ja: Ansible ロールまたはコレクションのいずれかをスキャフォールディングします。

en: Subsequent uses of the resource module builder will only replace the module arspec and file containing the module docstring.
ja: その後、リソースモジュールビルダーを使用すると、モジュールの arspec と、モジュールの docstring を含むファイルのみが置き換えられます。

en: Allows you to store complex examples along side the model in the same directory.
ja: 複雑なサンプルモデルと同じディレクトリーに保存できます。

en: Maintains the model as the source of truth for the module and use resource module builder to update the source files as needed.
ja: モジュールの信頼できるソースとしてこのモデルを維持し、必要に応じてリソースモジュールビルダーを使用してソースファイルを更新します。

en: Generates working sample modules for both ``<network_os>_<resource>`` and ``<network_os>_facts``.
ja: ``<network_os>_<resource>`` および ``<network_os>_facts`` の両方に作業サンプルモジュールを生成します。

en: Accessing the resource module builder
ja: リソースモジュールビルダーへのアクセス

en: To access the resource module builder:
ja: リソースモジュールビルダーにアクセスするには、以下を実行します。

en: clone the github repository:
ja: github リポジトリーのクローンを作成します。

en: Install the requirements:
ja: 要件をインストールします。

en: Creating a model
ja: モデルの作成

en: You must create a model for your new resource. The model is the single source of truth for both the argspec and docstring, keeping them in sync. Once your model is approved, you can use the resource module builder to generate three items based on the model:
ja: 新しいリソースのモデルを作成する必要があります。モデルは、argspec と docstring の両方に対する信頼できる唯一のソースとなります。モデルが承認されると、リソースモジュールビルダーを使用して、このモデルに基づいて 3 つのアイテムを生成できます。

en: The scaffold for a new module
ja: 新しいモジュールのスキャフォールディング

en: The argspec for the new module
ja: 新しいモジュールの argspec

en: The docstring for the new module
ja: 新しいモジュールの docstring

en: For any subsequent changes to the functionality, update the model first and use the resource module builder to update the module argspec and docstring.
ja: その後、機能に対する変更を行う場合は、最初にモデルを更新し、リソースモジュールビルダーを使用してモジュールの argspec および docstring を更新します。

en: For example, the resource model builder includes the ``myos_interfaces.yml`` sample in the :file:`models` directory, as seen below:
ja: たとえば、リソースモデルビルダーには、以下のように :file:`models` ディレクトリーに ``myos_interfaces.yml`` サンプルが含まれます。

en: Notice that you should include examples for each of the states that the resource supports. The resource module builder also includes these in the sample model.
ja: リソースがサポートする各状態の例を含める必要があることに注意してください。リソースモジュールビルダーには、サンプルモデルにもこれらが含まれます。

en: Share this model as a PR for review at `resource module models repository <https://github.com/ansible-network/resource_module_models>`_. You can also see more model examples at that location.
ja: このモデルは、`リソースモジュールモデルのリポジトリー <https://github.com/ansible-network/resource_module_models>`_ で確認するための PR として共有します。この場所でさらにモデルのサンプルを表示することもできます。

en: Creating a collection scaffold from a resource model
ja: リソースモデルからのコレクションのスキャフォールディングの作成

en: To use the resource module builder to create a collection scaffold from your approved resource model:
ja: リソースモジュールビルダーを使用して、認証されたリソースモデルからコレクションのスキャフォールディングを作成するには、以下を実行します。

en: Where the parameters are as follows:
ja: パラメーターは以下のようになります。

en: ``rm_dest``: The directory where the resource module builder places the files and directories for the resource module and facts modules.
ja: ``rm_dest``: リソースモジュールビルダーが、リソースモジュールおよびファクトモジュールのファイルおよびディレクトリーを置くディレクトリー。

en: ``structure``: The directory layout type (role or collection)
ja: ``structure``: ディレクトリーレイアウトの種類 (ロールまたはコレクション)。

en: ``role``: Generate a role directory layout.
ja: ``role``: ロールディレクトリーレイアウトを生成します。

en: ``collection``: Generate a collection directory layout.
ja: ``collection``: コレクションディレクトリーのレイアウトを生成します。

en: ``collection_org``: The organization of the collection, required when `structure=collection`.
ja: ``collection_org``: `structure=collection` の場合にコレクションの組織が必要です。

en: ``collection_name``: The name of the collection, required when `structure=collection`.
ja: ``collection_name``: `structure=collection` の場合に必要となるコレクションの名前です。

en: ``model``: The path to the model file.
ja: ``model``: モデルファイルへのパス。

en: To use the resource module builder to create a role scaffold:
ja: リソースモジュールビルダーを使用してロールのスキャフォールディングを作成するには、以下を実行します。

en: Examples
ja: 例

en: Collection directory layout
ja: コレクションディレクトリーのレイアウト

en: This example shows the directory layout for the following:
ja: この例では、以下のようなディレクトリーレイアウトを示しています。

en: Role directory layout
ja: ロールディレクトリーのレイアウト

en: This example displays the role directory layout for the following:
ja: この例では、以下のロールのディレクトリーレイアウトを表示しています。

en: Using the collection
ja: コレクションの使用

en: This example shows how to use the generated collection in a playbook:
ja: 以下の例は、生成されたコレクションを Playbook で使用する方法を示しています。

en: Using the role
ja: ロールの使用

en: This example shows how to use the generated role in a playbook:
ja: 以下の例は、生成されたロールを Playbook で使用する方法を示しています。

en: Resource module structure and workflow
ja: リソースモジュール構造およびワークフロー

en: The resource module structure includes the following components:
ja: リソースモジュール構造には、以下のコンポーネントが含まれます。

en: Module
ja: モジュール

en: ``library/<ansible_network_os>_<resource>.py``.
ja: ``library/<ansible_network_os>_<resource>.py``。

en: Imports the ``module_utils`` resource package and calls ``execute_module`` API:
ja: ``module_utils`` リソースパッケージをインポートし、``execute_module`` API を呼び出します。

en: Module argspec
ja: モジュールの argspec

en: ``module_utils/<ansible_network_os>/argspec/<resource>/``.
ja: ``module_utils/<ansible_network_os>/argspec/<resource>/``。

en: Argspec for the resource.
ja: リソースの argspec

en: Facts
ja: ファクト

en: ``module_utils/<ansible_network_os>/facts/<resource>/``.
ja: ``module_utils/<ansible_network_os>/facts/<resource>/``。

en: Populate facts for the resource.
ja: リソースのファクトを入力します。

en: Entry in ``module_utils/<ansible_network_os>/facts/facts.py`` for ``get_facts`` API to keep ``<ansible_network_os>_facts`` module and facts gathered for the resource module in sync for every subset.
ja: すべてのサブセットに対して同期するリソースモジュール用に収集された ``<ansible_network_os>_facts`` モジュールおよびファクトを保持する ``get_facts`` API の ``module_utils/<ansible_network_os>/facts/facts.py`` エントリー。

en: Entry of Resource subset in FACTS_RESOURCE_SUBSETS list in ``module_utils/<ansible_network_os>/facts/facts.py`` to make facts collection work.
ja: ``module_utils/<ansible_network_os>/facts/facts.py`` の FACTS_RESOURCE_SUBSETS 一覧でリソースサブセットのエントリー。ファクトコレクションを機能させます。

en: Module package in module_utils
ja: module_utils のモジュールパッケージ

en: ``module_utils/<ansible_network_os>/<config>/<resource>/``.
ja: ``module_utils/<ansible_network_os>/<config>/<resource>/``。

en: Implement ``execute_module`` API that loads the configuration to device and generates the result with ``changed``, ``commands``, ``before`` and ``after`` keys.
ja: 設定を読み込む ``execute_module`` API を実装し、``changed`` キー、``commands`` キー、``before`` キー、および ``after`` キーで結果を生成します。

en: Call ``get_facts`` API that returns the ``<resource>`` configuration facts or return the difference if the device has onbox diff support.
ja: ``<resource>`` 設定のファクトを返す ``get_facts`` API を呼び出すか、デバイスに onbox diff サポートがある場合はその相違点を返します。

en: Compare facts gathered and given key-values if diff is not supported.
ja: diff がサポートされていない場合は、収集されるファクトと、指定されるキー/値を比較します。

en: Generate final configuration.
ja: 最後の設定を生成します。

en: Utils
ja: ユーティリティー

en: ``module_utils/<ansible_network_os>/utils``.
ja: ``module_utils/<ansible_network_os>/utils``。

en: Utilities for the ``<ansible_network_os>`` platform.
ja: ``<ansible_network_os>`` プラットフォームのユーティリティー。

en: Running  ``ansible-test sanity`` and ``tox`` on resource modules
ja: リソースモジュールでの ``ansible-test sanity`` および ``tox`` の実行

en: You should run ``ansible-test sanity`` and ``tox -elinters`` from the collection root directory before pushing your PR to an Ansible-maintained collection. The CI runs both and will fail if these tests fail. See :ref:`developing_testing` for details on ``ansible-test sanity``.
ja: プル要求を Ansible で管理されたコレクションにプッシュする前に、コレクションルートディレクトリーから ``ansible-test sanity`` および ``tox -elinters`` を実行する必要があります。CI はその両方を実行し、このテストに失敗すると失敗します。``ansible-test sanity`` の詳細は、「:ref:`developing_testing`」を参照してください。

en: To install the necessary packages:
ja: 必要なパッケージをインストールするには、以下を実行します。

en: Ensure you have a valid Ansible development environment configured. See :ref:`environment_setup` for details.
ja: 有効な Ansible 開発環境が設定されていることを確認してください。詳細は :ref:`environment_setup` を参照してください。

en: Run ``pip install -r requirements.txt`` from the collection root directory.
ja: コレクションの root ディレクトリーから ``pip install -r requirements.txt`` を実行します。

en: Running ``tox -elinters``:
ja: ``tox -elinters`` の実行:

en: Reads :file:`tox.ini` from the collection root directory and installs required dependencies (such as ``black`` and ``flake8``).
ja: コレクションルートディレクトリーから :file:`tox.ini` を読み込み、必要な依存関係 (例: ``black``、``flake8``) をインストールします。

en: Runs these with preconfigured options (such as line-length and ignores.)
ja: 事前設定されたオプション (line-length や ignore など) を指定して、これらのコマンドを実行します。

en: Runs  ``black`` in check mode to show  which files will be formatted without actually formatting them.
ja: ``black`` をチェックモードで実行し、実際にフォーマットされることなくどのファイルをフォーマットするかを表示します。

en: Testing resource modules
ja: リソースモジュールのテスト

en: The tests rely on a role generated by the resource module builder. After changes to the resource module builder, the role should be regenerated and the tests modified and run as needed. To generate the role after changes:
ja: テストは、リソースモジュールビルダーが生成したロールに依存します。リソースモジュールビルダーへの変更後に、ロールを再生成し、必要に応じてテストが変更され、実行される必要があります。変更後にロールを生成するには、以下を行います。

en: Resource module integration tests
ja: リソースモジュール統合テスト

en: High-level integration test requirements for new resource modules are as follows:
ja: 新しいリソースモジュールのハイレベル統合テスト要件は次のとおりです。

en: Write a test case for every state.
ja: すべての状態についてテストケースを作成します。

en: Write additional test cases to test the behavior of the module when an empty ``config.yaml`` is given.
ja: 空の ``config.yaml`` が指定されている場合にモジュールの動作をテストするために、追加のテストケースを作成します。

en: Add a round trip test case. This involves a ``merge`` operation, followed by ``gather_facts``, a ``merge`` update with additional configuration, and then reverting back to the base configuration using the previously gathered facts with the ``state`` set to  ``overridden``.
ja: ラウンドトリップテストケースを追加します。これには ``merge`` の操作が含まれ、続いて ``gather_facts`` 、``merge`` が追加の構成で更新され、その後、``state`` が ``overridden`` に設定された状態で、以前に収集したファクトを使用して基本構成に戻ります。

en: Wherever applicable, assertions should check after and before ``dicts`` against a hard coded Source of Truth.
ja: 該当する場合、アサーションは、ハードコードされた信頼できる唯一のソースに対して ``dicts`` の前後で確認する必要があります。

en: We use Zuul as the CI to run the integration test.
ja: Zuul を CI として使用し、統合テストを実行します。

en: To view the report, click :guilabel:`Details` on the CI comment in the PR
ja: レポートを表示するには、プル要求の CI コメントにある :guilabel:`Details` をクリックします。

en: To view a failure report,  click :guilabel:`ansible/check` and select the failed test.
ja: 障害レポートを表示するには、:guilabel:`ansible/check` をクリックし、失敗したテストを選択します。

en: To view logs while the test is running, check for your PR number in the `Zull status board <https://dashboard.zuul.ansible.com/t/ansible/status>`_.
ja: テストの実行中にログを表示するには、`Zull 状態ボード <https://dashboard.zuul.ansible.com/t/ansible/status>`_ で プル要求番号を確認します。

en: To fix static test failure locally, run the  :command:`tox -e black` **inside the root folder of collection**.
ja: 静的テストの失敗をローカルで修正するには、:command:`tox -e black` を、**コレクションのルートディレクトリー内** で実行します。

en: To view The Ansible run logs and debug test failures:
ja: Ansible の実行ログおよびデバッグテストの失敗を表示するには、以下を実行します。

en: Click the failed job to get the summary, and click :guilabel:`Logs` for the log.
ja: 失敗したジョブをクリックしてサマリーを取得し、ログの :guilabel:`Logs` をクリックします。

en: Click :guilabel:`console` and scroll down to find the failed test.
ja: :guilabel:`console` をクリックし、スクロールダウンして失敗したテストを見つけます。

en: Click :guilabel:`>` next to the failed test for complete details.
ja: 詳細は、失敗したテストの横にある :guilabel:`>` をクリックします。

en: Integration test structure
ja: 統合テスト構造

en: Each test case should generally follow this pattern:
ja: 通常、各テストケースは、以下のパターンに従います。

en: setup —> test —> assert —> test again (for idempotency) —> assert —> tear down (if needed) -> done. This keeps test playbooks from becoming monolithic and difficult to troubleshoot.
ja: 設定 —> テスト —> アサート —> 再テスト (冪等性) —> アサート —> 分解 (必要な場合) -> 完了。これにより、テスト Playbook がモノリシックになり、トラブルシューティングが困難になります。

en: Include a name for each task that is not an assertion. You can add names to assertions as well, but it is easier to identify the broken task within a failed test if you add a name for each task.
ja: アサーションではない各タスクの名前を含めます。名前をアサーションに追加できますが、各タスクの名前を追加すると、失敗したテスト内では、破損したタスクを特定するのが容易になります。

en: Files containing test cases must end in ``.yaml``
ja: テストケースを含むファイルは ``.yaml`` で終了する必要があります。

en: Implementation
ja: 実装

en: For platforms that support ``connection: local`` *and* ``connection: network_cli``  use the following guidance:
ja: ``connection: local`` *および* ``connection: network_cli`` をサポートするプラットフォームについては、以下のガイダンスを使用します。

en: Name the :file:`targets/` directories after the module name.
ja: モジュール名の後に :file:`targets/` ディレクトリーに名前を付けます。

en: The :file:`main.yaml` file should just reference the transport.
ja: :file:`main.yaml` ファイルは、トランスポートを参照するだけです。

en: The following example walks through the integration tests for the ``vyos.vyos.vyos_l3_interfaces`` module in the `vyos.vyos <https://github.com/ansible-collections/vyos.vyos/tree/master/tests/integration>`_ collection:
ja: 以下の例では、`vyos.vyos <https://github.com/ansible-collections/vyos.vyos/tree/master/tests/integration>`_ コレクションの ``vyos.vyos.vyos_l3_interfaces`` モジュールの統合テストを行います。

en: Detecting test resources at runtime
ja: ランタイム時のテストリソースの検出

en: Your tests should detect resources (such as interfaces) at runtime rather than hard-coding them into the test. This allows the test to run on a variety of systems.
ja: テストは、(インターフェースなどの) リソースをテストにハードコーディングするのではなく、ランタイム時にリソースを検出する必要があります。これにより、テストはさまざまなシステムで実行できます。

en: For example:
ja: たとえば、以下のようになります。

en: See the complete test example of this at https://github.com/ansible-collections/cisco.nxos/blob/master/tests/integration/targets/prepare_nxos_tests/tasks/main.yml.
ja: https://github.com/ansible-collections/cisco.nxos/blob/master/tests/integration/targets/prepare_nxos_tests/tasks/main.yml. で、このテストの完全例を参照してください。

en: Running network integration tests
ja: ネットワーク統合テストの実行

en: Ansible uses Zuul to run an integration test suite on every PR, including new tests introduced by that PR. To find and fix problems in network modules, run the network integration test locally before you submit a PR.
ja: Ansible は Zuul を使用して、すべてのプル要求で、プル要求によって導入された新規テストを含む統合テストスイートを実行します。ネットワークモジュールで問題を特定して修正するには、プル要求を送信する前にネットワーク統合テストをローカルで実行します。

en: First, create an inventory file that points to your test machines. The inventory group should match the platform name (for example, ``eos``, ``ios``):
ja: まず、テストマシンを参照するインベントリーファイルを作成します。インベントリーグループは、プラットフォーム名と一致する必要があります (例: ``eos``、``ios``)。

en: To run these network integration tests, use ``ansible-test network-integration --inventory </path/to/inventory> <tests_to_run>``:
ja: これらのネットワーク統合テストを実行するには、``ansible-test network-integration --inventory </path/to/inventory> <tests_to_run>`` を使用します。

en: To run all network tests for a particular platform:
ja: 特定のプラットフォームでネットワークテストをすべて実行するには、次を実行します。

en: This example will run against all ``vyos`` modules. Note that ``vyos_.*`` is a regex match, not a bash wildcard - include the `.` if you modify this example.
ja: この例は、すべての ``vyos`` モジュールに対して実行します。``vyos_.*`` は、bash ワイルドカードではなく、正規表現一致であることに注意してください。この例を修正する場合は `.` を含むようにしてください。

en: To run integration tests for a specific module:
ja: 特定のモジュールに対して統合テストを実行するには、次を実行します。

en: To run a single test case on a specific module:
ja: 特定のモジュールでテストケースを 1 つ実行するには、次を実行します。

en: To run integration tests for a specific transport:
ja: 特定のトランスポートで統合テストを実行するには、次を実行します。

en: See `test/integration/targets/nxos_bgp/tasks/main.yaml <https://github.com/ansible-collections/cisco.nxos/blob/master/tests/integration/targets/nxos_bgp/tasks/main.yaml>`_ for how this is implemented in the tests.
ja: テストに実装される方法は、「`test/integration/targets/nxos_bgp/tasks/main.yaml <https://github.com/ansible-collections/cisco.nxos/blob/master/tests/integration/targets/nxos_bgp/tasks/main.yaml>`_」を参照してください。

en: For more options:
ja: その他のオプション:

en: If you need additional help or feedback, reach out in the ``#ansible-network`` IRC channel on the `irc.libera.chat <https://libera.chat/>`_ IRC network.
ja: 本書で示したもの以外にヘルプやフィードバックが必要な場合は、IRC ネットワーク `irc.libera.chat <https://libera.chat/>`_ の IRC チャンネル ``#ansible-network`` にアクセスしてください。

en: Unit test requirements
ja: ユニットテストの要件

en: High-level unit test requirements that new resource modules should follow:
ja: 新しいリソースモジュールが従う高レベルのユニットテスト要件は以下のようになります。

en: Write test cases for all the states with all possible combinations of config values.
ja: 設定値の組み合わせ可能なすべての状態についてテストケースを作成します。

en: Write test cases to test the error conditions ( negative scenarios).
ja: テストケースを作成し、エラー条件 (負のシナリオ) をテストします。

en: Check the  value of ``changed`` and ``commands`` keys in every test case.
ja: すべてのテストケースで ``changed`` キーおよび ``commands`` キーの値を確認します。

en: We run all unit test cases on our Zuul test suite, on the latest python version supported by our CI setup.
ja: CI 設定でサポートされる最新の python バージョンで、Zuul テストスイートですべてのユニットテストケースを実行します。

en: Use the :ref:`same procedure <using_zuul_resource_modules>` as the integration tests to view Zuul unit tests reports and logs.
ja: :ref:`同じ手順 <using_zuul_resource_modules>` を統合テストとして使用し、Zuul ユニットテストのレポートおよびログを表示します。

en: See  :ref:`unit module testing <testing_units_modules>` for general unit test details.
ja: 一般的なユニットテストの詳細は、「:ref:`ユニットモジュールのテスト <testing_units_modules>`」を参照してください。

en: Example: Unit testing Ansible network resource modules
ja: 例: Ansible ネットワークリソースモジュールのユニットテスト

en: This section walks through an example of how to develop unit tests for Ansible resource modules.
ja: 本セクションでは、Ansible リソースモジュールのユニットテストを開発する方法の例を説明します。

en: See :ref:`testing_units` and :ref:`testing_units_modules` for general documentation on Ansible unit tests for modules. Please read those pages first to understand unit tests and why and when you should use them.
ja: モジュール向けの Ansible ユニットテストの一般的なドキュメントは、「:ref:`testing_units`」および「:ref:`testing_units_modules`」を参照してください。ユニットテスト、および使用する理由およびその方法を理解するには、まずこれらのページをお読みください。

en: Using mock objects to unit test Ansible network resource modules
ja: モック (模擬) オブジェクトを使用した Ansible ネットワークリソースモジュールのユニットテスト

en: `Mock objects <https://docs.python.org/3/library/unittest.mock.html>`_ can be very useful in building unit tests for special or difficult cases, but they can also lead to complex and confusing coding situations.  One good use for mocks would be to simulate an API. The ``mock`` Python package is bundled with Ansible (use ``import units.compat.mock``).
ja: `モックオブジェクト <https://docs.python.org/3/library/unittest.mock.html>`_ は、特殊なケースや難しいケースのユニットテストを構築するのに非常に便利ですが、複雑で理解しづらいコーディングになってしまうこともあります。モックの使用方法として適切なものの 1 つに、API のシミュレートがあります。``mock`` Python パッケージは、Ansible にバンドルされています (``import units.compat.mock`` を使用)。

en: You can mock the device connection and output from the device as follows:
ja: 以下のように、デバイスの接続とデバイスからの出力を模倣できます。

en: The facts file of the module now includes a new method, ``get_device_data``. Call ``get_device_data`` here to emulate the device output.
ja: モジュールのファクトファイルに新しいメソッド ``get_device_data`` が追加されました。ここで ``get_device_data`` を呼び出して、デバイスの出力をエミュレートします。

en: Mocking device data
ja: デバイスデータの模倣

en: To mock fetching results from devices or provide other complex data structures that come from external libraries, you can use ``fixtures`` to read in pre-generated data. The text files for this pre-generated data live in ``test/units/modules/network/PLATFORM/fixtures/``. See for example the `eos_l2_interfaces.cfg file <https://github.com/ansible-collections/arista.eos/blob/master/tests/unit/modules/network/eos/fixtures/eos_l2_interfaces_config.cfg>`_.
ja: デバイスからの結果の取得や、外部ライブラリーからの複雑なデータ構造の提供を模倣するために、``fixtures`` を使用して事前に生成されたデータを読み込むことができます。この事前に生成されたデータのテキストファイルは、``test/units/modules/network/PLATFORM/fixtures/`` にあります。たとえば、`eos_l2_interfaces.cfg file <https://github.com/ansible-collections/arista.eos/blob/master/tests/unit/modules/network/eos/fixtures/eos_l2_interfaces_config.cfg>`_ の例を参照してください。

en: Load data using the ``load_fixture`` method and set this data as the return value of the ``get_device_data`` method in the facts file:
ja: ``load_fixture`` メソッドを使用してデータを読み込み、このデータをファクトファイルの ``get_device_data`` メソッドの戻り値として設定します。

en: See the unit test file `test_eos_l2_interfaces <https://github.com/ansible-collections/arista.eos/blob/master/tests/unit/modules/network/eos/test_eos_l2_interfaces.py>`_ for a practical example.
ja: 実用的な例は、ユニットテストファイル `test_eos_l2_interfaces <https://github.com/ansible-collections/arista.eos/blob/master/tests/unit/modules/network/eos/test_eos_l2_interfaces.py>`_ を参照してください。

en: Deep dive into developing unit tests for Ansible modules
ja: Ansible モジュールのユニットテスト開発を深く掘り下げて調査

en: Running tests locally including gathering and reporting coverage data
ja: カバレージデータの収集とレポートを含む、ローカルでのテストの実行

en: Get started developing a module
ja: モジュール開発を始める

en: Documenting new network platforms
ja: 新しいネットワークプラットフォームのドキュメント化

en: When you create network modules for a new platform, or modify the connections provided by an existing network platform(such as ``network_cli`` and ``httpapi``), you also need to update  the :ref:`settings_by_platform` table and add or modify the Platform Options file for your platform.
ja: 新しいプラットフォーム用のネットワークモジュールを作成する場合や、既存のネットワークプラットフォーム (``network_cli``、``httpapi`` など) が提供する接続を変更する場合は、:ref:`settings_by_platform` テーブルを更新して、プラットフォームの Platform Options ファイルを追加または変更することも必要です。

en: You should already have documented each module as described in :ref:`developing_modules_documenting`.
ja: 各モジュールは、「:ref:`developing_modules_documenting`」で説明されているように、すでに文書化されている必要があります。

en: Modifying the platform options table
ja: プラットフォームオプションテーブルの変更

en: The :ref:`settings_by_platform` table is a convenient summary of the connections options provided by each network platform that has modules in Ansible. Add a row for your platform to this table, in alphabetical order.  For example:
ja: :ref:`settings_by_platform` テーブルは、Ansible にモジュールがある各ネットワークプラットフォームが提供する接続オプションの便利な概要です。お使いのプラットフォームの行をアルファベット順に追加します。以下に例を示します。

en: Ensure that the table stays formatted correctly. That is:
ja: テーブルの形式が正しく表示されていることを確認します。つまり、以下のようになります。

en: Each row is inserted in alphabetical order.
ja: 各行はアルファベット順に挿入されます。

en: The cell division ``|`` markers line up with the ``+`` markers.
ja: セル分割マーカー ``|`` と ``+`` マーカーの位置は同じになります。

en: The check marks appear only for the connection types provided by the network modules.
ja: このチェックマークは、ネットワークモジュールが提供する接続タイプに限り表示されます。

en: Adding a platform-specific options section
ja: プラットフォーム固有のオプションセクションの追加

en: The platform- specific sections are individual ``.rst`` files that provide more detailed information for the users of your network platform modules.   Name your new file ``platform_<name>.rst`` (for example, ``platform_myos.rst``).  The platform name should match the module prefix. See `platform_eos.rst <https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/network/user_guide/platform_eos.rst>`_ and :ref:`eos_platform_options` for an example of the details you should provide in your platform-specific options section.
ja: プラットフォーム固有のセクションは、ネットワークプラットフォームモジュールのユーザーに関する詳細情報を提供する個別の ``.rst`` ファイルです。新しいファイル ``platform_<name>.rst`` に名前を付けます (例: ``platform_myos.rst``)。プラットフォーム名はモジュール接頭辞と一致させる必要があります。プラットフォーム固有のオプションセクションに指定する必要のある詳細例は、「`platform_eos.rst <https://github.com/ansible/ansible/blob/devel/docs/docsite/rst/network/user_guide/platform_eos.rst>`_」および「:ref:`eos_platform_options`」を参照してください。

en: Your platform-specific section should include the following:
ja: プラットフォーム固有のセクションには、以下のセクションが含まれている必要があります。

en: **Connections available table** - a deeper dive into each connection type, including details on credentials, indirect access, connections settings, and enable mode.
ja: **接続可能なテーブル** - 認証情報、間接アクセス、接続設定、有効化モードの詳細など、各接続タイプの詳細。

en: **How to use each connection type** - with working examples of each connection type.
ja: **各接続タイプの使用方法** - 各接続タイプの作業例を含む。

en: If your network platform supports SSH connections, also include the following at the bottom of your ``.rst`` file:
ja: ネットワークプラットフォームが SSH 接続に対応している場合は、``.rst`` ファイルの下部に以下も追加します。

en: Adding your new file to the table of contents
ja: 新規ファイルのコンテンツを表へ追加

en: As a final step, add your new file in alphabetical order in the ``platform_index.rst`` file. You should then build the documentation to verify your additions. See :ref:`community_documentation_contributions` for more details.
ja: 最終ステップとして、``platform_index.rst`` ファイルの新しいファイルをアルファベット順に追加します。次に、ドキュメントをビルドして、追加した内容を確認する必要があります。詳細は「:ref:`community_documentation_contributions`」を参照してください。

en: Network Developer Guide
ja: ネットワーク開発者ガイド

en: Welcome to the Developer Guide for Ansible Network Automation!
ja: ネットワークを自動化する開発者向けガイドへようこそ

en: **Who should use this guide?**
ja: **本ガイドの対象者**

en: If you want to extend Ansible for Network Automation by creating a module or plugin, this guide is for you. This guide is specific to networking. You should already be familiar with how to create, test, and document modules and plugins, as well as the prerequisites for getting your module or plugin accepted into the main Ansible repository.  See the  :ref:`developer_guide` for details. Before you proceed, please read:
ja: ネットワーク自動化のために、モジュールやプラグインを作成して Ansible を拡張する場合は、本ガイドをお勧めします。このガイドは、ネットワークに特化しています。モジュールやプラグインの作成、テスト、文書化の方法や、作成したモジュールやプラグインを Ansible のメインリポジトリーに受け入れてもらうための前提条件については、すでにご存知のことと思います。詳細は、「:ref:`developer_guide`」を参照してください。先に進む前に、以下をお読みください。

en: How  to :ref:`add a custom plugin or module locally <developing_locally>`.
ja: :ref:`カスタムプラグインまたはモジュールをローカルに追加する <developing_locally>` 方法

en: How to figure out if :ref:`developing a module is the right approach <module_dev_should_you>` for my use case.
ja: 個別のユースケースで :ref:`モジュールを開発することが正しいアプローチ <module_dev_should_you>` かどうかを判断する方法。

en: How to :ref:`set up my Python development environment <environment_setup>`.
ja: :ref:`Python 開発環境を設定する <environment_setup>` 方法

en: How to :ref:`get started writing a module <developing_modules_general>`.
ja: :ref:`モジュール作成を開始する <developing_modules_general>` 方法

en: Find the network developer task that best describes what you want to do:
ja: お客様が必要なことを最も適切に説明しているネットワーク開発者タスクを選択してください。

en: I want to :ref:`develop a network resource module <developing_resource_modules>`.
ja: :ref:`ネットワークリソースモジュールを開発 <developing_resource_modules>` したいです。

en: I want to :ref:`develop a network connection plugin <developing_plugins_network>`.
ja: :ref:`ネットワーク接続プラグインを開発 <developing_plugins_network>` したいです。

en: I want to :ref:`document my set of modules for a network platform <documenting_modules_network>`.
ja: :ref:`ネットワークプラットフォームのモジュールセットを文書化 <documenting_modules_network>` したいです。

en: If you prefer to read the entire guide, here's a list of the pages in order.
ja: 本ガイドをすべて読む場合は、以下に示す順番でページを表示してください。

en: Basic Concepts
ja: 基本的な概念

en: These concepts are common to all uses of Ansible, including network automation. You need to understand them to use Ansible for network automation. This basic introduction provides the background you need to follow the examples in this guide.
ja: この概念は、ネットワーク自動化を含む Ansible のすべての用途に共通しています。ネットワーク自動化のためにAnsibleを使用するには、これらを理解する必要があります。この基本的な紹介は、本ガイドの例を理解するのに必要な背景を説明します。

en: Control node
ja: コントロールノード

en: Any machine with Ansible installed. You can run Ansible commands and playbooks by invoking the ``ansible`` or ``ansible-playbook`` command from any control node. You can use any computer that has a Python installation as a control node - laptops, shared desktops, and servers can all run Ansible. However, you cannot use a Windows machine as a control node. You can have multiple control nodes.
ja: Ansible がインストールされているマシン。任意のコントロールノードから ``ansible`` コマンドまたは ``ansible-playbook`` コマンドを呼び出すことで、Ansible コマンドおよび Playbook を実行できます。Python がインストールされているコンピューターであれば、ラップトップ、共有ディスクトップ、サーバーなど、どのコンピューターでも Ansible を実行することができます。ただし、Windows マシンをコントロールノードとして使用することはできません。複数のコントロールノードを持つことができます。

en: Managed nodes
ja: 管理ノード

en: The network devices (and/or servers) you manage with Ansible. Managed nodes are also sometimes called "hosts". Ansible is not installed on managed nodes.
ja: Ansible で管理するネットワークデバイス (またはサーバー)。管理ノードは「ホスト」と呼ばれることもあります。Ansible は管理ノードにインストールされません。

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

en: A list of managed nodes. An inventory file is also sometimes called a "hostfile". Your inventory can specify information like IP address for each managed node. An inventory can also organize managed nodes, creating and nesting groups for easier scaling. To learn more about inventory, see :ref:`the Working with Inventory<intro_inventory>` section.
ja: 管理ノードの一覧。インベントリーファイルは「ホストファイル」と呼ばれることもあります。インベントリーは、各管理ノードに対して IP アドレスなどの情報を指定できます。インベントリーは管理ノードを整理でき、スケーリングが容易になるグループの作成やネスト化が可能です。インベントリーの詳細は「:ref:`インベントリーでの作業 <intro_inventory>`」セクションを参照してください。

en: Collections are a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. You can install and use collections through `Ansible Galaxy <https://galaxy.ansible.com>`_. To learn more about collections, see :ref:`collections`.
ja: コレクションは、Playbook、ロール、モジュール、プラグインを含む Ansible コンテンツのディストリビューション形式です。`Ansible Galaxy <https://galaxy.ansible.com>`_ でコレクションをインストールして使用することができます。コレクションの詳細は、「:ref:`collections`」を参照してください。

en: Modules
ja: モジュール

en: The units of code Ansible executes. Each module has a particular use, from administering users on a specific type of database to managing VLAN interfaces on a specific type of network device. You can invoke a single module with a task, or invoke several different modules in a playbook. Starting in Ansible 2.10, modules are grouped in collections. For an idea of how many collections Ansible includes, take a look at the :ref:`list_of_collections`.
ja: Ansible が実行するコードの単位。各モジュールは、特定タイプのデータベースのユーザーを管理したり、特定タイプのネットワークデバイスの VLAN インターフェースを管理するなど、特定の用途に使用されます。タスクで 1 つのモジュールを起動したり、Playbook で複数のモジュールを起動したりすることができます。Ansible 2.10 以降、モジュールはコレクションとしてまとめられています。Ansible に含まれるコレクションの数は、「:ref:`list_of_collections`」を参照してください。

en: Tasks
ja: タスク

en: The units of action in Ansible. You can execute a single task once with an ad hoc command.
ja: Ansible でのアクションの単位。アドホックコマンドを使用すると、単一のタスクを実行できます。

en: Playbooks
ja: Playbook

en: Ordered lists of tasks, saved so you can run those tasks in that order repeatedly. Playbooks can include variables as well as tasks. Playbooks are written in YAML and are easy to read, write, share and understand. To learn more about playbooks, see :ref:`about_playbooks`.
ja: 順番に並べられたタスクの一覧は保存されているため、その順番でタスクを繰り返し実行することができます。Playbook には、タスクだけでなく、変数も含めることができます。Playbook は YAML で記述されているため、読みやすく、書きやすく、共有しやすく、理解しやすい特徴があります。Playbook の詳細は、「:ref:`about_playbooks`」を参照してください。

en: Build Your Inventory
ja: インベントリーの構築

en: Running a playbook without an inventory requires several command-line flags. Also, running a playbook against a single device is not a huge efficiency gain over making the same change manually. The next step to harnessing the full power of Ansible is to use an inventory file to organize your managed nodes into groups with information like the ``ansible_network_os`` and the SSH user. A fully-featured inventory file can serve as the source of truth for your network. Using an inventory file, a single playbook can maintain hundreds of network devices with a single command. This page shows you how to build an inventory file, step by step.
ja: インベントリーを使用せずに Playbook を実行するには、いくつかのコマンドラインフラグが必要です。また、単一のデバイスに対して Playbook を実行しても、同じ変更を手動で行うのに比べて効率が大きく向上するわけではありません。Ansible を最大限に活用するための次のステップは、インベントリーファイルを使用して、管理対象のノードを ``ansible_network_os`` や SSH ユーザーなどの情報を持つグループに整理することです。完全な機能を備えたインベントリーファイルは、ネットワークの唯一の信頼できるソースとなります。インベントリーファイルを使用すると、1 つの Playbook で数百のネットワークデバイスを 1 つのコマンドで管理できます。このページでは、インベントリーファイルを作成する方法を順を追って説明します。

en: Basic inventory
ja: 基本的なインベントリー

en: First, group your inventory logically. Best practice is to group servers and network devices by their What (application, stack or microservice), Where (datacenter or region), and When (development stage):
ja: まず、インベントリーを論理的にグループ化します。ベストプラクティスは、サーバーおよびネットワークデバイスを、種類 (アプリケーション、スタック、またはマイクロサービス)、場所 (データセンタまたは地域)、および時期 (開発段階) でグループ化することです。

en: **What**: db, web, leaf, spine
ja: **種類**: db、web、leaf、spine

en: **Where**: east, west, floor_19, building_A
ja: **場所**: east、west、floor_19、building_A

en: **When**: dev, test, staging, prod
ja: **時期**: dev、test、staging、prod

en: Avoid spaces, hyphens, and preceding numbers (use ``floor_19``, not ``19th_floor``) in your group names. Group names are case sensitive.
ja: グループ名にスペースまたはハイフンを使用しないでください。またグループ名は数値で始めないでください (``19th_floor``ではなく ``floor_19`` を使用)。グループ名は大文字と小文字を区別します。

en: This tiny example data center illustrates a basic group structure. You can group groups using the syntax ``[metagroupname:children]`` and listing groups as members of the metagroup. Here, the group ``network`` includes all leafs and all spines; the group ``datacenter`` includes all network devices plus all webservers.
ja: この小さなデータセンターの例では、基本的なグループ構造を説明します。グループをグループ化するには、``[metagroupname:children]`` という構文を使い、グループをメタグループのメンバーとしてリストアップします。ここでは、``network`` というグループには、すべての leaf (リーフ) とすべての spine (スパイン) が含まれ、``datacenter`` というグループには、すべてのネットワークデバイスとすべての Web サーバーが含まれています。

en: You can also create this same inventory in INI format.
ja: 同じインベントリーを INI 形式で作成することもできます。

en: Add variables to the inventory
ja: インベントリーへの変数の追加

en: Next, you can set values for many of the variables you needed in your first Ansible command in the inventory, so you can skip them in the ``ansible-playbook`` command. In this example, the inventory includes each network device's IP, OS, and SSH user. If your network devices are only accessible by IP, you must add the IP to the inventory file. If you access your network devices using hostnames, the IP is not necessary.
ja: 次に、最初の Ansible コマンドで必要であった多くの変数の値をインベントリーに設定することで、``ansible-playbook`` コマンドでスキップできるようになります。この例では、インベントリーに各ネットワークデバイスの IP、OS、SSH ユーザーが含まれています。ネットワークデバイスに IP でしかアクセスできない場合は、インベントリーファイルに IP を追加する必要があります。ホスト名を使用してネットワークデバイスにアクセスする場合は、IP が必要ありません。

en: Group variables within inventory
ja: インベントリー内のグループ変数

en: When devices in a group share the same variable values, such as OS or SSH user, you can reduce duplication and simplify maintenance by consolidating these into group variables:
ja: グループ内のデバイスが、OS や SSH ユーザーなど、同じ変数値を共有している場合は、この値をグループ変数に統合することで、重複を減らし、メンテナンスを簡素化できます。

en: Variable syntax
ja: 変数の構文

en: The syntax for variable values is different in inventory, in playbooks, and in the ``group_vars`` files, which are covered below. Even though playbook and ``group_vars`` files are both written in YAML, you use variables differently in each.
ja: 変数の値の構文は、インベントリー、Playbook、および ``group_vars`` ファイルで異なりますが、以下で説明します。Playbook と ``group_vars`` ファイルはどちらも YAML で記述されていますが、変数は YAML でそれぞれ異なります。

en: In an ini-style inventory file you **must** use the syntax ``key=value`` for variable values: ``ansible_network_os=vyos.vyos.vyos``.
ja: ini 形式のインベントリーファイルで、変数値 ``ansible_network_os=vyos.vyos.vyos`` に構文 ``key=value`` を使用する **必要があります**。

en: In any file with the ``.yml`` or ``.yaml`` extension, including playbooks and ``group_vars`` files, you **must** use YAML syntax: ``key: value``.
ja: Playbook および ``group_vars`` ファイルを含む ``.yml`` 拡張子または ``.yaml`` 拡張子を持つファイルでは、YAML 構文 ``key: value`` を使用する**必要があります**。

en: In ``group_vars`` files, use the full ``key`` name: ``ansible_network_os: vyos.vyos.vyos``.
ja: ``group_vars`` ファイルで、完全な ``key`` 名 (``ansible_network_os: vyos.vyos.vyos``) を使用します。

en: In playbooks, use the short-form ``key`` name, which drops the ``ansible`` prefix: ``network_os: vyos.vyos.vyos``.
ja: Playbook では、``ansible`` の接頭辞を取り除いた短い形式の``key`` の名前を使用します (``network_os: vyos.vyos.vyos``)。

en: Group inventory by platform
ja: プラットフォームによるインベントリーのグループ化

en: As your inventory grows, you may want to group devices by platform. This allows you to specify platform-specific variables easily for all devices on that platform:
ja: インベントリーが大きくなるにつれ、プラットフォームでデバイスをグループ化できます。これにより、そのプラットフォームのすべてのデバイスに対してプラットフォーム固有の変数を簡単に指定できます。

en: With this setup, you can run ``first_playbook.yml`` with only two flags:
ja: この設定では、以下の 2 つのフラグを指定して ``first_playbook.yml`` を実行できます。

en: With the ``-k`` flag, you provide the SSH password(s) at the prompt. Alternatively, you can store SSH and other secrets and passwords securely in your group_vars files with ``ansible-vault``. See :ref:`network_vault` for details.
ja: ``-k`` フラグを使用して、プロンプトで SSH パスワードを指定します。これで、``ansible-vault`` で SSH と、その他のシークレットおよびパスワードを group_vars ファイルに安全に保存できます。詳細は「:ref:`network_vault`」を参照してください。

en: Verifying the inventory
ja: インベントリーの確認

en: You can use the :ref:`ansible-inventory` CLI command to display the inventory as Ansible sees it.
ja: CLI コマンド :ref:`ansible-inventory` を使用すると、Ansible が確認できるようにインベントリーを表示できます。

en: Protecting sensitive variables with ``ansible-vault``
ja: ``ansible-vault`` による機密変数の保護

en: The ``ansible-vault`` command provides encryption for files and/or individual variables like passwords. This tutorial will show you how to encrypt a single SSH password. You can use the commands below to encrypt other sensitive information, such as database passwords, privilege-escalation passwords and more.
ja: ``ansible-vault`` コマンドは、ファイルや、パスワードなどの個々の変数の暗号化を行います。このチュートリアルでは、1 つの SSH パスワードを暗号化する方法を紹介します。以下のコマンドを使用すると、データベースのパスワードや権限昇格のためのパスワードなど、その他の機密情報を暗号化することができます。

en: First you must create a password for ansible-vault itself. It is used as the encryption key, and with this you can encrypt dozens of different passwords across your Ansible project. You can access all those secrets (encrypted values) with a single password (the ansible-vault password) when you run your playbooks. Here's a simple example.
ja: まず、ansible-vault 自体のパスワードを作成する必要があります。これは暗号化キーとして使用され、Ansible プロジェクト全体で何十もの異なるパスワードを暗号化することができます。Playbook を実行するときに、1 つのパスワード (ansible-vault パスワード) でこの全シークレット (暗号化された値) にアクセスできます。以下に簡単な例を示します。

en: Create a file and write your password for ansible-vault to it:
ja: ファイルを作成して、ansible-vault のパスワードを書き込みます。

en: Create the encrypted ssh password for your VyOS network devices, pulling your ansible-vault password from the file you just created:
ja: VyOS ネットワークデバイス用に暗号化された ssh パスワードを作成し、作成したファイルから ansible-vault パスワードをプルします。

en: If you prefer to type your ansible-vault password rather than store it in a file, you can request a prompt:
ja: ファイルに保存せずに ansible-vault パスワードを入力する必要がある場合は、プロンプトを要求できます。

en: and type in the vault password for ``my_user``.
ja: また、``my_user`` に vault パスワードに入力します。

en: The :option:`--vault-id <ansible-playbook --vault-id>` flag allows different vault passwords for different users or different levels of access. The output includes the user name ``my_user`` from your ``ansible-vault`` command and uses the YAML syntax ``key: value``:
ja: option:`--vault-id <ansible-playbook --vault-id>` フラグを使用すると、ユーザーまたはアクセスレベルごとに異なる Vault パスワードを使用できます。出力には、``ansible-vault`` コマンドのユーザー名 ``my_user`` が含まれ、YAML 構文 ``key: value`` が使用されます。

en: This is an example using an extract from a  YAML inventory, as the INI format does not support inline vaults:
ja: INI 形式はインラインの vault に対応していないため、以下は YAML インベントリーから抽出を使用する例です。

en: To use an inline vaulted variables with an INI inventory you need to store it in a 'vars' file in YAML format, it can reside in host_vars/ or group_vars/ to be automatically picked up or referenced from a play via ``vars_files`` or ``include_vars``.
ja: インラインの Vault 変数を INI インベントリーで使用するには、これを YAML 形式で「vars」ファイルに保存する必要があります。これは host_vars/ または group_vars/ に置かれ、``vars_files`` または ``include_vars`` で Play から自動的に取得または参照されます。

en: To run a playbook with this setup, drop the ``-k`` flag and add a flag for your ``vault-id``:
ja: この設定で Playbook を実行するには、``-k`` フラグを削除し、``vault-id`` のフラグを追加します。

en: Or with a prompt instead of the vault password file:
ja: または、vault パスワードファイルの代わりにプロンプトを使用します。

en: To see the original value, you can use the debug module. Please note if your YAML file defines the `ansible_connection` variable (as we used in our example), it will take effect when you execute the command below. To prevent this, please make a copy of the file without the ansible_connection variable.
ja: 元の値を確認するには、デバッグモジュールを使用できます。(この例で使用したように) YAML ファイルで `ansible_connection` 変数が定義されているかどうかに注意してください。以下のコマンドを実行すると有効になります。これを防ぐには、ansible_connection 変数を使用せずにファイルのコピーを作成してください。

en: Vault content can only be decrypted with the password that was used to encrypt it. If you want to stop using one password and move to a new one, you can update and re-encrypt existing vault content with ``ansible-vault rekey myfile``, then provide the old password and the new password. Copies of vault content still encrypted with the old password can still be decrypted with old password.
ja: Vault のコンテンツは、暗号化に使用されたパスワードでのみ復号できます。1 つのパスワードの使用を停止して新しいパスワードに移動する場合は、``ansible-vault rekey myfile`` を使用して、既存の Valut コンテンツを更新して再暗号化でき、次に古いパスワードと新しいパスワードを入力します。古いパスワードで暗号化されたままの Vault コンテンツのコピーは、古いパスワードで復号できます。

en: For more details on building inventory files, see :ref:`the introduction to inventory<intro_inventory>`; for more details on ansible-vault, see :ref:`the full Ansible Vault documentation<vault>`.
ja: インベントリーファイルの構築の詳細は、「:ref:`インベントリーの概要<intro_inventory>`」を参照してください。ansible-vault の詳細は、:ref:`Ansible Vault の完全ドキュメント<vault>` を参照してください。

en: Now that you understand the basics of commands, playbooks, and inventory, it's time to explore some more complex Ansible Network examples.
ja: コマンド、Playbook、およびインベントリーの基本を理解したら、より複雑な Ansible Network の例をいくつか説明します。

en: Run Your First Command and Playbook
ja: 最初のコマンドおよび Playbook の実行

en: Put the concepts you learned to work with this quick tutorial. Install Ansible, execute a network configuration command manually, execute the same command with Ansible, then create a playbook so you can execute the command any time on multiple network devices.
ja: このクイックチュートリアルでは、これまで学んだ概念を実際に使ってみましょう。Ansible をインストールし、ネットワーク設定コマンドを手動で実行し、Ansible で同じコマンドを実行してから Playbook を作成するため、複数のネットワークデバイスでいつでもコマンドを実行できます。

en: Prerequisites
ja: 要件

en: Before you work through this tutorial you need:
ja: このチュートリアルを実行する前に、以下が必要になります。

en: Ansible 2.10 (or higher) installed
ja: Ansible 2.10 (以降) がインストールされている

en: One or more network devices that are compatible with Ansible
ja: Ansible と互換性のある 1 つ以上ネットワークデバイス

en: Basic Linux command line knowledge
ja: 基本的な Linux コマンドラインの知識

en: Basic knowledge of network switch & router configuration
ja: ネットワークスイッチおよびルーター設定に関する基本知識

en: Install Ansible
ja: Ansible のインストール

en: Install Ansible using your preferred method. See :ref:`installation_guide`. Then return to this tutorial.
ja: 好みの方法で Ansible をインストールします。「:ref:`installation_guide`」を参照してください。その後、このチュートリアルに戻ります。

en: Confirm the version of Ansible (must be >= 2.10):
ja: Ansible のバージョンを確認します (2.10 以下である必要があります)。

en: Establish a manual connection to a managed node
ja: 管理ノードへの手動接続の確立

en: To confirm your credentials, connect to a network device manually and retrieve its configuration. Replace the sample user and device name with your real credentials. For example, for a VyOS router:
ja: 認証情報を確認するには、手動でネットワークデバイスに接続し、その設定を取得します。サンプルユーザー名とデバイス名を実際の認証情報に置き換えます。たとえば、VyOS ルーターの場合は以下のようになります。

en: This manual connection also establishes the authenticity of the network device, adding its RSA key fingerprint to your list of known hosts. (If you have connected to the device before, you have already established its authenticity.)
ja: この手動接続により、ネットワークデバイスの信頼性も確立され、既知のホストの一覧に RSA 鍵フィンガープリントが追加されます (以前にデバイスを接続したことがある場合は、その信頼性がすでに確立されています)。

en: Run your first network Ansible command
ja: 最初のネットワーク Ansible コマンドの実行

en: Instead of manually connecting and running a command on the network device, you can retrieve its configuration with a single, stripped-down Ansible command:
ja: ネットワークデバイスでコマンドを手動で接続して実行する代わりに、1 つの削除済み Ansible コマンドで設定を取得できます。

en: The flags in this command set seven values:
ja: このコマンドのフラグは、7 つの値を設定します。

en: the host group(s) to which the command should apply (in this case, all)
ja: コマンドを適用するホストグループ (この場合は all)

en: the inventory (-i, the device or devices to target - without the trailing comma -i points to an inventory file)
ja: インベントリー (-i、ターゲットに設定するデバイス (最後のコンマがない -i はインベントリーファイルの指定がありません))

en: the connection method (-c, the method for connecting and executing ansible)
ja: 接続方法 (-c、ansible の接続方法および実行方法)

en: the user (-u, the username for the SSH connection)
ja: ユーザー (-u、SSH 接続のユーザー名)

en: the SSH connection method (-k, please prompt for the password)
ja: SSH 接続の方法 (-k、パスワードのプロンプト有り)

en: the module (-m, the Ansible module to run, using the fully qualified collection name (FQCN))
ja: モジュール (-m、完全修飾コレクション名 (FQCN) を使用した、実行する Ansible モジュール)

en: an extra variable ( -e, in this case, setting the network OS value)
ja: 追加変数 (-e、この場合はネットワーク OS 値の設定)

en: NOTE: If you use ``ssh-agent`` with ssh keys, Ansible loads them automatically. You can omit ``-k`` flag.
ja: 注記: ssh 鍵で ``ssh-agent`` を使用すると、Ansible により自動的に読み込まれます。``-k`` フラグは省略できます。

en: If you are running Ansible in a virtual environment, you will also need to add the variable ``ansible_python_interpreter=/path/to/venv/bin/python``
ja: 仮想環境で Ansible を実行している場合は、変数 ``ansible_python_interpreter=/path/to/venv/bin/python`` を追加する必要もあります。

en: Create and run your first network Ansible Playbook
ja: 最初のネットワークの Ansible Playbook の作成および実行

en: If you want to run this command every day, you can save it in a playbook and run it with ``ansible-playbook`` instead of ``ansible``. The playbook can store a lot of the parameters you provided with flags at the command line, leaving less to type at the command line. You need two files for this - a playbook and an inventory file.
ja: このコマンドを毎日実行する場合は、Playbook に保存し、``ansible`` の代わりに ``ansible-playbook`` を使用して実行できます。Playbook には、コマンドラインでフラグを使用して指定した多くのパラメーターを保存できるため、コマンドラインで入力するパラメータが少なくなります。これを行うためには、Playbook およびインベントリーファイルの 2 つのファイルが必要です。

en: Download :download:`first_playbook.yml <sample_files/first_playbook.yml>`, which looks like this:
ja: :download:`first_playbook.yml <sample_files/first_playbook.yml>` をダウンロードします。これは、以下のようになります。

en: The playbook sets three of the seven values from the command line above: the group (``hosts: all``), the connection method (``connection: ansible.netcommon.network_cli``) and the module (in each task). With those values set in the playbook, you can omit them on the command line. The playbook also adds a second task to show the config output. When a module runs in a playbook, the output is held in memory for use by future tasks instead of written to the console. The debug task here lets you see the results in your shell.
ja: Playbook では、上記のコマンドラインの 7 つの値のうちの 3 つ、つまりグループ (``hosts: all``)、接続方法 (``connection: ansible.netcommon.network_cli``)、モジュール (各タスク内) が設定されます。これらの値を Playbook で設定すると、コマンドラインで省略できます。この Playbook には、設定出力を表示する 2 番目のタスクも追加されています。モジュールが Playbook で実行すると、出力はコンソールに書き込まれるのではなく、将来のタスクで使用するためにメモリーに保持されます。ここでデバッグタスクを実行すると、シェルで結果を確認できます。

en: Run the playbook with the command:
ja: 以下のコマンドを使用して Playbook を実行します。

en: The playbook contains one play with two tasks, and should generate output like this:
ja: Playbook には、2 つのタスクを持つプレイが 1 つ含まれており、次のような出力が生成されます。

en: Now that you can retrieve the device config, try updating it with Ansible. Download :download:`first_playbook_ext.yml <sample_files/first_playbook_ext.yml>`, which is an extended version of the first playbook:
ja: デバイス設定を取得できたので、Ansible で更新してみましょう。最初の Playbook の拡張バージョンである :download:`first_playbook_ext.yml <sample_files/first_playbook_ext.yml>` をダウンロードします。

en: The extended first playbook has four tasks in a single play. Run it with the same command you used above. The output shows you the change Ansible made to the config:
ja: 拡張された最初の Playbook には、1 つのプレイに 4 つのタスクがあります。上記のコマンドと同じコマンドを使用して実行すると、出力には、Ansible が設定に加えた変更が表示されます。

en: Gathering facts from network devices
ja: ネットワークデバイスからのファクトの収集

en: The ``gather_facts`` keyword now supports gathering network device facts in standardized key/value pairs. You can feed these network facts into further tasks to manage the network device.
ja: ``gather_facts`` キーワードは、標準化された鍵と値のペアでネットワークデバイスのファクトの収集に対応します。これらのネットワークファクトを、ネットワークデバイスを管理する追加のタスクに指定できます。

en: You can also use the new ``gather_network_resources`` parameter with the network ``*_facts`` modules (such as :ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>`) to return just a subset of the device configuration, as shown below.
ja: また、新しい ``gather_network_resources`` パラメーターを、ネットワークの ``*_facts`` モジュール (:ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>` など) とともに使用すると、以下のようにデバイス設定のサブセットのみを返すことができます。

en: The playbook returns the following interface facts:
ja: Playbook は以下のインターフェースのファクトを返します。

en: Note that this returns a subset of what is returned by just setting ``gather_subset: interfaces``.
ja: これは、``gather_subset: interfaces`` の設定で返される内容のサブセットを返すことに注意してください。

en: You can store these facts and use them directly in another task, such as with the :ref:`eos_interfaces <ansible_collections.arista.eos.eos_interfaces_module>` resource module.
ja: これらのファクトを保存し、:ref:`eos_interfaces <ansible_collections.arista.eos.eos_interfaces_module>` リソースモジュールなどの別のタスクで直接使用できます。

en: Getting Started Guide
ja: 入門ガイド

en: Network Getting Started
ja: ネットワークスタートガイド

en: Ansible collections support a wide range of vendors, device types, and actions, so you can manage your entire network with a single automation tool. With Ansible, you can:
ja: Ansible コレクションは広範なベンダー、デバイスタイプ、アクションに対応しているため、1 つの自動化ツールでネットワーク全体を管理できます。Ansible では、以下を行うことができます。

en: Automate repetitive tasks to speed routine network changes and free up your time for more strategic work
ja: 反復タスクを自動化して、ルーチンネットワークの変更を迅速化し、その時間をより戦略的な作業に割り当てます。

en: Leverage the same simple, powerful, and agentless automation tool for network tasks that operations and development use
ja: 操作と開発で使用するネットワークタスクの両方に、同一の簡単で強力なエージェントレスの自動化ツールを使用します。

en: Separate the data model (in a playbook or role) from the execution layer (via Ansible modules) to manage heterogeneous network devices
ja: 異機種環境にあるネットワークデバイスを管理するため、(Ansible モジュールにより) 実行レイヤーからデータモデル (Playbook またはロール) を分離します。

en: Benefit from community and vendor-generated sample playbooks and roles to help accelerate network automation projects
ja: ネットワーク自動化プロジェクトを加速化するコミュニティーおよびベンダーが生成したサンプルの Playbook およびロールを活用します。

en: Communicate securely with network hardware over SSH or HTTPS
ja: SSH または HTTPS を介してネットワークハードウェアとセキュアに通信します。

en: This guide is intended for network engineers using Ansible for the first time. If you understand networks but have never used Ansible, work through the guide from start to finish.
ja: このガイドは、Ansible を初めて使用するネットワークエンジニアを対象としています。ネットワークを理解していて、Ansible を使用したことがない場合は、ガイドを最初から最後まで実践してください。

en: This guide is also useful for experienced Ansible users automating network tasks for the first time. You can use Ansible commands, playbooks and modules to configure hubs, switches, routers, bridges and other network devices. But network modules are different from Linux/Unix and Windows modules, and you must understand some network-specific concepts to succeed. If you understand Ansible but have never automated a network task, start with the second section.
ja: このガイドは、ネットワークタスクを初めて自動化する経験豊富な Ansible ユーザーにも役立ちます。Ansible コマンド、Playbook、モジュールを使用して、ハブ、スイッチ、ルーター、ブリッジ、その他のネットワークデバイスを構成できます。ただし、ネットワークモジュールは Linux/Unix および Windows のモジュールとは異なり、成功するにはネットワーク固有の概念を理解する必要があります。Ansible を理解していても、ネットワークタスクを自動化したことがない場合は、2 番目のセクションから始めてください。

en: This guide introduces basic Ansible concepts and guides you through your first Ansible commands, playbooks and inventory entries.
ja: 本ガイドでは、基本的な Ansible の概念を紹介し、Ansible コマンド、Playbook、およびインベントリーエントリーを説明します。

en: Beyond the basics
ja: 中級編

en: This page introduces some concepts that help you manage your Ansible workflow with directory structure and source control. Like the Basic Concepts at the beginning of this guide, these intermediate concepts are common to all uses of Ansible.
ja: このページでは、ディレクトリー構造とソース管理を使用した Ansible ワークフローの管理に役立つ概念を紹介します。このガイドの最初の基本概念と同様に、これらの中間概念は Ansible のすべての使用に共通です。

en: A typical Ansible filetree
ja: 一般的な Ansible ファイルツリー

en: Ansible expects to find certain files in certain places. As you expand your inventory and create and run more network playbooks, keep your files organized in your working Ansible project directory like this:
ja: Ansible では、特定の場所にある特定のファイルを見つけることを想定しています。インベントリーを拡張し、ネットワークの Playbook を作成して実行する場合は、ファイルを以下のように作業用の Ansible プロジェクトディレクトリーに整理した状態にします。

en: The ``backup`` directory and the files in it get created when you run modules like ``vyos_config`` with the ``backup: yes`` parameter.
ja: ``backup`` ディレクトリーと、そのディレクトリーのファイルは、``backup: yes`` パラメーターを使用した ``vyos_config`` のモジュールを実行する際に作成されます。

en: Tracking changes to inventory and playbooks: source control with git
ja: インベントリーおよび Playbook への変更の追跡: git でのソース制御

en: As you expand your inventory, roles and playbooks, you should place your Ansible projects under source control. We recommend ``git`` for source control. ``git`` provides an audit trail, letting you track changes, roll back mistakes, view history and share the workload of managing, maintaining and expanding your Ansible ecosystem. There are plenty of tutorials and guides to using ``git`` available.
ja: インベントリー、ロール、および Playbook を拡張するときは、Ansible プロジェクトをソース管理下に置く必要があります。ソース管理には ``git`` をお勧めします。``git`` には監査証跡が用意されており、変更の追跡、失敗のロールバック、履歴の表示、Ansible エコシステムの管理、維持、拡張のワークロードの共有が可能になります。``git`` を使用するためのチュートリアルとガイドが多数用意されています。

en: Working with network connection options
ja: ネットワーク接続オプションの使用

en: Network modules can support multiple connection protocols, such as ``ansible.netcommon.network_cli``, ``ansible.netcommon.netconf``, and ``ansible.netcommon.httpapi``. These connections include some common options you can set to control how the connection to your network device behaves.
ja: ネットワークモジュールは、``ansible.netcommon.network_cli``、``ansible.netcommon.netconf``、``ansible.netcommon.httpapi`` などの複数の接続プロトコルをサポートできます。これらの接続には、ネットワークデバイスへの接続の動作を制御するために設定できる一般的なオプションがあります。

en: Common options are:
ja: 一般的なオプションは以下のとおりです。

en: ``become`` and ``become_method`` as described in :ref:`privilege_escalation`.
ja: 「:ref:`privilege_escalation`」に記載される通りに ``become`` および ``become_method``

en: ``network_os`` - set to match your network platform you are communicating with. See the :ref:`platform-specific <platform_options>` pages.
ja: ``network_os`` - 通信しているネットワークプラットフォームと一致するように設定されます。「:ref:`platform-specific <platform_options>`」ページを参照してください。

en: ``remote_user`` as described in :ref:`connection_set_user`.
ja: 「:ref:`connection_set_user`」に記載される通りに ``remote_user``

en: Timeout options - ``persistent_command_timeout``, ``persistent_connect_timeout``, and ``timeout``.
ja: タイムアウトオプション: ``persistent_command_timeout``、``persistent_connect_timeout``、および ``timeout``

en: Setting timeout options
ja: タイムアウトオプションの設定

en: When communicating with a remote device, you have control over how long Ansible maintains the connection to that device, as well as how long Ansible waits for a command to complete on that device. Each of these options can be set as variables in your playbook files, environment variables, or settings in your :ref:`ansible.cfg file <ansible_configuration_settings>`.
ja: リモートデバイスと通信する場合は、Ansible がそのデバイスへの接続を維持する時間、およびそのデバイスでコマンドが完了するまで Ansible が待機する時間を制御できます。各オプションは、Playbook ファイルの変数、環境変数、または :ref:`ansible.cfg ファイル <ansible_configuration_settings>` の設定として設定できます。

en: For example, the three options for controlling the connection timeout are as follows.
ja: たとえば、接続タイムアウトを制御する 3 つのオプションは次のとおりです。

en: Using vars (per task):
ja: vars (タスクごと) の使用:

en: Using the environment variable:
ja: 環境変数の使用:

en: Using the global configuration (in :file:`ansible.cfg`)
ja: グローバル設定の使用 (:file:`ansible.cfg`) の使用

en: See :ref:`ansible_variable_precedence` for details on the relative precedence of each of these variables. See the individual connection type to understand each option.
ja: これらの各変数の相対優先度は、「:ref:`ansible_variable_precedence`」を参照してください。各オプションについては、個別の接続タイプを参照してください。

en: How Network Automation is Different
ja: ネットワーク自動化の相違点

en: Network automation leverages the basic Ansible concepts, but there are important differences in how the network modules work. This introduction prepares you to understand the exercises in this guide.
ja: ネットワーク自動化は、基本的な Ansible の概念を利用しますが、ネットワークモジュールの動作には重要な相違点があります。本ガイドの演習を始める前に、このイントロダクションをお読みください。

en: Execution on the control node
ja: コントロールノードでの実行

en: Unlike most Ansible modules, network modules do not run on the managed nodes. From a user's point of view, network modules work like any other modules. They work with ad hoc commands, playbooks, and roles. Behind the scenes, however, network modules use a different methodology than the other (Linux/Unix and Windows) modules use. Ansible is written and executed in Python. Because the majority of network devices can not run Python, the Ansible network modules are executed on the Ansible control node, where ``ansible`` or ``ansible-playbook`` runs.
ja: ほとんどの Ansible モジュールとは異なり、ネットワークモジュールは管理ノードで実行されません。ユーザーから見ると、ネットワークモジュールは他のモジュールと同様に機能します。アドホックコマンド、Playbook およびロールを使用します。しかし、その裏では、ネットワークモジュールは他 (Linux/Unix および Windows) のモジュールとは異なる方法を使用します。Ansible は Python で記述され、実行されます。大部分のネットワークデバイスは Python を実行できないため、Ansible ネットワークモジュールは Ansible コントロールノードで実行されます (``ansible`` または ``ansible-playbook`` が実行される場所です)。

en: Network modules also use the control node as a destination for backup files, for those modules that offer a ``backup`` option. With Linux/Unix modules, where a configuration file already exists on the managed node(s), the backup file gets written by default in the same directory as the new, changed file. Network modules do not update configuration files on the managed nodes, because network configuration is not written in files. Network modules write backup files on the control node, usually in the `backup` directory under the playbook root directory.
ja: ネットワークモジュールも、``backup`` オプションを提供するモジュールのバックアップファイルの宛先としてコントロールノードを使用します。Linux/Unix モジュールでは、管理ノードに設定ファイルがすでに存在する場合に、デフォルトでは、新しい変更したファイルと同じディレクトリーにバックアップファイルが書き込まれます。ネットワーク設定はファイルに書き込まれないため、ネットワークモジュールは管理ノード上の構成ファイルを更新しません。ネットワークモジュールは、通常は Playbook のルートディレクトリーの下の `backup` ディレクトリーにあるコントロールノードにバックアップファイルを書き込みます。

en: Multiple communication protocols
ja: 複数の通信プロトコル

en: Because network modules execute on the control node instead of on the managed nodes, they can support multiple communication protocols. The communication protocol (XML over SSH, CLI over SSH, API over HTTPS) selected for each network module depends on the platform and the purpose of the module. Some network modules support only one protocol; some offer a choice. The most common protocol is CLI over SSH. You set the communication protocol with the ``ansible_connection`` variable:
ja: ネットワークモジュールは管理ノードではなくコントロールノードで実行されるため、複数の通信プロトコルをサポートできます。各ネットワークモジュールに選択される通信プロトコル (SSH での XML、SSH での CLI、HTTPS での API) は、プラットフォームと、モジュールの目的によって異なります。プロトコルを 1 つしかサポートしていないネットワークモジュールもあります。複数のプロトコルをサポートするプロトコルもあります。最も一般的なプロトコルは CLI over SSH です。``ansible_connection`` 変数を使用して通信プロトコルを設定します。

en: Value of ansible_connection
ja: ansible_connection の値

en: Protocol
ja: プロトコル

en: Requires
ja: 必須

en: Persistent?
ja: 永続的?

en: CLI over SSH
ja: SSH での CLI

en: network_os setting
ja: network_os の設定

en: yes
ja: はい

en: XML over SSH
ja: SSH での XML

en: API over HTTP/HTTPS
ja: HTTP/HTTPS での API

en: local
ja: ローカル

en: depends on provider
ja: プロバイダーによって異なる

en: provider setting
ja: プロバイダー設定

en: no
ja: いいえ

en: ``ansible.netcommon.httpapi`` deprecates ``eos_eapi`` and ``nxos_nxapi``. See :ref:`httpapi_plugins` for details and an example.
ja: ``ansible.netcommon.httpapi`` は、``eos_eapi`` および ``nxos_nxapi`` を非推奨とします。詳細と例は「:ref:`httpapi_plugins`」参照してください。

en: The ``ansible_connection: local`` has been deprecated. Please use one of the persistent connection types listed above instead. With persistent connections, you can define the hosts and credentials only once, rather than in every task. You also need to set the ``network_os`` variable for the specific network platform you are communicating with. For more details on using each connection type on various platforms, see the :ref:`platform-specific <platform_options>` pages.
ja: ``ansible_connection: local`` は非推奨になりました。代わりに、上記の永続的接続タイプのいずれかを使用してください。永続的接続では、すべてのタスクに対してではなく、ホストと認証情報を 1 回だけ定義できます。また、通信する特定のネットワークプラットフォームの ``network_os`` 変数も設定する必要があります。さまざまなプラットフォームでの各接続タイプの使用の詳細は、「:ref:`platform-specific <platform_options>`」を参照してください。

en: Collections organized by network platform
ja: ネットワークプラットフォーム別に整理されたコレクション

en: A network platform is a set of network devices with a common operating system that can be managed by an Ansible collection, for example:
ja: ネットワークプラットフォームは、Ansible コレクションで管理できる共通のオペレーティングシステムを備えたネットワークデバイスセットです。以下に例を示します。

en: Cisco: `cisco.ios <https://galaxy.ansible.com/cisco/ios>`_, `cisco.iosxr <https://galaxy.ansible.com/cisco/iosxr>`_, `cisco.nxos <https://galaxy.ansible.com/cisco/nxos>`_
ja: Cisco: `cisco.ios <https://galaxy.ansible.com/cisco/ios>`_、`cisco.iosxr <https://galaxy.ansible.com/cisco/iosxr>`_、`cisco.nxos <https://galaxy.ansible.com/cisco/nxos>`_

en: All modules within a network platform share certain requirements. Some network platforms have specific differences - see the :ref:`platform-specific <platform_options>` documentation for details.
ja: ネットワークプラットフォーム内のすべてのモジュールは特定の要件を共有します。ネットワークプラットフォームによっては、特定の相違点があります。詳細は、:ref:`platform-specific <platform_options>` ドキュメントを参照してください。

en: Privilege Escalation: ``enable`` mode, ``become``, and ``authorize``
ja: 特権エスカレーション: ``enable`` モード、``become``、および ``authorize``

en: Several network platforms support privilege escalation, where certain tasks must be done by a privileged user. On network devices this is called the ``enable`` mode (the equivalent of ``sudo`` in \*nix administration). Ansible network modules offer privilege escalation for those network devices that support it. For details of which platforms support ``enable`` mode, with examples of how to use it, see the :ref:`platform-specific <platform_options>` documentation.
ja: 一部のネットワークプラットフォームでは特権エスカレーションがサポートされており、特権を持つユーザーが特定のタスクを実行する必要があります。ネットワークデバイスでは、これを ``enable`` モードと呼びます (\*nix 管理における ``sudo`` と同等)。Ansible ネットワークモジュールは、それをサポートするネットワークデバイスに特権エスカレーションを提供します。``enable`` モードをサポートプラットフォームとその使用例については、:ref:`platform-specific <platform_options>` ドキュメントを参照してください。

en: Using ``become`` for privilege escalation
ja: 権限昇格に ``become`` を使用

en: Use the top-level Ansible parameter ``become: yes`` with ``become_method: enable`` to run a task, play, or playbook with escalated privileges on any network platform that supports privilege escalation. You must use either ``connection: network_cli`` or ``connection: httpapi`` with ``become: yes`` with ``become_method: enable``. If you are using ``network_cli`` to connect Ansible to your network devices, a ``group_vars`` file would look like:
ja: 特権昇格をサポートする任意のネットワークプラットフォームで、昇格された特権を使用してタスク、プレイ、または Playbook を実行するには、``become_method: enable`` の Ansible 最上位パラメーター ``become: yes`` を使用します。``connection: network_cli`` または ``connection: httpapi`` を、``become: yes`` と ``become_method: enable`` とともに使用する必要があります。``network_cli`` を使用して Ansible をネットワークデバイスに接続している場合、``group_vars`` ファイルは次のようになります。

en: For more information, see :ref:`Become and Networks<become_network>`
ja: 詳細情報は、「:ref:`Become およびネットワーク<become_network>`」を参照してください。

en: Resources and next steps
ja: リソースと次のステップ

en: Documents
ja: ドキュメント

en: Read more about Ansible for Network Automation:
ja: ネットワーク自動化での Ansible の詳細は、次を参照してください。

en: Network Automation on the `Ansible website <https://www.ansible.com/overview/networking>`_
ja: `Ansible Web サイト <https://www.ansible.com/overview/networking>`_ 上のネットワーク自動化

en: Ansible Network `Blog posts <https://www.ansible.com/blog/topic/networks>`_
ja: Ansible ネットワークの `ブログ投稿 <https://www.ansible.com/blog/topic/networks>`_

en: Events (on video and in person)
ja: イベント (ビデオおよび個人)

en: All sessions at Ansible events are recorded and include many Network-related topics (use Filter by Category to view only Network topics). You can also join us for future events in your area. See:
ja: Ansible イベントにおけるセッションはすべて録画されており、ネットワーク関連のトピックが多数含まれています (「Filter by Category」を使用して、ネットワークトピックのみを表示します)。また、お住まいの地域で今後開催されるイベントにもご参加いただけます。以下を参照してください。

en: `Recorded AnsibleFests <https://www.ansible.com/resources/videos/ansiblefest>`_
ja: `AnsibleFests (録画) <https://www.ansible.com/resources/videos/ansiblefest>`_

en: `Recorded AnsibleAutomates <https://www.ansible.com/resources/webinars-training>`_
ja: `AnsibleAutomates (録画) <https://www.ansible.com/resources/webinars-training>`_

en: `Upcoming Ansible Events <https://www.ansible.com/community/events>`_ page.
ja: `今後の Ansible イベント <https://www.ansible.com/community/events>`_ ページ。

en: GitHub repos
ja: GitHub リポジトリー

en: Ansible hosts module code, examples, demonstrations, and other content on GitHub. Anyone with a GitHub account is able to create Pull Requests (PRs) or issues on these repos:
ja: Ansible では、モジュールのコード、サンプル、デモンストレーション、その他のコンテンツを GitHub で公開しています。GitHub のアカウントをお持ちの方は、これらのリポジトリーにプル要求 (PR) や問題を作成することができます。

en: `Network-Automation <https://github.com/network-automation>`_ is an open community for all things network automation. Have an idea, some playbooks, or roles to share? Email ansible-network@redhat.com and we will add you as a contributor to the repository.
ja: `Network-Automation <https://github.com/network-automation>`_ は、ネットワーク自動化に関するあらゆることを扱うオープンコミュニティーです。アイディア、Playbook、またはロールを共有しませんか。ansible-network@redhat.com にメールでお問い合わせいただければ、リポジトリーに貢献者として追加されます。

en: `Ansible collections <https://github.com/ansible-collections>`_ is the main repository for Ansible-maintained and community collections, including collections for network devices.
ja: `Ansible コレクション <https://github.com/ansible-collections>`_ は、Ansible が管理しているコレクションおよびコミュニティーコレクションの主なリポジトリーです。これにはネットワークデバイスのコレクションが含まれます。

en: IRC and Slack
ja: IRC および Slack

en: Join us on:
ja: 以下に参加してください。

en: IRC Channel - ``#ansible-network`` on `irc.libera.chat <https://libera.chat/>`_
ja: IRC チャンネル - `irc.libera.chat <https://libera.chat/>`_ の ``#ansible-network``

en: Use Ansible network roles
ja: Ansible ネットワークロールの使用

en: Roles are sets of Ansible defaults, files, tasks, templates, variables, and other Ansible components that work together. As you saw on :ref:`first_network_playbook`, moving from a command to a playbook makes it easy to run multiple tasks and repeat the same tasks in the same order. Moving from a playbook to a role makes it even easier to reuse and share your ordered tasks. You can look at :ref:`Ansible Galaxy <ansible_galaxy>`, which lets you share your roles and use others' roles, either directly or as inspiration.
ja: ロールは、Ansible のデフォルト、ファイル、タスク、テンプレート、変数、およびその他の Ansible コンポーネントのセットで、連携して動作します。:ref:`first_network_playbook` でこれまで見てきたように、コマンドから Playbook に移動すると、複数のタスクを簡単に実行し、同じタスクを同じ順序で繰り返すことができます。Playbook からロールに移動すると、注文したタスクの再利用と共有がさらに簡単になります。:ref:`Ansible Galaxy <ansible_galaxy>` では、自分のロールを共有したり、他の人のロールを直接またはインスピレーションとして使用したりできます。

en: Understanding roles
ja: ロールについて

en: So what exactly is a role, and why should you care? Ansible roles are basically playbooks broken up into a known file structure. Moving to roles from a playbook makes sharing, reading, and updating your Ansible workflow easier. Users can write their own roles. So for example, you don't have to write your own DNS playbook. Instead, you specify a DNS server and a role to configure it for you.
ja: では、ロールとは正確には何なのか、そしてなぜそれが必要なのでしょうか。Ansible ロールは基本的に、既知のファイル構造に分割された Playbook です。Playbook からロールに移動することで、Ansible ワークフローの共有、読み取り、および更新が簡単になります。ユーザーは独自のロールを作成できます。たとえば、独自の DNS Playbook を作成する必要はありません。代わりに、DNS サーバーと、DNS サーバーを構成するロールを指定します。

en: To simplify your workflow even further, the Ansible Network team has written a series of roles for common network use cases. Using these roles means you don't have to reinvent the wheel. Instead of writing and maintaining your own ``create_vlan`` playbooks or roles, you can concentrate on designing, codifying and maintaining the parser templates that describe your network topologies and inventory, and let Ansible's network roles do the work. See the `network-related roles <https://galaxy.ansible.com/ansible-network>`_ on Ansible Galaxy.
ja: ワークフローをさらに単純化するために、Ansible Network チームは一般的なネットワークのユースケースのための一連のロールを作成しました。これらのロールを使用すると、車輪を再発明する必要がなくなります。独自の ``create_vlan`` Playbook やロールを作成して管理する代わりに、Ansible のネットワークロールにその作業を任せることで、ネットワークトポロジーやインベントリーを記述するパーサーテンプレートの設計、コード化、および管理に集中することができます。Ansible Galaxyの「`ネットワーク関連のロール <https://galaxy.ansible.com/ansible-network>`_」を見てください。

en: A sample DNS playbook
ja: DNS Playbook のサンプル

en: To demonstrate the concept of what a role is, the example ``playbook.yml`` below is a single YAML file containing a two-task playbook.  This Ansible Playbook configures the hostname on a Cisco IOS XE device, then it configures the DNS (domain name system) servers.
ja: ロールの概念を説明するために、下記の例 ``playbook.yml`` は 2 つのタスクの Playbook を含む 1 つの YAML ファイルです。この Ansible Playbook は、Cisco IOS XE デバイスでホスト名を設定してから、DNS (ドメインネームシステム) サーバーを設定します。

en: If you run this playbook using the ``ansible-playbook`` command, you'll see the output below.  This example used ``-l`` option to limit the playbook to only executing on the **rtr1** node.
ja: ``ansible-playbook`` コマンドを使用してこの Playbook を実行する場合は、以下の出力が表示されます。この例では、``-l`` オプションを使用して Playbook を **rtr1** ノード上でのみ実行するように制限しています。

en: This playbook configured the hostname and DNS servers.  You can verify that configuration on the Cisco IOS XE **rtr1** router:
ja: この Playbook はホスト名および DNS サーバーを設定し、Cisco IOS XE **rtr1** ルーターの設定を確認できます。

en: Convert the playbook into a role
ja: Playbook のロールへの変換

en: The next step is to convert this playbook into a reusable role. You can create the directory structure manually, or you can use ``ansible-galaxy init`` to create the standard framework for a role.
ja: 次の手順では、この Playbook を再利用可能なロールに変換します。ディレクトリー構造を手動で作成するか、``ansible-galaxy init`` を使用してロールの標準フレームワークを作成できます。

en: This first demonstration uses only the **tasks** and **vars** directories.  The directory structure would look as follows:
ja: この最初のデモンストレーションは **tasks** ディレクトリーおよび **vars** ディレクトリーのみを使用します。ディレクトリー構造は以下のようになります。

en: Next, move the content of the ``vars`` and ``tasks`` sections from the original Ansible Playbook into the role. First, move the two tasks into the ``tasks/main.yml`` file:
ja: 次に、元の Ansible Playbook から ``vars`` セクションおよび ``tasks`` セクションの内容をロールに移動します。まず、2 つのタスクを ``tasks/main.yml`` ファイルに移動します。

en: Next, move the variables into the ``vars/main.yml`` file:
ja: 次に、変数を ``vars/main.yml`` ファイルに移動します。

en: Finally, modify the original Ansible Playbook to remove the ``tasks`` and ``vars`` sections and add the keyword ``roles``  with the name of the role, in this case ``system-demo``.  You'll have this playbook:
ja: 最後に、元の Ansible Playbook を変更して ``tasks`` セクションおよび ``vars`` セクションを削除し、ロールの名前 (ここでは ``system-demo``) でキーワード ``roles`` を追加します。これで、Playbook が完成します。

en: To summarize, this demonstration now has a total of three directories and three YAML files.  There is the ``system-demo`` folder, which represents the role.  This ``system-demo`` contains two folders, ``tasks`` and ``vars``.  There is a ``main.yml`` is each respective folder.  The ``vars/main.yml`` contains the variables from ``playbook.yml``.  The ``tasks/main.yml`` contains the tasks from ``playbook.yml``.  The ``playbook.yml`` file has been modified to call the role rather than specifying vars and tasks directly.  Here is a tree of the current working directory:
ja: 要約すると、このデモには合計 3 つのディレクトリーと 3 つの YAML ファイルがあります。ロールを表す ``system-demo`` ディレクトリーがあります。この ``system-demo`` には、``tasks`` および ``vars`` の 2 つのディレクトリーが含まれています。各ディレクトリーに ``main.yml`` があります。``vars/main.yml`` には、``playbook.yml`` の変数が含まれます。``tasks/main.yml`` には、``playbook.yml`` のタスクが含まれます。``playbook.yml`` ファイルは、変数とタスクを直接指定するのではなく、ロールを呼び出すように変更されています。現在の作業ディレクトリーのツリーを次に示します。

en: Running the playbook results in identical behavior with slightly different output:
ja: Playbook を実行すると、同じ動作で、出力が若干異なります。

en: As seen above each task is now prepended with the role name, in this case ``system-demo``.  When running a playbook that contains several roles, this will help pinpoint where a task is being called from.  This playbook returned ``ok`` instead of ``changed`` because it has identical behavior for the single file playbook we started from.
ja: 上記のように、各タスクの先頭にロール名が付加されます (``system-demo`` の場合)。複数のロールを含む Playbook を実行する場合、タスクの呼び出し元を特定するのに役立ちます。このPlaybook は、``changed`` ではなく ``ok`` を返しますが、これは、開始した単一ファイルの Playbook と同じ動作をするためです。

en: As before, the playbook will generate the following configuration on a Cisco IOS-XE router:
ja: 前述のように、Playbook は Cisco IOS-XE ルーターで以下の設定を生成します。

en: This is why Ansible roles can be simply thought of as deconstructed playbooks. They are simple, effective and reusable.  Now another user can simply include the ``system-demo`` role instead of having to create a custom "hard coded" playbook.
ja: このため、Ansible ロールは、簡単に言えば、分解された Playbook と考えることができます。ロールは、シンプルで、効果的で、再利用可能です。これで、別のユーザーがカスタムの「ハードコーディングされた」Playbook を作成する代わりに、``system-demo`` ロールを含めるだけで十分となります。

en: Variable precedence
ja: 変数の優先順位

en: What if you want to change the DNS servers?  You aren't expected to change the ``vars/main.yml`` within the role structure. Ansible has many places where you can specify variables for a given play. See :ref:`playbooks_variables` for details on variables and precedence. There are actually 21 places to put variables.  While this list can seem overwhelming at first glance, the vast majority of use cases only involve knowing the spot for variables of least precedence and how to pass variables with most precedence. See :ref:`ansible_variable_precedence` for more guidance on where you should put variables.
ja: DNS サーバーを変更する場合はどうすればよいですか。ロール構造内の ``vars/main.yml`` を変更する必要はありません。Ansible には、特定のプレイの変数を指定できる場所が多数あります。変数と優先順位の詳細は、「:ref:`playbooks_variables`」を参照してください。変数を置く場所は実際には 21 箇所あります。これは一見圧倒されるような数ですが、大半のユースケースでは、優先順位が最も低い変数の場所と、最も優先順位の高い変数を渡す方法を知るだけですみます。変数をどこに置くべきかは、「:ref:`ansible_variable_precedence`」を参照してください。

en: Lowest precedence
ja: 最も低い優先順位

en: The lowest precedence is the ``defaults`` directory within a role.  This means all the other 20 locations you could potentially specify the variable will all take higher precedence than ``defaults``, no matter what.  To immediately give the vars from the ``system-demo`` role the least precedence, rename the ``vars`` directory to ``defaults``.
ja: 最も低い優先順位は、ロール内の ``defaults`` ディレクトリーです。つまり、変数を指定できる可能性のある他の 20 箇所はすべて、``defaults`` より優先されます。``system-demo`` ロールの変数の優先順位を直ちに最も低くするには、``vars`` ディレクトリーの名前を ``defaults`` に変更します。

en: Add a new ``vars`` section to the playbook to override the default behavior (where the variable ``dns`` is set to 8.8.8.8 and 8.8.4.4).  For this demonstration, set ``dns`` to 1.1.1.1, so ``playbook.yml`` becomes:
ja: デフォルトの動作を上書きするために、Playbook に新しい ``vars`` セクションを追加します (ここでは、``dns`` 変数が 8.8.8.8 および 8.8.4.4 に設定されています)。このデモでは、``dns`` を 1.1.1.1 に設定するため、``playbook.yml`` は次のようになります。

en: Run this updated playbook on **rtr2**:
ja: 更新した Playbook を **rtr2** で実行します。

en: The configuration on the **rtr2** Cisco router will look as follows:
ja: **rtr2** Cisco ルーターの設定は以下のようになります。

en: The variable configured in the playbook now has precedence over the ``defaults`` directory.  In fact, any other spot you configure variables would win over the values in the ``defaults`` directory.
ja: Playbook に設定した変数は、``defaults`` ディレクトリーよりも優先されます。実際には、変数に設定したその他のスポットは、``defaults`` ディレクトリーの値よりも優先されます。

en: Highest precedence
ja: 最も高い優先順位

en: Specifying variables in the ``defaults`` directory within a role will always take the lowest precedence, while specifying ``vars`` as extra vars with the ``-e`` or ``--extra-vars=`` will always take the highest precedence, no matter what.  Re-running the playbook with the ``-e`` option overrides both the ``defaults`` directory (8.8.4.4 and 8.8.8.8) as well as the newly created ``vars`` within the playbook that contains the 1.1.1.1 dns server.
ja: ロール内の ``defaults`` ディレクトリーに変数を指定すると、常に優先順位が最も低くなりますが、``-e`` または ``--extra-vars=`` を使用して追加変数として ``vars`` を指定すると、優先順位が最も高くなります。``-e`` オプションを指定して Playbook を再実行すると、``defaults`` ディレクトリー (8.8.4.4 および 8.8.8.8) だけでなく、1.1.1.1 dns サーバーを含む Playbook 内に新しく作成された ``vars`` も上書きされます。

en: The result on the Cisco IOS XE router will only contain the highest precedence setting of 192.168.1.1:
ja: Cisco IOS XE ルーターの結果には、優先順位の最も高い 192.168.1.1 設定のみが含まれます。

en: How is this useful?  Why should you care?  Extra vars are commonly used by network operators to override defaults.  A powerful example of this is with Red Hat Ansible Tower and the Survey feature.  It is possible through the web UI to prompt a network operator to fill out parameters with a Web form.  This can be really simple for non-technical playbook writers to execute a playbook using their Web browser. See `Ansible Tower Job Template Surveys <https://docs.ansible.com/ansible-tower/latest/html/userguide/workflow_templates.html#surveys>`_ for more details.
ja: これはどのように役立つのでしょうか。なぜ気にする必要があるのでしょうか。ネットワークオペレーターは通常、追加の変数を使用してデフォルトを上書きします。その良い例は、Red Hat Ansible Tower と Survey 機能です。Web UI を使用して、ネットワークオペレーターに Web フォームでパラメーターの入力を求めることができます。これは、技術に詳しくない Playbook 作成者が Web ブラウザーを使用して Playbook を実行する場合に非常に簡単です。詳細は、「`Ansible Tower ジョブテンプレートサーベイ <https://docs.ansible.com/ansible-tower/latest/html/userguide/workflow_templates.html#surveys>`_」を参照してください。

en: Update an installed role
ja: インストールされたロールの更新

en: The Ansible Galaxy page for a role lists all available versions. To update a locally installed role to a new or different version, use the ``ansible-galaxy install`` command with the version and ``--force`` option. You may also need to manually update any dependent roles to support this version. See the role **Read Me** tab in Galaxy for dependent role minimum version requirements.
ja: ロールの Ansible Galaxy ページには、使用可能なすべてのバージョンが一覧表示されます。ローカルにインストールされたロールを新しいバージョンまたは別のバージョンに更新するには、``ansible-galaxy install`` コマンドにバージョンおよび ``--force`` オプションを指定して使用します。また、このバージョンをサポートするために、依存ロールを手動で更新しないといけない場合もあります。依存ロールの最小バージョン要件については、Galaxy のロールの「Read Me」タブを参照してください。

en: `Ansible Galaxy documentation <https://galaxy.ansible.com/docs/>`_
ja: `Ansible Galaxy ドキュメント <https://galaxy.ansible.com/docs/>`_

en: Ansible Galaxy user guide
ja: Ansible Galaxy ユーザーガイド

en: Ansible for Network Automation
ja: ネットワークの自動化における Ansible

en: Ansible Network modules extend the benefits of simple, powerful, agentless automation to network administrators and teams. Ansible Network modules can configure your network stack, test and validate existing network state, and discover and correct network configuration drift.
ja: Ansible Network モジュールは、シンプルで強力なエージェントレス自動化の利点をネットワーク管理者とチームに拡張します。Ansible Network モジュールは、ネットワークスタックを構成し、既存のネットワーク状態をテストおよび検証し、ネットワーク構成のドリフトを検出して修正できます。

en: If you're new to Ansible, or new to using Ansible for network management, start with :ref:`network_getting_started`. If you are already familiar with network automation with Ansible, see :ref:`network_advanced`.
ja: Ansible を初めて使用する場合や、ネットワーク管理に Ansible を初めて使用する場合は、:ref:`network_getting_started` から開始します。Ansible とのネットワーク自動化に精通している場合は、「:ref:`network_advanced`」を参照してください。

en: For documentation on using a particular network module, consult the :ref:`list of all network modules<network_modules>`. Network modules for various hardware are supported by different teams including the hardware vendors themselves, volunteers from the Ansible community, and the Ansible Network Team.
ja: 特定のネットワークモジュールの使用に関するドキュメントについては、「:ref:`ネットワークモジュールの一覧<network_modules>`」を参照してください。さまざまなハードウェアのネットワークモジュールが、ハードウェアベンダー自体、Ansible コミュニティーのボランティア、Ansible ネットワークチームなど、さまざまなチームにサポートされています。

en: Parsing semi-structured text with Ansible
ja: Ansible を使用した半構造化テキストの解析

en: The :ref:`cli_parse <ansible_collections.ansible.netcommon.cli_parse_module>` module parses semi-structured data such as network configurations into structured data to allow programmatic use of the data from that device. You can pull information from a network device and update a CMDB in one playbook. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on.
ja: :ref:`cli_parse <ansible_collections.ansible.netcommon.cli_parse_module>` モジュールは、ネットワーク構成などの半構造化データを構造化データに解析して、そのデバイスからのデータをプログラムで使用できるようにします。ネットワークデバイスから情報を取得し、1 つの Playbook で CMDB を更新できます。ユースケースには、自動トラブルシューティング、動的ドキュメントの作成、IPAM (IPアドレス管理) ツールの更新などがあります。

en: Understanding the CLI parser
ja: CLI パーサーについて

en: The `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ collection version 1.2.0 or later  includes the :ref:`cli_parse <ansible_collections.ansible.netcommon.cli_parse_module>` module that can run CLI commands and parse the semi-structured text output. You can use the ``cli_parse`` module on a device, host, or platform that only supports a command-line interface and the commands issued return semi-structured text. The ``cli_parse`` module can either run a CLI command on a device and return a parsed result or can simply parse any text document. The ``cli_parse`` module includes cli_parser plugins to interface with a variety of parsing engines.
ja: `ansible.netcommon <https://galaxy.ansible.com/ansible/netcommon>`_ コレクションバージョン 1.2.0 以降には、CLI コマンドを実行し、半構造化テキスト出力を解析できる :ref:`cli_parse <ansible_collections.ansible.netcommon.cli_parse_module>` モジュールが含まれています。コマンドラインインタフェースのみをサポートするデバイス、ホスト、またはプラットフォームで ``cli_parse`` モジュールを使用でき、実行したコマンドは半構造化テキストを返します。``cli_parse`` モジュールは、デバイス上で CLI コマンドを実行して解析結果を返すことも、単純にテキストドキュメントを解析することもできます。``cli_parse`` モジュールには、さまざまな解析エンジンとのインタフェースとなる cli_parser プラグインが含まれています。

en: Why parse the text?
ja: テキストを解析する理由

en: Parsing semi-structured data such as network configurations into structured data allows programmatic use of the data from that device. Use cases include automated troubleshooting, creating dynamic documentation, updating IPAM (IP address management) tools and so on. You may prefer to do this with Ansible natively to take advantage of native Ansible constructs such as:
ja: ネットワーク構成などの半構造化データを構造化データに解析すると、そのデバイスのデータをプログラムで使用できます。ユースケースには、自動トラブルシューティング、動的ドキュメントの作成、IPAM (IPアドレス管理) ツールの更新などがあります。このような作業は、Ansible でネイティブに行う方が、以下のような Ansible のネイティブな構成を活用できるかもしれません。

en: The ``when`` clause to conditionally run other tasks or roles
ja: 他のタスクまたはロールを条件的に実行する ``when`` 句

en: The ``assert`` module to check configuration and operational state compliance
ja: 設定と運用状態コンプライアンスを確認するための ``assert`` モジュール

en: The ``template`` module to generate reports about configuration and operational state information
ja: 設定および運用の状態情報に関するレポートを生成する ``template`` モジュール

en: Templates and ``command`` or ``config`` modules to generate host, device, or platform commands or configuration
ja: ホスト、デバイス、またはプラットフォームコマンドまたは設定を生成するテンプレートおよび ``command`` モジュールまたは ``config`` モジュール

en: The current platform ``facts`` modules to supplement native facts information
ja: ネイティブファクト情報を補足する現在のプラットフォームの ``facts`` モジュール

en: By parsing semi-structured text into Ansible native data structures, you can take full advantage of Ansible's network modules and plugins.
ja: 半構造化テキストを Ansible のネイティブデータ構造に解析することで、Ansible のネットワークモジュールおよびプラグインを完全に活用できます。

en: When not to parse the text
ja: テキストを解析しない場合

en: You should not parse semi-structured text when:
ja: 以下の場合は、半構造化されたテキストを解析しないでください。

en: The device, host, or platform has a RESTAPI and returns JSON.
ja: デバイス、ホスト、またはプラットフォームには RESTAPI があり、JSON を返します。

en: Existing Ansible facts modules already return the desired data.
ja: 既存の Ansible ファクトモジュールは、すでに必要なデータを返しています。

en: Ansible network resource modules exist for configuration management of the device and resource.
ja: デバイスおよびリソースの設定管理には、Ansible ネットワークリソースモジュールがあります。

en: Parsing the CLI
ja: CLI の解析

en: The ``cli_parse`` module includes the following cli_parsing plugins:
ja: ``cli_parse`` モジュールには、以下の cli_parsing プラグインが含まれます。

en: The native parsing engine built into Ansible and requires no addition python libraries
ja: Ansible に組み込まれたネイティブの解析エンジンで、Python ライブラリーを追加する必要はありません。

en: Convert XML to an Ansible native data structure
ja: XML の Ansible ネイティブデータ構造への変換

en: A python module which implements a template based state machine for parsing semi-formatted text
ja: 半フォーマット化テキストを解析するためにテンプレートベースの状態マシンを実装する Python モジュール

en: Predefined ``textfsm`` templates packages supporting a variety of platforms and commands
ja: さまざまなプラットフォームおよびコマンドをサポートする事前定義された ``textfsm`` テンプレートパッケージ

en: A library for semi-structured text parsing using templates, with added capabilities to simplify the process
ja: 処理を簡略化する機能が追加されている、テンプレートを利用した半構造化テキストの解析用ライブラリー

en: Uses the parsers included with the Cisco Test Automation & Validation Solution
ja: Cisco Test Automation & Validation Solution に含まれるパーサーを使用します。

en: A python module that converts the output of dozens of popular Linux/UNIX/macOS/Windows commands and file types to python dictionaries or lists of dictionaries. Note: this filter plugin can be found in the ``community.general`` collection.
ja: 多数の一般的な Linux/UNIX/macOS/Windows コマンドとファイルタイプの出力を python ディクショナリーまたはディクショナリーの一覧に変換する Python モジュール。このフィルタープラグインは ``community.general`` コレクションにあります。

en: Converts JSON output at the CLI to an Ansible native data structure
ja: CLI での JSON 出力を Ansible ネイティブデータ構造に変換

en: Although Ansible contains a number of plugins that can convert XML to Ansible native data structures, the ``cli_parse`` module runs the command on devices that return XML and returns the converted data in a single task.
ja: Ansible には、XML を Ansible のネイティブデータ構造に変換できる多数のプラグインが含まれていますが、``cli_parse`` モジュールは XML を返すデバイスでコマンドを実行し、変換されたデータを 1 つのタスクで返します。

en: Because ``cli_parse`` uses a plugin based architecture, it can use additional parsing engines from any Ansible collection.
ja: ``cli_parse`` はプラグインベースのアーキテクチャーを使用するため、任意の Ansible コレクションから追加の解析エンジンを使用できます。

en: The ``ansible.netcommon.native``  and ``ansible.netcommon.json`` parsing engines are fully supported with a Red Hat Ansible Automation Platform subscription. Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates``, pyATS, ``textfsm``, ``xmltodict``, public APIs as documented.
ja: 解析エンジン ``ansible.netcommon.native`` および ``ansible.netcommon.json`` は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。Red Hat Ansible Automation Platform サブスクリプションのサポートは、ドキュメントに記載されているように、``ntc_templates``、pyATS、``textfsm``、``xmltodict``、パブリック APIの使用に限定されます。

en: Parsing with the native parsing engine
ja: ネイティブ解析エンジンを使用した解析

en: The native parsing engine is included with the ``cli_parse`` module. It uses data captured using regular expressions to populate the parsed data structure. The native parsing engine requires a YAML template file to parse the command output.
ja: ネイティブ解析エンジンは ``cli_parse`` モジュールに含まれています。正規表現を使用して取得されたデータを使用して、解析されたデータ構造を生成します。ネイティブ解析エンジンでは、コマンド出力を解析するために YAML テンプレートファイルが必要です。

en: Networking example
ja: ネットワークの例

en: This example uses the output of a network device command and applies a native template to produce an output in Ansible structured data format.
ja: この例では、ネットワークデバイスコマンドの出力を使用し、ネイティブテンプレートを適用して Ansible 構造のデータ形式で出力を生成します。

en: The ``show interface`` command output from the network device looks as follows:
ja: ネットワークデバイスからの ``show interface`` コマンドの出力は以下のようになります。

en: Create the native template to match this output and store it as ``templates/nxos_show_interface.yaml``:
ja: この出力に一致するネイティブテンプレートを作成し、これを ``templates/nxos_show_interface.yaml`` として保存します。

en: This native parser template is structured as a list of parsers, each containing the following key-value pairs:
ja: このネイティブパーサーテンプレートはパーサーのリストとして構成され、それぞれに以下のキーと値のペアが含まれます。

en: ``example`` - An example line of the text line to be parsed
ja: ``example`` - 解析対象となるテキスト行の一例

en: ``getval`` - A regular expression using named capture groups to store the extracted data
ja: ``getval`` - 展開したデータを保存するために名前付きキャプチャーグループを使用した正規表現

en: ``result`` - A data tree, populated as a template, from the parsed data
ja: ``result`` - 解析されたデータからテンプレートとして生成されたデータツリー

en: ``shared`` - (optional) The shared key makes the parsed values available to the rest of the parser entries until matched again.
ja: ``shared`` - (任意) 共有キーは、再一致するまで、残りのパーサーエントリーに解析された値を利用できるようにします。

en: The following example task uses ``cli_parse`` with the native parser and the example template above to parse the ``show interface`` command from a Cisco NXOS device:
ja: 以下のタスク例では、ネイティブパーサーで ``cli_parse`` と上記のテンプレートのサンプルを使用して、Cisco NXOS デバイスからの ``show interface`` コマンドを解析します。

en: Taking a deeper dive into this task:
ja: このタスクをより深く掘り下げます。

en: The ``command`` option provides the command you want to run on the device or host. Alternately, you can provide text from a previous command with the ``text`` option instead.
ja: ``command`` オプションは、デバイスまたはホストで実行するコマンドを提供します。代わりに、``text`` オプションを指定して、前のコマンドのテキストを指定することもできます。

en: The ``parser`` option provides information specific to the parser engine.
ja: ``parser`` オプションは、パーサーエンジンに固有の情報を提供します。

en: The ``name`` suboption provides the fully qualified collection name (FQCN) of the parsing engine (``ansible.netcommon.native``).
ja: ``name`` サブオプションは、解析エンジン (``ansible.netcommon.native``) の完全修飾コレクション名 (FQCN) を提供します。

en: The ``cli_parse`` module, by default, looks for the template in the templates directory as ``{{ short_os }}_{{ command }}.yaml``.
ja: デフォルトでは、``cli_parse`` モジュールは、templates ディレクトリーで ``{{ short_os }}_{{ command }}.yaml`` と指定してテンプレートを検索します。

en: The ``short_os`` in the template filename is derived from either the host ``ansible_network_os`` or ``ansible_distribution``.
ja: テンプレートファイル名の ``short_os`` は、ホストの ``ansible_network_os`` または ``ansible_distribution`` から派生します。

en: Spaces in the network or host command are replace with ``_`` in the ``command`` portion of the template filename. In this example, the ``show interfaces`` network CLI command becomes ``show_interfaces`` in the filename.
ja: network または host コマンドのスペースは、テンプレートファイル名の ``command`` 部分にある ``_`` に置き換えます。この例では、``show interfaces`` network CLI コマンドはファイル名の ``show_interfaces`` になります。

en: ``ansible.netcommon.native`` parsing engine is fully supported with a Red Hat Ansible Automation Platform subscription.
ja: ``ansible.netcommon.native`` エンジンの解析は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。

en: Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the device based on the now-structured data returned from ``cli_parse``:
ja: このタスクの最後で、``set_fact`` オプションは、``interfaces`` から返された現在構造化されているデータに基づいて、デバイスに以下の ``cli_parse`` ファクトを設定します。

en: Linux example
ja: Linux の例

en: You can also use the native parser to run commands and parse output from Linux hosts.
ja: ネイティブパーサーを使用してコマンドを実行し、Linux ホストからの出力を解析することもできます。

en: The output of a sample Linux  command (``ip addr show``) looks as follows:
ja: Linux コマンドの出力例 (``ip addr show``) は以下のようになります。

en: Create the native template to match this output and store it as ``templates/fedora_ip_addr_show.yaml``:
ja: この出力に一致するネイティブテンプレートを作成し、これを ``templates/fedora_ip_addr_show.yaml`` として保存します。

en: The ``shared`` key in the parser template allows the interface name to be used in subsequent parser entries. The use of examples and free-spacing mode with the regular expressions makes the template easier to read.
ja: パーサーテンプレートの ``shared`` キーを使用すると、インターフェース名を後続のパーサーエントリーで使用できます。正規表現で例とフリースペースモードを使用すると、テンプレートが読みやすくなります。

en: The following example task uses ``cli_parse`` with the native parser and the example template above to parse the Linux output:
ja: 以下のタスク例では、ネイティブパーサーのある ``cli_parse`` と、上記のサンプルテンプレートを使用して Linux の出力を解析します。

en: This task assumes you previously gathered facts to determine the ``ansible_distribution`` needed to locate the template. Alternately, you could provide the path in the  ``parser/template_path`` option.
ja: このタスクでは、以前にファクトを収集してテンプレートを見つけるのに必要な ``ansible_distribution`` を決定することを仮定しています。あるいは、``parser/template_path`` オプションでパスを指定することもできます。

en: Lastly in this task, the ``set_fact`` option sets the following ``interfaces`` fact for the host, based on the now-structured data returned from ``cli_parse``:
ja: このタスクの最後で、``set_fact`` オプションは、``interfaces`` から返された現在構造化されているデータに基づいて、ホストに以下の ``cli_parse`` ファクトを設定します。

en: Parsing JSON
ja: JSON の解析

en: Although Ansible will natively convert serialized JSON to Ansible native data when recognized, you can also use the ``cli_parse`` module for this conversion.
ja: Ansible は、認識時にシリアライズされた JSON を Ansible ネイティブデータに変換しますが、この変換に ``cli_parse`` モジュールを使用することもできます。

en: Example task:
ja: タスクの例:

en: The ``show interface | json`` command is issued on the device.
ja: ``show interface | json`` コマンドはデバイスで発行されます。

en: The output is set as the ``interfaces`` fact for the device.
ja: この出力は、デバイスの ``interfaces`` ファクトとして設定されます。

en: JSON support is provided primarily for playbook consistency.
ja: JSON のサポートは、主に Playbook の一貫性のために提供されています。

en: The use of ``ansible.netcommon.json`` is fully supported with a Red Hat Ansible Automation Platform subscription
ja: ``ansible.netcommon.json`` の使用は、Red Hat Ansible Automation Platform サブスクリプションで完全にサポートされています。

en: Parsing with ntc_templates
ja: ntc_templates での解析

en: The ``ntc_templates`` python library includes pre-defined ``textfsm`` templates for parsing a variety of network device commands output.
ja: ``ntc_templates`` python ライブラリーには、さまざまなネットワークデバイスコマンドの出力を解析する事前定義済みの ``textfsm`` テンプレートが含まれています。

en: The ``ansible_network_os`` of the device is converted to the ntc_template format ``cisco_nxos``. Alternately, you can provide the ``os`` with the ``parser/os`` option instead.
ja: デバイスの ``ansible_network_os`` は ntc_template 形式 ``cisco_nxos`` に変換されますが、代わりに ``parser/os`` オプションで ``os`` を指定することもできます。

en: The ``cisco_nxos_show_interface.textfsm`` template, included with the ``ntc_templates`` package, parses the output.
ja: ``cisco_nxos_show_interface.textfsm`` パッケージに含まれる ``ntc_templates`` テンプレートは、出力を解析します。

en: See `the ntc_templates README <https://github.com/networktocode/ntc-templates/blob/master/README.md>`_ for additional information about the ``ntc_templates`` python library.
ja: ``ntc_templates`` python ライブラリーに関する追加情報は、`ntc_templates の「README」 <https://github.com/networktocode/ntc-templates/blob/master/README.md>`_ を参照してください。

en: Red Hat Ansible Automation Platform subscription support is limited to the use of the ``ntc_templates`` public APIs as documented.
ja: Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``ntc_templates`` パブリック API の使用に限定されます。

en: This task and and the predefined template sets the following fact as the ``interfaces`` fact for the host:
ja: このタスクおよび事前定義されたテンプレートは、以下のファクトをホストの ``interfaces`` ファクトとして設定します。

en: Parsing with pyATS
ja: pyATS での解析

en: ``pyATS`` is part of the Cisco Test Automation & Validation Solution. It includes many predefined parsers for a number of network platforms and commands. You can use the predefined parsers that are part of the ``pyATS`` package with the ``cli_parse`` module.
ja: ``pyATS`` は、Cisco Test Automation & Validation Solution の一部です。これには、多数のネットワークプラットフォームおよびコマンド用の定義済みパーサーが多数含まれています。``cli_parse`` モジュールでは、``pyATS`` パッケージに同梱される定義済みパーサーを使用できます。

en: The ``cli_parse`` modules converts the ``ansible_network_os`` automatically (in this example, ``ansible_network_os`` set to ``cisco.nxos.nxos``, converts to ``nxos`` for pyATS.  Alternately, you can set the OS with the ``parser/os`` option instead.
ja: ``cli_parse`` モジュールは、自動的に ``ansible_network_os`` を変換します (この例では、``ansible_network_os`` は ``cisco.nxos.nxos`` に設定されていますが、pyATS の場合は ``nxos`` に変換されます。代わりに、``parser/os`` オプションを使用して OS を設定することもできます)。

en: Using a combination of the command and OS, the pyATS selects the following parser: https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers/show%2520interface.
ja: コマンドと OS の組み合わせを使用して、pyATS がパーサー (https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers/show%2520interface) を選択します。

en: The ``cli_parse`` module sets ``cisco.ios.ios`` to ``iosxe`` for pyATS. You can override this with the ``parser/os`` option.
ja: ``cli_parse`` モジュールは、pyATS に対して ``cisco.ios.ios`` を ``iosxe`` に設定します。``parser/os`` オプションでこれを上書きできます。

en: ``cli_parse`` only uses the predefined parsers in pyATS. See the `pyATS documentation <https://developer.cisco.com/docs/pyats/>`_ and the full list of `pyATS included parsers <https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers>`_.
ja: ``cli_parse`` は pyATS の定義済みパーサーのみを使用します。`pyATS ドキュメント <https://developer.cisco.com/docs/pyats/>`_ と、`pyATS が含まれるパーサー <https://pubhub.devnetcloud.com/media/genie-feature-browser/docs/#/parsers>`_ の完全なリストを参照してください。

en: Red Hat Ansible Automation Platform subscription support is limited to the use of the pyATS public APIs as documented.
ja: Red Hat Ansible Automation Platform のサブスクリプションサポートは、文書化されている pyATS パブリック API の使用に限定されます。

en: This task sets the following fact as the ``interfaces`` fact for the host:
ja: このタスクは、ホストの ``interfaces`` ファクトとして以下のファクトを設定します。

en: Parsing with textfsm
ja: textfsm で解析

en: ``textfsm`` is a Python module which implements a template-based state machine for parsing semi-formatted text.
ja: ``textfsm`` は、半フォーマットのテキストを解析するためにテンプレートベースの状態マシンを実装する Python モジュールです。

en: The following sample``textfsm`` template is stored as ``templates/nxos_show_interface.textfsm``
ja: 以下のサンプル ``textfsm`` テンプレートは、``templates/nxos_show_interface.textfsm`` の形式で保存されます。

en: The following task uses the example template for ``textfsm`` with the ``cli_parse`` module.
ja: 以下のタスクでは、``textfsm`` モジュールで ``cli_parse`` のサンプルテンプレートを使用します。

en: The ``ansible_network_os`` for the device (``cisco.nxos.nxos``) is converted to ``nxos``. Alternately you can provide the OS in the ``parser/os`` option instead.
ja: デバイスの ``ansible_network_os`` (``cisco.nxos.nxos``) は ``nxos`` に変換されます。代わりに ``parser/os`` オプションに OS を指定することもできます。

en: The textfsm template name defaulted to ``templates/nxos_show_interface.textfsm`` using a combination of the OS and command run. Alternately you can override the generated template path with the ``parser/template_path`` option.
ja: textfsm のテンプレート名は、OS とコマンドランの組み合わせにより、デフォルトで``templates/nxos_show_interface.textfsm`` となっています。また、``parser/template_path`` オプションで、生成されたテンプレートのパスを上書きすることもできます。

en: See the `textfsm README <https://github.com/google/textfsm>`_ for details.
ja: 詳細は、`textfsm README <https://github.com/google/textfsm>`_ を参照してください。

en: ``textfsm`` was previously made available as a filter plugin. Ansible users should transition to the ``cli_parse`` module.
ja: ``textfsm`` は、以前はフィルタープラグインとして利用できました。Ansible ユーザーは、``cli_parse`` モジュールに移行する必要があります。

en: Red Hat Ansible Automation Platform subscription support is limited to the use of the ``textfsm`` public APIs as documented.
ja: Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``textfsm`` パブリック API の使用に限定されます。

en: Parsing with TTP
ja: TTP での解析

en: TTP is a Python library for semi-structured text parsing using templates. TTP uses a jinja-like syntax to limit the need for regular expressions. Users familiar with jinja templating may find the TTP template syntax familiar.
ja: TTP は、テンプレートを使用した半構造化テキスト解析用の Python ライブラリーです。TTP は、正規表現の必要性を制限するために、jinja に似た構文を使用します。jinja のテンプレート化に精通しているユーザーは、TTP テンプレートの構文に親しみを感じるかもしれません。

en: The following is an example TTP template stored as ``templates/nxos_show_interface.ttp``:
ja: 以下は、``templates/nxos_show_interface.ttp`` として保存された TTP テンプレートの例です。

en: The following task uses this template to parse the ``show interface`` command output:
ja: 以下のタスクでは、このテンプレートを使用して ``show interface`` コマンドの出力を解析します。

en: Taking a deeper dive in this task:
ja: このタスクをより深く掘り下げます。

en: The default template path ``templates/nxos_show_interface.ttp`` was generated using the ``ansible_network_os`` for the host and ``command`` provided.
ja: デフォルトのテンプレートパス ``templates/nxos_show_interface.ttp`` は、ホストの ``ansible_network_os`` と、指定した ``command`` を使用して生成されました。

en: TTP supports several additional variables that will be passed to the parser. These include:
ja: TTP は、パーサーに渡される追加変数をサポートします。これには以下が含まれます。

en: ``parser/vars/ttp_init`` -  Additional parameter passed when the parser is initialized.
ja: ``parser/vars/ttp_init`` - パーサーの初期化時に渡される追加のパラメーター。

en: ``parser/vars/ttp_results`` -  Additional parameters used to influence the parser output.
ja: ``parser/vars/ttp_results`` - パーサーの出力に影響を与えるために使用される追加のパラメーター。

en: ``parser/vars/ttp_vars`` -  Additional variables made available in the template.
ja: ``parser/vars/ttp_vars`` - テンプレートで利用可能な追加の変数

en: See the `TTP documentation <https://ttp.readthedocs.io>`_ for details.
ja: 詳細は、`TTP documentation <https://ttp.readthedocs.io>`_ を参照してください。

en: The task sets the follow fact as the ``interfaces`` fact for the host:
ja: このタスクは、ホストの ``interfaces`` ファクトとして follow ファクトを設定します。

en: Parsing with JC
ja: JC での解析

en: JC is a python library that converts the output of dozens of common Linux/UNIX/macOS/Windows command-line tools and file types to python dictionaries or lists of dictionaries for easier parsing. JC is available as a filter plugin in the ``community.general`` collection.
ja: JC は、多数の一般的な Linux/UNIX/macOS/Windows コマンドラインツールおよびファイルタイプの出力を python ディクショナリーまたはディクショナリーの一覧に変換する python ライブラリーです。JC は、``community.general`` コレクションのフィルタープラグインとして利用できます。

en: The following is an example using JC to parse the output of the ``dig`` command:
ja: 以下は、JC を使用して ``dig`` コマンドの出力を解析した例です。

en: The JC project and documentation can be found `here <https://github.com/kellyjonbrazil/jc/>`_.
ja: JC プロジェクトおよびドキュメントは `here <https://github.com/kellyjonbrazil/jc/>`_ にあります。

en: See this `blog entry <https://blog.kellybrazil.com/2020/08/30/parsing-command-output-in-ansible-with-jc/>`_ for more information.
ja: 詳細は、`ブログ記事 <https://blog.kellybrazil.com/2020/08/30/parsing-command-output-in-ansible-with-jc/>` を参照してください。

en: Converting XML
ja: XML の変換

en: This example task runs the ``show interface`` command and parses the output as XML:
ja: このサンプルタスクでは、``show interface`` コマンドを実行し、出力を XML として解析します。

en: Red Hat Ansible Automation Platform subscription support is limited to the use of the ``xmltodict`` public APIs as documented.
ja: Red Hat Ansible Automation Platform のサブスクリプションのサポートは、文書化されている ``xmltodict`` パブリック API の使用に限定されます。

en: This task sets the ``interfaces`` fact for the host based on this returned output:
ja: このタスクは、返された出力に基づいてホストの ``interfaces`` ファクトを設定します。

en: Advanced use cases
ja: 高度なユースケース

en: The ``cli_parse`` module supports several features to support more complex uses cases.
ja: ``cli_parse`` モジュールは、より複雑なユースケースをサポートする複数の機能をサポートします。

en: Provide a full template path
ja: 完全なテンプレートパスを提供

en: Use the ``template_path`` option to override the default template path in the task:
ja: ``template_path`` オプションを使用して、タスクのデフォルトのテンプレートパスを上書きします。

en: Provide command to parser different than the command run
ja: コマンド実行以外のパーサーを行うコマンドを指定

en: Use the ``command`` suboption for the ``parser`` to configure the command the parser expects if it is different from the command ``cli_parse`` runs:
ja: ``parser`` の ``command`` サブオプションを使用して、``cli_parse`` コマンドの実行とは異なる場合にパーサーが想定するコマンドを設定します。

en: Provide a custom OS value
ja: カスタム OS 値を指定

en: Use the ``os`` suboption to the parser to directly set the OS instead of using ``ansible_network_os`` or ``ansible_distribution`` to generate the template path or with the specified parser engine:
ja: テンプレートパスを生成する ``ansible_network_os`` や ``ansible_distribution``、または指定したパーサーエンジンを使用する代わりに、OS を直接設定するパーサーに ``os`` サブオプションを使用します。

en: Parse existing text
ja: 既存テキストの解析

en: Use the ``text`` option  instead of ``command`` to parse text collected earlier in the playbook.
ja: ``command`` の代わりに ``text`` オプションを使用して、Playbook で以前に収集したテキストを解析します。

en: Topics
ja: トピック

en: How can I improve performance for network playbooks?
ja: ネットワークの Playbook のパフォーマンスを改善するにはどうすればよいですか

en: Consider ``strategy: free`` if you are running on multiple hosts
ja: 複数のホストで実行している場合は ``strategy: free`` について検討してください。

en: The ``strategy`` plugin tells Ansible how to order multiple tasks on multiple hosts. :ref:`Strategy<strategy_plugins>` is set at the playbook level.
ja: ``strategy`` プラグインは、Ansible に対して複数のホストで複数のタスクを順序付ける方法を示します。:ref:`Strategy<strategy_plugins>` は Playbook レベルで設定されます。

en: The default strategy is ``linear``. With strategy set to ``linear``, Ansible waits until the current task has run on all hosts before starting the next task on any host. Ansible may have forks free, but will not use them until all hosts have completed the current task. If each task in your playbook must succeed on all hosts before you run the next task, use the ``linear`` strategy.
ja: デフォルトのストラテジーは ``linear`` です。ストラテジーを ``linear`` に設定すると、Ansible は、現在のタスクがすべてのホストで実行されるまで待機してから、任意のホストで次のタスクを開始します。Ansible はフォークを解放しているかもしれませんが、全てのホストが現在のタスクを完了するまでフォークを使用しません。次のタスクを実行する前に、Playbook の各タスクがすべてのホストで成功する必要がある場合は、``linear`` ストラテジーを使用します。

en: Using the ``free`` strategy, Ansible uses available forks to execute tasks on each host as quickly as possible. Even if an earlier task is still running on one host, Ansible executes later tasks on other hosts. The ``free`` strategy uses available forks more efficiently. If your playbook stalls on each task, waiting for one slow host, consider using ``strategy: free`` to boost overall performance.
ja: この ``free`` ストラテジーを使用すると、Ansible は、利用可能なフォークを使用して各ホストのタスクをできるだけ速く実行します。あるホストで前のタスクの実行が完了していない場合でも、Ansible は他のホストで後のタスクを実行します。この ``free`` ストラテジーでは、使用可能なフォークをより効率的に使用します。各タスクで Playbook が停滞し、1 つのホストの処理速度が遅い場合は、``strategy: free`` を使用して全体的なパフォーマンスを向上させることを検討してください。

en: Execute ``show running`` only if you absolutely must
ja: 絶対的に必要とされる場合にのみ ``show running`` を実行

en: The ``show running`` command is the most resource-intensive command to execute on a network device, because of the way queries are handled by the network OS. Using the command in your Ansible playbook will slow performance significantly, especially on large devices; repeating it will multiply the performance hit. If you have a playbook that checks the running config, then executes changes, then checks the running config again, you should expect that playbook to be very slow.
ja: この ``show running`` コマンドは、ネットワーク OS によるクエリーの処理方法のため、ネットワークデバイスで実行する最もリソースを消費するコマンドです。Ansible Playbook でこのコマンドを使用すると、特に大規模なデバイスではパフォーマンスが大幅に低下します。繰り返し実行すると、パフォーマンスへの影響が大きくなります。実行設定を確認してから変更を実行し、再び実行設定を確認する Playbook がある場合は、Playbook が非常に遅くなることが予想されます。

en: Use ``ProxyCommand`` only if you absolutely must
ja: 絶対的に必要とされる場合のみ ``ProxyCommand`` を使用

en: Network modules support the use of a :ref:`proxy or jump host<network_delegate_to_vs_ProxyCommand>` with the ``ProxyCommand`` parameter. However, when you use a jump host, Ansible must open a new SSH connection for every task, even if you are using a persistent connection type (``network_cli`` or ``netconf``). To maximize the performance benefits of the persistent connection types introduced in version 2.5, avoid using jump hosts whenever possible.
ja: ネットワークモジュールは、``ProxyCommand`` パラメーターで :ref:`プロキシーまたはジャンプホスト<network_delegate_to_vs_ProxyCommand>` の使用がサポートされています。ただし、ジャンプホストを使用する場合は、永続的な接続タイプ (``network_cli`` または ``netconf``) を使用している場合でも、タスクごとに新しい SSH 接続を開く必要があります。バージョン 2.5 で導入された永続接続タイプのパフォーマンス上の利点を最大限に活用するには、可能な限りジャンプホストを使用しないでください。

en: Set ``--forks`` to match your needs
ja: 必要に応じて ``--forks`` を設定

en: Every time Ansible runs a task, it forks its own process. The ``--forks`` parameter defines the number of concurrent tasks - if you retain the default setting, which is ``--forks=5``, and you are running a playbook on 10 hosts, five of those hosts will have to wait until a fork is available. Of course, the more forks you allow, the more memory and processing power Ansible will use. Since most network tasks are run on the control host, this means your laptop can quickly become cpu- or memory-bound.
ja: Ansible はタスクを実行するたびに、独自のプロセスをフォークします。``--forks`` パラメーターは、同時実行タスクの数を定義します。デフォルト設定 (``--forks=5``) のままで、10 台のホストで Playbook を実行していると、そのうち 5 台のホストは、フォークが使用可能になるまで待機する必要があります。もちろん、フォークの数が増えれば増えるほど、Ansible はより多くのメモリーと処理能力を使うことになります。ネットワークタスクの大半はコントロールホストで実行されるため、ラップトップでは、CPU またはメモリーがすぐに枯渇することになります。

en: Why is my output sometimes replaced with ``********``?
ja: 出力が ``********`` に置き換えられることがあるのはなぜですか

en: Ansible replaces any string marked ``no_log``, including passwords, with ``********`` in Ansible output. This is done by design, to protect your sensitive data. Most users are happy to have their passwords redacted. However, Ansible replaces every string that matches your password with ``********``. If you use a common word for your password, this can be a problem. For example, if you choose ``Admin`` as your password, Ansible will replace every instance of the word ``Admin`` with ``********`` in your output. This may make your output harder to read. To avoid this problem, select a secure password that will not occur elsewhere in your Ansible output.
ja: Ansible は、Ansible 出力で、パスワードを含む ``no_log`` と印された文字列を ``********`` に置き換えます。これは、機密データを保護するために設計されています。ほとんどのユーザーは、自身のパスワードが伏字になることを希望します。ただし、Ansible はパスワードに一致するすべての文字列を ``********`` に置き換えます。パスワードに一般的な単語を使用すると、問題が発生する可能性があります。たとえば、``Admin`` をパスワードとした場合、``Admin`` は出力内にあるその単語のすべてのインスタンスを ``********`` に置き換えます。これにより、出力が読みにくくなる場合があります。この問題を回避するには、他の Ansible 出力場所では使用されない安全なパスワードを選択してください。

en: Why do the ``*_config`` modules always return ``changed=true`` with abbreviated commands?
ja: 省略されたコマンドで ``*_config`` モジュールが常に ``changed=true`` を返すのはなぜですか

en: When you issue commands directly on a network device, you can use abbreviated commands. For example, ``int g1/0/11`` and ``interface GigabitEthernet1/0/11`` do the same thing; ``shut`` and ``shutdown`` do the same thing. Ansible Network ``*_command`` modules work with abbreviations, because they run commands through the network OS.
ja: ネットワークデバイスで直接コマンドを実行する場合は、省略されたコマンドを使用できます。たとえば、``int g1/0/11`` と ``interface GigabitEthernet1/0/11`` は、同じ動作になります。``shut`` と ``shutdown`` も同じ動作になります。Ansible Network の ``*_command`` モジュールは、ネットワーク OS を介してコマンドを実行するため、省略形で動作します。

en: When committing configuration, however, the network OS converts abbreviations into long-form commands. Whether you use ``shut`` or ``shutdown`` on ``GigabitEthernet1/0/11``, the result in the configuration is the same: ``shutdown``.
ja: ただし、設定をコミットすると、ネットワーク OS は省略形を長い形式のコマンドに変換します。``GigabitEthernet1/0/11`` で ``shut`` または ``shutdown`` を使用した場合の設定は同じで、``shutdown`` となります。

en: Ansible Network ``*_config`` modules compare the text of the commands you specify in ``lines`` to the text in the configuration. If you use ``shut`` in the ``lines`` section of your task, and the configuration reads  ``shutdown``, the module returns ``changed=true`` even though the configuration is already correct. Your task will update the configuration every time it runs.
ja: Ansible Network の ``*_config`` モジュールは、``lines`` で指定したコマンドのテキストを設定のテキストと比較します。タスクの ``lines`` セクションで ``shut`` を使用し、設定が ``shutdown`` を読み込む場合は、設定が正しいにもかかわらず、モジュールが ``changed=true`` を返します。タスクを実行するたびに設定が更新されます。

en: To avoid this problem, use long-form commands with the ``*_config`` modules:
ja: この問題を回避するには、``*_config`` モジュールで長い形式のコマンドを使用します。

en: Advanced Topics
ja: 高度なトピック

en: Network Advanced Topics
ja: ネットワークの高度なトピック

en: Once you have mastered the basics of network automation with Ansible, as presented in :ref:`network_getting_started`, use this guide understand platform-specific details, optimization, and troubleshooting tips for Ansible for network automation.
ja: :ref:`network_getting_started` に記載されているように、Ansible を使用したネットワーク自動化の基本を習得したら、本ガイドを参照して、ネットワーク自動化に関する Ansible のプラットフォーム固有の詳細、最適化、およびトラブルシューティングのヒントを理解します。

en: This guide is intended for network engineers using Ansible for automation. It covers advanced topics. If you understand networks and Ansible, this guide is for you. You may read through the entire guide if you choose, or use the links below to find the specific information you need.
ja: このガイドは、自動化に Ansible を使用するネットワークエンジニアを対象とした高度なトピックを説明します。ネットワークと Ansible を理解しているユーザーを対象としています。必要に応じてガイド全体を読むか、次のリンクを使用して必要な特定情報を選択してください。

en: If you're new to Ansible, or new to using Ansible for network automation, start with the :ref:`network_getting_started`.
ja: Ansible を初めて使用する場合や、ネットワーク管理に Ansible を初めて使用する場合は、最初に「:ref:`network_getting_started`」をお読みください。

en: Ansible Network Examples
ja: Ansible ネットワークの例

en: This document describes some examples of using Ansible to manage your network infrastructure.
ja: 本ガイドでは、Ansible を使用してネットワークインフラストラクチャーを管理する例を説明します。

en: This example requires the following:
ja: この例では、以下が必要です。

en: **Ansible 2.10** (or higher) installed. See :ref:`intro_installation_guide` for more information.
ja: **Ansible 2.10** (またはそれ以上) がインストールされている。詳細は「:ref:`intro_installation_guide`」を参照してください。

en: One or more network devices that are compatible with Ansible.
ja: Ansible と互換性がある 1 つ以上ネットワークデバイス。

en: Basic understanding of YAML :ref:`yaml_syntax`.
ja: YAML :ref:`yaml_syntax` の基本知識

en: Basic understanding of Jinja2 templates. See :ref:`playbooks_templating` for more information.
ja: Jinja2 テンプレートの基本的な理解。詳細は「:ref:`playbooks_templating`」を参照してください。

en: Basic Linux command line use.
ja: 基本的な Linux コマンドラインの使用。

en: Basic knowledge of network switch & router configurations.
ja: ネットワークスイッチおよびルーター設定に関する基本知識。

en: Groups and variables in an inventory file
ja: インベントリーファイルのグループおよび変数

en: An ``inventory`` file is a YAML or INI-like configuration file that defines the mapping of hosts into groups.
ja: ``inventory`` ファイルは、ホストからグループへのマッピングを定義する YAML または INI のような設定ファイルです。

en: In our example, the inventory file defines the groups ``eos``, ``ios``, ``vyos`` and a "group of groups" called ``switches``. Further details about subgroups and inventory files can be found in the :ref:`Ansible inventory Group documentation <subgroups>`.
ja: この例では、インベントリーファイルは ``eos``、``ios``、および ``vyos`` と、``switches`` と呼ばれる「グループのグループ」を定義します。サブグループとインベントリーファイルの詳細は「:ref:`Ansible inventory Group documentation <subgroups>`」にあります。

en: Because Ansible is a flexible tool, there are a number of ways to specify connection information and credentials. We recommend using the ``[my_group:vars]`` capability in your inventory file.
ja: Ansible は柔軟なツールであるため、接続情報および認証情報を指定する方法は複数あります。インベントリーファイルで ``[my_group:vars]`` 機能を使用することが推奨されます。

en: If you use ssh-agent, you do not need the ``ansible_password`` lines. If you use ssh keys, but not ssh-agent, and you have multiple keys, specify the key to use for each connection in the ``[group:vars]`` section with ``ansible_ssh_private_key_file=/path/to/correct/key``. For more information on ``ansible_ssh_`` options see :ref:`behavioral_parameters`.
ja: ssh-agent を使用する場合、``ansible_password`` 行は必要ありません。ssh-agent でなく ssh キーを使用し、鍵が複数ある場合は、``ansible_ssh_private_key_file=/path/to/correct/key`` の ``[group:vars]`` セクションで、各接続に使用するキーを指定します。``ansible_ssh_`` オプションの詳細は、「:ref:`behavioral_parameters`」を参照してください。

en: Never store passwords in plain text.
ja: プレーンテキストにパスワードを保存しないでください。

en: Ansible vault for password encryption
ja: パスワード暗号化用の Ansible Vault

en: The "Vault" feature of Ansible allows you to keep sensitive data such as passwords or keys in encrypted files, rather than as plain text in your playbooks or roles. These vault files can then be distributed or placed in source control. See :ref:`playbooks_vault` for more information.
ja: Ansible の「Vault」機能を使用すると、パスワードやキーなどの機密データを、Playbook やロールのプレーンテキストとしてではなく、暗号化されたファイルに保存することができます。この Vault ファイルは、ソース制御に配布または配置することができます。詳細は、「:ref:`playbooks_vault`」を参照してください。

en: Here's what it would look like if you specified your SSH passwords (encrypted with Ansible Vault) among your variables:
ja: 変数内に SSH パスワード (Ansible Vault で暗号化) を指定すると、以下のようになります。

en: Common inventory variables
ja: 共通のインベントリー変数

en: The following variables are common for all platforms in the inventory, though they can be overwritten for a particular inventory group or host.
ja: 以下の変数はインベントリー内のすべてのプラットフォームに共通ですが、特定のインベントリーグループまたはホストについて上書きできます。

en: Ansible uses the ansible-connection setting to determine how to connect to a remote device. When working with Ansible Networking, set this to an appropriate network connection option, such as``ansible.netcommon.network_cli``, so Ansible treats the remote node as a network device with a limited execution environment. Without this setting, Ansible would attempt to use ssh to connect to the remote and execute the Python script on the network device, which would fail because Python generally isn't available on network devices.
ja: Ansible は ansible-connection 設定を使用してリモートデバイスへの接続方法を決定します。Ansible ネットワークを使用する場合は、適切なネットワーク接続オプション (``ansible.netcommon.network_cli`` など) に設定して、Ansible が実行環境が制限されたネットワークデバイスとしてリモートノードを扱うようにします。この設定がないと、Ansible は ssh を使用してリモートに接続し、Python スクリプトをネットワークデバイスで実行しようとしますが、Python は一般的にネットワークデバイスで使用できないため失敗します。

en: Informs Ansible which Network platform this hosts corresponds to. This is required when using the ``ansible.netcommon.*`` connection options.
ja: このホストに対応するネットワークプラットフォームを Ansible に通知します。これは、``ansible.netcommon.*`` 接続オプションを使用する場合に必要です。

en: The user to connect to the remote device (switch) as. Without this the user that is running ``ansible-playbook`` would be used. Specifies which user on the network device the connection
ja: リモートデバイス (スイッチ) に接続するユーザーです。これがないと、このユーザーが ``ansible-playbook`` を実行しているユーザーに使用されます。ネットワークデバイス上のどのユーザーに接続するかを指定します。

en: The corresponding password for ``ansible_user`` to log in as. If not specified SSH key will be used.
ja: ``ansible_user`` でログインするためのパスワードです。指定しない場合は、SSH キーが使用されます。

en: If enable mode (privilege mode) should be used, see the next section.
ja: Enable モード (特権モード) を使用する場合は、次のセクションを参照してください。

en: Which type of `become` should be used, for ``network_cli`` the only valid choice is ``enable``.
ja: どのタイプ `become` を使用すべきか。``network_cli`` では、有効な選択は ``enable`` のみです。

en: Privilege escalation
ja: 権限昇格

en: Certain network platforms, such as Arista EOS and Cisco IOS, have the concept of different privilege modes. Certain network modules, such as those that modify system state including users, will only work in high privilege states. Ansible supports ``become`` when using ``connection: ansible.netcommon.network_cli``. This allows privileges to be raised for the specific tasks that need them. Adding ``become: yes`` and ``become_method: enable`` informs Ansible to go into privilege mode before executing the task, as shown here:
ja: Arista EOS や Cisco IOS などの特定のネットワークプラットフォームには、異なる特権モードの概念があります。ユーザーを含むシステム状態を変更するような特定のネットワークモジュールは、高特権状態でのみ動作します。Ansible は、``connection: ansible.netcommon.network_cli`` の使用時に、``become`` をサポートします。これにより、権限を必要とする特定のタスクに対して権限を設定できます。次に示すように、``become: yes`` および ``become_method: enable`` を追加すると、タスクを実行する前に特権モードに入るように Ansible に通知します。

en: For more information, see the :ref:`using become with network modules<become_network>` guide.
ja: 詳細は「:ref:`ネットワークモジュールで become の使用<become_network>`」ガイドを参照してください。

en: Jump hosts
ja: ジャンプホスト

en: If the Ansible Controller does not have a direct route to the remote device and you need to use a Jump Host, please see the :ref:`Ansible Network Proxy Command <network_delegate_to_vs_ProxyCommand>` guide for details on how to achieve this.
ja: Ansible Controller がリモートデバイスへの直接ルートがなく、ジャンプホストを使用する必要がある場合は、これを実現する方法について、「:ref:`Ansible ネットワークプロキシーコマンド <network_delegate_to_vs_ProxyCommand>`」ガイドを参照してください。

en: Example 1: collecting facts and creating backup files with a playbook
ja: 例 1: Playbook でファクトを収集し、バックアップファイルの作成

en: Ansible facts modules gather system information 'facts' that are available to the rest of your playbook.
ja: Ansible ファクトモジュールは、他の Playbook で利用可能なシステム情報の「ファクト」を収集します。

en: Ansible Networking ships with a number of network-specific facts modules. In this example, we use the ``_facts`` modules :ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>`, :ref:`cisco.ios.ios_facts <ansible_collections.cisco.ios.ios_facts_module>` and :ref:`vyos.vyos.vyos_facts <ansible_collections.vyos.vyos.vyos_facts_module>` to connect to the remote networking device. As the credentials are not explicitly passed with module arguments, Ansible uses the username and password from the inventory file.
ja: Ansible ネットワークには、ネットワーク固有のファクトモジュールがいくつか付属しています。この例では、``_facts`` モジュール (:ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>`、:ref:`cisco.ios.ios_facts <ansible_collections.cisco.ios.ios_facts_module>`、および :ref:`vyos.vyos.vyos_facts <ansible_collections.vyos.vyos.vyos_facts_module>`) を使用し、リモートネットワーキングデバイスに接続します。認証情報はモジュール引数とともに明示的に渡されないため、Ansible はインベントリーファイルからのユーザー名とパスワードを使用します。

en: Ansible's "Network Fact modules" gather information from the system and store the results in facts prefixed with ``ansible_net_``. The data collected by these modules is documented in the `Return Values` section of the module docs, in this case :ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>` and :ref:`vyos.vyos.vyos_facts <ansible_collections.vyos.vyos.vyos_facts_module>`. We can use the facts, such as ``ansible_net_version`` late on in the "Display some facts" task.
ja: Ansibleの「ネットワークファクトモジュール」はシステムから情報を収集し、``ansible_net_`` の接頭辞が付いたファクトに結果を格納します。これらのモジュールによって収集されるデータは、モジュールドキュメントの `Return Values` セクション (この場合は :ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>` および :ref:`vyos.vyos.vyos_facts <ansible_collections.vyos.vyos.vyos_facts_module>`) に記載されています。``ansible_net_version`` などのファクトは、「Display some facts (一部のファクトを表示する)」タスクの後半で使用できます。

en: To ensure we call the correct mode (``*_facts``) the task is conditionally run based on the group defined in the inventory file, for more information on the use of conditionals in Ansible Playbooks see :ref:`the_when_statement`.
ja: 正しいモード (``*_facts``) を呼び出すようにするには、インベントリーファイルに定義されたグループに基づいてタスクが条件付きで実行されます。Ansible Playbook での条件付き使用の詳細は、「:ref:`the_when_statement`」を参照してください。

en: In this example, we will create an inventory file containing some network switches, then run a playbook to connect to the network devices and return some information about them.
ja: この例では、一部のネットワークスイッチを含むインベントリーファイルを作成してから、Playbook を実行してネットワークデバイスに接続し、その情報を返します。

en: Step 1: Creating the inventory
ja: ステップ 1: インベントリーの作成

en: First, create a file called ``inventory``, containing:
ja: まず、以下を含む ``inventory`` という名前のファイルを作成します。

en: Step 2: Creating the playbook
ja: ステップ 2: Playbook の作成

en: Next, create a playbook file called ``facts-demo.yml`` containing the following:
ja: 次に、以下を含む ``facts-demo.yml`` という名前の Playbook ファイルを作成します。

en: Step 3: Running the playbook
ja: ステップ 3: Playbook の実行

en: To run the playbook, run the following from a console prompt:
ja: Playbook を実行するには、コンソールプロンプトから以下を実行します。

en: This should return output similar to the following:
ja: このコマンドを実行すると、以下のような出力が返されます。

en: Step 4: Examining the playbook results
ja: 手順 4: Playbook の結果の検証

en: Next, look at the contents of the file we created containing the switch facts:
ja: 次に、スイッチファクトを含む作成したファイルの内容を確認します。

en: You can also look at the backup files:
ja: バックアップファイルを確認することもできます。

en: If `ansible-playbook` fails, please follow the debug steps in :ref:`network_debug_troubleshooting`.
ja: `ansible-playbook` が失敗する場合は、:ref:`network_debug_troubleshooting` のデバッグ手順に従ってください。

en: Example 2: simplifying playbooks with network agnostic modules
ja: 例 2: ネットワークに依存しないモジュールを使用した Playbook の単純化

en: (This example originally appeared in the `Deep Dive on cli_command for Network Automation <https://www.ansible.com/blog/deep-dive-on-cli-command-for-network-automation>`_ blog post by Sean Cavanaugh -`@IPvSean <https://github.com/IPvSean>`_).
ja: (この例は、元々、Sean Cavanaugh (`@IPvSean <https://github.com/IPvSean>`_) 氏が投稿したブログ「`Deep Dive on cli_command for Network Automation <https://www.ansible.com/blog/deep-dive-on-cli-command-for-network-automation>`_」で紹介されました。)

en: If you have two or more network platforms in your environment, you can use the network agnostic modules to simplify your playbooks. You can use network agnostic modules such as ``ansible.netcommon.cli_command`` or ``ansible.netcommon.cli_config`` in place of the platform-specific modules such as ``arista.eos.eos_config``, ``cisco.ios.ios_config``, and ``junipernetworks.junos.junos_config``. This reduces the number of tasks and conditionals you need in your playbooks.
ja: 環境内に複数のネットワークプラットフォームがある場合は、ネットワークに依存しないモジュールを使用して、Playbook を簡素化できます。``arista.eos.eos_config``、``cisco.ios.ios_config``、``junipernetworks.junos.junos_config`` などのプラットフォーム固有のモジュールの代わりに、``ansible.netcommon.cli_command``、``ansible.netcommon.cli_config`` などのネットワークに依存しないモジュールを使用できます。これにより、Playbook に必要なタスクおよび条件の数が減ります。

en: Network agnostic modules require the :ref:`ansible.netcommon.network_cli <ansible_collections.ansible.netcommon.network_cli_connection>` connection plugin.
ja: ネットワークに依存しないモジュールには、:ref:`ansible.netcommon.network_cli <ansible_collections.ansible.netcommon.network_cli_connection>` 接続プラグインが必要です。

en: Sample playbook with platform-specific modules
ja: プラットフォーム固有のモジュールを含む Playbook のサンプル

en: This example assumes three platforms, Arista EOS, Cisco NXOS, and Juniper JunOS.  Without the network agnostic modules, a sample playbook might contain the following three tasks with platform-specific commands:
ja: この例では、Arista EOS、Cisco NXOS、Juniper JunOS の 3 つのプラットフォームを想定しています。ネットワークに依存しないモジュールを使用しないと、サンプル Playbook にはプラットフォーム固有のコマンドと共に、以下の 3 つのタスクが含まれる場合があります。

en: Simplified playbook with ``cli_command`` network agnostic module
ja: ``cli_command`` ネットワークに依存しないモジュールを使用した Playbook の簡素化

en: You can replace these platform-specific modules with the network agnostic ``ansible.netcommon.cli_command`` module as follows:
ja: これらのプラットフォーム固有のモジュールは、以下のようにネットワークに依存しない ``ansible.netcommon.cli_command`` モジュールに置き換えることができます。

en: If you use groups and group_vars by platform type, this playbook can be further simplified to :
ja: プラットフォームタイプ別にグループおよび group_vars を使用する場合は、この Playbook をさらに簡単にできます。

en: You can see a full example of this using group_vars and also a configuration backup example at `Network agnostic examples <https://github.com/network-automation/agnostic_example>`_.
ja: group_vars の完全例と設定バックアップの例は、`ネットワークに依存しない例 <https://github.com/network-automation/agnostic_example>`_ で確認できます。

en: Using multiple prompts with the  ``ansible.netcommon.cli_command``
ja: ``ansible.netcommon.cli_command`` を含む複数のプロンプトの使用

en: The ``ansible.netcommon.cli_command`` also supports multiple prompts.
ja: ``ansible.netcommon.cli_command`` は、複数のプロンプトもサポートします。

en: See the :ref:`ansible.netcommon.cli_command <cli_command_module>` for full documentation on this command.
ja: このコマンドに関するドキュメントは、「:ref:`ansible.netcommon.cli_command <cli_command_module>`」を参照してください。

en: Implementation Notes
ja: 実装に関する注意点

en: Demo variables
ja: デモ変数

en: Although these tasks are not needed to write data to disk, they are used in this example to demonstrate some methods of accessing facts about the given devices or a named host.
ja: これらのタスクは、ディスクにデータを書き込む必要はありませんが、この例では、特定のデバイスまたは名前付きホストのファクトにアクセスする方法を実証するために使用されます。

en: Ansible ``hostvars`` allows you to access variables from a named host. Without this we would return the details for the current host, rather than the named host.
ja: Ansible ``hostvars`` を使用すると、名前付きホストから変数にアクセスすることができます。これを使用しないと、名前付きホストではなく、現在のホストの詳細が返されます。

en: For more information, see :ref:`magic_variables_and_hostvars`.
ja: 詳細情報は、「:ref:`magic_variables_and_hostvars`」を参照してください。

en: Get running configuration
ja: 実行中の設定の取得

en: The :ref:`arista.eos.eos_config <ansible_collections.arista.eos.eos_config_module>` and :ref:`vyos.vyos.vyos_config <ansible_collections.vyos.vyos.vyos_config_module>` modules have a ``backup:`` option that when set will cause the module to create a full backup of the current ``running-config`` from the remote device before any changes are made. The backup file is written to the ``backup`` folder in the playbook root directory. If the directory does not exist, it is created.
ja: :ref:`arista.eos.eos_config <ansible_collections.arista.eos.eos_config_module>` モジュールおよび :ref:`vyos.vyos.vyos_config <ansible_collections.vyos.vyos.vyos_config_module>` モジュールには、設定されている場合は、変更が行われる前にリモートデバイスから現在の ``running-config`` のフルバックアップを作成する ``backup:`` オプションがあります。バックアップファイルは、Playbook のルートディレクトリー内の ``backup`` ディレクトリーに書き込まれます。このディレクトリーが存在しない場合は作成されます。

en: To demonstrate how we can move the backup file to a different location, we register the result and move the file to the path stored in ``backup_path``.
ja: バックアップファイルを別の場所に移動する方法を実証するために、結果を登録し、ファイルを ``backup_path`` に保存されているパスに移動します。

en: Note that when using variables from tasks in this way we use double quotes (``"``) and double curly-brackets (``{{...}}`` to tell Ansible that this is a variable.
ja: この方法でタスクの変数を使用する場合は、Ansible にこれが変数であることを伝えるために、二重引用符 (``"``) と二重中括弧 (``{{...}}``) を使用します。

en: Troubleshooting
ja: トラブルシューティング

en: If you receive an connection error please double check the inventory and playbook for typos or missing lines. If the issue still occurs follow the debug steps in :ref:`network_debug_troubleshooting`.
ja: 接続エラーを受け取った場合は、インベントリーと Playbook で誤字または欠落している行がないか再確認してください。問題が解決しない場合は、:ref:`network_debug_troubleshooting` のデバッグ手順に従います。

en: Network Debug and Troubleshooting Guide
ja: ネットワークデバッグおよびトラブルシューティングガイド

en: This section discusses how to debug and troubleshoot network modules in Ansible.
ja: 本セクションでは、Ansible でネットワークモジュールをデバッグし、トラブルシューティングを行う方法を説明します。

en: How to troubleshoot
ja: トラブルシューティングの方法

en: Ansible network automation errors generally fall into one of the following categories:
ja: Ansible ネットワーク自動化エラーは通常、以下のカテゴリーのいずれかに分類されます。

en: Authentication issues
ja: 認証の問題

en: Not correctly specifying credentials
ja: 認証情報を正しく指定できない

en: Remote device (network switch/router) not falling back to other other authentication methods
ja: リモートデバイス (ネットワークスイッチ/ルーター) が他の認証方法にフォールバックしない

en: SSH key issues
ja: SSH キーの問題

en: Timeout issues
ja: タイムアウトの問題

en: Can occur when trying to pull a large amount of data
ja: 大量のデータを取得しようとすると発生することがある

en: May actually be masking a authentication issue
ja: 認証の問題を実際にマスクする可能性がある

en: Playbook issues
ja: Playbook の問題

en: Use of ``delegate_to``, instead of ``ProxyCommand``. See :ref:`network proxy guide <network_delegate_to_vs_ProxyCommand>` for more information.
ja: ``ProxyCommand`` の代わりに ``delegate_to`` を使用します。詳細は、「:ref:`ネットワークプロキシーガイド <network_delegate_to_vs_ProxyCommand>`」を参照してください。

en: The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. See the "Authentication and connection issues" section in this document for more information.
ja: ``unable to open shell`` メッセージは、``ansible-connection`` デーモンがリモートネットワークデバイスと正常に通信できなかったことを示します。これは通常、認証の問題があることを意味します。詳細については、このドキュメントの「認証と接続の問題」を参照してください。

en: Enabling Networking logging and how to read the logfile
ja: ネットワークロギングの有効化とログファイルの読み取り方法

en: **Platforms:** Any
ja: **プラットフォーム:** 任意

en: Ansible includes logging to help diagnose and troubleshoot issues regarding Ansible Networking modules.
ja: Ansible には、Ansible ネットワークモジュールに関する問題の診断とトラブルシューティングに役立つロギングが含まれます。

en: Because logging is very verbose, it is disabled by default. It can be enabled with the :envvar:`ANSIBLE_LOG_PATH` and :envvar:`ANSIBLE_DEBUG` options on the ansible-controller, that is the machine running ``ansible-playbook``.
ja: ロギングは非常に詳細なため、デフォルトでは無効になっています。これは、ansible-controller の :envvar:`ANSIBLE_LOG_PATH` オプションおよび :envvar:`ANSIBLE_DEBUG` オプションで有効にできます。これは、``ansible-playbook`` を実行しているマシンです。

en: Before running ``ansible-playbook``, run the following commands to enable logging::
ja: ``ansible-playbook`` を実行する前に、以下のコマンドを実行してロギングを有効にします。

en: After Ansible has finished running you can inspect the log file which has been created on the ansible-controller:
ja: Ansible の実行が完了したら、ansible-controller で作成されたログファイルを確認できます。

en: From the log notice:
ja: このログ通知は、以下のようになります。

en: ``p=28990`` Is the PID (Process ID) of the ``ansible-connection`` process
ja: ``p=28990`` ``ansible-connection`` プロセスの PID (プロセス ID) です。

en: ``u=fred`` Is the user `running` ansible, not the remote-user you are attempting to connect as
ja: ``u=fred`` ansible を `実行` しているユーザーです (接続しようとしているリモートユーザーではありません)。

en: ``creating new control socket for host veos01:22 as user admin`` host:port as user
ja: ``ホスト veos01:22 の新しいコントロールソケットをユーザー管理者`` ユーザーとして host:port

en: ``control socket path is`` location on disk where the persistent connection socket is created
ja: ``control socket path is`` 永続接続ソケットが作成されるディスクの場所

en: ``using connection plugin network_cli`` Informs you that persistent connection is being used
ja: ``using connection plugin network_cli`` 永続接続が使用されていることが通知されます。

en: ``connection established to veos01 in 0:00:22.580626`` Time taken to obtain a shell on the remote device
ja: ``connection established to veos01 in 0:00:22.580626`` リモートデバイスでシェルの取得にかかった時間

en: Because the log files are verbose, you can use grep to look for specific information. For example, once you have identified the ``pid`` from the ``creating new control socket for host`` line you can search for other connection log entries::
ja: ログファイルは冗長であるため、grepを使用して特定の情報を検索できます。たとえば、``creating new control socket for host`` 行から ``pid`` を特定したら、他の接続ログエントリーを検索できます。

en: Enabling Networking device interaction logging
ja: ネットワークデバイスの対話ロギングの有効化

en: Ansible includes logging of device interaction in the log file to help diagnose and troubleshoot issues regarding Ansible Networking modules. The messages are logged in the file pointed to by the ``log_path`` configuration option in the Ansible configuration file or by setting the  :envvar:`ANSIBLE_LOG_PATH`.
ja: Ansible には、Ansible ネットワークモジュールに関する問題の診断およびトラブルシューティングに役立つ、ログファイル内のデバイスの対話のログが含まれています。このメッセージは、Ansible 設定ファイルの ``log_path`` 設定オプションで指定されているファイルに記録されるか、:envvar:`ANSIBLE_LOG_PATH` を設定すると記録されます。

en: The device interaction messages consist of command executed on the target device and the returned response. Since this log data can contain sensitive information including passwords in plain text it is disabled by default. Additionally, in order to prevent accidental leakage of data, a warning will be shown on every task with this setting enabled, specifying which host has it enabled and where the data is being logged.
ja: デバイスインタラクションメッセージは、ターゲットデバイス上で実行されたコマンドと返された応答で構成されます。このログデータには、パスワードなどの機密情報がプレーンテキストの形式で含まれる可能性があるため、デフォルトでは無効になっています。また、誤ってデータが漏洩しないように、この設定が有効になっているすべてのタスクに警告が表示され、有効になっているホストとデータが記録される場所が指定されます。

en: Be sure to fully understand the security implications of enabling this option. The device interaction logging can be enabled either globally by setting in configuration file or by setting environment or enabled on per task basis by passing a special variable to the task.
ja: このオプションを有効にした場合のセキュリティーへの影響を完全に理解してください。デバイス対話ロギングは、設定ファイルでグローバルに設定するか、環境を設定して有効にするか、または特殊な変数をタスクに渡すことでタスクごとに有効にすることができます。

en: Before running ``ansible-playbook`` run the following commands to enable logging:
ja: ``ansible-playbook`` を実行する前に、以下のコマンドを実行してロギングを有効にします。

en: Enable device interaction logging for a given task
ja: 特定のタスクのデバイス対話ログを有効にします。

en: To make this a global setting, add the following to your ``ansible.cfg`` file:
ja: この設定をグローバルにするには、以下の設定を ``ansible.cfg`` ファイルに追加します。

en: or enable the environment variable `ANSIBLE_PERSISTENT_LOG_MESSAGES`:
ja: または、環境変数 `ANSIBLE_PERSISTENT_LOG_MESSAGES` を有効にします。

en: If the task is failing on connection initialization itself, you should enable this option globally. If an individual task is failing intermittently this option can be enabled for that task itself to find the root cause.
ja: タスク自体が接続の初期化に失敗している場合は、このオプションをグローバルに有効にする必要があります。個々のタスクが断続的に失敗する場合は、そのタスク自体に対してこのオプションを有効にして、根本原因を見つけることができます。

en: After Ansible has finished running you can inspect the log file which has been created on the ansible-controller
ja: Ansible の実行が完了したら、ansible-controller で作成されたログファイルを確認できます。

en: Be sure to fully understand the security implications of enabling this option as it can log sensitive information in log file thus creating security vulnerability.
ja: このオプションを有効にすると、ログファイルに機密情報が記録され、セキュリティ上の脆弱性が生じる可能性があるため、セキュリティー上の影響を十分に理解してください。

en: Isolating an error
ja: エラーの分離

en: As with any effort to troubleshoot it's important to simplify the test case as much as possible.
ja: トラブルシューティングにおけるあらゆる作業と同様に、テストケースをできるだけ簡略化することが重要です。

en: For Ansible this can be done by ensuring you are only running against one remote device:
ja: Ansible の場合は、1 つのリモートデバイスに対してのみ実行するようにすることでこれを行うことができます。

en: Using ``ansible-playbook --limit switch1.example.net...``
ja: ``ansible-playbook --limit switch1.example.net...`` の使用

en: Using an ad hoc ``ansible`` command
ja: ``ansible`` アドホックコマンドの使用

en: `ad hoc` refers to running Ansible to perform some quick command using ``/usr/bin/ansible``, rather than the orchestration language, which is ``/usr/bin/ansible-playbook``. In this case we can ensure connectivity by attempting to execute a single command on the remote device::
ja: `ad hoc` は、オーケストレーション言語 ``/usr/bin/ansible-playbook`` ではなく、``/usr/bin/ansible`` を使用して簡単なコマンドを実行するために Ansible を実行することを指します。この場合は、リモートデバイスで 1 つのコマンドを実行することで、接続を確認できます。

en: In the above example, we:
ja: 上記の例では、以下を行います。

en: connect to ``switch1.example.net`` specified in the inventory file ``inventory``
ja: インベントリーファイル ``inventory`` に指定された ``switch1.example.net`` に接続します。

en: use the module ``arista.eos.eos_command``
ja: ``arista.eos.eos_command`` モジュールの使用

en: run the command ``?``
ja: ``?`` コマンドの実行

en: connect using the username ``admin``
ja: ユーザー名 ``admin`` を使用して接続

en: inform the ``ansible`` command to prompt for the SSH password by specifying ``-k``
ja: ``-k`` を指定して SSH パスワードを要求するように、``ansible`` コマンドに通知

en: If you have SSH keys configured correctly, you don't need to specify the ``-k`` parameter.
ja: SSH キーが正しく設定されている場合は、``-k`` パラメーターを指定する必要はありません。

en: If the connection still fails you can combine it with the enable_network_logging parameter. For example:
ja: それでも接続が失敗した場合は、これを enable_network_logging パラメーターと組み合わせることができます。以下に例を示します。

en: Then review the log file and find the relevant error message in the rest of this document.
ja: 次に、ログファイルを確認し、このドキュメントの残りの部分で、関連するエラーメッセージを見つけます。

en: Troubleshooting socket path issues
ja: ソケットパスの問題のトラブルシューティング

en: The ``Socket path does not exist or cannot be found``  and ``Unable to connect to socket`` messages indicate that the socket used to communicate with the remote network device is unavailable or does not exist.
ja: ``Socket path does not exist or cannot be found`` メッセージおよび ``Unable to connect to socket``メッセージは、リモートネットワークデバイスとの通信に使用されるソケットが利用できないか、存在しないことを示しています。

en: or
ja: または

en: Suggestions to resolve:
ja: 解決するためのヒント:

en: Verify that you have write access to the socket path described in the error message.
ja: エラーメッセージに記載されているソケットパスへの書き込み権限があることを確認します。

en: Follow the steps detailed in :ref:`enable network logging <enable_network_logging>`.
ja: 「:ref:`ネットワークロギングの有効化 <enable_network_logging>`」記載される手順に従ってください。

en: If the identified error message from the log file is:
ja: ログファイルから特定されたエラーメッセージが以下の場合は、

en: Follow the steps detailed in :ref:`timeout issues <timeout_issues>`
ja: 「:ref:`タイムアウトの問題 <timeout_issues>`」に記載の手順に従ってください。

en: The ``unable to open shell`` message means that the ``ansible-connection`` daemon has not been able to successfully talk to the remote network device. This generally means that there is an authentication issue. It is a "catch all" message, meaning you need to enable :ref:`logging <a_note_about_logging>` to find the underlying issues.
ja: ``unable to open shell`` メッセージは、``ansible-connection`` デーモンがリモートネットワークデバイスと正常に通信できなかったことを示します。これは通常、認証の問題があることを意味します。これは「catch all (全て取得する)」メッセージです。つまり、:ref:`logging <a_note_about_logging>` を有効にして、根本的な問題を検出する必要があります。

en: or:
ja: または

en: Follow the steps detailed in enable_network_logging_.
ja: enable_network_logging_ に記載の手順に従います。

en: Once you've identified the error message from the log file, the specific solution can be found in the rest of this document.
ja: ログファイルからエラーメッセージが特定できたら、特定の解決方法は、本ガイドのその他のセクションを参照してください。

en: Indicates that the remote host you are trying to connect to can not be reached
ja: 接続しようとしているリモートホストに到達できないことを示します。

en: If you are using the ``provider:`` options ensure that its suboption ``host:`` is set correctly.
ja: ``provider:`` オプションを使用している場合は、サブオプション ``host:`` が正しく設定されていることを確認します。

en: If you are not using ``provider:`` nor top-level arguments ensure your inventory file is correct.
ja: ``provider:`` またはトップレベルの引数を使用しない場合には、インベントリーファイルが正しいことを確認してください。

en: Occurs if the credentials (username, passwords, or ssh keys) passed to ``ansible-connection`` (via ``ansible`` or ``ansible-playbook``) can not be used to connect to the remote device.
ja: (``ansible`` または ``ansible-playbook`` を使用して) ``ansible-connection`` に渡される認証情報 (ユーザー名、パスワード、または ssh キー) を使用してリモートデバイスに接続できない場合に発生します。

en: If you are specifying credentials via ``password:`` (either directly or via ``provider:``) or the environment variable `ANSIBLE_NET_PASSWORD` it is possible that ``paramiko`` (the Python SSH library that Ansible uses) is using ssh keys, and therefore the credentials you are specifying are being ignored. To find out if this is the case, disable "look for keys". This can be done like this:
ja: (直接または ``provider:`` を使用して) ``password:`` で認証情報を指定する場合や、環境変数 `ANSIBLE_NET_PASSWORD` を指定する場合は、``paramiko`` (Ansible が使用する Python SSH ライブラリー) が ssh キーを使用している可能性があるため、指定する認証情報が無効になります。これを確認するには、「look for keys」を無効にします。これは次のように行います。

en: To make this a permanent change, add the following to your ``ansible.cfg`` file:
ja: これを永続的に行うには、以下を ``ansible.cfg`` ファイルに追加します。

en: This may occur if the SSH fingerprint hasn't been added to Paramiko's (the Python SSH library) know hosts file.
ja: これは、SSH フィンガープリントが Paramiko の既知のホストファイル (Python SSH ライブラリー) に追加されていない場合に発生する可能性があります。

en: When using persistent connections with Paramiko, the connection runs in a background process.  If the host doesn't already have a valid SSH key, by default Ansible will prompt to add the host key.  This will cause connections running in background processes to fail.
ja: Paramiko で永続的な接続を使用する場合、接続はバックグラウンドプロセスで実行します。ホストが有効な SSH キーを持っていない場合、Ansible はデフォルトでホストキーを追加するようプロンプトを出します。これにより、バックグラウンドプロセスで実行中の接続が失敗します。

en: Use ``ssh-keyscan`` to pre-populate the known_hosts. You need to ensure the keys are correct.
ja: ``ssh-keyscan`` を使用して known_hosts を事前に設定します。キーが正しいことを確認してください。

en: You can tell Ansible to automatically accept the keys
ja: 鍵を自動的に受け入れるように Ansible に設定できます。

en: Environment variable method::
ja: 環境変数メソッド::

en: ``ansible.cfg`` method:
ja: ``ansible.cfg`` メソッド:

en: No password or SSH key supplied
ja: パスワードまたは SSH キーが指定されていない

en: Clearing Out Persistent Connections
ja: 永続的な接続を解除

en: In Ansible 2.3, persistent connection sockets are stored in ``~/.ansible/pc`` for all network devices.  When an Ansible playbook runs, the persistent socket connection is displayed when verbose output is specified.
ja: Ansible 2.3 では、すべてのネットワークデバイスの永続的な接続ソケットが ``~/.ansible/pc`` に保存されます。Ansible Playbook が実行すると、詳細な出力が指定されている場合に永続的なソケット接続が表示されます。

en: To clear out a persistent connection before it times out (the default timeout is 30 seconds of inactivity), simple delete the socket file.
ja: タイムアウトする前に永続的な接続 (デフォルトのタイムアウトが 30 秒の非アクティブタイムアウト) を削除するには、ソケットファイルを簡単な削除します。

en: Persistent connection idle timeout
ja: 永続的な接続アイドルタイムアウト

en: By default, ``ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`` is set to 30 (seconds). You may see the following error if this value is too low:
ja: デフォルトでは、``ANSIBLE_PERSISTENT_CONNECT_TIMEOUT`` は 30 (秒) に設定されます。この値が低すぎると、以下のエラーが表示される可能性があります。

en: Increase value of persistent connection idle timeout:
ja: 永続的な接続アイドルタイムアウトの値を大きくします。

en: Command timeout
ja: コマンドタイムアウト

en: By default, ``ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`` is set to 30 (seconds). Prior versions of Ansible had this value set to 10 seconds by default. You may see the following error if this value is too low:
ja: デフォルトでは、``ANSIBLE_PERSISTENT_COMMAND_TIMEOUT`` は 30 (秒) に設定されます。Ansible の以前のバージョンでは、デフォルトでこの値を 10 秒に設定されています。この値が低すぎると、以下のエラーが発生する可能性があります。

en: Option 1 (Global command timeout setting): Increase value of command timeout in configuration file or by setting environment variable.
ja: オプション 1 (グローバルコマンドのタイムアウト設定): 設定ファイル、または環境変数を設定してコマンドタイムアウトの値を増やします。

en: Option 2 (Per task command timeout setting): Increase command timeout per task basis. All network modules support a timeout value that can be set on a per task basis. The timeout value controls the amount of time in seconds before the task will fail if the command has not returned.
ja: オプション 2 (タスクごとのコマンドのタイムアウト設定): タスクごとにコマンドタイムアウトを増やします。すべてのネットワークモジュールは、タスクごとに設定できるタイムアウト値をサポートしています。タイムアウト値は、コマンドが返されなかった場合にタスクが失敗するまでの時間を秒単位で制御します。

en: For local connection type:
ja: ローカル接続タイプの場合:

en: Some operations take longer than the default 30 seconds to complete.  One good example is saving the current running config on IOS devices to startup config. In this case, changing the timeout value from the default 30 seconds to 60 seconds will prevent the task from failing before the command completes successfully.
ja: 一部の操作は、完了までにデフォルトの 30 秒より長くかかります。たとえば、IOS デバイス上の現在の実行設定をスタートアップ設定に保存します。この場合は、タイムアウト値をデフォルトの 30 秒から 60 秒に変更すると、コマンドが正常に完了する前にタスクが失敗するのを防ぐことができます。

en: Persistent connection retry timeout
ja: 永続的な接続の再試行タイムアウト

en: By default, ``ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`` is set to 15 (seconds). You may see the following error if this value is too low:
ja: デフォルトでは、``ANSIBLE_PERSISTENT_CONNECT_RETRY_TIMEOUT`` は 15 (秒) に設定されます。この値が低すぎると、以下のエラーが表示される可能性があります。

en: Increase the value of the persistent connection idle timeout. Note: This value should be greater than the SSH timeout value (the timeout value under the defaults section in the configuration file) and less than the value of the persistent connection idle timeout (connect_timeout).
ja: 持続的接続アイドルタイムアウトの値を増やします。注意: この値は、SSH タイムアウト値 (設定ファイルのデフォルトセクションの下のタイムアウト値) より大きく、永続的接続アイドルタイムアウト値 (connect_timeout) より小さくする必要があります。

en: Timeout issue due to platform specific login menu with ``network_cli`` connection type
ja: ``network_cli`` 接続タイプを持つプラットフォーム固有のログインメニューによるタイムアウトの問題

en: In Ansible 2.9 and later, the network_cli connection plugin configuration options are added to handle the platform specific login menu. These options can be set as group/host or tasks variables.
ja: Ansible 2.9 以降では、プラットフォーム固有のログインメニューを処理するために network_cli 接続プラグイン設定オプションが追加されました。これらのオプションは、グループ/ホストまたはタスク変数として設定できます。

en: Example: Handle single login menu prompts with host variables
ja: 例: ホスト変数を使用した 1 つのログインメニュープロンプトを処理します。

en: Example: Handle remote host multiple login menu prompts with host variables
ja: 例: ホスト変数を使用したリモートホストの複数のログインメニュープロンプトを処理します。

en: To handle multiple login menu prompts:
ja: 複数のログインメニュープロンプトを処理するには、以下を行います。

en: The values of ``ansible_terminal_initial_prompt`` and ``ansible_terminal_initial_answer`` should be a list.
ja: ``ansible_terminal_initial_prompt`` および ``ansible_terminal_initial_answer`` の値は一覧形式である必要があります。

en: The prompt sequence should match the answer sequence.
ja: プロンプトシーケンスは、応答シーケンスに一致する必要があります。

en: The value of ``ansible_terminal_initial_prompt_checkall`` should be set to ``True``.
ja: ``ansible_terminal_initial_prompt_checkall`` の値は ``True`` に設定する必要があります。

en: If all the prompts in sequence are not received from remote host at the time connection initialization it will result in a timeout.
ja: 接続の初期化時に、リモートホストからシーケンス内のすべてのプロンプトを受け取らないと、タイムアウトが生じます。

en: This section details issues are caused by issues with the Playbook itself.
ja: 本セクションでは、Playbook 自体の問題が原因で発生する問題を詳しく説明します。

en: **Platforms:** Arista EOS and Cisco IOS
ja: **プラットフォーム:** Arista EOS および Cisco IOS

en: This occurs when you attempt to run a task that requires privileged mode in a user mode shell.
ja: これは、ユーザーモードシェルで特権モードを必要とするタスクを実行しようとすると発生します。

en: Use ``connection: ansible.netcommon.network_cli`` and ``become: yes``
ja: ``connection: ansible.netcommon.network_cli`` および ``become: yes`` の使用

en: Proxy Issues
ja: プロキシーの問題

en: delegate_to vs ProxyCommand
ja: delegate_to 対 ProxyCommand

en: In order to use a bastion or intermediate jump host to connect to network devices over ``cli`` transport, network modules support the use of ``ProxyCommand``.
ja: bastion または中間ジャンプホストを使用して ``cli`` トランスポートでネットワークデバイスに接続するために、ネットワークモジュールは ``ProxyCommand`` の使用に対応します。

en: To use ``ProxyCommand``, configure the proxy settings in the Ansible inventory file to specify the proxy host.
ja: ``ProxyCommand`` を使用するには、Ansible インベントリーファイルでプロキシー設定を設定して、プロキシーホストを指定します。

en: With the configuration above, simply build and run the playbook as normal with no additional changes necessary.  The network module will now connect to the network device by first connecting to the host specified in ``ansible_ssh_common_args``, which is ``bastion01`` in the above example.
ja: 上記の設定では、追加の変更を必要とせずに、通常どおり Playbook をビルドして実行します。ネットワークモジュールは、最初に ``ansible_ssh_common_args`` で指定したホスト (上記の例は ``bastion01``) に接続して、ネットワークデバイスに接続します。

en: You can also set the proxy target for all hosts by using environment variables.
ja: 環境変数を使用して、すべてのホストのプロキシーターゲットを設定することもできます。

en: Using bastion/jump host with netconf connection
ja: netconf 接続での bastion/ジャンプホストの使用

en: Enabling jump host setting
ja: ジャンプホスト設定の有効化

en: Bastion/jump host with netconf connection can be enabled by:
ja: netconf 接続を持つ bastion/ジャンプホストは、以下で有効にできます。

en: Setting Ansible variable ``ansible_netconf_ssh_config`` either to ``True`` or custom ssh config file path
ja: Ansible 変数 ``ansible_netconf_ssh_config`` を ``True`` またはカスタムの ssh 設定ファイルパスに設定

en: Setting environment variable ``ANSIBLE_NETCONF_SSH_CONFIG`` to ``True`` or custom ssh config file path
ja: 環境変数 ``ANSIBLE_NETCONF_SSH_CONFIG`` を ``True`` またはカスタムの ssh 設定ファイルパスに設定

en: Setting ``ssh_config = 1`` or ``ssh_config = <ssh-file-path>`` under ``netconf_connection`` section
ja: ``ssh_config = 1`` セクションの下に ``ssh_config = <ssh-file-path>`` または ``netconf_connection`` の設定

en: If the configuration variable is set to 1 the proxycommand and other ssh variables are read from default ssh config file (~/.ssh/config).
ja: 設定変数が 1 に設定されている場合、proxycommand およびその他の ssh 変数はデフォルトの ssh 設定ファイル (~/.ssh/config) から読み込まれます。

en: If the configuration variable is set to file path the proxycommand and other ssh variables are read from the given custom ssh file path
ja: 設定変数がファイルパスに設定されていると、proxycommand およびその他の ssh 変数は指定のカスタム ssh ファイルパスから読み込まれます。

en: Example ssh config file (~/.ssh/config)
ja: ssh 設定ファイルの例 (~/.ssh/config)

en: Example Ansible inventory file
ja: Ansible インベントリーファイルの例

en: Using ``ProxyCommand`` with passwords via variables
ja: 変数を介したパスワードでの ``ProxyCommand`` の使用

en: By design, SSH doesn't support providing passwords via environment variables. This is done to prevent secrets from leaking out, for example in ``ps`` output.
ja: 設計上、SSH は環境変数経由でパスワードの提供をサポートしません。これは、``ps`` の出力など、シークレットがリークしないようにします。

en: We recommend using SSH Keys, and if needed an ssh-agent, rather than passwords, where ever possible.
ja: SSH 鍵を使用することを推奨します。必要に応じて、可能な場合は、パスワードではなく ssh-agent を使用することが推奨されます。

en: Miscellaneous Issues
ja: その他の問題

en: Intermittent failure while using ``ansible.netcommon.network_cli`` connection type
ja: ``ansible.netcommon.network_cli`` 接続タイプの使用中に断続的な失敗

en: If the command prompt received in response is not matched correctly within the ``ansible.netcommon.network_cli`` connection plugin the task might fail intermittently with truncated response or with the error message ``operation requires privilege escalation``. Starting in 2.7.1 a new buffer read timer is added to ensure prompts are matched properly and a complete response is send in output. The timer default value is 0.2 seconds and can be adjusted on a per task basis or can be set globally in seconds.
ja: 応答で受け取ったコマンドプロンプトが ``ansible.netcommon.network_cli`` 接続プラグイン内で正しく一致しないと、タスクが断続的に失敗し、応答が切り捨てられるか、エラーメッセージ ``operation requires privilege escalation`` が表示されることがあります。2.7.1 以降、プロンプトが正しく一致し、完全な応答が出力に送信されるように、新しいバッファ読み取りタイマーが追加されました。タイマーのデフォルト値は 0.2 秒で、タスクごとに調整することも、秒単位でグローバルに設定することもできます。

en: Example Per task timer setting
ja: タスクタイマーごとの設定例

en: This timer delay per command executed on remote host can be disabled by setting the value to zero.
ja: リモートホストで実行されるコマンド別のこのタイマー遅延は、値をゼロに設定すると無効にできます。

en: Task failure due to mismatched error regex within command response using ``ansible.netcommon.network_cli`` connection type
ja: ``ansible.netcommon.network_cli`` 接続タイプを使用したコマンド応答内のエラー正規表現の不一致によるタスクの失敗

en: In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration options are added to handle the stdout and stderr regex to identify if the command execution response consist of a normal response or an error response. These options can be set group/host variables or as tasks variables.
ja: Ansible 2.9 以降では、``ansible.netcommon.network_cli`` 接続プラグイン設定オプションが追加され、標準出力と標準エラーの正規表現を処理して、コマンド実行応答が通常の応答かエラー応答かを識別します。これらのオプションは、グループ/ホスト変数またはタスク変数として設定できます。

en: Example: For mismatched error response
ja: 例: 不一致のエラー応答の場合

en: Playbook run output:
ja: Playbook 実行の出力:

en: Modify the error regex for individual task.
ja: 個々のタスクのエラー正規表現を変更します。

en: The terminal plugin regex options ``ansible_terminal_stderr_re`` and ``ansible_terminal_stdout_re`` have ``pattern`` and ``flags`` as keys. The value of the ``flags`` key should be a value that is accepted by the ``re.compile`` python method.
ja: 端末プラグインの正規表現オプション ``ansible_terminal_stderr_re`` および ``ansible_terminal_stdout_re`` は、``pattern`` と ``flags`` をキーとします。``flags`` キーの値は、``re.compile`` python メソッドで許可される値である必要があります。

en: Intermittent failure while using ``ansible.netcommon.network_cli`` connection type due to slower network or remote target host
ja: 低速ネットワークまたはリモートターゲットホストによる ``ansible.netcommon.network_cli`` 接続タイプの使用時の断続的な失敗

en: In Ansible 2.9 and later, the ``ansible.netcommon.network_cli`` connection plugin configuration option is added to control the number of attempts to connect to a remote host. The default number of attempts is three. After every retry attempt the delay between retries is increased by power of 2 in seconds until either the maximum attempts are exhausted or either the ``persistent_command_timeout`` or ``persistent_connect_timeout`` timers are triggered.
ja: Ansible 2.9 以降では、リモートホストへの接続の試行回数を制御するために、``ansible.netcommon.network_cli`` 接続プラグイン設定オプションが追加されました。デフォルトの試行回数は 3 回です。再試行のたびに、最大試行回数がなくなるか、``persistent_command_timeout`` または ``persistent_connect_timeout`` タイマーのいずれかが発生するまで、再試行間の遅延は 2 の累乗 (秒) ずつ増加します。

en: Network Resource Modules
ja: ネットワークリソースモジュール

en: Ansible network resource modules simplify and standardize how you manage different network devices. Network devices separate configuration into sections (such as interfaces and VLANs) that apply to a network service. Ansible network resource modules take advantage of this to allow you to configure subsections or *resources* within the network device configuration. Network resource modules provide a consistent experience across different network devices.
ja: Ansible ネットワークリソースモジュールは、さまざまなネットワークデバイスの管理方法を簡素化し、標準化します。ネットワークデバイスは、ネットワークサービスに適用されるセクション (インターフェースや VLAN など) に設定を分割します。Ansible ネットワークリソースモジュールはこれを利用して、ネットワークデバイス設定内でサブセクションや *リソース* を設定することができます。ネットワークリソースモジュールは、異なるネットワークデバイス間で一貫したエクスペリエンスを提供します。

en: Network resource module states
ja: ネットワークリソースモジュールの状態

en: You use the network resource modules by assigning a state to what you want the module to do. The resource modules support the following states:
ja: モジュールの動作に状態を割り当てて、ネットワークリソースモジュールを使用します。リソースモジュールは以下の状態をサポートします。

en: Using network resource modules
ja: ネットワークリソースモジュールの使用

en: This example configures the L3 interface resource on a Cisco IOS device, based on different state settings.
ja: この例では、異なる状態設定に基づいて、Cisco IOS デバイスで L3 インターフェースリソースを設定します。

en: The following table shows an example of how an initial resource configuration changes with this task for different states.
ja: 以下の表は、このタスクで初期リソースの設定が異なる状態で変化する例を示しています。

en: Resource starting configuration
ja: リソース起動の設定

en: task-provided configuration (YAML)
ja: タスク提供設定 (YAML)

en: Final resource configuration on device
ja: デバイスの最終的なリソース設定

en: *merged*
ja: *マージ*

en: *replaced*
ja: *置き換え済*

en: *overridden*
ja: *上書き済*

en: Incorrect use case. This would remove all interfaces from the device
ja: 誤ったユースケース。これにより、デバイスからすべてのインターフェースが削除されます。

en: (including the mgmt interface) except
ja: (mgmt インターフェースを含む) 以下を除く

en: the configured loopback100
ja: 設定されている loopback100

en: *deleted*
ja: *削除済*

en: Network resource modules return the following details:
ja: ネットワークリソースモジュールは、以下の詳細を返します。

en: The *before* state -  the existing resource configuration before the task was executed.
ja: *before* 状態 - タスクの実行前の既存リソース設定。

en: The *after* state - the new resource configuration that exists on the network device after the task was executed.
ja: *after* 状態 - タスク実行後にネットワークデバイスに存在する新しいリソース設定。

en: Commands - any commands configured on the device.
ja: コマンド - このデバイスに設定されるすべてのコマンド。

en: Example: Verifying the network device configuration has not changed
ja: 例: ネットワークデバイス設定が変更されていないことを確認

en: The following playbook uses the :ref:`arista.eos.eos_l3_interfaces <ansible_collections.arista.eos.eos_l3_interfaces_module>` module to gather a subset of the network device configuration (Layer 3 interfaces only) and verifies the information is accurate and has not changed. This playbook passes the results of :ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>` directly to the ``arista.eos.eos_l3_interfaces`` module.
ja: 以下の Playbook は、:ref:`arista.eos.eos_l3_interfaces <ansible_collections.arista.eos.eos_l3_interfaces_module>` モジュールを使用してネットワークデバイス設定のサブセット (レイヤー 3 インターフェースのみ) を収集し、情報が正確であり、変更されていないことを確認します。この Playbook は、:ref:`arista.eos.eos_facts <ansible_collections.arista.eos.eos_facts_module>` の結果を直接 ``arista.eos.eos_l3_interfaces`` モジュールに渡します。

en: Example: Acquiring and updating VLANs on a network device
ja: 例: ネットワークデバイスの VLAN の調整および更新

en: This example shows how you can use resource modules to:
ja: 以下の例は、リソースモジュールを使用して以下を行う方法を示しています。

en: Retrieve the current configuration on a network device.
ja: ネットワークデバイスの現在の設定を取得します。

en: Save that configuration locally.
ja: その設定をローカルに保存します。

en: Update that configuration and apply it to the network device.
ja: その設定を更新して、ネットワークデバイスに適用します。

en: This example uses the ``cisco.ios.ios_vlans`` resource module to retrieve and update the VLANs on an IOS device.
ja: この例では、``cisco.ios.ios_vlans`` リソースモジュールを使用して、IOS デバイスの VLAN を取得および更新します。

en: Retrieve the current IOS VLAN configuration:
ja: 現在の IOS VLAN 設定を取得します。

en: Store the VLAN configuration locally:
ja: VLAN 設定をローカルに保存します。

en: Modify the stored file to update the VLAN configuration locally.
ja: 保存したファイルを変更して、VLAN 設定をローカルに更新します。

en: Merge the updated VLAN configuration with the existing configuration on the device:
ja: 更新された VLAN 設定を、デバイス上の既存の設定とマージします。

en: A introductory blog post on network resource modules.
ja: ネットワークリソースモジュールに関する入門ブログの投稿

en: A deeper dive presentation into network resource modules.
ja: ネットワークリソースモジュールの詳細な説明

en: Working with command output and prompts in network modules
ja: ネットワークモジュールのコマンド出力およびプロンプトの使用

en: Conditionals in networking modules
ja: ネットワークモジュールの条件

en: Ansible allows you to use conditionals to control the flow of your playbooks. Ansible networking command modules use the following unique conditional statements.
ja: Ansible では、条件を使用して Playbook のフローを制御できます。Ansible ネットワークコマンドモジュールは、以下の固有の条件付きステートメントを使用します。

en: ``eq`` - Equal
ja: ``eq`` - 等しい

en: ``neq`` - Not equal
ja: ``neq`` - 等しくない

en: ``gt`` - Greater than
ja: ``gt`` - より大きい

en: ``ge`` - Greater than or equal
ja: ``ge`` - より大きいか等しい

en: ``lt`` - Less than
ja: ``lt`` - より小さい

en: ``le`` - Less than or equal
ja: ``le`` - より小さいか等しい

en: ``contains`` - Object contains specified item
ja: ``contains`` - オブジェクトに指定された項目が含まれる

en: Conditional statements evaluate the results from the commands that are executed remotely on the device.  Once the task executes the command set, the ``wait_for`` argument can be used to evaluate the results before returning control to the Ansible playbook.
ja: 条件文は、デバイス上でリモートに実行されるコマンドの結果を評価します。タスクがコマンドセットを実行すると、Ansible Playbook に制御を戻す前に、``wait_for`` 引数を使用して結果を評価できます。

en: For example::
ja: 例::

en: In the above example task, the command :code:`show interface Ethernet4 | json` is executed on the remote device and the results are evaluated.  If the path :code:`(result[0].interfaces.Ethernet4.interfaceStatus)` is not equal to "connected", then the command is retried.  This process continues until either the condition is satisfied or the number of retries has expired (by default, this is 10 retries at 1 second intervals).
ja: 上記のタスク例では、リモートデバイスで command :code:`show interface Ethernet4 | json` が実行され、結果が評価されます。path :code:`(result[0].interfaces.Ethernet4.interfaceStatus)`が「connected」になっていなければ、コマンドは再試行されます。この処理は、条件が満たされるか、再試行回数が期限切れになる (デフォルトでは、1 秒間隔で 10 回の再試行) まで継続されます。

en: The commands module can also evaluate more than one set of command results in an interface.  For instance::
ja: また、commands モジュールは、1 つのインターフェースで複数のコマンド結果を評価することもできます。たとえば、以下のようになります。

en: In the above example, two commands are executed on the remote device, and the results are evaluated.  By specifying the result index value (0 or 1), the correct result output is checked against the conditional.
ja: 上記の例では、2 つのコマンドがリモートデバイスで実行され、結果が評価されます。結果のインデックス値 (0 または 1) を指定することで、条件に対して正しい結果出力が確認されます。

en: The ``wait_for`` argument must always start with result and then the command index in ``[]``, where ``0`` is the first command in the commands list, ``1`` is the second command, ``2`` is the third and so on.
ja: ``wait_for`` 引数は、必ず結果で、次に ``[]`` のコマンドインデックスが必要です。``0`` はコマンドリストの最初のコマンド、``1`` は 2 番目のコマンド、``2`` は 3 番目のコマンドなどになります。

en: Handling prompts in network modules
ja: ネットワークモジュールのプロンプトの処理

en: Network devices may require that you answer a prompt before performing a change on the device. Individual network modules such as :ref:`cisco.ios.ios_command <ansible_collections.cisco.ios.ios_command_module>` and :ref:`cisco.nxos.nxos_command <ansible_collections.cisco.nxos.nxos_command_module>` can handle this with a ``prompt`` parameter.
ja: ネットワークデバイスは、デバイスの変更を実行する前にプロンプトの回答が必要になる場合があります。:ref:`cisco.ios.ios_command <ansible_collections.cisco.ios.ios_command_module>` および :ref:`cisco.nxos.nxos_command <ansible_collections.cisco.nxos.nxos_command_module>` などの個別ネットワークモジュールは ``prompt`` パラメーターでこれを処理できます。

en: ``prompt`` is a Python regex. If you add special characters such as ``?`` in the ``prompt`` value, the prompt won't match and you will get a timeout. To avoid this, ensure that the ``prompt`` value is a Python regex that matches the actual device prompt. Any special characters must be handled correctly in the ``prompt`` regex.
ja: ``prompt`` は Python の正規表現です。``prompt`` 値に ``?`` などの特殊文字を追加すると、プロンプトが一致せず、タイムアウトが発生します。これを回避するには、``prompt`` 値が実際のデバイスプロンプトと一致する Python 正規表現であることを確認します。特殊文字は、``prompt`` 正規表現で正しく処理する必要があります。

en: You can also use the :ref:`ansible.netcommon.cli_command <ansible_collections.ansible.netcommon.cli_command_module>` to handle multiple prompts.
ja: :ref:`ansible.netcommon.cli_command <ansible_collections.ansible.netcommon.cli_command_module>` を使用して、複数のプロンプトを処理することもできます。

en: You must list the prompt and the answers in the same order (that is, prompt[0] is answered by answer[0]).
ja: プロンプトと回答を同じ順序で一覧表示する必要があります (つまり、prompt[0] には answer[0] で応答します)。

en: In the above example, ``check_all: True`` ensures that the task gives the matching answer to each prompt. Without that setting, a task with multiple prompts would give the first answer to every prompt.
ja: 上記の例では、``check_all: True`` により、タスクが各プロンプトに一致する応答を返すようにします。この設定がないと、複数のプロンプトがあるタスクでは、すべてのプロンプトに対して最初の応答が表示されます。

en: In the following example, the second answer would be ignored and ``y`` would be the answer given to both prompts. That is, this task only works because both answers are identical. Also notice again that ``prompt`` must be a Python regex, which is why the ``?`` is escaped in the first prompt.
ja: 次の例では、2 番目の回答は無視され、両方のプロンプトに ``y`` が入力されます。つまり、このタスクが機能するのは、両方の答えが同じだからです。また、``prompt`` は Python の正規表現でなければならないことにも注意してください。このため、``?`` は最初のプロンプトでエスケープされます。

en: Examples using ``wait_for``, ``wait_for_connection``, and ``prompt`` for network devices.
ja: ネットワークデバイス用に ``wait_for``、``wait_for_connection``、および ``prompt`` を使用する例。

en: Detailed overview of how to use the ``cli_command``.
ja: ``cli_command`` の使用方法に関する詳細な概要

en: CloudEngine OS Platform Options
ja: CloudEngine OS プラットフォームオプション

en: CloudEngine CE OS is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it.
ja: CloudEngine CE OS は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、複数の接続をサポートします。このページでは、Ansible での各接続がどのように機能し、どのように使用されるかを詳細に説明します。

en: Connections available
ja: 利用可能な接続

en: Credentials
ja: 認証情報

en: uses SSH keys / SSH-agent if present
ja: SSH キー/SSH-agent が存在する場合は使用します

en: accepts ``-u myuser -k`` if using password
ja: パスワードを使用する場合に ``-u myuser -k`` を受け入れます。

en: Indirect Access
ja: 間接アクセス

en: via a bastion (jump host)
ja: bastion (jump ホスト) を使用

en: Connection Settings
ja: 接続設定

en: not supported by ce OS
ja: ce OS ではサポートなし

en: Returned Data Format
ja: 返されるデータ形式

en: Refer to individual module documentation
ja: 各モジュールのドキュメンテーションを参照してください。

en: The ``ansible_connection: local`` has been deprecated. Please use  ``ansible_connection: ansible.netcommon.netconf`` or ``ansible_connection=ansible.netcommon.network_cli`` instead.
ja: ``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.netconf`` または ``ansible_connection=ansible.netcommon.network_cli`` を使用してください。

en: Using CLI in Ansible
ja: Ansible での CLI の使用

en: Example CLI inventory ``[ce:vars]``
ja: CLI インベントリーの例 ``[ce:vars]``

en: If you are using SSH keys (including an ssh-agent) you can remove the ``ansible_password`` configuration.
ja: SSH キー (ssh-agent を含む) を使用している場合は、``ansible_password`` 設定を削除できます。

en: If you are accessing your host directly (not through a bastion/jump host) you can remove the ``ansible_ssh_common_args`` configuration.
ja: (bastion/ジャンプホストを経由せず) ホストに直接アクセスしている場合は、``ansible_ssh_common_args`` 設定を削除できます。

en: If you are accessing your host through a bastion/jump host, you cannot include your SSH password in the ``ProxyCommand`` directive. To prevent secrets from leaking out (for example in ``ps`` output), SSH does not support providing passwords via environment variables.
ja: bastion/ジャンプホストを介してホストにアクセスする場合は、``ProxyCommand`` ディレクティブに SSH パスワードを含めることができません。シークレットが漏洩するのを防ぐために (例: ``ps`` 出力)、SSH は環境変数によるパスワードの提供をサポートしません。

en: Example CLI task
ja: CLI タスクの例

en: Using NETCONF in Ansible
ja: Ansible での NETCONF の使用

en: Enabling NETCONF
ja: NETCONF の有効化

en: Before you can use NETCONF to connect to a switch, you must:
ja: NETCONF を使用してスイッチに接続する前に、以下を行う必要があります。

en: install the ``ncclient`` python package on your control node(s) with ``pip install ncclient``
ja: ``pip install ncclient`` を使用して、``ncclient`` python パッケージをコントロールノードにインストールします。

en: enable NETCONF on the CloudEngine OS device(s)
ja: CloudEngine OS デバイスでの NETCONF の有効化

en: To enable NETCONF on a new switch using Ansible, use the ``community.network.ce_config`` module with the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:
ja: Ansibleを使用する新しいスイッチで NETCONF を有効にするには、CLI 接続でモジュールを ``community.network.ce_config`` 使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のような Playbook タスクを実行します。

en: Once NETCONF is enabled, change your variables to use the NETCONF connection.
ja: NETCONF を有効にしたら、変数を変更して NETCONF 接続を使用します。

en: Example NETCONF inventory ``[ce:vars]``
ja: NETCONF インベントリーの例 ``[ce:vars]``

en: Example NETCONF task
ja: NETCONF タスクの例

en: Notes
ja: 備考

en: Modules that work with ``ansible.netcommon.network_cli``
ja: ``ansible.netcommon.network_cli`` と連携するモジュール

en: Modules that work with ``ansible.netcommon.netconf``
ja: ``ansible.netcommon.netconf`` と連携するモジュール

en: Never store passwords in plain text. We recommend using SSH keys to authenticate SSH connections. Ansible supports ssh-agent to manage your SSH keys. If you must use passwords to authenticate SSH connections, we recommend encrypting them with :ref:`Ansible Vault <playbooks_vault>`.
ja: パスワードをプレーンテキストで保存しないでください。SSH キーを使用して SSH 接続を認証することが推奨されます。Ansible は SSH キーを管理するための ssh-agent をサポートしています。SSH 接続の認証にパスワードを使用する必要がある場合は、:ref:`Ansible Vault <playbooks_vault>` で暗号化することが推奨されます。

en: CNOS Platform Options
ja: CNOS プラットフォームのオプション

en: CNOS is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on CNOS in Ansible.
ja: CNOS は、`community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の CNOS で Enable Mode を有効にする方法を詳細に説明します。

en: supported: use ``ansible_become: yes`` with ``ansible_become_method: enable`` and ``ansible_become_password:``
ja: サポート対象: ``ansible_become: yes`` を、``ansible_become_method: enable`` および ``ansible_become_password:`` と併用します。

en: The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` instead.
ja: ``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` を使用してください。

en: Example CLI ``group_vars/cnos.yml``
ja: CLI の例 ``group_vars/cnos.yml``

en: Dell OS10 Platform Options
ja: Dell OS10 プラットフォームオプション

en: The `dellemc.os10 <https://galaxy.ansible.com/dellemc_networking/os10>`_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS10 in Ansible.
ja: `dellemc.os10 <https://galaxy.ansible.com/dellemc_networking/os10>`_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS10 で Enable Mode を使用する方法に関する詳細が記載されています。

en: Example CLI ``group_vars/dellos10.yml``
ja: CLI の例 ``group_vars/dellos10.yml``

en: Dell OS6 Platform Options
ja: Dell OS6 プラットフォームオプション

en: The `dellemc.os6 <https://github.com/ansible-collections/dellemc.os6>`_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS6 in Ansible.
ja: `dellemc.os6 <https://github.com/ansible-collections/dellemc.os6>`_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS6 で Enable Mode の使用方法に関する詳細が記載されています。

en: Example CLI ``group_vars/dellos6.yml``
ja: CLI の例 ``group_vars/dellos6.yml``

en: Dell OS9 Platform Options
ja: Dell OS9 プラットフォームオプション

en: The `dellemc.os9 <https://github.com/ansible-collections/dellemc.os9>`_ collection  supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on OS9 in Ansible.
ja: `dellemc.os9 <https://github.com/ansible-collections/dellemc.os9>`_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の OS9 で Enable Mode の使用方法に関する詳細が記載されています。

en: Example CLI ``group_vars/dellos9.yml``
ja: CLI の例 ``group_vars/dellos9.yml``

en: ENOS Platform Options
ja: ENOS プラットフォームのオプション

en: ENOS is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ENOS in Ansible.
ja: ENOS は、`community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の ENOS で Enable Mode を有効にする方法を説明します。

en: Example CLI ``group_vars/enos.yml``
ja: CLI の例 ``group_vars/enos.yml``

en: EOS Platform Options
ja: EOS プラットフォームのオプション

en: The `Arista EOS <https://galaxy.ansible.com/arista/eos>`_ collection supports multiple connections. This page offers details on how each connection works in Ansible and how to use it.
ja: `Arista EOS <https://galaxy.ansible.com/arista/eos>`_ コレクションは複数の接続をサポートします。このページでは、各接続がどのように Ansible でどのように機能するかと、その使用方法を説明します。

en: uses HTTPS certificates if present
ja: HTTPS 証明書が存在する場合は使用します。

en: via a web proxy
ja: Web プロキシー経由

en: supported: |br|
ja: サポート対象: |br|

en: use ``ansible_become: yes`` with ``ansible_become_method: enable``
ja: ``ansible_become: yes`` を ``ansible_become_method: enable`` と併用します。

en: ``httpapi`` uses ``ansible_become: yes`` with ``ansible_become_method: enable``
ja: ``httpapi`` は、``ansible_become: yes`` を ``ansible_become_method: enable`` と併用します。

en: The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi`` instead.
ja: ``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.httpapi`` を使用してください。

en: Example CLI ``group_vars/eos.yml``
ja: CLI の例 ``group_vars/eos.yml``

en: Using eAPI in Ansible
ja: Ansible での eAPI の使用

en: Enabling eAPI
ja: EAPI の有効化

en: Before you can use eAPI to connect to a switch, you must enable eAPI. To enable eAPI on a new switch with Ansible, use the ``arista.eos.eos_eapi`` module through the CLI connection. Set up ``group_vars/eos.yml`` just like in the CLI example above, then run a playbook task like this:
ja: eAPI を使用してスイッチに接続する前に、eAPI を有効にする必要があります。Ansible を使用する新しいスイッチで eAPI を有効にするには、CLI 接続を介して ``arista.eos.eos_eapi`` モジュールを使用します。上記の CLI の例のように ``group_vars/eos.yml`` を設定し、次のように Playbook タスクを実行します。

en: You can find more options for enabling HTTP/HTTPS connections in the :ref:`arista.eos.eos_eapi <ansible_collections.arista.eos.eos_eapi_module>` module documentation.
ja: HTTP/HTTPS 接続を有効にするオプションの詳細は、:ref:`arista.eos.eos_eapi <ansible_collections.arista.eos.eos_eapi_module>` モジュールのドキュメントを参照してください。

en: Once eAPI is enabled, change your ``group_vars/eos.yml`` to use the eAPI connection.
ja: eAPI を有効にしたら、``group_vars/eos.yml`` を変更して eAPI 接続を使用します。

en: Example eAPI ``group_vars/eos.yml``
ja: eAPI の例 ``group_vars/eos.yml``

en: If you are accessing your host directly (not through a web proxy) you can remove the ``proxy_env`` configuration.
ja: (Web プロキシーを経由せず) ホストに直接アクセスしている場合は、``proxy_env`` 設定を削除できます。

en: If you are accessing your host through a web proxy using ``https``, change ``http_proxy`` to ``https_proxy``.
ja: ``https`` を使用して Web プロキシー経由でホストにアクセスする場合は、``http_proxy`` を ``https_proxy`` に変更します。

en: Example eAPI task
ja: eAPI タスクの例

en: In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module in the task.
ja: この例では、``group_vars`` で定義された ``proxy_env`` 変数が、タスクで使用されるモジュールの ``environment`` オプションに渡されます。

en: ERIC_ECCLI Platform Options
ja: ERIC_ECCLI プラットフォームのオプション

en: Extreme ERIC_ECCLI is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and only supports CLI connections today. This page offers details on how to use ``ansible.netcommon.network_cli`` on ERIC_ECCLI in Ansible.
ja: Extreme ERIC_ECCLI は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、現在は CLI 接続のみに対応しています。このページでは、Ansible の ERIC_ECCLI で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。

en: not supported by ERIC_ECCLI
ja: ERIC_ECCLI ではサポートされません。

en: ERIC_ECCLI does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``.
ja: ERIC_ECCLI は、``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。

en: Example CLI ``group_vars/eric_eccli.yml``
ja: CLI の例 ``group_vars/eric_eccli.yml``

en: EXOS Platform Options
ja: EXOS プラットフォームのオプション

en: Extreme EXOS is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and supports multiple connections. This page offers details on how each connection works in Ansible and how to use it.
ja: Extreme EXOS は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、複数の接続をサポートします。このページでは、Ansible での各接続がどのように機能し、どのように使用されるかを詳細に説明します。

en: not supported by EXOS
ja: EXOS ではサポートされません

en: EXOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.httpapi``.
ja: EXOS は、``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.httpapi`` を使用する必要があります。

en: Example CLI ``group_vars/exos.yml``
ja: CLI の例 ``group_vars/exos.yml``

en: Using EXOS-API in Ansible
ja: Ansible での EXOS-API の使用

en: Example EXOS-API ``group_vars/exos.yml``
ja: EXOS-API の例 ``group_vars/exos.yml``

en: Example EXOS-API task
ja: EXOS-API タスクの例

en: In this example the ``proxy_env`` variable defined in ``group_vars`` gets passed to the ``environment`` option of the module used in the task.
ja: この例では、``proxy_env`` で定義された ``group_vars`` 変数は、タスクで使用されるモジュールの ``environment`` オプションに渡されます。

en: FRR Platform Options
ja: FRR プラットフォームのオプション

en: The `FRR <https://galaxy.ansible.com/frr/frr>`_ collection supports the ``ansible.netcommon.network_cli`` connection. This section provides details on how to use this connection for Free Range Routing (FRR).
ja: `FRR <https://galaxy.ansible.com/frr/frr>`_ コレクションは、``ansible.netcommon.network_cli`` 接続をサポートします。本セクションでは、この接続を Free Range Routing (FRR) に使用する方法を説明します。

en: not supported
ja: サポート対象外

en: Example CLI ``group_vars/frr.yml``
ja: CLI の例 ``group_vars/frr.yml``

en: The ``ansible_user`` should be a part of the ``frrvty`` group and should have the default shell set to ``/bin/vtysh``.
ja: ``ansible_user`` は ``frrvty`` グループに含まれるはずです。デフォルトのシェルは ``/bin/vtysh`` に設定する必要があります。

en: ICX Platform Options
ja: ICX プラットフォームのオプション

en: ICX is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on ICX in Ansible.
ja: ICX は、`community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の ICX で Enable Mode を有効にする方法を説明します。

en: Example CLI ``group_vars/icx.yml``
ja: CLI の例 ``group_vars/icx.yml``

en: Platform Options
ja: プラットフォームのオプション

en: Some Ansible Network platforms support multiple connection types, privilege escalation (``enable`` mode), or other options. The pages in this section offer standardized guides to understanding available options on each network platform. We welcome contributions from community-maintained platforms to this section.
ja: 一部の Ansible Network プラットフォームは、複数の接続タイプ、権限エスカレーション (``enable`` モード) 、またはその他のオプションをサポートしています。本セクションのページでは、各ネットワークプラットフォームで利用可能なオプションを理解する標準ガイドが紹介されています。コミュニティーが管理するプラットフォームから、このセクションへの貢献を歓迎いたします。

en: Settings by Platform
ja: プラットフォーム別の設定

en: ``ansible_connection:`` settings available
ja: ``ansible_connection:`` 設定が利用可能

en: Network OS
ja: ネットワーク OS

en: OS that supports Netconf `[†]`_
ja: Netconf に対応する OS `[†]`_

en: **[†]** Maintained by Ansible Network Team
ja: **[†]** Ansible Network Team が管理

en: IOS Platform Options
ja: IOS プラットフォームのオプション

en: The `Cisco IOS <https://galaxy.ansible.com/cisco/ios>`_ collection supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IOS in Ansible.
ja: `Cisco IOS <https://galaxy.ansible.com/cisco/ios>`_ コレクションは Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の IOS で Enable Mode を有効にする方法を説明します。

en: Example CLI ``group_vars/ios.yml``
ja: CLI の例 ``group_vars/ios.yml``

en: IOS-XR Platform Options
ja: IOS-XR プラットフォームのオプション

en: The `Cisco IOS-XR collection <https://galaxy.ansible.com/cisco/iosxr>`_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it.
ja: `Cisco IOS-XR collection <https://galaxy.ansible.com/cisco/iosxr>`_ は複数の接続をサポートします。このページでは、Ansible で各接続がどのように機能するか、およびその使用方法を詳細に説明します。

en: only for modules ``iosxr_banner``, ``iosxr_interface``, ``iosxr_logging``, ``iosxr_system``, ``iosxr_user``
ja: モジュールの ``iosxr_banner``、``iosxr_interface``、``iosxr_logging``、``iosxr_system``、``iosxr_user`` のみ

en: The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.network_cli`` or ``ansible_connection: ansible.netcommon.netconf`` instead.
ja: ``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.network_cli`` または ``ansible_connection: ansible.netcommon.netconf`` を使用してください。

en: Example CLI inventory ``[iosxr:vars]``
ja: CLI インベントリーの例 ``[iosxr:vars]``

en: enable NETCONF on the Cisco IOS-XR device(s)
ja: Cisco IOS-XR デバイスで NETCONF を有効にします。

en: To enable NETCONF on a new switch via Ansible, use the ``cisco.iosxr.iosxr_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:
ja: Ansible を介して新しいスイッチで NETCONF を有効にするには、CLI 接続を介して ``cisco.iosxr.iosxr_netconf`` モジュールを使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のように Playbook タスクを実行します。

en: Example NETCONF inventory ``[iosxr:vars]``
ja: NETCONF インベントリーの例 ``[iosxr:vars]``

en: IronWare Platform Options
ja: IronWare プラットフォームのオプション

en: IronWare is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and supports Enable Mode (Privilege Escalation). This page offers details on how to use Enable Mode on IronWare in Ansible.
ja: IronWare は、`community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、Enable Mode (Privilege Escalation) をサポートします。このページでは、Ansible の IronWare で Enable Mode を有効にする方法を説明します。

en: Example CLI ``group_vars/mlx.yml``
ja: CLI の例 ``group_vars/mlx.yml``

en: Junos OS Platform Options
ja: Junos OS プラットフォームのオプション

en: The `Juniper Junos OS <https://galaxy.ansible.com/junipernetworks/junos>`_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it.
ja: `Juniper Junos OS <https://galaxy.ansible.com/junipernetworks/junos>`_ は複数の接続をサポートします。このページでは、Ansible で各接続がどのように機能するか、およびその使用方法を詳細に説明します。

en: ``junos_netconf`` & ``junos_command`` modules only
ja: ``junos_netconf`` モジュールおよび ``junos_command`` モジュールのみ

en: all modules except ``junos_netconf``, which enables NETCONF
ja: NETCONF を有効にする ``junos_netconf`` 以外のすべてのモジュール

en: not supported by Junos OS
ja: Junos OS ではサポートされません

en: text: ``result[1].interface-information[0].physical-interface[0].name[0].data foo lo0``
ja: テキスト: ``result[1].interface-information[0].physical-interface[0].name[0].data foo lo0``

en: Example CLI inventory ``[junos:vars]``
ja: CLI インベントリーの例 ``[junos:vars]``

en: enable NETCONF on the Junos OS device(s)
ja: Junos OS デバイスの netconf を有効にします。

en: To enable NETCONF on a new switch via Ansible, use the ``junipernetworks.junos.junos_netconf`` module through the CLI connection. Set up your platform-level variables just like in the CLI example above, then run a playbook task like this:
ja: Ansible を介して新しいスイッチで NETCONF を有効にするには、CLI 接続を介して ``junipernetworks.junos.junos_netconf`` モジュールを使用します。上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のように Playbook タスクを実行します。

en: Example NETCONF inventory ``[junos:vars]``
ja: NETCONF インベントリーの例 ``[junos:vars]``

en: Meraki Platform Options
ja: Meraki プラットフォームのオプション

en: The `cisco.meraki <https://galaxy.ansible.com/cisco/meraki>`_ collection only supports the ``local`` connection type at this time.
ja: `cisco.meraki <https://galaxy.ansible.com/cisco/meraki>`_ コレクションは、現時点では ``local`` 接続タイプのみをサポートします。

en: Dashboard API
ja: ダッシュボード API

en: uses API key from Dashboard
ja: Dashboard からの API キーの使用

en: Example Meraki task
ja: Meraki タスクの例

en: Netconf enabled Platform Options
ja: Netconf が有効なプラットフォームオプション

en: This page offers details on how the netconf connection works in Ansible and how to use it.
ja: このページには、netconf 接続が Ansible でどのように機能するか、およびその詳細な使用方法が記載されています。

en: The ``ansible_connection: local`` has been deprecated. Please use ``ansible_connection: ansible.netcommon.netconf`` instead.
ja: ``ansible_connection: local`` は非推奨になりました。代わりに ``ansible_connection: ansible.netcommon.netconf`` を使用してください。

en: install the ``ncclient`` Python package on your control node(s) with ``pip install ncclient``
ja: ``pip install ncclient`` を使用して、``ncclient`` Python パッケージをコントロールノードにインストールします。

en: To enable NETCONF on a new switch via Ansible, use the platform specific module via the CLI connection or set it manually. For example set up your platform-level variables just like in the CLI example above, then run a playbook task like this:
ja: Ansible 経由で新しいスイッチの NETCONF を有効にするには、CLI 接続経由でプラットフォーム固有のモジュールを使用するか、手動で設定します。たとえば、上記の CLI の例のようにプラットフォームレベルの変数を設定し、次のような Playbook タスクを実行します。

en: Example NETCONF task with configurable variables
ja: 設定可能な変数を含む NETCONF タスクの例

en: Note: For netconf connection plugin configurable variables see :ref:`ansible.netcommon.netconf <ansible_collections.ansible.netcommon.netconf_connection>`.
ja: 注意: netconf 接続プラグインの設定可能な変数は、「:ref:`ansible.netcommon.netconf <ansible_collections.ansible.netcommon.netconf_connection>`」を参照してください。

en: Bastion/Jumphost configuration
ja: Bastion/Jumphost の設定

en: To use a jump host to connect to a NETCONF enabled device you must set the ``ANSIBLE_NETCONF_SSH_CONFIG`` environment variable.
ja: ジャンプホストを使用して NETCONF 対応のデバイスに接続するには、``ANSIBLE_NETCONF_SSH_CONFIG`` 環境変数を設定する必要があります。

en: ``ANSIBLE_NETCONF_SSH_CONFIG`` can be set to either:
ja: ``ANSIBLE_NETCONF_SSH_CONFIG`` を、次のいずれかに設定できます。

en: 1 or TRUE (to trigger the use of the default SSH config file ~/.ssh/config)
ja: 1 または TRUE (デフォルトの SSH 設定ファイル ~/.ssh/config の使用を開始するため)。

en: The absolute path to a custom SSH config file.
ja: カスタムの SSH 設定ファイルへの絶対パス。

en: The SSH config file should look something like:
ja: SSH 設定ファイルは以下のようになります。

en: Authentication for the jump host must use key based authentication.
ja: ジャンプホストの認証は、鍵ベースの認証を使用する必要があります。

en: You can either specify the private key used in the SSH config file:
ja: SSH 設定ファイルで使用する秘密鍵のいずれかを指定できます。

en: Or you can use an ssh-agent.
ja: または、ssh-agent を使用できます。

en: ansible_network_os auto-detection
ja: ansible_network_os 自動検出

en: If ``ansible_network_os`` is not specified for a host, then Ansible will attempt to automatically detect what ``network_os`` plugin to use.
ja: ホストに ``ansible_network_os`` が指定されていない場合、Ansible は、使用する ``network_os`` プラグインを自動的に検出しようとします。

en: ``ansible_network_os`` auto-detection can also be triggered by using ``auto`` as the ``ansible_network_os``. (Note: Previously ``default`` was used instead of ``auto``).
ja: ``ansible_network_os`` 自動検出は、``auto`` を ``ansible_network_os`` として使用することで発生させることもできます (注意: 以前は ``default`` の代わりに ``auto``が使用されていました)。

en: Pluribus NETVISOR Platform Options
ja: Pluribus NETVISOR プラットフォームのオプション

en: Pluribus NETVISOR Ansible is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on NETVISOR in Ansible.
ja: Pluribus NETVISOR Ansible は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の NETVISOR で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。

en: not supported by NETVISOR
ja: NETVISOR ではサポートされません

en: Pluribus NETVISOR does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``.
ja: Pluribus NETVISOR は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。

en: Example CLI ``group_vars/netvisor.yml``
ja: CLI の例 ``group_vars/netvisor.yml``

en: NOS Platform Options
ja: NOS プラットフォームのオプション

en: Extreme NOS is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on NOS in Ansible.
ja: Extreme NOS は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の NOS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。

en: not supported by NOS
ja: NOS ではサポートされません

en: NOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``.
ja: NOS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。

en: Example CLI ``group_vars/nos.yml``
ja: CLI の例 ``group_vars/nos.yml``

en: NXOS Platform Options
ja: NXOS プラットフォームのオプション

en: The `Cisco NXOS <https://galaxy.ansible.com/cisco/nxos>`_ supports multiple connections. This page offers details on how each connection works in Ansible and how to use it.
ja: `Cisco NXOS <https://galaxy.ansible.com/cisco/nxos>`_ は複数の接続をサポートします。このページでは、Ansible で各接続がどのように機能するか、およびその使用方法を詳細に説明します。

en: not supported by NX-API
ja: NX-API ではサポートされません

en: Example CLI ``group_vars/nxos.yml``
ja: CLI の例 ``group_vars/nxos.yml``

en: Using NX-API in Ansible
ja: Ansible での NX-API の使用

en: Enabling NX-API
ja: NX-API の有効化

en: Before you can use NX-API to connect to a switch, you must enable NX-API. To enable NX-API on a new switch via Ansible, use the ``nxos_nxapi`` module via the CLI connection. Set up group_vars/nxos.yml just like in the CLI example above, then run a playbook task like this:
ja: NX-API を使用してスイッチに接続する前に、NX-API を有効にする必要があります。Ansible を介して新しいスイッチで NX-API を有効にするには、CLI 接続を介して ``nxos_nxapi`` モジュールを使用します。前述の CLI の例と同様に group_vars/nxos.yml を設定し、次のように Playbook タスクを実行します。

en: To find out more about the options for enabling HTTP/HTTPS and local http see the :ref:`nxos_nxapi <nxos_nxapi_module>` module documentation.
ja: HTTP/HTTPS およびローカル http を有効にするオプションの詳細は、:ref:`nxos_nxapi <nxos_nxapi_module>` モジュールのドキュメントを参照してください。

en: Once NX-API is enabled, change your ``group_vars/nxos.yml`` to use the NX-API connection.
ja: NX-API を有効にしたら、NX-API 接続を使用するように ``group_vars/nxos.yml`` を変更します。

en: Example NX-API ``group_vars/nxos.yml``
ja: NX-API の例 ``group_vars/nxos.yml``

en: Example NX-API task
ja: NX-API タスクの例

en: Cisco Nexus platform support matrix
ja: Cisco Nexus プラットフォームのサポートマトリックス

en: The following platforms and software versions have been certified by Cisco to work with this version of Ansible.
ja: 以下のプラットフォームおよびソフトウェアのバージョンは、Cisco が本バージョンの Ansible で機能することが認定されています。

en: Platform / Software Minimum Requirements
ja: プラットフォーム/ソフトウェア最小要件

en: Supported Platforms
ja: サポート対象のプラットフォーム

en: Minimum NX-OS Version
ja: 最小 NX-OS バージョン

en: 7.0(3)I2(5) and later
ja: 7.0(3)I2(5) 以降

en: 7.3(0)N1(1) and later
ja: 7.3(0)N1(1) 以降

en: 7.3(0)D1(1) and later
ja: 7.3(0)D1(1) 以降

en: 8.4(1) and later
ja: 8.4(1) 以降

en: Platform Models
ja: プラットフォームモデル

en: Platform
ja: プラットフォーム

en: Description
ja: 説明

en: Support includes N30xx, N31xx and N35xx models
ja: サポートには、N30xx モデル、N31xx モデル、および N35xx モデルが含まれます。

en: Support includes all N5xxx models
ja: サポートには、N5xxx の全モデルが含まれます。

en: Support includes all N6xxx models
ja: サポートには、N6xxx の全モデルが含まれます。

en: Support includes all N7xxx models
ja: サポートには、N7xxx の全モデルが含まれます。

en: Support includes all N9xxx models
ja: サポートには、N9xxx の全モデルが含まれます。

en: Support includes all MDS 9xxx models
ja: サポートには、MDS 9xxx モデルがすべて含まれます。

en: RouterOS Platform Options
ja: RouterOS プラットフォームのオプション

en: RouterOS is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on RouterOS in Ansible.
ja: RouterOS は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の RouterOS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。

en: not supported by RouterOS
ja: RouterOS ではサポートされません

en: RouterOS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``.
ja: RouterOS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。

en: Example CLI ``group_vars/routeros.yml``
ja: CLI の例 ``group_vars/routeros.yml``

en: If you are getting timeout errors you may want to add ``+cet1024w`` suffix to your username which will disable console colors, enable "dumb" mode, tell RouterOS not to try detecting terminal capabilities and set terminal width to 1024 columns. See article `Console login process <https://wiki.mikrotik.com/wiki/Manual:Console_login_process>`_ in MikroTik wiki for more information.
ja: タイムアウトエラーが発生した場合は、ユーザー名に ``+cet1024w`` 接頭辞を追加することでコンソールの色を無効にし、「dumb」モードを有効にし、端末機能を検出しないように RouterOS に指示し、端末の幅を 1024 カラムに設定することができます。詳細は、MikroTik Wikiの記事「`Console login process <https://wiki.mikrotik.com/wiki/Manual:Console_login_process>`_」を参照してください。

en: SLX-OS Platform Options
ja: SLX-OS プラットフォームのオプション

en: Extreme SLX-OS is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and only supports CLI connections today. ``httpapi`` modules may be added in future. This page offers details on how to use ``ansible.netcommon.network_cli`` on SLX-OS in Ansible.
ja: Extreme SLX-OS は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、現在は CLI 接続のみをサポートしています。将来的に ``httpapi`` モジュールが追加される可能性があります。このページでは、Ansible の SLX-OS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。

en: not supported by SLX-OS
ja: SLX-OS ではサポートされません

en: SLX-OS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``.
ja: SLX-OS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。

en: Example CLI ``group_vars/slxos.yml``
ja: CLI の例 ``group_vars/slxos.yml``

en: VOSS Platform Options
ja: VOSS プラットフォームのオプション

en: Extreme VOSS is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and only supports CLI connections today. This page offers details on how to use ``ansible.netcommon.network_cli`` on VOSS in Ansible.
ja: Extreme VOSS は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、現在は CLI 接続のみをサポートしています。このページでは、Ansible の VOSS で ``ansible.netcommon.network_cli`` を使用する方法を詳細に説明します。

en: supported: use ``ansible_become: yes`` with ``ansible_become_method: enable``
ja: サポート対象: ``ansible_become: yes`` を ``ansible_become_method: enable`` と併用してください。

en: VOSS does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``.
ja: VOSS は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。

en: Example CLI ``group_vars/voss.yml``
ja: CLI の例 ``group_vars/voss.yml``

en: VyOS Platform Options
ja: VyOS プラットフォームのオプション

en: The `VyOS <https://galaxy.ansible.com/vyos/vyos>`_ collection supports the ``ansible.netcommon.network_cli`` connection type. This page offers details on connection options to manage VyOS using Ansible.
ja: `VyOS <https://galaxy.ansible.com/vyos/vyos>`_ コレクションは、``ansible.netcommon.network_cli`` 接続タイプをサポートします。このページでは、Ansible を使用して VyOS を管理する接続オプションの詳細を提供します。

en: Example CLI ``group_vars/vyos.yml``
ja: CLI の例 ``group_vars/vyos.yml``

en: WeOS 4 Platform Options
ja: WeOS 4 プラットフォームオプション

en: Westermo WeOS 4 is part of the `community.network <https://galaxy.ansible.com/community/network>`_ collection and only supports CLI connections. This page offers details on how to use ``ansible.netcommon.network_cli`` on WeOS 4 in Ansible.
ja: Westermo WeOS 4 は `community.network <https://galaxy.ansible.com/community/network>`_ コレクションの一部で、CLI 接続のみをサポートします。このページでは、Ansible の WeOS 4 で ``ansible.netcommon.network_cli`` を使用する方法を説明します。

en: not supported by WeOS 4
ja: WeOS 4 でサポート対象外

en: WeOS 4 does not support ``ansible_connection: local``. You must use ``ansible_connection: ansible.netcommon.network_cli``.
ja: WeOS 4 は ``ansible_connection: local`` をサポートしません。``ansible_connection: ansible.netcommon.network_cli`` を使用する必要があります。

en: Example CLI ``group_vars/weos4.yml``
ja: CLI の例 ``group_vars/weos4.yml``

en: Example Configuration task
ja: 設定タスクの例
