msgid "This page provides a basic overview of correct YAML syntax, which is how Ansible playbooks (our configuration management language) are expressed."
msgid "We use YAML because it is easier for humans to read and write than other common data formats like XML or JSON. Further, there are libraries available in most programming languages for working with YAML."
msgid "For Ansible, nearly every YAML file starts with a list. Each item in the list is a list of key/value pairs, commonly called a \"hash\" or a \"dictionary\". So, we need to know how to write lists and dictionaries in YAML."
msgid "There's another small quirk to YAML. All YAML files (regardless of their association with Ansible or not) can optionally begin with ``---`` and end with ``...``. This is part of the YAML format and indicates the start and end of a document."
msgid "Values can span multiple lines using ``|`` or ``>``. Spanning multiple lines using a \"Literal Block Scalar\" ``|`` will include the newlines and any trailing spaces. Using a \"Folded Block Scalar\" ``>`` will fold newlines to spaces; it's used to make what would otherwise be a very long line easier to read and edit. In either case the indentation will be ignored. Examples are::"
msgid "Let's combine what we learned so far in an arbitrary YAML example. This really has nothing to do with Ansible, but will give you a feel for the format::"
msgid "While you can put just about anything into an unquoted scalar, there are some exceptions. A colon followed by a space (or newline) ``\": \"`` is an indicator for a mapping. A space followed by the pound sign ``\" #\"`` starts a comment."
msgid "Further, Ansible uses \"{{ var }}\" for variables. If a value after a colon starts with a \"{\", YAML will think it is a dictionary, so you must quote it, like so::"
msgid "If your value starts with a quote the entire value must be quoted, not just part of it. Here are some additional examples of how to properly quote things::"
msgid "In addition to ``'`` and ``\"`` there are a number of characters that are special (or reserved) and cannot be used as the first character of an unquoted scalar: ``[] {} > | * & ! % # ` @ ,``."
msgid "You should also be aware of ``? : -``. In YAML, they are allowed at the beginning of a string if a non-space character follows, but YAML processor implementations differ, so it's better to use quotes."
msgid "Boolean conversion is helpful, but this can be a problem when you want a literal `yes` or other boolean values as a string. In these cases just use quotes::"
msgid "YAML converts certain strings into floating-point values, such as the string `1.0`. If you need to specify a version number (in a requirements.yml file, for example), you will need to quote the value if it looks like a floating-point value::"
msgid "`Ansible Automation Hub <https://www.ansible.com/products/automation-hub>`_ is the official location to discover and download supported :ref:`collections <collections>`, included as part of an Ansible Automation Platform subscription. These content collections contain modules, plugins, roles, and playbooks in a downloadable package."
msgid "Ansible Automation Hub gives you direct access to trusted content collections from Red Hat and Certified Partners. You can find content by topic or Ansible Partner organizations."
msgstr "Ansible Automation Hub を使用すると、Red Hat および認定パートナーから、信頼できるコンテンツコレクションに直接アクセスできます。コンテンツは、トピック別または Ansible パートナー組織別に検索できます。"
msgid "Ansible Automation Hub is the downstream Red Hat supported product version of Ansible Galaxy. Find out more about Ansible Automation Hub features and how to access it at `Ansible Automation Hub <https://www.ansible.com/products/automation-hub>`_. Ansible Automation Hub is part of the Red Hat Ansible Automation Platform subscription, and comes bundled with support from Red Hat, Inc."
msgstr "Ansible Automation Hub は、Red Hat がサポートする Ansible Galaxy の製品バージョン (ダウンストリーム) です。Ansible Automation Hub の機能とそのアクセス方法の詳細は、「`Ansible Automation Hub <https://www.ansible.com/products/automation-hub>`_」を参照してください。Ansible Automation Hub は、Red Hat Ansible Automation Platform サブスクリプションで利用でき、Red Hat, Inc のサポートが含まれています。"
msgid "Ansible modules normally return a data structure that can be registered into a variable, or seen directly when output by the `ansible` program. Each module can optionally document its own unique return values (visible through ansible-doc and on the :ref:`main docsite<ansible_documentation>`)."
msgid "Information on differences between the previous and current state. Often a dictionary with entries ``before`` and ``after``, which will then be formatted by the callback plugin to a diff view."
msgid "Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on), this field contains 'return code' of these utilities."
msgid "Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on), this field contains the error output of these utilities."
msgid "Some modules execute command line utilities or are geared for executing commands directly (raw, shell, command, and so on). This field contains the normal output of these utilities."
msgid "This key should contain a dictionary which will be appended to the facts assigned to the host. These will be directly accessible and don't require using a registered variable."
msgid "This key contains a list of dictionaries that will be presented to the user. Keys of the dictionaries are `msg` and `version`, values are string, value for the `version` key can be an empty string."
msgid "Ansible supports several sources for configuring its behavior, including an ini file named ``ansible.cfg``, environment variables, command-line options, playbook keywords, and variables. See :ref:`general_precedence_rules` for details on the relative precedence of each source."
msgstr "Ansible は、``ansible.cfg`` という名前の ini ファイル、環境変数、コマンドラインオプション、Playbook のキーワード、変数など、動作を設定するための複数のソースをサポートします。各ソースの相対優先順位に関する詳細は「:ref:`general_precedence_rules`」を参照してください。"
#: ../../rst/reference_appendices/config.rst:9
msgid "The ``ansible-config`` utility allows users to see all the configuration settings available, their defaults, how to set them and where their current value comes from. See :ref:`ansible-config` for more information."
msgid "The configuration file is one variant of an INI format. Both the hash sign (``#``) and semicolon (``;``) are allowed as comment markers when the comment starts the line. However, if the comment is inline with regular values, only the semicolon is allowed to introduce the comment. For instance::"
msgid "If Ansible were to load ``ansible.cfg`` from a world-writable current working directory, it would create a serious security risk. Another user could place their own config file there, designed to make Ansible run malicious code both locally and remotely, possibly with elevated privileges. For this reason, Ansible will not automatically load a config file from the current working directory if the directory is world-writable."
msgid "If you depend on using Ansible with a config file in the current working directory, the best way to avoid this problem is to restrict access to your Ansible directories to particular user(s) and/or group(s). If your Ansible directories live on a filesystem which has to emulate Unix permissions, like Vagrant or Windows Subsystem for Linux (WSL), you may, at first, not know how you can fix this as ``chmod``, ``chown``, and ``chgrp`` might not work there. In most of those cases, the correct fix is to modify the mount options of the filesystem so the files and directories are readable and writable by the users and groups running Ansible but closed to others. For more details on the correct settings, see:"
msgstr "現在の作業ディレクトリーの設定ファイルで Ansible を使用する場合、この問題を回避する最善の方法は、Ansible ディレクトリーへのアクセスを特定のユーザーやグループに制限することです。Ansible ディレクトリーが、Vagrant や Windows Subsystem for Linux (WSL) などの Unix パーミッションをエミュレートする必要があるファイルシステムに存在する場合、そこでは ``chmod``、``chown``、および ``chgrp`` が機能しない可能性があるため、最初はどのように修正するか分からない場合があります。ほとんどの場合は、適切な修正が、ファイルシステムのマウントオプションを修正することです。これにより、ファイルおよびディレクトリーは、Ansible を実行しているユーザーおよびグループが読み取りおよび書き込みをできるようになり、他のユーザーには許可しないようにすることができます。正しい設定の詳細は、以下を参照してください。"
msgid "for WSL, the `WSL docs <https://docs.microsoft.com/en-us/windows/wsl/wsl-config#set-wsl-launch-settings>`_ and this `Microsoft blog post <https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/>`_ cover mount options."
msgstr "WSL の場合、`WSL docs <https://docs.microsoft.com/en-us/windows/wsl/wsl-config#set-wsl-launch-settings>`_ とこの `Microsoft blog post <https://blogs.msdn.microsoft.com/commandline/2018/01/12/chmod-chown-wsl-improvements/>`_ はマウントオプションに対応しています。"
#: ../../rst/reference_appendices/config.rst:67
msgid "If you absolutely depend on storing your Ansible config in a world-writable current working directory, you can explicitly specify the config file via the :envvar:`ANSIBLE_CONFIG` environment variable. Please take appropriate steps to mitigate the security concerns above before doing so."
msgid "You can specify a relative path for many configuration options. In most of those cases the path used will be relative to the ``ansible.cfg`` file used for the current execution. If you need a path relative to your current working directory (CWD) you can use the ``{{CWD}}`` macro to specify it. We do not recommend this approach, as using your CWD as the root of relative paths can be a security risk. For example: ``cd /tmp; secureinfo=./newrootpassword ansible-playbook ~/safestuff/change_root_pwd.yml``."
msgid "This is a copy of the options available from our release, your local install might have extra options due to additional plugins, you can use the command line utility mentioned above (`ansible-config`) to browse through those."
msgid "By default Ansible will issue a warning when received from a task action (module or action plugin) These warnings can be silenced by adjusting this setting to False."
msgid "Display an agnostic become prompt instead of displaying a prompt containing the command line supplied become method"
msgstr "become メソッドを提供するコマンドラインを含むプロンプトを表示する代わりに、依存しない become プロンプトを表示します。"
#: ../../rst/reference_appendices/config.rst:118
#: ../../rst/reference_appendices/config.rst:290
#: ../../rst/reference_appendices/config.rst:1075
#: ../../rst/reference_appendices/config.rst:1089
#: ../../rst/reference_appendices/config.rst:1102
#: ../../rst/reference_appendices/config.rst:1115
#: ../../rst/reference_appendices/config.rst:1128
#: ../../rst/reference_appendices/config.rst:1141
msgid "[privilege_escalation]"
msgstr "[privilege_escalation]"
#: ../../rst/reference_appendices/config.rst:119
msgid "agnostic_become_prompt"
msgstr "agnostic_become_prompt"
#: ../../rst/reference_appendices/config.rst:121
msgid ":envvar:`ANSIBLE_AGNOSTIC_BECOME_PROMPT`"
msgstr ":envvar:`ANSIBLE_AGNOSTIC_BECOME_PROMPT`"
#: ../../rst/reference_appendices/config.rst:126
msgid "ALLOW_WORLD_READABLE_TMPFILES"
msgstr "ALLOW_WORLD_READABLE_TMPFILES"
#: ../../rst/reference_appendices/config.rst:128
msgid "This makes the temporary files created on the machine world-readable and will issue a warning instead of failing the task. It is useful when becoming an unprivileged user."
msgid "Specify where to look for the ansible-connection script. This location will be checked before searching $PATH. If null, ansible will start with the same directory as the ansible script."
msgid "Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer. This can result in a very significant performance improvement when enabled. However this conflicts with privilege escalation (become). For example, when using 'sudo:' operations you must first disable 'requiretty' in /etc/sudoers on all managed hosts, which is why it is disabled by default. This option is disabled if ``ANSIBLE_KEEP_REMOTE_FILES`` is enabled. This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all."
msgid "Prefix to use for cache plugin files/tables"
msgstr "cache プラグインファイル/テーブルに使用する接頭辞"
#: ../../rst/reference_appendices/config.rst:345
msgid "fact_caching_prefix"
msgstr "fact_caching_prefix"
#: ../../rst/reference_appendices/config.rst:347
msgid ":envvar:`ANSIBLE_CACHE_PLUGIN_PREFIX`"
msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN_PREFIX`"
#: ../../rst/reference_appendices/config.rst:352
msgid "CACHE_PLUGIN_TIMEOUT"
msgstr "CACHE_PLUGIN_TIMEOUT"
#: ../../rst/reference_appendices/config.rst:354
#: ../../rst/reference_appendices/config.rst:3255
msgid "Expiration timeout for the cache plugin data"
msgstr "cache プラグインデータの有効期限のタイムアウト"
#: ../../rst/reference_appendices/config.rst:355
#: ../../rst/reference_appendices/config.rst:1278
#: ../../rst/reference_appendices/config.rst:1307
#: ../../rst/reference_appendices/config.rst:1693
#: ../../rst/reference_appendices/config.rst:1735
#: ../../rst/reference_appendices/config.rst:1905
#: ../../rst/reference_appendices/config.rst:2028
#: ../../rst/reference_appendices/config.rst:2084
#: ../../rst/reference_appendices/config.rst:2712
#: ../../rst/reference_appendices/config.rst:2726
#: ../../rst/reference_appendices/config.rst:2968
#: ../../rst/reference_appendices/config.rst:3062
#: ../../rst/reference_appendices/config.rst:3079
msgid "integer"
msgstr "integer"
#: ../../rst/reference_appendices/config.rst:356
msgid "86400"
msgstr "86400"
#: ../../rst/reference_appendices/config.rst:359
msgid "fact_caching_timeout"
msgstr "fact_caching_timeout"
#: ../../rst/reference_appendices/config.rst:361
msgid ":envvar:`ANSIBLE_CACHE_PLUGIN_TIMEOUT`"
msgstr ":envvar:`ANSIBLE_CACHE_PLUGIN_TIMEOUT`"
#: ../../rst/reference_appendices/config.rst:366
msgid "CALLABLE_ACCEPT_LIST"
msgstr "CALLABLE_ACCEPT_LIST"
#: ../../rst/reference_appendices/config.rst:368
#: ../../rst/reference_appendices/config.rst:3553
#: ../../rst/reference_appendices/config.rst:3563
msgid "Whitelist of callable methods to be made available to template evaluation"
msgstr "テンプレート評価で利用できる呼び出し可能なメソッドのホワイトリスト"
#: ../../rst/reference_appendices/config.rst:370
#: ../../rst/reference_appendices/config.rst:395
#: ../../rst/reference_appendices/config.rst:1428
#: ../../rst/reference_appendices/config.rst:1519
#: ../../rst/reference_appendices/config.rst:2001
#: ../../rst/reference_appendices/config.rst:2554
#: ../../rst/reference_appendices/config.rst:2924
#: ../../rst/reference_appendices/config.rst:2939
msgid "[]"
msgstr "[]"
#: ../../rst/reference_appendices/config.rst:373
msgid "callable_whitelist"
msgstr "callable_whitelist"
#: ../../rst/reference_appendices/config.rst:376
#: ../../rst/reference_appendices/config.rst:378
msgid "callable_enabled"
msgstr "callable_enabled"
#: ../../rst/reference_appendices/config.rst:381
msgid ":envvar:`ANSIBLE_CALLABLE_ENABLED`"
msgstr ":envvar:`ANSIBLE_CALLABLE_ENABLED`"
#: ../../rst/reference_appendices/config.rst:383
msgid ":envvar:`ANSIBLE_CALLABLE_WHITELIST`"
msgstr ":envvar:`ANSIBLE_CALLABLE_WHITELIST`"
#: ../../rst/reference_appendices/config.rst:386
#: ../../rst/reference_appendices/config.rst:3559
msgid "ANSIBLE_CALLABLE_ENABLED"
msgstr "ANSIBLE_CALLABLE_ENABLED"
#: ../../rst/reference_appendices/config.rst:391
msgid "CALLBACKS_ENABLED"
msgstr "CALLBACKS_ENABLED"
#: ../../rst/reference_appendices/config.rst:393
#: ../../rst/reference_appendices/config.rst:3588
#: ../../rst/reference_appendices/config.rst:3598
msgid "List of enabled callbacks, not all callbacks need enabling, but many of those shipped with Ansible do as we don't want them activated by default."
msgid "When a collection is loaded that does not support the running Ansible version (via the collection metadata key `requires_ansible`), the default behavior is to issue a warning and continue anyway. Setting this value to `ignore` skips the warning entirely, while setting it to `fatal` will immediately halt Ansible execution."
msgid "Colon separated paths in which Ansible will search for collections content. Collections must be in nested *subdirectories*, not directly in these directories. For example, if ``COLLECTIONS_PATHS`` includes ``~/.ansible/collections``, and you want to add ``my.collection`` to that directory, it must be saved as ``~/.ansible/collections/ansible_collections/my/collection``."
msgid "Defines the color to use when emitting warning messages"
msgstr "警告メッセージを生成するときに使用する色を定義します。"
#: ../../rst/reference_appendices/config.rst
#: ../../rst/reference_appendices/config.rst:922
#: ../../rst/reference_appendices/config.rst:2158
#: ../../rst/reference_appendices/config.rst:2881
msgid "warn"
msgstr "warn"
#: ../../rst/reference_appendices/config.rst:924
msgid ":envvar:`ANSIBLE_COLOR_WARN`"
msgstr ":envvar:`ANSIBLE_COLOR_WARN`"
#: ../../rst/reference_appendices/config.rst:929
msgid "COMMAND_WARNINGS"
msgstr "COMMAND_WARNINGS"
#: ../../rst/reference_appendices/config.rst:931
msgid "Ansible can issue a warning when the shell or command module is used and the command appears to be similar to an existing Ansible module. These warnings can be silenced by adjusting this setting to False. You can also control this at the task level with the module option ``warn``. As of version 2.11, this is disabled by default."
msgid "the command warnings feature is being removed"
msgstr "コマンド警告機能が削除されています。"
#: ../../rst/reference_appendices/config.rst:946
msgid "CONDITIONAL_BARE_VARS"
msgstr "CONDITIONAL_BARE_VARS"
#: ../../rst/reference_appendices/config.rst:948
msgid "With this setting on (True), running conditional evaluation 'var' is treated differently than 'var.subkey' as the first is evaluated directly while the second goes through the Jinja2 parser. But 'false' strings in 'var' get evaluated as booleans. With this setting off they both evaluate the same but in cases in which 'var' was 'false' (a string) it won't get evaluated as a boolean anymore. Currently this setting defaults to 'True' but will soon change to 'False' and the setting itself will be removed in the future. Expect that this setting eventually will be deprecated after 2.12"
msgid "Sets the output directory on the remote host to generate coverage reports to. Currently only used for remote coverage on PowerShell modules. This is for internal use only."
msgid "A list of paths for files on the Ansible controller to run coverage for when executing on the remote host. Only files that match the path glob will have its coverage collected. Multiple path globs can be specified and are separated by ``:``. Currently only used for remote coverage on PowerShell modules. This is for internal use only."
msgid "When enabled, this option allows lookup plugins (whether used in variables as ``{{lookup('foo')}}`` or as a loop as with_foo) to return data that is not marked 'unsafe'. By default, such data is marked as unsafe to prevent the templating engine from evaluating any jinja2 templating language, as this could represent a security risk. This option is provided to allow for backwards-compatibility, however users should first consider adding allow_unsafe=True to any lookups which may be expected to contain data which may be run through the templating engine late"
msgid "This controls whether an Ansible playbook should prompt for a login password. If using SSH keys for authentication, you probably do not need to change this setting."
msgid "Toggles debug output in Ansible. This is *very* verbose and can hinder multiprocessing. Debug output can also include secret information despite no_log settings being enabled, which means debug mode should not be used in production."
msgid "This indicates the command to use to spawn a shell under for Ansible's execution needs on a target. Users may need to change this in rare instances when shell usage is constrained, but in most cases it may be left as is."
msgid "This option allows you to globally configure a custom path for 'local_facts' for the implied M(ansible.builtin.setup) task when using fact gathering. If not set, it will fallback to the default from the M(ansible.builtin.setup) module: ``/etc/ansible/facts.d``. This does **not** affect user defined tasks that use the M(ansible.builtin.setup) module."
msgid "This option controls if notified handlers run on a host even if a failure occurs on that host. When false, the handlers will not run if a failure has occurred on a host. This can also be set per play or on the command line. See Handlers and Failure for more details."
msgid "Set the `gather_subset` option for the M(ansible.builtin.setup) task in the implicit fact gathering. See the module documentation for specifics. It does **not** apply to user defined M(ansible.builtin.setup) tasks."
msgid "This setting controls the default policy of fact gathering (facts discovered about remote systems). When 'implicit' (the default), the cache plugin will be ignored and facts will be gathered per play unless 'gather_facts: False' is set. When 'explicit' the inverse is true, facts will not be gathered unless directly requested in the play. The 'smart' value means each new host that has no facts discovered will be scanned, but if the same host is addressed in multiple plays it will not be contacted again in the playbook run. This option can be useful for those wishing to save fact gathering time. Both 'smart' and 'explicit' will use the cache plugin."
msgid "Since 2.0 M(ansible.builtin.include) can be 'dynamic', this setting (if True) forces that if the include appears in a ``handlers`` section to be 'static'."
msgid "This setting controls how duplicate definitions of dictionary variables (aka hash, map, associative array) are handled in Ansible. This does not affect variables whose values are scalars (integers, strings) or arrays. **WARNING**, changing this setting is not recommended as this is fragile and makes your content (plays, roles, collections) non portable, leading to continual confusion and misuse. Don't change this setting unless you think you have an absolute need for it. We recommend avoiding reusing variable names and relying on the ``combine`` filter and ``vars`` and ``varnames`` lookups to create merged versions of the individual variables. In our experience this is rarely really needed and a sign that too much complexity has been introduced into the data structures and plays. For some uses you can also look into custom vars_plugins to merge on input, even substituting the default ``host_group_vars`` that is in charge of parsing the ``host_vars/`` and ``group_vars/`` directories. Most users of this setting are only interested in inventory scope, but the setting itself affects all sources and makes debugging even harder. All playbooks and roles in the official examples repos assume the default for this setting. Changing the setting to ``merge`` applies across variable sources, but many sources will internally still overwrite the variables. For example ``include_vars`` will dedupe variables internally before updating Ansible, with 'last defined' overwriting previous definitions in same file. The Ansible project recommends you **avoid ``merge`` for new projects.** It is the intention of the Ansible developers to eventually deprecate and remove this setting, but it is being kept as some users do heavily rely on it. New projects should **avoid 'merge'**."
msgid "This sets the interval (in seconds) of Ansible internal processes polling each other. Lower values improve performance with large playbooks at the expense of extra CPU load. Higher values are more suitable for Ansible usage in automation scenarios, when UI responsiveness is not required but CPU usage might be a concern. The default corresponds to the value hardcoded in Ansible <= 2.1"
msgid "This is a developer-specific feature that allows enabling additional Jinja2 extensions. See the Jinja2 documentation for details. If you do not know what these do, you probably don't need to change this setting :)"
msgid "Enables/disables the cleaning up of the temporary files Ansible used to execute the tasks on the remote. If this option is enabled it will disable ``ANSIBLE_PIPELINING``."
msgid "This setting causes libvirt to connect to lxc containers by passing --noseclabel to virsh. This is necessary when running on systems which do not have SELinux."
msgid "environment variables without ``ANSIBLE_`` prefix are deprecated"
msgstr "``ANSIBLE_`` 接頭辞のない環境変数が非推奨になりました。"
#: ../../rst/reference_appendices/config.rst:1481
#: ../../rst/reference_appendices/config.rst:3766
msgid "the ``ANSIBLE_LIBVIRT_LXC_NOSECLABEL`` environment variable"
msgstr "``ANSIBLE_LIBVIRT_LXC_NOSECLABEL`` 環境変数"
#: ../../rst/reference_appendices/config.rst:1486
msgid "DEFAULT_LOAD_CALLBACK_PLUGINS"
msgstr "DEFAULT_LOAD_CALLBACK_PLUGINS"
#: ../../rst/reference_appendices/config.rst:1488
#: ../../rst/reference_appendices/config.rst:3778
msgid "Controls whether callback plugins are loaded when running /usr/bin/ansible. This may be used to log activity from the command line, send notifications, and so on. Callback plugins are always loaded for ``ansible-playbook``."
msgid "Sets the macro for the 'ansible_managed' variable available for M(ansible.builtin.template) and M(ansible.windows.win_template) modules. This is only relevant for those two modules."
msgid "Toggle Ansible logging to syslog on the target when it executes tasks. On Windows hosts this will disable a newer style PowerShell modules from writing to the event log."
msgid "For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how often to check back on the status of those tasks when an explicit poll interval is not supplied. The default is a reasonably moderate 15 seconds which is a tradeoff between checking in frequently and providing a quick turnaround when something may have completed."
msgid "Option for connections using a certificate or key file to authenticate, rather than an agent or passwords, you can set the default value here to avoid re-specifying --private-key with every invocation."
msgid "Makes role variables inaccessible from other roles. This was introduced as a way to reset role variables to default values if a role is used more than once in a playbook."
msgid "Some filesystems do not support safe operations and/or return inconsistent errors, this setting makes Ansible 'tolerate' those in the list w/o causing fatal errors. Data corruption may occur and writes are not always verified when a filesystem is in the list."
msgid "Set the main callback used to display Ansible output, you can only have one at a time. You can have many other callbacks, but just one can be in charge of stdout."
msgid "The `include` tasks can be static or dynamic, this toggles the default expected behaviour if autodetection fails and it is not explicitly set in task."
msgid "Default connection plugin to use, the 'smart' option will toggle between 'ssh' and 'paramiko' depending on controller OS and ssh versions"
msgstr "使用するデフォルトの connection プラグイン。「smart」オプションは、コントローラー OS と ssh のバージョンに応じて、「ssh」と「paramiko」の間で切り替えられます。"
#: ../../rst/reference_appendices/config.rst:1922
msgid "transport"
msgstr "transport"
#: ../../rst/reference_appendices/config.rst:1924
msgid ":envvar:`ANSIBLE_TRANSPORT`"
msgstr ":envvar:`ANSIBLE_TRANSPORT`"
#: ../../rst/reference_appendices/config.rst:1929
msgid "DEFAULT_UNDEFINED_VAR_BEHAVIOR"
msgstr "DEFAULT_UNDEFINED_VAR_BEHAVIOR"
#: ../../rst/reference_appendices/config.rst:1931
msgid "When True, this causes ansible templating to fail steps that reference variable names that are likely typoed. Otherwise, any '{{ template_expression }}' that contains undefined variables will be rendered in a template or ansible action line exactly as written."
msgid "The vault_id to use for encrypting by default. If multiple vault_ids are provided, this specifies which to use for encryption. The --encrypt-vault-id cli option overrides the configured value."
msgid "How many lines of context to show when displaying the differences between files."
msgstr "ファイル間の差異を表示する際に表示するコンテキストの行数。"
#: ../../rst/reference_appendices/config.rst:2085
msgid "3"
msgstr "3"
#: ../../rst/reference_appendices/config.rst:2088
msgid "context"
msgstr "context"
#: ../../rst/reference_appendices/config.rst:2090
msgid ":envvar:`ANSIBLE_DIFF_CONTEXT`"
msgstr ":envvar:`ANSIBLE_DIFF_CONTEXT`"
#: ../../rst/reference_appendices/config.rst:2095
msgid "DISPLAY_ARGS_TO_STDOUT"
msgstr "DISPLAY_ARGS_TO_STDOUT"
#: ../../rst/reference_appendices/config.rst:2097
msgid "Normally ``ansible-playbook`` will print a header for each task that is run. These headers will contain the name: field from the task if you specified one. If you didn't then ``ansible-playbook`` uses the task's action to help you tell which task is presently running. Sometimes you run many of the same action and so you want more information about the task to differentiate it from others of the same action. If you set this variable to True in the config then ``ansible-playbook`` will also include the task's arguments in the header. This setting defaults to False because there is a chance that you have sensitive values in your parameters and you do not want those to be printed. If you set this to True you should be sure that you have secured your environment's stdout (no one can shoulder surf your screen and you aren't saving stdout to an insecure file) or made sure that all of your playbooks explicitly added the ``no_log: True`` parameter to tasks which have sensitive values See How do I keep secret data in my playbook? for more information."
msgid "By default Ansible will issue a warning when a duplicate dict key is encountered in YAML. These warnings can be silenced by adjusting this setting to False."
msgid "Whether or not to enable the task debugger, this previously was done as a strategy plugin. Now all strategy plugins can inherit this behavior. The debugger defaults to activating when a task is failed on unreachable. Use the debugger keyword for more flexibility."
msgid "The directory that stores cached responses from a Galaxy server. This is only used by the ``ansible-galaxy collection install`` and ``download`` commands. Cache files inside this dir will be ignored if they are world writable."
msgid "Some steps in ``ansible-galaxy`` display a progress wheel which can cause issues on certain displays or when outputting the stdout to a file. This config option controls whether the display wheel is shown or not. The default is to show the display wheel if stdout has a tty."
msgid "If set to yes, ansible-galaxy will not validate TLS certificates. This can be useful for testing against a server with a self-signed certificate."
msgid "URL to prepend when roles don't specify the full URI, assume they are referencing this server as the source."
msgstr "ロールが完全な URI を指定していない場合に先頭に追加する URL。このサーバーがソースとして参照されていることを前提とします。"
#: ../../rst/reference_appendices/config.rst:2293
msgid "https://galaxy.ansible.com"
msgstr "https://galaxy.ansible.com"
#: ../../rst/reference_appendices/config.rst:2296
msgid "server"
msgstr "server"
#: ../../rst/reference_appendices/config.rst:2298
msgid ":envvar:`ANSIBLE_GALAXY_SERVER`"
msgstr ":envvar:`ANSIBLE_GALAXY_SERVER`"
#: ../../rst/reference_appendices/config.rst:2303
msgid "GALAXY_SERVER_LIST"
msgstr "GALAXY_SERVER_LIST"
#: ../../rst/reference_appendices/config.rst:2305
msgid "A list of Galaxy servers to use when installing a collection. The value corresponds to the config ini header ``[galaxy_server.{{item}}]`` which defines the server details. See :ref:`galaxy_server_config` for more details on how to define a Galaxy server. The order of servers in this list is used to as the order in which a collection is resolved. Setting this config option will ignore the :ref:`galaxy_server` config option."
msgid "Facts are available inside the `ansible_facts` variable, this setting also pushes them as their own vars in the main namespace. Unlike inside the `ansible_facts` dictionary, these will have an `ansible_` prefix."
msgid "Path to the Python interpreter to be used for module execution on remote targets, or an automatic discovery mode. Supported discovery modes are ``auto``, ``auto_silent``, and ``auto_legacy`` (the default). All discovery modes employ a lookup table to use the included system Python (on distributions known to include one), falling back to a fixed ordered list of well-known Python interpreter locations if a platform-specific default is not available. The fallback behavior will issue a warning that the interpreter should be set explicitly (since interpreters installed later may change which one is used). This warning behavior can be disabled by setting ``auto_silent``. The default value of ``auto_legacy`` provides all the same behavior, but for backwards-compatibility with older Ansible releases that always defaulted to ``/usr/bin/python``, will use that interpreter if present (and issue a warning that the default behavior will change to that of ``auto`` in a future Ansible release."
msgid "If 'true', it is a fatal error when any given inventory source cannot be successfully parsed by any available inventory plugin; otherwise, this situation only attracts a warning."
msgid "By default Ansible will issue a warning when there are no hosts in the inventory. These warnings can be silenced by adjusting this setting to False."
msgid "This variable is used to enable bastion/jump host with netconf connection. If set to True the bastion/jump host ssh settings should be present in ~/.ssh/config file, alternatively it can be set to custom ssh configuration file path to read the bastion/jump host settings."
msgid "Previously Ansible would only clear some of the plugin loading caches when loading new roles, this led to some behaviours in which a plugin loaded in previous plays would be unexpectedly 'sticky'. This setting allows to return to that behaviour."
msgid "This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host_vars/group_vars The ``top`` option follows the traditional behaviour of using the top playbook in the chain to find the root directory. The ``bottom`` option follows the 2.4.0 behaviour of using the current playbook to find the root directory. The ``all`` option examines from the first parent to the current playbook."
msgid "A path to configuration for filtering which plugins installed on the system are allowed to be used. See :ref:`plugin_filtering_config` for details of the filter file's format. The default is /etc/ansible/plugin_filters.yml"
msgid "Attempts to set RLIMIT_NOFILE soft limit to the specified value when executing Python modules (can speed up subprocess usage on Python 2.x. See https://bugs.python.org/issue11284). The value will be limited by the existing hard limit. Default value of 0 does not attempt to adjust existing system-defined limits."
msgid "This sets the path in which Ansible will save .retry files when a playbook fails and retry files are enabled. This file will be overwritten after each run with the list of failed hosts from all plays."
msgid "This setting can be used to optimize vars_plugin usage depending on user's inventory size and play selection. Setting to C(demand) will run vars_plugins relative to inventory sources anytime vars are 'demanded' by tasks. Setting to C(start) will run vars_plugins relative to inventory sources after importing that inventory source."
msgid "Action to take when a module parameter value is converted to a string (this does not affect variables). For string parameters, values such as '1.00', \"['a', 'b',]\", and 'yes', 'y', etc. will be converted by the YAML parser unless fully quoted. Valid options are 'error', 'warn', and 'ignore'. Since 2.8, this option defaults to 'warn' but will change to 'error' in 2.12."
msgid "This list of filters avoids 'type conversion' when templating variables Useful when you want to avoid conversion into lists or dictionaries for JSON strings, for example."
msgid "Allows disabling of warnings related to potential issues on the system running ansible itself (not on the managed hosts) These may include warnings about 3rd party packages or other conditions that should be resolved if possible."
msgid "default list of tags to run in your plays, Skip Tags has precedence."
msgstr "プレイで実行するタグのデフォルト一覧。Skip Tags が優先されます。"
#: ../../rst/reference_appendices/config.rst:2927
#: ../../rst/reference_appendices/config.rst:2942
msgid "[tags]"
msgstr "[tags]"
#: ../../rst/reference_appendices/config.rst:2928
msgid "run"
msgstr "run"
#: ../../rst/reference_appendices/config.rst:2930
msgid ":envvar:`ANSIBLE_RUN_TAGS`"
msgstr ":envvar:`ANSIBLE_RUN_TAGS`"
#: ../../rst/reference_appendices/config.rst:2935
msgid "TAGS_SKIP"
msgstr "TAGS_SKIP"
#: ../../rst/reference_appendices/config.rst:2937
#: ../../rst/reference_appendices/config.rst:4556
msgid "default list of tags to skip in your plays, has precedence over Run Tags"
msgstr "プレイでスキップするタグのデフォルト一覧は Run Tags よりも優先"
#: ../../rst/reference_appendices/config.rst:2945
msgid ":envvar:`ANSIBLE_SKIP_TAGS`"
msgstr ":envvar:`ANSIBLE_SKIP_TAGS`"
#: ../../rst/reference_appendices/config.rst:2950
msgid "TASK_DEBUGGER_IGNORE_ERRORS"
msgstr "TASK_DEBUGGER_IGNORE_ERRORS"
#: ../../rst/reference_appendices/config.rst:2952
msgid "This option defines whether the task debugger will be invoked on a failed task when ignore_errors=True is specified. True specifies that the debugger will honor ignore_errors, False will not honor ignore_errors."
msgid "Make ansible transform invalid characters in group names supplied by inventory sources. If 'never' it will allow for the group name but warn about the issue. When 'ignore', it does the same as 'never', without issuing a warning. When 'always' it will replace any invalid characters with '_' (underscore) and warn the user When 'silently', it does the same as 'always', without issuing a warning."
msgid "Force 'verbose' option to use stderr instead of stdout"
msgstr "stdout の代わりに「verbose」オプションを強制的に使用"
#: ../../rst/reference_appendices/config.rst:3052
msgid "verbose_to_stderr"
msgstr "verbose_to_stderr"
#: ../../rst/reference_appendices/config.rst:3054
msgid ":envvar:`ANSIBLE_VERBOSE_TO_STDERR`"
msgstr ":envvar:`ANSIBLE_VERBOSE_TO_STDERR`"
#: ../../rst/reference_appendices/config.rst:3059
msgid "WIN_ASYNC_STARTUP_TIMEOUT"
msgstr "WIN_ASYNC_STARTUP_TIMEOUT"
#: ../../rst/reference_appendices/config.rst:3061
msgid "For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how long, in seconds, to wait for the task spawned by Ansible to connect back to the named pipe used on Windows systems. The default is 5 seconds. This can be too low on slower systems, or systems under heavy load. This is not the total time an async command can run for, but is a separate timeout to wait for an async command to start. The task will only start to be timed against its async_timeout once it has connected to the pipe, so the overall maximum duration the task can take will be extended by the amount specified here."
msgid "The maximum number of times to check Task Queue Manager worker processes to verify they have exited cleanly. After this limit is reached any worker processes still running will be terminated. This is for internal use only."
msgid "The number of seconds to sleep between polling loops when checking Task Queue Manager worker processes to verify they have exited cleanly. This is for internal use only."
msgid "Check all of these extensions when looking for 'variable' files which should be YAML or JSON or vaulted versions of these. This affects vars_files, include_vars, inventory and vars plugins among others."
msgid "Specify where to look for the ansible-connection script. This location will be checked before searching $PATH.If null, ansible will start with the same directory as the ansible script."
msgid "Pipelining, if supported by the connection plugin, reduces the number of network operations required to execute a module on the remote server, by executing many Ansible modules without actual file transfer.This can result in a very significant performance improvement when enabled.However this conflicts with privilege escalation (become). For example, when using 'sudo:' operations you must first disable 'requiretty' in /etc/sudoers on all managed hosts, which is why it is disabled by default.This option is disabled if ``ANSIBLE_KEEP_REMOTE_FILES`` is enabled.This is a global option, each connection plugin can override either by having more specific options or not supporting pipelining at all."
msgid "With this setting on (True), running conditional evaluation 'var' is treated differently than 'var.subkey' as the first is evaluated directly while the second goes through the Jinja2 parser. But 'false' strings in 'var' get evaluated as booleans.With this setting off they both evaluate the same but in cases in which 'var' was 'false' (a string) it won't get evaluated as a boolean anymore.Currently this setting defaults to 'True' but will soon change to 'False' and the setting itself will be removed in the future.Expect that this setting eventually will be deprecated after 2.12"
msgid "Sets the output directory on the remote host to generate coverage reports to.Currently only used for remote coverage on PowerShell modules.This is for internal use only."
msgid "A list of paths for files on the Ansible controller to run coverage for when executing on the remote host.Only files that match the path glob will have its coverage collected.Multiple path globs can be specified and are separated by ``:``.Currently only used for remote coverage on PowerShell modules.This is for internal use only."
msgid "By default Ansible will issue a warning when received from a task action (module or action plugin)These warnings can be silenced by adjusting this setting to False."
msgid "Ansible can issue a warning when the shell or command module is used and the command appears to be similar to an existing Ansible module.These warnings can be silenced by adjusting this setting to False. You can also control this at the task level with the module option ``warn``.As of version 2.11, this is disabled by default."
msgid "By default Ansible will issue a warning when there are no hosts in the inventory.These warnings can be silenced by adjusting this setting to False."
msgid "This option allows you to globally configure a custom path for 'local_facts' for the implied M(ansible.builtin.setup) task when using fact gathering.If not set, it will fallback to the default from the M(ansible.builtin.setup) module: ``/etc/ansible/facts.d``.This does **not** affect user defined tasks that use the M(ansible.builtin.setup) module."
msgid "This option controls if notified handlers run on a host even if a failure occurs on that host.When false, the handlers will not run if a failure has occurred on a host.This can also be set per play or on the command line. See Handlers and Failure for more details."
msgid "This setting controls the default policy of fact gathering (facts discovered about remote systems).When 'implicit' (the default), the cache plugin will be ignored and facts will be gathered per play unless 'gather_facts: False' is set.When 'explicit' the inverse is true, facts will not be gathered unless directly requested in the play.The 'smart' value means each new host that has no facts discovered will be scanned, but if the same host is addressed in multiple plays it will not be contacted again in the playbook run.This option can be useful for those wishing to save fact gathering time. Both 'smart' and 'explicit' will use the cache plugin."
msgid "Set the `gather_subset` option for the M(ansible.builtin.setup) task in the implicit fact gathering. See the module documentation for specifics.It does **not** apply to user defined M(ansible.builtin.setup) tasks."
msgid "This setting controls how duplicate definitions of dictionary variables (aka hash, map, associative array) are handled in Ansible.This does not affect variables whose values are scalars (integers, strings) or arrays.**WARNING**, changing this setting is not recommended as this is fragile and makes your content (plays, roles, collections) non portable, leading to continual confusion and misuse. Don't change this setting unless you think you have an absolute need for it.We recommend avoiding reusing variable names and relying on the ``combine`` filter and ``vars`` and ``varnames`` lookups to create merged versions of the individual variables. In our experience this is rarely really needed and a sign that too much complexity has been introduced into the data structures and plays.For some uses you can also look into custom vars_plugins to merge on input, even substituting the default ``host_group_vars`` that is in charge of parsing the ``host_vars/`` and ``group_vars/`` directories. Most users of this setting are only interested in inventory scope, but the setting itself affects all sources and makes debugging even harder.All playbooks and roles in the official examples repos assume the default for this setting.Changing the setting to ``merge`` applies across variable sources, but many sources will internally still overwrite the variables. For example ``include_vars`` will dedupe variables internally before updating Ansible, with 'last defined' overwriting previous definitions in same file.The Ansible project recommends you **avoid ``merge`` for new projects.**It is the intention of the Ansible developers to eventually deprecate and remove this setting, but it is being kept as some users do heavily rely on it. New projects should **avoid 'merge'**."
msgid "This is a developer-specific feature that allows enabling additional Jinja2 extensions.See the Jinja2 documentation for details. If you do not know what these do, you probably don't need to change this setting :)"
msgid "Enables/disables the cleaning up of the temporary files Ansible used to execute the tasks on the remote.If this option is enabled it will disable ``ANSIBLE_PIPELINING``."
msgid "Makes role variables inaccessible from other roles.This was introduced as a way to reset role variables to default values if a role is used more than once in a playbook."
msgid "Some filesystems do not support safe operations and/or return inconsistent errors, this setting makes Ansible 'tolerate' those in the list w/o causing fatal errors.Data corruption may occur and writes are not always verified when a filesystem is in the list."
msgid "Set the main callback used to display Ansible output, you can only have one at a time.You can have many other callbacks, but just one can be in charge of stdout."
msgid "Whether or not to enable the task debugger, this previously was done as a strategy plugin.Now all strategy plugins can inherit this behavior. The debugger defaults to activating whena task is failed on unreachable. Use the debugger keyword for more flexibility."
msgid "This option defines whether the task debugger will be invoked on a failed task when ignore_errors=True is specified.True specifies that the debugger will honor ignore_errors, False will not honor ignore_errors."
msgid "When True, this causes ansible templating to fail steps that reference variable names that are likely typoed.Otherwise, any '{{ template_expression }}' that contains undefined variables will be rendered in a template or ansible action line exactly as written."
msgid "Normally ``ansible-playbook`` will print a header for each task that is run. These headers will contain the name: field from the task if you specified one. If you didn't then ``ansible-playbook`` uses the task's action to help you tell which task is presently running. Sometimes you run many of the same action and so you want more information about the task to differentiate it from others of the same action. If you set this variable to True in the config then ``ansible-playbook`` will also include the task's arguments in the header.This setting defaults to False because there is a chance that you have sensitive values in your parameters and you do not want those to be printed.If you set this to True you should be sure that you have secured your environment's stdout (no one can shoulder surf your screen and you aren't saving stdout to an insecure file) or made sure that all of your playbooks explicitly added the ``no_log: True`` parameter to tasks which have sensitive values See How do I keep secret data in my playbook? for more information."
msgid "By default Ansible will issue a warning when a duplicate dict key is encountered in YAML.These warnings can be silenced by adjusting this setting to False."
msgid "A list of Galaxy servers to use when installing a collection.The value corresponds to the config ini header ``[galaxy_server.{{item}}]`` which defines the server details.See :ref:`galaxy_server_config` for more details on how to define a Galaxy server.The order of servers in this list is used to as the order in which a collection is resolved.Setting this config option will ignore the :ref:`galaxy_server` config option."
msgid "Some steps in ``ansible-galaxy`` display a progress wheel which can cause issues on certain displays or when outputting the stdout to a file.This config option controls whether the display wheel is shown or not.The default is to show the display wheel if stdout has a tty."
msgid "The directory that stores cached responses from a Galaxy server.This is only used by the ``ansible-galaxy collection install`` and ``download`` commands.Cache files inside this dir will be ignored if they are world writable."
msgid "Make ansible transform invalid characters in group names supplied by inventory sources.If 'never' it will allow for the group name but warn about the issue.When 'ignore', it does the same as 'never', without issuing a warning.When 'always' it will replace any invalid characters with '_' (underscore) and warn the userWhen 'silently', it does the same as 'always', without issuing a warning."
msgid "Facts are available inside the `ansible_facts` variable, this setting also pushes them as their own vars in the main namespace.Unlike inside the `ansible_facts` dictionary, these will have an `ansible_` prefix."
msgid "This sets which playbook dirs will be used as a root to process vars plugins, which includes finding host_vars/group_varsThe ``top`` option follows the traditional behaviour of using the top playbook in the chain to find the root directory.The ``bottom`` option follows the 2.4.0 behaviour of using the current playbook to find the root directory.The ``all`` option examines from the first parent to the current playbook."
msgid "This sets the path in which Ansible will save .retry files when a playbook fails and retry files are enabled.This file will be overwritten after each run with the list of failed hosts from all plays."
msgid "This setting can be used to optimize vars_plugin usage depending on user's inventory size and play selection.Setting to C(demand) will run vars_plugins relative to inventory sources anytime vars are 'demanded' by tasks.Setting to C(start) will run vars_plugins relative to inventory sources after importing that inventory source."
msgid "This list of filters avoids 'type conversion' when templating variablesUseful when you want to avoid conversion into lists or dictionaries for JSON strings, for example."
msgid "Allows disabling of warnings related to potential issues on the system running ansible itself (not on the managed hosts)These may include warnings about 3rd party packages or other conditions that should be resolved if possible."
msgid "The maximum number of times to check Task Queue Manager worker processes to verify they have exited cleanly.After this limit is reached any worker processes still running will be terminated.This is for internal use only."
msgid "The number of seconds to sleep between polling loops when checking Task Queue Manager worker processes to verify they have exited cleanly.This is for internal use only."
msgid "For asynchronous tasks in Ansible (covered in Asynchronous Actions and Polling), this is how long, in seconds, to wait for the task spawned by Ansible to connect back to the named pipe used on Windows systems. The default is 5 seconds. This can be too low on slower systems, or systems under heavy load.This is not the total time an async command can run for, but is a separate timeout to wait for an async command to start. The task will only start to be timed against its async_timeout once it has connected to the pipe, so the overall maximum duration the task can take will be extended by the amount specified here."
msgid "Check all of these extensions when looking for 'variable' files which should be YAML or JSON or vaulted versions of these.This affects vars_files, include_vars, inventory and vars plugins among others."
msgid "Action to take when a module parameter value is converted to a string (this does not affect variables). For string parameters, values such as '1.00', \"['a', 'b',]\", and 'yes', 'y', etc. will be converted by the YAML parser unless fully quoted.Valid options are 'error', 'warn', and 'ignore'.Since 2.8, this option defaults to 'warn' but will change to 'error' in 2.12."
msgid "Here are some commonly asked questions and their answers."
msgstr "以下に、よくある質問とその回答を紹介しています。"
#: ../../rst/reference_appendices/faq.rst:11
msgid "Where did all the modules go?"
msgstr "すべてのモジュールはどこに移されましたか"
#: ../../rst/reference_appendices/faq.rst:13
msgid "In July, 2019, we announced that collections would be the `future of Ansible content delivery <https://www.ansible.com/blog/the-future-of-ansible-content-delivery>`_. A collection is a distribution format for Ansible content that can include playbooks, roles, modules, and plugins. In Ansible 2.9 we added support for collections. In Ansible 2.10 we `extracted most modules from the main ansible/ansible repository <https://access.redhat.com/solutions/5295121>`_ and placed them in :ref:`collections <list_of_collections>`. Collections may be maintained by the Ansible team, by the Ansible community, or by Ansible partners. The `ansible/ansible repository <https://github.com/ansible/ansible>`_ now contains the code for basic features and functions, such as copying module code to managed nodes. This code is also known as ``ansible-base``."
msgid "To learn more about contributing to existing collections, see the individual collection repository for guidelines, or see :ref:`contributing_maintained_collections` to contribute to one of the Ansible-maintained collections."
msgid "IF you are searching for a specific module, you can check the `runtime.yml <https://github.com/ansible/ansible/blob/devel/lib/ansible/config/ansible_builtin_runtime.yml>`_ file, which lists the first destination for each module that we extracted from the main ansible/ansible repository. Some modules have moved again since then. You can also search on `Ansible Galaxy <https://galaxy.ansible.com/>`_ or ask on one of our :ref:`IRC channels <communication_irc>`."
msgid "starting in 2.0.1 the setup task from ``gather_facts`` also inherits the environment directive from the play, you might need to use the ``|default`` filter to avoid errors if setting this at play level."
msgid "Setting inventory variables in the inventory file is the easiest way."
msgstr "インベントリーファイルにインベントリー変数を設定する方法が最も簡単です。"
#: ../../rst/reference_appendices/faq.rst:56
msgid "For instance, suppose these hosts have different usernames and ports:"
msgstr "たとえば、以下では、ホストに異なるユーザー名とポートが指定されています。"
#: ../../rst/reference_appendices/faq.rst:64
msgid "You can also dictate the connection type to be used, if you want:"
msgstr "任意で、使用する接続タイプを指定できます。"
#: ../../rst/reference_appendices/faq.rst:73
msgid "You may also wish to keep these in group variables instead, or file them in a group_vars/<groupname> file. See the rest of the documentation for more information about how to organize variables."
msgid "Switch your default connection type in the configuration file to ``ssh``, or use ``-c ssh`` to use Native OpenSSH for connections instead of the python paramiko library. In Ansible 1.2.1 and later, ``ssh`` will be used by default if OpenSSH is new enough to support ControlPersist as an option."
msgid "Paramiko is great for starting out, but the OpenSSH type offers many advanced options. You will want to run Ansible from a machine new enough to support ControlPersist, if you are using this connection type. You can still manage older clients. If you are using RHEL 6, CentOS 6, SLES 10 or SLES 11 the version of OpenSSH is still a bit old, so consider managing from a Fedora or openSUSE client even though you are managing older nodes, or just use paramiko."
msgid "We keep paramiko as the default as if you are first installing Ansible on these enterprise operating systems, it offers a better experience for new users."
msgid "You can set a ``ProxyCommand`` in the ``ansible_ssh_common_args`` inventory variable. Any arguments specified in this variable are added to the sftp/scp/ssh command line when connecting to the relevant host(s). Consider the following inventory group:"
msgid "Ansible will append these arguments to the command line when trying to connect to any hosts in the group ``gatewayed``. (These arguments are used in addition to any ``ssh_args`` from ``ansible.cfg``, so you do not need to repeat global ``ControlPersist`` settings in ``ansible_ssh_common_args``.)"
msgid "Note that ``ssh -W`` is available only with OpenSSH 5.4 or later. With older versions, it's necessary to execute ``nc %h:%p`` or some equivalent command on the bastion host."
msgid "With earlier versions of Ansible, it was necessary to configure a suitable ``ProxyCommand`` for one or more hosts in ``~/.ssh/config``, or globally by setting ``ssh_args`` in ``ansible.cfg``."
msgid "You can add ``-o ServerAliveInterval=NumberOfSeconds`` in ``ssh_args`` from ``ansible.cfg``. Without this option, SSH and therefore Ansible will wait until the TCP connection times out. Another solution is to add ``ServerAliveInterval`` into your global SSH configuration. A good value for ``ServerAliveInterval`` is up to you to decide; keep in mind that ``ServerAliveCountMax=3`` is the SSH default so any value you set will be tripled before terminating the SSH session."
msgid "Don't try to manage a fleet of machines of a cloud provider from your laptop. Rather connect to a management node inside this cloud provider first and run Ansible from there."
msgid "While you can write Ansible modules in any language, most Ansible modules are written in Python, including the ones central to letting Ansible work."
msgid "By default, Ansible assumes it can find a :command:`/usr/bin/python` on your remote system that is either Python2, version 2.6 or higher or Python3, 3.5 or higher."
msgid "Setting the inventory variable ``ansible_python_interpreter`` on any host will tell Ansible to auto-replace the Python interpreter with that value instead. Thus, you can point to any Python you want on the system if :command:`/usr/bin/python` on your system does not point to a compatible Python interpreter."
msgid "Some platforms may only have Python 3 installed by default. If it is not installed as :command:`/usr/bin/python`, you will need to configure the path to the interpreter via ``ansible_python_interpreter``. Although most core modules will work with Python 3, there may be some special purpose ones which do not or you may encounter a bug in an edge case. As a temporary workaround you can install Python 2 on the managed host and configure Ansible to use that Python via ``ansible_python_interpreter``. If there's no mention in the module's documentation that the module requires Python 2, you can also report a bug on our `bug tracker <https://github.com/ansible/ansible/issues>`_ so that the incompatibility can be fixed in a future release."
msgid "Also, this works for ANY interpreter, for example ruby: ``ansible_ruby_interpreter``, perl: ``ansible_perl_interpreter``, and so on, so you can use this for custom modules written in any scripting language and control the interpreter location."
msgid "Keep in mind that if you put ``env`` in your module shebang line (``#!/usr/bin/env <other>``), this facility will be ignored so you will be at the mercy of the remote `$PATH`."
msgid "While installing Ansible, sometimes you may encounter errors such as `No package 'libffi' found` or `fatal error: Python.h: No such file or directory` These errors are generally caused by the missing packages, which are dependencies of the packages required by Ansible. For example, `libffi` package is dependency of `pynacl` and `paramiko` (Ansible -> paramiko -> pynacl -> libffi)."
msgstr "Ansible のインストール中に、`No package 'libffi' found` または `fatal error: Python.h: No such file or directory` などのエラーが発生する場合があります。このようなエラーは通常、Ansible で必要なパッケージの依存関係パッケージが不足している場合に発生します。たとえば、`libffi` パッケージは `pynacl` および `paramiko` の依存関係です (Ansible -> paramiko -> pynacl -> libffi)。"
#: ../../rst/reference_appendices/faq.rst:185
msgid "In order to solve these kinds of dependency issues, you might need to install required packages using the OS native package managers, such as `yum`, `dnf`, or `apt`, or as mentioned in the package installation guide."
msgid "If you need to use any libraries which are not available via pip (for instance, SELinux Python bindings on systems such as Red Hat Enterprise Linux or Fedora that have SELinux enabled), then you need to install them into the virtualenv. There are two methods:"
msgstr "pip で入手できないライブラリーを使用する必要がある場合は (例: SELinux が有効な Red Hat Enterprise Linux または Fedora などのシステムにある SELinux Python のバインディング)、virtualenv にインストールする必要があります。2 つの方法があります。"
#: ../../rst/reference_appendices/faq.rst:221
msgid "When you create the virtualenv, specify ``--system-site-packages`` to make use of any libraries installed in the system's Python:"
msgid "By default, Solaris 10 and earlier run a non-POSIX shell which does not correctly expand the default tmp directory Ansible uses ( :file:`~/.ansible/tmp`). If you see module failures on Solaris machines, this is likely the problem. There are several workarounds:"
msgid "You can set ``remote_tmp`` to a path that will expand correctly with the shell you are using (see the plugin documentation for :ref:`C shell<csh_shell>`, :ref:`fish shell<fish_shell>`, and :ref:`Powershell<powershell_shell>`). For example, in the ansible config file you can set::"
msgid "You can set :ref:`ansible_shell_executable<ansible_shell_executable>` to the path to a POSIX compatible shell. For instance, many Solaris hosts have a POSIX shell located at :file:`/usr/xpg4/bin/sh` so you can set this in inventory like so::"
msgstr ":ref:`ansible_shell_executable<ansible_shell_executable>` を、POSIX の互換性のあるパスに設定します。たとえば、多数の Solaris ホストでは POSIX シェルが、:file:`/usr/xpg4/bin/sh` に配置されているため、インベントリーにこの値を以下のように設定できます。"
#: ../../rst/reference_appendices/faq.rst:266
msgid "(bash, ksh, and zsh should also be POSIX compatible if you have any of those installed)."
msgid "To get around this limitation, download and install a later version of `python for z/OS <https://www.rocketsoftware.com/zos-open-source>`_ (2.7.13 or 3.6.1) that represents strings internally as ASCII. Version 2.7.13 is verified to work."
msgid "When ``pipelining = False`` in `/etc/ansible/ansible.cfg` then Ansible modules are transferred in binary mode via sftp however execution of python fails with"
msgid "SyntaxError: Non-UTF-8 code starting with \\'\\\\x83\\' in file /a/user1/.ansible/tmp/ansible-tmp-1548232945.35-274513842609025/AnsiballZ_stat.py on line 1, but no encoding declared; see https://python.org/dev/peps/pep-0263/ for details"
msgstr "SyntaxError: Non-UTF-8 code starting with \\'\\\\x83\\' in file /a/user1/.ansible/tmp/ansible-tmp-1548232945.35-274513842609025/AnsiballZ_stat.py on line 1, but no encoding declared; see https://python.org/dev/peps/pep-0263/ for details"
#: ../../rst/reference_appendices/faq.rst:282
msgid "To fix it set ``pipelining = True`` in `/etc/ansible/ansible.cfg`."
msgid "Start of python fails with ``The module libpython2.7.so was not found.``"
msgstr "python の起動に失敗し、``The module libpython2.7.so was not found.`` が表示"
#: ../../rst/reference_appendices/faq.rst:296
msgid "EE3501S The module libpython2.7.so was not found."
msgstr "EE3501S The module libpython2.7.so was not found."
#: ../../rst/reference_appendices/faq.rst:298
msgid "On z/OS, you must execute python from gnu bash. If gnu bash is installed at ``/usr/lpp/bash``, you can fix this in your inventory by specifying an ``ansible_shell_executable``::"
msgid "Some issues arise as ``fakeroot`` does not create a full nor POSIX compliant system by default. It is known that it will not correctly expand the default tmp directory Ansible uses (:file:`~/.ansible/tmp`). If you see module failures, this is likely the problem. The simple workaround is to set ``remote_tmp`` to a path that will expand correctly (see documentation of the shell plugin you are using for specifics)."
msgid "What is the best way to make content reusable/redistributable?"
msgstr "コンテンツを再利用/再配信できるようにする最適な方法にはどんなものがありますか"
#: ../../rst/reference_appendices/faq.rst:322
msgid "If you have not done so already, read all about \"Roles\" in the playbooks documentation. This helps you make playbook content self-contained, and works well with things like git submodules for sharing content with others."
msgid "If some of these plugin types look strange to you, see the API documentation for more details about ways Ansible can be extended."
msgstr "このようなプラグインタイプの詳細は、Ansible の拡張方法に関する詳細を API ドキュメントで確認してください。"
#: ../../rst/reference_appendices/faq.rst:330
msgid "Where does the configuration file live and what can I configure in it?"
msgstr "設定ファイルの配置場所はどこですか。または、どのように設定すれば良いですか"
#: ../../rst/reference_appendices/faq.rst:333
msgid "See :ref:`intro_configuration`."
msgstr "「:ref:`intro_configuration`」を参照してください。"
#: ../../rst/reference_appendices/faq.rst:338
msgid "How do I disable cowsay?"
msgstr "cowsay はどのように無効化すれば良いですか"
#: ../../rst/reference_appendices/faq.rst:340
msgid "If cowsay is installed, Ansible takes it upon itself to make your day happier when running playbooks. If you decide that you would like to work in a professional cow-free environment, you can either uninstall cowsay, set ``nocows=1`` in ``ansible.cfg``, or set the :envvar:`ANSIBLE_NOCOWS` environment variable:"
msgid "How do I see a list of all of the ansible\\_ variables?"
msgstr "ansible\\_ 変数一覧を確認するにはどうすれば良いですか"
#: ../../rst/reference_appendices/faq.rst:353
msgid "Ansible by default gathers \"facts\" about the machines under management, and these facts can be accessed in playbooks and in templates. To see a list of all of the facts that are available about a machine, you can run the ``setup`` module as an ad hoc action:"
msgid "This will print out a dictionary of all of the facts that are available for that particular host. You might want to pipe the output to a pager.This does NOT include inventory variables or internal 'magic' variables. See the next question if you need more than just 'facts'."
msgid "A pretty common pattern is to iterate over a list of hosts inside of a host group, perhaps to populate a template configuration file with a list of servers. To do this, you can just access the \"$groups\" dictionary in your template, like this:"
msgid "If you need to access facts about these hosts, for instance, the IP address of each hostname, you need to make sure that the facts have been populated. For example, make sure you have a play that talks to db_servers::"
msgstr "このようなホストに関するファクト (各ホスト名の IP アドレスなど) にアクセスする必要がある場合には、ファクトが生成されていることを確認する必要があります。たとえば、db_servers と対話するプレイがあることを確認します::"
#: ../../rst/reference_appendices/faq.rst:413
msgid "Then you can use the facts inside your template, like this:"
msgstr "次に、以下のように、テンプレート内のファクトを使用できます。"
#: ../../rst/reference_appendices/faq.rst:424
msgid "How do I access a variable name programmatically?"
msgstr "プログラムで変数名にアクセスするにはどうすれば良いですか"
#: ../../rst/reference_appendices/faq.rst:426
msgid "An example may come up where we need to get the ipv4 address of an arbitrary interface, where the interface to be used may be supplied via a role parameter or other input. Variable names can be built by adding strings together, like so:"
msgid "The trick about going through hostvars is necessary because it's a dictionary of the entire namespace of variables. ``inventory_hostname`` is a magic variable that indicates the current host you are looping over in the host loop."
msgid "Technically, you don't, Ansible does not really use groups directly. Groups are labels for host selection and a way to bulk assign variables, they are not a first class entity, Ansible only cares about Hosts and Tasks."
msgid "How do I access a variable of the first host in a group?"
msgstr "グループ内の最初のホストの変数にアクセスするにはどうすれば良いですか"
#: ../../rst/reference_appendices/faq.rst:461
msgid "What happens if we want the ip address of the first webserver in the webservers group? Well, we can do that too. Note that if we are using dynamic inventory, which host is the 'first' may not be consistent, so you wouldn't want to do this unless your inventory is static and predictable. (If you are using :ref:`ansible_tower`, it will use database order, so this isn't a problem even if you are using cloud based inventory scripts)."
msgstr "webservers グループの最初の webserver の IP アドレスが必要な場合にはどうすれば良いですか。私たちはそれも行うことができます。動的インベントリーを使用している場合は、どのホストが「最初」であるかが一貫していない可能性があるため、インベントリーが静的で予測可能でない限り、これを実行したくないことに注意してください (:ref:`ansible_tower` を使用している場合は、データベースの順序を使用するため、クラウドベースのインベントリースクリプトを使用している場合でも、これは問題になりません)。"
#: ../../rst/reference_appendices/faq.rst:466
msgid "Anyway, here's the trick:"
msgstr "以下に方法を示します。"
#: ../../rst/reference_appendices/faq.rst:472
msgid "Notice how we're pulling out the hostname of the first machine of the webservers group. If you are doing this in a template, you could use the Jinja2 '#set' directive to simplify this, or in a playbook, you could also use set_fact::"
msgid "How do I copy files recursively onto a target host?"
msgstr "ターゲットホストにファイルを再帰的にコピーするにはどうすれば良いですか"
#: ../../rst/reference_appendices/faq.rst:486
msgid "The ``copy`` module has a recursive parameter. However, take a look at the ``synchronize`` module if you want to do something more efficient for a large number of files. The ``synchronize`` module wraps rsync. See the module index for info on both of these modules."
msgid "How do I access shell environment variables?"
msgstr "shell 環境変数にアクセスするにはどうすれば良いですか"
#: ../../rst/reference_appendices/faq.rst:495
msgid "**On controller machine :** Access existing variables from controller use the ``env`` lookup plugin. For example, to access the value of the HOME environment variable on the management machine::"
msgstr "**コントローラーマシンの場合:** コントローラーから既存の変数にアクセスするには、``env`` lookup プラグインを使用します。たとえば、管理マシンで HOME 環境変数の値にアクセスするには、以下を指定します。"
#: ../../rst/reference_appendices/faq.rst:504
msgid "**On target machines :** Environment variables are available via facts in the ``ansible_env`` variable:"
msgid "If you need to set environment variables for TASK execution, see :ref:`playbooks_environment` in the :ref:`Advanced Playbooks <playbooks_special_topics>` section. There are several ways to set environment variables on your target machines. You can use the :ref:`template <template_module>`, :ref:`replace <replace_module>`, or :ref:`lineinfile <lineinfile_module>` modules to introduce environment variables into files. The exact files to edit vary depending on your OS and distribution and local configuration."
msgid "How do I generate encrypted passwords for the user module?"
msgstr "ユーザーモジュールの暗号化パスワードを生成するにはどうすれば良いですか"
#: ../../rst/reference_appendices/faq.rst:522
msgid "Ansible ad hoc command is the easiest option:"
msgstr "Ansible ad-hoc コマンドを使用するのが最も簡単なオプションです。"
#: ../../rst/reference_appendices/faq.rst:528
msgid "The ``mkpasswd`` utility that is available on most Linux systems is also a great option:"
msgstr "ほとんどの Linux システムで利用できる ``mkpasswd`` ユーティリティーも優れたオプションです。"
#: ../../rst/reference_appendices/faq.rst:535
msgid "If this utility is not installed on your system (for example, you are using macOS) then you can still easily generate these passwords using Python. First, ensure that the `Passlib <https://foss.heptapod.net/python-libs/passlib/-/wikis/home>`_ password hashing library is installed:"
msgid "Use the integrated :ref:`hash_filters` to generate a hashed version of a password. You shouldn't put plaintext passwords in your playbook or host_vars; instead, use :ref:`playbooks_vault` to encrypt sensitive data."
msgid "The dot notation comes from Jinja and works fine for variables without special characters. If your variable contains dots (.), colons (:), or dashes (-), if a key begins and ends with two underscores, or if a key uses any of the known public attributes, it is safer to use the array notation. See :ref:`playbooks_variables` for a list of the known public attributes."
msgid "Another problem with 'dot notation' is that some keys can cause problems because they collide with attributes and methods of python dictionaries."
msgid "When is it unsafe to bulk-set task arguments from a variable?"
msgstr "変数からタスク引数の一括設定をすると安全でないのはどのような場合ですか"
#: ../../rst/reference_appendices/faq.rst:588
msgid "You can set all of a task's arguments from a dictionary-typed variable. This technique can be useful in some dynamic execution scenarios. However, it introduces a security risk. We do not recommend it, so Ansible issues a warning when you do something like this::"
msgid "This particular example is safe. However, constructing tasks like this is risky because the parameters and values passed to ``usermod_args`` could be overwritten by malicious values in the ``host facts`` on a compromised target machine. To mitigate this risk:"
msgid "set bulk variables at a level of precedence greater than ``host facts`` in the order of precedence found in :ref:`ansible_variable_precedence` (the example above is safe because play vars take precedence over facts)"
msgid "disable the :ref:`inject_facts_as_vars` configuration setting to prevent fact values from colliding with variables (this will also disable the original warning)"
msgid "Yes! See our `services page <https://www.ansible.com/products/consulting>`_ for information on our services and training offerings. Email `info@ansible.com <mailto:info@ansible.com>`_ for further details."
msgid "We also offer free web-based training classes on a regular basis. See our `webinar page <https://www.ansible.com/resources/webinars-training>`_ for more info on upcoming webinars."
msgid "If you would like to keep secret data in your Ansible content and still share it publicly or keep things in source control, see :ref:`playbooks_vault`."
msgid "If you have a task that you don't want to show the results or command given to it when using -v (verbose) mode, the following task or playbook attribute can be useful::"
msgid "The ``no_log`` attribute can also apply to an entire play::"
msgstr "``no_log`` 属性は、プレイ全体にも適用できます。"
#: ../../rst/reference_appendices/faq.rst:654
msgid "Though this will make the play somewhat difficult to debug. It's recommended that this be applied to single tasks only, once a playbook is completed. Note that the use of the ``no_log`` attribute does not prevent data from being shown when debugging Ansible itself via the :envvar:`ANSIBLE_DEBUG` environment variable."
msgid "A steadfast rule is 'always use ``{{ }}`` except when ``when:``'. Conditionals are always run through Jinja2 as to resolve the expression, so ``when:``, ``failed_when:`` and ``changed_when:`` are always templated and you should avoid adding ``{{ }}``."
msgid "In most other cases you should always use the brackets, even if previously you could use variables without specifying (like ``loop`` or ``with_`` clauses), as this made it hard to distinguish between an undefined variable and a string."
msgid "In most cases it has to do with maintainability. There are many ways to ship software and we do not have the resources to release Ansible on every platform. In some cases there are technical issues. For example, our dependencies are not present on Python Wheels."
msgid "As the documentation states, connection variables are taken from the ``delegate_to`` host so ``ansible_host`` is overwritten, but you can still access the original via ``hostvars``::"
msgid "How do I fix 'protocol error: filename does not match request' when fetching a file?"
msgstr "ファイルの取得時の「protocol error: filename does not match request」のエラーはどのように修正すれば良いですか"
#: ../../rst/reference_appendices/faq.rst:720
msgid "Since release ``7.9p1`` of OpenSSH there is a `bug <https://bugzilla.mindrot.org/show_bug.cgi?id=2966>`_ in the SCP client that can trigger this error on the Ansible controller when using SCP as the file transfer mechanism::"
msgid "In these releases, SCP tries to validate that the path of the file to fetch matches the requested path. The validation fails if the remote filename requires quotes to escape spaces or non-ascii characters in its path. To avoid this error:"
msgid "If you see an ``invalid argument`` error when using ``-T``, then your SCP client is not performing filename validation and will not trigger this error."
msgid "No, Ansible is designed to execute multiple tasks against multiple targets, minimizing user interaction. As with most automation tools, it is not compatible with interactive security systems designed to handle human interaction. Most of these systems require a secondary prompt per target, which prevents scaling to thousands of targets. They also tend to have very short expiration periods so it requires frequent reauthorization, also an issue with many hosts and/or a long set of tasks."
msgid "In such environments we recommend securing around Ansible's execution but still allowing it to use an 'automation user' that does not require such measures. This is something that Tower/AWX excels at by allowing administrators to set up RBAC access to inventory, along with managing credentials and job execution."
msgid "How do I submit a change to the documentation?"
msgstr "ドキュメントへの変更を提出するにはどうすれば良いですか"
#: ../../rst/reference_appendices/faq.rst:762
msgid "Documentation for Ansible is kept in the main project git repository, and complete instructions for contributing can be found in the docs README `viewable on GitHub <https://github.com/ansible/ansible/blob/devel/docs/docsite/README.md>`_. Thanks!"
msgid "To give you maximum flexibility in managing your environments, Ansible offers many ways to control how Ansible behaves: how it connects to managed nodes, how it works once it has connected. If you use Ansible to manage a large number of servers, network devices, and cloud resources, you may define Ansible behavior in several different places and pass that information to Ansible in several different ways. This flexibility is convenient, but it can backfire if you do not understand the precedence rules."
msgid "These precedence rules apply to any setting that can be defined in multiple ways (by configuration settings, command-line options, playbook keywords, variables)."
msgid "Ansible offers four sources for controlling its behavior. In order of precedence from lowest (most easily overridden) to highest (overrides all others), the categories are:"
msgid "Each category overrides any information from all lower-precedence categories. For example, a playbook keyword will override any configuration setting."
msgid "Within each precedence category, specific rules apply. However, generally speaking, 'last defined' wins and overrides any previous definitions."
msgid ":ref:`Configuration settings<ansible_configuration_settings>` include both values from the ``ansible.cfg`` file and environment variables. Within this category, values set in configuration files have lower precedence. Ansible uses the first ``ansible.cfg`` file it finds, ignoring all others. Ansible searches for ``ansible.cfg`` in these locations in order:"
msgid "Environment variables have a higher precedence than entries in ``ansible.cfg``. If you have environment variables set on your control node, they override the settings in whichever ``ansible.cfg`` file Ansible loads. The value of any given environment variable follows normal shell precedence: the last value defined overwrites previous values."
msgid "When you type something directly at the command line, you may feel that your hand-crafted values should override all others, but Ansible does not work that way. Command-line options have low precedence - they override configuration only. They do not override playbook keywords, variables from inventory or variables from playbooks."
msgid "You can override all other settings from all other sources in all other precedence categories at the command line by :ref:`general_precedence_extra_vars`, but that is not a command-line option, it is a way of passing a :ref:`variable<general_precedence_variables>`."
msgid "At the command line, if you pass multiple values for a parameter that accepts only a single value, the last defined value wins. For example, this :ref:`ad hoc task<intro_adhoc>` will connect as ``carol``, not as ``mike``::"
msgstr "コマンドラインで、単値のみを受け入れるパラメーターに多値を渡すと、最後に定義された値が優先されます。たとえば、この :ref:`ad hoc task<intro_adhoc>` は、``mike`` ではなく、``carol`` として接続します。"
msgid "Some parameters allow multiple values. In this case, Ansible will append all values from the hosts listed in inventory files inventory1 and inventory2::"
msgid "In this example, the ``connection`` keyword is set to ``ssh`` at the play level. The first task inherits that value, and connects using ``ssh``. The second task inherits that value, overrides it, and connects using ``paramiko``. The same logic applies to blocks and roles as well. All tasks, blocks, and roles within a play inherit play-level keywords; any task, block, or role can override any keyword by defining a different value for that keyword within the task, block, or role."
msgid "Remember that these are KEYWORDS, not variables. Both playbooks and variable files are defined in YAML but they have different significance. Playbooks are the command or 'state description' structure for Ansible, variables are data we use to help make playbooks more dynamic."
msgid "Variables that have equivalent playbook keywords, command-line options, and configuration settings are known as :ref:`connection_variables`. Originally designed for connection parameters, this category has expanded to include other core variables like the temporary directory and the python interpreter."
msgid "Connection variables, like all variables, can be set in multiple ways and places. You can define variables for hosts and groups in :ref:`inventory<intro_inventory>`. You can define variables for tasks and plays in ``vars:`` blocks in :ref:`playbooks<about_playbooks>`. However, they are still variables - they are data, not keywords or configuration settings. Variables that override playbook keywords, command-line options, and configuration settings follow the same rules of :ref:`variable precedence <ansible_variable_precedence>` as any other variables."
msgid "When set in a playbook, variables follow the same inheritance rules as playbook keywords. You can set a value for the play, then override it in a task, block, or role::"
msgid "Variable values set in a playbook exist only within the playbook object that defines them. These 'playbook object scope' variables are not available to subsequent objects, including other plays."
msgid "Variable values associated directly with a host or group, including variables defined in inventory, by vars plugins, or using modules like :ref:`set_fact<set_fact_module>` and :ref:`include_vars<include_vars_module>`, are available to all plays. These 'host scope' variables are also available via the ``hostvars[]`` dictionary."
msgid "To override all other settings in all other categories, you can use extra variables: ``--extra-vars`` or ``-e`` at the command line. Values passed with ``-e`` are variables, not command-line options, and they will override configuration settings, command-line options, and playbook keywords as well as variables set elsewhere. For example, this task will connect as ``brian`` not as ``carol``::"
msgid "Consult the documentation home page for the full documentation and to see the terms in context, but this should be a good resource to check your knowledge of Ansible's components and understand how they fit together. It's something you might wish to read for review or when a term comes up on the mailing list."
msgid "An action is a part of a task that specifies which of the modules to run and which arguments to pass to that module. Each task can have only one action, but it may also have other parameters."
msgid "Refers to running Ansible to perform some quick command, using :command:`/usr/bin/ansible`, rather than the :term:`orchestration` language, which is :command:`/usr/bin/ansible-playbook`. An example of an ad hoc command might be rebooting 50 machines in your infrastructure. Anything you can do ad hoc can be accomplished by writing a :term:`playbook <playbooks>` and playbooks can also glue lots of other operations together."
msgid "A software package (Python, deb, rpm, and so on) that contains ansible-base and a select group of collections. Playbooks that worked with Ansible 2.9 should still work with the Ansible 2.10 package. See the :file:`ansible-<version>.build` file in the release-specific directory at `ansible-build-data <https://github.com/ansible-community/ansible-build-data>`_ for a list of collections included in Ansible, as well as the included ``ansible-base`` version."
msgid "New for 2.10. The installable package (RPM/Python/Deb package) generated from the `ansible/ansible repository <https://github.com/ansible/ansible>`_. Contains the command-line tools and the code for basic features and functions, such as copying module code to managed nodes. The ``ansible-base`` package includes a few modules and plugins and allows you to add others by installing collections."
msgid "An `online resource <galaxy.ansible.com>`_ for finding and sharing Ansible community content. Also, the command-line utility that lets users install individual Ansible Collections, for example`` ansible-galaxy install community.crypto``."
msgid "Refers to a task that is configured to run in the background rather than waiting for completion. If you have a long process that would run longer than the SSH timeout, it would make sense to launch that task in async mode. Async modes can poll for completion every so many seconds or can be configured to \"fire and forget\", in which case Ansible will not even check on the task again; it will just kick it off and proceed to future steps. Async modes work with both :command:`/usr/bin/ansible` and :command:`/usr/bin/ansible-playbook`."
msgid "Refers to some user-written code that can intercept results from Ansible and do something with them. Some supplied examples in the GitHub project perform custom logging, send email, or even play sound effects."
msgid "Refers to running Ansible with the ``--check`` option, which does not make any changes on the remote systems, but only outputs the changes that might occur if the command ran without this flag. This is analogous to so-called \"dry run\" modes in other systems, though the user should be warned that this does not take into account unexpected command failures or cascade effects (which is true of similar modes in other systems). Use this to get an idea of what might happen, but do not substitute it for a good staging environment."
msgid "A packaging format for bundling and distributing Ansible content, including plugins, roles, modules, and more. Collections release independent of other collections or ``ansible-base`` so features can be available sooner to users. Some collections are packaged with Ansible (version 2.10 or later). You can install other collections (or other versions of collections) with ``ansible-galaxy collection install <namespace.collection>``."
msgid "The second part of a Fully Qualified Collection Name. The collection name divides the collection namespace and usually reflects the function of the collection content. For example, the ``cisco`` namespace might contain ``cisco.ios``, ``cisco.aci``, and ``cisco.nxos``, with content for managing the different network devices maintained by Cisco."
msgid "A special collection managed by the Ansible Community Team containing all the modules and plugins which shipped in Ansible 2.9 that do ont have their own dedicated Collection. See `community.general <https://galaxy.ansible.com/community/general>`_` on Galaxy."
msgstr "Ansible 2.9 に同梱された、専用のコレクションを持たないすべてのモジュールとプラグインを含む Ansible Community Team が管理する特定のコレクション。Galaxy の「`community.general <https://galaxy.ansible.com/community/general>`_`」を参照してください。"
#: ../../rst/reference_appendices/glossary.rst:69
msgid "community.network (collection)"
msgstr "community.network (コレクション)"
#: ../../rst/reference_appendices/glossary.rst:71
msgid "Similar to ``community.general``, focusing on network content. `community.network <https://galaxy.ansible.com/community/network>`_` on Galaxy."
msgid "By default, Ansible talks to remote machines through pluggable libraries. Ansible uses native OpenSSH (:term:`SSH (Native)`) or a Python implementation called :term:`paramiko`. OpenSSH is preferred if you are using a recent version, and also enables some features like Kerberos and jump hosts. This is covered in the :ref:`getting started section <remote_connection_information>`. There are also other connection types like ``accelerate`` mode, which must be bootstrapped over one of the SSH-based connection types but is very fast, and local mode, which acts on the local system. Users can also write their own connection plugins."
msgid "A conditional is an expression that evaluates to true or false that decides whether a given task is executed on a given machine or not. Ansible's conditionals are powered by the 'when' statement, which are discussed in the :ref:`working_with_playbooks`."
msgid "An approach to achieving a task that uses a description of the final state rather than a description of the sequence of steps necessary to achieve that state. For a real world example, a declarative specification of a task would be: \"put me in California\". Depending on your current location, the sequence of steps to get you to California may vary, and if you are already in California, nothing at all needs to be done. Ansible's Resources are declarative; it figures out the steps needed to achieve the final state. It also lets you know whether or not any steps needed to be taken to get to the final state."
msgid "A ``--diff`` flag can be passed to Ansible to show what changed on modules that support it. You can combine it with ``--check`` to get a good 'dry run'. File diffs are normally in unified diff format."
msgid "A core software component of Ansible that is the power behind :command:`/usr/bin/ansible` directly -- and corresponds to the invocation of each task in a :term:`playbook <playbooks>`. The Executor is something Ansible developers may talk about, but it's not really user land vocabulary."
msgid "Facts are simply things that are discovered about remote nodes. While they can be used in :term:`playbooks` and templates just like variables, facts are things that are inferred, rather than set. Facts are automatically discovered by Ansible when running plays by executing the internal :ref:`setup module <setup_module>` on the remote nodes. You never have to call the setup module explicitly, it just runs, but it can be disabled to save time if it is not needed or you can tell ansible to collect only a subset of the full facts via the ``gather_subset:`` option. For the convenience of users who are switching from other configuration management systems, the fact module will also pull in facts from the :program:`ohai` and :program:`facter` tools if they are installed. These are fact libraries from Chef and Puppet, respectively. (These may also be disabled via ``gather_subset:``)"
msgid "A filter plugin is something that most users will never need to understand. These allow for the creation of new :term:`Jinja2` filters, which are more or less only of use to people who know what Jinja2 filters are. If you need them, you can learn how to write them in the :ref:`API docs section <developing_filter_plugins>`."
msgid "Ansible talks to remote nodes in parallel and the level of parallelism can be set either by passing ``--forks`` or editing the default in a configuration file. The default is a very conservative five (5) forks, though if you have a lot of RAM, you can easily set this to a value like 50 for increased parallelism."
msgid "The full definition of a module, plugin, or role hosted within a collection, in the form <namespace.collection.content_name>. Allows a Playbook to refer to a specific module or plugin from a specific source in an unambiguous manner, for example, ``community.grafana.grafana_dashboard``. The FQCN is required when you want to specify the exact source of a plugin. For example, if multiple collections contain a module plugin called ``user``, the FQCN specifies which one to use for a given task. When you have multiple collections installed, the FQCN is always the explicit and authoritative indicator of which collection to search for the correct plugin for each task."
msgid ":term:`Facts` are mentioned above. Sometimes when running a multi-play :term:`playbook <playbooks>`, it is desirable to have some plays that don't bother with fact computation if they aren't going to need to utilize any of these values. Setting ``gather_facts: False`` on a playbook allows this implicit fact gathering to be skipped."
msgid "Globbing is a way to select lots of hosts based on wildcards, rather than the name of the host specifically, or the name of the group they are in. For instance, it is possible to select ``ww*`` to match all hosts starting with ``www``. This concept is pulled directly from :program:`Func`, one of Michael DeHaan's (an Ansible Founder) earlier projects. In addition to basic globbing, various set operations are also possible, such as 'hosts in this group and not in another group', and so on."
msgid "A group consists of several hosts assigned to a pool that can be conveniently targeted together, as well as given variables that they share in common."
msgid "The :file:`group_vars/` files are files that live in a directory alongside an inventory file, with an optional filename named after each group. This is a convenient place to put variables that are provided to a given group, especially complex data structures, so that these variables do not have to be embedded in the :term:`inventory` file or :term:`playbook <playbooks>`."
msgid "Handlers are just like regular tasks in an Ansible :term:`playbook <playbooks>` (see :term:`Tasks`) but are only run if the Task contains a ``notify`` directive and also indicates that it changed something. For example, if a config file is changed, then the task referencing the config file templating operation may notify a service restart handler. This means services can be bounced only if they need to be restarted. Handlers can be used for things other than service restarts, but service restarts are the most common usage."
msgid "A host is simply a remote machine that Ansible manages. They can have individual variables assigned to them, and can also be organized in groups. All hosts have a name they can be reached at (which is either an IP address or a domain name) and, optionally, a port number, if they are not to be accessed on the default SSH port."
msgid "Each :term:`Play <plays>` in Ansible maps a series of :term:`tasks` (which define the role, purpose, or orders of a system) to a set of systems."
msgid "Just like :term:`Group Vars`, a directory alongside the inventory file named :file:`host_vars/` can contain a file named after each hostname in the inventory file, in :term:`YAML` format. This provides a convenient place to assign variables to the host without having to embed them in the :term:`inventory` file. The Host Vars file can also be used to define complex data structures that can't be represented in the inventory file."
msgid "An operation is idempotent if the result of performing it once is exactly the same as the result of performing it repeatedly without any intervening actions."
msgid "The idea that :term:`playbook <playbooks>` files (which are nothing more than lists of :term:`plays`) can include other lists of plays, and task lists can externalize lists of :term:`tasks` in other files, and similarly with :term:`handlers`. Includes can be parameterized, which means that the loaded file can pass variables. For instance, an included play for setting up a WordPress blog may take a parameter called ``user`` and that play could be included more than once to create a blog for both ``alice`` and ``bob``."
msgid "A file (by default, Ansible uses a simple INI format) that describes :term:`Hosts <Host>` and :term:`Groups <Group>` in Ansible. Inventory can also be provided via an :term:`Inventory Script` (sometimes called an \"External Inventory Script\")."
msgid "A very simple program (or a complicated one) that looks up :term:`hosts <Host>`, :term:`group` membership for hosts, and variable information from an external resource -- whether that be a SQL database, a CMDB solution, or something like LDAP. This concept was adapted from Puppet (where it is called an \"External Nodes Classifier\") and works more or less exactly the same way."
msgid "Jinja2 is the preferred templating language of Ansible's template module. It is a very simple Python template language that is generally readable and easy to write."
msgid "In general, Ansible evaluates any variables in :term:`playbook <playbooks>` content at the last possible second, which means that if you define a data structure that data structure itself can define variable values within it, and everything \"just works\" as you would expect. This also means variable strings can include other variables inside of those strings."
msgid "By passing ``--limit somegroup`` to :command:`ansible` or :command:`ansible-playbook`, the commands can be limited to a subset of :term:`hosts <Host>`. For instance, this can be used to run a :term:`playbook <playbooks>` that normally targets an entire set of servers to one particular server."
msgid "A local_action directive in a :term:`playbook <playbooks>` targeting remote machines means that the given step will actually occur on the local machine, but that the variable ``{{ ansible_hostname }}`` can be passed in to reference the remote hostname being referred to in that step. This can be used to trigger, for example, an rsync operation."
msgid "By using ``connection: local`` in a :term:`playbook <playbooks>`, or passing ``-c local`` to :command:`/usr/bin/ansible`, this indicates that we are managing the local host and not a remote machine."
msgid "A lookup plugin is a way to get data into Ansible from the outside world. Lookup plugins are an extension of Jinja2 and can be accessed in templates, for example, ``{{ lookup('file','/path/to/file') }}``. These are how such things as ``with_items``, are implemented. There are also lookup plugins like ``file`` which loads data from a file and ones for querying environment variables, DNS text records, or key value stores."
msgid "Generally, Ansible is not a programming language. It prefers to be more declarative, though various constructs like ``loop`` allow a particular task to be repeated for multiple items in a list. Certain modules, like :ref:`yum <yum_module>` and :ref:`apt <apt_module>`, actually take lists directly, and can install all packages given in those lists within a single transaction, dramatically speeding up total time to configuration, so they can be used without loops."
msgid "Modules are the units of work that Ansible ships out to remote machines. Modules are kicked off by either :command:`/usr/bin/ansible` or :command:`/usr/bin/ansible-playbook` (where multiple tasks use lots of different modules in conjunction). Modules can be implemented in any language, including Perl, Bash, or Ruby -- but can leverage some useful communal library code if written in Python. Modules just have to return :term:`JSON`. Once modules are executed on remote machines, they are removed, so no long running daemons are used. Ansible refers to the collection of available modules as a :term:`library`."
msgid "The concept that IT systems are not managed one system at a time, but by interactions between multiple systems and groups of systems in well defined orders. For instance, a web server may need to be updated before a database server and pieces on the web server may need to be updated after *THAT* database server and various load balancers and monitoring servers may need to be contacted. Ansible models entire IT topologies and workflows rather than looking at configuration from a \"one system at a time\" perspective."
msgid "The first part of a fully qualified collection name, the namespace usually reflects a functional content category. Example: in ``cisco.ios.ios_config``, ``cisco`` is the namespace. Namespaces are reserved and distributed by Red Hat at Red Hat's discretion. Many, but not all, namespaces will correspond with vendor names. See `Galaxy namespaces <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_ on the Galaxy docsite for namespace requirements."
msgstr "完全修飾コレクション名の最初の部分で、名前空間は通常、機能的なコンテンツカテゴリーを反映しています。たとえば、``cisco.ios.ios_config`` では、``cisco`` が名前空間になります。名前空間は Red Hat によって予約され、Red Hat の裁量で配布されます。すべてではありませんが、多くの名前空間はベンダーの名前に対応しています。名前空間の要件については、Galaxy ドキュメントサイトの「`Galaxy 名前空間 <https://galaxy.ansible.com/docs/contributing/namespaces.html#galaxy-namespaces>`_」を参照してください。"
msgid "The act of a :term:`task <tasks>` registering a change event and informing a :term:`handler <handlers>` task that another :term:`action` needs to be run at the end of the :term:`play <plays>`. If a handler is notified by multiple tasks, it will still be run only once. Handlers are run in the order they are listed, not in the order that they are notified."
msgid "Many software automation systems use this word to mean different things. Ansible uses it as a conductor would conduct an orchestra. A datacenter or cloud architecture is full of many systems, playing many parts -- web servers, database servers, maybe load balancers, monitoring systems, continuous integration systems, and so on. In performing any process, it is necessary to touch systems in particular orders, often to simulate rolling updates or to deploy software correctly. Some system may perform some steps, then others, then previous systems already processed may need to perform more steps. Along the way, emails may need to be sent or web services contacted. Ansible orchestration is all about modeling that kind of process."
msgstr "多くのソフトウェア自動化システムでは、この言葉をさまざまな意味で使用しています。Ansible は、この言葉を「指揮者がオーケストラを指揮する」という意味で使用しています。データセンターやクラウドのアーキテクチャには、Web サーバー、データベースサーバー、ロードバランサー、監視システム、継続的統合システムなど、多くのシステムが存在し、さまざまな役割を担っています。プロセスを実行する際には、特定の順序でシステムに触れる必要があります。これは、ローリングアップデートをシミュレートしたり、ソフトウェアを正しくデプロイするためです。あるシステムがいくつかのステップを実行し、次に他のシステムを実行し、すでに処理された前のシステムがさらにステップを実行する必要があるかもしれません。その過程で、メールの送信や Web サービスへの問い合わせが必要になることもあります。Ansible のオーケストレーションは、このようなプロセスをモデル化するためのものです。"
msgid "By default, Ansible manages machines over SSH. The library that Ansible uses by default to do this is a Python-powered library called paramiko. The paramiko library is generally fast and easy to manage, though users who want to use Kerberos or Jump Hosts may wish to switch to a native SSH binary such as OpenSSH by specifying the connection type in their :term:`playbooks`, or using the ``-c ssh`` flag."
msgid "Playbooks are the language by which Ansible orchestrates, configures, administers, or deploys systems. They are called playbooks partially because it's a sports analogy, and it's supposed to be fun using them. They aren't workbooks :)"
msgid "A :term:`playbook <playbooks>` is a list of plays. A play is minimally a mapping between a set of :term:`hosts <Host>` selected by a host specifier (usually chosen by :term:`groups <Group>` but sometimes by hostname :term:`globs <Globbing>`) and the :term:`tasks` which run on those hosts to define the role that those systems will perform. There can be one or many plays in a playbook."
msgid "By default, Ansible runs in :term:`push mode`, which allows it very fine-grained control over when it talks to each system. Pull mode is provided for when you would rather have nodes check in every N minutes on a particular schedule. It uses a program called :command:`ansible-pull` and can also be set up (or reconfigured) using a push-mode :term:`playbook <playbooks>`. Most Ansible users use push mode, but pull mode is included for variety and the sake of having choices."
msgid ":command:`ansible-pull` works by checking configuration orders out of git on a crontab and then managing the machine locally, using the :term:`local connection` plugin."
msgid "Push mode is the default mode of Ansible. In fact, it's not really a mode at all -- it's just how Ansible works when you aren't thinking about it. Push mode allows Ansible to be fine-grained and conduct nodes through complex orchestration processes without waiting for them to check in."
msgid "The result of running any :term:`task <tasks>` in Ansible can be stored in a variable for use in a template or a conditional statement. The keyword used to define the variable is called ``register``, taking its name from the idea of registers in assembly programming (though Ansible will never feel like assembly programming). There are an infinite number of variable names you can use for registration."
msgid "Ansible modules work in terms of resources. For instance, the :ref:`file module <file_module>` will select a particular file and ensure that the attributes of that resource match a particular model. As an example, we might wish to change the owner of :file:`/etc/motd` to ``root`` if it is not already set to ``root``, or set its mode to ``0644`` if it is not already set to ``0644``. The resource models are :term:`idempotent <idempotency>` meaning change commands are not run unless needed, and Ansible will bring the system back to a desired state regardless of the actual state -- rather than you having to tell it how to get to the state."
msgid "Roles are units of organization in Ansible. Assigning a role to a group of :term:`hosts <Host>` (or a set of :term:`groups <group>`, or :term:`host patterns <Globbing>`, and so on) implies that they should implement a specific behavior. A role may include applying certain variable values, certain :term:`tasks`, and certain :term:`handlers` -- or just one or more of these things. Because of the file structure associated with a role, roles become redistributable units that allow you to share behavior among :term:`playbooks` -- or even with other users."
msgid "The act of addressing a number of nodes in a group N at a time to avoid updating them all at once and bringing the system offline. For instance, in a web topology of 500 nodes handling very large volume, it may be reasonable to update 10 or 20 machines at a time, moving on to the next 10 or 20 when done. The ``serial:`` keyword in an Ansible :term:`playbooks` control the size of the rolling update pool. The default is to address the batch size all at once, so this is something that you must opt-in to. OS configuration (such as making sure config files are correct) does not typically have to use the rolling update model, but can do so if desired."
msgid "Ansible does not require root logins, and since it's daemonless, definitely does not require root level daemons (which can be a security concern in sensitive environments). Ansible can log in and perform many operations wrapped in a sudo command, and can work with both password-less and password-based sudo. Some operations that don't normally work with sudo (like scp file transfer) can be achieved with Ansible's :ref:`copy <copy_module>`, :ref:`template <template_module>`, and :ref:`fetch <fetch_module>` modules while running in sudo mode."
msgid "Native OpenSSH as an Ansible transport is specified with ``-c ssh`` (or a config file, or a directive in the :term:`playbook <playbooks>`) and can be useful if wanting to login via Kerberized SSH or using SSH jump hosts, and so on. In 1.2.1, ``ssh`` will be used by default if the OpenSSH binary on the control machine is sufficiently new. Previously, Ansible selected ``paramiko`` as a default. Using a client that supports ``ControlMaster`` and ``ControlPersist`` is recommended for maximum performance -- if you don't have that and don't need Kerberos, jump hosts, or other features, ``paramiko`` is a good choice. Ansible will warn you if it doesn't detect ControlMaster/ControlPersist capability."
msgid "Ansible allows tagging resources in a :term:`playbook <playbooks>` with arbitrary keywords, and then running only the parts of the playbook that correspond to those keywords. For instance, it is possible to have an entire OS configuration, and have certain steps labeled ``ntp``, and then run just the ``ntp`` steps to reconfigure the time server information on a remote host."
msgid ":term:`Playbooks` exist to run tasks. Tasks combine an :term:`action` (a module and its arguments) with a name and optionally some other keywords (like :term:`looping directives <loops>`). :term:`Handlers` are also tasks, but they are a special kind of task that do not run unless they are notified by name when a task reports an underlying change on a remote system."
msgid "Ansible can easily transfer files to remote systems but often it is desirable to substitute variables in other files. Variables may come from the :term:`inventory` file, :term:`Host Vars`, :term:`Group Vars`, or :term:`Facts`. Templates use the :term:`Jinja2` template engine and can also include logical constructs like loops and if statements."
msgid "Ansible uses :term:``Connection Plugins`` to define types of available transports. These are simply how Ansible will reach out to managed systems. Transports included are :term:`paramiko`, :term:`ssh <SSH (Native)>` (using OpenSSH), and :term:`local <Local Connection>`."
msgid "An optional conditional statement attached to a :term:`task <tasks>` that is used to determine if the task should run or not. If the expression following the ``when:`` keyword evaluates to false, the task will be ignored."
msgid "As opposed to :term:`Facts`, variables are names of values (they can be simple scalar values -- integers, booleans, strings) or complex ones (dictionaries/hashes, lists) that can be used in templates and :term:`playbooks`. They are declared things, not things that are inferred from the remote system's current state or nature (which is what Facts are)."
msgid "Ansible does not want to force people to write programming language code to automate infrastructure, so Ansible uses YAML to define :term:`playbook <playbooks>` configuration languages and also variable files. YAML is nice because it has a minimum of syntax and is very clean and easy for people to skim. It is a good data format for configuration files and humans, but also machine readable. Ansible's usage of YAML stemmed from Michael DeHaan's first use of it inside of Cobbler around 2006. YAML is fairly popular in the dynamic language community and the format has libraries available for serialization in many languages (Python, Perl, Ruby, and so on)."
msgid "Most Ansible modules that execute under a POSIX environment require a Python interpreter on the target host. Unless configured otherwise, Ansible will attempt to discover a suitable Python interpreter on each target host the first time a Python module is executed for that host."
msgid "Detects the target OS platform, distribution, and version, then consults a table listing the correct Python interpreter and path for each platform/distribution/version. If an entry is found, and ``/usr/bin/python`` is absent, uses the discovered interpreter (and path). If an entry is found, and ``/usr/bin/python`` is present, uses ``/usr/bin/python`` and issues a warning. This exception provides temporary compatibility with previous versions of Ansible that always defaulted to ``/usr/bin/python``, so if you have installed Python and other dependencies at ``/usr/bin/python`` on some hosts, Ansible will find and use them with this setting. If no entry is found, or the listed Python is not present on the target host, searches a list of common Python interpreter paths and uses the first one found; also issues a warning that future installation of another Python interpreter could alter the one chosen."
msgid "Detects the target OS platform, distribution, and version, then consults a table listing the correct Python interpreter and path for each platform/distribution/version. If an entry is found, uses the discovered interpreter. If no entry is found, or the listed Python is not present on the target host, searches a list of common Python interpreter paths and uses the first one found; also issues a warning that future installation of another Python interpreter could alter the one chosen."
msgstr "ターゲット OS プラットフォーム、ディストリビューション、およびバージョンを検出してから、各プラットフォーム/ディストリビューション/バージョンに適した Python インタープリターとパスを表示するテーブルを参照します。エントリーが見つからなかった場合や、リストされた Python がターゲットホストにない場合は、一般的な Python インタープリターパスのリストを検索し、最初に検出したインタープリターを使用します。また、今後別のインタープリターをインストールすると、選択したパスが変更する可能性があるという警告が表示されます。"
msgid "You can still set ``ansible_python_interpreter`` to a specific path at any variable level (for example, in host_vars, in vars files, in playbooks, and so on). Setting a specific path completely disables automatic interpreter discovery; Ansible always uses the path specified."
msgid "By default Ansible sends output about plays, tasks, and module arguments to your screen (STDOUT) on the control node. If you want to capture Ansible output in a log, you have three options:"
msgid "To save Ansible output in a single log on the control node, set the ``log_path`` :ref:`configuration file setting <intro_configuration>`. You may also want to set ``display_args_to_stdout``, which helps to differentiate similar tasks by including variable values in the Ansible output."
msgid "To save Ansible output in separate logs, one on each managed node, set the ``no_target_syslog`` and ``syslog_facility`` :ref:`configuration file settings <intro_configuration>`."
msgid "To save Ansible output to a secure database, use :ref:`Ansible Tower <ansible_tower>`. Tower allows you to review history based on hosts, projects, and particular inventories over time, using graphs and/or a REST API."
msgstr "Ansible の出力を安全なデータベースに保存するには、:ref:`Ansible Tower <ansible_tower>` を使用します。Tower を使用すると、グラフや REST API を使用して、ホスト、プロジェクト、および特定のインベントリーに基づいて履歴を確認できます。"
#: ../../rst/reference_appendices/logging.rst:12
msgid "Protecting sensitive data with ``no_log``"
msgstr "``no_log`` を使用した機密データの保護"
#: ../../rst/reference_appendices/logging.rst:14
msgid "If you save Ansible output to a log, you expose any secret data in your Ansible output, such as passwords and user names. To keep sensitive values out of your logs, mark tasks that expose them with the ``no_log: True`` attribute. However, the ``no_log`` attribute does not affect debugging output, so be careful not to debug playbooks in a production environment. See :ref:`keep_secret_data` for an example."
#: ansible.module_utils.basic.AnsibleModule.atomic_move:1 of
msgid "atomically move src to dest, copying attributes from dest, returns true on success it uses os.rename to ensure this as it is an atomic operation, rest of the function is to work around limitations, corner cases and ensure selinux context is saved if possible"
#: ansible.module_utils.basic.AnsibleModule.get_bin_path:5 of
msgid "optional list of directories to search in addition to ``PATH``"
msgstr "``PATH`` と、検索するディレクトリーのオプションの一覧です。"
#: ansible.module_utils.basic.AnsibleModule.get_bin_path:6 of
msgid "if found return full path; otherwise return None"
msgstr "見つかった場合はフルパスを返します。見つからない場合は None を返します。"
#: ansible.module_utils.basic.AnsibleModule.is_executable:1 of
msgid "is the given path executable?"
msgstr "指定のパスは実行ファイルですか。"
#: ansible.module_utils.basic.AnsibleModule.is_executable:3 of
msgid "The path of the file to check."
msgstr "確認するファイルのパス。"
#: ansible.module_utils.basic.AnsibleModule.is_executable:5 of
msgid "Limitations:"
msgstr "制限事項:"
#: ansible.module_utils.basic.AnsibleModule.is_executable:7 of
msgid "Does not account for FSACLs."
msgstr "FSACL を考慮しません。"
#: ansible.module_utils.basic.AnsibleModule.is_executable:8 of
msgid "Most times we really want to know \"Can the current user execute this file\". This function does not tell us that, only if any execute bit is set."
#: ansible.module_utils.basic.AnsibleModule.is_special_selinux_path:1 of
msgid "Returns a tuple containing (True, selinux_context) if the given path is on a NFS or other 'special' fs mount point, otherwise the return will be (False, None)."
#: ansible.module_utils.basic.AnsibleModule.load_file_common_arguments:1 of
msgid "many modules deal with files, this encapsulates common options that the file module accepts such that it is directly available to all modules and they can share code."
#: ansible.module_utils.basic.AnsibleModule.md5:5 of
msgid "Do not use this function unless you have no other choice for:"
msgstr "他の選択肢がない場合は、この機能を使用しないでください。"
#: ansible.module_utils.basic.AnsibleModule.md5:4 of
msgid "Optional backwards compatibility"
msgstr "任意の下位互換性"
#: ansible.module_utils.basic.AnsibleModule.md5:5 of
msgid "Compatibility with a third party protocol"
msgstr "サードパーティープロトコルとの互換性"
#: ansible.module_utils.basic.AnsibleModule.md5:7 of
msgid "This function will not work on systems complying with FIPS-140-2."
msgstr "この機能は、FIPS-140-2 に準拠するシステムでは機能しません。"
#: ansible.module_utils.basic.AnsibleModule.md5:9 of
msgid "Most uses of this function can use the module.sha1 function instead."
msgstr "この機能の大半は、代わりに module.sha1 関数を使用できます。"
#: ansible.module_utils.basic.AnsibleModule.preserved_copy:1 of
msgid "Copy a file with preserved ownership, permissions and context"
msgstr "保存済みの所有権、パーミッション、およびコンテキストでファイルをコピーします。"
#: ansible.module_utils.basic.AnsibleModule.run_command:1 of
msgid "Execute a command, returns rc, stdout, and stderr."
msgstr "コマンドを実行して、rc、stdout、および stderr を返します。"
#: ansible.module_utils.basic.AnsibleModule.run_command:3 of
msgid "is the command to run * If args is a list, the command will be run with shell=False. * If args is a string and use_unsafe_shell=False it will split args to a list and run with shell=False * If args is a string and use_unsafe_shell=True it runs with shell=True."
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw path_prefix"
msgstr "kw path_prefix"
#: ansible.module_utils.basic.AnsibleModule.run_command:13 of
msgid "If given, additional path to find the command in. This adds to the PATH environment variable so helper commands in the same directory can also be found"
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw cwd"
msgstr "kw cwd"
#: ansible.module_utils.basic.AnsibleModule.run_command:16 of
msgid "If given, working directory to run the command inside"
msgstr "指定した場合は、コマンドを実行する作業ディレクトリー"
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw use_unsafe_shell"
msgstr "kw use_unsafe_shell"
#: ansible.module_utils.basic.AnsibleModule.run_command:17 of
msgid "See `args` parameter. Default False"
msgstr "`args` パラメーターを参照してください (デフォルトは False)。"
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw prompt_regex"
msgstr "kw prompt_regex"
#: ansible.module_utils.basic.AnsibleModule.run_command:18 of
msgid "Regex string (not a compiled regex) which can be used to detect prompts in the stdout which would otherwise cause the execution to hang (especially if no input data is specified)"
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw environ_update"
msgstr "kw environ_update"
#: ansible.module_utils.basic.AnsibleModule.run_command:21 of
msgid "dictionary to *update* os.environ with"
msgstr "os.environ を *更新* するディクショナリー"
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw umask"
msgstr "kw umask"
#: ansible.module_utils.basic.AnsibleModule.run_command:22 of
msgid "Umask to be used when running the command. Default None"
msgstr "コマンドを実行する際に使用される umask です。デフォルトは None。"
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw encoding"
msgstr "kw encoding"
#: ansible.module_utils.basic.AnsibleModule.run_command:23 of
msgid "Since we return native strings, on python3 we need to know the encoding to use to transform from bytes to text. If you want to always get bytes back, use encoding=None. The default is \"utf-8\". This does not affect transformation of strings given as args."
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw errors"
msgstr "kw errors"
#: ansible.module_utils.basic.AnsibleModule.run_command:28 of
msgid "Since we return native strings, on python3 we need to transform stdout and stderr from bytes to text. If the bytes are undecodable in the ``encoding`` specified, then use this error handler to deal with them. The default is ``surrogate_or_strict`` which means that the bytes will be decoded using the surrogateescape error handler if available (available on all python3 versions we support) otherwise a UnicodeError traceback will be raised. This does not affect transformations of strings given as args."
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw expand_user_and_vars"
msgstr "kw expand_user_and_vars"
#: ansible.module_utils.basic.AnsibleModule.run_command:37 of
msgid "When ``use_unsafe_shell=False`` this argument dictates whether ``~`` is expanded in paths and environment variables are expanded before running the command. When ``True`` a string such as ``$SHELL`` will be expanded regardless of escaping. When ``False`` and ``use_unsafe_shell=False`` no path or variable expansion will be done."
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw pass_fds"
msgstr "kw pass_fds"
#: ansible.module_utils.basic.AnsibleModule.run_command:42 of
msgid "When running on Python 3 this argument dictates which file descriptors should be passed to an underlying ``Popen`` constructor. On Python 2, this will set ``close_fds`` to False."
#: ansible.module_utils.basic.AnsibleModule.run_command of
msgid "kw before_communicate_callback"
msgstr "kw before_communicate_callback"
#: ansible.module_utils.basic.AnsibleModule.run_command:46 of
msgid "This function will be called after ``Popen`` object will be created but before communicating to the process. (``Popen`` object will be passed to callback as a first argument)"
#: ansible.module_utils.basic.AnsibleModule.run_command:53 of
msgid "A 3-tuple of return code (integer), stdout (native string), and stderr (native string). On python2, stdout and stderr are both byte strings. On python3, stdout and stderr are text strings converted according to the encoding and errors parameters. If you want byte strings on python3, use encoding=None to turn decoding to text off."
msgid "Name of the platform the module is running on in a native string"
msgstr "モジュールがネイティブ文字列で実行されているプラットフォームの名前"
#: ansible.module_utils.basic.get_platform:5 of
msgid "Returns a native string that labels the platform (\"Linux\", \"Solaris\", etc). Currently, this is the result of calling :py:func:`platform.system`."
msgid "These are the keywords available on common playbook objects. Keywords are one of several sources for configuring Ansible behavior. See :ref:`general_precedence_rules` for details on the relative precedence of each source."
msgid "Aliases for the directives are not reflected here, nor are mutable one. For example, :term:`action` in task can be substituted by the name of any Ansible module."
msgid "Boolean that controls if privilege escalation is used or not on :term:`Task` execution. Implemented by the become plugin. See :ref:`become_plugins`."
msgid "Tasks within a role do not inherit the value of ``collections`` from the play. To have a role search a list of collections, use the ``collections`` keyword in ``meta/main.yml`` within a role."
msgid "A dictionary that gets converted into environment vars to be provided for the task upon execution. This can ONLY be used with modules. This isn't supported for any other type of plugins nor Ansible itself nor its configuration, it just sets the variables for the code responsible for executing the task. This is not a recommended way to pass in confidential data."
msgid "A section with tasks that are treated as handlers, these won't get executed normally, only when notified after each section of tasks is complete. A handler's `listen` field is not templatable."
msgid "Boolean that allows you to ignore task failures due to an unreachable host and continue with the play. This does not affect other task errors (see :term:`ignore_errors`) but is useful for groups of volatile/ephemeral hosts."
msgid "can be used to abort the run after a given percentage of hosts in the current batch has failed. This only wokrs on linear or linear derived strategies."
msgid "Controls the sorting of hosts as they are used for executing the play. Possible values are inventory (default), sorted, reverse_sorted, reverse_inventory and shuffle."
msgid "Boolean that will bypass the host loop, forcing the task to attempt to execute on the first host available and afterwards apply any results and facts to all active hosts in the same batch."
msgid "Limit number of concurrent task runs on task, block and playbook level. This is independent of the forks and serial settings, but cannot be set higher than those limits. For example, if forks is set to 10 and the throttle is set to 15, at most 10 hosts will be operated on in parallel."
msgid "Ansible 2.5 and above work with Python 3. Previous to 2.5, using Python 3 was considered a tech preview. This topic discusses how to set up your controller and managed machines to use Python 3."
msgid "On the controller we support Python 3.5 or greater and Python 2.7 or greater. Module-side, we support Python 3.5 or greater and Python 2.6 or greater."
msgid "The easiest way to run :command:`/usr/bin/ansible` under Python 3 is to install it with the Python3 version of pip. This will make the default :command:`/usr/bin/ansible` run with Python3:"
msgid "If you are running Ansible :ref:`from_source` and want to use Python 3 with your source checkout, run your command via ``python3``. For example:"
msgid "Individual Linux distribution packages may be packaged for Python2 or Python3. When running from distro packages you'll only be able to use Ansible with the Python version for which it was installed. Sometimes distros will provide a means of installing for several Python versions (via a separate package or via some commands that are run after install). You'll need to check with your distro to see if that applies in your case."
msgid "Ansible will automatically detect and use Python 3 on many platforms that ship with it. To explicitly configure a Python 3 interpreter, set the ``ansible_python_interpreter`` inventory variable at a group or host level to the location of a Python 3 interpreter, such as :command:`/usr/bin/python3`. The default interpreter path may also be set in ``ansible.cfg``."
msgid "Note that you can also use the `-e` command line option to manually set the python interpreter when you run a command. This can be useful if you want to test whether a specific module or playbook has any bugs under Python 3. For example:"
msgid "We have spent several releases squashing bugs and adding new tests so that Ansible's core feature set runs under both Python 2 and Python 3. However, bugs may still exist in edge cases and many of the modules shipped with Ansible are maintained by the community and not all of those may be ported yet."
msgid "If you find a bug running under Python 3 you can submit a bug report on `Ansible's GitHub project <https://github.com/ansible/ansible/issues/>`_. Be sure to mention Python3 in the bug report so that the right people look at it."
msgid "If you would like to fix the code and submit a pull request on github, you can refer to :ref:`developing_python_3` for information on how we fix common Python3 compatibility issues in the Ansible codebase."
msgid "This section describes the Ansible and ``ansible-core`` releases. Ansible is the package that most users install. ``ansible-core`` is primarily for developers."
msgid "Ansible is developed and released on a flexible release cycle. This cycle can be extended in order to allow for larger changes to be properly implemented and tested before a new release is made available. See :ref:`roadmaps` for upcoming release details."
msgid "For Ansible version 2.10 or later, the major release is maintained for one release cycle. When the next release comes out (for example, 2.11), the older release (2.10 in this example) is no longer maintained."
msgid "If you are using a release of Ansible that is no longer maintained, we strongly encourage you to upgrade as soon as possible in order to benefit from the latest features and security fixes."
msgid "You can refer to the :ref:`porting guides<porting_guides>` for tips on updating your Ansible playbooks to run on newer versions. For Ansible 2.10 and later releases, you can install the Ansible package with ``pip``. See :ref:`intro_installation_guide` for details. For older releases, You can download the Ansible release from `<https://releases.ansible.com/ansible/>`_."
msgid "This table links to the release notes for each major Ansible release. These release notes (changelogs) contain the dates and significant changes in each minor release."
msgid "``ansible-core`` is developed and released on a flexible release cycle. This cycle can be extended in order to allow for larger changes to be properly implemented and tested before a new release is made available. See :ref:`roadmaps` for upcoming release details."
msgid "``ansible-core`` has a graduated maintenance structure that extends to three major releases. For more information, read about the :ref:`development_and_stable_version_maintenance_workflow` or see the chart in :ref:`release_schedule` for the degrees to which current releases are maintained."
msgid "If you are using a release of ``ansible-core`` that is no longer maintained, we strongly encourage you to upgrade as soon as possible in order to benefit from the latest features and security fixes."
msgid "``ansible-core`` maintenance continues for 3 releases. Thus the latest release receives security and general bug fixes when it is first released, security and critical bug fixes when the next ``ansible-core`` version is released, and **only** security fixes once the follow on to that version is released."
msgid "This table links to the release notes for each major ``ansible-core`` release. These release notes (changelogs) contain the dates and significant changes in each minor release."
msgid "Collection updates (new modules, plugins, features and bugfixes) will always be integrated in what will become the next version of Ansible. This work is tracked within the individual collection repositories."
msgid "Ansible and ``ansible-core`` provide bugfixes and security improvements for the most recent major release. The previous major release of ``ansible-core`` will only receive fixes for security issues and critical bugs. ``ansible-core`` only applies security fixes to releases which are two releases old. This work is tracked on the ``stable-<version>`` git branches."
msgid "Note that while there are no guarantees for providing fixes for unmaintained releases of Ansible, there can sometimes be exceptions for critical issues."
msgid "We generate changelogs based on fragments. Here is the generated changelog for 2.9_ as an example. When creating new features or fixing bugs, create a changelog fragment describing the change. A changelog entry is not needed for new modules or plugins. Details for those items will be generated from the module documentation."
msgid "Ansible and ``ansible-core`` tag the first release candidate (``RC1``) which is usually scheduled to last five business days. The final release is done if no major bugs or issues are identified during this period."
msgid "If there are major problems with the first candidate, a second candidate will be tagged (``RC2``) once the necessary fixes have landed. This second candidate lasts for a shorter duration than the first. If no problems have been reported after two business days, the final release is done."
msgid "More release candidates can be tagged as required, so long as there are bugs that the Ansible or ``ansible-core`` core maintainers consider should be fixed before the final release."
msgid "Merging new features or fixes that are not related to the release candidate may be delayed in order to allow the new release to be shipped as soon as possible."
msgid "Sometimes we need to remove a feature, normally in favor of a reimplementation that we hope does a better job. To do this we have a deprecation cycle. First we mark a feature as 'deprecated'. This is normally accompanied with warnings to the user as to why we deprecated it, what alternatives they should switch to and when (which version) we are scheduled to remove the feature permanently."
msgid "Since Ansible is a package of individual collections, the deprecation cycle depends on the collection maintainers. We recommend the collection maintainers deprecate a feature in one Ansible major version and do not remove that feature for one year, or at least until the next major Ansible version. For example, deprecate the feature in 2.10.2, and do not remove the feature until 2.12.0. Collections should use semantic versioning, such that the major collection version cannot be changed within an Ansible major version. Thus the removal should not happen before the next major Ansible release. This is up to each collection maintainer and cannot be guaranteed."
msgid "The cycle is normally across 4 feature releases (2.x.y, where the x marks a feature release and the y a bugfix release), so the feature is normally removed in the 4th release after we announce the deprecation. For example, something deprecated in 2.9 will be removed in 2.13, assuming we don't jump to 3.x before that point. The tracking is tied to the number of releases, not the release numbering."
msgid "When the current role is being executed by means of an :ref:`include_role <include_role_module>` or :ref:`import_role <import_role_module>` action, this variable contains a list of all parent roles, with the most recent role (in other words, the role that included/imported this role) being the first item in the list. When multiple inclusions occur, this list lists the *last* role (in other words, the role that included this role) as the *first* item in the list. It is also possible that a specific role exists more than once in this list."
msgid "For example: When role **A** includes role **B**, inside role B, ``ansible_parent_role_names`` will equal to ``['A']``. If role **B** then includes role **C**, the list becomes ``['B', 'A']``."
msgid "When the current role is being executed by means of an :ref:`include_role <include_role_module>` or :ref:`import_role <import_role_module>` action, this variable contains a list of all parent roles, with the most recent role (in other words, the role that included/imported this role) being the first item in the list. Please refer to ``ansible_parent_role_names`` for the order of items in this list."
msgid "The names of the roles currently imported into the current play. This list does **not** contain the role names that are implicitly included via dependencies."
msgid "The names of the roles currently imported into the current play, or roles referenced as dependencies of the roles imported into the current play."
msgid "Contents of the ``--tags`` CLI option, which specifies which tags will be included for the current run. Note that if ``--tags`` is not passed, this variable will default to ``[\"all\"]``."
msgid "Dictionary/map that contains information about the current running version of ansible, it has the following keys: full, major, minor, revision and string."
msgid "These are variables that contain information pertinent to the current host (`inventory_hostname`). They are only available if gathered first. See :ref:`vars_and_facts` for more information."
msgid "Contains any facts gathered or cached for the `inventory_hostname` Facts are normally gathered by the :ref:`setup <setup_module>` module automatically in a play, but any module can return facts."
msgid "Contains any 'local facts' gathered or cached for the `inventory_hostname`. The keys available depend on the custom facts created. See the :ref:`setup <setup_module>` module and :ref:`local_facts` for more details."
msgid "Connection variables are normally used to set the specifics on how to execute actions on a target. Most of them correspond to connection plugins, but not all are specific to them; other plugins like shell, terminal and become are normally involved. Only the common ones are described as each connection/become/shell/etc plugin can define its own overrides and specific variables. See :ref:`general_precedence_rules` for how connection variables interact with :ref:`configuration settings<ansible_configuration_settings>`, :ref:`command-line options<command_line_tools>`, and :ref:`playbook keywords<playbook_keywords>`."
msgid "Many times, people ask, \"how can I best integrate testing with Ansible playbooks?\" There are many options. Ansible is actually designed to be a \"fail-fast\" and ordered system, therefore it makes it easy to embed testing directly in Ansible playbooks. In this chapter, we'll go into some patterns for integrating tests of infrastructure and discuss the right level of testing that may be appropriate."
msgid "This is a chapter about testing the application you are deploying, not the chapter on how to test Ansible modules during development. For that content, please hop over to the Development section."
msgid "By incorporating a degree of testing into your deployment workflow, there will be fewer surprises when code hits production and, in many cases, tests can be leveraged in production to prevent failed updates from migrating across an entire installation. Since it's push-based, it's also very easy to run the steps on the localhost or testing servers. Ansible lets you insert as many checks and balances into your upgrade workflow as you would like to have."
msgid "Ansible resources are models of desired-state. As such, it should not be necessary to test that services are started, packages are installed, or other such things. Ansible is the system that will ensure these things are declaratively true. Instead, assert these things in your playbooks."
msgid "If you think the service may not be started, the best thing to do is request it to be started. If the service fails to start, Ansible will yell appropriately. (This should not be confused with whether the service is doing something functional, which we'll show more about how to do later)."
msgid "In the above setup, `--check` mode in Ansible can be used as a layer of testing as well. If running a deployment playbook against an existing system, using the `--check` flag to the `ansible` command will report if Ansible thinks it would have had to have made any changes to bring the system into a desired state."
msgid "This can let you know up front if there is any need to deploy onto the given system. Ordinarily, scripts and commands don't run in check mode, so if you want certain steps to execute in normal mode even when the `--check` flag is used, such as calls to the script module, disable check mode for those tasks::"
msgid "It's easy to push an arbitrary script (in any language) on a remote host and the script will automatically fail if it has a non-zero return code::"
msgid "Should you feel the need to test for the existence of files that are not declaratively set by your Ansible configuration, the 'stat' module is a great choice::"
msgid "As mentioned above, there's no need to check things like the return codes of commands. Ansible is checking them automatically. Rather than checking for a user to exist, consider using the user module to make it exist."
msgid "Ansible is a fail-fast system, so when there is an error creating that user, it will stop the playbook run. You do not have to check up behind it."
msgid "As such, deploying into a local development VM and a staging environment will both validate that things are according to plan ahead of your production deploy."
msgid "Something like an integration test battery should be written by your QA team if you are a production webservice. This would include things like Selenium tests or automated API tests and would usually not be something embedded into your Ansible playbooks."
msgstr "実稼働の Web サービスを使用する場合には、QA チームが同様の統合テストバッテリーを記述するようにしてください。このようなテストには Selenium テストや自動化 API テストなどが含まれ、通常は、Ansible Playbook に組み込まれているものではありません。"
msgid "However, it does make sense to include some basic health checks into your playbooks, and in some cases it may be possible to run a subset of the QA battery against remote nodes. This is what the next section covers."
msgid "If you have read into :ref:`playbooks_delegation` it may quickly become apparent that the rolling update pattern can be extended, and you can use the success or failure of the playbook run to decide whether to add a machine into a load balancer or not."
msgid "Of course in the above, the \"take out of the pool\" and \"add back\" steps would be replaced with a call to an Ansible load balancer module or appropriate shell command. You might also have steps that use a monitoring module to start and end an outage window for the machine."
msgid "However, what you can see from the above is that tests are used as a gate -- if the \"apply_testing_checks\" step is not performed, the machine will not go back into the pool."
msgid "Read the delegation chapter about \"max_fail_percentage\" and you can also control how many failing tests will stop a rolling update from proceeding."
msgid "In the event of a problem, fix the few servers that fail using Ansible's automatically generated retry file to repeat the deploy on just those servers."
msgid "Some Ansible users use the above approach to deploy a half-dozen or dozen times an hour without taking all of their infrastructure offline. A culture of automated QA is vital if you wish to get to this level."
msgid "If you are still doing a large amount of manual QA, you should still make the decision on whether to deploy manually as well, but it can still help to work in the rolling update patterns of the previous section and incorporate some basic health checks using modules like 'script', 'stat', 'uri', and 'assert'."
msgid "Ansible believes you should not need another framework to validate basic things of your infrastructure is true. This is the case because Ansible is an order-based system that will fail immediately on unhandled errors for a host, and prevent further configuration of that host. This forces errors to the top and shows them in a summary at the end of the Ansible run."
msgid "However, as Ansible is designed as a multi-tier orchestration system, it makes it very easy to incorporate tests into the end of a playbook run, either using loose tasks or roles. When used with rolling updates, testing steps can decide whether to put a machine back into a load balanced pool or not."
msgid "Finally, because Ansible errors propagate all the way up to the return code of the Ansible program itself, and Ansible by default runs in an easy push-based mode, Ansible is a great step to put into a build environment if you wish to use it to roll out systems as part of a Continuous Integration/Continuous Delivery pipeline, as is covered in sections above."
msgid "The focus should not be on infrastructure testing, but on application testing, so we strongly encourage getting together with your QA team and ask what sort of tests would make sense to run every time you deploy development VMs, and which sort of tests they would like to run against the staging environment on every deploy. Obviously at the development stage, unit tests are great too. But don't unit test your playbook. Ansible describes states of resources declaratively, so you don't have to. If there are cases where you want to be sure of something though, that's great, and things like stat/assert are great go-to modules for that purpose."
msgid "In all, testing is a very organizational and site-specific thing. Everybody should be doing it, but what makes the most sense for your environment will vary with what you are deploying and who is using it -- but everyone benefits from a more robust and reliable deployment system."
msgid "`Red Hat Ansible Tower <https://www.ansible.com/products/tower>`_ is a web console and REST API for operationalizing Ansible across your team, organization, and enterprise. It's designed to be the hub for all of your automation tasks."
msgstr "`Red Hat Ansible Tower <https://www.ansible.com/products/tower>`_ は、チーム、組織、企業全体で Ansible を操作する Web コンソールおよび REST API です。Red Hat Ansible Tower は、すべての自動化タスクのハブとなるように設計されています。"
#: ../../rst/reference_appendices/tower.rst:8
msgid "Ansible Tower gives you role-based access control, including control over the use of securely stored credentials for SSH and other services. You can sync your Ansible Tower inventory with a wide variety of cloud sources, and powerful multi-playbook workflows allow you to model complex processes."
msgid "It logs all of your jobs, integrates well with LDAP, SAML, and other authentication sources, and has an amazing browsable REST API. Command line tools are available for easy integration with Jenkins as well."
msgstr "すべてのジョブをログ記録し、LDAP、SAML、他の認証ソースと統合の相性がよく、ブラウザーで使用可能な素晴らしい REST API が含まれます。また、Jenkins と簡単に統合できるように、コマンドラインも利用できます。"
#: ../../rst/reference_appendices/tower.rst:13
msgid "Ansible Tower is the downstream Red-Hat supported product version of Ansible AWX. Find out more about Ansible Tower features and how to download it on the `Ansible Tower webpage <https://www.ansible.com/products/tower>`_. Ansible Tower is part of the Red Hat Ansible Automation subscription, and comes bundled with amazing support from Red Hat, Inc."
msgstr "Ansible Tower は、Red Hat がサポートする Ansible AWX の製品のバージョン (ダウンストリーム) です。Ansible Tower の機能とそのダウンロード方法の詳細は、`Ansible Tower web ページ <https://www.ansible.com/products/tower>`_ を参照してください。Ansible Tower は、Red Hat Ansible Automation サブスクリプションに含まれ、Red Hat, Inc のサポートが利用できます。"
#~ msgid "ANSIBLE_SSH_ARGS"
#~ msgstr ""
#~ msgid "If set, this will override the Ansible default ssh arguments. In particular, users may wish to raise the ControlPersist time to encourage performance. A value of 30 minutes may be appropriate. Be aware that if `-o ControlPath` is set in ssh_args, the control path setting is not used."
#~ msgid "This is the location to save ssh's ControlPath sockets, it uses ssh's variable substitution. Since 2.3, if null, ansible will generate a unique hash. Use `%(directory)s` to indicate where to use the control dir path setting. Before 2.3 it defaulted to `control_path=%(directory)s/ansible-ssh-%%h-%%p-%%r`. Be aware that this setting is ignored if `-o ControlPath` is set in ssh args."
#~ msgstr ""
#~ msgid "control_path"
#~ msgstr ""
#~ msgid ":envvar:`ANSIBLE_SSH_CONTROL_PATH`"
#~ msgstr ""
#~ msgid "ANSIBLE_SSH_CONTROL_PATH_DIR"
#~ msgstr ""
#~ msgid "This sets the directory to use for ssh control path if the control path setting is null. Also, provides the `%(directory)s` variable for the control path setting."
#~ msgstr ""
#~ msgid "~/.ansible/cp"
#~ msgstr ""
#~ msgid ":envvar:`ANSIBLE_SSH_CONTROL_PATH_DIR`"
#~ msgstr ""
#~ msgid "ANSIBLE_SSH_EXECUTABLE"
#~ msgstr ""
#~ msgid "This defines the location of the ssh binary. It defaults to `ssh` which will use the first ssh binary available in $PATH. This option is usually not required, it might be useful when access to system ssh is restricted, or when using ssh wrappers to connect to remote hosts."
#~ msgstr ""
#~ msgid "ssh"
#~ msgstr ""
#~ msgid "ssh_executable"
#~ msgstr ""
#~ msgid ":envvar:`ANSIBLE_SSH_EXECUTABLE`"
#~ msgstr ""
#~ msgid "ANSIBLE_SSH_RETRIES"
#~ msgstr ""
#~ msgid "Number of attempts to establish a connection before we give up and report the host as 'UNREACHABLE'"
#~ msgstr ""
#~ msgid ":envvar:`ANSIBLE_SSH_RETRIES`"
#~ msgstr ""
#~ msgid "DEFAULT_SCP_IF_SSH"
#~ msgstr ""
#~ msgid "Preferred method to use when transferring files over ssh. When set to smart, Ansible will try them until one succeeds or they all fail. If set to True, it will force 'scp', if False it will use 'sftp'."
#~ msgstr ""
#~ msgid "scp_if_ssh"
#~ msgstr ""
#~ msgid ":envvar:`ANSIBLE_SCP_IF_SSH`"
#~ msgstr ""
#~ msgid "DEFAULT_SFTP_BATCH_MODE"
#~ msgstr ""
#~ msgid "sftp_batch_mode"
#~ msgstr ""
#~ msgid ":envvar:`ANSIBLE_SFTP_BATCH_MODE`"
#~ msgstr ""
#~ msgid "DEFAULT_SSH_TRANSFER_METHOD"
#~ msgstr ""
#~ msgid "unused?"
#~ msgstr ""
#~ msgid "transfer_method"
#~ msgstr ""
#~ msgid ":envvar:`ANSIBLE_SSH_TRANSFER_METHOD`"
#~ msgstr ""
#~ msgid "If set, this will override the Ansible default ssh arguments.In particular, users may wish to raise the ControlPersist time to encourage performance. A value of 30 minutes may be appropriate.Be aware that if `-o ControlPath` is set in ssh_args, the control path setting is not used."
#~ msgstr ""
#~ msgid "See also :ref:`ANSIBLE_SSH_ARGS <ANSIBLE_SSH_ARGS>`"
#~ msgstr ""
#~ msgid "This is the location to save ssh's ControlPath sockets, it uses ssh's variable substitution.Since 2.3, if null, ansible will generate a unique hash. Use `%(directory)s` to indicate where to use the control dir path setting.Before 2.3 it defaulted to `control_path=%(directory)s/ansible-ssh-%%h-%%p-%%r`.Be aware that this setting is ignored if `-o ControlPath` is set in ssh args."
#~ msgstr ""
#~ msgid "See also :ref:`ANSIBLE_SSH_CONTROL_PATH <ANSIBLE_SSH_CONTROL_PATH>`"
#~ msgstr ""
#~ msgid "This sets the directory to use for ssh control path if the control path setting is null.Also, provides the `%(directory)s` variable for the control path setting."
#~ msgstr ""
#~ msgid "See also :ref:`ANSIBLE_SSH_CONTROL_PATH_DIR <ANSIBLE_SSH_CONTROL_PATH_DIR>`"
#~ msgstr ""
#~ msgid "This defines the location of the ssh binary. It defaults to `ssh` which will use the first ssh binary available in $PATH.This option is usually not required, it might be useful when access to system ssh is restricted, or when using ssh wrappers to connect to remote hosts."
#~ msgstr ""
#~ msgid "See also :ref:`ANSIBLE_SSH_EXECUTABLE <ANSIBLE_SSH_EXECUTABLE>`"
#~ msgstr ""
#~ msgid "See also :ref:`ANSIBLE_SSH_RETRIES <ANSIBLE_SSH_RETRIES>`"
#~ msgstr ""
#~ msgid "Preferred method to use when transferring files over ssh.When set to smart, Ansible will try them until one succeeds or they all fail.If set to True, it will force 'scp', if False it will use 'sftp'."
#~ msgstr ""
#~ msgid "See also :ref:`DEFAULT_SCP_IF_SSH <DEFAULT_SCP_IF_SSH>`"
#~ msgstr ""
#~ msgid "See also :ref:`DEFAULT_SFTP_BATCH_MODE <DEFAULT_SFTP_BATCH_MODE>`"
#~ msgstr ""
#~ msgid "See also :ref:`DEFAULT_SSH_TRANSFER_METHOD <DEFAULT_SSH_TRANSFER_METHOD>`"
